Memory Managers for Windows 3.11: HIMEM and EMM386

To run Microsoft Windows 3.11 effectively, the essential memory manager required alongside HIMEM.SYS was EMM386.EXE. While HIMEM.SYS provided access to extended memory (XMS) above the 1 MB barrier, EMM386.EXE converted unused portions of the upper memory area into Upper Memory Blocks (UMBs) and provided Expanded Memory (EMS) emulation. Utilizing both managers in tandem was the standard practice for freeing critical conventional memory beneath the 640 KB barrier, ensuring that Windows 3.11, background drivers, and DOS-based software could run concurrently without out-of-memory errors.

The Baseline: What HIMEM.SYS Provided

HIMEM.SYS was the core extended memory manager for MS-DOS and Windows 3.x. Without it, Windows 3.11 could not start in 386 Enhanced Mode.

Its primary duties included:

  • Enabling access to extended memory (RAM above 1,024 KB).
  • Managing the High Memory Area (HMA), a specific 64 KB block of memory just above the 1 MB mark (1024 KB to 1088 KB).
  • Allowing MS-DOS itself to load into the HMA via the DOS=HIGH directive, which freed up roughly 50 KB of conventional memory.

Why EMM386.EXE Was Essential for Effective Operation

While HIMEM.SYS met the bare minimum technical requirement to launch Windows, the system quickly encountered bottlenecks without EMM386.EXE.

Real-world MS-DOS environments typically loaded multiple drivers and Terminate-and-Stay-Resident (TSR) programs before Windows even started—such as mouse drivers, CD-ROM extensions (MSCDEX), sound card drivers, and network interface cards (NICs). Because DOS applications and Windows virtual machines relied on the lower 640 KB of conventional memory, loading these utilities into conventional RAM severely crippled available resources.

EMM386.EXE resolved this by providing two critical features:

  1. Upper Memory Blocks (UMBs): It mapped physical extended memory into the unused spaces of the Upper Memory Area (the region between 640 KB and 1 MB, historically reserved for video adapters and hardware ROMs). This allowed administrators to use the DEVICEHIGH command in CONFIG.SYS and the LOADHIGH (or LH) command in AUTOEXEC.BAT to shift drivers and TSRs out of conventional memory.
  2. Expanded Memory (EMS) Emulation: Many older DOS-based business and gaming applications required Expanded Memory Specifications (LIM EMS) rather than Extended Memory (XMS). EMM386.EXE simulated this memory standard using available extended memory.

Standard Configuration

To configure a system running Windows 3.11 for peak efficiency, both memory managers were loaded sequentially in the system's CONFIG.SYS file:

DEVICE=C:\DOS\HIMEM.SYS
DEVICE=C:\DOS\EMM386.EXE NOEMS
DOS=HIGH,UMB

In this setup:

  • HIMEM.SYS loaded first to initialize the extended memory hardware.
  • EMM386.EXE loaded second. Using the NOEMS switch was common when running Windows, as it disabled EMS frame allocation to maximize the available UMB space for loading drivers high, while Windows 3.11's internal memory manager could dynamically allocate EMS memory to DOS boxes if requested.
  • DOS=HIGH,UMB instructed DOS to relocate its core files into the HMA and link the Upper Memory Blocks managed by EMM386.EXE into the main memory allocation chain.

Third-Party Alternatives

Although EMM386.EXE was the official Microsoft utility bundled with MS-DOS 5.0 through 6.22, power users and enterprise environments frequently substituted third-party alternatives. Programs such as Quarterdeck's QEMM-386 and Qualitas's 386MAX performed the same function as EMM386.EXE but with more sophisticated memory-reclaiming algorithms, often yielding significantly more conventional memory for demanding Windows 3.11 installations.