Sorting it all Out Michael Kaplan's random stuff of dubious value Be sure to read the disclaimer here first!
The note from the Suggestion Box was:
Loading keyboard dlls in a 64-bit environment using a 32-bit application
I've been enjoying you topics regarding the keyboard dlls (kbd**.dll) files and how to mess with them :)
Earlier I decided to create a onscreenkeyboard of my own, based on scan codes, so I could take the advantage of these existing keyboards dlls.
In my path of development; I did not get it to work on a 64-bit system, the pVkToWcharTable was always NULL. It only worked if I compiled a 64-bit version of my app.
I've written a class to actually manage 32-bit app on a 64-bit system, and it works. I've even shared it to the public, by writing an article: http://lars.werner.no/?p=870
Since you always investigate deep, do you have any root cause of what actually fails?
Hope to see an article on that later on!
We don't actually document how to act like Windows does when it uses one of these keyboard layout DLLs.
Previous travails, discussed in The wacky world of WOW64 keyboards, un-leashed, un-locked, un-something-or-other and If you just don't think you can hold it (64-bit style!), may seem relevant.
But they aren't -- not directly at least.
Yet by looking at what happens differently in 64-bit builds, one can reverse engineer the differences for 64-bit builds either directly here or indirectly by looking at kbd.h and how it defines the structure differently for the 64-bit case.
I'd help, but that would be a Microsoft employee doing the work to document the stuff that we decided not to document....