How Windows 98 Managed Virtual DOS Machines

Windows 98 managed legacy applications through Virtual DOS Machines (VDMs), which used the Intel processor's Virtual 8086 mode combined with 32-bit Virtual Device Drivers (VxDs) to emulate an isolated MS-DOS environment. Orchestrated by the Virtual Machine Manager (VMM32), this architecture allowed users to run 16-bit real-mode software alongside modern 32-bit Windows programs without sacrificing system stability or preemptive multitasking.

Hardware Virtualization via Virtual 8086 Mode

At the core of the Windows 98 VDM was the Intel 80386 (and newer) processor's hardware feature known as Virtual 8086 mode (V86 mode). While Windows 98 operated in 32-bit protected mode, launching an MS-DOS program triggered the CPU to spawn a V86 execution context.

Inside this context, the processor simulated the real-mode segmented memory architecture (the standard 1 MB address space, including 640 KB of conventional memory). To the DOS program, it appeared as if it were the sole software running on a dedicated 8086/8088 CPU, while the host operating system maintained supervisor-level control over hardware interrupts and physical memory.

The Virtual Machine Manager and VxDs

The subsystem responsible for handling these environments was VMM32 (Virtual Machine Manager). Instead of letting DOS programs directly manipulate physical peripherals, VMM32 routed hardware calls through Virtual Device Drivers (VxDs).

Key VxD components included:

  • VKD (Virtual Keyboard Device): Virtualized keystrokes and keyboard buffer management.
  • VDD (Virtual Display Device): Managed screen output, allowing DOS programs to run either inside an emulation window on the desktop or in exclusive full-screen mode.
  • VPICD (Virtual Programmable Interrupt Controller Device): Handled hardware IRQs, arbitrating interrupt requests between DOS tasks and 32-bit Windows processes.
  • VTD (Virtual Timer Device): Emulated the PC timer to satisfy timing loops common in DOS applications.

When a DOS program attempted a direct I/O port instruction (such as IN or OUT) or an interrupt (INT), the processor trapped the action and handed control to the appropriate VxD. The VxD either emulated the hardware response or safely passed the instruction to the physical hardware.

Memory Management and Emulation

Each VDM was assigned its own virtual address space, preventing one misbehaving DOS application from corrupting the memory of other running programs or the Windows kernel. Windows 98 emulated multiple standard DOS memory extension specifications:

  • Expanded Memory (EMS): Virtualized using the system's extended memory via the Expanded Memory Specification (EMS 4.0).
  • Extended Memory (XMS): Managed through the Extended Memory Specification via an internal driver (HIMEM.SYS equivalent within the VDM).
  • DPMI (DOS Protected Mode Interface): Implemented to allow 16-bit and 32-bit protected-mode DOS programs (such as games using DOS extenders like DOS/4GW) to run seamlessly within the VDM.

Program Information Files (PIFs)

Windows 98 allowed fine-grained execution tuning through Program Information Files (.PIF). When a user modified the properties of a DOS executable, Windows wrote the settings to a corresponding PIF file. These settings dictated:

  • Allocation limits for conventional, EMS, XMS, and DPMI memory.
  • Idle sensitivity, which allowed the scheduler to detect when a DOS program was idling on keyboard input and yield CPU cycles to other Windows threads.
  • Graphics mode configuration (windowed vs. full-screen).
  • Protection against direct hardware writes and port contention.

MS-DOS Mode: The Native Fallback

For complex DOS programs—particularly games requiring direct access to sound cards, custom video modes, or specialized memory managers that V86 mode could not reliably virtualize—Windows 98 provided "MS-DOS Mode."

MS-DOS Mode was not a VDM. Instead, Windows 98 unloaded the graphical user interface, flushed all disk caches, and restarted the system into real-mode MS-DOS 7.1. In this state, multitasking was suspended entirely, and the program gained direct, unvirtualized access to all physical hardware. Upon exiting the software, the system automatically executed a reboot sequence to return to the Windows 98 desktop.