Multiple BMS Installs
-
I read in another post recently that having multiple installs of BMS is not supported and should be done at our own risk as it potentially drives you off a cliff. This is news to me as it had been a standard practice for many years and, as far as I know, never caused any issues. Maybe it’s the way we have instructed our Wing members to do it or maybe something has changed or maybe we’ve just been lucky but I wanted to see if we could get some clarity on this and make sure the reason many do this is clear to the Dev team (and others). My hope is that we can find a safe way to test out new releases while still providing an easy way to go back if needed.
I’ll start with why I feel this is needed. Quite simply, many of us have ongoing campaigns, new pilot training or just regular routines of flying online with each other and when new releases come out we want to make sure that we can continue those routines while still learning the new features, etc. while waiting for everyone else to come up to speed. Some people barely have enough time to fly and they need to make time to do an upgrade and learn anything new specific to the release. That’s were having a separate install comes in handy.
The way I have always done this is as follows:
- make a copy of the entire X:\Falcon BMS 4.XX folder…call it Falcon BMS 4.XX.Y where Y=0 or 1 or whatever.
- Run the updater (recently) in the original 4.XX folder or do the old red setup.exe to upgrade after downloading the new bits
This would give me the latest version to play with. If I needed to run the previous one, say for a Wing flight with others who have not upgraded yet, I would simply rename the 4.XX folder that has the latest to 4.XX.Z and rename the 4.XX.Y back to just 4.XX. And to go back to the latest, just reverse the process.
To my knowledge, that does not change any references in the registry and BMS is none the wiser and doesn’t even know about the other versions on the disk (admittedly if new entries where made or values changed to those only supported by the latest version there could be a problem). To be clear, I would never run BMS from any folder other than its original 4.XX folder.
To the Dev team or others that REALLY KNOW what the code, libraries, registry entries, etc. all do and expect, is this a dangerous practice? And if it is, can you recommend a way for people to try out a new release of BMS while still preserving a practical option for going back and forth so that Wing operations can continue while some people test out the new release and prepare new TEs, campaigns, etc.?
-
@Zeus As far as I understand its ok to have seperate installs of different versions
(4.35+4.37) but risky to have dual installs of the same version for registy reasons. I clone my drive then install so I have a backup. -
@Zeus sure that works, that’s essentially how I do regression-testing…
not saying it doesn’t work, just saying it’s too error prone and confusing for us to say it’s supported… especially when people complain about the updater not working, which seems highly likely caused by running from the wrong place – but again there’s no way for us to know that or repro that
it’s like Linux… I personally love that people are running BMS on wine/linux, and offer support to one another for that here, but BMS team is not testing that, so we can’t reasonably say we support that
if we intend a release to be supported sxs with older bits, we’ll give it a version bump (4.36 to 4.37) and corresponding new registry key and new folder name
but updates are meant to be in-place updates
-
@airtex2019 - Thanks, knowing its not supported because there is risk of people not doing it correctly or accidentally running things from incorrect folders makes complete sense. I get it - not everyone has the same comfort level with PCs and many a good pilot can fly a Viper while at the same time struggle with file-level changes. I have been in the IT biz for over 4 decades so I get the need to protect people from themselves.
Just glad to know that the above practice, when followed correctly, isn’t setting me up for an unknown risk or impending disaster.
Thanks again for the feedback
@Icarus - thanks for your feedback too…I’ve scoured the registry and there isn’t anything in there that would indicate a potential problem or favor why major update vs minor update would be better or worse than the other. And based on @airtex2019 comments, it sounds like care is taken to make new entries when needed.
-
@Zeus to be clear, for IT-savvy folks comfortable with their ability to handle this, I love that you’re doing it – it means you’re able to help me regression-test bugs reported here
But the burden of support shifts a bit… if you encounter a weird CTD or problem that nobody else is hitting, the burden of proof goes first to you, to verify / repro the problem on a clean install.
And it probably also means you should sign up to be a beta tester because that is basically the hardest part of that job.
-
@airtex2019 - responsibility understood (and accepted). Would be happy to help test any time.
-
The primary concerns when running multiple installations of a software application typically revolve around registry settings, shared libraries, and potential conflicts. Some applications store configuration settings in the Windows Registry. If these settings change between versions, running multiple installations might lead to conflicts or unexpected behavior. Associations between file types and the application might be managed centrally. Running multiple versions could lead to confusion about which version should handle certain file types.
-
@Zeus It is more an issue for people who do it and don’t accept the cosequences as the update process can only sustain a single registry location…
I am not happy to lose time investigating over a case where someone that mess-up with the install and is not disciplined enough to manage and maintain this.
My time is precious and when someone comes with install issues it falls on me and I just don’t have the time to deal with frankenstein situations.
So I will reject non compliant installations support requests in the future.
That’s all
-
Hi, Zeus. When U3 came out I wanted to maintain a working U2 for testing purposes. While there are probably several ways to do that, I was shown a simple way that bypasses any issues. I made a copy of x/Falcon 4.37 and renamed it Falcon 4.37.2. Then , I updated the original to U3.
The launcher only recognizes “Falcon 4.37” , so no reg. issues or problems like Max infers. To fly U2, I just rename 4.37.2 to 4.37 and U3 to 4.37.3, and vice versa to swap back for U3. While it’s admittedly a “back yard mechanic “ solution, I have found it fail safe -
I think it’s funny, though…I had asked a question on this subject about the non-compatibility of TE and Campaign 4.37.2 …apparently, for the ITO theater, it recommends 2 installations for conversion.
I find that crazy!