WPI 5.0rc2 Bug Reports

[Denney]

I was waiting until the new version came out to report this as it happens in v4 aswell...

When setting ProgB to depend on ProgA and setting BOTH to default, only ProgA is selected.

ProgB must be selected manually, although it is set to be default in the config file.

Edit: I just realised that it's because of the way the items are ordered in the config file.

ProgB's MUST appear AFTER ProgA in the config.js file. In other words, the ID must work out to be "higher ranked" for ProgA than ProgB.

Eg.

ProgA [with ID ProgA] and ProgB [with ID ProgB] = both checked.
ProgA [with ID STPD] and ProgB [with ID DaemonTools] = STPD checked but DaemonTools NOT checked.

Edit2: I was wrong. It's not sorted on UID... it's sorted on name (but you already knew that). So the names need to be ranked accordingly.

Edited June 1, 2006 by Denney

[Djé]

The way ExtractArgs(cmd) tries to extract the arguments part is not optimal as well: using "-" or "/" at the start of an argument is absolutely NOT mandatory.

Actually I have a lot of commands with the arguments part not starting with any of these.

And this will also make the FielExists(cmd) test fail...

[Denney]

@Dje: I agree. I have many "cmd" scripts that I call and I pass the path of WPI to them like so:

"%wpipath%\software\someprog\someprog.cmd" "%wpipath%"

[Denney]

I don't know enough javascript, but doesn't the shell.run function return an error code if it fails?

Wouldn't this be more recommended for debuging a list of applications?

And at least the command would be marked as failed AFTER having been run

The problem with that is that each program's return code is different. It's up to the program to return a return code so the actual return code would only be usefull if the user knew what the return codes meant.

Would be a better idea than the current implementation though. Maybe checking for a "0" return code to indicate success (most programs return 0 on success)?

Edit: Just an update on my post above (#16), I managed to fix this by changing line 227 in program.js from:

progspercat.sort(SortByProg);

to:

progspercat.sort(SortByOrdr);

I just loose the ability to sort programs by name when displaying them.

Edited June 1, 2006 by Denney

[Djé]

[EDIT]: This is no bug. It was my fault, as Denney pointed it out below. Forget this post.

Oh I see.

Sorry for 'moving the knife back and forth in the wound' (almost a literal translation of a French idiom, but I think you'll get the meaning).

It seems that this FileExists(cmdLine) was there for a good purpose:

Shell.Run itself is not able to handle all commands correctly:

If I hack the file and remove the FileExists(cmdLine) tests, I get a Javascript error:

*removed*

So it looks like the solution will not be as easy...

@Denney

I was not talking about the return code of the program itself, but of the Shell.Run function, which -I imagine- could be something like

1 - command run successfully

0 - command failed

But usually things are more complicated in real life

Edited June 1, 2006 by Djé

[Dynaletik]

I have got some little problems with my config file and the way WPI 5 installs my apps:

I gave order number 1 to the .NET Framework and number 2 to the ATI Catalyst Control Center, but WPI 5 does not install Framework before CCC. WPI 1.2 Lite did this.

Another thing: Since WPI 5, I cannot apply the XP-AntiSpy Tweaks as I could do it in WPI 1.2. When I try to call the "XP-AntiSpy.exe" with its parameters, WPI does not search for the .exe file only. It seems to search for "XP-AntiSpy.exe +0 +1 +2 +3 ...". This is why it breaks the AntiSpy Install. I "solved" this problem with an WinRAR sfx archive for the moment.

Edited July 20, 2006 by Dynaletik

[Denney]

@Denney

I was not talking about the return code of the program itself, but of the Shell.Run function, which -I imagine- could be something like

1 - command run successfully

0 - command failed

But usually things are more complicated in real life

You're right. They are. The Shell.Run command returns the return code of the program it's executing and not of the Shell.Run command itself.

Basically, it just passes the return code through.

@Dynaletik:

Your first problem, of the config file, are you using RC2 or RC1? RC2 fixes a problem of it not installing based on order number.

Your second problem is the reason Dje and I are posting here. It has to do with the way WPI v5 handles command arguments (it only searches for -'s and /'s and XP-AntiSpy uses +'s).

Personally, I've commented out the FileExists() code because I've added a FileExists() condition to ALL of my programs. Maybe make that another config file option? So the user can specify the file to look for before running the install? Or hell, make it optional.

Edit: Better idea, make 2 config file options... 1 for the command to run and 1 for the arguments to run with it. Sure, it'd break the current configs but it would make the FileExists() calls work.

Edited June 1, 2006 by Denney

[Dynaletik]

Your first problem, of the config file, are you using RC2 or RC1? RC2 fixes a problem of it not installing based on order number.

I just downloaded RC2 again to be sure, but I got that problem with RC2. I already had it.

I hope the other "bug" gets fixes for WPI 5 Final.

[Denney]

@Dje: What is the actual "rundll32" command you are using in WPI?

Edit: The reason the command doesn't work is because WPI surrounds the entire command in double quotes. Comment out the "ExtractArgs" line and replace the InstallShell.Run line with:

InstallShell.Run(cmdLine,1,true);

and it should work.

Edited June 1, 2006 by Denney

[Djé]

Edit: The reason the command doesn't work is because WPI surrounds the entire command in double quotes. Comment out the "ExtractArgs" line and replace the InstallShell.Run line with:

InstallShell.Run(cmdLine,1,true);

and it should work.

Oups, You're right. My bad.

I don't know where I had my head when I looked at this.

My 'command runner' lines now looks like:

CheckInstaller();
		if ((programs[i].cmd1 != null) && (path(programs[i].cmd1) != ''))
		{
			cmdLine=substituteCommand(programs[i].cmd1);
				WriteLogLine("Cmd1 Success: '"+cmdLine+"'");
				InstallShell.Run(cmdLine,1,true);
				programs[i].success=true;
		}

And it works perfectly on RunDLL32

The thing is now:

how to deal with buggy cmdLine(s) to make use of the loging feature?

Edited June 1, 2006 by Djé

[Denney]

I have mine setup like this:

ReturnCode = InstallShell.Run(cmdLine,1,true);
				if (ReturnCode)
				{
					WriteLogLine("Cmd1 Fail (returned code "+ReturnCode+"): '"+cmdLine+"'");
					programs[i].fail=true;
				}
				else
				{
					WriteLogLine("Cmd1 Success (returned code "+ReturnCode+"): '"+cmdLine+"'");
					programs[i].success=true;
				}

Granted it doesn't always return the correct code but at least if gives you an idea. NOD32 and TortioseSVN are 2 programs that return non-0 return codes when they finish.

I think this is better than the old way because at least the programs get executed rather than just bypassed.

[mritter]

I see my biggest fear is being realized: how difficult it is to use shell.Run() reliably. It was never intended to be used like this; it was meant to launch programs with their paths hard-coded in, ones that never change. When you have 100s of people making custom installers things get a little dicey. I will be thinking of ideas on how to improve it. Keep the reports coming in.

Thanks, guys!

[Djé]

@Denney

Great! that's what I was looking for.

But what about if Shell.Run cannot find the command?

Won't we get a javascript error messing up everything?

I'll make some tests right now!

@mritter

Sorry for hijacking you work .

Thank you very much anyway.

[Denney]

@Dje: Yes you will and that is why I have a FileExists() condition for every one of my programs in WPI. Granted it uses up my "condition" statement but hey, it makes sure the programs are there (and I still have the greyed-condition to use).

If we're gonna stick with the Shell.Run() command, I'd suggest having an option in the configuration file for an actual FileExists() condition that the user can specify. More work the end user but does prevent these errors.

@mritter: Yes, thankyou heaps for your work. At least this is better than nothing and I'm greatfull. WPI has saved me HEAPS on time in making my business run smoothly. Thankyou both (mritter and Kel) for the excellent work!

Edited June 1, 2006 by Denney

[Djé]

So if I understand well, the user would have to decide if (s)he wants to check for the existence of the file, and this for each command ... and which would fail on commands not starting with a valid path like regedit or rundll32 commands anyway.

And how does this work when there are arguments in the command? What does FileExists() say?

* Or maybe I'm mistaken and you specifically feed the file path/name to FileExists(), not just tick a checkbox to validate the command.

What about tweaking the FileExists() function so it would only check the existence of the whole command if the command starts with a valid path:

if FileExists(left(cmdLine,3)) then ...