# OHMTransX 2018.05.06 MMExt2 for Orbiter 2016

#### Enjo

##### Mostly harmless
Tutorial Publisher
Donator
I see your .zip in this thread is still dynamically linked, but I assume if you go back to an ancient enough version then the OS should have shipped with it.
It is, because Windows forced me to upgrade the VS2005. It's exactly dependent on VC redist 2005 SP2. If we hear complaints, we'll work it out. First we have to start from something, and this would already be a great leap.
Happy to re-release this package down-compiled to the oldest version if that helps. We made it very backwards-compatible after all. (I remember the NULL vs nullptr discussion, for example!).
When you do, be sure to update all your links in OH. We'll finally have just one version of the library.

Last edited:

#### Enjo

##### Mostly harmless
Tutorial Publisher
Donator
The weekend is almost gone. Still no chance to replace a module?

##### Scientist
The weekend is almost gone. Still no chance to replace a module?

Standing by for Peter's results.

#### PeterRoss

##### Warranty man
Sorry, I was kinda busy lately.
Alas, still no luck:

Code:
============================ ERROR: ===========================
===============================================================
============================ ERROR: ===========================
===============================================================
============================ ERROR: ===========================
===============================================================
============================ ERROR: ===========================
===============================================================
============================ ERROR: ===========================
===============================================================

By the way, it's showing another error code, 126 instead of 193. I just tried the 2016 version of MMext as well, it shows code 126 too. Don't remember if it was this way when I first encountered the problem. Maybe I broke something trying to fix VCredist. I think I'll try to remove and reinstall all the VC packages and then report back here if anything changes.

##### Scientist
Hi Peter,
Your build is broken with no hope of recovery . Honestly, you need to rebuild a new Orbiter structure from scratch, and remove and reinstall all VC redists.

These two codes mean the following:

Error 126: you are asking Orbiter to load a DLL, and it cannot find a pre-requisite dependency (i.e. something that you can see in Depends.exe). In your case, if you are using Enjo's version of ModuleMessagingExt, it means you don't even have really old runtimes available (I forget ... VC2008, VC2005 ... whatever Enjo linked against).

Error 193: you are trying to force your 32 bit Orbiter.exe to load 64 bit DLLs and it simply refuses to do this.

Basically ... both of these errors is the perfect storm of messed up runtime DLLs.

What would I do?

1. Remove every VC redist possible via Add/Remove programs.

2. Look carefully at your PATH variables to see if there are any nonstandard places for the VC++ runtimes to be lurking. If so, adjust PATH accordingly.

3. Install VC2005, VC2008, VC2010, VC2015 32-BIT ONLY (i.e. x86) redists via downloads from Microsoft.com. I.e. download and run the VC redist installer .EXE (i.e. no manual copying of any VC++ runtime files).

4. Install a new C:\Orbiter2010 and C:\Orbiter2016 from scratch, with NO C++ RUNTIME DLLs installed in the Orbiter directory trees.

5. Test. If all this fails ... then you may need to reinstall Windows from scratch, sorry to say.

#### PeterRoss

##### Warranty man
Looks like the problem is caused by Win7 x64 simply not allowing VCredistr2005 x86 to install. Looks like it is quite common, people asked Microsoft what to do with it, no sane anwer followed. Some people are proposing some workarounds, but none had worked in my case. Alas. And I don't think reinstalling Windows will help. Maybe I should try virtual machine with good ol' WinXP instead.

##### Scientist
Jeez... for the love of all things holy, just install Win 7 or Win 10. Please ...

.

Or not ... but you are in purgatory here.

#### DaveS

##### Space Shuttle Ultra Project co-developer
Donator
Beta Tester
Jeez... for the love of all things holy, just install Win 7 or Win 10. Please ...

.

Or not ... but you are in purgatory here.
He does have Win 7 x64 but the problem is that the TransX/MMExt modules were compiled using a too old VC++ version (most likely VC++ 2005). This results in the modules relying on runtimes that are not compatible with any OS older than Win XP, so Vista and later are out.

Best solution is to get a newer VC++ version, like 2010 and later. I know this cuts out the very small minority that still use Win XP, but that's on them. MS EOL'ed XP a long time ago so upgrading to a later OS is the right thing to do. Win 7 is an excellent OS, I can testify to that, being a user of it since it went public beta for the first time in January 2009, nearly 9 years ago.

#### Enjo

##### Mostly harmless
Tutorial Publisher
Donator
Somehow everything works on my Windows 8.1, but I realize that something has to be done here.
Best solution is to get a newer VC++ version, like 2010 and later. I know this cuts out the very small minority that still use Win XP, but that's on them.
I don't want to cut out the XP users. Therefore the best solution will be to link the distributables statically. We can then compile with whatever MS version we choose.

I recall, that I've already tried it and failed, but I was lacking time back then:
Now I'm not sure if it was really the libcmt problem. Maybe something else. I'll keep you posted.

#### Face

##### Well-known member
Orbiter Contributor
Beta Tester
Looks like the problem is caused by Win7 x64 simply not allowing VCredistr2005 x86 to install. Looks like it is quite common, people asked Microsoft what to do with it, no sane anwer followed. Some people are proposing some workarounds, but none had worked in my case. Alas. And I don't think reinstalling Windows will help. Maybe I should try virtual machine with good ol' WinXP instead.

Would it help you to have a version without the mandatory module messaging option? I.e. is the reason why you want this TransX version the capability of sending data to the other mentioned modules, or because it has additional features?

#### Enjo

##### Mostly harmless
Tutorial Publisher
Donator
In this case, no, because it's the TransX that exposes his problem (it's linked against VC2005 redist).
Being able to load the dependent dlls dynamically would surely be a step towards modularity though.

#### Face

##### Well-known member
Orbiter Contributor
Beta Tester
Peter, this here is a ZIP with recompiles of MMExt for various runtimes out of VS2015. You can rename them to *.dll to try it and see if the 126 still shows up. Perhaps you are lucky to hit one of your installed runtimes.

##### Scientist
Being able to load the dependent dlls dynamically would surely be a step towards modularity though.

This is the right end-state, I think. We each compile statically to avoid the redist problem, and then add the wrapper code to do our own LoadLibrary and GetProcAddress to bind to utilities if they are installed, or to back off that functionality if not needed.

As Enjo and I own the bulk of the MFD's using the interops, if he is up for it, we can plan it out and implement quite quickly.

#### PeterRoss

##### Warranty man
Would it help you to have a version without the mandatory module messaging option? I.e. is the reason why you want this TransX version the capability of sending data to the other mentioned modules, or because it has additional features?

In fact, I don't need module messaging very much. It all started with me installing BTC because I wanted this convenient tool to provide me with dV budget data. Since the latest BTC depends on MMExt I've installed it as well. Then again, I thought installing the new TransX would be fine too :lol:

Now I can't even run the vanilla Orbiter2016 transx from SVN repository - Orbiter crashes when I try to run transx MFD in simulation, but at least it is appearing in the MFD list. Removing MMExt isn't helping. What is even more weird, nothing appears in Orbiter.log regarding this CTD.

What I really want is working transx and BTC I've never used advantages of module messaging before, but it is mostly because I've never had a chance to run it all correctly yet

Peter, this here is a ZIP with recompiles of MMExt for various runtimes out of VS2015. You can rename them to *.dll to try it and see if the 126 still shows up. Perhaps you are lucky to hit one of your installed runtimes.

Uh, sorry, but this 126 error was entirely my own fault, as I expexted :shifty: If you look at my error report closely you can see it is trying to find MMExt in Plugins folder, although it is actually situated in Modules. Can't really explain my logic back then, guess I was kinda sleepy. In short, I placed MMExt into Plugins and added it into Orbiter.cfg manually. Don't ask. Yes, end users can be this stupid. Then I removed MMExt from Plugins, but forgot to remove the string from Orbiter.cfg until now. Anyway, at this moment 126 error is gone, I have only 193 errors with latest versions of TransX and BTC and crashing vanilla transx.
And, by the way, Avast is quite suspicious about the contents of the zip file you provided. Nevertheless, just in case I tested MMExt dlls for 2015 and 2013 VCredistr and none produced 126 errors or anything alike. Now it is only TransX and BTC with 193. Currently I have VCredist2008, 2010, 2012, 2013, 2015 all x86 installed.

Last edited:

##### Scientist
Loos like you are making progress, which is good.

I'm looking to eliminate MMExt problems in the next release by making the linkages all run-time controlled. This plus static linking will eliminate all these kinds of issues.

#### Face

##### Well-known member
Orbiter Contributor
Beta Tester
What I really want is working transx and BTC I've never used advantages of module messaging before, but it is mostly because I've never had a chance to run it all correctly yet

Thought so, thanks for the answer.

And, by the way, Avast is quite suspicious about the contents of the zip file you provided.

Well, the modules were created on a work machine (virus defended over its neck) with fully licensed VS2015, 2013, 2012, 2010, 2008 and 2005. The runtimes came along with the studios, so they should be pristine, too. The code is from Andrew's github repository, unaltered (except for target directory, of course), and to my knowledge there is nothing "bad" in there.

Perhaps your scanner got upset about the altering of the DLL filenames with number endings. :shrug:

#### PeterRoss

##### Warranty man
And thanks to Face's insight the problem was narrowed down to the beta incompatibility. I tried all the MMExt and both MMExt-dependant TransX and BTC modules with vanilla Orbiter 2016, everything works fine. I've mentioned in my first post in this thread that I'm using beta, but I suppose everyone including me just forgot about it.
Just to be clear, the problem was with beta v.171013. And the "vanilla transx" which is crashing on launch was from beta v.171203.
Seems like it is generally a bad idea to play in beta. Sorry for all this confusion, guys. Still don't know what it has to do with VCredistr incompatibility, but the fact is everything works fine in vanilla 2016.

#### Face

##### Well-known member
Orbiter Contributor
Beta Tester
Seems like it is generally a bad idea to play in beta. Sorry for all this confusion, guys. Still don't know what it has to do with VCredistr incompatibility, but the fact is everything works fine in vanilla 2016.

Good to know that the next Orbiter might cause many MFD addons to be recompiled. For those interested, this is what we tried out:

TransX using 2015 runtimes without MMExt support for Orbiter 2016 (API 160828)
TransX using 2015 runtimes without MMExt support for Orbiter Beta (API 171010)

##### Scientist
A bit more info on what Enjo and I are planning for the next version of MM Ext: MFD's will transparently disable the MM Ext functionality if it's not installed (with a note in the Orbiter.log). This will be implemented by a LoadLibrary and GetProcAddress call in the calling-code (in the MMEXt header). This plus static linking will help minimize conflicts and 126 errors. This technique is also used by Doug in the XR-series code, so I think it will become our new best practice for other devs if they need a hand.

#### Enjo

##### Mostly harmless
Tutorial Publisher
Donator
but the fact is everything works fine in vanilla 2016.

Replies
1
Views
1K
Replies
0
Views
1K
Replies
6
Views
5K
Replies
243
Views
96K
Replies
3
Views
2K