Check out the the article: “How 64-bit version of Windows differs architecturally from 32-bit version”
The summary from the article:
Sometimes understanding the underlying architecture of a system is critical to being able to work with that system safely and effectively. The x64 version of Windows is a perfect example of this.
Windows XP and Windows Server 2003 are both available in 64-bit versions which are designed to run on x64 hardware. These x64 Windows operating systems run 64-bit code natively but can also run 32-bit code through the use of an integrated emulator called Windows on Windows 64 (WOW64).
No big deal, you say. After all, the 32-bit versions of the various Windows operating systems are designed to run both 32-bit and 16-bit code simultaneously. (Technically, it’s not truly running simultaneously, but explaining how the multitasking engine handles 16-bit code is for another tip).
The point is that 32-bit versions of Windows have a complicated mechanism in place to allow 32- and 16-bit code to run side by side. Still, the system is designed so that whether you’re a systems administrator or a casual user, you don’t need to know how these mechanisms work.
But 64-bit versions of Windows are different. From a user’s standpoint, 64-bit applications simply run side by side with 32-bit applications; nothing special is going on. But for administrators (and members of the help desk), it’s a different story: The 32-bit code must be kept isolated from 64-bit code. This isolation is so important that x64 versions of Windows have two registries, one for 64-bit code and one for 32-bit code.
Even though the 64-bit versions of Windows XP and Windows Server 2003 look and act almost identical to their 32-bit counterparts, below the surface there are major differences. If you perform certain tweaks on a 64-bit version of Windows in the same way you did in the 32-bit version, you could cause some problems.
The first rule of 64-bit applications is this: You absolutely cannot mix 32- and 64-bit code in a single application. If you have a 64-bit application, everything related to that application, including the DLL files, must be 64-bit. This presents an interesting challenge because sometimes multiple applications will rely on a common DLL file. Fortunately, Windows keeps 32-bit DLL files separate from 64-bit DLL files.
If you look in the \Windows folder on any 32-bit system, you’ll see two subdirectories: one named SYSTEM and one named SYSTEM32. The SYSTEM subdirectory is a leftover from Windows 3.x that has remained in Windows for the purpose of maintaining backward compatibility with older applications. Generally speaking, 16-bit DLL files (and other support files) are placed in the \Windows\System folder; 32-bit DLLs and various support files are placed in the \Windows\System32 folder.
The way that 32-bit versions of Windows maintain the separation between 16- and 32-bit DLLs is fairly straightforward. The way that 64-bit versions of Windows keep 64-bit and 32-bit DLL files separate is not.
Logically, Microsoft should have created a folder named \Windows\System64 and used it for 64-bit DLL files. Instead, Microsoft created a new folder named SysWOW64 for storing the 32-bit DLLs. At first glace, this makes sense when you consider that WOW64 is the name of the emulator that runs 32-bit applications. But keep in mind that 32-bit applications are designed to place their DLL files in the \Windows\System32 folder.
The \Windows\System32 folder still exists in the x64 version of Windows. But Microsoft uses this folder as a repository for 64-bit DLLs, not 32-bit DLLs. I don’t understand Microsoft’s reasoning for using the \Windows\System32 folder for 64-bit DLLs, but I’ve heard it has to do with backward compatibility.
So what about all those 32-bit applications that are designed to store their DLL files in the \Windows\System32 folder? This is where things get confusing.
As I mentioned earlier, 32-bit code can not run natively through the X64 version of Windows. In order to run 32-bit applications, Windows makes use of the WOW64 emulator, which makes the apps think they are running on a 32-bit version of Windows.
When you install a 32-bit application, that installation wizard is running within the WOW64 emulator. Remember: 32-bit and 64-bit code don’t mix. Once an application (including a Setup wizard) launches from within the WOW64 emulator, it must continue to run within WOW64. This means that when you install an application, the Setup wizard has no idea that the app is being installed on a 64-bit version of Windows, and will write DLL files to the \Windows\System32 folder just as if it were running in a 32-bit operating system.
Of course, WOW64 knows that the Setup wizard is a 32-bit application running within an emulator. It also knows that 64- and 32-bit code cannot be mixed. As such, the WOW64 emulator aliases an alias to the \Windows\SysWOW64 folder. This means that any time a 32-bit application needs to read or write anything to or from the \Windows\System32 folder, the WOW64 emulator transparently redirects the request to the \Windows\SysWOW64 folder.
All of this means that if you were to manually manipulate the contents of the \Windows\System32 folder, you could be in for some nasty surprises. I recently read about an administrator who needed to install a couple of small support scripts for an existing application. The instructions that came with the scripts said they should be placed in the \Windows\System32 folder. Of course those instructions assumed that the application would be running on a 32-bit system.
The scripts didn’t cause the system to crash. Instead Windows gave the illusion that the update had never been applied. When the admin ran the application, it was transparently being redirected to the \Windows\SysWOW64 folder. The admin knew he had placed the scripts into the \Windows\System32 folder and could see the scripts from Windows Explorer, but could not figure out why the application could not see the scripts. Thinking the issue was permissions-related, he spent a lot of time chasing his tail. Had he known about the way the x64 versions of Windows keep DLLs separated, he could have just placed the scripts into the \Windows\SysWOW64 folder. They would have worked as anticipated.
The x64 versions of Windows represent one of the few cases in which it is truly important for an admin to understand the underlying system architecture. My next article iwill discuss differences in the ways that Windows maintains 64- and 32-bit program files.