Inside Windows 98
Understanding computer memory often proves less than easy, even for experienced computer users. This chapter helps sort out conventional memory, memory addressing, virtual memory, and Windows 98's memory model. The chapter emphasizes virtual memory, owing to its significance in Windows 98 memory management. Finally, the chapter shows you how to organize Windows 98 memory for optimum performance. Many of Windows 98's memory management features are automatic; Windows 98 constantly searches for ways to refine and "groom" itself for performance advantages. After initial setup, therefore, you might not need to concern yourself with memory issues very often. If memory does become an issue, however, you'll find familiarity with the concepts this chapter discusses quite useful.
In this chapter, you examine the following memory concepts:
With a basic understanding of these memory concepts, you should be able to handle most of the memory-related issues that might arise during your use of the Windows 98 operating system. At the very least, you will be able to recognize memory-related problems and have a good start toward solving those problems.
Random-access memory (RAM) refers to the volatile storage area in which your applications, data from those applications, and the operating system are stored during use. All computer programs must load into RAM memory before you can run them. Any active data in applications on which you work, such as text in a word processor document, also resides in RAM.
RAM memory qualifies as volatile because you lose the data in RAM if the power to the computer is interrupted in any way, shape, or form. You can see why you should know what portions of your data and programs you lose if you don't save them to disk before you turn off your computer or experience an unexpected calamity.
The opposite of volatile memory is permanent memory, commonly referred to as storage. Storage refers to areas to which data is written and saved, even when the computer is off--usually a floppy disk or hard drive. Chapter 14, "Disk and File System Overview," discusses storage issues.
A bit constitutes the primary unit of all computer information and memory. A bit is actually an electronic register that is either on or off. (As discussed later, in computer programming lingo, this model of storage is described as binary code--the register is a 1 or 0.)
Bits are grouped together into bytes (eight bits per byte). A byte represents one character of information, such as a letter or a numeral. Bits are organized in a system called binary language. Binary language organizes eight bits (on or off--1 or 0) into a system that represents characters. The 8-bit code 01000001, for example, is conventionally used to represent the character A.
The basic memory size terms further define how memory is organized in large amounts:
All memory is not equal. Computers use different portions of memory in different ways and certain software applications use different areas of memory for different operations. The four main types of memory are conventional memory, extended memory, expanded memory, and virtual memory.
The following four sections cover these types of memory in turn. Understanding these types of memory will help you understand software manufacturer's requirements for memory use. For example, if a program requires a certain amount of free conventional memory, after reading these sections, you will understand how to be sure you have sufficient memory to run the program.
Conventional memory is the first 1,024 KB of memory available on your computer system, divided into two regions: system memory (the first 640 KB) and high memory (between 640 KB and 1,024 KB). MS-DOS programs use conventional memory more often than any other type of program. In fact, many MS-DOS programs require a significant amount of the system memory area (as much as 610 KB) to be free--that is, not used by any other programs--before you can load and run them.
TIP Many programs require certain amounts of conventional memory, so you might get an out of memory error message from a program that purports to require only 500 KB of memory, even though you have 8 MB of RAM in your system. For example, if you have a CD-ROM driver program, a mouse driver, and a sound card driver loaded into memory, then you attempt to run an MS-DOS program (especially games that require 16-bit sound card drivers) that requires a large amount of conventional memory, you might get an out of memory error, even though you have free memory in other memory areas.
Therefore, when you examine new programs, you should consider the total amount of conventional memory the program requires.
MS-DOS programs must also share conventional memory with other programs, such as device drivers, which are small programs that control certain of your system's components (like your sound card or video monitor). Because this region of memory is so small (compared to the total memory in your system), many MS-DOS programs have problems loading all the necessary information into conventional memory.
Extended memory is all memory beyond 1,024 KB. (The maximum amount of extended memory you can have on a Windows 98-configured computer is 4 GB.) Extended memory is accessed linearly, which makes it faster to use than expanded memory. It is not accessed via paging. (Extended memory can't be accessed by the computer more than a few kilobytes at a time. The whole process by which the range of extended memory is accessed freely is called paging.)
Expanded memory refers to memory mapped in the high memory area (HMA) by certain software, called expanded memory manager (EMM) software. Only applications designed to work with an EMM can use this type of memory. Expanded memory is mapped via the EMM pager. The memory pager tracks every page of memory in HMA, so it has a large overhead.
NOTE Expanded memory's popularity has diminished today, owing to the performance penalty you suffer from paging all expanded memory out of the HMA. EMM also gives applications limited amounts of expanded memory at a time, further impeding application performance. Some DOS-based games still require expanded memory to run, but no Windows 98 applications require expanded memory.
Virtual Memory Virtual memory actually involves writing pages of information that normally go into volatile memory onto a hard disk drive, thus emulating RAM memory. Mainframe operating systems have done this for years, but only recently has it become popular on PC operating systems. Virtual memory is limited only by the amount of available hard disk space.
NOTE Windows 98 uses virtual memory extensively. Virtual memory is used by an application via a pager. This pager tracks the amount of RAM used by the computer, and when the need for more memory arises, the pager swaps memory pages (such as blocks of memory) onto disk, thus emulating the existence of more memory. The application is unaware of the type of memory that is being used because the pager handles all the memory operations.
Perhaps one of Windows 98's most exciting features is its memory model--the same model Windows NT uses--called demand-paged virtual memory. It uses 32-bit addresses to access a flat linear address space. Each application, including the Windows 98 operating system, uses pages, which are pieces of this virtual address space.
Demand paging refers to the method by which information (data) moves in units (pages) from physical memory to a disk file, called a paging file. As a given process needs its paging file's information, its information pages back into physical memory, a page at a time.
The memory pager tracks in physical memory all the pages in the virtual address space and maps them to their respective processes. The memory pager acts as a buffer between the application and the computer's memory. Besides increasing speed, the memory pager prevents applications from overwriting each other in memory space. The pager also keeps the different machine processes separate and hides the actual layout of the memory pages in physical memory from the application or process using the memory.
Windows 3.x, a 16-bit operating system, uses a memory structure based on memory segments. Segments, 64 KB in size, reference memory using 16-bit segment addresses and 16-bit offset addresses within the segment. The small size of segments constricts the performance when applications need to access data across many segments.
Using the 32-bit capabilities of 80386 and faster processors, Windows 98 supports a flat, 32-bit, linear memory model. This model supports a 32-bit operating system and 32-bit applications (Win32 apps). Linear addressing greatly increases operating system and application performance by doing away with the segmented memory model. Less instructions and less CPU time are needed to get to a particular piece of memory, which means faster performance.
Linear memory addressing is the process whereby the memory manager creates a seemingly endless stack of memory and renders it available to the applications and operating system. The stack of memory is actually made up of chunks of physical memory (or RAM) and virtual memory (or disk space). It is considered linear because the VMM handles the memory issues and determines whether to use physical or virtual memory and hide this process from the application, so all the application sees is a stack (line) of memory that is available on the system. It's also not quite endless; it's limited by available disk space and physical memory size.
Linear addressing enables Windows 98 to use up to 4 GB of addressable memory space for the entire 32-bit operating system and component combined. Each 32-bit application can access up to 2 GB of addressable memory space!
Virtual memory acts as the heart of the Windows 98 memory management system. Virtual memory is the label for the process of moving information that applications need into and out of physical memory (RAM chips) and the disk cache area, or swap file, to form logical memory. Virtual memory entails using the usually large amount of hard disk space available to handle memory-related functions, thereby enabling more information to be processed, and more complicated processes.
In Windows 98, memory is accessed using a 32-bit linear addressing scheme. A 32-bit addressing system can access up to 4 GB of memory. Thus, in Windows 98 when an application attempts to access memory, it simply specifies a 32-bit memory address. (The minimum allocation of virtual memory is one 4 KB page.)
Virtual memory can include a physical structure or a logical structure, as discussed in the following sections.
Physical memory--your RAM chips or memory modules--is organized as a series of one-byte storage units that make up the machine's physical address space of the machine. Only the amount of RAM on the motherboard limits the number of physical addresses on a machine.
NOTE Physical memory (RAM) resides on your system's memory modules, which consist of one or more computer chips, usually of the single in-line memory module (SIMM) standard. When you purchase extra "memory" for your system, you purchase such modules.
Logical memory is the key to the virtual memory process. It includes both physical
memory and the swap file, or disk-cached memory. In essence,
logical memory simply labels the way in which applications actually use memory. Using
logical memory and the virtual memory process, some of the contents of physical memory
can be moved onto the hard disk in a paging file when memory becomes scarce--when
a process tries, for example, to access more memory than physically available on
your computer system. In other words, when an application tries to use more RAM than
the computer can offer, virtual memory closes the gap.
As a practical matter, the virtual memory capacity available on a computer equals the space that the Virtual Memory Manager can use to store data swapped out to the hard disk. If you have a 1.2 GB hard drive with 200 MB of free hard drive space, you have only 200 MB of possible virtual memory space. Still, those 200 MB can enable you to run applications of a power and dimension that were not available to a DOS or Windows 3.x user.
Windows 98's Virtual Memory Manager (VMM) controls allocating physical and logical memory. When you launch a new application, the Virtual Memory Manager initializes the virtual address space.
Programmers historically have designed applications to use as little memory as possible, given most systems' limited physical memory. Windows 98's VMM can address up to 4 GB, including space on your system's hard drives, however, so now programmers can write programs to exploit large amounts of memory without worrying about the type of memory or the amount of memory available.
Windows 98's Virtual Memory Manager provides this large, virtual memory space to applications via two memory management processes: paging, or moving data between physical RAM and the hard disk, and translating physical memory addresses to virtual memory addresses or mapped file I/O.
When a set of information, for example a file, exceeds in size available RAM, the Virtual Memory Manager uses paging to move data between RAM and the hard disk by dividing all physical memory and virtual memory (the memory applications use) into equal-sized blocks or pages (4 KB each). When a request is made to access data not in RAM, the Virtual Memory Manager swaps a page from RAM with the desired page from the paging file (a file on the hard disk used solely by the Virtual Memory Manager for memory pages).
Page states are registered in the virtual page table. A page both in physical RAM and immediately available to its application is marked as valid. Pages currently already in the paging file are marked as invalid. When an application tries to access an invalid page, the CPU generates a page fault. The Virtual Memory Manager intercepts page faults, retrieves pages from the paging file, and places them into RAM. If RAM doesn't have enough room to store a new page, the VMM moves a valid page out of RAM into the paging file.
When an application accesses a virtual address in a page marked invalid, the processor uses a system trap called a page fault. The virtual memory system locates the required page on disk and loads it into a free page frame in physical memory. When the amount of available page frames runs short, the virtual memory system selects page frames to free and pages their contents out to disk. Paging occurs transparently for the user and the program or application.
Three policies dictate how the Virtual Memory Manager determines how and when to page:
Windows 98 transfers data in 32-bit addresses. Windows 98 divides each 32-bit address into three groups: two groups of 10 bits each, and one group of 12 bits. It uses each group as an offset into a specific page of memory: the first 10 bit groups as an offset into the page directory; the second 10 bits as an offset into the page table; and the third 12 bits to address a specific byte in the page frame.
Every page of memory falls into one of three categories: page directories, page tables, or page frames.
Locking Pages For time-sensitive applications and those with other special memory performance requirements, the VMM enables a user subsystem or process with special privileges to lock selected virtual pages into its working set to ensure that a critical page is not be paged out of memory during the application. Such applications could include games and MIDI applications (which require precise synchronization to both the system clock and to outside devices).
The VMM uses a two-level process for memory allocation: it first reserves the pages and then commits them. Reserved memory is a set of virtual addresses that the VMM reserves for future use. Reserving memory (virtual addresses) is fast in Windows 98. No memory actually is used, but another application asking for a memory allocation cannot use the reserved virtual addresses.
A committed page has physical storage (RAM memory or virtual memory on disk) allocated for its use. When the VMM allocates memory for use by an application, it can reserve and commit memory simultaneously, or it can simply reserve the memory, committing it later when the application needs the memory.
When a particular range of addresses is not being used, the VMM can decommit them, thus freeing space in the paging file.
If an application attempts to load a file larger than both the system RAM and the paging file (swap file) combined, Virtual Memory Manager's mapped file I/O services are used. Mapped file I/O enables the Virtual Memory Manager to map virtual memory addresses to a large file, inform the application that the file is available, and then load only the pieces of the file that the application actually intends to use. Because only portions of the large file are loaded into memory (RAM or page file), this greatly decreases file load time and system resource drainage. It's a very useful service for database applications that often require access to huge files.
The Windows 98 memory management system provides a new, enhanced level of protection for applications running on the system. In Windows 3.x, for example, a 16-bit application gone bad can easily bring down the entire system, and with it all other applications running on the system, potentially causing serious data loss. Likewise, if under Windows 3.x you ran a 16-bit application, then launched an MS-DOS application, the MS-DOS application could actually seek to use the 16-bit application's memory area, thereby bringing about system failure.
In Windows 98, each type of application--16-bit, 32-bit, or MS-DOS--is protected from the other. Although 32-bit based applications benefit the most from system memory protection, the improvements present in Windows 98 result in a more stable and reliable operating environment for all applications than in Windows 3.x. This doesn't mean that it's not possible to "hang" or crash a Windows 98 system. A badly written program, either 16- or 32-bit, can still lock the system up and require a hard reset. Windows 98 does feature more safeguards against this sort of thing happening casually or for no real reason.
16-bit-based applications run within a unified address space, and cooperatively multitask as they do under Windows 3.x. The improvements in overall system-wide robustness, owing to better system memory management support underneath the application, greatly enhance the system's capability to recover from a hung application and reduce the likelihood for application errors.
The Windows 98 memory system also helps segregate applications from other applications and from their own memory segments. General protection faults (GPFs) in Windows 3.x usually result from applications attempting to write over their own memory segments, instead of from applications overwriting memory belonging to another application. Windows 3.x does not recover gracefully when an application crashes or hangs. When a GPF halts an application in 3.x, the user must restart the system by rebooting the computer, and loses any unsaved work prior to the GPF.
Due to improved protection in Windows 98, a rebellious 16-bit-based application cannot easily bring down the system as a whole, nor can it bring down other MS-DOS applications or 32-bit applications. However, crashing 16-bit applications still can affect other running 16-bit based applications. Each type of application--16-bit, 32-bit, or DOS--has a corresponding Virtual Machine Manager. If a 16-bit application locks up for some reason, it can stop the whole 16-bit process; all 16-bit applications are stopped from working because the 16-bit Virtual Machine Manager is locked up. Sometimes this requires a reboot, especially if the system uses drivers that require 16-bit access.
Protection improvements also include the use of separate message queues for each running 32-bit application. The use of a separate message queue for the 16-bit address space and for each running 32-bit application provides for better recovery of the system as a whole and doesn't halt the system should a 16-bit application hang.
Windows 98 has another key memory-management improvement over Windows 95, which is designed to work in conjunction with FAT32 and programs compiled specifically for Windows 98.
When a user runs a program in Windows 95, the operating system makes two copies of the program: one in the disk cache, and another in the area of memory staked out to run the program. When the program is copied from the cache to active memory, it does so in 4 KB blocks. The reason for the 4 KB blocks is because a 4 KB block is the minimum amount of memory that the virtual-memory manager can address at once. This creates a kind of redundancy: two copies of the program are, for all intents and purposes, in memory at once.
Windows 98 has a more efficient way of making use of the disk cache where programs are involved. If a program is already pre-aligned into 4 KB boundaries, which must be done when it is compiled, then Windows 98 can run the program directly from the cache, which saves both CPU time and memory, since it doesn't have to perform a copy operation.
Most programs shipped today come aligned on 4 KB boundaries, but Microsoft also has a utility called WinAlign (WALIGN.EXE, in \WINDOWS\ SYSTEM) that can take an existing program and realign it on 4 KB boundaries. Keep in mind that some programs will experience compatibility problems if you do this--make a backup copy in case the aligned version doesn't run.
How does FAT32 play a part in this? The 4 KB cluster size in FAT32 matches the boundary alignments perfectly, so there is less chance that unneeded information from a given cluster will be read. This happens often in FAT16 drives, where 16 KB or 32 KB clusters cause a great deal of unneeded information to be read from the disk. Therefore, using FAT32 adds even more performance gains for 4 KB-aligned software.
In implementing the virtual memory process, Windows 98 creates a hard disk swap file to which it writes information that will not fit into physical (RAM) memory. Windows 98 contains several improvements to the virtual memory swap file implementation provided in Windows 3.x. These improvements have corrected some problems and removed some limitations present in the previous systems.
In the earlier versions of Windows, you face many complex choices and configuration options when arranging a swap file. You must decide whether to use a temporary swap file or a permanent swap file, how big to make the swap file, whether to use 32-bit disk access, and with version 3.11, whether to use 32-bit file access. Users benefit from a temporary swap file in that the swap file does not need to be contiguous, and Windows allocates space on the hard disk during bootup and frees up the space when you close out Windows--but this also makes starting Windows slower. A permanent swap file provides the best performance, but it demands a large amount of disk space that will not be freed up when you exit Windows.
Windows 98's swap file simplifies configuration by combining the best features of the Windows 3.x temporary and permanent swap files in improved virtual memory algorithms and access methods. Windows 98's swap file is dynamic, and can shrink or grow, based on the operations performed on the system. (The Windows 98 swap file still has to be "created" during system startup if it doesn't already exist, slowing startup time.)
You still can adjust the parameters for defining the swap file in Windows 98. The intelligent use of system defaults, however, reduces your need to do so. Generally configuring Windows so that you prevent it from automatically managing the size of the swap file provides no benefits.
Figure 13.1 shows the new, simplified swap-file configuration options, which enable
the user to specify the minimum and maximum swap file size to use.
FIGURE 13.1 The new
swap file configuration window enables you to allocate how much disk space is to
be used for the swap file or allows the user to leave the exact amount to be decided
by Windows 98.
Note that turning off the swap file completely can degrade performance.
WARNING Disabling virtual memory completely is not recommended. Doing so can cause the system to lock and also can prevent the computer from rebooting properly. In addition, overall system performance decreases dramatically.
If you have multiple hard drives, you might want to change the location of the swap file to the fastest hard drive, or, if all drives are the same speed, you probably want to use the drive that contains the most free space. Be careful not to change the location of the swap file to a network drive. Access to network drives can be very slow, and using one for the host of your virtual memory file can adversely affect system performance.
You probably have seen Out of Memory error messages while running multiple Windows-based applications under Windows 3.x, even though the system still reported several megabytes of available free memory when you consulted the Help About dialog box. What you encountered, although you probably didn't know it, was a condition in which the system could not allocate an internal memory resource in a Windows API function call because it didn't have enough space available in the memory heap.
Windows 3.x maintains heaps for system components called GDI and USER. Each heap is 64 KB in size and is used for storing GDI or memory object information allocated when an application calls a Windows API. The GDI (Graphic Device Interface) space is used to describe and "tag" objects like windows, dialog boxes, icons, and so on. USER space is used to control input and output for device drivers, such as the keyboard, video card, and printer. Both USER and GDI only have a finite amount of memory assigned to them, but Windows 98 has more and better USER and GDI memory allocation than either Windows 3.x or Windows 95.
TIP The amount of space available in the combination of these two heaps is identified as a percentage of system resources that are free, and are shown in the Windows 3.x Help About dialog box. In Windows 95 and 98, that information has been left out.
The amount of space available in the combination of these two heaps is identified as a percentage of system resources that are free, and are shown in the Windows 3.x Help About dialog box.
The percentage of free system resources reported in the Help About dialog box actually is the aggregate percentage of free memory in the GDI and USER heaps. When the free system resources percentage drops to a low number, it normally produces an out of memory error message, even though the amount of free memory shown in the Help About dialog box still is quite high. This error results from low memory in the GDI heap or the USER heap.
To help reduce this system resource limitation, a number of the data structures stored in the 16-bit GDI and USER heaps in Windows 3.x have been moved out and stored in 32-bit heaps in Windows 98, leaving more room for the remaining data elements to be created. You will notice this mostly from the fact that you do not encounter such a rapid decrease in system resources as you did with Windows 3.x.
Windows 98 improves the system capacity for the USER heap by moving menu and window handles to the 32-bit USER heap. Windows 98 also raises the total limit of these data structures from 200 in Windows 3.x to 32,767 menu handles and an additional 32,767 window handles per memory process (instead of 32,767 handles for the whole of the system).
The improvements in Windows 98 that facilitate cleaning up the system of unfreed resources also help the system resource limitation problem. Windows 98 cleans up and deallocates leftover data structures after it determines that the other processes no longer need the resources in memory. This minimizes the problem of "memory leaks" due to poorly-written programs, although it does not eliminate it completely. There is still a burden on the programmer, as there should be, to write code that manages memory as efficiently as possible.
Windows 95 and Windows 98 do not have any differences in terms of how USER or GDI resources are allocated, but they are significantly different in how they manage memory in general, as described above in the section entitled "Memory Alignment."
Even though Windows 98 handles memory much more efficiently than its predecessor systems, you might still need to enhance your system's performance. If so, you can use some of the following performance suggestions.
TIP Enhancing the performance of the Windows 98 operating system is easier than in Windows 3.x. Many of the following performance suggestions are more effectual because of Windows 98's "self-tuning" nature.
WARNING The Pentium II and Pentium Pro processors are designed to exploit 32-bit addressing and performance. Many users who use Windows 95 with the Pro (and occasionally the II, depending on the application in question) have reported that some games or 16-bit based applications do not perform reliably, or perform erratically, on these processors. Because the Pro is generally designed to be used in servers, it's unlikely that a Windows 98 machine would come shipped with it, but it is good to be conscious of these issues when deploying Windows 98 on a new machine.
Windows 98 is designed to monitor itself and perform certain actions to fine-tune itself. Windows 98 does several things automatically to enhance system performance, including the following three more noticeable ones:
In addition to these features, Windows 98 includes a handy utility called the
Memory Troubleshooter (see Figure 13.2), actually a Windows 98 wizard you can find
in the Help system. As do most Windows 98 wizards, the Memory Troubleshooter guides
you through a series of steps--in this case, steps that help you diagnose a variety
of memory problems. (Some of these steps include shortcuts to other Windows 98 utilities,
such as ScanDisk.)
FIGURE 13.2 The Memory Troubleshooter
asks a series of questions to help determine the cause of a given memory-related
problem
To activate the Memory Troubleshooter, click on the Start button and select Help.
In the Help index, look up the entry "memory, problems with, troubleshooting."
The Memory Troubleshooter will start in the right-hand panel of the Windows Help
browser.
When first activated, the Memory Troubleshooter asks the user about the nature of the memory problem--blue screen crashes, inaccurate memory size reportage, or Out of Memory errors. By further narrowing down the symptoms with additional questions, the Memory Troubleshooter eventually produces a list of possible reasons for the problem, and a list of instructions to follow which might alleviate the problem. If the recommended action doesn't solve the problem, then the user can elect to try another set of possible fixes.
Windows 98 helps provide the maximum conventional memory available for running your existing MS-DOS-based applications. Some MS-DOS-based applications will not run under Windows 3.x because after all the MS-DOS device drivers, TSRs, MS-DOS-based networking components, and the Windows 3.x operating system were loaded, not enough conventional memory was available to load and run the software.
To help alleviate these problems, Windows 98 provides 32-bit protected-mode components that replace many of the 16-bit real-mode counterparts. These 32-bit protected-mode components, called virtual device drivers, provide the same functionality while improving overall system performance by using no conventional memory.
Table 13.1 provides a partial list of 16-bit real-mode device drivers that are replaced by 32-bit virtual device drivers in Windows 98, including the approximate file sizes. TABLE 13.1
Description File(s) Memory Saved Microsoft Network client software NET.EXE 95 KB
Novell NetWare client software Various 155 KB
MS-DOS extended file sharing SHARE.EXE 17 KB
Adaptec SCSI driver ASPI4DOS.SYS 5 KB
Adaptec CD-ROM driver ASPICD.SYS 11 KB
Microsoft CD-ROM Extensions MSCDEX.EXE 39 KB
SmartDrive disk caching software SMARTDRV.EXE 28 KB Microsoft Mouse driver MOUSE.COM 17 KB As Table 13.1 shows, you can save a significant amount of memory by using 32-bit protected-mode components.
Some MS-DOS-based applications don't run properly under Windows 3.x. Some MS-DOS applications, for example, require lots of available free conventional memory, and thus won't run in a DOS virtual machine (VM), owing to large real-mode components such as network drivers or device drivers. Other MS-DOS-based applications will not run under Windows 3.x because they require direct access to the computer hardware and conflict with Windows' own device drivers.
One goal in Windows 98 is to provide better support for MS-DOS-based applications. In doing so, the designers have attempted to provide support for not only "clean" MS-DOS-based applications (those that run well under Windows 3.x) but also those "bad" MS-DOS-based applications that try to take over the hardware or require machine resources unavailable under Windows 3.x.
Many graphics-oriented MS-DOS-based games assume that they are the only application running in the system, and, therefore, they attempt to directly access and manipulate the underlying hardware. As a result, they do not run well, if at all, in an MS-DOS VM under Windows 3.x. In fact, games are the most notorious class of MS-DOS-based applications that do not get along well with Windows 3.x. Some of these applications write to video memory directly, manipulate the hardware support resources, such as clock timers, and take over hardware resources, such as sound cards.
Windows 98 provides better support for running MS-DOS-based applications that interact with the hardware, including better virtualization of computer resources, such as timers and sound device support. In addition, 32-bit protected-mode device drivers benefit MS-DOS-based applications by providing more free conventional memory than is available under Windows 3.x, enabling a class of memory-intensive applications to run properly.
Different MS-DOS-based applications require varying levels of support from both the computer hardware and from the operating system. Some MS-DOS-based games require close to 100 percent use of the CPU to perform properly, for example, and other MS-DOS-based applications modify interrupt addresses and other low-level hardware settings. Windows 98 provides several different levels of support for running these MS-DOS-based applications. These levels of support take into account that different applications interact with the hardware in different ways.
By default, MS-DOS-based applications are preemptively multitasked with other tasks running on the system, and can run full-screen or in a window. Generally, MS-DOS applications that attempt to use graphics hardware directly should be run full-screen for the best speed, best compatibility, and best pointer behavior.
To provide support for the most intrusive set of MS-DOS-based applications that work only under MS-DOS and require 100 percent access to the system components and system resources, Windows 98 provides a mechanism equiv-alent to running an MS-DOS-based application from real-mode MS-DOS, called single MS-DOS application mode. Although fewer MS-DOS-based applications need to run in this mode because of improved compatibility support, this mode provides an escape-hatch mechanism for running applications that run only under MS-DOS.
To run an MS-DOS-based application in this mode, you can set the Single MS-DOS
Application Mode property from the Program page on the MS-DOS property sheet for
the application. In this mode, Windows 98 removes itself from memory (except for
a small stub) and provides the MS-DOS-based application with full access to all the
resources in the computer. Before you run an MS-DOS-based application in this mode,
Windows 98 prompts you to tell it whether it can end other running tasks. Upon your
approval, Windows 98 ends all running tasks, loads a real-mode copy of MS-DOS, and
launches the specified application--kind of like exiting Windows 3.x and running
the specified MS-DOS-based application under MS-DOS. After you exit the MS-DOS-based
application, Windows 98 restarts and returns the screen to the Windows 98 desktop.
There are many advantages to this methodology. By removing most of the Windows
98 components from memory, the vast majority of the machine is made available for
the program in question. Also, the CPU overhead previously used by Windows 98 is
returned to the program itself. Lastly, the program has more direct access to hardware.
There are some drawbacks to this scheme. Multimedia hardware, for instance, generally
has to rely on 16-bit real-mode drivers to operate; 32-bit protected-mode Windows
98 drivers for sound cards, video accelerators, and so forth, can't be used in Single
MS-DOS Application mode. These have to be provided in the shortcut that activates
Single MS-DOS Application Mode for the stated program.
To support a higher level of memory protection for running MS-DOS-based applications,
Windows 98 also includes a global memory protection attribute on the Program property
page that protects the MS-DOS system area from "rogue" MS-DOS-based applications.
When the global memory protection attribute is set, the MS-DOS system area sections
are write-
protected so that applications can't write data into this memory area and corrupt
MS-DOS support and MS-DOS-based device drivers.
In addition to the system area protection, Windows 98 performs enhanced parameter validation for file I/O requests issued through the MS-DOS INT 21h function, providing a higher degree of safety.
This option is not enabled by default for all MS-DOS-based applications due to the additional overhead associated with providing improved parameter and memory address checking. You need to set this flag manually if you constantly encounter difficulty running a specific MS-DOS-based application.
A 32-bit Windows application generally requires more virtual memory than the original 16-bit Windows application. However, the 32-bit version of the application can have a smaller working set. (Recall from the section on virtual memory paging that the working set is the certain number of pages that the Virtual Memory Manager must keep in memory for a process to execute efficiently.) The lower the working set of an application, the fewer pages of virtual memory are needed and the less RAM is used.
Sometimes it might seem that the 32-bit version of an application running on Windows 98 requires more RAM than the 16-bit version of the same application running on the same computer system. This is because segments of a 16-bit application are loaded only as they are referenced or needed, whereas the address space is reserved for the 32-bit application and all its dynamic link libraries when the program is initially loaded.
This is why the memory count that appears in the Help About dialog box can be misleading. The free memory reported for 16-bit applications is reduced only by the number of segments actually loaded in memory, not the total number of segments. On the other hand, the free memory reported for 32-bit applications is reduced by the total address space required for the application--that is, the total amount that the VMM reserves for the application upon initial program load. However, this free memory represents only the virtual address space that all applications share, not the amount of RAM actually used.
© Copyright, Macmillan Publishing. All rights reserved.
){kind=link}
){kind=link}