Francesco

I noticed that getFileVersion returns 0 when there is an error (like when the file is missing) but the 0 is returned as an integer rather than a string. The function I wrote returns errors if both the parameters aren't strings so either the getFileVersion function is fixed by returning "0" or an empty string "" or my function has to be changed by replacing the var line with this: var split1 = fileVersion1.toString().split("."), split2 = fileVersion2.toString().split("."); I updated the function in first post with the changes.

Insert this pretty function at the bottom of registry_dos.js and have fun: function fileVersionGreaterThan(fileVersion1,fileVersion2) { position="registry_dos.js"; whatfunc="fileVersionGreaterThan()"; var split1 = fileVersion1.toString().split("."), split2 = fileVersion2.toString().split("."); for (var i = 0; i < split1.length; i++) { var split2item = parseInt(split2[i]); if ((parseInt(split1[i]) > (isNaN(split2item)?0:split2item))) return true; } return false; } Examples: fileVersionGreaterThan("7.0",getFileVersion("c:\Program Files\Internet Explorer\iexplore.exe")) checks if a version of internet explorer previous to 7.0 is installed on the system. fileVersionGreaterThan("3.0",getFileVersion("c:\Program Files\Mozilla Firefox\firefox.exe")) checks if a version of firefox previous to 3.0 is installed on the system. fileVersionGreaterThan("3.0.0.7",getFileVersion("c:\Program Files\Mozilla Firefox\firefox.exe")) checks if a version of firefox previous to 3.0.0.7 is installed on the system. fileVersionGreaterThan("11.0",getFileVersion("c:\Program Files\Windows Media Player\wmplayer.exe")) checks if a version of windows media player previous to 11 is installed on the system. fileVersionGreaterThan("2.0.40115.0",RegKeyValue("HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Silverlight\Version")) checks if a version of silverlight previous to 2.0.40115.0 is installed on the system fileVersionGreaterThan("7.2.6001.788",getFileVersion("%SystemRoot%\System32\wuapi.dll")) checks if the windows update agent version is previous to 7.2.6001.788.

I tried with timer=0 and nothing happened, I thought it wanted all the parameters but it looks like WPI just didn't like the timer value being 0. On the previous versions using 0 would start installing immediately. I think you should write in the help file that the parameters can be in any order and that not all of them are required or it may be confusing: usually people expect optional parameters inside square brackets.

Those are not removable devices: those are the motherboard built-in devices and shouldn't be removable in any way. When using the original XP SP3 CD none of those devices are detected as removable like this: heck, even the USB controller itself became removable! Either this PC was infected by a virus that is turning the motherboard into swappable lego bricks or there's something weird in the last update I added that messed things up. I'll try remaking the nlite config file from scratch and see what happens. I wonder why the weirdest issues always happen to me

I've tried making the CD on an XP machine and it still seems to have this issue. I've ran nLite only once on the source, I started with clear sources and I also didn't slipstream any service pack because I have the official windows xp with sp3 cd. What could have gone wrong?

I just added the AutoRun Update (KB967715) to my nLited Windows XP SP3 CD and strangely many devices that shouldn't ever been removable like the ethernet, soundcard and USB controller became removable. I've attached my nLite configuration files. Last_Session.ini Last_Session_u.ini

On the previous WPIs I could launch WPI with just the name of a configuration and the seconds to wait before starting to install: I used that to start WPI immediately after the Windows XP setup. Is there a way to do this on the newer WPIs without having to use separated config and options files? Also I've noticed this in the WPI.hta file: cmdLinePattern='^( +('+optionsPattern+'|'+configPattern+'|'+checkOLPattern+'|'+timerPattern+'|'+themePattern+'|'+resolutionPattern+'))*$'; //any combination of the above, with spaces inbetween regexpSearch=new RegExp(cmdLinePattern,"i"); WPIcmdArgs=argLine.match(regexpSearch); if (WPIcmdArgs) { if (WPIcmdArgs[3]) { optionsFile=WPIcmdArgs[3].replace(/\"/gi,''); if (optionsFile.indexOf('\\') == -1) optionsFile=wpipath+"\\WPIScripts\\"+optionsFile; } shouldn't if (WPIcmdArgs[3]) be if (WPIcmdArgs[1])? The options file is the first parameter, not the third, same for the IF branches that detect the other parameters.

The reboot issues saga saga continues : When I imported my older config file %reboot% was imported as "%reboot%" and failed. I changed it to %reboot% but nothing happens, it seems to just skip the command. Was the %reboot% superseded by something else? Nevermind, I found out that the Commands button can be clicked and that the new command is {REBOOT}. The import issue is still there though since it wasn't changed to {REBOOT} like it should have been. I put {REBOOT} 30 but reboot still doesn't work. There are no reboots and the command is skipped in the log file, WPI skips to the next command ignoring the reboot. What could it be?

This new version is really amazing! Thanks!

I fixed this by making a new options file and setting everything like it was on the old one. The window size was not set so I don't have a clue about what could have been the cause, I think it could have been some setting saved by an older WPI version that was incompatible with the newest. The only issue I have now is that when it starts maximized there's a 2-3pixels thin border on the left side of the window but I can live with it. I think that the window size should be allowed to be set even when the window is flagged as maximized so that when you "de-maximize" the window it goes back to the right size you want (instead of a default one) and that the window state should be set after the window appears unless it's minimized. That's the behavior most applications have when saving/restoring window size.

I have issues with WPI window not being maximized unless I select thin border type. Am I alone?

I use only %reboot% and it doesn't reboot unless I remove the first of those 2 lines from the core.js or I specify the seconds. The two lines in the core.js are one immediately next the other so if you don't specify a reboot time the reboot command call will be "shutdown.exe -r -f -t " that won't never work, because -t has no time value. No one of those 2 replaces is looking for a space, they both look for the same identical string.

Any news about a fix for this bug? I still see it on the latest WPI 6.4

If you remove the first of those 2 lines the reboot command ("%reboot%" with no other parameters) works fine. I think all you have to do is add an IF block that checks if there's a number after the %reboot% command and then use the first or second replace accordingly.

I still have the same problem with the latest WPI version 6.3. Any idea?

when I create my cd image with cdimage.exe and the -d switch (that forces all the files to uppercase, I need it for the xp setup) I get weird WPI behaviours, for example the first part of the file path is skipped (if I use "%WPIPATH%\install\test.bat" then "%WPIPATH%\test.bat" is invoked instead (probably the %WPIPATH% is set wrong when the files are uppercase).

I'm running WPI from RunOnce and I get the following error sometimes but not all the times. JavaScript Error Report Message: Access Denied Url: file://D:\WPI\WPI.hta File: tips.js Function: mig_lay() Line: 80 I got this error as soon as WPI started displaying the interface (not all the interface was drawn).

I have a few problems with %reboot%, for some weird reasons "shutdown.exe -r -f -t" is invoked without the time (0) I saw this in the core.js file that probably is the cause rs = rs.replace(/%reboot%/gi, 'shutdown.exe -r -f -t '); // force a reboot after X seconds rs = rs.replace(/%reboot%/gi, 'shutdown.exe -r -f -t 0'); // force a reboot now there are those 2 replaces one after another but the reboot time isn't specified for the 1° one causing the reboot to fail (the time parameter is mandatory).

Maybe a good idea would be to avoid using WMI and access directly the registry keys instead. WMI as long as I could see was used only to get out the system language settings.

This has nothing to do with UAC. I found out the problem was caused by AIM6 that was breaking WMI. I had to stop WMI delete its repository and restart it again to get everything working again.

Only 3 but if you say that's normal nevermind then. I've gave a look at the LOG files of the integrated hotfixes and those TMP files seem to be useless stuff (files that were replaced multiple times by different hotfixes).

What about not using an .HTA for the progress dialog (maybe something simple in .NET?)? Unfortunately after installing the cumulative IE7 hotfix (at least in my case, but another confirmed the same problem here on the WPI forum) the progress dialog crashes Also no HTA means less locked windows libraries: for example IE7 and its patch could be installed without reboots if WPI wasn't using HTA files for the progress dialog.

After seeing that applications like Acrobat Reader when unpacked are more than 100mb (even if the original setup is just 21mb) and that if I compress those setups with 7zip it takes ages for them to extract on old computers or computers with slow HDs (laptops) I started thinking about using the new vista's WIM format to create a compressed image with the acrobat files that I can mount on XP and use it to install acrobat. WIM images can be mounted as a driver letter (not only on Vista but also on XP and probably win2k) and have a very fast decompression so one could create a compressed WIM image with all of his uncompressed unattended applications installs and then mount it and install everything from there and still have a good speed/compression compromise. Has somebody already tried this solution or am I the only one thinking about it?

I created an unattended cd using nLite and added all the XP important hotfixes and a few optional ones (remote desktop, etc). Strangely the windows install leaves some tmp files named SETx.tmp (where x is a number) in the c:\windows\ folder. As long as I know those files are temp files created by the hotfixes setups that are usually moved in the right places with PendingFileRenameOperation entries so they shouldn't be there at all. Is that normal?

I added an IE7 entry in WPI that first installs IE7, then reboots (%reboot%) and then installs the IE7 cumulative hotfix. I get an "unable to initialize application" error generated by Sleep.exe just before WPI reboots the system and I also get a WPI script error after the PC is rebooted, the IE7 cumulative hotfix has been installed and WPI finishes installing all the rest of the applications: