Jump to content

Future feature requests


Recommended Posts


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.

Link to comment
Share on other sites

Francesco: You probably have seen the previous posts about this. Checking is the desktop is already loaded via JavaScript is next to impossible. 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.

Correct, getDesktopLoaded() is not working. I can't find a 100% "flag" to check.

If you can provide and app that can do an accurate desktop loaded check, then yes, please send it over.

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

The main reason to load the desktop first is for registry tweaks. The user's account/desktop must be up for most to take affect.

Link to comment
Share on other sites

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.

Edited by Francesco
Link to comment
Share on other sites

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.

mmmm you do know WPI supports command switches right?

With switches you can have unlimited WPI configs and call it ANY way you want.

Link to comment
Share on other sites

Why do you not use objects for configuration instead of multiple arrays?

Maybe it could speed up WPI if you switch from

pn=0;
prog[pn]='App1';
desc[pn]='descr1'
pn++;

to something like this:

function Application(aName, aDescr)
{
this.name = aName;
this.descr = aDescr;
}
Application.prototype.setName = function(aName) {
this.name = aName;
}
Application.prototype.getName = function() {
return this.name;
}
Application.prototype.setDescr = function(aDescr) {
this.descr = aDescr;
}
Application.prototype.getDescr = function() {
return this.descr;
}

var app = new Application("Microsoft Windows Media Player 12", "a media player");

With this you hold one array of all applications an can quickly access the properties of the current application.

--> I hope this could be faster - but I'm not sure.

Al

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Thats friggin insane. Someone would have to build a giant database of apps and keep it up to date. IF and only IF we got paid enough (Or really any at all) then we might consider all of the extra work.

You see though this isn't glamorous at all. We gat paid almost nothing! mritter has gotten like 15 dollars in donations in the past couple of years he has been at this.

Then we get trouble makers that are not ever satisfied and think they could do better, emails from people who ask for help becuase the warez makers use WPI in most of their releases. (Stopid emails too Like "I lost my [insert warez release name here] serial what is it?) and people who just want to complain...

Link to comment
Share on other sites

Francesco,

Look at this thread, 64bit has been covered already.

Also, if you specify the complete path to mshta in your cmd scripts when starting WPI, it will run the appropriate 32 or 64bit mshta.

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

As far as an uninstaller, I see your point in wanting it, but could be really hard to work out. Like, what if the uninstaller wants to reboot before new version could be installed? You would have to know that ahead of time. Lots of little things need to be accounted for. Will take some serious thought and planning.

Link to comment
Share on other sites

Hi, I really wish for an AND function with Conditions.

ex. I have Nvidia files in my WPI where i would like conditons like:

Cond. GetOSVer=Win7, Vista AND Getbits=32

If i do this:

cond[pn]=['getOSver()==Win7","Vista"','getbits()==32];

it shows the app. in XP-32bit and 2003-32bit.

is there anyway you could make a rule like if first answer is NO and second answer is YES, the condition is "not show" - only if first answer is YES it will check for next answer/cond. in line.?

or maybe like this:

cond1[pn]=

cond2[pn]=

Thx for good programming, i've been using WPI for several years now. :-)

Link to comment
Share on other sites

There is an AND function. All the operators are in the manual.

getOSver()=="Win7" && getbits()==32

(getOSver()=="Win7" || getOSver()=="Vista") && getbits()==64

You will want the second example.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...