Specific simconnect.dll not registered

[jimkeir]

Hi,



I'm trying to compile a traditional C++ program against simconnect.dll, using dynamic binding, using the DLL manifest. It seems like the installer doesn't register this with Windows because there's nothing in the WinSxS folder.



I've also looked in the MSI and at didn't see any reference to it there, although it does seem to install three versions of the original FSX SimConnect.dll .



Can I assume I should be trying to find these versions and not a specific Prepar3D one?



Cheers,

Jim

[beatle]

Hey Jim,



We don't make a SimConnect.DLL anymore. Our client library is now a static link library, so when you link to the SimConnect.lib, the client code is linked directly into your application. The WinSxS stuff seemed to cause nothing but trouble with FSX's and ESP's use of it, so we decided to go with a static library instead. This also means you can run the SimConnect client app on another computer without having to install the SDK (or at least run the SimConnect.msi) on that computer first.



If you have code that already does the dynamic linking/looking for the latest installed version, then just continue to do that using the FSX-SP2 or ESP versions of the libraries in the WinSxS (we do install those for backwards compatiblity), but if you want to use any of the new APIs that we add, you will need to use our static library to access those.



Tim

[fsdreamscapes]

Quote:
Quote from jimkeir on November 14, 2010, 10:02

Hi,



I'm trying to compile a traditional C++ program against simconnect.dll, using dynamic binding, using the DLL manifest. It seems like the installer doesn't register this with Windows because there's nothing in the WinSxS folder.



I've also looked in the MSI and at didn't see any reference to it there, although it does seem to install three versions of the original FSX SimConnect.dll .



Can I assume I should be trying to find these versions and not a specific Prepar3D one?



Cheers,

Jim





Hey Jim,



Good to see you here

[jimkeir]

Hi,



Tim, if you're using solely a static lib, can you please provide the debug version of it? I can't link against the debug libraries because simconnect.lib now depends on the MSVC runtime, and assumes non-debug. I suspect you may also need to provide builds for VS2010 although I can't check this, I'm still on VS2008. I'm not sure how a program will cope using two different runtime stacks at the same time



Also, a way of getting the version number without going through all that nasty asynchronous stuff would be nice. I can't just use GetModuleVersion() any more. A simple exported symbol from the .lib would be fine.



I have to say I never had any trouble with the dynamic libs; you didn't have to install the SDK to get them, they were installed with the sim. Didn't have to provide a different version for VC2008/2010/debug/non-debug either



Hi Dean!



Cheers,

Jim

[Beau Hollis]

We don't ship a debug lib, but in our internal testing, we have been able to build in debug while linking against the release lib. Currently, we only ship a VS2010 version of the lib, so for the time being, you will either need to upgrade to 2010 (express should also work), or link against the legacy DLLs provided.

[jimkeir]

Hi,



Curious... I can link and run perfectly with the static simconnect.lib in VS2008 in Release mode (specifically, when using the non-debug runtime libraries) but not against the Debug libraries. It links fine, but on startup the application fails because it can't open msvcr90.dll . This is installed, of course, so I suspect that it is clashing with the debug version used by the main application and refusing to load.



> Currently, we only ship a VS2010 version of the lib



Maybe you're using VC2010 with the 9.0 "platform toolset" setting? Either way, try running one of the successfully-compiled programs in debug mode. I'm betting it won't start.



I can work round it easily enough, just thought you should be aware.



Cheers,

Jim

[Beau Hollis]

Thanks for the heads up. We have compiled and run debug projects with VS2010, so it's likely an issue with using VS2008. I'm glad you were able to compile against the lib. We do currently use the VC9 toolset, but may be migrating away from it in future releases.

[beatle]

Actually, we stopped using the VC9 toolset about 5 months ago :-> We use VC10 compilers and libraries for everything now (and .Net 4 for all the managed code).



I did check through the SimConnect client code to make sure it wasn't using anything that was VC10 specific and since its a static library, it should just use whatever version of the C RunTime the rest of the code you are linking it with is using, although it is built to use the DLL version of the runtime. We should probably provide at least a couple versions of the lib, one for the DLL runtime and one for the statically linked version of the runtime.



Not sure what the issue is with the MSVCR90.DLL, I've run into issues with that file before, though not related to the SimConnect client code and not since we switched to using VC10 for everything.



Tim

[Pete Dowson]

Hi Tim,



This is news to me, and as a maker of modules which are intended, in one package, to work with FSX, ESP and Prepar3D, I think I need some answers:



Quote:
We don’t make a SimConnect.DLL anymore. Our client library is now a static link library, so when you link to the SimConnect.lib, the client code is linked directly into your application.



Now whilst I welcome a move away from the horrendous nightmare that WinSxS can be, could you clarify what might happen if I were, say, to compile your static LIB into FSUIPC and supply it to someone using FSX RTM, SP1 or SP2?



If this can still all work (providing I take care internally to only use whatever subsets of the SimConnect API should be applicable, which I assume I can determine from the version number returned by the Open call) then I'd be delighted, though it means quite a lot of work extricating all of the complex code I managed to get working to allow FSUIPC to interface with any of the four extant dynamic SimConnect libraries!



Your later comment:

Quote:
... but if you want to use any of the new APIs that we add, you will need to use our static library to access those.

does appear to make it even more important for me to resolve these questions, as I'm sure some FSUIPC-addicted developers will love to be able to take advantage of new developments.



Best Regards

Pete

[RXP]

Hi,



I agree with Pete as we also do build our products on top our own framework that among other things, abstracts SimConnect on all versions (FSX, SP1, SP2, ESP, P3D) , in a dynamically loaded/bound fashion: the same "DLL" loads directly into any of these sim version using the correct SimConnect DLL automatically.



I also second the option for a "static CRT" version of the lib, in addition to the "dll CRT" version you already offer.



Best regards,



Jean-Luc

[beatle]

Hey Pete,



Sorry, I missed this message going by during all the Christmas/End of Year stuff.



Quote:
Now whilst I welcome a move away from the horrendous nightmare that WinSxS can be, could you clarify what might happen if I were, say, to compile your static LIB into FSUIPC and supply it to someone using FSX RTM, SP1 or SP2?



If this can still all work (providing I take care internally to only use whatever subsets of the SimConnect API should be applicable, which I assume I can determine from the version number returned by the Open call) then I'd be delighted, though it means quite a lot of work extricating all of the complex code I managed to get working to allow FSUIPC to interface with any of the four extant dynamic SimConnect libraries!



At the moment, the static library won't allow this, it can only talk to its version or newer, it doesn't currently support talking to downlevel servers.



I have some changes planned for the SimConnect client stuff, but none of this has been scheduled/approved/etc yet, so is just informative of where we are likely to go in the near future.



I'm working on a new API code generator (because the current one is in Perl and I can't figure out what half of it is doing :->) that will allow us to spit out several versions of the API client code, the existing C and managed wrapper that FSX/ESP had (for source level backward compat), plus new native and managed clients, more like the replacement managed client lib I released (ie no use of the SimConnect.cfg file, just provide the connection params directly on the Open call, etc). For the Native library, I expect it to be interface based with a class factory function, so in order to support both old DLL style SimConnect for FSX/ESP (the code you currently have) and P3D, you could provide an interface implementation that wraps your existing DLL code, and decide which implementation of the interface you will use based on the version of the server you are going to talk to. Yes, this would mean providing some sort of quick version check handshake function (would also validate the server name/ip and port number).



While I do want to make the new client libs support connections to down-level servers, you would probably still want to do the above interface implementation, so you are actually using the FSX or ESP DLL when talking to them, as you won't get the in-proc network bypass benefits using the P3D static lib with either FSX or ESP (I had to add a second method of hooking the in-proc bypass because of the way the original one was implemented).



We're also planning to make a scaled down C/C++ version of the client that could be distributed as source code for use in embedded dev environements, so folks could make hardware addons that speak SimConnect directly.



Besides making multiple client versions, the new code generator could also create multiple server modules as well, although I'm not sure what to do with this yet (maybe a WCF style web service interface?).



Any ideas for additions to SimConnect, either in how its implemented or in the APIs themselves, feel free to post them. We've got lots of new APIs for the upcoming releases, but we haven't exposed a lot of the old systems yet.



Tim