Supermium

[VistaLover]

12 minutes ago, NotHereToPlayGames said:

With regard to associations with protocols/files/applications, portable software isn't really about not having these associations, but rather having exact and precise finite control of these associations.
This PRECISE CONTROL is really only limited by the user's own intentions/imagination.

You are right, of course, but that "exact and precise finite control of these associations" is in practice left for "advanced" users, not "average" Windows user "Joe" (at least that's how I see it myself  ) ...

Like you, I was introduced to the PA.com format many years ago, and, actually, after an "accident" that happened during my WinXP era, when sister ran a "wipe whole C drive" virus  on then "family" desktop; after a Windows reinstall (no C drive back-ups were being taken at that time ), I had to reconfigure all re-installed programs from scratch... PA.com format appealed to me, because I could "install" many programs on a second, D, disk partition, where both the applications' binaries and their settings would reside; in the unfortunate event of a second C partition "demise", all my "portable" programs on D partition would survive...

I think most take "portable" to signify "have the app's settings alongside the app's main (binary) files, not save settings in %appdata% and/or the registry"; but "portable" also means "be able to store the app and its settings/configuration to a suitable external storage medium (USB stick, ExtHDD/SSD, etc.) and be able to transfer the storage device and use said "portable" app across many different hosts, without permanently impacting (and/or leaving traces in) each host's fie system/registry/etc. ; this is why most portable app authors advise not to establish associations of any kind with the host system the portable app is currently running on; yes, I've come across very "smart" portable launchers that clean up the host system after the app has been exited, but that depends on the exact launcher; during the years, I have seen portable-application users associating portable launchers with the host system, and this has less risk overall, but, TBH, I don't do that myself either...

Now I'm thinking of it, my advice "not to associate" was particular to the simple "Sm-Portable.cmd" batch file I posted previously  ; this isn't a proper "portable launcher" per se, so if you clicked on a URL link inside a PDF file and expected that to be opened in the "portable" Supermium "Profile", then I couldn't offer an "easy" way to do that (you'd probably have to mess with the registry, and so on) ; and the "--disable-encryption --disable-machine-id" switches were specifically added so that the portable "Profile" remains unlocked and accessible/readable across hosts  ...

[NotHereToPlayGames]

Seems NEW TOPICS are no longer allowed to be posted here at MSFN.  I know it's not just me because SEVERAL others have cited this in recent weeks.  We have to reply to current topics instead.

[NotHereToPlayGames]

On 11/22/2025 at 2:04 AM, hidao said:

I recommend Chrome++ ,but it doesn't work on XP

Today, I updated my Chrome++ from version 1.11.1 to the most-recent version 1.13.3 (due to older versions do not properly work with Chrome versions v140 or newer).

I use the launch_on_exit= feature of Chrome++.

v1.11.1 would run a .bat file on exit WITHOUT popping up a flash of a command window.

v1.13.3 flashes up a command window, cycles through the line items of the .bat file, then closes the command window.

 

How do I prevent the FLASH on, closes when completed, command window from FLASHING on, kind of an EYE SORE.

Edited 8 hours ago by NotHereToPlayGames

[NotHereToPlayGames]

3 hours ago, NotHereToPlayGames said:

Today, I updated my Chrome++ from version 1.11.1 to the most-recent version 1.13.3 (due to older versions do not properly work with Chrome versions v140 or newer).

I use the launch_on_exit= feature of Chrome++.

v1.11.1 would run a .bat file on exit WITHOUT popping up a flash of a command window.

v1.13.3 flashes up a command window, cycles through the line items of the .bat file, then closes the command window.

 

How do I prevent the FLASH on, closes when completed, command window from FLASHING on, kind of an EYE SORE.

Disregard.

Reverted to WinPenPack's launcher and using its [RunAfter] section instead of Chrome++'s launch_on_exit= section.

[VistaLover]

7 hours ago, NotHereToPlayGames said:

I use the launch_on_exit= feature of Chrome++.

v1.11.1 would run a .bat file on exit WITHOUT popping up a flash of a command window.

v1.13.3 flashes up a command window, cycles through the line items of the .bat file, then closes the command window.

... I think you've hit issue #185  , which the Chrome++ author (Bush2021) closed as "wontfix/not planned"  ...

Yes, I also believe "change/update" isn't always for the best  , but what can one do ...

[NotHereToPlayGames]

26 minutes ago, VistaLover said:

... I think you've hit issue #185 

Yep, sure enough.

My bank now forces Chrome/Chromium v140 as minimum *IF* you want to avoid two-step PITA login (ie, text or email code after username/password).

Two-step is a enough of a PITA that I just upgraded everything in the house from Chrome/Chromium v136 to v140.

Funny thing is, my bank still works with 360Chrome's v86 if you don't mind the added step of text or email code after the username/password.

"Most" of Chrome++ version 1.11.1 seemed to be working fine.  But not having it displayed in Help/About made me leary of not upgrading.

And I don't think it was applying all of the startup parameters.  I didn't keep it long enough to see just what was and was not working.

I'm okay with upgrading it to v1.13.3 but I will NOT be using its launch_on_exit feature when ALTERNATIVE APPROACHES do the job BETTER.