The default value of the section [SinglePortableAppInstance] is false, i.e. it's possible to run multiple instances of the portable app simultaneously. For the following considerations we will call the portable app suitable "multiple_instances". Furthermore we assume, that this app stores its settings in the registry key HKCU\Software\Publisher\multiple_instances. Accordingly the following code is necessary for making this app portable:
[Activate] Registry=true [RegistryKeys] multiple_instances=HKCU\Software\Publisher\multiple_instances
Now we start the portable app twice, whereas we will call the 1. instance "multiple_instances_1" and the 2. instance "multiple_instances_2". After starting "multiple_instances_1" we make some alterations in the settings. These settings will stored in the above mentioned registry key. If we now start "multiple_instances_2" additionally to the already running "multiple_instances_1", the multiple_instances_2 will perform a backup of the settings of "multiple_instances_1". Furthermore we make some alterations in the settings of "multiple_instances_2". This has the consequence that "multiple_instances_1" now uses the same settings as "multiple_instances_2". Consequently, it is impossible that the two instances simultaneously use different settings.
Finally, I would just say something briefly on the changes in the registry. In another thread with the subject "Question regarding the registry" I've reported in more detail about that topic. In particular, I created there a tutorial consisting of 10 steps (see under the comment with the subject "revision of the instructions"). Under No. 6 -8 I described the changes in the registry after the closure of the app. However, if I apply these considerations to the above case, this will lead to a contradiction. If for example I have closed "multiple_instances_1", then according to the No. 8 the registry key "HKCU\Software\Publisher\multiple_instances" will be deleted. But that is not possible since "multiple_instances_2" yet runs.
Visit the Community page
Join our forums
Subscribe to our email newsletter
Subscribe with RSS
Follow us on Facebook
Follow us on LinkedIn
Follow us on Twitter
Follow us on Mastodon
Follow us on BlueSky
When launched a second time, PAL will start and exit, leaving a second instance of the app running but only the single, first instance of PAL. The 2nd instance of PAL will not touch the registry. The first instance of PAL will then wait for both instances of the app to exit before cleaning up. PAL doesn't just do an ExecWait on a single instance and then exit. It waits for all running instances of that app.
Sometimes, the impossible can become possible, if you're awesome!
Suppose I close the first instance "multiple_instances_1" with the special settings that we call "settings_1". Afterwards I close the second instance "multiple_instances_2" with the special settings that we call "settings_2". Because of your statement the PAL waits until both instances are closed before cleaning up. Accordingly, in both instances only the "settings_2" saved.
Is my above statement true, that it is impossible that the two instances simultaneously use different settings.
But it is exactly the same as running two instances of a locally installed application.
If they are both running from the same settings files, they are both running from the same settings. The exception to this is where the setting changes are in-memory and have not propagated to both instances:
Two instances cannot save different settings and two instances cannot start with different settings, but they may (depending on the base app) use different settings while running.
Regarding your remarks under No. 1 - 4 I've the same thoughts. As you mentioned under No. 3, the changes of the settings in instance 1 are only present in the working memory and these settings may not have been written to file/registry, or may not have been read from file/registry by instance 2.
winterblood wrote ...
These findings follow from the assumption, that you are starting the same launcher twice. But let me consider the following case. You install the same portable app in 2 different folders folder1 and folder2. Now you start the portable app within folder1 and close it with the settings called "setting1". Afterwards you start the portable app within folder2 and close it with the settings called "setting2". In that case it's possible, that two instances start with different settings. But how John mentioned above, only one instance of the PAL will remain open. And this one instance of the PAL waits until both instances of the base app are closed before cleaning up. Accordingly, in both instances will only the same settings saved.
Yes, I was assuming two instances of the same installation.
Regarding two instances from different installations, it depends on the app. For something like Pencil Project, it uses a profile from within the Data directory thus multiple instances can successfully co-exist with different settings.
Multiple instances of an app using resources in %AppData% would not be so successful as every instance after the first would use the settings of the first.
I am under the assumption that instances after the first would not lose their settings if the instances were shut down in the incorrect order though, as I would expect the Launcher from the first is still the only one running, and thus would only overwrite the settings of the first installation (I haven't tested it though).
But there remain one important question, if we speak about multiple instances of an app. Does that mean, that someone start the same base app twice? Or does it mean, that someone starts the base app twice, whereas these same base apps will be stored in different locations? Or is there no difference between these two cases?
Like a local app, it's up to the app how it handles its settings with multiple instances. Including multiple installs and instantiations of the same EXE. On our end, we just ensure that we keep the portable bits portable. If the EXE steps on its settings when you start multiple instances, then its the app's problem, same as it would be with a local install.
Sometimes, the impossible can become possible, if you're awesome!