The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

System32 directory on 64 Bit Windows

Was it a mistake for Microsoft to use the System32 directory for 64 Bit applications while redirecting 32 Bit applications to SysWow64?

I think it would have been cleaner if they had introduced a System64 directory, leaving the 32 Bit infrastructure alone.

I assume it is a bit easier to port from 32 to 64 Bits if one doesn't have to rename the path name, but it still seems unclean.

Thoughts?
Andrew Brehm Send private email
Friday, August 31, 2007
 
 
The mistake was calling it System32 in the first place. They should have been smart enough to know that we would go beyond 32 bits eventually. Heck, we will go beyond 256 bits somewhere in the not-to-distant future...
anon
Friday, August 31, 2007
 
 
Use system APIs to retrieve the system directory path - you shouldn't even care what the dir is called.
JK
Friday, August 31, 2007
 
 
1. I agree with JK.

2. With all due respect I'm sure some pretty competent engineers at Microsoft spent a long time thinking about this. I don't think either you or I can easily anticipate all the implications they had to consider.

So far I've only encountered a single situation in which I needed to explicitly select the appropriate directory. One of our PS engineers was trying to register a browser extension on Windows 2003 x64. The browser extension was 32 bit but he was trying to use the RegSvr32 in the System32 directory. Obviously it failed. I instructed him to use the one in SysWow64 and it worked.
Dan Shappir Send private email
Friday, August 31, 2007
 
 
WOW64 :) reminds me of wow32 in win95:
"Wow32.dll is required by windows and is used to call 32-Bit functions from within a 16-bit program. "
Totally Agreeing
Friday, August 31, 2007
 
 
"With all due respect I'm sure some pretty competent engineers at Microsoft spent a long time thinking about this."

Non sequitur. I didn't question the competence of the engineers.


"I don't think either you or I can easily anticipate all the implications they had to consider."

Hence my question about it in a forum.
Andrew Brehm Send private email
Saturday, September 01, 2007
 
 
"The mistake was calling it System32 in the first place. They should have been smart enough to know that we would go beyond 32 bits eventually."

It used to be called "System". They added "System32" with 32 bit Windows.

If they have to keep separate versions of DLLs around, why not keep the directory names consistent.

You could (and should) still use an API to get the locations from a program, but troubleshooting would be easier if the directory names were consistent.

If an application fails with an error message about some faulty permission in the System32 folder, I would now have to figure out if it was a 32 or 64 bit program in order to know whether it is talking about the actual System32 folder or SysWoW64.

The concept Microsoft introduced adds complexity, was unpredictable, and required underlying changes in the file system driver (automatic redirection) to work. That screams bad design, I think.

16 Bit Windows: System
32 Bit Windows: System32 (and System for 16 Bit apps)
64 Bit Windows: System64 (and System32 for 32 Bit apps)

That would have been predictable.

But

64 Bit Windows: System32 (and SysWoW64 for 32 Bit apps)

was NOT predictable, let alone the inconsistency of having the number 32 in the 64 Bit System folder and the number 64 in the 32 Bit system folder.
Andrew Brehm Send private email
Saturday, September 01, 2007
 
 
> Non sequitur

Perhaps. I probably should have written "either you or I or anybody else on this forum (unless the Microsoft engineers involved care to respond)". What I meant is that this is one of those problems for which there is no clean solution or some nice algorithm. This is one of these cases where you need to think through lots and lots of special cases and edge-conditions and pick the least of all evils. I doubt anybody on this forum is likely to put in such effort into this problem.

I tend to agree that a solution that puts the 64 bit executable into a folder called "...32" and the 32 bit executable into a folder called "...64" does not look nice. But I also tend to view the entire Wow64 infrastructure as black magic. Getting a all those 32 bit apps, mostly not written by Microsoft and often not well written, to properly work on a 64 bit OS cannot be easy.
Dan Shappir Send private email
Saturday, September 01, 2007
 
 
Perhaps WoW64 exists only because previous 64 Bit platforms were not natively backwards compatible (enough) with x86?

64 Bit Linux and Solaris seem to be able to run 32 Bit binaries without a (advertised) need for a WoW64 equivalent (although they do have 32 Bit libraries, I suppose) and Mac OS X runs 32 Bit and 64 Bit binaries side-by-side without a special subsystem.

(Closer investigation turned out that Mac OS X 10.4 runs in compatibility mode in long mode, i.e. it's a 32 Bit kernel running in 64 Bit mode, a bit like Windows 95, I suppose.)

Windows NT appears to be the only OS for which there is a specific version for 16 Bit and one for 32 Bit, with Solaris, Mac OS, and Linux it appears to be transparent.

Mac OS X running on 32 Bit Intel hardware runs in protected mode and the same kernel runs in compatibility mode on 64 Bit hardware. I assume that a 64 Bit Mac OS would come with a fat kernel containing both the current 32 Bit kernel and the new 64 Bit kernel.
Andrew Brehm Send private email
Saturday, September 01, 2007
 
 
"Heck, we will go beyond 256 bits somewhere in the not-to-distant future..."

Beyond 256-bits?  What're you planning to do, model the entire observable universe at the atomic scale?
Iago
Sunday, September 02, 2007
 
 
Based on Iago's comments from this and other posts it appears that he is a complete idiot.

256 bits does not just represent the scale by which something can be modeled. It also represents the DATA/CODE PATH SIZE THAT YOU CAN GET WITH A SINGLE INSTRUCTION. So although it is unlikely that we may want to store a number in something larger than 64bits, it is HIGHLY conceivable that we would want to process 4 such numbers at a time!

The increase in speed derived from increasing the processor bit size does not just come from the ability to process larger numbers. It comes from the ability to process much more information at once.
anon
Monday, September 03, 2007
 
 
Um, the idiot is you.  A mere widening of the data path between memory and CPU won't affect the OS architecture as long as the total address space remains the same.  Such a change should be completely transparent to software.  Hence, no need for a "System256" directory in Windows.
Chris Nahr
Tuesday, September 04, 2007
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz