[Outdated] PortableApps.com Launcher 1.0 Alpha 4

I have two questions.
Sorry if they are noobish questions.

First. Will this be a supported Portable App format.
Second (depends on the first). Will it become the Portable App format, or will we have a choice of the format we want?

Is this designed to gracefully upgrade apps?
What I mean is, how will it allow devs to release upgraded apps that will preserve the settings from the previously installed versions?

Like when you upgrade Firefox and it keeps your personal links and settings?

(I understand that it won't work upgrading an app that was previously created with CPAL)

Would it be okay to rename the launcher to AppNamePortable.exe? I'm fine with the INI being named PortableApps.comLauncher.ini (that actually makes a lot more sense), but having a bunch of PortableApps.comLauncher.exe in Task Manager would be confusing (what if God forbid I need to kill one? "Okay, now which one is it..."), plus it'd be better for people who don't use the Platform and instead launch manually if the launcher has a meaningful name.

Just found another bug: WaitForOtherInstances will almost-certainly never do anything.
I turned on the DEBUG option, and got the message "Waiting till any other instances of ThunderUSB\ThunderStarter.exe are finished."; however, FindProcDLL::FindProc is looking for an executable name, not a path. I got bitten by this while I was trying to create a patch for a related feature, and ended up using this code to get around it:

${ParseLocations} $1
${GetFileName} $1 $1
FindProcDLL::FindProc $1

That worked, so here's a patch for WaitForOtherInstances.

		;=== Wait till it's done {{{3
			${ReadLauncherConfig} $0 Launch WaitForOtherInstances
			${If} $0 != "false"
				${DebugMsg} "Waiting till any other instances of $PROGRAMEXECUTABLE are finished."
				${Do}
					Sleep 1000
                                        StrCpy $1 $PROGRAMEXECUTABLE
                                        ${ParseLocations} $1
                                        ${GetFileName} $1 $1
					FindProcDLL::FindProc $1
				${LoopWhile} $R0 = 1
				${DebugMsg} "All instances of $PROGRAMEXECUTABLE are finished."
			${EndIf}

I haven't tested that, since I don't have any restarting apps I'm working on, but it should work.

Also, I have a patch to add a new feature: waiting for other programs to finish. Here's the patch, to be inserted immediately after the WaitForOtherInstances code and just before the Remove TEMP dir code:

        		${ForEachINIPair} "WaitForProgram" $0 $1
                  		${DebugMsg} "Waiting until $1 is finished."
                            		${Do}
                                             Sleep 1000
                                             ${ParseLocations} $1
                                             ${GetFileName} $1 $1
                                             FindProcDLL::FindProc $1
                                        ${LoopWhile} $R0 = 1
                        ${EndForEachINIPair}

To use the new feature, create a new section in launcher.ini; it should look something like this:

[WaitForProgram]
MyApp=SomeApp.exe

EDIT: it occurred to me that, since the two patches are right next to each other, I should probably merge them into one patch to make life easier for people. The comments at the top and bottom are simply for placeholders; match the comments in my patch to the comments in the launcher code, and you've got the patch placed correctly.

		;=== Wait till it's done {{{3
			${ReadLauncherConfig} $0 Launch WaitForOtherInstances
			${If} $0 != "false"
				${DebugMsg} "Waiting till any other instances of $PROGRAMEXECUTABLE are finished."
				${Do}
					Sleep 1000
                                        StrCpy $1 $PROGRAMEXECUTABLE
                                        ${ParseLocations} $1
                                        ${GetFileName} $1 $1
					FindProcDLL::FindProc $1
				${LoopWhile} $R0 = 1
				${DebugMsg} "All instances of $PROGRAMEXECUTABLE are finished."
			${EndIf}
			
        		${ForEachINIPair} "WaitForProgram" $0 $1
                  		${DebugMsg} "Waiting until $1 is finished."
                            		${Do}
                                             Sleep 1000
                                             ${ParseLocations} $1
                                             ${GetFileName} $1 $1
                                             FindProcDLL::FindProc $1
                                        ${LoopWhile} $R0 = 1
                        ${EndForEachINIPair}

		;=== Remove custom TEMP directory {{{3

Well, I've found a couple more bugs; I've got a patch for one, but I don't know about the other yet.

Bug #1: PAL tries restoring data files from their backups even though there isn't a backup to restore from.

Patch:

		;=== Save portable settings and restore any backed up settings {{{3
			;=== Files {{{4
			;=== FilesMove {{{5
			${ForEachINIPair} "FilesMove" $0 $1
				${ParseLocations} $1
				${GetFileName} $0 $2
				StrCpy $1 $1\$2

				${If} $RUNLOCALLY != "true"
					${DebugMsg} "Copying file from $1 to $DATADIRECTORY\$0"
					Delete "$DATADIRECTORY\$0"
					CopyFiles /SILENT $1 "$DATADIRECTORY\$0"
				${EndIf}
				${DebugMsg} "Removing portable settings file $1 from run location."
				Delete $1

				${IfNot} ${FileExists} "$1-BackupBy$AppID"
					${DebugMsg} "Moving local settings file from $1-BackupBy$AppID to $1"
					Rename "$1-BackupBy$AppID" $1
				${EndIf}
			${EndForEachINIPair}

should be

		;=== Save portable settings and restore any backed up settings {{{3
			;=== Files {{{4
			;=== FilesMove {{{5
			${ForEachINIPair} "FilesMove" $0 $1
				${ParseLocations} $1
				${GetFileName} $0 $2
				StrCpy $1 $1\$2

				${If} $RUNLOCALLY != "true"
					${DebugMsg} "Copying file from $1 to $DATADIRECTORY\$0"
					Delete "$DATADIRECTORY\$0"
					CopyFiles /SILENT $1 "$DATADIRECTORY\$0"
				${EndIf}
				${DebugMsg} "Removing portable settings file $1 from run location."
				Delete $1

				${If} ${FileExists} "$1-BackupBy$AppID"
					${DebugMsg} "Moving local settings file from $1-BackupBy$AppID to $1"
					Rename "$1-BackupBy$AppID" $1
				${EndIf}
			${EndForEachINIPair}

Bug #2: for some reason, PAL really struggles with copying multiple files. Regardless of whether I use a wildcard (*) or explicitly list each file, something invariably gets left in App when it should get moved back to Data. No idea what's up with this one yet.

Shouldn't you remove the sample stuff from DefaultData? It's pretty unprofessional if this is going to become an official release. The sample launchers are fine as they serve as a nice point of reference for new users, but the sample DefaultData files are useless.

Also the "virus" joke in the sample launcher.ini, while funny, might be seen by some as being in poor taste and should be taken out.

I'm currently upgrading my Inno Setup launcher to PAL from CPAL Test 5, but I found I'd like a certain behavior that I can't achieve currently: Inno Setup uses the registry, so obviously you don't want the portable to run at the same time as a local copy, or they'd step on each other's toes. The problem is that if I set SingleAppInstance to true to accomplish this, now I can't run multiple portable instances either, when that would otherwise be fine.

Also, any chance you could update the help.html to list the default values for each of the launcher.ini directives? It'd help me immensely when deciding whether or not to add a directive if I knew what its default value was (this way I could leave it out if the default was okay).

Edit: Okay, I just noticed you have the default values bolded, but that's too subtle; especially with the values in monospace, the bolding is almost invisible. A format like the one used in the Inno Setup docs would be better:

KillEmAll (values: true or false - default: true)

Less confusion that way too, as the intent of the bolding--even if you do notice it--isn't immediately obvious.

Edit 2: In the documentation for WaitForOtherInstances: "If the application can restart itself at all, e.g. Firefox can, DO NOT set this to true..." Don't you mean "DO NOT set this to false"?

Apparently help.html needs a serious once-over. I just found another error--the example for DirectoriesMove:

AppName=%APPDATA%

Given the description of how DirectoriesMove works ("%DATADIRECTORY%\from\*.* gets copied to to\*.*"), won't that cause the user's entire %APPDATA% tree to be copied to Data\AppName? That could be a disaster if someone actually tries that example.

Edit: Hmm. Apparently the splash screen wreaks havoc with full-screen games. I tried using PAL to portabilize the RPG I'm working on, but if the splash doesn't disappear by the time the game starts, when PAL finally hides it it causes the game to minimize itself. I then have to click its taskbar button to pull it back up.

I'm making a launcher for HxD and I just discovered a pretty big bug: It seems if you have a DefaultData which doesn't contain AppNamePortableSettings.ini and launcher.ini specifies drive letter substitutions, all bare slashes are replaced with the drive letter. To illustrate, this is what HxD.ini normally looks like:

[\Position\FormMain\]
Left=25
Top=25
Width=720
Height=400
WindowState=3

[\]
...

etc.

Well, when the launcher gets hold of that, the file ends up looking like this instead:

[L:\PositionL:\FormMainL:\]
...

[L:\]
...

etc.

So yeah, you might want to fix that. Note that after the first run it's fine (since the launcher has since created AppNamePortableSettings.ini with the correct drive letter), but it does screw up the initial state for the first run.

The launcher.ini for my NoteCase launcher:

[Launch]
ProgramExecutable=NoteCase\notecaselauncher.exe
WaitForEXE=notecase.exe
SingleAppInstance=false

[LiveMode]
CopyApp=true

[FilesMove]
settings\notecase.ini=%APPDIR%\NoteCase\config

[FileDriveLetterUpdate]
Backslash1=%DATADIR%\settings\notecase.ini
Forwardslash1=%DATADIR%\settings\notecase.ini

How NoteCase's own portable version (which I'm using for this) works is that you run notecaselauncher.exe, which in turn runs notecase.exe then quits. This is why I have WaitForEXE=notecase.exe in [Launch]. Problem is, PAL isn't waiting for notecase.exe--once notecaselauncher.exe terminates, PAL quits.

Maybe you could include the possibility to only backup/restore single registry values and not only whole keys.
This would be important for example for the Run key. For portable applications this is of course not needed, but some applications may tend to rewrite this every run.

I think another good idea would be the possibility to enable a progressbar as some applications may need lots og registry keys to be copied which might take a long time. Or a least something showing that the launcher didn't just freeze.

At least the first point I think would be really important. I'll look at the PAL and maybe port my (and radarman36's) Steam Portable dev test to it.