When working with the 64-bit flavor of Windows, there are a couple of quirks that you just need to accept. First, when Microsoft designed windows for 64 bit processing, they weren’t going to break legacy applications and second, how this gets done makes absolutely no sense unless you simply have faith that the Operating System will take care of it all for you.
So why doesn’t it make sense? Well, Windows 64-bit systems are essentially operating systems with two minds. One the one hand, you have the system designed to run 64-bit processes, but lives within an ecosystem where nearly all windows applications are still designed for 32-bit systems. So what is an OS designer to do? Well, you have both versions of the OS running, obviously. Really, it’s not that simple (or complex) — in reality, Microsoft has a 32 bit emulator that allows all 32 bit applications to run on 64-bit versions of Windows. However, this is where it gets complicated. Since 64 bit processes cannot access 32 bit processes and vise versa — you run into a scenerio where Windows must mirror a number of systems components for both 32 and 64 bit processes. They do this two ways:
- In the registry — Microsoft has what I like to think of as a shadow registry that exists for WOW64 bit processes (that’s the 32 bit emulator if you can’t tell) — to register COM objects and components accessible to 32-bit applications.
- The presence of a system32 (this is ironically where the 64bit libraries live) and a SysWow64 (this is where the 32 bit libraries live) system folders which replicate large portions of the Windows API and provide system components for 32-bit and 64 bit processes.
So how does this all work together? Well, Microsoft makes it work through redirection. Quietly, transparently — the Windows operating system will access the applicable part of the system based on the process type (being either 64 or 32 bit). The problem arises when one is running a 32-bit process, but want to have access to a dedicated 64 bit folder or registry key. Because redirection happens at the system level, programming tools, api access, etc. all are redirected to the appropriate folder for the process type.
Presently, I’m in the process of rebuilding MarcEdit, and one of the requirements is that it run natively in either 32 or 64 bit mode. The problem is that there are a large cohort of users that are working with MarcEdit on 64 bit systems, but have it installed as a 32 bit app. So, I’ve been tweaking an Installer class that will evaluate the user’s environment (if 32 bit process running in a 64 bit OS) and move the appropriate 64 bit files into their correct locations so that when they run the program for the first time, the C# code compiled to run on Any CPU (so, if it’s a 64 bit OS, it will run natively as a 64 bit app) — the necessary components will be available.
So how do we do this? Actually, it’s not all that hard. Microsoft provides two important API for the task: Wow64DisableWow64FsRedirection and Wow64RevertWow64FsRedirection. Using these two functions, you can temporarily disable redirection within your application. However, you want to make sure you re-enable when your required access of these components is over (or apparently, the world as we know it will come to and end). So, here’s my simple example of how this might work:
#region API_To_Disable_File_Redirection_On_64bit_Machines public static string gslash = System.IO.Path.DirectorySeparatorChar.ToString(); [DllImport("kernel32.dll", SetLastError = true)] private static extern bool Wow64DisableWow64FsRedirection(ref IntPtr ptr); [DllImport("kernel32.dll", SetLastError = true)] private static extern bool Wow64RevertWow64FsRedirection(IntPtr ptr); #endregion
#region Fix 64bit if (System.Environment.Is64BitProcess == false && System.Environment.Is64BitOperatingSystem == true) { //This needs to have some data elements moved from the 64bit folder to the System32 directory try { string[] files = System.IO.Directory.GetFiles(AppPath() + "64bit" + gslash); string windir = Environment.ExpandEnvironmentVariables("%windir%"); string system32dir = Path.Combine(windir, "System32"); if (system32dir.EndsWith(gslash) == false) { system32dir += gslash; } //We need to run off the redirection that happens on 64 bit systems. IntPtr ptr = new IntPtr(); bool isWow64FsRedirectionDisabled = Wow64DisableWow64FsRedirection(ref ptr); foreach (string f in files) { try { string filename = System.IO.Path.GetFileName(f); if (System.IO.File.Exists(system32dir + filename) == false) { System.IO.File.Copy(AppPath() + "64bit" + gslash + filename, system32dir + filename); } } catch (System.Exception yyy){//System.Windows.Forms.MessageBox.Show(yyy.ToString()); } } //We need to run the redirection back on if (isWow64FsRedirectionDisabled) { bool isWow64FsRedirectionReverted = Wow64RevertWow64FsRedirection(ptr); } } catch {} } #endregion
And that’s it. Pretty straightforward. As noted above, the big thing to remember is to Reenable the Redirection. If you don’t, lord knows what will happen.
–TR