[wpkg-users] Problems with the WOW64 mess

[Rainer Meier]

Hi Heiko,

On 18.05.2010 11:50, heiko.helmle at horiba.com wrote:
>> In addition I was under the impression that %TEMP% expands to %
>> SystemRoot%\temp
>> (c:\windows\temp) for the system account. At least I've never seen
>> it expanding
>> to systemprofile\AppData\Temp which looks anyway wrong, if at all it
> should
>> expand to "systemprofile\AppData\Local\Temp" but this would also lead
> to the
>> problems you describe. But I am quite sure %TEMP% of the system
>> profile expands
>> to "windows\Temp".
> 
> Did you test this on 7? As far as i know, this did change on 7 - (And
> you're right, it is \local\Temp, but the base path is still
> unfortunately %WINDIR%\system32\systemprofile)

Meanwhile I am not running any Vista OS any more. Only Windows 7 x64 (and some
legacy XP boxes).
However I just accessed a Vista system to check and there is no
%SystemRoot%\system32\config\systemprofile\AppDataTemp folder at all. The system
profile uses %SystemRoot%\Temp for temporary storage which is not virtualized.



> This is true in theory - and the msiexec.exe called by the install.exe
> actually is 32bit, but all msiexec.exe does is call the Windows
> Installer Service via some internal Interface - and that one is 64bit.

I agree that the Windows Installer service is a 64-bit service. However I've
never faced any problems as you describe them. I have to admit that I don't know
all the internals and which part of the installation are performed by the
service. Not sure if it has to pick up the MSI files either. In any case a
64-bit service should be able to access both, system32 and SysWOW64 folders as
it is 64-bit. For sure some paths might be wrong if passed by a 32-bit service
but such things can easily be solved by the service by looking at both
locations. In fact this is also the approach WPKG does. If invoked by 64-bit
cscript.exe it's able to read 32-bit and 64-bit folders and registry settings
and it will just look in both transparently.
But I have no clue if Microsoft thought about this case. As I said for files
stored in %TEMP% I don't think it's a problem. But it might be if the installer
stores some transforms or similar things in %AppData%... and the Windows
Installer service does look in the wrong location only. Personally I've never
experienced such problems as I said.


>> In any case I don't like boxed installers too much. So I used to extract
>> Installers which extract MSI files in advance and then work with
>> pure MSI files.
> 
> Which is fine when all the .exe does is unpacking and running the MSI.
> In the case of X-Manager I spent nearly 2 days and finally giving up.
> This Installer is installscript-driven and convincing the MSI to run
> without installscript produces a broken install.
> I'm ok with the "boxed" versions if they give all the options I need and
> work reliably. Saves me from much work disecting every version upgrade.
> Java's Installer is okay-ish, except for the 64bit issue.

Don't know the X-Manager installer. But for Java it was the same for me, no
issues running extracted MSI files directly, instructions can be found at the
WPKG home page.

So for the X-Manager it might help if you wrap it in a small .cmd script, if it
accesses %TEMP% environment variable you might override it before calling the
installer. If it reads the locations from the registry you might be able to
point it to a different location as well.


> Tried and did for many packages - but some are left, those pesky ones
> that need InstallScript for the install to go right.
> 
> But I see light - I looked through some Docs and it seems that (by
> default) the builtin "Administrator" local user on Windows 7 is running
> elevated by default. That would mean no UAC-Prompts for this user - so
> it'd work for silent installs. It just needs to be activated (and
> passworded). I'll try this and report back to the list :)

So you're planning to use "runas" with the Administrator account I guess. For
sure this might be an option as well.
This could have been a solution to the "broken Innosetup" installer problem some
of us faced a while ago. Some new version of Innosetup was just hanging during
the installation process when run within SYSTEM context. Luckily this was fixed
quite quickly and usually all following installer releases were fixed (for
example it applied to the K-Lite codec packages).


br,
Rainer