locked
Disable redirector when Installing 32 bit application on Window 7- 64 bit RRS feed

  • Question

  • When I install my 32 bit apps on Window 7 - 64 bit, it redirects registries and data files.
    However, the current codes have hardcoded to read the regular location such as:
    "HKLM\Software\MyApps" and "\Program Files\MyApps"

    Is there a way that I can disable the director while install my 32 bit application to solve this situation?
    If yes, can someone please show me how to do so in c#?
    I found they mention about calling Wow64EnableWow64FsRedirection in Kernel32.dll.


    Thanks

    Thursday, February 18, 2010 7:54 PM

Answers

All replies

  • What does "while install" mean? Does it mean that you have an MSI-based install, or are you using your own code?

    If it's your own code, you'd call RegDisableReflectionKey (). This is Win32 - I don't know if there's a .NET equivalent - so you'd p/invoke.
    Phil Wilson
    Thursday, February 18, 2010 9:56 PM
  • Phil, thanks for replying.

    I meant I want to do something like:
    - Create a tool to disable the redirection on window 7 - 64 bit
    - Run this tool before i install my apps.
    - Install the apps so it can write files/registry into the correct location.



    Let say if I can successfully disable the redirection so my application can install everything OK to "HKLM\Software\MyApps" and "\Program Files\MyApps".
    However, at runtime, if all the binaries in my application were built as 32 bit .dll, do they have permission to read/write into "HKLM\Software\MyApps" and "\Program Files\MyApps"?

    If no, is there a solution for this?
    The bottom line is that I want to make my 32 bit apps works on Window 7 (64x) and minimize the work to rewrite the codes.

    Thx

    Friday, February 19, 2010 12:14 AM
  •  

    Hi,

    To access 64-bit registry key from 32-bit application, you may specify KEY_WOW64_64KEY flag to RegOpenKeyEx method. this article shows a demo about how to access 64-bit registry from a 32-bit application in managed code, hope it can help.

     

    We can use API Wow64DisableWow64FsRedirection to disable File System Redirection, and revert it with API Wow64RevertWow64FsRedirection, here is some code snippets:

     

            [DllImport("kernel32.dll", SetLastError = true)]

            public static extern bool Wow64DisableWow64FsRedirection(ref IntPtr ptr);

     

            [DllImport("kernel32.dll", SetLastError = true)]

            public static extern bool Wow64RevertWow64FsRedirection(IntPtr ptr);

           

            static void Main(string[] args)

            {

                Console.WriteLine("FsRedirection enabled.");

     

                // Physical path is "C:\Windows\SysWOW64\test\32"

                Console.WriteLine(Directory.Exists(@"C:\Windows\System32\test\32"));

                // Physical path is "C:\Windows\System32\test\64\"

                Console.WriteLine(Directory.Exists(@"C:\Windows\System32\test\64"));

     

                IntPtr ptr = IntPtr.Zero;

                if (Wow64DisableWow64FsRedirection(ref ptr))

                {

                    Console.WriteLine("FsRedirection disabled.");

     

                    Console.WriteLine(Directory.Exists(@"C:\Windows\System32\test\32"));

                    Console.WriteLine(Directory.Exists(@"C:\Windows\System32\test\64"));

     

                    if (Wow64RevertWow64FsRedirection(ptr))

                    {

                        Console.WriteLine("FsRedirection enabled.");

     

                        Console.WriteLine(Directory.Exists(@"C:\Windows\System32\test\32"));

                        Console.WriteLine(Directory.Exists(@"C:\Windows\System32\test\64"));

                    }

                }

     

                Console.ReadLine();

            }

     

    Since the Wow64DisableWow64FsRedirection function affects all file operations performed by the current thread, which can have unintended consequences if file system redirection is disabled for any length of time (For example, DLL loading depends on file system redirection), disabling file system redirection will cause DLL loading to fail.  To avoid these problems, disable file system redirection immediately before calls to specific file I/O functions (such as CreateFile) that must not be redirected, and re-enable file system redirection immediately afterward using Wow64RevertWow64FsRedirection.


    Sincerely,
    Eric
    MSDN Subscriber Support in Forum
    If you have any feedback of our support, please contact msdnmg@microsoft.com.
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.
    Welcome to the All-In-One Code Framework! If you have any feedback, please tell us.
    Monday, February 22, 2010 9:00 AM
  • Eric, thanks for replying.
    If we use this method to redirect files for the current thread, at run time, can 32-bit application access to 64-bit directories/files (such as \Program Files\...)?

    It would be a really big effort if we go back to the codes and make change to KEY_WOW64_64KEY flag whenever we call  RegOpenKeyEx in our managed/unmanaged codes. Because they're all over the place in the codes.

    Should we change our install to write key into HKLM\Software\Wow6432Node\MyApps?
    Then in our codes, instead of hardcoded to read HKLM\Software\MyApps, they will read HKLM\Software\Wow6432Node\MyApps?

    If this works, it would be much easier because we only need to change a few common files in our codes.

    Thx
    Monday, February 22, 2010 5:32 PM
  •  

    Hi,

    1. Yes, Wow64DisableWow64FsRedirection disable File System Redirector, so that all directories you have in the code are physical path, and we can access 64-bit files from 32-bit applications.
    2. From my understanding, the application is running as 32-bit application, am I right?

    If so, we can create a 32-bit MSI package, keep HKLM\Software\MyApps in both the MSI package and the source code,  because if a program is running as 32-bit, any attempt to access HKLM\Software\MyApps will be redirected to HKLM\Software\Wow6432Node\MyApps.


    Sincerely,
    Eric
    MSDN Subscriber Support in Forum
    If you have any feedback of our support, please contact msdnmg@microsoft.com.
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.
    Welcome to the All-In-One Code Framework! If you have any feedback, please tell us.
    Tuesday, February 23, 2010 3:19 AM
  • Eric,
    As follow to your answer #2, this is my comment:

    Yes, our apps is 32-bit MSI package and 32-bit codes.
    However, here is the hassle. The application is a mix of COM and .net.
    The core part was build from visual Studio 6.0 (C++, VB).  Then .net c# are sitting on top of core.
    This is our current situation:
    - For install, we still keep as 32 bit MSI, so at install, it supposes to write to HKLM\Software\MyApps. But on Window 7-64 bit, it was redirected to HKLM\Software\Wow6432Node\MyApps.
    - For the codes: we hardcoded to read HKLM\Software\MyApps
             - C#: If we currently build our .net C# codes as "Any CPU", will Window 7-64 considers those binaries as 64 bit .dlls? When those binaries make a call to read registry "HKLM\Software\MyApps", Window 7-64 bit will NOT redirect them to read "HKLM\Software\Wow6432Node\MyApps" ? If yes, then we need to build our .net C# codes as "86x" to make the redirection occur? 
             - C++, VB: are they considered as 32 bit binaries? Whenever they make a call to read registry "HKLM\Software\MyApps", Window 7-64bit will redirect them to "HKLM\Software\Wow6432Node\MyApps" ?

             Thx

    Tuesday, February 23, 2010 6:49 AM
  •  

    Hi,

    For C#, we can build it as x86 to make the redirection take effect.

    For C++/VB, if the binaries are loaded by 32-bit C# executable, they are also treated as 32-bit, and "HKLM\Software\MyApps" will be redirected to "HKLM\Software\Wow6432Node\MyApps".

     

    See also:

    File System Redirector

    Registry Redirector


    Sincerely,
    Eric
    MSDN Subscriber Support in Forum
    If you have any feedback of our support, please contact msdnmg@microsoft.com.
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.
    Welcome to the All-In-One Code Framework! If you have any feedback, please tell us.
    Tuesday, February 23, 2010 8:23 AM
  • Eric,
    Thx very much for your answer, I'm almost clearing out the picture.

    As your comment:

    For C++/VB, if the binaries are loaded by 32-bit C# executable, they are also treated as 32-bit, and "HKLM\Software\MyApps" will be redirected to "HKLM\Software\Wow6432Node\MyApps".


    Actually, our application is the other way arround. The entry point MyApp.exe is built as VB 6.0. It will call and load other codes .net, C++, VB.
    I would guess that the OS will treat them as 32 bit binaries including C# binaries (if we rebuild all of them in 86x to get in sync with c++, VB 6.0)

    Is that a correct assumtion?
    Thx

    Tuesday, February 23, 2010 7:28 PM
  •  

    Hi,

    VB6 runtime is 32-bit only, so VB6 application will run as 32-bit program under 64-bit OS, so your assumption is correct.


    Sincerely,
    Eric
    MSDN Subscriber Support in Forum
    If you have any feedback of our support, please contact msdnmg@microsoft.com.
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.
    Welcome to the All-In-One Code Framework! If you have any feedback, please tell us.
    • Marked as answer by garynguyen Wednesday, February 24, 2010 4:47 PM
    Wednesday, February 24, 2010 2:07 AM