Why are the HKL and KLID of the keyboard different? - Sorting it all Out - Site Home

I actually get this question on a regular basis, believe it or not.

People look at the two numbers, see the similarities, and then start assuming they are the same. To review from my old keyboard terminiology post:

KLID -- a keyboard layout identifier. Traditionally pronounced "Kay-El-Eye-Dee" because some people in the USA get very uptight about certain homonyms (you can catch me slipping on this point from time to time). It's also sometimes called the input locale identifier since the name for HKL has been updated (see the HKL definiteion for info on why that is incorrect since the HKL is for something different). The KLID can be retrieved for the currently selected keyboard layout in a thread through the GetKeyboardLayoutName API (note the pswzKLID parameter), though that is not true of any other selected or installed keyboard layout. Every keyboard layout on the system has one of these. Each KLID is 32 bits (thus 8 hex digits), and they can all be found in the registry as the subkeys under HKLM\SYSTEM\CurrentControlSet\Control\Keyboard Layouts\. The bottom half of the KLID is a LANGID, and the top half is something device-specific. By convention, the first hex digit is usually as follows:
- 0 -- Most keyboard layouts
- A -- Keyboard layouts defined by MSKLC
- D -- Some non-CJK input methods that have been defined by the Text Services Framework (note: reported to me; I have never seen one of these!)
- E -- CJK input methods, also known as IMEs
HKL -- a handle to a keyboard layout, traditionally pronounced "Āch-Kay-El", the terminiology folks have pretty aggressively tried to call this an "input locale identifier" despite the obvious problem that it has nothing to do with locales and that it is not the same value as the actual identifier (the KLID). The HKL in actuality is the handle to an input method. Althought defined as a handle, only the lower 32 bits are currently used. Of those 32 bits, the bottom 16 bits represent a LANGID, and the top 16 bits represent a value defined by the USER SUBSYSTEM which helps to uniquely identify an installed keyboard layout. This is crucial since any keyboard layout can be installed more than once (by installing it under different languages, which helps user operations like spell checking).

The differences are not obvious if you install keyboards via the LoadKeyboardLayout API (by the way, note the pwszKLID parameter name for those who doubted me about the whole KLID thing!). In that case, the same LCID is always used, and if the keyboard is one of the many with KLID values like 00000409 or 00000407 then the HKL value will be the same as KLID, further making people think they are the same. However, there are two times when they can and will be different:

Any time the KLID value is more than just the LANGID -- like 00010439 for the Hindi Traditional keyboard layout or 0003041e for the Thai Pattachote (non-ShiftLock) keyboard layout, the HKL will have a high word of the lower DWORD filled with different information.
Any time the keyboard is assigned via the Text Services Framework UI under a different language than the original keyboard (e.g. installing the US keyboard under the French language), the HKL will be based on the language you chos, not the language implicit in the KLID.

One could say that making the HKL a handle was a waste, especially since it is a waste of 32 bits of space on 64-bit platforms, but I kind of wish we had defined LCIDs in the same way, it allows for a lot more flexibility.

In any case, these two values are based on entirely different principles, and the times that they are the same value are entirely coincidential....

This post brought to you by "Ѐ" (U+0400, a.k.a. CYRILLIC CAPITAL LETTER IE WITH GRAVE)
A letter whose current importance is almost entirely based on its lack of substance in Windows!