How Windows 95 Handled Alt-Tab Task Switching

When Windows 95 launched, it revolutionized task navigation by replacing the rudimentary modal boxes of Windows 3.1 with the modern graphical "cool switch" interface. This article explores the internal mechanisms Windows 95 used to intercept the Alt-Tab keystroke, maintain the window hierarchy, render the iconic on-screen overlay, and manage the execution context transfer between legacy 16-bit applications and new preemptive 32-bit processes.

Intercepting the Keyboard Input

The process began at the hardware level. When a user pressed the Alt and Tab keys, the keyboard controller triggered Hardware Interrupt 1 (IRQ 1). The Windows 95 keyboard driver converted these hardware signals into scan codes and routed them directly to the USER subsystem (USER32.DLL and its core 16-bit counterpart USER.EXE).

Unlike standard application-targeted keystrokes, the system filtered the VK_MENU (Alt) and VK_TAB combination before it reached the active thread's message queue. The OS maintained dedicated input handling logic that monitored the state of modifier keys. Once it detected that Alt was held down and Tab was struck, it initiated the internal fast-task-switching routine instead of dispatching the message to the active window.

Filtering the Window Z-Order

To determine which applications could be switched to, Windows 95 traversed its internal window list. The operating system organized desktop windows in a Z-order—a linked list representing the stacking order of windows from the top of the screen to the background.

Not every window qualified for the Alt-Tab menu. The USER subsystem applied specific filtering criteria to determine eligibility:

  • The window had to be visible (WS_VISIBLE).
  • The window had to be a top-level unowned window, or explicitly marked with the WS_EX_APPWINDOW style.
  • Tool windows (WS_EX_TOOLWINDOW) and hidden utility windows were skipped.
  • Child windows and the desktop background window were excluded.

The system cached an ordered array of handles (HWND) representing these valid applications, positioning the second window in the Z-order (the most recently used window prior to the active one) as the initial selection.

Rendering the Heads-Up Display

Once the eligible applications were determined, the operating system created a lightweight, transient system window to display the task switcher heads-up display.

The system queried each application window for its display metadata. To retrieve icons, it checked the window's registered class (WNDCLASS) structure for an hIcon handle, or sent a non-blocking WM_GETICON message. It retrieved the application title using the window's internal text buffer (equivalent to GetWindowText).

Windows 95 then used standard Graphics Device Interface (GDI) routines to draw a centered gray box containing a horizontal row of 32x32 icons. As the user continued to tap Tab while holding Alt, an internal index pointer incremented (or decremented if Shift was held), moving a highlight frame to the next icon and updating the single-line text label at the bottom of the box.

Context Switching and Activating the Target Window

The task-switching sequence concluded when the user released the Alt key. Windows 95 detected the release via the keyboard hook, immediately erased the switch window, and initiated the window activation sequence via the internal SetForegroundWindow routine.

This process required several coordinated operating system actions:

  1. Z-Order Realignment: The target window was repositioned at the top of the Z-order.
  2. Focus Messaging: The OS dispatched WM_ACTIVATE and WM_KILLFOCUS messages to the formerly active application, followed by WM_ACTIVATE and WM_SETFOCUS to the newly selected window.
  3. Thread Input Attachment: Windows 95 detached the hardware input queue from the old thread and attached it to the thread owning the newly activated window.
  4. Handling the Win16Mutex: If the task switch involved a legacy 16-bit Windows 3.1 application, the operating system had to manage the Win16Mutex—a global lock ensuring that only one 16-bit application executed at a time—before yielding or granting execution slices to the incoming task.

If the user pressed the Escape key before releasing Alt, the sequence was aborted, leaving the original application focused and restoring the desktop to its initial state.