The wacky world of WOW64 keyoards, un-leashed, un-locked, un-something-or-other

by Michael S. Kaplan, published on 2010/05/04 07:01 -04:00, original URI: http://blogs.msdn.com/b/michkap/archive/2010/05/04/10003033.aspx

Back in the end of February, A2 asked via the Contact link:

Hi Michael.

(I already posted this message one or two months ago and can't find if you published it or if you even received it! I wanted to answer to this thread : http://blogs.msdn.com/michkap/archive/2007/01/30/1557184.aspx at the beginning. I prefer now using the contact form system. Sorry if my message bother you, I won't send it again.)

So I'm wondering how to have a WOW64 keyboard layout dll using WDK7 (if it's really needed…)

I'm on Win7 (x64 machine) with MSKLC 1.4 and WDK 7.0. I'm building Windows drivers for french keyboard layout bepo (http://bepo.fr). Here is where I am with all this. Please correct me if I'm wrong.

MSKLC 1.4 generate a .exe, three .msi and four .dll. The .exe only choose the good .msi depending of the computer architecture. Installation or uninstallation only need the good .msi (and one or two .dll for installation). For example, on x86 machines, i386.msi copy \i386\ .dll to \windows\system32\ dir (and add some lines to windows registry).

On my x64 machine, the amd64.msi requests two dlls : the one in \amd64\ is copied to \system32\ and the other in \wow64\ to \sysWOW64\. (I read above that the i386 dll was needed for sys32 dir, this is wrong, at last under win7.)

I began using kbdutool.exe to build the four .dll in order to bypass one of the MSKLC guy error (can't add underscore in AltGr+space). These dlls can be used with the MSKLC generated .exe/.msi files to have user friendly setup files (overwriting MSKLC dlls).

I started to look at the Neo2 german layout (http://www.neo-layout.org/) wich works with WDK and source files. This layout is kindly innovating (using six layers and having a compose-like deadkey) and I wanted to adapt this for our french bepo.

I can't find how to build the WOW64 dll to be able to still use older .exe/.msi :
*ia64 build environnement builds the ia64 dll;
*x64 build environnement builds the amd64 dll;
*x86 build environnement builds the i386 dll.

I don't have Itanium machine (IA64), I imagine ia64.msi from MSKLC needs at last the \ia64\ dll and probably the \wow64\ one too.

If I use the amd64 dll in wow64 dir, the installation fail. The contrary works, it seems logic.

For the moment I'm copying the amd64 dll manualy in sys32/64 dirs to have the layout working, adding the good registry entries. The problem being that I'd like to have a clean installer for lambda users.

So my questions are :
* is there a way to build the wow64 dll with WDK?
* where to look in order to have a Windows installer for my WDK dll otherwise?

Quickly, another thing I don't understand : it seems that the the file formats needed for .klc files in kbdutool.exe is different then those used by MSKLC? Do you have recommandations about that? (I must convert my .klc to little endian (perhaps something else is better) to be able to use kbdutool.exe -u).

— A2

It was Igor Levicki who figured out how to get the WOW64 version of the files built.

It is in If you just don't think you can hold it (64-bit style!), in this comment:

Well, because I hate to leave things half-finished I dug out the right way to deal with that issue during compilation :)

It is just a matter of compiling using 32-bit compiler with -DBUILD_WOW6432.

So now I have the complete solution.

He integrated it into his full page with instructions, which used to be at http://levicki.blogspot.com/2006/09/how-to-build-keyboard-layouts-for.html but now is on his new site, at http://levicki.net/articles/tips/2006/09/29/HOWTO_Build_keyboard_layouts_for_Windows_x64.php and I am glad as the full story is worth having. :-)

Anyway, as Igor determined, the WOW64 file is built with:

• the 32-bit (x86) compiler, and
• the BUILD_WOW6432 define (-DBUILD_WOW6432 from the command line)

You can look to Igor's site for the other details.

For those who want to understand the BUILD_WOW6432 issue, it is relatively simple.

Almost all of the files you will find in the SYSWOW64 directory of a 64-bit machine are actually the 32-bit files that exist on a 32-bit i386 machine.

Because just the same way that your 32-bit apps can run on 64-bit hardware, most of the system's files do as well.

HOWEVER, there are a small number of files that are 32-bit files that have to deal with 64-bit pointers because of the nature of the work they do on 64-bit systems (where those pointers have to do 64-bit thunks) that requires a different pointer size to be used for exported functions that have pointers in their parameter and/or return values.

This includes kernel32.dll, user32.dll, all of the keyboard layout DLL files, and other core system files.

Some but not all of the system files would have to be built this way for the SYSWOW64 subdirectory, but the bulk of these files are not built in the WDK or by anyone outside of the Windows team, which is why this is not documented better.

In fact in the Windows 7 RTM build, there are fewer than 200 such files out of the ~2500 files in the syswow64 directory, and almost all of those (like ~95%) are keyboard DLLs!

(If you build Windows, you can check these out in the WOW6432 subdirectory)

The actual utility of all this may be somewhat questionable given the fact that the pointers in question are really just sign-extended 32-bit pointers (as discussed in 32 bit vs. 62 bit HKLs?), but as an arcane build issue that no one really understands it is unclear whether it would be worth doing anything different about, in the long run. I suspect there are a few oldtimers who might be able to explain why this makes the whole thing easier....

During Vista, it certainly caused me (as the dev owner of the keyboard layout DLLs) some interesting extra work as the problem of building setup manifests to handle these files was very complicated since the new setup didn't really support the idea at first and the ways that various experts instructed me to author the files tended to break the validation scripts that the same team kept building to improve setup quality. Thank goodness for Perl scripts is all I'm going to say!

Gerardo on the test team was the person to find out directly how the first two of the five setup manifest iteratons (authored by the instructions of the setup team) actually led to the wrong versions of keyboard layout files being put in the SYSWOW64 directory of 64-bit machines. Though those manifests were the only ones that never failed validation routines like te next two versions that did. Kind of ironic that only the invalid manifests were validaing properly (as the valid manifests kept failing validation), huh?

As a bizarre final twist, after Vista shipped and shortly after I changed teams, yet another set of setup manifest validation tools declared all of the keyboard manifests were incorrecrly authored (and CompCentral declared me to be the owner of these many wayward binaries), but at that point the work had been transitioned to someone else so I gaqve the bugs to them with instructions and avoided having to do the work yet again.

Igor may be the first non-internal Microsoft person to ever figure it out. Internally most don't figure it out either, they just build the files using scripts written ages ago and never pay attention to the details. I certainly never knew about it until doing the 64-bit work for MSKLC 1.4, despite having built the keyboards hundreds of times and kernel32.dll thousands of times; when I finally did it, it was by reverse engineering the keyboard layout DLLs being built by Windows....

I believe that covers most of the question, though a few more bits to add:

I suppose IA64 is not really so important anymore. I won't say anything else on this subject, other than to (not for nothing) mention that if software tech companies were run entirely by women there are certain types of strategies that probably would never happen. Intel's IA64 plan is one of them and the Compaq plan for Alpha 64 and Alpha 32 are two others, in my opinion. I won't explain further; either you understand what I mean or you don't (and if you don't you might be offended once you do; if you do then you may agree!). So I'll just leave it there.

Microsoft does not, AFAIK, document any way to get the keyboard layout DLLs running other than MSKLC. Though obviously there are WDK samples for the DLLs, there is real dearth of info on how to get them installed on systems. The setup MSKLC creates takes care of all of the details, and I highly recommend taking that approach for building setups.

The files MSKLC creates are the very ones it passes to kbdutool.exe itself for building. It should already be little endian Unicode, for example. Not sure what kind of errors are being hit, but if MSKLC and kbdutool were not compatible then (looking at the latest download statistics) there would be up to half a million unhappy keyboard authors out there! So I am not sure what problems were appening but there shouldn't be.

Hopefully that takes care of all the issues for A2, if not then let me know; I'm around. :-)

# Yuhong Bao on 4 May 2010 12:01 PM:

# Michael S. Kaplan on 4 May 2010 4:35 PM:

# Yuhong Bao on 4 May 2010 10:35 PM:

# Michael S. Kaplan on 5 May 2010 12:06 AM:

# Random832 on 6 May 2010 6:11 AM:

# Michael S. Kaplan on 6 May 2010 6:34 AM:

referenced by

go to newer or older post, or back to index or month or day