Originally posted by: Absolution75
Eh, does this matter to anyone besides developers? No.
SysWOW is obviously System WOW which is synonymous with emulation. It isn't really backwards. As far as the System32 directory, its obviously not renamed to preserve compatibility with old programs.
Program Files x86 is obviously 32bit programs and Program Files is obviously native 64bit programs. I can't see how this is relevant regardless.
I can tell you don't know very much about how software is developed.
No, it really doesn't matter to anyone else, but as a developer I see it as being really silly and a pointless hack.
I don't know how you can see that as not backwards, the directory labeled with the number 64 contains 32 bit libraries and the one labeled 32 has 64 bit libraries. That's pretty much a textbook example of backwards from what one could logically expect.
The compatibility argument doesn't hold water either, since to use those 64 bit libraries a program would have to be recompiled for 64 bit, so no old applications which would need backwards compatibility tricks can ever use it. They also do remapping on all legacy applications, so a 32 bit application sees the contents of the SysWOW64 directory if it requests System32. I don't see any logical reason they bothered with a backwards naming scheme and remapping when it would have been simpler and more sane to just keep System32 where it is and call the new one something like System64. If you look back at the Windows 95 transition that's obviously what they did there, System contained 16 bit libraries, System32 was 32 bit. I think that may also stretch in to the old NT codebase, but I'm unfamiliar with NT before Windows 2000 so I won't speculate.
Separating the different Program Files directories is also a hack that I do not see a reason for. Why should my applications live in different places (once again using remapping so 32 bit applications see "Program Files (x86)" as "Program Files") when the OS knows what they are and doesn't care in the long run? My Linux and Mac boxes don't do this, why does Windows.
Again I also only chose the examples that are obvious and known to anyone who's gone digging around even slightly in a 64 bit Windows system. The AppleInsider articles I linked plus a number of other sources describe other strange decisions in the 64 bit Windows development process and implementation that to me just make it clear Microsoft never planned on having Windows run on 64 bit desktops.
Hint: The first public release of ANY 64 bit Windows was the OEM-only Windows 2000 for Itanium, available in Advanced Server and Datacenter Server licensing levels, released August 2001 (processors had been shipping since June of that year). It took them until April of 2005 to release XP and Server 2003 for x86-64 (processors had been shipping for two years). By comparison, Linux supported both of those chips before any silicon was publicly available, as well as a number of other 64 bit platforms in the past.
As a daily user of 64 bit versions of both Vista and Windows 7, it's clear that it's been implemented in the traditional Windows way of just piling stuff on until it works. Please don't make assumptions about my knowledge of how software is developed. I write code every day for all three platforms and regularly read a number of the MSDN blogs, so I know why some of the things done in Windows that seem silly on the surface were done, but these particular examples I have never seen a decent explanation for.
Originally posted by: WaitingForNehalem
No, your precious mac file system is full of symbolic links since it still uses the Unix file system.
Mac OS X aliases and symbolic links
OMG REALLY!?!?!? </sarcasm>
So? Symlinks are a well known and well defined filesystem feature that have been around longer than I have. They work, what's wrong with them? Why reinvent the wheel with shortcuts, aliases, etc. when symlinks are available?