How Windows 95 Managed VxD Device Drivers

Windows 95 relied on the Virtual Device Driver (VxD) architecture to bridge the gap between 16-bit legacy DOS environments and its new 32-bit preemptively multitasked operating system. Using the .vxd file extension, these drivers operated at the highest processor privilege level, intercepting hardware requests, virtualizing resources for multiple applications, and providing direct hardware access. This article explains how the Virtual Machine Manager coordinated these drivers, how VxDs virtualized physical hardware, and the mechanisms used to load and execute them.

Ring 0 Execution and the Virtual Machine Manager

At the core of Windows 95's driver management was the Virtual Machine Manager (VMM32.VXD). The system operated using the x86 processor's protection rings. While standard applications ran in the restricted Ring 3 user mode, VxDs ran directly in Ring 0 (kernel mode).

Running in Ring 0 granted VxDs unrestricted access to the CPU instructions, system memory, and physical I/O ports. The Virtual Machine Manager served as the primary host, supervisor, and scheduler for all VxDs, facilitating inter-driver communication and exposing a centralized set of operating system services.

Hardware Virtualization and Interception

The "x" in VxD represented any generic hardware device class, such as a display adapter (VDD), mouse (VMOUSE), or communication port (VCD). Because multiple MS-DOS applications and Windows programs could run simultaneously, multiple processes often attempted to access the same physical hardware at the same time.

To prevent hardware conflicts, VxDs used x86 hardware virtualization features:

  • I/O Port Trapping: VxDs configured the CPU's I/O Permission Bitmaps to intercept attempts by applications to read or write directly to hardware ports.
  • State Virtualization: When a program tried to access a hardware port, the CPU triggered an exception that transferred control to the designated VxD. The VxD maintained virtual copies of the hardware's state registers for each Virtual DOS Machine (VDM).
  • Arbitration: The driver decided whether to queue the request, pass it directly to the physical hardware, or simulate a response back to the software, thereby maintaining stability without breaking DOS compatibility.

Loading Mechanisms: Static vs. Dynamic VxDs

Windows 95 improved upon Windows 3.1 by supporting both static and dynamic driver loading:

  1. Static Loading: Essential system drivers were loaded during the early boot phase. Windows 95 read the system registry and SYSTEM.INI file, locating drivers defined under the [386Enh] section. Many core drivers were packed into a single monolithic archive called VMM32.VXD located in the SYSTEM directory to improve boot performance.
  2. Dynamic Loading: Windows 95 introduced dynamic VxDs to support features like Plug and Play (PnP). Dynamic drivers could be loaded into Ring 0 memory and unloaded on demand when a device was connected or disconnected (such as PCMCIA cards). Applications and system components could dynamically invoke drivers through the Win32 CreateFile and DeviceIoControl APIs.

Driver Communication and Interfaces

VxDs functioned as modular components that exposed service tables. Windows 95 managed these interactions through several structured interfaces:

  • System Control Messages: The VMM broadcast messages to VxDs regarding major operating system events, such as device initialization, system exit, or the creation and destruction of a Virtual Machine.
  • Service Tables: A VxD could register named services that other VxDs could invoke directly in Ring 0 using efficient jump tables.
  • Application Interfaces: Ring 3 programs (both 16-bit and 32-bit) communicated with VxDs using software interrupts (such as INT 2Fh) or system calls to pass control buffers and receive hardware state data.

Because VxDs operated in Ring 0 with zero memory protection boundaries between drivers, an unhandled exception or corrupt memory write in any .vxd file would halt the entire operating system, often causing a Blue Screen of Death (BSOD). This architecture prioritized performance and legacy compatibility, serving as Windows 95's primary driver model until Microsoft transitioned toward the more stable and unified Windows Driver Model (WDM).