Windows – How to install multiple versions of the same software

Since you've already got tools for (a) mounting NFTS from virtual drives and (b) importing registry keys in proper way, you should have no problem with deploying an offline installation of any software.

Unfortunately, there are several issues that would make it an extremely poor solution:

• You will have to analyse each product thoroughly for registry changes and file modifications.
• You will have to do it for each OS and architecture separately to get correct file and registry paths.
• With each new version of the software, all the work will have to be done from scratch.
• Since likely no one does it on a regular basis, you'll find no resources over Internet, neither out of the box solutions nor much help in debugging, if something unexpected happens.
• Non-linear installations (ie. varying on environment, availability of prerequisites etc.) will be even more painfull.
• Debugging will be nightmare.

So, long story short, it is possible, yet unlikely worth all the trouble.

Personally I would urge you to consider an alternative solution - a software deployment system that would install predefined software packages when the VM boots up.

The software will be deployed before user or service starts work, and at the same time, you will not have to boot up OS. You will just have to maintain packages and deploy them.

Personally, I use Wpkg deployment system with Wpkg-GP windows client (a service that runs at bootup using GPE mechanism). Wpkg itself is just a JScript application hosted on an SMB or Samba share - accessible to client machines.

You will have no problems with preparing files on your nix machine. Configuration and packages are stored in simple XML files. An XML package definition contains a set of instructions for the client to run - referring to installation files stored on the SMB share alongside Wpkg. You would still need some Windows VM for package tests, of course.

Wpkg website contains plenty of package definitions and a moderately large community maintaining them. As soon as you get accustomed to the simple XML syntax, you will have no problems creating packages on your own.

And with Wpkg you use original installers. You do not have to analyse them, you just read the software manual (or Google) and find all the necessary unattended/silent install options.

And, of course, Wpkg is free :)

A bit late on replying to this question, but anyway there goes my 2 cents.

I've been using the multi-version + multi-profile dance with FF since version 2.0 or 3.0. An added bonus is profile portability between different computers and different Windows versions. Let's see the basics:

1. Install as many FF versions as you wish to, each in its own directory. 'C:\Program Files (x86)' is no longer the best option under Win7 (due to UAC), but I keep using it even so (out of WinXP bad habits). In this machine, for example, I have:

   • C:\Program Files (x86)\Firefox_26
   • C:\Program Files (x86)\Firefox_31
   • C:\Program Files (x86)\Firefox_38

2. Have a dedicated folder to store your collection of FF profiles, with one sub-folder for each profile (hopefully named in whatever meaningful way, in order to avoid confusion). Again, in this machine I have:

   • D:\TJ\Fake_subst_I\FF_profiles\Profil_12.0_Main
   • D:\TJ\Fake_subst_I\FF_profiles\Profil_12.0_PH
   • D:\TJ\Fake_subst_I\FF_profiles\Profil_19.0_Main
   • D:\TJ\Fake_subst_I\FF_profiles\Profil_26.0_Main
   • D:\TJ\Fake_subst_I\FF_profiles\Profil_31.0_discard_sessions
   • D:\TJ\Fake_subst_I\FF_profiles\Profil_31.0_Main
   • D:\TJ\Fake_subst_I\FF_profiles\Profil_38.0_discard_sessions

3. Go inside each of the install directories and make multiple copies of firefox.exe (OFC with different names – again, meaningful names!). For example ...

   • C:\Program Files (x86)\Firefox_31\firefox(v31_test_restored_profile).exe
   • C:\Program Files (x86)\Firefox_31\firefox(v31_txyz).exe
   • C:\Program Files (x86)\Firefox_31\firefox(v31_txyz_discard_sessions_bypass_Avast).exe
   • C:\Program Files (x86)\Firefox_31\firefox(v31_zyxba_bypass_Avast).exe

   • C:\Program Files (x86)\Firefox_31\firefox.exe

     1. NOTE: the plain 'firefox.exe': I use it when I want to test one specific version of FF with a 'default' profile (mostly with ZERO add-ons).

4. What follows requires a healthy dose of attention to detail; not really complicated, but it needs lots of copy-pasting and careful search & replace: have a collection of .BAT files that will MATCH some given version of FF with some given profile folder. I have some very long and convoluted .BATs which I'm not posting in full right now, but some key elements follow:

   set dir_applic=C:\PROGRA~2\FIREFO~3
   REM
   REM .BAT is happier with old DOS 8.3 filenames (when 'normal' filenames contain spaces)
   REM
   set dir_profil=I:\FF_profiles\Profil_38.0_discard_sessions
   set ff_exe=firefox(v38_txyz_discard_sessions_bypass_Avast).exe
   set coman=start %dir_applic%\%ff_exe% -no-remote -profile %dir_profil%\
   REM
   REM I don't like and don't use parm '-P' for 'profile NAMES'
   REM
   echo %coman%
   pause
   REM
   REM ... the echo+pause lets you SEE the actual command expansion before execution
   REM
   %coman%
   REM
   REM the cooked-up command has just been executed.
   REM
   

   1. If you noticed that the contents of variable 'dir_profil' do NOT fully match the path for the profile folder, it's because of a legacy portability issue that crept into my structures. It's not directly related to the question being replied to, but for completeness' sake I'll state that MY version of the .BAT files also have the following commands, beforehand:

   set real_drive=D
   set fake_drive=I
   subst %fake_drive%: %real_drive%:\TJ\Fake_subst_%fake_drive%
   REM ... so that the .BAT actually goads FF into seeing a sub-folder of D: as I:

5. The above setup allows you to run multiple combos of versions+profiles SIMULTANEOUSLY (OFC as long as the available RAM will allow).

6. Now, for each profile, you NEED to have all the following valid; otherwise, imminent BORK is guaranteed to occur, not only within one particular PROFILE folder but also within one particular INSTALL folder. You have been warned!

   • menu Tools/Options/Advanced/Update: "NEVER check for updates".
   • don't – ever – check manually for FF updates. Again – NEVER.
   • in about:config: extensions.update.enabled = false
   • check for add-on updates MANUALLY whenever you feel the need; it's advisable to check the 'view recent updates' list in the add-on manager afterwards, to get a feel of WHICH add-ons were updated each time as well as WHAT changes were done to each (probably unnecessary geekiness).

7. Heavily recommended as a GLUE to the whole strategy:

   • FEBE add-on – https://addons.mozilla.org/en-US/firefox/addon/febe/ (it allows practical and intelligent PROFILE BACKUPS – manually, automatically, scheduled, itemized and/or all-in-one)

8. More or less recommended (don't let the 'security experts' learn of this), depending OFC on your (mis)behaved browsing habits: resist the temptation to have ALL of FF's latest versions. You'd have to install each one in its own directory and have a NEW profile directory to match, as well.

9. Whenever you feel the urge to have a brand-new FF version, you'd have to follow this procedure:

   • download the new version from Mozilla.org (again, DON'T use any 'update' functionality)
   • create a NEW install folder
   • install the new FF version in the newly created folder, but DON'T run it yet!
   • run the last FF version you have been using (starting from the .BAT file, OFC)
   • on that previous FF version, update all add-ons
   • run a FULL FEBE backup of said previous FF version (it will generate an optimized .ZIP file, actually named 'whatever.FBU')
   • create a NEW EMPTY folder for containing the FF profile for the newly installed FF version
   • [OPTIONAL] use 7z to unpack the 'whatever.FBU' file (the zipped profile backup by FEBE) and unceremoniously DUMP all of its contents into the newly created empty profile folder. Note: "OPTIONAL" here means: either you DO this, towards the goal of having a COMPLETE and UPDATED version of an older profile, or you DON'T do this, towards starting with a brand-new BLANK profile. Both will work, depending on what you'd want the new profile for – and in the case of the blank profile, FF will automagically populate its basic, required elements on first usage.
   • copy the 'firefox.exe' file from the newly installed FF version into its very SAME directory, now with a meaningful name (to match the new profile folder name & purpose)

   • clone your previous .BAT file into a new one, where you'll carefully replace the contents of the following variables:

     dir_applic (if containing spaces, use its 8.3 DOS notation)
     dir_profil
     ff_exe
     

   • run the newly cloned & edited .BAT file, so that a RENAMED firefox.exe from the NEWLY installed FF version will reference the NEW just-filled PROFILE folder (while OFC totally ignoring and preserving the previous FF versions and each of their corresponding profiles)

   • this is the moment of TRUTH where FF will check all of your add-ons for compatibility, disable a few of them, recommend new versions of some others etc. etc etc.
   • whenever you're done with massaging add-ons in your newest profile, go to next item!

10. Since FEBE's settings contain a DESTINATION folder for profile backups, you should now change it from its previous value, so that from now on any new FEBE backups will get stored in a folder different from the backups of the previous FF version.

11. Generate TWO FEBE backups: one itemized and one all-in-one. Verify that both backup sets ended up in the NEW destination folder (i.e., NOT together with the backups from the previous profile-version combo).

12. Create – and test – a shortcut somewhere, pointing to the newly tested .BAT file.

13. Have a sigh of relief, and/or blame myself for such a complicated and involved procedure.

Cheers & good luck!

Edit on July 5, 2015, to clarify some issues raised in a comment by the OP to my proposed solution above:

A. If I "run one of the various firefox_xxx.exe files without specifying a profile on the command line" ... it would [try to] run the 'default' FF profile of my Windows user, i.e., the profile located inside "C:\Users\myusername". Results would be random, depending on which version is the current FF .exe running the default profile and on which version was the previous FF .exe that attempted a previous run on same default profile. Remembering, in my scheme of things, that:

• none of my assorted firefox_xxx.exe files is meant to be run without a proper .BAT file;
• my default FF profile sits there just for TEST purposes, such as comparing a cleaner FF environment with one of my typical others with dozens of add-ons, and is not meant to be used regularly.

B. The "check for updates" button is not meant to be pressed in my scheme of things. However, in a hypothetical situation where it would be pressed, the following would happen, approximately:

1. let's suppose I'm running a particular .BAT file which invokes an install of FF 31, coupled with a particular profile which has been tailored for FF 31:
2. the update would actually update the version of FF located in "C:\Program Files (x86)\Firefox_31" to, let's say, FF 39, including the ORIGINAL firefox.exe and all supporting files present in that install directory;
3. the renamed 'clones' of firefox.exe in that same install directory would REMAIN at v31, and any attempt to run any of these executables – now surrounded by a set of supporting files which are all now updated to FF 39 – would probably throw an error, or not start the browser at all.
4. the update would also scan the profile directory pointed to by the .BAT file, validating and invalidating add-ons as seen fit to be run with v39, and most likely crippling that profile directory for any future use with the original v31 it had been tailored for;
5. all my other installed versions of FF (which live each in a specific install directory) would remain untouched;
6. all my other existing profile directories would remain untouched, including any others I might have which had been made for FF 31;
7. if, for example, after this undesired update of FF 31, I then run my specific .BAT file which invokes my install of FF 38, coupled with a particular profile tailored for FF 38, everything would be still untouched and run perfectly;
8. OTOH, if I now attempt to run ANOTHER .BAT file which would invoke FF 31, coupled with a DIFFERENT profile which has also been tailored for FF 31, I might have unpredictable results – because, while this different profile directory would still be intact as a 'v31' profile, the INSTALL directory of FF 31 now contains a full FF 39 install, together with cloned .exes which have remained at v31. This .BAT file would, in this case, be calling one of the 'leftover' v31 .exes.

C. As I expect to have demonstrated above, your statement "If updating one install affects other installs ..." is not true, and therefore your conclusion "the installs are not fully independent" is invalid.

D. The lockpref approach which you've linked to is aimed to be used in an environment where there's an 'admin' which needs to prevent undesired actions by 'common users'. My solution, OTOH, is a construct created by a geek for its own use, and as such it assumes not only strict and careful usage parameters, but also an absence of other users who might bork it thru careless usage.