Sign in to follow this  
Guest zzmikezz

Bizarre SimConnect-Related Issue

Recommended Posts

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

Share this post


Link to post
Share on other sites
Help AVSIM continue to serve you!
Please donate today!

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).

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites

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".

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

>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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this