System32 and SysWOW64 are mutually exclusive

Hi,
A strange thing (bug?) happens, when you install and uninstall on Windows 7 64-bit with 'Run as administractor' into the following directories:

'C:\Windows\SysWOW64\MacroMed\Flash\FlashPlayerTrust\'
'C:\Windows\System32\MacroMed\Flash\FlashPlayerTrust\'

writing to both folders consecutively. Unicode and Ansi compilers.

You can to write to one but not both folders. Or, you can work-around the problem by writing to one place and copying from there to the other.

Notice I say 'you', because I think this is a bug. Prove me wrong (please), and I would be very happy.

When you have installed to SysWOW64 and System32, by copying, take your pick. You can uninstall from SysWOW64 or uninstall from System32. Consecutively -- I haven't tried it another way -- SysWOW64 thinks it's System32 and vice versa.

    StrCpy $SYS_DIR "$WINDIR\SysWOW64" #

    StrCpy $SYS__DIR "$WINDIR\System32" #



    StrCpy $R0 "$SYS_DIR\Macromed\Flash\FlashPlayerTrust" #

    Delete "$R0\trust25032013.cfg"

    RMDir $R0

    StrCpy $R1 "$SYS__DIR\Macromed\Flash\FlashPlayerTrust" #

    IfFileExists "$R1" 0 +5

    Delete "$R1\trust25032013.cfg"

    RMDir $R1

Pending a bug-fix, can anybody A) verify/reproduce the bug, B) think of another way to uninstall both files? It doesn't have to be consecutively. Any fix would be immensely appreciated, great. Thanks.

I found a solution in another thread in the form a system call:

    StrCpy $R0 "$SYS_DIR\Macromed\Flash\FlashPlayerTrust" #

    Delete "$R0\trust25032013.cfg"

    RMDir $R0

    System::Call kernel32::Wow64DisableWow64FsRedirection(*i.r0) i.r1 ; !! solution !!

    StrCpy $R1 "$SYS__DIR\Macromed\Flash\FlashPlayerTrust" #

    IfFileExists "$R1\trust25032013.cfg" 0 +5

    Delete "$R1\trust25032013.cfg"

    RMDir $R1

Thanks.

Which leaves only: Why can you copy to both locations, but write only to one? (Without Wow64DisableWow64FsRedirection, I mean.)

Edit: Does the problem also exist on Windows 8 64-bit, Vista 64-bit, XP 64-bit, ... ?

Edit II: The certificate enables Flash to JavaScript communication. Installing it for 64-bit became necessary with IE10, that looks for "FlashPlayerTrust" under SysWOW64 only. Nonetheless, if other 64-bit OSes support IE10 and have a similar issue to the one described, changing the system folder, Wow64 redirection should be disabled on all of those systems. I don't like doing it, as I do not entirely trust system calls.

You have to do it because the installer is 32-bit so by default gets redirected to SysWOW64. There is an x64.nsh which you can use ${DisableX64FSRedirection} from.

Stu

...and remember to turn it back as soon as possible! Only filesystem stuff like File/IfFileExists/GetAttributes/Delete/Find*/RMDir should be performed when it is active, ExecShell etc might fail...

Looking good 🙂 :

    StrCpy $SYS_DIR "$WINDIR\SysWOW64" #

    StrCpy $SYS__DIR "$WINDIR\System32" #



    StrCpy $R0 "$SYS_DIR\Macromed\Flash\FlashPlayerTrust" #

    Delete "$R0\trust25032013.cfg"

    RMDir $R0

    ${If} ${RunningX64}

    ${AndIf} ${AtLeastWinVista}

      ${DisableX64FSRedirection}

      StrCpy $R1 "$SYS__DIR\Macromed\Flash\FlashPlayerTrust" #

      IfFileExists "$R1\trust25032013.cfg" 0 +3 ; jumps to EnableX64FSRedirection

      Delete "$R1\trust25032013.cfg"

      RMDir $R1

      ${EnableX64FSRedirection}

    ${EndIF}

IE10 is supported on the following operating systems and platforms, say Microsoft: Windows 8, Windows Server 2012, Windows 7 SP1, Windows Server 2008 R2 with SP1, but you never know. I got a feeling they'll be rolling out a Vista version come the next Service Pack.

I still find it strange that CopyFiles worked without redirection. It must be doing something right.

Thank you.

Edit: IE10 checks System32, and not the other way around. Formerly SysWOW64 was the place to put trust files.

System32 is the native/64 bit folder, a 32 bit program gets System32 redirected to SysWOW64...