The keyboard-interrupt handler services hardware interrupts generated by the
keyboard. The handler retrieves scan codes from the keyboard, translates the
scan codes into virtual-key codes, and passes the scan and virtual-key codes to Windows through the keyboard-event callback function. It also updates the keyboard flags (usually at 40h:17h in the RAM area of the ROM BIOS) and checks for special keys or key combinations.
When the interrupt handler receives control, such as when the user presses or releases a key, the handler retrieves the current input from the keyboard data port and determines whether the input is a scan code or a command byte. If it is a command byte, it passes control to the original keyboard-interrupt handler. Otherwise, it continues to process the scan code.
When processing the scan code, the handler checks for key combinations, such as CTRL+ALT+DELETE, and passes control to the original keyboard-interrupt handler to carry out the corresponding actions. It also checks for the ALT+PRINTSCREEN and SHIFT+PRINTSCREEN key combinations and translates these into the VK_SNAPSHOT virtual-key code. When Windows receives this virtual-key code, it takes a snapshot of the active window or the entire screen. The handler indicates which snapshot to take by setting the BX register to zero for the active window (ALT+PRINTSCREEN) and to 1 for the entire screen (SHIFT+PRINTSCREEN).
To support debugging, the interrupt handler checks for the CTRL+ALT+SYSREQ key and eithers simulates a nonmaskable interrupt (NMI) (to pass control to a debugger) or jumps to the CVWBreak function (KERNEL.205) to carry out a controlled break. If Windows is running with OS/2, the handler ignores the CTRL+ALT+SYSREQ key combination.
To complete processing the scan code, the handler sets the interrupt flag using the SetInterruptFlag (sti) instruction. Before doing so, it makes sure a subsequent keyboard interrupt does not invoke the handler again as only one interrupt can be handled at a time. If Windows is running in enhanced mode, this may require masking out the keyboard interrupt (usually IRQ1) at the interrupt controller.
If Windows is running with OS/2, the interrupt handler checks for the ALT+ESC and CTRL+ESC key combinations. If either of these key combinations is carried out, the interrupt handler passes the scan codes to the original keyboard-interrupt handler so that OS/2 can switch from Windows to OS/2 programs. However, the Windows keyboard-interrupt handler only passes these scan codes if screen-switching is enabled. The display driver specifies when screen-switching is enabled or disabled by calling the ScreenSwitchEnable function. The display driver disables switching whenever it enters a critical section. If switching is disabled, the Windows keyboard-interrupt handler ignores the ALT+ESC and CTRL+ESC key combinations.