How Windows 95 Handled HMA for Legacy MS-DOS

Windows 95 streamlined how legacy MS-DOS utilities accessed the High Memory Area (HMA) by integrating extended memory management directly into the operating system's boot process and virtualizing memory allocation for legacy applications. Instead of relying on manual configuration via separate drivers, Windows 95 automatically managed the A20 gate, preloaded the MS-DOS kernel into the HMA by default, and used its 32-bit Virtual Machine Manager to coordinate HMA access across multitasking DOS environments and dedicated real-mode sessions.

Automated Boot Integration

In standalone MS-DOS, loading drivers into the HMA—the first 64 KB of extended memory above the 1 MB boundary—required explicitly loading HIMEM.SYS and declaring DOS=HIGH inside CONFIG.SYS.

Windows 95 eliminated this requirement by consolidating the real-mode startup sequence into a unified IO.SYS file. During boot, IO.SYS automatically initialized the XMS (Extended Memory Specification) driver and enabled the A20 line without requiring an external HIMEM.SYS entry. The system applied DOS=HIGH by default, automatically placing core MS-DOS data structures, buffers, and code segments into the HMA. This freed up vital conventional memory (the first 640 KB) for legacy applications before the graphical user interface even loaded.

Virtualization via V86MMGR

When running legacy utilities inside the Windows 95 graphical interface via an MS-DOS prompt, the operating system ran each application inside a Virtual 86 (V86) mode container. Real-mode hardware limitations dictate that only one program can occupy the physical HMA at any given time.

To resolve this conflict, Windows 95 relied on the 32-bit Virtual Machine Manager (VMM32.VXD) and the virtual memory manager driver (V86MMGR.VXD). When an MS-DOS utility made an XMS call to request or release the HMA, V86MMGR intercepted the request:

• If the global real-mode MS-DOS kernel had already claimed the physical HMA during boot, the virtual machine manager reported to the application that the HMA was in use.
• The system virtualized the A20 line on a per-VM basis, allowing legacy programs to toggle A20 state masking without causing system-wide memory faults or crashing other running tasks.

Program Information Files (PIF) Controls

Windows 95 allowed users to fine-tune how individual DOS utilities interacted with memory using Program Information Files (.PIF). Through the properties sheet of any DOS executable:

• Users could explicitly allocate specific amounts of expanded (EMS) or extended (XMS) memory.
• The system exposed an option to prevent an application from detecting Windows, altering how the memory manager reported HMA availability to bypass legacy compatibility checks.

Exclusive Access via MS-DOS Mode

Certain legacy disk utilities, games, and hardware diagnostics required direct, unvirtualized access to the physical HMA and real-mode interrupt tables. For these programs, Windows 95 offered "MS-DOS Mode."

When an application was configured for MS-DOS Mode, Windows 95 completely unloaded the 32-bit protected-mode kernel, GUI, and virtual device drivers (VxDs). The system then rebooted the machine into a pure 16-bit real-mode environment, parsing custom CONFIG.SYS and AUTOEXEC.BAT directives tailored specifically to that utility. In this state, memory management fell back entirely to physical real-mode rules, giving the legacy software exclusive, hardware-level control over the physical HMA until the user exited the utility and the machine rebooted back into the 32-bit Windows environment.