• Which the release of FS2020 we see an explosition of activity on the forun and of course we are very happy to see this. But having all questions about FS2020 in one forum becomes a bit messy. So therefore we would like to ask you all to use the following guidelines when posting your questions:

    • Tag FS2020 specific questions with the MSFS2020 tag.
    • Questions about making 3D assets can be posted in the 3D asset design forum. Either post them in the subforum of the modelling tool you use or in the general forum if they are general.
    • Questions about aircraft design can be posted in the Aircraft design forum
    • Questions about airport design can be posted in the FS2020 airport design forum. Once airport development tools have been updated for FS2020 you can post tool speciifc questions in the subforums of those tools as well of course.
    • Questions about terrain design can be posted in the FS2020 terrain design forum.
    • Questions about SimConnect can be posted in the SimConnect forum.

    Any other question that is not specific to an aspect of development or tool can be posted in the General chat forum.

    By following these guidelines we make sure that the forums remain easy to read for everybody and also that the right people can find your post to answer it.

EXE vs. DLL

ronh

ronh

Messages
1,360
Country
canada
A question for anyone.

What are the advantages and disadvantages between writing a simconnect program as a DLL or EXE.

I see the traffic map program in the SDK is a DLL. Why could it not be an EXE? Since Simconnect is client/server is it more efficient communications as a DLL vs and EXE. It says a DLL is in the FS process space and EXE is not. MS says it is safer to run as an EXE.

The only thing I see is that you don't need to set your sim to "continue running during task switching". Can you get fancy and use the dialogs/messageboxes that FS has rather than the regular windows dialogs?
 
Easier to debug EXE.
Can run EXE on separate machine.
More stable (crashing EXE doesn't crash FSX).
Can choose processor affinity for EXE but not for DLL?
 
Hi Ron,

The SDK tools aren't technically SimConnect clients, they just use the DLL.XML mechanism to get loaded, but they don't use the SimConnect APIs to talk to the rest of the system, instead they direct link to various bits and pieces of the system (which is also why you have to have your SDK SP level matching your FSX SP level).

Basic guideline would be, if your module doesn't have its own UI (say its only providing support for custom triggers from the mission system, automating certain cockpit chores, providing an interface layer ala FSUIPC, etc) then maybe making the module a .DLL would be the better choice. But if you want to have a full, rich UI on your module, with the possiblity of running your module on another computer, then a .EXE would be the better choice.

Also, if you want to create a managed .Net based module, then .EXE is your only choice as FSX can't load managed .DLL files within its own process space.
 
Thanks Matthew and Tim,

"The SDK tools aren't technically SimConnect clients" Oh?

So FSUIPC type program still has legs. So where is this "direct link FSX SDK" ;)

Is there any performance hit/increase of dll vs EXE?

Is there any performance hit with C++/CLR or C# vs C++ native?

TIA
 
Hey Ron,

<<
So FSUIPC type program still has legs.
>>
Pete still maintains it to provide support to external add-ons that make use of it. Interntally, Pete uses SimConnect for about 95% of his functionality, doing a couple of direct hacks for things that SimConnect doesn't support yet.

<<
Is there any performance hit/increase of dll vs EXE?
>>
I wouldn't think so. SP2 (or was it SP1?) added support for a named pipe interface as an alternative to the TCP/IP interface, which performs better with addons on the same machine (if you use Auto as the Protocol in the SimConnect.cfg file (or run without a .CFG file), then you will be using the Named Pipe interface).

<<
Is there any performance hit with C++/CLR or C# vs C++ native?
>>
Not really, other than the performance differences between a native program and a managed program in general. There might be a slight decrease in performance for managed clients because the managed SimConnect library is a wrapper around the unmanaged library, but I haven't noticed one in the managed client apps I've written so far. I have been looking into writing a fully managed client library to replace the wrapper, but no idea if/when that might get released :->.
 
Tim,

Thanks for the reply.

This is an interesting tid bit.

beatle said:
SP2 (or was it SP1?) added support for a named pipe interface as an alternative to the TCP/IP interface, which performs better with addons on the same machine (if you use Auto as the Protocol in the SimConnect.cfg file (or run without a .CFG file), then you will be using the Named Pipe interface).
Click to expand...

Oh ... more to learn ...
 
You must log in or register to reply here.
Back
Top