<font size=2 face="sans-serif">Hello list,</font>
<br>
<br><font size=2 face="sans-serif">I'm currently and regularly running
into the WOW64 mess while trying to make my wpkg-package collection "Win64-ready".
The problem consists of two facts:</font>
<br>
<br><font size=2 face="sans-serif">* A 32 bit installshield .exe</font>
<br><font size=2 face="sans-serif">* the WOW brain-hurt diversion layer</font>
<br><font size=2 face="sans-serif">* MSI</font>
<br><font size=2 face="sans-serif">* WPKG running as user SYSTEM and the
SYSTEM profile sitting in </font><font size=3>c:\Windows\system32\config\systemprofile
</font><font size=2 face="sans-serif">by default.</font>
<br>
<br><font size=2 face="sans-serif">The symptome is that the install works
fine as a normal user, though there's an UAC prompt (obviously). But if
run via WPKG-Client-Service (which runs as user SYSTEM) the install fails
_very_ early.</font>
<br>
<br><font size=2 face="sans-serif">The cause is the following.</font>
<br>
<br><font size=2 face="sans-serif">* Installer gets run and unpacks its
MSI to %TEMP% - %TEMP% expands to </font><font size=3>c:\Windows\system32\config\systemprofile</font><font size=2 face="sans-serif">\AppData\Temp</font>
<br><font size=2 face="sans-serif">* Because the installer is 32bit, WOW64
diverts this to </font><font size=3>c:\Windows\sysWOW64\config\systemprofile</font><font size=2 face="sans-serif">\AppData\Temp</font>
<br><font size=2 face="sans-serif">* Installer calls the MSI via MSI API</font>
<br><font size=2 face="sans-serif">* MSI Service is 64bit, so no WOW64
diversion - it looks into the ...system32.. path</font>
<br><font size=2 face="sans-serif">* FAIL -> File not found</font>
<br>
<br><font size=2 face="sans-serif">This is mainly a problem with "Installshield
MSI" packages. Some of them are solvable:</font>
<br>
<br><font size=2 face="sans-serif">1) A few (SecureCRT for example) accept
the /b switch, which allows the MSI-cache location to be specified. Specify
an alternate path (That's not covered by WOW64) and you're done.</font>
<br><font size=2 face="sans-serif">2) Some package (like X-Manager) can
be fooled by re-defining %TMP% or %TEMP%</font>
<br><font size=2 face="sans-serif">3) Some simply won't work and have to
be disected (like unfortunately Suns/Oracles JRE/JDK) (as described in
the wiki), because the installer gets its extraction path from the registry.</font>
<br>
<br><font size=2 face="sans-serif">My question is: Did anybody find a good
way around Case 3? - because disecting a package should obviously be the
very last resort. I'm still hoping that I missed some low hanging fruit
:)</font>
<br>
<br><font size=2 face="sans-serif">The only other thing I thinked of was
using a dedicated user for wpkg (so the profile path is in c:\users). Did
anybody do this? How does UAC get involved when you're using a normal (but
admin) user for this?</font>
<br>
<br><font size=2 face="sans-serif">Kind Regards</font>
<br><font size=2 face="sans-serif">        Heiko</font>