Published on 1st November 2003
To implementers, it seems inputting data into applications via keyboards should be one
of the fundamentally simple features on Windows. However, once additional complexities like fonts and rendering engines are taken into consideration, input appears to be not quite so simple anymore. Adding many different keyboard layouts on top of over 135 locales further complicates the issue. And finally, once you include the ability to define keyboard layouts (whether by Microsoft interfaces or third party products) where all of Unicode can be supported, it becomes downright complex!
Definition of a keyboard layout
A keyboard layout is the collection of data for each keystroke and shift state combination within a particular keyboard driver. It is not the physical keyboard that a user types on, but rather, the software that the hardware calls to output text streams to applications.
Association between the scan codes, the virtual keys and the shift states in a keyboard.
1. Scan codes
Keyboard input starts at the hardware level. The keys on the physical keyboard each have a value assigned to them called a scan code, and these scan codes are sent whenever you type a key. To complicate things, keyboard hardware varies depending on the geographical market; in many of the markets, you will find slightly different relationships between physical keys and scan codes. Because of this, layout maps like the full Windows XP list, which can be found at http://www.microsoft.com/ globaldev/reference/keyboards.aspx can be somewhat inaccurate in some parts of the world, since the maps assume that:
- Physical key placement is identical and
- Keys will have the same meaning, even if the hardware is different.
Click here for two examples of scan code maps that cover the main part of the keyboard.
2. Virtual Key (VK) values
At the software level, what becomes crucial is the VK or Virtual Key value. These values fit within a byte (0x00 to 0xff) and are defined in winuser.h: the Platform SDK header file that contains procedure declarations, constant definitions and macros for the USER subsystem of Windows
3. Processing keystrokes
When a Windows message loop handles a VK in the WM_KEYDOWN message, it can pass the VK to the DefWindowProc API. To handle the message, the code in the USER subsystem will process the keystroke and convert it (when appropriate) to a character, passed as a WM_CHAR message.
This processing requires a great deal of information:
- the shift state
- the virtual key
- the current keyboard layout
Once all of this information is collected by the USER subsystem (that is, the keyboard layout is known for each thread and the WM_KEYDOWN message contains the VK and shift state), the code is then is able to come up with the appropriate character, taking all the information about shift states, VKs and current layout into account (obviously hitting arrow keys, for example, would not be expected to insert characters; USER will not have any of this extra character-based work run).