You are here

Home » Forums » General Forums » General Discussion

Portability as I understood it so far, and making PortableApps defaults

3 posts / 0 new
Log in or register to post comments
Last post
October 13, 2016 - 3:36pm
#1
mupan
Offline
Last seen: 7 years 6 months ago
Joined: 2009-04-22 02:15
Portability as I understood it so far, and making PortableApps defaults

I am a bit confused now that I read some discussion in the net and here in the forums about that topic, and viewed and changed some registry keys.

I found on stackoverflow that in HKEY_LOCAL_MACHINE\SOFTWARE\RegisteredApplications\ (registry) and the there called registry keys the contents of the Default Programs lists is defined. So I concluded that when I have difficulties to make a PortableApp a default because it will not appear in the open with list even if I browse the .exe it's because I need to change the \command\ keys in here and let Windows Default Programs list fix the rest. This is true for Windows 7 at least.

I am currently testing if that works for Firefox Portable. I would prefer that manual method from any .exe that does the same job for me because I cannot download or transfer an exe to a system I administer in a foreign domain just for the purpose of changing defaults, but I often can edit the registry. And I trust a script (.reg, .ps1) I can edit more than a compiled .exe.

I sometimes read ...\PortableApps\FirefoxPortable\App\Firefox64\firefox.exe and sometimes ...\PortableApps\FirefoxPortable\FirefoxPortable.exe as .exe for entries in HKCU\Software\Classes\ resp. HLKM\Software\RegisteredApplications\. ...\PortableApps\FirefoxPortable\FirefoxPortable.exe would have been my first guess because I understood that this invokes the portability magic: Either have the program use an .ini for the settings if it is designed to give the user a choice where to store the settings, or start the program.exe in an environment where it can send and receive registry communcation by the ProgramPortable.exe wrapper while that wrapper in fact translates the registry calls to ini read and write commands.

I learned though that e.g. Irfan view can only be associated to .jpg and Co. with ...\PortableApps\IrfanViewPortable\App\IrfanView\i_view32.exe as the command to run, while, on the other hand, Firefox loads another profile when it is run via ...\PortableApps\FirefoxPortable\App\Firefox64\firefox.exe, different from the one that is loaded by calling ...\PortableApps\FirefoxPortable\FirefoxPortable.exe, so I use FirefoxPortable.exe paths everywhere. Maybe the answer is: Depends? Bad

Now my questions:
* According to your experience, is my assumption right that editing HKEY_LOCAL_MACHINE\SOFTWARE\RegisteredApplications\ and using the GUI to change the default works best?
* Shouldn't I use the ...\PortableApps\AppPortable\AppPortable.exe to register file extension associations or registered applications? At least where that works.
* Shouldn't it be standard in PortableApps apps that ...\PortableApps\AppPortable\AppPortable.exe passes every parameter given by user or system (filename, switches) to the actually called .exe?

Top
October 14, 2016 - 12:37am
Gord Caswell
Gord Caswell's picture
Offline
Last seen: 4 months 4 weeks ago
DeveloperModerator
Joined: 2008-07-24 18:46
Read, will reply

I've read your questions, but I personally won't have time to respond to them in enough detail until Monday. In the meantime, someone else may be able to tell you what you need to know.

Top
October 14, 2016 - 4:16pm
mupan
Offline
Last seen: 7 years 6 months ago
Joined: 2009-04-22 02:15
Even more details, and hopefully clearer

Hello all,

@Cord: Thanks for reading it anyway Wink

I've tested a bit more.

I ensured the paths in the HKLM\Software\Clients\ registry branch are all pointing to ...\FirefoxPortable.exe and not ...\firefox.exe. I think running ...\FirefoxPortable.exe /SetAsDefaultAppGlobal does the same job (passing the parameter to helper.exe). Then ran Default Programs again and made Firefox the default for all its capabilities, i.e., .htm[l] and Co. and the http[s] protocols, as defined in HKLM\Software\Clients\.

Now when I closed all Firefox instances and click a link in a mail in Thunderbird, the portable Firefox runs, but bypassing FirefoxPortable.exe. When I started FirefoxPortable.exe before, Windows opens the link requested by TB in my already opened session (as I would expect), and since FirefoxPortable.exe does its job of virtualizing registry for firefox.exe, cleaning up the registry and sync'ing with prefs.js after shutting down, and what it does to portabilize FF, this does not break portability, right?

PS lnk:\> Get-Process *firefox* # FirefoxPortable started before

Handles  NPM(K)    PM(K)      WS(K) VM(M)   CPU(s)     Id ProcessName
-------  ------    -----      ----- -----   ------     -- -----------
    703     137   624972     577372  1121    22,00    536 firefox
    146      14    37408       9196   121     0,08   7064 FirefoxPortable


PS lnk:\> Get-Process *firefox* # FirefoxPortable not started before

Handles  NPM(K)    PM(K)      WS(K) VM(M)   CPU(s)     Id ProcessName
-------  ------    -----      ----- -----   ------     -- -----------
    701      92   284492     220896   655     3,01   4424 firefox

So I change my questions / theses:

  • It seems to me that opening links by Windows Default Program feature can break PortableApps portability, if I understood the function of the AppPortable.exe wrappers right. If a program has its own default user choice management, like Firefox, no problem. True?
  • If that's true, the only way to open links in a portable Firefox is to not just click links in programs that use Windows Default Programs feature, but either
    • »Copy Link Location« in context menu, start / focus FF portable, open a new tab {Ctrl+T}, paste the link in the then focussed address bar {Ctrl+V}, and go {Enter}, or
    • ensure \App\firefox.exe or FirefoxPortable.exe is defined in every path in HKLM\Software\Clients\, by manual registry edit, helper.exe /SetAsDefaultAppGlobal or any third party tool, set Firefox in Default Programs the default everything it's capable of, and run FirefoxPortable.exe before clicking any link in a program, that uses Windows Default Program management, and not its own.

    True?

  • If that's true, it's true for FF, but not necessarily for other PortableApps. Irfan view is now an example for a non-critical app. It has changed in that regard or I did not understand it right when I tested it years before: I tested it now and changed the Windows default for .jpg to the Irfan view Portable launcher. Press enter on a selected .jpg now opened it successfully in Irfan, and both IrfanViewPortable.exe and i_view32.exe are started.
    PS lnk:\> (Get-Process *irfan*).Path
G:\util\PortableApps\IrfanViewPortable\IrfanViewPortable.exe
PS lnk:\> (Get-Process *i_view*).Path
G:\util\PortableApps\IrfanViewPortable\App\IrfanView\i_view32.exe

    So I think in the case of Irfan using the convenient Windows Default Programs is OK. What do you think?

  • I think breaking portability is too easy. I had the job to clean up systems where the self-update of firefox (not of the PortableApps platform) had messed the clean portable usage, and making the portable app the Windows default is a risky undertaking as well. What do you think?

Not WhatsApp: mupan@swissjabber.org

Top
Log in or register to post comments