Why does Windows put 64-bit binaries in System32?
Raymond Chen recently wrote about the WOW64 system that Windows uses to virtualize file system and registry access for 32-bit applications running on a 64-bit version of the OS. In the comments, some began discussing the fact that Windows puts 64-bit binaries in the “System32” directory, and puts the 32-bit versions in a directory called “SysWow64” to which 32-bit applications get redirected. It does seem odd, I’ll grant you that.
One commentor wrote:
“Maybe it’s finally time for MS to stop catering to bad ignorant developers that skip on reading the documentation? I suppose that’s what big A did.”
This, of course, is making an assumption that the design had anything to do with ignorant developers or developers not following some documentation.
But think about it… exactly which documentation would they not be following? I mean, if a developer built a 32-bit application that hardcoded windows\system32 – then clearly they wouldn’t have a problem if the 32-bit binaries were left in that directory. Their 32-bit application would continue to find the binaries its looking for just as before. On the other hand, if they’re going through the trouble to recompile their application for 64-bit, they could probably handle fixing that little issue along the way, right?
So it stands to reason that the decision was made on a different basis. Let’s see, if it wasn’t to support existing 32-bit apps, and it wasn’t for apps that are recompiled as 64-bit, then who would this arrangement benefit?
Well, I wasn’t around when WOW64 came about, but I have a theory. There’s another little kind of “program” out there that isn’t really 32-bit or 64-bit, in fact is isn’t even compiled at all. They aren’t sold on store shelves, but there are millions of them, often vital to the businesses and developers who use them.
They’re called scripts, and the chosen WOW64 model keeps most of them chugging along quite happily.