How Windows 3.11 Initializes Devices via WIN.COM

This article explains how Microsoft Windows 3.11 (and Windows for Workgroups 3.11) initializes system devices during the execution of WIN.COM. It covers the transition from MS-DOS real mode to 386 Enhanced Mode, the role of WIN386.EXE, the phased loading of Virtual Device Drivers (VxDs) via the Virtual Machine Manager, and the handoff to the 16-bit graphical subsystem drivers defined in SYSTEM.INI.

When a user typed WIN at the MS-DOS prompt, the system executed WIN.COM, a real-mode executable designed to orchestrate the bootstrap process. Because Windows 3.11 abandoned Real and Standard modes, WIN.COM primarily functioned to verify system capabilities (confirming at least an Intel 80386 processor), evaluate command-line switches, and locate the primary core files before unpacking and handing control over to WIN386.EXE.

Once launched, WIN386.EXE initialized the protected-mode environment. It configured the Global Descriptor Table (GDT), Interrupt Descriptor Table (IDT), and paging tables, shifting the CPU from real mode to protected mode. At this stage, the MS-DOS session from which Windows was launched was encapsulated into the "System Virtual Machine" (System VM). WIN386.EXE then instantiated the Virtual Machine Manager (VMM), the kernel layer responsible for managing memory, preemptive multitasking between VMs, and hardware virtualization.

Device initialization under the VMM occurred primarily through 32-bit Virtual Device Drivers (VxDs). The VMM parsed the [386Enh] section of SYSTEM.INI to locate both internal (monolithic modules embedded within WIN386.EXE) and external VxDs (such as network drivers, storage virtualization like FastDisk/32-bit Disk Access, and virtual display drivers).

The VMM initialized these VxDs in a strictly defined, multi-pass sequence by broadcasting directed control messages to each driver:

1. Sys_Critical_Init: Interrupts remained disabled. Drivers performed bare-minimum initialization necessary for survival, such as setting up internal data structures and validating presence. Drivers were forbidden from performing I/O that relied on interrupts or allocating memory during this phase.
2. Device_Init: Interrupts were enabled. VxDs hooked hardware interrupts (IRQs) through the Virtual Programmable Interrupt Controller Device (*VPICD), intercepted I/O ports, allocated memory buffers, and claimed specific hardware resources.
3. Init_Complete: Broadcast once every VxD completed its Device_Init phase. This allowed drivers to interact with other fully initialized VxDs or release temporary memory used only during the setup phase.

After the 32-bit virtualization layer stabilized, the VMM loaded the 16-bit Windows operating environment components: KRNL386.EXE (Kernel), GDI.EXE (Graphics Device Interface), and USER.EXE (User Interface).

During the initialization of KRNL386.EXE, Windows read the [boot] section of SYSTEM.INI to load standard 16-bit ring-3 device drivers, including system.drv, keyboard.drv, mouse.drv, display.drv, and sound.drv. Unlike MS-DOS drivers, these Windows drivers communicated down through the VxD layer (such as *VKD for the keyboard and *VMD for the mouse) rather than accessing physical ports directly. This design allowed the 32-bit protected-mode VxDs to arbitrate hardware access seamlessly between MS-DOS virtual machines and the Windows graphical interface.

Once the 16-bit drivers successfully established connections to their virtualized hardware interfaces, the shell program (typically PROGMAN.EXE) was launched, concluding the device initialization sequence and presenting the user with the graphical desktop.