Some friends have asked me to represent them in this forum because a) I

I think your friends are confused :->. There is no SimConnect interface for FS9, that's a new feature of FSX. There's no way SimConnect could do anything with FS9, its just not possible. Maybe they are using some other library that happens to have the same name as the new FSX API layer (although I've never heard of it before).The only SimConnect.DLL files that should exist, are in the windows SxS (Side by Side) directories, and possibly under the SDK installed dir (although these versions should never be loaded, only the SxS versions should be loaded).Yes, the different versions of the SimConnect.DLL are for the different Service Pack levels of FSX (RTM, SP1, SP2). That's why these live in the SxS directory, to allow different versioned DLLs to be installed and coexist peacefully allowing addons written to a specific version to be loaded even if the version of FSX has been upgraded to a later Service Pack level (ie an addon written against the SP1 version of SimConnect will still load under SP2, using the SP1 version of the SimConnect.DLL file).

beatle,Thanks for your reply.Their Play.dll module is resident in the FS9 Modules folder, so it runs when FS9 starts up. The Play.dll module does a LoadLibrary of SimConnect.dll, even though SimConnect.dll is a feature of FSX and is not distributed with FS9. The SimConnect that they load is in some location where they have stashed a copy of one of the SimConnect versions.So all of my comments and questions stand. I know this is all very weird. That's why I used "Bizarre" in the thread title.

Lets see, you use a module from game y in game x ( the older version that doesnt support game y features ) and then wonder why it doesnt work?In general, things like this never work, eg using new features from new games in the old game. Trying to do something like this is like trying to run with scissors, dont do that.They should use the EventViewer in the AdminTools control panel to find out exactly what caused the load failure, but I highly suspect this is unsolvable. And a scenario that is so far out of the support zone that...well, you get the idea.

Many thanks, Phil. I don't know the details and I hear you regarding being in la la land re support. Can you give me a little more information regarding why it shouldn't work? I hate to impose but if you could take a couple more minutes I would be most grateful.Edit: I should add that it IS working so our question has more to do with what the technical risks are. It's terra incognita but what's your gut?

if its just the _USE_RTM_VERSION issue, which I replied to Jean Luc about in the other thread, that may work since he is benignly loading SimConnect in a gauge package designed to work in either sim and do the right thing at the right time. if its some other issue, who knows. and no one is going to dig to figure it out since the scenario is "out there".

Merci beaucoup, I will now fade back into the woodwork.

I'm a tad confused... we're not allowed to distribute the SimConnect.dll file are we?

Nope :->

That is interesting. Lately someone reported that FSIN/FSCopilot is making our gauges fail to draw in the VC.Now with this thread, I suspect it is related to SimConnect (we use that in FSX just to know if we are in the VC or 2D and to prevent the gauges to render in the VC when in 2D view - long lasting bug in the FS series at least since FS9... -).If FSIN is copying SimConnect (I don't know what version) this might explain why my gauges are having issues?!?! (like mismatch versions loaded in memory)?!?http://www.simforums.com/forums/forum_posts.asp?TID=24473

And my friends report that they too have been having problems when FSinn/FScopilot are installed.Also, they were dynamically linking to SimConnect, and even though I don't know their system I can see how this might result in a second instance of SimConnect in their address space, especially confusing if the system has several versions to choose from for the second instance, which should not be there in the first place.I'm thinking that the solution may be a static link with a known version of SimConnect, if this is possible, much as one would do with DirectX.But I really don't know what I'm talking about here. I'm simply trying to gather information for my friends. I don't have access to their sources so I can't read the code. The guy who really knows what's in there is out of town and unavailable, which is why they asked me to intervene.

>And my friends report that they too have been having problems>when FSinn/FScopilot are installed.>>Also, they were dynamically linking to SimConnect, and even>though I don't know their system I can see how this might>result in a second instance of SimConnect in their address>space, especially confusing if the system has several versions>to choose from for the second instance, which should not be>there in the first place.>Your friends can not distribute the SimConnect.dll, thus it's actually their version that is the problem. They need to adapt their code to connect to the correct version that is available via the Windows Side-by-Side(SxS) installation system. The multiple copies contained within the SxS installations are intentional and proper.I believe the primary source of their issue is that they're using a LoadLibrary to access the DLL. They should be using the SimConnect.h file and the SimConnect.lib file. By using the defined methodology, their code will most definitely connect with the correct version as long as it's been installed on the end-users's system.

Thanks, Ed, that's what I've suggested to them -- static link with a known version. I will point them to this thread and your post.

No problem. Please ensure they understand they can not legally distribute the DLL... wouldn't want them to get spanked. ;)

They're taking that issue up directly with Microsoft. Anyone who's been following my anti-piracy discussions would realize that this would be the case.