Question about 64-bit Windows and SysWOW64

[archcommus]

So I understand that the system32 directory in 64-bit Windows confusingly holds 64-bit DLLs and not 32-bit DLLs for backward compatibility and legacy reasons, like software that is hardcoded to use that folder. But, it then redirects requests for 32-bit DLLs to the SysWOW64 folder.

My question is, if it's able to do that, couldn't it have just as easily redirected 64-bit DLL requests to a system64 folder, and just leave 32-bit stuff in system32 and keep things simple? I don't know why this wouldn't work considering they are able to redirect 32-bit requests to another folder.

Just curious, thanks.

 

[ViRGE]

Microsoft deemed it to be easier to keep system32 as the main system folder, so that poorly coded 64bit applications that have their system directory hardcoded as system32 (often as a case of porting a 32bit app to 64bit) would still end up in the right directory. Otherwise if a 64bit app requests system32, does it mean it really wants the 64bit system directory, or is it installing some 32bit libraries? Meanwhile redirecting 32bit apps to use SysWoW64 was rather easy because WoW was already redirecting other things; that would be far easier than needing another service to redirect 64bit applications.

It's really not a great solution in any way, but since it was deemed to make fewer things break, MS went for it anyhow.

 

[Aberforth]

SysWOW64 is basically a backend for 32bit applications running on Windows 64bit. A 32bit app cannot use a 64bit DLL, a true 64bit app pulls API from System32. Like for example, in Vista 64bit there are native 64bit apps like Windows Media Player but it doesn't use 64bit version until you configure it, I am sure this done because of compatibility issues. Similarly many apps doesn't use 64bit even though they support it, like there are two versions of jscript.dll - 32bit version is in SysWOW64, so since some apps use 32bit jscript.dll (like Adobe Installer)- you ought to register 32bit Jscript.dll rather than 64bit, because you can use only one at a time. Anyway I know this is a bit confusing, future versions of Windows might use virtualization to resolve issues- even at a device driver level which brings process isolation a and a repository for dependencies.

 

[Aberforth]

http://en.wikipedia.org/wiki/WOW64

 

[VirtualLarry]

Originally posted by: ViRGE
Microsoft deemed it to be easier to keep system32 as the main system folder, so that poorly coded 64bit applications that have their system directory hardcoded as system32 (often as a case of porting a 32bit app to 64bit) would still end up in the right directory.

That's absolutely the dumbest thing that I've ever heard.

If they are doing a port to 64-bit, they probably need to change some code, so why not change a few definitions of where the system directory lies. Anyways, aren't apps supposed to query a registry key for the location of the system directory?

 

[ViRGE]

Originally posted by: VirtualLarry

Originally posted by: ViRGE
Microsoft deemed it to be easier to keep system32 as the main system folder, so that poorly coded 64bit applications that have their system directory hardcoded as system32 (often as a case of porting a 32bit app to 64bit) would still end up in the right directory.

That's absolutely the dumbest thing that I've ever heard.

If they are doing a port to 64-bit, they probably need to change some code, so why not change a few definitions of where the system directory lies. Anyways, aren't apps supposed to query a registry key for the location of the system directory?

Of course, but when a certain percentage of developers are idiots and there are x^(big number) Windows developers, you end up with a lot of idiots that need to be dealt with.

 

[archcommus]

Originally posted by: ViRGE
Microsoft deemed it to be easier to keep system32 as the main system folder, so that poorly coded 64bit applications that have their system directory hardcoded as system32 (often as a case of porting a 32bit app to 64bit) would still end up in the right directory. Otherwise if a 64bit app requests system32, does it mean it really wants the 64bit system directory, or is it installing some 32bit libraries? Meanwhile redirecting 32bit apps to use SysWoW64 was rather easy because WoW was already redirecting other things; that would be far easier than needing another service to redirect 64bit applications.

It's really not a great solution in any way, but since it was deemed to make fewer things break, MS went for it anyhow.

Good point, you know if a 32-bit app is requesting DLLs they are 32-bit and can safely be redirected to SysWOW64, but you do not know if a 64-bit app is trying to get some 32-bit access or normal 64-bit libraries, I guess. I suppose this was just the easiest way to redirect.