Jump to content

Francesco

Member
  • Posts

    414
  • Joined

  • Last visited

  • Donations

    0.00 USD 
  • Country

    Italy

Posts posted by Francesco

  1. 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;

  2. 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%
    }

  3. RegKeyExists requires a final backslash in the key name or it won't work.

    Source: MSDN (RegKeyExists is based on RegRead):

    You can specify a key-name by ending strName with a final backslash. Do not include a final backslash to specify a value-name. A value entry has three parts: its name, its data type, and its value. When you specify a key-name (as opposed to a value-name), RegRead returns the default value. To read a key's default value, specify the name of the key itself. Fully qualified key-names and value-names begin with a root key. You may use abbreviated versions of root key names with the RegRead method. The five possible root keys are listed in the following table.

    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?

  4. That would be a bad idea to move WPI.hta. It will throw off %wpipath%.

    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.

    And not everyone is going to use the launcher.

    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.

    Keep the launcher simple.

    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.

  5. 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.

  6. Like I said before: if you specify the entire path to mshta it will use the 32/64 bit version accordingly.

    start "" /wait "%windir%\system32\mshta.exe" "%wpipath%\WPI\WPI.hta"

    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.

  7. 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.

  8. 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.

  9. 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.

  10. Francesco came up with an idea for a new option: Reboot before installation starts. I like it, but thought some more about it: is it necessary?

    I don't have a current XP/Vista disc with WPI on it. So I am drawing a blank: When XP and Vista finish installing don't they reboot anyway before WPI is started? Or do they finish, close, WPI runs, desktop loaded?

    Francesco: Explain in detail how you want to use 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;".

  11. Francesco: You probably have seen the previous posts about this. Checking is the desktop is already loaded via JavaScript is next to impossible.

    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?

    And this option was never meant to be used the way you are using/wanting it. It's meant to be used from DVD after Windows finishes installing and WPI is started, items picked, hit Install, desktop loads, then WPI installs apps. It is not meant to be used from the desktop.

    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 you can provide and app that can do an accurate desktop loaded check, then yes, please send it over.

    If the taskbar check is enough I can easily do that. It's just a dozen lines of code.

    Let me do some thinking on your other ideas. I do like the Reboot before install starts.

    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.

  12. Steps to update your WPI folder:

    I have thought about using an actual install package creator, but steps 3-5 would still need to be done manually.

    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.

  13. It's in the Conditions menu, File System -> File -> fileVersionGreaterThan(). Same place it's always been.

    I will test some bad conditions and see what comes up. Thanks.

    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.

  14. 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.

  15. Yes, that is how it is supposed to work. That is a function meant to be used from DVD after Windows has been installed. Useful for registry tweaks that need the desktop to be loaded or certain user to be logged in.

    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?

  16. 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.

  17. 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.

×
×
  • Create New...