by Michael S. Kaplan, published on 2006/12/19 11:51 -05:00, original URI: http://blogs.msdn.com/b/michkap/archive/2006/12/19/1326431.aspx
Reader Lionel Fourquaux asked me:
I was mentioning MSKLC to a fellow student who complained that he couldn't get his usual keyboard configuration on Windows, when I realized that on one point he was perfectly right to complain: since MSKLC install a system-wide keyboard DLL, it cannot be used by a normal user (non-admin). This can be very inconvenient for shared computers.
I think that keyboard configurations should be fully a per-user setting, and that this problem should be considered for the future.
This is a very interesting feature idea, even more so in the world of Vista and LUA/UAC. The question becomes almost obvious -- why can't keyboards work at a per-user level?
Unfortunately, the problem is complicated by the fact that since NT 4.0, this particular bit of the user subsystem has been one of those bits that is mostly a kernel mode component (more information in the article entitled MS Windows NT Kernel-mode User and GDI White Paper for those who are curious about this change).
With user profiles being as complicated as they are, tying them in such a way as to allow per-user keyboards would be a pretty difficult negotiation!
With that said, there are other pieces of profiles that are made part of the local machine only (they end up in the user's hidden Local Settings directory (now AppData\Local in Vista). So perhaps there could be a mechanism to allow keyboards that are "per user" which are registered when the user is logged in so that the kernel mode piece would know to (and be able!) to pay attention to it. Perhaps this could be a feature in a future version of Windows? :-)
Now of course I would not encourage people to get their hopes up too much (and even ignoring that it is obviously going to be a bit of time before the next release of Windows), but it might be a feature idea to keep in mind.
I'll be sure to do my best to make sure that after such a feature is in Windows that the version of MSKLC that comes out will support it....
This post brought to you by ｋ (U+ff4b, a.k.a. FULLWIDTH LATIN SMALL LETTER K)
Darryl on 19 Dec 2006 2:23 PM:
Not to mention when you use remote desktop to access a machine and the remote machine has some strange keyboard configured.
Nothing like trying to figure out how to type in your password only to find the key you are using isn't they key the machine is getting :(
Actually I am not sure if this is a keyboard definition thing or an IME thing. But I am sure you know.
Ben Cooke on 19 Dec 2006 11:08 PM:
I was just about to post about the same thing Darryl posted.
It seems that if the keyboard layout you're using on your local machine isn't available on the remote system, it defaults to some other layout. On the Windows Server 2003 systems at work, this always seems to be US English, which is annoying since I'm British! I guess the default depends on what regional version of Windows you are running, though?
It confused me no end at first, since I had forgotten that I was using a custom keyboard layout. Since Windows seems to group keyboard layouts by country anyway, perhaps it could be made to default to one of the keyboard layouts whose country matches the selected layout if the exact layout is unavailable. That way I'd still end up with my quote signs on Shift+2 even if I don't have my em-dashes on Shift+AltGr+minus; when remotely administrating servers, I generally type the quote character much more often than I type an em-dash!
Lionel Fourquaux on 20 Dec 2006 1:31 PM:
Thanks for the post, Michael!
I'm aware that the kernel-mode implementation makes this difficult. However, since part of the graphic code (WDDM drivers) was pulled back from kernel mode in Vista, while keeping correct performance, maybe something like that could be considered for keyboard layouts? While the Windows message queue itself should be fast, I doubt anyone is typing fast enough that there is a performance issue intrinsically tied to keyboard layouts. So, maybe this part could be moved to userland with little performance impact?
Anyway, I posted a suggestion about this on Connect (early feedback, bug id 247007).