Mostweb browsers are installed in Windows as 64-bit versions by default, Firefox being the exception. If you installed the default download of Firefox, you have the 32-bit version, not the 64-bit version, even if you're running a 64-bit version of Windows.
Say you recently got a new Windows computer. After installing the 32-bit version of Firefox from the main page, you installed your favorite add-ons, restored your backed up bookmarks, and even set up multiple profiles for personal and work purposes. But, now you want to upgrade to the 64-bit version of Firefox for better performance. You could uninstall the 32-bit version and then install the 64-bit version, but doing so will remove your Firefox user data, such as saved passwords, bookmarks, settings, extensions, and themes.
You could back up your profile folders from the 32-bit version of Firefox and then restore them after uninstalling Firefox and installing the 64-bit version. But that's a bit of a hassle, and there is an easier way.
NOTE: Firefox 64-bit can only be installed on 64-bit Windows. If you're not sure which version of Windows you're running, you can easily check. If you're running 32-bit Windows, you cannot upgrade Firefox to 64-bit.
Close Firefox (all windows) if it's running. Then, run the 64-bit Firefox installer you downloaded and follow the on-screen instructions to install it. The 32-bit version of Firefox on your PC will not be uninstalled.
Again, using our procedures for finding out which version of Firefox you're running, you'll discover that you're now running the 64-bit version. And all your settings, bookmarks, extensions, themes, etc. have been preserved.
As we said, the 32-bit version of Firefox is still installed on your PC. When you upgraded Firefox to 64-bit, the Firefox entries in the Start menu list and the shortcuts on the desktop and Taskbar are replaced with calls to the 64-bit version of Firefox. You don't need to do anything further, but if you want to uninstall the 32-bit version of Firefox, you can.
To do that, open the Control Panel and click "Uninstall a program" under the Programs category. Then find the Mozilla Firefox entry in the list with "(x86 en-US)" at the end. Be sure you don't select the Mozilla Firefox entry with "(x64 en-US)" at the end, which is the 64-bit version you just installed.
If you want to run the 32-bit version of Firefox by default again, simply download the 32-bit version of Firefox, run it, and follow the on-screen instructions to install it. You can use the Start menu entry and the shortcuts on the desktop and Taskbar for Firefox to run the 32-bit version again.
(/03/12/22 - EDIT:- Given that modern, Woof-built Puppies are now beginning to come with PulseAudio built-in as standard, the portables have been re-jigged. Upon startup, the 'LAUNCH' script now checks to see if PulseAudio is present on the system; if it is, one set of libs are used.....if not, a different set of libs are employed. It's all automatic, so the user shouldn't need to concern themselves as to what audio system they're running.)
Fred's original simply placed a short script, called 'ff', inside the firefox directory. That script made use of the Firefox ability to specify the location of its profile directory, so Fred used this to create the Firefox profile inside the 'firefox' directory. This kept everything together in one place, and allowed the entire browser directory to be moved from one location to another.....hence, it became 'portable', no longer being tethered to a fixed, 'standard' location.
I was very taken by this whole idea. It was a concept I'd encountered years before in Windows XP, and one which I'd always wanted to get working in Puppy. That original release of Fred's 'showed the way', as it were, and set me on a path which still has no end in sight.....
My use of the 'LAUNCH' script first came about through helping a sweet old guy over at BleepingComputer, who'd made the switch to Puppy and wanted to have a 'shared' browser he could use with more than one Puppy/machine. So I used the then current Firefox ESR, basically using Fred's layout, but with the clearly labelled 'LAUNCH' script at the top 'level', pointing to the 'ff' script inside. (He admitted he wasn't very good with Linux, and he was so nice - and very polite with it - that I did what I could to make it easier for him). Hence the 'LAUNCH' script.....and by placing the entire thing on a suitably-formatted flash drive, it was totally portable, and he could plug it in & use it anywhere he wanted.
Since then, I've also added the ability to add a Menu entry from wherever the portable directory has been located. MenuAdd & MenuRemove scripts are self-explanatory, and the 'MenuReadMe' explains how to use them effectively. When the add/remove scripts are used, 'fixmenus' runs, followed by 'jwm -restart' (or better still, 'jwm-reload').....same as Puppy does when installing packages (which doesn't close anything you may have open.)
Fred's 'ff' script and my 'LAUNCH' script have been combined, along with now creating the 'profile' directory at the top 'level. With the 'extralibs' directory - for the PulseAudio emulation stuff - also now living at the top 'level', nothing extraneous remains within the firefox directory.
Cons
As for me, I prefer having profile data separate from the application. That way I can use Puppy's savefile encryption, and not need to worry about defining data/config paths for each application. Also, having an app like Firefox or Blender in a SFS file can save hundreds of MB. If there are many "portable" apps loaded, doing user data backups can be difficult. Applications might bebacked up with data, which can increase the backup size hundreds of MB. Finally, sometimes I have different versions of VirtualBox, LibreOffice, Blender, etc. which have features that work better in older/newer versions. It's easy to load/unload SFS files, AppImages, etc. on-the-fly.
Pros
Now back to the postives of the "portable" method. This "portable" method does have merit for "roaming" user data via USB stick sneaker nets. Your "portable" method I think would be more valuable if it was inside a mountable disk image container, using something like Veracrypt or LUKS. This locks down people having access to your bookmarks, passwords, etc. that are stored in a browser.
Possible Alternative
Data and Profiles Separated
Have any data that is to USB roa in a Veracrypt container
When mounting container, symlink things like /mnt/veracrypt/.config/Firefox to /root/.config/Firefox
In this way your data is always with you, and can be used on Windows, Mac, Linux, etc.
Other
One last thing. I noticed that the MenuReadMe included in your downloads says the following:
"...it will then restart "X"...."
I think it should say, "...it will then restart your window manager..." The reason being is that if X-Windows is restarted, sometimes things like opened documents aren't saved automatically. A jwm -reload or jwm -restart does not need to close apps.
It's fairly easy to provide an alternate LAUNCH script --say named SLAUNCH-- which has its own menu entry and a different profile; for example substitute "secured" for "profile" in the three places above. On occasion I've done that. What I can't do is:
Edit the LAUNCH script to create an encrypted profile folder if one doesn't already exist, and ask for and store a password; or ask for a password for an encrypted profile folder, decrypt such folder and use its contents if it already exists; adding some lines to remove/delete the decrypted folder once the password is typed; or perhaps after a short interval*. Obviously, you'd need an encrypt/decrypt application already on your system.
About Puppy's Save Encryption, unless you're using LUKS --I know you are already familiar with it-- you're using the encryption capabilities available if you choose to create a SaveFile formatted as Linux Ext2. Linux Ext2 partitions are prone to corruption. And, IIRC --never used it myself-- you're offered three levels of encryption of which only the strongest isn't easily hacked.
-=-=-=-
* My understanding is that the contents of the profile folder are read-into the application. Once that happens the decrypted folder would no longer be needed. But you'll probably also need some way to update the profile and/or change the password. At this point, I'm getting lost in the complexity.
Are you supporting and writing the LAUNCH script being used for your "portable" versions? If not, my above post is kind of irrelevant, since it was going over ideas for future features and to fix a typo.
I didn't come up with all the original content. As with so many things in Puppy, snippets of code get re-hashed, modified & re-used when they're found to work. Fredx181 was the one who started the ball rolling for all the recent (last couple of years or so) 'portable' browsers - and many other applications - that I've since produced.
Fred & I, and others, have bounced ideas, suggestions and other stuff off each other many times over the years. Many individuals have contributed bits & pieces over time, and, as I've said frequently in the past, while I will take credit for producing the packages as they are currently, I refuse to take credit for the work of others which has helped to hone many of those packages into what they are now. In so many ways, much of my stuff is a 'community' effort, at the end of the day.
On top of which, my own scripting skills are, like those of so many others, gradually getting better as time passes. 8 years ago, when I first started with Puppy, I couldn't have imagined I'd be doing a lot of the stuff I now take for granted. I'm happy to work together with a group of like-minded, similarly enthusiastic people. What I find somewhat unsettling is when a noob comes in and starts almost demanding that I begin to implement a), b) and c).....
3a8082e126