Hello again :)
Don't worry about posting multiple times in a row. In actual fact I prefer it, as then I get a notification of your new post vs. no notification for an edit.
As promised, a little talk on redirection. First, let's discuss file system redirection. We will come onto registry later. If you don't understand any part of this, feel completely free to ask me about it. Also, I do not know what you do and do not know, so I have included pretty much everything. It will also help future readers.
System32 vs. SysWOW64 vs. Sysnative
Finally, although you may already know this, I would like to briefly talk about these folders. All three of them exist on a 64bit computer under %SystemRoot% (C:\Windows)(although you will not be able to find Sysnative using explorer.exe), however, only System32 exists on a 32bit computer.
The names of these folder are slightly counterintuitive, however, it is done for compatibility reasons with old programs.
On a 32bit computer, everything is nice and simple. There is only one set of Windows files, and they are compiled for a 32bit architecture. They are stored under winsxs with the prefix x86_ and the active version of each file is linked into the System32 folder.
On a 64bit computer, everything is not quite so nice and simple. First, Microsoft realised that many programs had hardcoded the path C:\Windows\System32 rather than using some form of expansion variable such as an environmental variable. This meant that they couldn't just move everything to System64, as then all those old programs would break. The System32 name had to stick, or at least be redirected.
But there is another difficulty. Microsoft also wished for legacy 32bit programs to still work on the 64bit architecture. To achieve this, they implemented something called WOW64. Now all of a sudden, two sets of each Windows file exists: the 64bit files (winsxs prefix of amd64_) and the 32bit files (winsxs prefix of wow64_ [or occasionally x86_ - technicality]).
The next point of note is the wow64 files. Contrary to much of the misinformation currently available on the internet, these 32bit copies of the files do not actually contain full sets of the code. In fact, they are merely redirection shells. When a legacy 32bit application makes a call to a Windows .dll, it is sent a reference to the 32bit copy of the .dll file. However, this 32bit copy of the .dll does not actually process the call. Instead, it converts all of the 32bit data types from the 32bit application to 64bit, calls the 64bit copy of the .dll with this converted data which does the actual processing, and then takes the returned 64bit datatypes from the 64bit .dll, converts them back to 32bit before returning them to the application as though the 64bit .dll had never been invoked. This is what is actually going on.
So where are the active versions of these wow64 files linked? Well, they're linked in a new folder called SysWOW64. And then the truly 64bit copies of the files are stored in the System32 folder to maintain compatibility with legacy applications for the reasons already given. But this leads to another problem: what happens if a 32bit legacy application directly calls C:\Windows\System32\example.dll? Well then it gets sent a 64bit .dll file, which won't work. So to solve this, 32bit applications which directly call System32 get silently redirected to the 32bit copy in SysWOW64.
But this doesn't completely solve the problem. What if a 32bit application explicitly wants to access the 64bit copy of the file directly? Well, Microsoft have provided several different solutions to this problem any one of which can be used, but perhaps the simplest is the virtual Sysnative folder. This folder isn't real. It doesn't contain anything, it's just a link to another folder. And for 32bit applications, it links to the 64bit System32. So Sysnative may be used to bypass normal System32 direction and actually get access to System32. This is why you won't be able to find this folder in explorer.exe: it doesn't really exist. But there's another reason too. This sort of redirection doesn't make sense in 64bit. 64bit applications can already access the 64bit copies of the files through System32, and they can access the 32bit copies of the files through SysWOW64. So there's no need for Sysnative, so Sysnative doesn't work in 64bit applications.
Wow, that's long and confusing. What about a nice summary?
In summary:
System32 holds 32bit copies of files on 32bit computers, and 64bit copies of files on a 64bit computer.
SysWOW64 holds wow64/32bit copies of files on a 64bit computer, and doesn't exist on a 32bit computer.
Sysnative is a virtual redirection directory which doesn't exist except under legacy 32bit applications on a 64bit computer.
32bit application on 32bit computer:
System32 --> no redirection --> System32
SysWOW64 --> doesn't exist
Sysnative --> doesn't exist
64bit application on 64bit computer:
System32 --> no redirection --> System32
SysWOW64 --> no redirection --> SysWOW64
Sysnative --> doesn't exist
32bit application on 64bit computer:
System32 --> redirection --> SysWOW64
SysWOW64 --> no redirection --> SysWOW64
Sysnative --> redirection --> System32
So, hopefully you understand a little more about the System32, SysWOW64, and Sysnative folders, and why they were created as they are.
So, now let's say you want to access C:\Windows\System32\example.dll (no redirection, actually in System32).
On a 32bit computer, it's very simple: Just access C:\Windows\System32\example.dll. On a 64bit app on a 64bit computer, again just access C:\Windows\System32\example.dll. But on a 32bit app on a 64bit computer, you must access C:\Windows\Sysnative\example.dll.
So, if you are writing a permanently 32bit app, and you want to access the real C:\Windows\System32\example.dll, you must first check whether the system is 32bit or 64bit. If it is 32bit, you directly access C:\Windows\System32\example.dll, and if it's 64bit you change the request and access C:\Windows\Sysnative\example.dll.
What about the registry? Well, a very similar thing occurs. This time, if you want to access the other architecture of a registry value you have a magical registry key called Wow6432Node. But things are a little different this time.
The 64bit copy of the key on 64bit OS or 32bit copy of the key on 32bit OS is stored where it should be, e.g. HKEY_LOCAL_MACHINE\Software. However, for 64bit OS, the 32bit copy of the key is stored at HKEY_LOCAL_MACHINE\Software\Wow6432Node.
Normally, a 32bit app on a 64bit computer which tries to access HKEY_LOCAL_MACHINE\Software is silently redirected to HKEY_LOCAL_MACHINE\Software\Wow6432Node. A 64bit app on a 64bit computer can access either HKEY_LOCAL_MACHINE\Software or HKEY_LOCAL_MACHINE\Wow6432Node directly, with no redirection. But there's a problem. What about 32bit app on 64bit computer accessing 64bit key? There's no second magic key for that. Hmmmmm... This situation is a bit like having System32 and SysWOW64, but no Sysnative. Big hmmmmmm.
Fortunately, there's a solution. We can ask Windows not to redirect us. You can use (in C#) RegistryKey.OpenBaseKey with HKEY_LOCAL_MACHINE\Software, and with view (RegistryView Enumeration (Microsoft.Win32)) set to either Registry32 or Registry64 to access exactly what you want.
And in C++ (and I assume via P/Invoke C# also), for those few exceptionally rare times when you cannot ask Windows not to redirect you, can you globally and temporarily disable redirection entirely using Wow64DisableWow64FsRedirection function (Windows) and Wow64RevertWow64FsRedirection function (Windows).
You should not need to use these.
There is only one scenario I know of where all of these techniques fail, and that involves a very specific and extremely complex operation on the Volume Shadow Copy Service, where you simply have to drop a 64bit exe on the 64bit computer, and run that.
I hope this helps, but suspect it will only confuse further
Richard
Has Sysnative Forums helped you? Please consider donating to help us support the site!
