Windows 3.11 DOS Memory Allocation Explained

Microsoft Windows 3.11 managed memory for concurrent DOS sessions by leveraging the Intel 80386 processor's 386 Enhanced Mode to run each command prompt or DOS application inside an isolated Virtual Machine (VM). Through the Virtual Machine Manager (WIN386.EXE) and hardware-level paging, the operating system virtualized the classic 1 MB real-mode address space for every session. This setup granted each DOS session its own private conventional memory while dynamically doling out extended (XMS) and expanded (EMS) memory without causing conflicts between concurrent programs.

The Virtual 8086 Mode and Virtual Machines

The foundation of running multiple DOS sessions concurrently was the Intel 80386 processor's Virtual 8086 (V86) mode. Windows 3.11 established a single "System VM" to house the Windows graphical environment (including Program Manager, the GDI, and standard 16-bit Windows applications), while spawning a separate, distinct VM for every initiated DOS session.

Inside a V86 virtual machine, the processor mimics an 8086 environment with an 8086-style segmented memory model (1 MB limit). The DOS application acts as if it has exclusive control over the CPU and the full 640 KB of conventional memory, while WIN386.EXE supervises execution from 32-bit protected mode.

Paging and Conventional Memory Virtualization

Windows 3.11 used the 80386 CPU's memory management unit (MMU) and 4 KB hardware paging to decouple physical RAM from the virtual addresses seen by DOS applications.

When a DOS session referenced an address within its virtual 1 MB boundary (such as 0x00000 to 0x9FFFF for the standard 640 KB base), the processor's page tables translated that virtual address to an arbitrary physical page in RAM. When the user switched between DOS tasks, Windows swapped the active page directory base register (CR3), mapping the active session's private memory into the foreground while preserving background sessions in their own assigned physical pages or paging them out to the hard disk swap file if physical RAM ran low.

Extended (XMS) and Expanded (EMS) Emulation

Real-mode DOS required specific drivers like HIMEM.SYS for extended memory or expanded memory boards (and software like EMM386.EXE) for expanded memory. In Windows 3.11, memory management for these subsystems was integrated directly into the 32-bit core:

  • XMS (Extended Memory): Windows 3.11 acted as a central XMS server. DOS sessions requiring extended memory communicated with virtual device drivers (VxDs) that allocated memory pools from 32-bit extended memory, governed by the limits defined for that session.
  • EMS (Expanded Memory): Windows natively emulated the LIM EMS 4.0 specification. It reserved a 64 KB page frame in the Upper Memory Area (UMA—the region between 640 KB and 1 MB) within each VM. Through hardware paging, WIN386.EXE rapidly remapped physical 4 KB pages into this 64 KB window on demand, giving DOS programs access to multi-megabyte expanded memory without requiring specialized expanded memory hardware.

Instance Data and Global Memory

Running concurrent DOS sessions required a strategy for handling DOS structures loaded prior to launching Windows. Drivers and TSRs (Terminate and Stay Ready programs) loaded in CONFIG.SYS or AUTOEXEC.BAT occupied memory that preceded Windows initialization:

  • Global Data: Read-only code and shared device drivers (such as mouse drivers or CD-ROM extensions) remained global, occupying the same physical and virtual addresses across all VMs to conserve RAM.
  • Instance Data: Certain variables within the shared DOS kernel—such as current disk directories, drive tables, keyboard buffers, and swappable DOS internal data structures—had to be private to each session. Windows marked these specific memory segments as "instance data." When the CPU performed a context switch between DOS sessions, the Virtual Machine Manager automatically swapped the contents of these specific memory blocks so that one session's file I/O or state did not overwrite another's.

Program Information Files (PIFs)

Memory allocation per session was explicitly controlled using Program Information Files (.PIF). Through the PIF Editor, users defined exact memory allocations for each DOS executable:

  • KB Required: The absolute minimum conventional memory required to launch the session.
  • KB Desired: The maximum conventional memory granted to the program (up to 640 KB).
  • EMS / XMS Memory Limits: Explicit caps (specified in kilobytes) indicating how much expanded or extended memory the session could allocate from the system pool. Setting these limits prevented a single misbehaved or greedy DOS program from exhausting the system's global physical RAM and swap space.