To create a dummy Share.exe file
This section summarizes technical information about running applications under Windows 98. For more information about the supporting system components, see Chapter 28, "Windows 98 Architecture."
The following sections describe how system changes affect 16-bit and 32-bit applications and MS-DOS-based applications.
Windows 98 changes the system configuration files, as described in Chapter 5, "Setup Technical Discussion." The following changes affect application support:
To create a dummy Share.exe file
The Distributed Component Object Model (Distributed COM) is based on the COM standard. With COM, an object can have multiple interfaces (the set of methods and properties the object supports). When an application accesses a COM object, it always uses an interface pointer. As a result, the calling application does not need to know the location of the object or how it is implemented. Also, developers can modify the implementation of COM interfaces — or add support for additional interfaces to your components — without rebuilding the client applications that use them.
COM also provides location transparency. All method calls on objects are similar to in-process function calls. The operating system handles all the details of making the call across processes.
As Figure 25.3 shows, Distributed COM extends COM to make the call across computers and to add security mechanisms. An application does not need to know the details of local or remote procedure calls (RPCs).
Figure 25.3 Distributed COM schematic overview
Applications that use Win32 application programming interfaces (APIs) can take full advantage of all Windows 98 performance enhancement features. Win32-based applications can utilize multitasking, Win32 APIs, long file name support, separate message queues, and memory protection. Each Win32-based application runs in its own fully protected, private address space, preventing it from causing the operating system or other applications to fail and preventing interference from errors generated by other applications. In addition, you can manage files from the Open dialog box in Win32-based applications.
To support preemptive multitasking, the Windows 98 kernel schedules the time allotted for running applications. This results in smoother concurrent processing and prevents any one application from using all system resources without permitting other tasks to run. (An exception is when you run an MS-DOS-based application in MS-DOS mode, which gives the application exclusive use of system resources.) Win32-based applications can implement threads to improve the level of detail at which they can take advantage of multitasking. As Figure 25.4 shows, each Win32-based application has its own message queue and, consequently, is not affected by how other tasks access message queues.
Figure 25.4 Message queues in Windows 98
Resources allocated for each Win32-based application tracked on a per-thread basis are automatically freed when the application ends. If an application stops responding, you can press CTRL+ALT+DEL to display the Close Program dialog box, and then close the unresponsive application without affecting other running tasks.
To make the most of Windows 98, your applications should:
A Win32-based application that runs under Windows NT will run well under Windows 98 if it does not use any Windows NT–specific APIs (such as those for security) or if it has been designed to run under both Windows 98 and Windows NT.
Win16-based applications designed for Windows 3.1 run under Windows 98 without modification. Windows 98 ensures that Win16-based applications running on a computer with 16 MB or memory or more perform as well as—or better than—they did under Windows 3.1. In addition, the performance of Win16-based applications is improved, because they can use operating system services provided by the 32-bit system components of Windows 98, including 32-bit device driver components and 32-bit subsystems.
Windows 98 provides the same system resources to both Win32-based and Win16-based applications, but Win16-based applications cannot take advantage of preemptive multitasking. Win16-based applications share memory as well as common input and message queues, and their processes are scheduled cooperatively.
Win16-based applications benefit from preemptive multitasking of other system components, including the 32-bit print and communications subsystems and improvements made in system robustness and protection for the Windows 98 system kernel.
Because all Win16-based applications run in the same VM, an errant application can cause other Win16-based applications to fail, but it should not adversely affect Win32-based applications. However, the improvements made to overall system-wide robustness significantly increase the system’s ability to recover from an errant application. Improved cleanup of the system lessens the likelihood of application errors. Windows 98 tracks resources allocated by Win16-based applications and uses the information to clean up the system after an application exits or ends abnormally, thus freeing up unused resources that the rest of the system can use. If an application does fail, you can press CTRL+ALT+DEL to display the Close Program dialog box, and then close the unresponsive application without affecting other running tasks.
Note
Win16-based applications cannot use long file names. The Windows 98 file system should preserve long file names while you use a Win16-based application to edit files. However, you will lose long file names if you copy files from within existing Win16-based applications, such as user interface replacements.
Windows 98 support for MS-DOS-based applications includes better printing support and improved capabilities for running hardware-intensive applications, such as games.
Each MS-DOS-based application runs in its own VM, allowing multiple 8086-compatible sessions to run on the CPU. This, in turn, allows existing MS-DOS-based applications to run preemptively with the rest of the system. The use of virtual device drivers (VxDs) provides common regulated access to hardware resources. Each application running in a VM appears to run on its own individual computer; this allows applications that were not designed for multitasking to run concurrently with other applications.
VMs are protected from each other and from other running applications. This prevents errant MS-DOS-based applications from overwriting memory that is occupied or used by system components or other applications. If an MS-DOS-based application attempts to access memory outside its address space, the system notifies the user and ends the MS-DOS-based application.
One of the major difficulties MS-DOS-based applications had in the VMs in versions of Windows earlier than Windows 95 was insufficient conventional memory space. By the time MS-DOS-based device drivers, TSR applications, and networking components were loaded with Windows, there often was not enough conventional memory left to allow the MS-DOS-based application to load or run. Windows 98 provides 32-bit, protected-mode driver components that replace many 16-bit, real-mode device driver and TSR counterparts, improving overall system performance and using no conventional memory. The savings in memory with protected-mode components can be significant. For example, a computer using only Windows 98 protected-mode components would save more than 225 KB of conventional memory over the amount used by real-mode networking software, drivers for a mouse and SCSI CD-ROM drive, and SMARTDrive.
Some Windows-based and MS-DOS-based applications may not run well under Windows 98 because they were written to take advantage of characteristics of older operating systems. For example, certain applications use a portion of the title bar to include items other than the title, such as a Quick Help button. Because Windows 98 title bars are not formatted in the same way as Windows 3.x title bars, some information may be overwritten when you run these old applications.
In addition, some applications use interrupts that are not automatically supported by Windows 98. Others do not handle long file names well, or they incorrectly check for the operating system’s version number.
Windows 98 provides the Make Compatible utility to make compatible an application that is initially incompatible with Windows 98. You can use this utility to troubleshoot if you have trouble printing from an application, or if an application stalls or has other performance problems. This utility provides the means to increase stack memory to an application, emulate earlier versions of Windows, and solve other common problems that cause an application not to run with Windows 98. For more information, see online Help.
To run the Make Compatible utility
Note
Many programming tools not specifically designed to run under Windows 98 may run satisfactorily, but the corresponding debugging tools usually do not. Make sure that both the programming and the debugging tools you use are designed for Windows 98.
Some Win16-based and MS-DOS-based disk utilities must be run with special care. In addition, some disk utilities do not perform correctly with long file names. For more information about using Win16-based and MS-DOS-based disk utilities with Windows 98, see Chapter 10, "Disks and File Systems."
Some older terminate-and-stay-resident programs (TSRs) rely on MS-DOS interrupts to monitor everything that happens on the system. However, because of its protected-mode file system, Windows 98 does not use MS-DOS interrupts. If Windows 98 detects that a TSR is trying to monitor these interrupts, it will accommodate the application and send all system information through MS-DOS interrupts. In this way, the TSR can monitor system events successfully. However, doing this will significantly slow the performance of the operating system.
Ios.ini, as described in Chapter 24, "Device Management," includes a list of "safe" drivers and applications. If Windows 98 finds the application listed in Ios.ini, it will not send system events through MS-DOS interrupts, thus avoiding slowed performance.
If you are using an MS-DOS-based application that was designed for an MS-DOS version other than 7.1 (which is the version that Windows 98 reports), you may receive a message that says you are not using the correct version of MS-DOS. If this is the case, you can add the application to the version table. The version table contains a list of executable files, followed by the version number of MS-DOS with which the applications were designed to run. Windows 98 cannot report the correct MS-DOS version to applications unless the version table is loaded into memory.
To display the version table, type setver in a command prompt window. For information about the syntax, parameters, and switches you can use to add an application to the version table, add the question mark (?) switch to the command (that is, type setver /? at the command prompt).
To load the version table, include a device command in Config.sys. For example:
device=c:\windows\setver.exe
If you modify the version table or Config.sys, restart the computer so the changes can take effect.
Some applications incorrectly check the version number of Windows 98. Incorrect version-checking techniques sometimes invert the two bytes that record the version number; thus, version 3.10 would be reported as 10.3. Windows 98 tries to accommodate this possible version-checking error by reporting 3.98 as the version. In this way, if an application looks for a version greater than 3.10 or its inverse, 10.3, the new Windows 98 version proves to be greater.
If the application looks for an exact match for the version number, such as Windows version 3.10, it may not run under Windows 98. To resolve this problem, add the following line to the [Compatibility] section of Win.ini:
compiled_module_name=0x00200000
To determine the compiled module name, right-click an executable file in Windows Explorer, and then click QuickView. The Module Name line provides this information. After you have obtained the module name, the section you add to Win.ini should look similar to the following entry for cc:Mail:
[Compatibility]
CCMAIL=0x00200000
Windows 98 Setup adds entries to Win.ini for many applications that are known to have this problem.
Note
Do not add a permanent entry to Win.ini for an installation application. Install your application first, and then edit the compiled module name in Win.ini.
If a setup application incorrectly detects the version of Windows 98, you may not be able to install the application. In this case, add an entry to the [Compatibility] section of Win.ini for the setup application (for example, SETUP=0x00200000). Install the application, and then immediately remove the section that you added to Win.ini.
Some setup applications do not check the version of the system files they are installing and overwrite the newer Windows 98 versions of those dynamic-link libraries (DLLs). Windows 98 restores its original DLLs after every setup application runs and for the first three startups thereafter. If an application stops running or behaves erratically after you install it, you may need to obtain an updated version of the application that does not overwrite Windows 98 system files.
Versions of Windows earlier than Windows 95 allowed applications to redistribute parts of the system with no ill effects. For example, an application might overwrite a system file with no adverse consequences. In Windows 98, multiple system files have been consolidated to expedite the startup process. If an application tries to overwrite a system file that is no longer used, Windows allows the application to copy the file, but does not use it.
If your application must run with a replacement file, you can add that file to the \Windows\System\Vmm32 directory (which is initially empty after you set up Windows 98).
After you install an application, Windows 98 checks for files that are commonly overwritten by setup applications. If any are found, a dialog box appears, enabling you to restore the files from the hidden \Windows\Sysbckup directory.
Windows 98 includes a new utility, System File Checker, that checks for replaced system files. For information, see Chapter 27, "General Troubleshooting."