How Windows 95 Handled ISA Hardware Interrupts

Windows 95 managed ISA hardware interrupts by bridging legacy 16-bit real-mode hardware with its 32-bit preemptive multitasking kernel. Rather than allowing expansion cards to directly trigger legacy MS-DOS Interrupt Service Routines (ISRs), Windows 95 intercepted interrupt requests (IRQs) using its Virtual Machine Manager (VMM32) and the Virtual Programmable Interrupt Controller Device (VPICD). This abstraction allowed the operating system to arbitrate hardware signals, prioritize 32-bit protected-mode drivers, and selectively route interrupts to legacy DOS or Windows applications without crashing the system.

The Industry Standard Architecture (ISA) bus relied on dedicated physical lines connected to two cascaded Intel 8259A Programmable Interrupt Controllers (PICs), providing IRQ 0 through IRQ 15. Because standard ISA interrupts were edge-triggered—meaning the controller responded to a voltage transition rather than a sustained state—IRQs generally could not be reliably shared between multiple ISA expansion cards. When an ISA card needed attention, it raised its specific IRQ line, prompting the PIC to signal the processor.

When an interrupt fired, the CPU referenced the protected-mode Interrupt Descriptor Table (IDT). In Windows 95, these IDT vectors pointed directly to core routines within the VMM, bypassing the real-mode Interrupt Vector Table (IVT) located in lower memory. The primary subsystem responsible for handling these incoming signals was VPICD.VXD (Virtual Programmable Interrupt Controller Device).

VPICD acted as an arbiter between the physical hardware and any software layers attempting to process the interrupt. Device drivers declared ownership of specific IRQs at boot by calling VPICD services, such as VPICD_Virtualize_IRQ. When processing an interrupt, VPICD followed a distinct operational sequence:

  1. Hardware Masking: Upon receiving an interrupt, the 8259A PIC signaled the CPU, and the VMM routed control to VPICD. The PIC or VPICD masked the active IRQ line to prevent subsequent interrupts from the same device from interrupting execution before the first request cleared.
  2. Driver Routing: VPICD determined whether the interrupt belonged to a native 32-bit virtual device driver (VxD) or a legacy 16-bit driver running in a Virtual DOS Machine (VDM).
  3. Execution in Protected Mode: If a 32-bit VxD owned the IRQ, VPICD directly executed the driver's registered hardware ISR in Ring 0. The VxD communicated directly with the ISA card's I/O ports to read data or acknowledge the hardware condition.
  4. Reflection to Real Mode: If the hardware was managed by a 16-bit real-mode driver (such as a legacy DOS mouse or network driver loaded via AUTOEXEC.BAT), VPICD suspended the current thread, switched execution contexts, and "reflected" the interrupt down to the virtual machine executing the 16-bit code via the VM's virtualized IVT.
  5. End of Interrupt (EOI): Once the driver finished servicing the hardware event, it notified VPICD. VPICD issued an End of Interrupt (EOI) instruction to the physical 8259A PIC, unmasking the IRQ line and re-enabling the ISA card to signal future events.

Because ISA hardware lacked native support for dynamic resource assignment, Windows 95 managed IRQ allocations using the Configuration Manager. Legacy ISA cards required manual jumper configuration to match system settings, while later Plug and Play (PnP) ISA cards allowed Windows 95 to isolate cards via software key sequences and assign conflict-free IRQs before VPICD initialized the hardware hooks.