Multitasking without memory management is like having a party in a closet: You may be able to accommodate some of the earlier arrivals, but once everybody starts mingling, some toes are going to get smashed.
Memory management has always been one of the most remarkable aspects of Windows. Even Windows 1 included a sophisticated memory management scheme that implemented in software some of the memory management features you might expect to find in a protected-mode operating system. Here are some examples of Windows 1 memory management:
When Windows runs multiple instances of the same program, it uses the same code segments and the same resources for each instance. (Resources include icons, cursors, menu templates, and dialog box templates, all of which are covered in the next three chapters.) In most cases, Windows requires only that data segments be unique for each instance of a program.
Much of the memory allocated within Windows is moveable, including (in most cases) the memory allocated for a program's code segments, data segments, and resources.
Code segments and resources are often ”demand-loaded“: Windows does not load them into memory until a program specifically needs them.
Code segments and resources are often discardable: When Windows needs to free some memory, it discards the segments from memory and later reloads them from the program's .EXE file as the program requires.
These memory management features allowed Windows 1 to run several large programs in a memory space that might not be large enough for even one of the programs under a less ambitious memory management scheme. The problem is that this memory management scheme requires that Windows often reload code segments and resources from the hard disk, hurting program performance. For this reason, support of the Expanded Memory Specification (EMS) 4.0 was added to Windows 2, and protected-mode support was added to Windows 3.
Windows 3 can run in three distinct modes:
On a machine based around the Intel 8086 processor (or an 80286 or 80386 processor with less than 1 MB of memory), Windows 3 runs in ”real mode.“ This is essentially compatible with the memory configuration of Windows 2.1. Windows and its applications occupy an upper area of the 640 KB of conventional memory above MS-DOS and any device drivers and RAM-resident programs that may be loaded.
In this mode, Windows can take advantage of any expanded memory under the Lotus-Intel-Microsoft Expanded Memory Specification 4.0 (LIM EMS 4.0). This configuration requires an EMS memory board and an EMS 4 device driver.
On a machine based around the Intel 80286 processor with at least 1 MB of memory (or an 80386 processor with less than 2 MB of memory), Windows 3 runs in ”standard mode.“ This is 286-compatible protected mode. Windows can use up to 16 MB of conventional memory and extended memory.
On a machine based around the Intel 80386 processor with at least 2 MB of memory, Windows 3 runs in ”386 enhanced mode.“ This is essentially standard mode with two additional features: Windows uses the paging registers of the 386 processor to implement virtual memory. The 386 pages are 4 KB in length. Windows can swap pages to disk and reload them when necessary. (This is the only form of virtual memory supported for Windows applications.) The page swapping is something you normally don't have to think about when coding for Windows. The second feature of 386 enhanced mode uses the Virtual-86 mode of the 386 processor to support multiple virtual DOS machines. This does not impact Windows programming.
You can override the default configuration by running Windows from the command line with a /R (real mode), /2 (standard mode), or /3 (386 enhanced mode) parameter. A Windows program can obtain information about the mode in which it is running by calling GetWinFlags.
Much of this chapter discusses the real mode memory configuration because this is the least common denominator of all the modes in which Windows can run. (Another reason for this is that the techniques Windows uses to manage memory in real mode are quite interesting!) If you initially feel a little queasy when thinking about Windows moving your program around in memory in real mode, that's good. It means that you're already aware that this is not an easy feat. You must keep this fact in mind in order to write programs that run without problems. You must cooperate with Windows' memory management. That's what we'll look at in this chapter.