Windows 3.11 High Memory Allocation via HIMEM.SYS

Microsoft Windows 3.11 relied on the DOS device driver HIMEM.SYS to break past the real-mode 640 KB conventional memory boundary by managing the High Memory Area (HMA) and Extended Memory (XMS). Running exclusively in 386 Enhanced Mode, Windows 3.11 used HIMEM.SYS as a foundational bootstrap manager to control the CPU's A20 address line, reserve the first 64 KB chunk of extended memory, and coordinate safe memory access before initializing its own protected-mode virtualization core. This article details the mechanics of how HIMEM.SYS exposed the HMA and how Windows 3.11 utilized this allocation to maximize conventional memory for applications.

The High Memory Area and the A20 Gate

The High Memory Area (HMA) refers to the 65,520-byte (nearly 64 KB) block of memory located directly above the 1 MB boundary, spanning addresses 100000h to 10FFEFh. On original 8086 processors, segment-offset arithmetic that exceeded 1 MB wrapped around to physical address 00000h because the CPU only had 20 address lines (A0 through A19). Starting with the Intel 80286, processors featured 24 or more address lines, preventing this wrap-around and allowing addressing beyond 1 MB unless artificially constrained.

To preserve backward compatibility with software relying on the 1 MB wrap-around bug, PC manufacturers implemented the "A20 gate," typically wired through the keyboard controller or a dedicated motherboard chipset pin. HIMEM.SYS served as the standardized driver to control this gate. By toggling the A20 line, HIMEM.SYS allowed software to physically address the HMA in real mode using addresses derived from the segment base FFFFh.

The eXtended Memory Specification (XMS) Rule

Memory allocation via HIMEM.SYS adhered strictly to the eXtended Memory Specification (XMS). Under XMS rules, the HMA could not be fragmented or dynamically partitioned between multiple processes; it was an all-or-nothing allocation. The first requesting process that called XMS Function 01h (Request High Memory Area) received exclusive rights to the entire ~64 KB block until released.

In a standard Windows 3.11 environment, the primary claimant of the HMA was usually MS-DOS itself. When a user included DOS=HIGH in CONFIG.SYS, MS-DOS requested the HMA from HIMEM.SYS during the boot sequence. This relocated the DOS kernel, buffers, and internal tables out of the first 640 KB of conventional memory and into the HMA, preserving vital conventional memory for DOS-based programs running inside Windows.

Windows 3.11 Bootstrap and Protected Mode Handoff

Unlike earlier iterations, Windows 3.11 dropped Standard Mode and ran exclusively in 386 Enhanced Mode. When a user launched Windows by executing WIN.COM, the system loaded the 386 Enhanced Mode kernel (WIN386.EXE). WIN386.EXE could not initialize without an active XMS driver; thus, HIMEM.SYS was a mandatory prerequisite in CONFIG.SYS.

During startup, Windows verified that HIMEM.SYS was present and functioning by querying software interrupt 2Fh (Multiplex Interrupt) with function 4310h to obtain the entry point for the XMS driver. Once established, Windows evaluated the status of the HMA:

  1. If DOS Claimed the HMA: Windows left the DOS structures intact in the HMA. When Windows 3.11 transitioned the CPU into 32-bit protected mode, its Virtual Machine Manager (VMM) mapped the physical HMA into Virtual 8086 Mode (V86) sessions, ensuring that DOS system calls across all virtual machines retained access to the relocated DOS kernel without consuming base memory.
  2. If the HMA Was Unclaimed: If CONFIG.SYS lacked the DOS=HIGH directive, the HMA remained unallocated. In this state, Windows 3.11 could reserve the block for specific Windows system resources or drivers, or leave it exposed through the internal XMS provider so that native Windows components and DOS virtual machines could request it on demand.

Virtualizing the HMA via WIN386

Once fully loaded, WIN386.EXE assumed supervisory control of the CPU’s paging units and memory virtualization. While HIMEM.SYS remained resident to handle global real-mode XMS requests and maintain standard BIOS/hardware handshakes, Windows 3.11 used its own internal driver, *V86MMGR (Virtual 8086 Mode Memory Manager), to virtualize the state of the A20 line for each individual virtual DOS machine (VDM).

Through this handoff, HIMEM.SYS established the hardware-level extended memory map, enabling Windows 3.11 to switch into protected mode, reclaim lower memory, and isolate or share the High Memory Area seamlessly across the operating environment.