To see a report of performance problems
Windows 98 cleans up resources that have not been freed to help reduce system resource limitations. When Windows 98 determines that an application that owned certain resources no longer needs those resources in memory, it reallocates remaining data structures, freeing the resources for use elsewhere in the system.
Wherever possible, Windows 98 is self-tuning, adjusting cache sizes or other elements of the system environment to provide the best performance for the current configuration. Windows 98 can also detect when the loaded drivers or other performance-related components are not providing the optimal performance.
To see a report of performance problems
Windows 98 provides a significant increase in the system resources available to Windows-based and MS-DOS-based applications over what was available under earlier versions of Windows. The net result for users is that they can count on more system resources being available for creating windows, using fonts, running five or more applications simultaneously, and so on.
In Windows 98, to help reduce the system resource limitation, many data structures formerly stored in the 16-bit graphics device interface (GDI) and User heaps are now stored in 32-bit heaps. This provides more room for the remaining data elements to be created.
Table 26.1 shows the system limits in Windows 98, as compared to the constraining limits under Windows 3.1. For more information about how to assess performance of key system resources, see "Identifying Performance Problems with System Monitor" later in this chapter. For more information about the supporting architecture, see Chapter 28, "Windows 98 Architecture."
Table 26.1 Windows 3.1 and Windows 98 system limits
| Resource | Windows 3.11 | Windows 982 |
|---|---|---|
| Windows Menu handles | ~299 | 32 KB |
| Timers | 32 | Unlimited |
| COM and LPT ports | 4 per type | Unlimited |
| Items per list box | 8 KB | 32 KB |
| Data per list box | 64 KB | Unlimited |
| Data per edit control | 64 KB | Unlimited |
| Regions | All in 64 KB segment | Unlimited |
| Physical pens and brushes | All in 64 KB segment | Unlimited |
| Logical pens and brushes | All in 64 KB segment | All in 64 KB segment |
| Logical fonts | All in 64 KB segment | 750 – 800 |
| Installed fonts | 250 – 300 (best case) | 1000 |
| Device contexts | 200 (best case) | 16 KB |
| 1 Limits for GDI objects in Windows 3.1 are not exact, because all regions, physical objects, logical objects, device contexts (DCs), and installed fonts had to fit in a single 64 KB segment. Because many of these have been moved to the 32-bit heap, Windows 98 provides much more room for remaining items, such as logical pens, brushes, and so on. The remaining items in the Windows 98 local heap are all less than 10 – 20 bytes each. 2 System-wide resources, unless otherwise noted. |
||
Many users have wondered whether Windows 98 contains MS-DOS code and, if so, whether that means that Windows 98 is somehow built on top of MS-DOS. Many of these questions relate to how Windows 98 achieves the highest possible degree of compatibility with existing devices and applications created for MS-DOS and Windows 3.x. Three key questions are answered here:
The following services were written for Windows 95 and Windows 98, and are not revisions to MS-DOS code:
Some functions, however, are handled by MS-DOS code, although the code itself is running in virtual 8086 mode, not real mode. Functions implemented in this manner ensure backward compatibility with existing real-mode software, such as the Novell NetWare client. The following list shows such functions:
| Create Program Segment Prefix (function 55h) Create Temp File (function 5Ah) Dup File Handle (function 45h) Exit (function 4Ch) Get Date/Time (functions 2Ah and 2Ch) |
Get MS-DOS Version (function 30h) International (function 65h) Set/Get Drive (functions 0Eh and 19h) Set/Get Program Segment Prefix (functions 50h and 51h) NetWare Get Station Num (function DCh) |
An important example of how Windows 98 reclaims memory from real-mode device drivers is MSCDEX, the CD-ROM driver. After Windows 98 Setup is completed and Windows 98 starts from the hard disk for the first time, special code runs to determine whether the protected-mode compact disc file system (CDFS) drivers have taken over the CD-ROM drive completely. If so, the real-mode MSCDEX driver in memory is matched to the related lines in Autoexec.bat, and the MSCDEX entries are then commented out. This provides a trail in Autoexec.bat to show what has happened. Similar methods are used for other device drivers that Windows 98 knows to be safe to remove, such as other vendors’ real-mode disk cache utilities and redundant protected-mode virtual device drivers (VxDs).
As a final example, some users have wondered whether the fact that Io.sys loads Win.com (rather than loading Vmm32.vxd directly) is an indication that Windows 98 is built on Windows 3.x code, with the addition of new VxDs. Actually, Io.sys is used to load Win.com only to ensure backward compatibility. Certain real-mode drivers and terminate-and-stay-resident (TSR) programs insert themselves at various places in the Windows 3.1 startup process. If Windows 98 were to bypass the loading of Win.com and instead load VxDs directly, any driver that needs to insert itself when Win.com is loaded would never be called. Instead, Windows 98 starts in precisely the same way as Windows 3.1 and loads the same components in the same order, ensuring compatibility with earlier versions of applications and device drivers.