I know this is 'crazy' but still. Would the 'calling' PortableApp interfere with the 'called' PortableApp in any way ?
New: Kanri (Oct 9, '24), Platform 29.5.3 (Jun 27, '24)
1,100+ portable packages, 1.1 billion downloads
No Ads November!, Please donate today
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
Are you talking about creating a new PortableApps structure around an existing PortableApp (you should never need to do this, everything you could possibly want is already covered by one Launcher) or are you talking about creating a PortableApps version of an app that calls another PortableApp?
yes i know it is normally never done. but i would like to try out something.
i have a portable app, say papp2, that works OK. I want to create another portable, say papp1, that treats papp2 as just another program.
ie. I would end up like this :
papp1Portable.exe
help.html
App
....AppInfo
....DefaultData
....App2
........papp2Portable.exe
........help.html
........App
...........AppInfo
...........DefaultData
...........app2.exe
.........Data
.........Other
Data
Other
I honestly can't think of a single reason that could be beneficial in any way.
If you are doing nothing other than wrapping an existing PortableApp in another PortableApp structure you will gain no benefit whatsoever, you will just increase the filesize of the installer and make more work for yourself if you ever need to update it.
If you are actually placing something other than just the existing PortableApp in the package (eg. another app that would make use of the existing PortableApp) why don't you just point the new app to the existing app's location and have them happily co-exist with or without each other (which we already do in a number of cases)?
Say I want a portable firefox that has both 32 & 64 bit versions. The 32 bit version is available here so I would not need to create it. There is a portable version of Cyber fox (64 bit) too. So what I can do is have the 'calling' portable app run portable firefox if the OS is 32 bit, or run portable cyberfox if the OS is 64 bit.
You'd want to modify Firefox Portable to use PAL and a dual-mode setup, not repackage Firefox Portable.
It's not worth doing, though, as the Firefox 64-bit builds on Windows are very, very buggy, which is why Mozilla won't even classify it as alpha quality. All of the '64-bit versions of Firefox' are subject to the exact same bugs as they're just taking the 64-bit version of Firefox that Mozilla already produces and building it with different compilers or different compilation options. None of them are actually fixing any of the bugs.
Sometimes, the impossible can become possible, if you're awesome!
OK, but it's not really about FF. I would like to know if the portable-within-a-portable thing would work.
If you tell us what your specific use case is, we can help you do it the right way, instead of trying to hack one PortableApp into another.
Actually i was looking at getting cyberfox posted here, So my portable version users could benefit from auto-updates when i release a new version.
You should give cyberfox a try its not like mozilla's x64bit builds.
Hopefully it will be welcomed by this great community.
All of the 64-bit Firefox apps are just rebranded versions of the Mozilla Firefox 64-bit builds with different build options applied. Mozilla specifically hasn't released a 64-bit version of Firefox because the codebase itself is considered too buggy (pre-alpha quality). I have never seen an x64 Firefox variant that has any bugfixes on top of the actual Firefox code base. As such, it will have the exact same pre-alpha-quality issues that the Firefox x64 unofficial builds do.
Sometimes, the impossible can become possible, if you're awesome!
Hi john
are you able to point out what these bugs are in cyberfox so i can fix them, Thank you.
Unless you've applied patches to the Firefox codebase before building (which it would be silly to do rather than just submit them), it has all the bugs of the Firefox 64-bit builds that Mozilla deems it unfit for release. Here are some of them from a tracking bug. There are also many others that are untracked because the tracking system doesn't do a good job of distinguishing 64-bit-specific bugs. You'll also note that quite a few bugs in the tracker are solved as Mozilla is moving towards doing a 64-bit build for Windows at some point in the future. They won't do this until it's stable enough, though.
Sometimes, the impossible can become possible, if you're awesome!
Hi mate have you tried cyberfox, It's not just a recompile of there code with x64bit settings, i fix quite a few bugs and do allot of code tweaks for better performance so far the only issue with cyberfox x64bit is the limited plugin support like quicktime ect.
I work on this project 24/7 to provide fast and stable releases, All i wanted was to provide my user's with an update option and an easier way to download it.
But seems x64bit and firefox variants are not welcome here witch is a huge shame.
You really should try it before putting it in the same bag as x64bit nightly's.
Thank you for your incite I will let my userbase know that the portable apps platform is not going to be a via option.
Did you fix some of the bugs I linked to? If so, did you submit patches to Mozilla?
I have not tried Cyberfox, but I've yet to see any x64 build/rebrand of Firefox that fixes any of the bugs that Mozilla deems as important enough not to even offer an alpha release. If you have, I'd love to know about it and put you in touch with the Mozilla folks so you can submit patches upstream.
As for 64-bit-only apps, we don't accept them for inclusion in the Portable App Directory. When you use portable software, as you move from machine to machine, you have no idea whether each machine will be 32-bit or 64-bit, so Cyberfox would fail on (seemingly) random machines as the user moves around. This makes for a poor user experience.
At PortableApps.com, we support 64-bit software, but only with what we call dual mode apps. These apps have both the 32-bit and 64-bit versions of the app in the same package. We started doing this back in 2010 (the reasons are in the link). We do lots of 64-bit apps now wherever they net a good performance boost relative to the app size increase (7-Zip, PeaZip, etc), offer better features or functionality (RawTherapee, AkelPad, Notepad2, etc) or are required to properly support all machines (jKDefrag, PeerBlock, Explorer++, etc). It's just all handled automatically and transparently, so users don't need to worry about it.
If you'd like to package Cyberfox up as a 32-bit and 64-bit build, we'd love to make it available in our app directory. But 64-bit-only apps are currently not permitted due to the poor user experience in terms of using software portably. Remember, lots of portable users use all kinds of PCs outside of their control (work, school, library, hotel, friends, relatives, net cafe, etc). These PCs run the gamut from Windows XP to Windows 8 and include lots of 32-bit and 64-bit variants. The apps we make official have to work on all of them.
This can result in some extra work sometimes. For example, PeerBlock Portable includes 4 different versions in a single package to switch automatically between 32-bit XP, 64-bit XP, 32-bit Vista & up, and 64-bit Vista & up. So, it's a lot more work to build and test than a regular app. But, we think it's worth it so our user's software works everywhere without them needing to worry.
Sometimes, the impossible can become possible, if you're awesome!
Thank you for your reply im currently looking through thos bugs now and if i find any that i have fix or can find fixes for i might "Emphasis" on the might consider submitting them.
Unfortunately i don't provide x32bit version due to that's what Firefox is, And only work on x64 version.
Also cyberfox don't support windows xp only vista to 8 and no plans to.
Again thank you for your incite if i do consider making and x32bit version i will duel pack x32 and x64 and post in the beta forums.
Thank you you have left allot of food for my thought.
The only real interference I can think of is slower startup/exit times for the portable [portable]app especially if the data is larger because it needs to be copied over an additional time from the inner Data folder. Like Firefox would take a lot longer for sure as your accumulate browsing data. But basic app functionality should be unaffected.
Would the 2nd set of apps need to be actually inside the first one? If all 3 apps (2 'real' ones and one 'caller') were all installed normally, then wouldn't the 'caller' just be launching one of the other two apps? Kinda like a mini menu would?
Michael D. Shook
You can write a launcher that runs an app from the parent directory or higher; the 2nd set of apps does not need to be inside the first one.