How Windows 3.11 Processed Bus Mouse Input

This article provides an overview of how Microsoft Windows 3.11 handled input from legacy bus mouse devices. Operating in protected mode, Windows 3.11 bypassed typical MS-DOS interrupt routines to communicate directly with bus mouse expansion hardware. Through a combination of the Virtual Programmable Interrupt Controller Device, low-level virtual device drivers (VxDs), and the 16-bit Windows mouse driver, the operating system converted raw hardware signals from ISA expansion cards into graphical cursor movement and window messages.

The Hardware Interface

Unlike serial mice that communicated over RS-232 lines or PS/2 mice that interfaced with the motherboard’s Intel 8042 controller, a bus mouse relied on a dedicated ISA add-in card, such as the Microsoft InPort interface. This interface mapped the device directly to system input/output (I/O) port addresses (commonly ranges like 0x23C through 0x23F) and a dedicated hardware Interrupt Request line (typically IRQ 2, 3, 4, or 5).

Movement of the mouse mechanical rollers turned quadrature encoders, altering hardware counters on the card. When the state of the counters changed or a button was pressed, the interface card asserted its assigned IRQ line on the ISA bus.

Protected Mode Interrupt Handling

In Windows 3.11’s standard 386 Enhanced Mode, direct hardware interactions were virtualized and managed by the operating system kernel (WIN386.EXE). Hardware interrupts generated by the bus mouse were trapped by the Virtual Programmable Interrupt Controller Device (VPICD.386).

VPICD.386 mapped the physical IRQ of the bus card to the virtual mouse driver, typically VMOUSE.386. This allowed Windows to process the interrupt in 386 protected mode without requiring a mode switch down to real-mode MS-DOS or relying on the real-mode INT 33h driver, which significantly reduced input latency and prevented system instability.

Data Extraction and Latch Clearing

Once VMOUSE.386 caught the interrupt, it communicated with the bus card’s internal registers via direct IN assembly instructions:

  1. Register Selection: The driver wrote to the interface's control register to select the desired data channel (such as the low and high bytes of the relative X and Y delta counters).
  2. Reading Movement and Buttons: The driver read the delta values (number of mickeys moved since the last poll) and the instantaneous state of the microswitch buttons.
  3. Reset and Acknowledgment: The driver wrote back to the hardware control register to reset the quadrature counters and release the interrupt latch on the ISA card.
  4. End of Interrupt (EOI): An EOI command was sent to the 8259 Programmable Interrupt Controller, re-enabling subsequent hardware interrupts.

Coordinate Normalization and Event Dispatching

After VMOUSE.386 retrieved the raw motion deltas and button states, it forwarded this data to the 16-bit user-mode driver, MOUSE.DRV.

MOUSE.DRV was responsible for interpreting physical motion into desktop coordinates. It applied user-defined acceleration curves, sensitivity scalers, and ballistic tracking algorithms set in the SYSTEM.INI and CONTROL.INI configuration files. The driver updated the internal virtual coordinates of the mouse cursor, ensuring it remained bounded within the display resolution parameters provided by the active display driver.

Generation of Windows Messages

Once MOUSE.DRV resolved the absolute coordinates and button actions, it invoked the event handler in USER.EXE (the Windows 3.11 User interface library).

USER.EXE updated the graphical position of the mouse cursor on the display and generated standard Windows input messages. Movement yielded WM_MOUSEMOVE messages, while button state transitions generated messages such as WM_LBUTTONDOWN, WM_LBUTTONUP, WM_RBUTTONDOWN, or WM_RBUTTONUP. These messages were subsequently posted directly into the message queue of the window control currently beneath the cursor coordinates or to the application that held mouse capture.