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.
Comments are closed.
Oh, that was my comment; nice to hear from you. So how about making Windows search that runs on reduced priority (doesn’t slow the rest of the system responsiveness), doesn’t take >50% of 2.4GHz processor, and opens files in non-buffered mode, to avoid that ugly file cache bloat that makes the whole system stand still while madly inpaging. I mean, runs on an XP-capable machine, reasonably. And which doesn’t make that lame “the folder is not indexed yet” excuse. If a folder is not indexed, just read the damn files. Who cares? I want to find a file, it’s here, not somewhere on internet. What would BillG say for that “not indexed” message? He would rant even longer than me. I just uninstalled it very promptly.
“I want to find a file, it’s here, not somewhere on internet.”
But the content on the internet is indexed, and thus easier and faster to find.
Do you have any idea how long it takes to find a file on your hard drive by brute force? It’s a limitation of hardware. Your hard drive can only be read so fast. Indexing it is the only way to be able to find what you want fast.
You uninstalled it? So you went back to the slow-no-matter-what grep method of searching through files? Doesn’t that defeat your entire purpose?
Also, Windows Search does run with reduced priority.
Mio,
Do an experiment. Install, for example new DDK or SDK, just a bunch of files. With Windows Search 4, try to find some word _in_ _that_ _directory_ that you know should be there, some function name. If you do it too soon, you’ll be greeted with ever friendly “Folder not indexed yet”. Is is truly impossible to do what’s requested: just run through the files and find the requested files/words, etc? It takes finite time, you know, not as fast as for an indexed directory, but still faster than getting a cup of coffee. Why Windows search should be completely orthogonal to the built-in traditional search? I want one function: Find, not “Find with index” and “Find without index”. It should just do a best effort.
And don’t get me started on those non-indexable files. If I want search in non-indexable files, *please* just do traditional search, not ignore them altogether.
Alex –
You’ve pretty much described how Windows Search already works. It already “backs off” on user activity, and takes great care in the use of I/O, memory, and processor prioritization. On Vista or later, the shell will perform a Grep search in unindexed locations. In Windows 7, we’ve done a lot of work to improve the scenario of searching locations that are only partially indexed, with items being added to the view as they’re crawled, and the location you’re viewing being prioritized in the indexing queue.
We already have two posts about the Windows Search indexer up on the Engineering Team blog, covering a lot of what you’ve asked.
http://blogs.msdn.com/e7/archive/2008/10/13/windows-desktop-search.aspx
and
http://blogs.msdn.com/e7/archive/2008/10/23/follow-up-windows-desktop-search.aspx
Brandon,
Thanks for heeding my wishes. Are those enhancements in XP version yet?
At this time we have no plans to offer new features for Windows XP. We’re very focused right now on making sure that Windows 7 offers the best search and browse experience that we can put together.
Alexandre, although I doubt you’ll see this, the answer for Windows XP is Copernic. I’ve never used Live Search 4 on XP, but it couldn’t possibly be better than Copernic, because that search is super fast.
I’m still undecided on whether it’s better than Vistas search, because I run Vista and 7 at home and XP at work.
Kevin