Francesco

Feature: LaunchInf In ConfigWizard.js Below CommandsMenuBar.addNewChild("cmd_system", 3, "dos_instinf", "InstINF", false, "", ""); add CommandsMenuBar.addNewChild("cmd_system", 4, "dos_launchinf", "LaunchInf", false, "", ""); Below case 'dos_instinf': HandleCommandsSelectionMenu("{INSTINF} "); break; add case 'dos_launchinf': HandleCommandsSelectionMenu("{LAUNCHINF} "); break; Replace if (document.getElementById("cmd1").value.substr(0,9)=="{INSTINF}") with if (document.getElementById("cmd1").value.substr(0,9)=="{INSTINF}" || document.getElementById("cmd1").value.substr(0,9)=="{LAUNCHINF}") In Installer.js Below case '{INSTINF}': cmd=("CMD /C "+cmd.replace(/{INSTINF}/gi,'rundll32.exe setupapi,InstallHinfSection DefaultInstall 132')); fsoCmd=true; break; add case '{LAUNCHINF}': cmd=("CMD /C "+cmd.replace(/{LAUNCHINF}/gi,'rundll32.exe advpack.dll,LaunchINFSection')); fsoCmd=true; break;

How to reproduce Go to Start Menu, Run, type the wpi.exe path changing the case of some of the path letters and launch it: when adding files to commands WPI will insert invalid paths. Cause WPI doesn't do case-insensitive replacement of %wpipath% when browsing for commands to add, meaning that if WPI isn't started typing the exact lowercase/uppercase path name the path trimming function won't work. Fix Replace the following lines in configwizard.js if (str.indexOf(wpipath) != -1) { trimpath=wpipath; trimpathvar="%wpipath%"; //Could have used %cdrom% } with if ((WPIPathPosition=str.toLowerCase().indexOf(wpipath.toLowerCase())) != -1) { trimpath=str.substring(WPIPathPosition,wpipath.length); trimpathvar="%wpipath%"; //Could have used %cdrom% }

Cause Vista and Win7 have a different security center WMI namespace. Fix Replace the two lines in WMI.js objWMIService=GetObject("winmgmts:\\\\" + "." + "\\root\\SecurityCenter"); with objWMIService=GetObject("winmgmts:\\\\" + "." + "\\root\\SecurityCenter" + (getOSver() != "XP" ? "2" : ""));

RegKeyExists requires a final backslash in the key name or it won't work. Source: MSDN (RegKeyExists is based on RegRead): The RegKeyExists("HKEY_CURRENT_USER\\Software\\WPI\\Theme") example shown when you click to add the function is wrong because it doesn't include the final backslash. Maybe WPI should add the final backslash if it's not already present in the key name?

No need, I already updated it. lang_it.js

The launcher could set the environment variable, or pass a command line parameter, or the setWPIPath function inside core.js could be changed to remove the last directory entry so it wouldn't be such a big problem. Most people will go directly to the EXE now that they'll see there's one. Newbies will use it because they don't know that .HTA files can be run, pros will run it because they'll think it is now necessary to use it (and it is, if they want to avoid all the error messageboxes on vista because of UAC). Having only the executable and TXT files in the main dir could help make things less confusing. Adding some file/registry key checks to detect missing files or conflicting applications could hardly make the launcher bloated or slow because it c++ code is very fast and small.

Can you please move the .HTA file in one of the folders? With the HTA and launcher in the same folder it could get confusing. Tell me if you can move it and where so I can rebuild the exe with the new path. Also if WPI is incompatible with some applications like Nero or need some certain windows files I can detect those and warn the user so they won't come complaining here when WPI doesn't load.

Now I added a messagebox when WPI.hta is not found WPI.rar

Yes, I know, but having to use batch files to launch the correct version is ugly, having a launcher would be much better. Anyway, I made it. It's 2kb without the icon, 8kb with the 6kb WPI icon. I attached the version with the icon to this message. If you need some changes tell me. This launcher could be also used to pass to WPI informations that it's unable to read, for example rather than having WPI check for explorer with findexplorer, this launcher could tell WPI if explorer is loaded with a reserved command line parameter.

Can you please make the music player stop playing when the install ends? The music covers the WPI Closes sound. Also, are you sure you don't need a WPI launcher that runs it as administrator and selects the correct MSHTA 32/64bit version? That could be quite useful.

Sorry if I didn't post a reply before but I had quite a few problems with my PC, my motherboard broke and I'll have to wait an entire month until I get a replacement because the shop where I bought it is closed. I didn't mean anything near the complexity of an applications database. What I meant was to add a tab to the config wizard to do version detection, where you specify the current version and how to detect it (registry key, file version, INI value); a tab where you specify uninstall commands to remove the older versions (and all the commands you put there are added in front of the install commands so there's nothing else to rewrite and WPI will also handle reboots) and a column to the commands page's list control where you specify if the command has to be ran only on some architectures. I can add that stuff to WPI and post the changes if that's a problem.

I'm having a few annoyances with 64bit applications and also with applications upgrades. I premise that I use the conditions properties to hide applications that are already installed (and where the version is equal or higher than the one present in WPI), so that the same applications aren't installed twice and I don't have the screen flooded by applications already installed. Usually for 64bit applications there are two kind of installers: a separated installer for the 32bit and 64bit versions, or an unified installer that installs the right version for your system. The first kind of installer would usually require a batch file that launches the correct setup or need two entries for the 32bit and 64bit version inside WPI, but this can be avoided by using the %PROCESSOR_ARCHITECTURE% environment variable, that I suggest should be added in the Commands/Paths menu. With both the installers however there's another problem that lies in the install conditions: since MSHTA runs at 32bit by default, the %programfiles% envvar will always point to the 32bit path, while the real 64bit programs files path is stored inside %ProgramW6432% (that on 32bit systems doesn't exist), so when you want to have a single entry for the 32bit/64bit application this can become quite a problem, because you have to use javascript expressions in the condition to select the right path, so I suggest to have WPI replace the environment variables when 64bit processing is enabled, offering the %programfiles% and %programfiles(x86)% variables on both 32bit and 64bit system and setting them to the correct paths so that they work correctly in the conditions, or another alternative could be to use a launcher for WPI that launches the HTA with the correct version of MSHTA (in case it's needed I can write that, I can also make it terminate other MSHTA instances so there won't be any more mshta.exe hanging in background preventing WPI from open). The other problem is with applications that have to be uninstalled before the new version can be installed. This can be quite challenging because the way of uninstalling each version could be different for each version and usually requires pretty long .bat files, so I suggest improving WPI by adding an Uninstallation tab that allows detecting older versions (with a condition) and uninstalling all of these before the new version installs. This could be also used to have WPI work like an uninstaller, that when it sees that an application is already installed offers you a "remove checkbox" to uninstall it. I think that WPI could greatly benefit from a move to a more application-centric approach where you have only one entry for each application and WPI, natively, does all the version checking, uninstalls of previous versions, and installs the correct version for each architecture.

What about a message box (and an option to enable it) that asks for confirms before reboots? Like when "reboot before install" is on or when you select an entry that has reboot commands in it. It could have three options: "OK", "Reboot Later" and "Cancel", where Reboot Later sets WPI to start at the next reboot. It could be useful.

Do you happen to know if the fake vista sounds are copyrighted? Those could be useful to make a very pretty sound scheme. I uploaded here a sound scheme I quickly made from it.

I don't actually use or need that option. I added it to WPI to offer the same identical old behavior of the "load desktop before install starts" option since I made you change how that option worked and didn't want to bother the users who will expect to have the same old behavior. A reason to have it would probably be to use it when you start WPI manually to have all the changes applied during the boot process in order to make the installs faster: with no desktop loaded there are less files in use so installs are faster and you can avoid rebooting again for certain updates, for example IE and its patches could install without another reboot. I tested the code and seemed to work fine, the code changes are minimal so I don't think that implementing them would cause any major problem however it's entirely up to you to chose to add it or not. Anyway remember that I also did another change: I removed the "do not load desktop" option that now seems to be quite useless because when the install ends if you have "Load desktop before install" enabled the desktop would be loaded anyway. By the way, if you are going to add that change I forgot to add a "if (!LoadDesktopBeforeInstall) RestartSeconds=0;" line inside installer.js, in place of the previous "if (DoNotLoadDesktop) RestartSeconds=0;".

I can write a small command-line tool for that. I know how to check if the taskbar is present and how to wait until the taskbar is started (explorer sends a message to all applications when the taskbar is created) would that be OK? That's exactly how I'm using it. I run WPI from RunOnce but with that option enabled WPI just shuts down and the desktop loads and, in order to have WPI install, I have to run it again from the DVD again and tell it to start installing. I also have the problem that it closes when I launch WPI from the desktop (and I understand that's by design but I still think it could be improved so I don't have to keep 2 versions of WPI, one for first boot install and one for desktop install) but the most annoying issue is when WPI closes after being launched by the runonce entry. If the taskbar check is enough I can easily do that. It's just a dozen lines of code. We can add that option anyway to simulate the old behavior. It also can be useful for IE/patches install when desktop isn't loaded, that would save a few reboots.

Many installers can be programmed to copy/move/delete folders and do most of the stuff you can do with a custom application without touching a single line of code but if you could create folders for user-inserted themes and audio files (and add two options inside WPI to hide default themes and sounds in the list) then even a simple RAR SFX would be enough to update WPI.

Could you please update the Italian language file with the one I attached to this post? I added the latest 7.6.0 strings, fixed the indentation and corrected some spelling mistakes. lang_it.js

Did you happen to read my other post here?

Could you please update the fileVersionGreaterThan function with the new one I posted here? Thanks. BTW I still get the "VPWindow is null or is not an object" messagebox when one of the conditions causes a javascript error.

I thought a new version came out and when I downloaded it I didn't find the new function inside but now I found out it was because 7.5.0 shows wrong the version number (7.4.0) so the version I got is still the old one I already had that doesn't have the updated function inside. On another different subject could you please change how the "Load desktop before installation starts" option works? I need desktop loaded when the install starts for certain setups but I don't want to be forced to reboot the PC all the times I start WPI manually (there are no checks to see if the desktop is already loaded so when you start the install WPI just closes waiting for a reboot). I suggest one of the following solutions: WPI checking if the desktop is already loaded rather than waiting for reboot. I saw there's a function called getDesktopLoaded in wmi.js that seems to be unfinished and isn't used anywhere. Was that function supposed to check if the desktop is loaded? If that's not the case I can write a small executable that returns errorlevel 0 if the desktop is loaded, 1 if it's not that can be used by WPI. a "Reboot before starting install" option (in Options->Tools above the "Restart computer after installation is complete) and WPI starting instantly also with the "wait for desktop" option. This would simulate the old behavior. a switch for {REBOOT} (or a new reboot command with another name) that specifies if desktop has to be loaded (or not) and WPI starting the installation instantly without checking for the "wait for desktop" option. People who want the old behavior just need to set that switch for the setups that have issues when the desktop is not loaded. (the simplest) WPI just starting the installation instantly even with the "wait for desktop" option enabled. People who want the old behaviour can use the actual %reboot% switch (unchanged) to have the system reboot before the install starts. I doubt that desktop needs to be loaded before WPI all the times because only few setups need the desktop loaded in order to install fine, also, WPI is usually started manually or automatically after windows install so in both cases the desktop would be loaded or it wouldn't so waiting for desktop even after starting the install would be useful only for some in strange cases. If you can tell me if one of these solutions is fine I can tell you what to change in the code. I already gave a look at the code to find out why it wasn't waiting for desktop to start so I already know what to change.

My fileVersionGreaterThan function seems to have been removed from the latest 7.5.0 version along with the pretty CorporateIT theme. Any idea why? Also I noticed that when there's an error in the conditions' syntax you get a script error about VPWindow.createWindow failing because VPWindow is null instead than getting the custom error messagebox. It can be fixed with a try/catch that uses alert('') when that call fails.

I understand, but if the desktop is already loaded (you launch WPI manually) it should start anyway shouldn't it? If that's the case if I change WPI to make it work that way can you please add those changes to the official version?

Is it a wanted behaviour that when you enable the "Load desktop before installation starts" WPI doesn't start installing if the desktop is already loaded? I have to restart WPI or reboot windows to make it work. I use WPI both unattended-ly after XP ends installing and also starts it to install additionals applications later so I need that option enabled.

Could you please update my javascript function with this new one? 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; } this one works also when you compare numbers and empty version numbers without throwing errors.