Archive: System32 and SysWOW64 are mutually exclusive


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...