64-bit thoughts, and an apology

by Michael S. Kaplan, published on 2006/06/17 03:01 -04:00, original URI: http://blogs.msdn.com/b/michkap/archive/2006/06/17/634936.aspx


64-bit is becoming more and more popular.

This I know because not a week goes by that I do not get either an email or a contact link request for information about when the 64-bit version of MSKLC will be available, despite the fact that there are four posts about it already! :-)

(Even not having children, I can see the humor in the whole 'Are we there yet?' aspects of this!)

I promise the answer to that has not changed -- the importance of 64-bit is a known thing and no one who is doing the feature planning for the next version of MSKLC is unaware of this issue.

But that is not what this post is really about.

This post is about an apology, from me to all of my readers who are developers working in the internationalization space.

About ten months ago, I posted Mitigation tools for IDN security problems here and talked about all of the cool work that went into the Microsoft Internationalized Domain Names (IDN) Mitigation APIs 1.0. And I still believe it is very cool, between all of the things the new functions do and the downlevel normalization support.

But I did not actually install the package; if I had I would have been posting a little more information here that I think is important to communicate to developers....

You see, the download page allows you to install MSIdnAPIsMP.EXE, which when run will create a folder with x32, x64, and ia64 subdirectories (each of which contains the files you would install into the %windir%\System32 directory on the x86, AMD64/ENT64, and IA64 target machines, respectively), and some helpful documentation on using the tools in the readme file.

However, what the documentation did not mention, and what I would have  (had I installed the package and read the readme file!) is how to handle using the tools from 32-bit applications when running on the 64-bit operating systems.

As I pointed out when I asked Why do we park on a driveway, and drive on a parkway?, the special system directory where all of the 32-bit files go on a 64-bit system is actually %windir%\SysWOW64 (though folder redirection makes it look like it is %windir%\System32 to 32-bit programs). So if you want to use the package from 32-bit programs on a 64-bit platform, you have to be sure to place the files in the x32 subdirectory into %windir%\SysWOW64 on the target machine.

A 32-bit program can just place them into %windir%\System32 and let folder redirection put them in the right place, but of course a complex program with both 32-bit and 64-bit components would need to place both sets of files into the appropriate places....

Now of course this may be something you already knew, or you may not have been affected due to the careful way that the redirection happens. Or maybe you don't even use the tools at all. But just in case, I figure it is better to mention the issue than it is to not mention it.

Again, I am sorry about that.

If it of any redeeming value at all, I'll point out that I had indeed tried the functions (in both downlevel and Vista versions!). But even so, I should not have talked about how cool the download was without trying it out to see what else I should have mentioned to be sure that the cool factor would be maintained no matter what.

And the tools are still very cool, either way....

 

This post brought to you by "а" (U+0430, a.k.a. CYRILLIC SMALL LETTER A)


# Dean Harding on 18 Jun 2006 9:43 PM:

Yeah, that's true of any x86/x64 DLLs.

The funny thing is, I don't know why System32 is still called System32, even though it's full of 64-bit DLLs. Why didn't they just keep System32 for 32-bit DLLs and add a new System64 for 64-bit DLLs?

It just seems strange that 32-bit DLLs got into SysWOW64 and 64-bit DLLs go into System32...

Anyway, I guess it doesn't matter. Eventually, everything will be 64-bit and the fact that the "system" directory has "32" on the end will just be an amusing story for Raymond to put in his blog ("Once upon a time, Windows was available on 32-bit platforms...")

# md on 19 Jun 2006 1:13 AM:

The funny thing is, I don't know why System32 is still called System32, even though it's full of 64-bit DLLs.

Backwards compatability.  Imagine, as one example, all those batch files which use something like %windir%\system32 thinking there are system binaries in there they might reference.  Change that to system64 and migration to 64 bit becomes a lot more expensive for people with legacy code.

# Vladimir on 26 Jun 2006 9:34 PM:

1. What do you think is the hardest part in implementing MSKLC that can spit out x64 compatible keyboard DLL?

2. Do you have a link to page where the keyboard DLL APIs are defined.  I was able to find kbd.h, but no such luck with the DDK documentation for it.

Thank you,

Vladimir

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.

referenced by

2006/08/10 Why are there MODIFIER LETTERS that are not in the Letter, Modifier category?

2006/07/16 Nobody likes change

2006/07/16 Update to the mitigation tools for IDN security problems

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