Role of VMM32.VXD in Windows 98 Memory Management

In Microsoft Windows 98, VMM32.VXD served as the core container and entry point for the Virtual Machine Manager (VMM), orchestrating memory management, process isolation, and protected-mode operations. It was responsible for establishing the 32-bit flat memory model, supervising x86 hardware paging, and allocating virtual memory ranges across the operating system's hybrid architecture. By bundling the primary kernel memory routines with essential device drivers, VMM32.VXD functioned as the backbone for managing both physical RAM and the system paging file.

Monolithic Architecture of VMM32.VXD

Rather than being a single, isolated device driver, VMM32.VXD was an aggregate archive generated during Windows setup. It combined the core Virtual Machine Manager (VMM.VXD) with critical Virtual Device Drivers (VxDs), including PAGESWAP and PAGEFILE. Consolidating these drivers into a single binary allowed the operating system to transition smoothly from 16-bit real mode (MS-DOS) into 32-bit protected mode during boot, immediately establishing memory control before loading other modular drivers.

4 GB Virtual Address Space Management

VMM32.VXD utilized the protected mode features of x86 processors to create a 4-gigabyte (GB) linear virtual address space for the entire system, partitioned into specific operational regions:

  • 0 MB to 4 MB: Reserved for MS-DOS compatibility and real-mode interrupt vector tables.
  • 4 MB to 2 GB: The private user space. VMM32.VXD isolated each 32-bit Win32 process here, ensuring that an application could not overwrite the memory of another program.
  • 2 GB to 3 GB: Shared memory space accessible by all processes. This area contained shared system DLLs, 16-bit Windows applications running in a shared address space, and core user-interface components.
  • 3 GB to 4 GB: The privileged Ring 0 system area. VMM32.VXD itself resided here, alongside kernel-level device drivers and low-level subsystem code, shielded from user-mode tampering.

Demand Paging and Physical RAM Control

The memory manager inside VMM32.VXD implemented demand-paged virtual memory using the hardware paging mechanism of the CPU (via the CR3 register and page directory tables). Memory was divided into fixed 4-kilobyte (KB) pages.

When a running application requested more physical RAM than was physically installed, VMM32.VXD invoked its paging services to transfer idle pages out of physical RAM and into the dynamic swap file (WIN386.SWP). If a thread referenced an address currently stored on the disk, VMM32.VXD trapped the resulting page fault, retrieved the requested 4 KB block back into physical memory, updated the page table entry, and resumed execution without application interruption.

Memory Allocation Services

VMM32.VXD exposed Ring 0 services that other VxDs and system components used to manipulate memory states. These services allowed the operating system to differentiate between reserving address space and actually committing physical memory:

  • PageReserve: Reserved ranges of virtual address space without consuming physical RAM or page-file space.
  • PageCommit: Mapped reserved virtual addresses to physical memory or disk-backed pages.
  • PageDecommit and PageFree: Released physical backing or destroyed virtual reservations when memory was discarded.
  • PageLock: Locked specific memory pages into physical RAM to prevent them from being swapped out during time-critical hardware operations or Direct Memory Access (DMA) transfers.

Through these functions, VMM32.VXD acted as the foundational memory arbiter in Windows 98, abstracting physical hardware constraints to provide a modern, stable, 32-bit memory environment for applications while maintaining backwards compatibility with legacy DOS and Win16 software.