In the land of the unsupported, previous blogs and tools can be king
by Michael S. Kaplan, published on 2012/08/16 07:01 -04:00, original URI: http://blogs.msdn.com/b/michkap/archive/2012/08/16/10340297.aspx
The note from the Suggestion Box was:
Loading keyboard dlls in a 64-bit environment using a 32-bit application
Mon, Aug 13 2012 3:51 AM
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....
Please consider a donation
to keep this archive running, maintained and free of advertising.
Donate €20 or more to receive an offline copy of the whole archive including all images.
go to newer or older post, or back to index or month or day