PuTTY semi-bug win-dead-keys

This is a mirror. Follow this link to find the primary PuTTY web site.

summary: Trouble with dead keys on Windows
class: semi-bug: This might or might not be a bug, depending on your precise definition of what a bug is.
difficulty: taxing: Needs external things we don't have (standards, users etc)
priority: medium: This should be fixed one day.
fixed-in: 2004-03-27 4736781f42e99168a2fc792b96141d08ee5d6497 (0.55)

When using a keyboard layout that uses dead keys (such as German, or US International) on Win2K or XP, entering a non-composing sequence (such as a pair of circumflexes), such that the second keypress resulted in two characters, gave the wrong result (the second character was wrong).

Changing the storage behind the lpChar argument of ToAsciiEx from WORD[] to BYTE[], and using a pointer cast, makes it work properly on 2K/XP. (Done as of 2004-03-25.) The documentation isn't clear what type the storage behind the pointer should be, but Googling indicates that this usage is not uncommon.

However, this breaks the same situation in (French and German) Win98SE, which was working OK before with the WORD[] array. (But fixes it for French Win2K.) The storage of the array is conditionalised on Windows version as of 2004-03-27. *crosses fingers*

This area is rich in history. For example:

We originally switched from ToAscii to ToAsciiEx to fix a problem a Lithuanian user was having with top bits being stripped.
ref: 20001222172132.A17154@kibiras.kaunas.alna.lt
We then had a complaint from a Korean user that ToAsciiEx didn't work on Korean Win98 (but was OK on WinMe and 2000), whereas ToAscii was fine. We didn't do anything about this because it seemed just too horrible.
ref: 3B67475D.64790726@kias.re.kr
We've also had a complaint from a Danish user that they get the first key in a dead key sequence and the composed character.
ref: 000701c09c57$a2ce70e0$0e00a8c0@neland.dk
We've had a report that fiddling with the keys array before passing it to ToAsciiEx makes a difference, which could be consistent with a confusion like that described above.
ref: E14wR3x-0000t8-00@ixion.tartarus.org

I've got a horrible suspicion that it's not as simple as a Win9x/NT split; this function appears to be an interface to the keyboard driver, and MS's specification of that interface on their website looks unclear to me, so I suspect that whether it's an array of bytes or words is dependent on the keyboard driver in question.

We could in principle try to detect it by initialising the array with unlikely values and seeing what changes. Bleurgh.

This may be the root of some other keyboard problems people have been having, too, if we're lucky. If our hacking in this area makes a difference to you (positive or negative), please let us know.

If you want to comment on this web site, see the Feedback page.

Audit trail for this semi-bug.

(last revision of this bug record was at 2017-04-28 16:52:45 +0100)