Pointless Question, System32 folder?

[Stead]

Hrmm, i know this is a bit pointless, but i've wondered since the first time i've seen xp64 why isn't there a system64 folder, now, i haven't checked, and i do not know for sure (just felt like asking and i thought since its a friendly forum, someone may want to answer..and i will have a look on google now..) but i always assumed system32 appeared as windows was 32bit, and the system folder was for 16bit programs...(is that even right?) so how come theres no system64 folder, for the 64bit stuff, and the system32 for compatability with older programs, would it be such an issue if only 64bit stuff went into a sytem64 folder?

anywho, going to search google now (i know i have too much time! but ... its one of those annoying questions)

*edit*

well, anywho, i feel silly now, but (if anyone is curious) the SysWOW64 is actually the system32 folder, and the system32 folder is actually the system64 folder, i haven't looked through much, but i noticed one file (i noticed the icon to be honest..) ati2saag.exe is in both folders...but what seems even odder? its also the same file in both, so now i'm totally confused about the whole thing, i'm sure it makes lots of sence to lots of people tho, at least i know why xp64 needs so much space!

Edited March 9, 2006 by Stead

[r3incarnat0r]

I'm not sure, but I think that Windows XP Professional x64 is based on Windows XP Professional (32-bit), only recompiled to 64-bit (and with many modifications of course). It is the imho similar reason, why for example kernel32.dll is not renamed to kernel64.dll. 32-bit applications could not work because of its dependency on *32.* files. And if both *32.* and *64.* files would coexist in Windows, installation files probably would not fit onto CD. (Only my opinion.)

[prathapml]

Hi,

this is not pointless at all! I fully agree with the first post. Here's a quote from one of my old posts:

Thats partly been one of my irritants with win64 - try as much as I might (i mean programmatically, not manually), 32-bit executables are relegated to SysWOW64, & only 64-bit ones are allowed in System32.... Now I wonder, how intelligent it was of MS, to make a directory named System32 the native 64-bit folder.

post

[Aegis]

I believe the folder is named System32 for compatibility reasons. If they changed it to System64, then they'd have to replace all instances of the string System32 in the Windows source code with System64. So partly, it's because of the role System32 plays in the NT family OS's that forced Microsoft to keep the name.

[Delprat]

I believe the folder is named System32 for compatibility reasons. If they changed it to System64, then they'd have to replace all instances of the string System32 in the Windows source code with System64. So partly, it's because of the role System32 plays in the NT family OS's that forced Microsoft to keep the name.

Well, you forgot that this this folder was named "system32" because NT became 32-bit

(and the 16-bit "system" directory is still here)

It was 10 years ago... Now MS cannot do the same, not because of "compatibility", but because of people that would blame they for breaking compatibility

But, as r3incarnat0r says, Windows x64 is not a 64-bit OS ; it's a "64-bit Windows on 32-bit Windows" (WOW)

[LLXX]

Still, it would make more sense if M$ put the 64-bit components in a system64 folder, and have new names for them like kernel64.dll, gdi64.dll, etc. Then compatibility files like kernel32.dll could remain in the system32 folder, and less confusion would result.

[r3incarnat0r]

Still, it would make more sense if M$ put the 64-bit components in a system64 folder, and have new names for them like kernel64.dll, gdi64.dll, etc. Then compatibility files like kernel32.dll could remain in the system32 folder, and less confusion would result.

I still maintain the opinion I have already written:

... blah blah... And if both *32.* and *64.* files would coexist in Windows, installation files probably would not fit onto CD.

Also I'm sure that more files equals more problems. For example - M$ would have to release more hotfixes , registry would be much bigger (and system much slower) because of libraries which must be "registered", etc...

[Stead]

i thought there was already 32 and 64bit versions of all the installed files ?

[cluberti]

But, as r3incarnat0r says, Windows x64 is not a 64-bit OS ; it's a "64-bit Windows on 32-bit Windows" (WOW)

That's the biggest load of BS I've ever heard. Windows XP x64 is indeed a 64bit OS, and all system binaries running the OS are 64bit. There are 32bit binaries on the system for compatibility (IE 32bit, for example), but the OS is a 64bit OS - otherwise it wouldn't be able to address memory over the 4GB boundary.

The WOW 64 (Windows on Windows 64) foundation is just the opposite of what you think - it exists for running 32bit applications on 64bit Windows, not the other way around.

I'm not sure, but I think that Windows XP Professional x64 is based on Windows XP Professional (32-bit), only recompiled to 64-bit (and with many modifications of course). It is the imho similar reason, why for example kernel32.dll is not renamed to kernel64.dll. 32-bit applications could not work because of its dependency on *32.* files. And if both *32.* and *64.* files would coexist in Windows, installation files probably would not fit onto CD. (Only my opinion.)

Windows XP x64 is not based on Windows XP 32bit, it's based on Windows Server 2003 SP1 (notice file versions are 5.2.3790.xxxx, not 5.1.2600.xxxx). It's been rebuilt/recompiled as 64bit, yes, but not from XP 32bit. I'm not entirely certain about renaming files from ...32.dll to ...64.dll, but I'm fairly confident that this is for API compatibility reasons.

[r3incarnat0r]

But, as r3incarnat0r says, Windows x64 is not a 64-bit OS ; it's a "64-bit Windows on 32-bit Windows" (WOW)

I didn't say that Windows x64 is not a 64-bit OS.

I'm not sure, but I think that Windows XP Professional x64 is based on Windows XP Professional (32-bit), only recompiled to 64-bit (and with many modifications of course). It is the imho similar reason, why for example kernel32.dll is not renamed to kernel64.dll. 32-bit applications could not work because of its dependency on *32.* files. And if both *32.* and *64.* files would coexist in Windows, installation files probably would not fit onto CD. (Only my opinion.)

Windows XP x64 is not based on Windows XP 32bit, it's based on Windows Server 2003 SP1 (notice file versions are 5.2.3790.xxxx, not 5.1.2600.xxxx). It's been rebuilt/recompiled as 64bit, yes, but not from XP 32bit. I'm not entirely certain about renaming files from ...32.dll to ...64.dll, but I'm fairly confident that this is for API compatibility reasons.

OK, I confess I only guessed... Now I can see.