Sorry to be late to this thread. I'm the Program Manager responsible for MSKLC at this time. As far as the history here, I can only reiterate Michael's point that making significant changes to user32.dll faces significant, perhaps insurmountable headwinds. There would have to be compelling reasons to make any kind of changes here. If you have specific feedback for Microsoft on this issue, please follow up with me off line.
Thanks, Andrew Glass -----Original Message----- From: Unicode [mailto:[email protected]] On Behalf Of Doug Ewell Sent: Friday, August 7, 2015 3:21 PM To: Unicode Mailing List <[email protected]> Cc: Marcel Schneider <[email protected]> Subject: Re: Windows keyboard restrictions Marcel Schneider <charupdate at orange dot fr> wrote: > I brought the good news that SIXTEEN UNICODE CODE POINTS can be > generated by a single key stroke on Windows six dot one. The only bad > news, because of which I've e-mailed to the List, is that that wasn't > working in one single circumstance. It was obvious that the main thing > to do, is to inform about this fact, so that other people mustn't > search for a bug in the driver if it's only that. But that's what I've been trying to say. The maximum isn't 16, it's 4. "That wasn't working" is the expected behavior here. If you were able to create a keyboard layout where 16 code points ever worked on Windows 7 (which reports itself as "6.1"), it was purely by accident -- because Windows 7 did not check for the overrun, and because the overrun did not happen to cause any collateral damage. If you have a light bulb that's rated for 110 volts, and you apply 220 volts to it and for some reason the bulb doesn't burn out immediately, that doesn't mean 220 volts is the correct operating environment for that bulb. It means you got lucky. If there's a bug here, it's that Windows didn't detect that the limit had been exceeded, and respond by locking out the key. -- Doug Ewell | http://ewellic.org | Thornton, CO 🇺🇸
