Hello,
First of all, as this is my first post to this forum, I want to thank everybody who participates (directly or not) to keeping this project alive, at such a high quality level. I have been using various PortableApps products for a few good years, mostly for experimenting with software that I didn't want to install. Recently I have also started to use PortableApps builds for comparing the behaviors of different releases of the same application, and I stumbled on a couple of behaviors that don't seem right.
I've been doing software development for many years, but never developed a portable application using the PortableApps platform, so these behaviors might be "by design" and I'm missing their purpose, therefore I'm using the term "issue" rather than "bug". I believe both issues deal with the Launcher, and occur when SingleAppInstance=false. I have searched the forum before posting and couldn't find anything relevant, but please don't hesitate to point me in the right direction if I missed something.
Issue 1: [RegistryKeys] "-="
Your documentation states that:
"If you do not wish to save the data of the registry key to a file but only want to keep it safe and throw away any changes, set the “file name” to -, so you end up with -=registry key location."
It all makes sense ... but I noticed that in order to achieve this desired effect, the Launcher actually deletes the specified key when it starts, and restores it when it exits. For an app that can only run "single instance", this approach is as good as any. But for apps allowing multiple instances (installed and portable), the initial deletion is a problem, as it "steals" the respective key from the running application. I think that in such cases (multiple instances) the initial key deletion shouldn't be done. However, if there are developed apps that depend on this behavior, maybe you can add a different specifier (i.e. "~=") that would allow the key to survive.
Issue 2: Instance name detection
If SingleAppInstance=true, the Launcher seems to check the process tree, and if it finds any process using the same .exe name as the one it is trying to start it gives the "single instance" error message. If no other instance is running, the Launcher starts the program and it remain active (probably monitoring the process tree) until the process (tree) it started ends, at which point it does the required cleanup and exits as well.
Now if SingleAppInstance=false, it skips the initial process tree search, but otherwise it does the same thing as in the other case. Unfortunately, when monitoring the process tree to detect if the launched app has finished, it seems it is using only the .exe name to identify the processes it monitors and not its full path-name. As a result, if the installed program is still running, the Launcher doesn't notice that its own app has finished, and will only do the cleanup after the installed program finishes (with possibly undesired results if it has to deal with the Registry). I can't see any benefit of this approach, so, if you agree with this opinion, please adjust the Launcher's code to do the proper checking. I haven't tested that, but, by similarity, the SinglePortableAppInstance=false might suffer from a similar issue (please check).