Section 6: Input System Integration

The Big Picture: A Post Office for Input

Your keyboard and mouse send signals that mean nothing by themselves: "button 1 went down", "moved 3 units left". Something has to answer the question: which window should get this? If you click on Notepad but Chrome is behind it, Chrome must not receive the click.

Windows solves this with an input system, like a post office sorting letters. Hardware drops raw "letters" in at the back door. The input system looks at the address (where is the pointer? which window has focus?) and delivers each one, as a message, to the right window's message queue (Section 3).

This section covers the desktop side of that path. The hardware side (how a key press becomes a signal, how a mouse measures movement) is in Chapter 31 — Keyboard and Mouse Internals.

 Keyboard / Mouse hardware           (Chapter 31)
        │  report over USB, Bluetooth, PS/2
        ▼
 Device drivers (HID class drivers)  (Chapter 13)
        │
        ▼
 Kernel input system (win32k family) ◄── this section
        │   decides the target window
        ▼
 Message queue of the target window's thread
        │
        ▼
 Message loop ──► WndProc  (Section 3)

6.1 How Input Reaches the Focused (or Pointed-At) Window

What it is: The kernel keeps a central input thread, often described as the raw input thread, that receives all the data from the keyboard and mouse drivers in order. It turns them into messages and places each one in the right queue.

There are two different rules, one for the mouse and one for the keyboard:

Mouse messages. As the mouse moves, the system keeps the cursor position on screen. Each time it changes (or a button changes), the system finds the target window and posts messages such as:

Hit testing. The system asks each window, starting at the top of the z-order: "Is this point inside you?" The first one that says yes wins. It then asks the window which part was hit (WM_NCHITTEST): the client area (the inside), the title bar, a border, the close button, and so on. That is how clicking a title bar drags the window but clicking the body does not.

Pointer at (400, 300)
  ▼
 z-order, front to back
 ┌─ Calculator window ?   (400,300) is outside  ──► no
 ├─ Notepad window ?      (400,300) is inside   ──► YES, client area
 └─ Desktop (Explorer)    (not asked; Notepad already won)

Keyboard messages. The system sends key events to the focus window's queue:

So pressing Shift + a produces key messages for Shift and A, and one WM_CHAR carrying A. A key such as an arrow produces key messages but no character.

Why a single input thread and per-thread queues? If every program read the hardware itself, they would fight over it, and a hung program could block the mouse for everyone. With one trusted sorter that drops messages into separate queues, a hung program only blocks its own queue. That is the reason "Not Responding" does not freeze the mouse pointer. The pointer is moved by the system, not by the stuck program.

Raw input. Games and drawing tools sometimes ask for raw input, which gives them the original device movement, without the acceleration and cursor rules. Both paths exist in Windows.

6.2 Focus and Activation

What it is: Focus decides which window gets the keyboard. Activation decides which top-level window is the active window (the one with the highlighted title bar). They usually move together.

Rules that protect you. A program may not steal the foreground at any moment. If a background program could suddenly pull itself to the front while you type your password, your keystrokes could go to the wrong place. So Windows limits foreground changes. Often a program that tries gets only a flashing taskbar button instead. This is why a finished download flashes orange on the taskbar rather than jumping onto your screen.

What the user sees as focus changes:

Click on Notepad's text box
   │
   ├─ Windows sends WM_ACTIVATE to Notepad (you are now active)
   ├─ Windows sends WM_SETFOCUS to the text box
   ├─ The previous window gets WM_KILLFOCUS and its title bar dims
   └─ Next keystrokes go to Notepad's queue

Special case: elevated windows and the secure desktop. A normal program cannot send simulated key presses to a window that runs with higher privileges (a "Run as administrator" window), and the User Account Control prompt (Chapter 25 and Chapter 26) appears on a separate secure desktop that normal programs cannot read or control. This prevents malware from clicking "Yes" on your behalf.

Global shortcuts (hotkeys). Some keys are caught before any window sees them. Win + D, Win + E, Ctrl + Alt + Del and Alt + Tab are handled by the system or shell. Programs can also register their own hotkeys and ask Windows to message them when pressed, even if they are in the background.

6.3 Input and the "Not Responding" Check

Windows gives each window a short time to react to input. If the thread behind a window leaves messages unprocessed for a few seconds, Windows marks it as not responding (Section 3.3). The system itself keeps working: the pointer moves, other windows respond. The shell and DWM (Section 4) still draw the frozen window's last picture, so you can move or close it. Choosing End task in the window or in Task Manager (Chapter 11) asks Windows to remove that process.

Summary