CODEWITHSUNDEEP
64-bitcmd
hmmlee
hmmlee

Reputation: 91

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 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.

Upvotes: 9

Views: 36805

Answers (4)

Ian Boyd
Ian Boyd

Reputation: 256581

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.

Upvotes: 2

user2048753
user2048753

Reputation:

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.

Upvotes: 7

Rook
Rook

Reputation: 62528

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.

Upvotes: 14

me_and
me_and

Reputation: 15634

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.

Upvotes: 0

Related Questions