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).
Visit the Community page
Join our forums
Subscribe to our email newsletter
Subscribe with RSS
Follow us on BlueSky
Follow us on Facebook
Follow us on LinkedIn
Follow us on Mastodon
Follow us on Twitter
The first issue is, I think, due to a misread of the purpose of this directive. Multiple separate instances of an app run from different locations (one local, one portable) that tried to share the same set of settings would likely step all over each other and just wipe out each other's settings. There's really no way for most apps that use the registry to run as multiple instances unless the apps themselves specifically support it. And you generally wouldn't want someone's local settings for an app polluting your portable instance either. This -= directive is for keys that don't need to be save to a .reg file between runs. Keys which don't contain settings you wish saved. It is not used for keys containing settings, since you DO want those to be saved to a .reg file at the end. About half our apps that use the registry use this directive, so dozens of official releases.
The second issue is by design due to legacy reasons. The plugins for NSIS only did instance checking based on filename and not full path because that's what was needed. As a general rule, this doesn't affect any of our apps. In order for it to be an issue, the app would have to (1) start multiple separate instances of itself, (2) not have the primary instance started by the launcher be the last running instance, (3) allow separate instances of the app to be run from different locations and use different settings files, and (4) not use the registry as that would cause settings collisions between instances. None of our released or test apps fit these criteria for this to be an issue at present. There may be a couple apps that incorrectly have SingleAppInstance set, which we should be made aware of.
We'll likely be introducing a more fine-grained check to see if the app is still running via some custom code rather than relying on the NSIS features in the future.
Glad you're enjoying our apps so far. Please keep working, asking questions, and help us make things even better.
Sometimes, the impossible can become possible, if you're awesome!
Thank you for the quick and very clear answer.
Unfortunately it seems I have the bad habit of systematically finding myself on the "wrong side" of "typical use". You are right to assume that the SingleAppInstance=false was not part of the original package. It was added by me, on the assumption that "I know what I'm doing" (the Registry pollution was a non-issue in my tests) ...
I have looked at some app virtualization solutions, but they all lack the "critical mass" of community developers that PortableApps has. I know that (in most cases), virtualizing or "portabilizing" a software product is not rocket science (if done with the right tools) but I also know it is a tedious exercise that needs a lot of "creative" testing to make sure it works OK in all circumstances (I've done it a few times). However, the concept of "virtual app" is more generic than "portable app", so maybe in some future the community that is so helpful in dealing with one portable app or another, may reuse some of their work towards virtualizing them as well.
I have written a small program to help me deal with the Launcher's name confusion, described in my previous post. In case anybody wants to try it, it is hosted on Bitbucket at:
http://bitbucket.org/vd_projects/exec_skip_dots/
The landing page offers more details on how it works and how it is supposed to be used. I released it as open source, so its source can be downloaded from there as well and tweaked if neded.
This program ONLY helps solving the Launcher's name confusion. All other issues related to running multiple instances/versions of a program concurrently have to be properly taken care of BEFORE trying to use it!