I have a cmd file that runs on 32 bit Vista system.
I notice that the code has references to the system32 driver folder.
I'm wondering whether the code could potentially run on a 64 bit Windows 7 system. So I guess my question is Does a 64 bit system contain a system32 folder?
Be very grateful for any replies.
The System32 folder in 64-bit Windows actually contains the 64-bit files, and 32-bit programs running under WOW64 would generally go looking in System32 for the 32-bit DLLs etc. that they can call - but they'll find the 64-bit ones instead. Therefore the OS redirects all 32-bit applications' requests for the System32 folder to the SysWOW64 folder, which contains 32-bit system files.
System32 is the name of the folder that contains important operating system files.
Early versions of 64-bit Windows XP only ran 64-bit applications. This made sense:
And early versions of 64-bit Windows XP were 64-bit, and only supported running 64-bit applications.
And since all the folders names stay the same, you can simply recompile your application as 64-bit (and not have to change anything else - including your accidentally hard-coded paths), and it will just work.
Very quickly it became obvious that only being able to run 64-bit applications on 64-bit Windows, would prevent some people from upgrading to 64-bit Windows. So an emulation layer was created to allow you to run 32-bit applications on a 64-bit operating system.
It was called WOW64: Windows
on
Windows64
:
The problem is where should these 32-bit applications store all their 32-bit files, and configure the locations of their 32-bit DLLs, and load 32-bit operating system support files?
We already know where native applications store their stuff.
| Native Application |
|---------------------|
| C:\Windows\System32 |
| C:\Program Files |
| HKCU\Software |
This is all correct and right; if you simply recompile your 32-bit application as 64-bit: everything works. All these locations are still correct.
But now since we're going to bend-over backwards in order to accomdoate non-64 bit applications, we have to find someplace for them to have their old 32-bit OS files, and store their 32-bit data, and have their 32-bit programs, with 32-bit shared components:
| Native Application | Emulated 32-bit |
|---------------------|---------------------------|
| C:\Windows\System32 | C:\Windows\SysWOW64 |
| C:\Program Files | C:\Program Files (x86) |
| HKCU\Software | HKCU\Software\Wow6432Node |
A problem is that:
C:\Windows\System32
, it damn well better get 64-bit filesC:\Windows\System32
, it damn well better get 32-bit filesThis means that if a 32-bit process ask for some of these file locations, Windows has to transparently redirect the call to the 32-bit folders and registry keys.
If a 32-bit program, that thinks it's running on an old 32-bit operating system, asks for a 32-bit location, it needs to be given the "real" location:
| Native Application | Emulated 32-bit asks for | Is actually given |
|---------------------|---------------------------|---------------------------|
| C:\Windows\System32 | C:\Windows\System32 | C:\Windows\SysWOW64 |
| C:\Program Files | C:\Program Files | C:\Program Files (x86) |
| HKCU\Software | HKCU\Software | HKCU\Software\Wow6432Node |
If you don't want your 32-bit application to be subject to all this emulation and thunking, then the solution is obvious:
Stop creating a 32-bit application, and then complaining when the emulation layer causes you to go through emulation. Your application is the misbehaving oddball; fix it.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With