System32 Folder on a 64-bit system

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开发者_如何学JAVA 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.

Windows has a technology called WoW 64 (Windows-on-Windows 64-bit) that allows 32-bit applications (even compiled ones written in C/C++, etc.) to run on 64-bit Windows.

In addition to the System32 folder, a 64-bit Windows installation has a SysWow64 folder that has 32-bit versions of the files that you'll find in System32.

To be clear, references to System32 get redirected when running from a 32-bit process (unless the process disables this redirection, which is possible). As a result, if you have a .CMD file that references System32, it's actually going to read from the SysWow64 directory.

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:

• you run 16-bit applications on 16-bit Windows
• you run 32-bit applications on 32-bit Windows
• you run 64-bit applications on 64-bit Windows

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.

Emulate 32-bit OS on 64-bit Windows

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:

• This emulation layer simulates the x86 architecture, virtualizing the CPU, the file system, the registry, the environment variables, the system information functions, all that stuff.
• If a 32-bit program tries to look at the system, it will see a 32-bit system.
• For example, if the program calls the GetSystemInfo function to see what processor is running, it will be told that it's running on a 32-bit processor, with a 32-bit address space, in a world with a 32-bit sky and 32-bit birds in the 32-bit trees.
• And that's the point of the emulation: To keep the 32-bit program happy by simulating a 32-bit execution environment.

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.

32-bit in a 64-bit world

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:

• if a 64-bit program asks for C:\Windows\System32, it damn well better get 64-bit files
• if a 32-bit program asks for C:\Windows\System32, it damn well better get 32-bit files

This 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:

• create a 64-bit application for a 64-bit operating system

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.

Windows 7 64 bit has a System32 folder.

Whether your file will still run, however, is a more complex problem. It might, and depends entirely on what it relies on; if it's relying on drivers in the wrong way, it will fail as 32 bit drivers just don't work on 64 bit systems.