bnicer
25th March 2013 14:21 UTC
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.
bnicer
25th March 2013 15:19 UTC
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.
Afrow UK
25th March 2013 16:40 UTC
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
Anders
25th March 2013 16:51 UTC
...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...
bnicer
25th March 2013 18:24 UTC
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.
Anders
25th March 2013 19:55 UTC
System32 is the native/64 bit folder, a 32 bit program gets System32 redirected to SysWOW64...