Windows 3.11 Mouse Input in Full-Screen DOS

In Microsoft Windows 3.11 running in 386 Enhanced Mode, processing mouse input for full-screen MS-DOS sessions required a coordinated subsystem consisting of the Virtual Machine Manager (VMM), a dedicated Virtual Device Driver (VxD), and virtualized real-mode software interrupts. Instead of granting the DOS environment direct, unmediated access to physical hardware, Windows intercepted physical mouse interrupts in protected mode and translated those movements into standard DOS mouse service calls (INT 33h) within the active Virtual 8086 Machine.

The Role of Virtual 8086 Mode and VxDs

When running in 386 Enhanced Mode, Windows 3.11 operated the CPU in protected mode while running each DOS application inside its own isolated Virtual 8086 (V86) machine. Physical hardware access was mediated by the 32-bit protected-mode kernel.

Mouse handling relied heavily on the Virtual Mouse Device driver, typically named VMD.386 (or vendor-specific variants like LVMD.386 for Logitech). When Windows booted, VMD.386 took control of the physical mouse hardware and hooked the hardware Interrupt Request line assigned to the device (typically IRQ 12 for PS/2 mice or IRQ 4/IRQ 3 for serial mice).

Hardware Interrupt Trapping and State Tracking

When a user moved the mouse or pressed a button while a full-screen DOS session was active:

  1. Hardware Interrupt Interception: The physical mouse generated an IRQ. Because the CPU was executing with hardware I/O virtualization enabled, control immediately trapped into protected mode, where VMD.386 received the raw hardware packets (mickeys, button flags).
  2. Context Resolution: The Virtual Machine Manager checked which virtual machine currently held input focus. In a full-screen session, the active foreground V86 machine was designated as the primary input recipient.
  3. Data Translation: VMD.386 converted the raw physical movement packets into standardized coordinate deltas (mickeys) and button status flags matching standard Microsoft Mouse specifications.

Virtualizing INT 33h

Under native DOS, mouse software relied on the INT 33h API provided by drivers like MOUSE.COM or MOUSE.SYS. Windows 3.11 virtualized this interface for DOS sessions using two primary methods depending on system configuration:

  • Internal VxD Emulation: VMD.386 could directly simulate the presence of a mouse driver inside the VM by hooking the INT 33h vector in the virtual machine's real-mode interrupt vector table (IVT). When the DOS application queried the mouse status or set event handlers via INT 33h, the calls were caught by the VxD without requiring a resident real-mode DOS driver to be loaded prior to launching Windows.
  • Driver Pass-Through: If a real-mode mouse driver was loaded in AUTOEXEC.BAT or CONFIG.SYS before starting Windows, VMD.386 worked in tandem with an instance of the DOS driver, passing virtualized hardware interrupts down into the real-mode driver's physical interrupt handler.

Event Delivery and DOS Callbacks

Most interactive DOS applications (such as games or word processors) did not merely poll INT 33h for current coordinates; they registered an asynchronous user interrupt routine using INT 33h, Function 000Ch (Set Mouse Interrupt Subroutine).

To execute this callback:

  1. VMD.386 loaded the synthesized register values (cursor position, horizontal/vertical mickeys, button press states) into the virtual execution context of the target V86 machine.
  2. The VxD invoked the VMM service Call_VM_Event or used interrupt reflection to schedule an execution interrupt inside the DOS session.
  3. When the V86 machine resumed execution, the CPU transitioned to real-mode semantics and jumped to the entry point of the DOS application's registered callback routine.
  4. Once the DOS routine issued a Far Return (RETF), execution seamlessly yielded back to the application's main thread.

Full-Screen vs. Windowed Differences

In a windowed DOS prompt, Windows had to hide the DOS cursor, project a 32-bit Windows mouse pointer over the desktop, and map pixel coordinates from the desktop window into the DOS session's internal character grid.

In a full-screen DOS session, this abstraction layer was bypassed. Windows relinquished GDI screen rendering entirely, allowed the DOS application to render its own cursor directly to video memory (such as VGA Mode 13h or Mode 03h), and supplied raw, unscaled movement data straight through VMD.386 to the virtualized INT 33h interface.