Hi Heiko, On 18.05.2010 11:50, heiko.hel...@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 ------------------------------------------------------------------------- wpkg-users mailing list archives >> http://lists.wpkg.org/pipermail/wpkg-users/ _______________________________________________ wpkg-users mailing list wpkg-users@lists.wpkg.org http://lists.wpkg.org/mailman/listinfo/wpkg-users
