How Windows 3.11 Processed System Hotkeys

In Microsoft Windows 3.11, processing system shortcut hotkeys was a low-level operation handled through a combination of hardware interrupts, virtual device drivers, the keyboard driver, and the 16-bit User module. Because Windows 3.11 ran as a cooperative multitasking graphical environment on top of MS-DOS, capturing critical system keys like Alt+Tab, Ctrl+Esc, or Ctrl+Alt+Del required intercepting scan codes before normal applications or DOS virtual machines could consume them. This article explains the technical pipeline that detected, trapped, and executed these global keystroke combinations.

Hardware Interruption and BIOS Trapping

The process began at the hardware level. When a user pressed a key, the keyboard controller generated hardware Interrupt Request 1 (IRQ 1), which triggered Interrupt 09h (INT 9). In standard MS-DOS mode, this placed raw scan codes into the BIOS keyboard buffer. However, in Windows 3.11 running in 386 Enhanced Mode, the system took control of hardware interrupts through the Virtual Machine Manager (VMM).

The Role of the Virtual Keyboard Device (VKD.386)

In 386 Enhanced Mode, the low-level virtual device driver VKD.386 acted as the primary gatekeeper for keyboard input. VKD hooked INT 9 directly:

  • Hardware Arbitration: VKD tracked the real-time state of modifier keys (Alt, Ctrl, Shift) across all active virtual machines, including DOS sessions and the System Virtual Machine running the Windows graphical interface.
  • Hot-Key Interception: Before delivering a scan code to the active virtual machine, VKD evaluated the code against a table of global system hotkeys. If a combination such as Ctrl+Alt+Del or a configured DOS switching key was encountered, VKD intercepted the sequence, preventing it from reaching the target application.

Translation by KEYBOARD.DRV

For keystrokes that reached the Windows System VM, control passed to the 16-bit Windows keyboard driver (KEYBOARD.DRV).

  1. Scan Code Conversion: KEYBOARD.DRV converted the hardware make-and-break scan codes into Windows-standard virtual key codes (VK codes).
  2. State Tracking: The driver maintained an internal state array for modifier keys to distinguish combinations like Alt+Tab from standard alphanumeric keystrokes.
  3. Queue Placement: Once converted, KEYBOARD.DRV called the hardware_event procedure in USER.EXE to push the input event into the single, shared system message queue.

Handling System Commands in USER.EXE

The 16-bit USER.EXE module managed window management and the message loop. When evaluating messages from the system queue, it identified system-level shortcut keys through specific behaviors:

  • Fast Alt+Tab Switching: If the user pressed Alt+Tab and the "Fast Alt+Tab" feature was enabled (introduced in Windows 3.1), USER.EXE bypassed normal message routing. It displayed a modal pop-up box showing the icon and title of the next top-level window, cycling through the internal window list until the user released the Alt key.
  • Task Manager (Ctrl+Esc): When USER.EXE detected Ctrl+Esc, it launched or brought focus to TASKMAN.EXE (the Windows Task Manager).
  • System Menu Shortcuts (Alt+Space, Alt+F4): Standard window management shortcuts were converted into WM_SYSKEYDOWN and WM_SYSKEYUP messages. When processed by DefWindowProc, these messages generated WM_SYSCOMMAND notifications (such as SC_CLOSE for Alt+F4 or SC_KEYMENU for Alt+Space), directing the active window to execute the corresponding system behavior.

Global Hooks via WH_KEYBOARD

Software applications that needed to monitor or intercept system-wide shortcuts relied on the Windows hook mechanism. Developers used SetWindowsHookEx with the WH_KEYBOARD filter residing in a dynamic link library (DLL). Because 16-bit Windows shared a unified address space, a WH_KEYBOARD hook in a DLL ran in the context of the running application, allowing programs to inspect, alter, or discard keystrokes before they reached the destination window's message queue.