Memory manager

It has been suggested that this article or section be merged into Expanded memory. (Discuss)

This article is about a class of DOS device drivers. For the general concept, see: memory management.

In IBM PC compatible computing, a memory manager was a software system which employed a variety of clever tricks to give applications access to more than 640K of "conventional memory". The best-known examples were Quarterdeck's QEMM product and Microsoft's EMM386.

During the period roughly spanning the mid-1980s through the mid-1990s, PCs were typically limited to 640K of address space for accessing RAM. Software gradually outgrew this constraint as RAM became cheaper. To allow software to use more than 640K, a mechanism called expanded memory appeared. It integrated bank-switching hardware with software support, allowing applications to exploit additional RAM through a window in the address space. The driver servicing the bank-switching hardware was called an Expanded Memory Manager.

Although applications could use expanded memory with relative freedom, many other software components such as drivers and TSRs were still normally constrained to reside within the 640K "conventional memory" area, which soon became a critically scarce resource.

Clever tricks appeared, notably with QRAM and the LOADHI command, which allowed to place device drivers and TSRs in expanded memory. QRAM did not require an 80386 processor.

The biggest break-through came with the Intel 80386 processor, its virtual memory support and virtual 8086 mode. This combination allowed to freely model the address space used by real mode programs and a wide variety of software-only approaches were invented to move as much code as possible out of the 640K area.

Memory managers like QEMM might move the bulk of the code for a driver or TSR into extended memory and replace it with a small fingerhold that was capable of accessing the extended-memory-resident code. They might analyze memory usage to detect drivers that required more RAM during startup than they did subsequently, and recover and reuse the memory that was no longer needed after startup. They might even remap areas of memory normally used for memory-mapped I/O. Many of these tricks involved assumptions about the functioning of drivers and other components. In effect, memory managers might reverse-engineer and modify other vendors' code on the fly. As might be expected, such tricks did not always work. Therefore, memory managers also incorporated very elaborate systems of configurable options, and provisions for recovery should a selected option render the PC unbootable (a frequent occurrence).

Installing and configuring a memory manager might involve hours of experimentation with options, repeatedly rebooting the machine, and testing the results. But conventional memory was so valuable that PC owners felt that such time was well-spent if the result was to free up 30K or 40K of conventional memory space.