by Michael S. Kaplan, published on 2012/02/22 07:01 -05:00, original URI: http://blogs.msdn.com/b/michkap/archive/2012/02/22/10271073.aspx
So let's say you call GetKeyNameText to get the names of the keyboard keys.
As it says in the remarks:
The format of the key-name string depends on the current keyboard layout. The keyboard driver maintains a list of names in the form of character strings for keys with names longer than a single character. The key name is translated according to the layout of the currently installed keyboard, thus the function may give different results for different input locales. The name of a character key is the character itself. The names of dead keys are spelled out in full.
Ok, so let's load the German keyboard layout (kbdgr.dll, KLD value of 0000407).
Let's skip the function calls and load it up in MSKLC to get the key names all at once:
KEYNAME
01 ESC
0e R\x00DCCK
0f TABULATOR
1c EINGABE
1d STRG
2a UMSCHALT
36 "UMSCHALT RECHTS"
37 " (ZEHNERTASTATUR)"
38 ALT
39 LEER
3a FESTSTELL
3b F1
3c F2
3d F3
3e F4
3f F5
40 F6
41 F7
42 F8
43 F9
44 F10
45 PAUSE
46 ROLLEN-FESTSTELL
47 "7 (ZEHNERTASTATUR)"
48 "8 (ZEHNERTASTATUR)"
49 "9 (ZEHNERTASTATUR)"
4a "- (ZEHNERTASTATUR)"
4b "4 (ZEHNERTASTATUR)"
4c "5 (ZEHNERTASTATUR)"
4d "6 (ZEHNERTASTATUR)"
4e "+ (ZEHNERTASTATUR)"
4f "1 (ZEHNERTASTATUR)"
50 "2 (ZEHNERTASTATUR)"
51 "3 (ZEHNERTASTATUR)"
52 "0 (ZEHNERTASTATUR)"
53 "KOMMA (ZEHNERTASTATUR)"
57 F11
58 F12
KEYNAME_EXT
1c "EINGABE (ZEHNERTASTATUR)"
1d STRG-RECHTS
35 " (ZEHNERTASTATUR)"
37 DRUCK
38 "ALT GR"
45 NUM-FESTSTELL
46 UNTBR
47 POS1
48 NACH-OBEN
49 BILD-NACH-OBEN
4b NACH-LINKS
4d NACH-RECHTS
4f ENDE
50 NACH-UNTEN
51 BILD-NACH-UNTEN
52 EINFG
53 ENTF
54 <00>
56 HILFE
5b "LINKE WINDOWS"
5c "RECHTE WINDOWS"
5d ANWENDUNG
Now let's look at the Windows 8 soft keyboard based on kbdgr.dll:
There are some keys that match, and some that do not.
As it turns out, they are not using GetKeyNameText at all; they have a new, standard, conventional mechanism to put resources in a DLL -- the same "multi-language" style used by the common dialogd, which means that the kbdbr.dll "Portuguese (Brazilian ABNT)" keyboard with KLID 00000416:
KEYNAME
01 Esc
0e Backspace
0f Tab
1c Enter
1d Ctrl
2a Shift
36 "Right Shift"
37 "Num *"
38 Alt
39 Space
3a "Caps Lock"
3b F1
3c F2
3d F3
3e F4
3f F5
40 F6
41 F7
42 F8
43 F9
44 F10
45 Pause
46 "Scroll Lock"
47 "Num 7"
48 "Num 8"
49 "Num 9"
4a "Num -"
4b "Num 4"
4c "Num 5"
4d "Num 6"
4e "Num +"
4f "Num 1"
50 "Num 2"
51 "Num 3"
52 "Num 0"
53 "Num Del"
54 "Sys Req"
57 F11
58 F12
7c F13
7d F14
7e F15
7f F16
80 F17
81 F18
82 F19
83 F20
84 F21
85 F22
86 F23
87 F24
KEYNAME_EXT
1c "Num Enter"
1d "Right Control"
35 "Num /"
37 "Prnt Scrn"
38 "Right Alt"
45 "Num Lock"
46 Break
47 Home
48 Up
49 "Page Up"
4b Left
4d Right
4f End
50 Down
51 "Page Down"
52 Insert
53 Delete
54 <00>
56 Help
5b "Left Windows"
5c "Right Windows"
5d Application
is covered as well as the kbdpo.dll "Portuguese" keyboard with KLID 00000816:
KEYNAME
01 ESC
0e BACKSPACE
0f TAB
1c ENTER
1d CTRL
2a SHIFT
36 "SHIFT DIREITO"
37 "ASTERISCO (TN)"
38 ALT
39 "BARRA DE ESPA\x00C7OS"
3a CAPSLOCK
3b F1
3c F2
3d F3
3e F4
3f F5
40 F6
41 F7
42 F8
43 F9
44 F10
45 PAUSE
46 "SCROLL LOCK"
47 "7 (TN)"
48 "8 (TN)"
49 "9 (TN)"
4a "MENOS (TN)"
4b "4 (TN)"
4c "5 (TN)"
4d "6 (TN)"
4e "MAIS (TN)"
4f "1 (TN)"
50 "2 (TN)"
51 "3 (TN)"
52 "0 (TN)"
53 "PONTO DECIMAL (TN)"
57 F11
58 F12
KEYNAME_EXT
1c "ENTER (TN)"
1d "CTRL DIREITO"
35 "BARRA (TN)"
37 "PRINT SCRN"
38 "ALT DIREITO"
45 "NUM LOCK"
46 BREAK
47 HOME
48 "SETA ACIMA"
49 PGUP
4b "SETA \x00C0 ESQUERDA"
4d "SETA \x00C0 DIREITA"
4f END
50 "SETA ABAIXO"
51 PGDOWN
52 INSERT
53 DELETE
54 <00>
56 HELP
5b "WINDOWS ESQUERDA"
5c "WINDOWS DIREITA"
5d APLICATIVO
You can we see a lot of them are even more off than German!
Now I have several competing thoughts here:
On the the hand, the mapping of localization of SKU languages and keyboards is rather lopsized since there just 36 of one and 116 of the other, with many of the latter covering languages outside those 36.
On the other hand, the "localization" of key names with the names stored in the DLL (as described in Flirting with a strange keyboard, will you remember its language in the morning?) is a bloody mess that localization engineers have no good means to reach.
On yet another hand, the new model is one that is easy and comfortable for localizers of those 36 languages, which means Windows finally can fix some of that broken model.
And on yet another hand, the mapping of soft keyboards to the layout DLLs is a problematic match in another way -- not every single layout has a unique soft keyboard layout.
And on a fifth hand, those crazy DLL based names are the only ones with a semi-documented way for people to retrieve the names -- the GetKeyNameText function -- which although it as problems, like the Catalan bug reported by a customer to the MSDN Product Feedback Center here, is all we give developers.
On the last hand, the names are in many cases of of sync between the two, as the above examples show (this was how I originally found out about the problem!).
Me and my conflicted six hands, what to do?
With the help of localization engineers I now have those soft keyboard key names, and I am going to try to sync up many of the DLLs for those 36 languages, so the two will be more in sync for Windows 8 some time after the upcoming Windows 8 Consumer Preview, so they will return the same names.
Some of the remaining key names may stay broken, as we have no good source for what the names should be in other languages -- there may well be common hardware for some languages that I have no way to even attempt to sync up with.
I am struck by the fact that if I had never dug into this issue, no one else would have noticed until months or years later - or meybe ever. One of those bugs that now that I know about it, I can't ignore, though.
I almost wish for some triage effort to won't fix the issue and relieve me of the responsibility!
Probably worth the effort though, as imperfect as it may be in the end, right? :-)