FSW Compiling with FSW Simconnect Tips

[rhumbaflappy]

I thought I'd start a thread about tips when compiling with Dovetail's Simconnect.

First, if you need a copy of FSW's SimConnect.dll in the same directory as your finished exe or dll. There is no SxS GAC64 entry for Simconnect.dll, so your compilation cannot find it.

Next. You may have trouble with ypur end-result not finding the SimConnect.dll. You could get a pop-up error telling you SxS can't find it, and you need sxstrace.exe to log the problem. The actual problem is in SimConnect .h:

//-----------------------------------------------------------------------------
//
// (c) 2017 Dovetail Games, a trading name of RailSimulator.com Limited. All rights reserved.
//
// NOTE: This file is autogenerated. Edit the master copy, not this one.
//-----------------------------------------------------------------------------

#ifndef _SIMCONNECT_H_
#define _SIMCONNECT_H_

#pragma once

#ifndef SIMCONNECT_H_NOMANIFEST
#if _MSC_FULL_VER >= 140040130
#ifdef _M_X64
#pragma comment(linker,"/manifestdependency:\"type='win32' " \
    "name='Dovetail.DFS.SimConnect.Hybrid' " \
    "version='0.1.1073.999' " \
    "processorArchitecture='amd64' " \
    "publicKeyToken='1ed9da73c880e429'\"")
#else
#pragma comment(linker,"/manifestdependency:\"type='win32' " \
    "name='Dovetail.DFS.SimConnect.Hybrid' " \
    "version='0.1.1073.999' " \
    "processorArchitecture='x86' " \
    "publicKeyToken='1ed9da73c880e429'\"")
#endif
#endif
#endif  //SIMCONNECT_H_NOMANIFEST

#ifndef DWORD_MAX
#define DWORD_MAX 0xFFFFFFFF
#endif

#include <float.h>


typedef DWORD SIMCONNECT_OBJECT_ID;

Change this to:

//-----------------------------------------------------------------------------
//
// (c) 2017 Dovetail Games, a trading name of RailSimulator.com Limited. All rights reserved.
//
// NOTE: This file is autogenerated. Edit the master copy, not this one.
//-----------------------------------------------------------------------------

#ifndef _SIMCONNECT_H_
#define _SIMCONNECT_H_

#pragma once

#ifndef DWORD_MAX
#define DWORD_MAX 0xFFFFFFFF
#endif

#include <float.h>


typedef DWORD SIMCONNECT_OBJECT_ID;

Now your app will find the SimConnect.dll that you put in your directory.

I have been copying the P3d v4 SDK file structures (substituting the appropriate FSW files), and using The free VisualStudio 2017 Community, for the C++ examples.

 

[WarpD]

I am not sure it's a good idea to duplicate the DLL that comes with the sim. Any updates to the DLL made by Dovetail wouldn't be in your copied file. This could cause problems. I think it is best to determine location of the Dovetail DLL and load that one instead. It's much, much safer.
Just my thoughts.

 

[rhumbaflappy]

First, you are altering the SimConnect.h, which is already a deviation from the original. You don't want to alter the original, just your copy, in another folder you create.

Then, Dovetail could (and probably will) change the Simconnect.dll, and you would now have an exe that might not work with the new dll, but still might with the old.

You could place your exe in the root folder of FSW... but here is a problem. Now you are altering the FSW folder. Bad idea. You could have several apps and dlls clogging up your root folder.

I do see a possibility here. FSW has a tools folder and a module folder (for DLLs). You could install to those folders (perhaps with a subfolder for your app or dll), and then you'd have an easy path for the using the original SimConnect.dll, without messing up your root folder at all.

Just making a path to the root folder could cause problems, as not everyone will have a standard folder location.

Just include the Simconnect.dll in the app's folder. End of problem. If the DLL is unuseable with a new update, then you'd need to recompile with the updated SimConnect.h and SimConnect.lib for a new version of the app (so just include the SimConnect.dll with the new version).

Besides, it's pretty much standard practice to include DLLs with a released app, whether native or managed programs.

 

[rhumbaflappy]

I am not sure it's a good idea to duplicate the DLL that comes with the sim. Any updates to the DLL made by Dovetail wouldn't be in your copied file. This could cause problems. I think it is best to determine location of the Dovetail DLL and load that one instead. It's much, much safer.
Just my thoughts.

I've thought some more of your apprehension of having multiple versions of FSW's simconnect.dll floating around. Of course you are right. But until Dovetail installs the DLL to the WinSxS folder, we don't have much choice. We can always install apps to the FSW folder, but that is not a good practice either. Looking for a solution...

 

[rhumbaflappy]

Maybe I was over-thinking this. A simple batch file can set a path for the dll search, then execute the program:

set PATH=%PATH%;C:\Program Files (x86)\Steam\steamapps\common\FSW
DataHarvester
pause

 

[WarpD]

I am confused as to why you need a direct path to the DLL at run-time. That just doesn't make sense to me as it places a great deal on the developer to ensure someone else's installation (Microsoft's/Lockheed-Martin's/Dovetail's) is correct. Of course, I've always used dynamic linking and a call to OpenLibrary myself. You're rapidly convincing me that C# is not a good language to use. LOL

 

[rhumbaflappy]

I'm writing of C++. The app needs a path to the DLL or it won't run.

The above attachment is simply an P3dv4 example converted to FSW. FSX, P3D and FSW all need to have the SimConnect.dll in the path.

Microsoft and P3D use the WinSxS to store the appropriate version of the DLL, which is then always in a search path for the system. FSW's DLL is not stored in the WinSxS, so you need to put the app in FSW's root folder (where the DLL originally is placed), or supply a copy of SimConnect.dll in the app's folder, or create a path to the DLL (like I did above).

The SimConnect.dll must either be in the system search path or in the same folder as the app. If you load the library in the app, you still need to have a location of the DLL or the app won't work.

This is known as "dll hell".

 

[WarpD]

Uh... I certainly don't... so I can't honestly understand why you do. I use SimConnect in DLLs, gauges, apps. At no point have I needed to know the physical location of the SimConnect DLL.

 

[12bPilot]

The app needs a path to the DLL or it won't run.

Depends on how you link the DLL functions, static (load time dynamic linking) or via run-time dynamic linking.
The latter uses the Windows API function LoadLibrary. And this function does not necessarily need a full path, the module filename is sufficient, see the remarks here https://msdn.microsoft.com/en-us/library/windows/desktop/ms684175(v=vs.85).aspx

When specifying only the module name and if the DLL is not yet loaded by some other app (FSW for instance), Windows will start searching for it, starting at the directory where your application is called from. Then it uses a search order which is described here: https://msdn.microsoft.com/en-us/library/windows/desktop/ms682586(v=vs.85).aspx

I must admit I have never tried that with FSW's SimConnect.dll, but if I understand those MSDN articles correctly, if FSW loads the SimConnect.dll, your app should be able to get a handle to it using the LoadLibrary API call specifying only the module name.

-Jeffrey

 

[WarpD]

I don't link the DLL functions, I haven't found a reason to. The SimConnect LIB file provides the linked code. However, if you insist on linking with a load, certainly a dynamic load is a better choice. I also recommend you test to see if the DLL is already loaded by using GetModuleHandle to obtain the handle. If you don't get a valid handle returned then you can use LoadLibrary. The SimConnect DLL should already be in memory because the sim loads it.

 

[rhumbaflappy]

I'd be interested in seeing an FSW example or two. A better way is certainly welcomed!

 

[rhumbaflappy]

Uh... I certainly don't... so I can't honestly understand why you do. I use SimConnect in DLLs, gauges, apps. At no point have I needed to know the physical location of the SimConnect DLL.

A little reading and I understand your method.

The SimConnect examples for apps (FSX or P3D) use implicit linking, and that does require a dll file to link at runtime (and so, a location or path to that file).

Another method uses explicit linking, and uses LoadLibrary(), GetProcAddress(), and FreeLibrary() to link to a DLL.

You test with GetModuleHandle() for a valid handle, and if false use LoadLibrary(), else the DLL is already loaded in memory. I read there may be problems with multi-threaded applications, but apparently not with FSX or P3D. I like your way, as most apps have no need for file linking as SimConnect is pointless unless FSW is already running.

 

[WarpD]

To be clear, I don't load the SimConnect DLL at all. I have never had a reason to do that. I can use the SimConnect API without loading the DLL.

 

[rhumbaflappy]

To be clear, I don't load the SimConnect DLL at all. I have never had a reason to do that. I can use the SimConnect API without loading the DLL.

Yes, I understand. The DLL is already in memory being used by the simulator. I'll play with this this weekend.

One question: do you use SimConnect.h with your apps and gauges? And you do not link the LIB file?

 

[WarpD]

I use SimConnect.h and I link the LIB file.

 

[rhumbaflappy]

I'm stuck getting the handle to the already loaded SimConnect.

#include <windows.h>
#include <tchar.h>
#include <stdio.h>
#include "SimConnect.h"
#include <strsafe.h>

HANDLE hSimConnect;


void testOpenClose()
{
    HANDLE hSimConnect;

    hSimConnect = GetModuleHandle("SimConnect.dll");
//    hSimConnect = LoadLibrary("SimConnect.dll");

    HRESULT hr;

    if (SUCCEEDED(SimConnect_Open(&hSimConnect, "Open and Close", NULL, 0, 0, 0)))
    {
        printf("\nConnected to FSW!");  
   
        hr = SimConnect_Close(hSimConnect);

        printf("\nDisconnected from FSW");
       
    } else
        printf("\nFailed to connect to FSW");
}

int __cdecl _tmain(int argc, _TCHAR* argv[])
{


    testOpenClose();

    return 0;
}

The program runs fine if a copy of SimConnect.dll is in the same directory as the program. I can't seem to get the handle of Simconnect that is already loaded by FSW.

 

[WarpD]

First problem I see is that you're attempting to pass the DLL's handle as the SimConnect object handle. While they are both HANDLE types, they are not the same thing. Try this:

#include <windows.h>
#include <tchar.h>
#include <stdio.h>
#include "SimConnect.h"
#include <strsafe.h>

HANDLE hSimConnect = NULL;


void testOpenClose()
{
    HRESULT hr;

    if (SUCCEEDED(SimConnect_Open(&hSimConnect, "Open and Close", NULL, 0, 0, 0)))
    {
        printf("\nConnected to FSW!");  
   
        hr = SimConnect_Close(hSimConnect);

        printf("\nDisconnected from FSW");
       
    } else
        printf("\nFailed to connect to FSW");
}

int __cdecl _tmain(int argc, _TCHAR* argv[])
{


    testOpenClose();

    return 0;
}

The call to SimConnect_Open should populate the hSimConnect variable with the needed SimConnect HANDLE.

 

[rhumbaflappy]

I tried your suggestion, and it still doesn't work unless SimConnect.dll is in the same folder. FSX and P3D (not sure about version 4) have the dll in the WinSxS folder, so the program will always have a path to the SimConnect.dll. FSW doesn't have the dll in WinSxS, so the program still searches the system PATH for it (and finds it if it's in the same folder).

 

[ddawson]

What you will probably want to do is retrieve the FSW installation path from the registry. You can then safely call LoadLibrary to use dynamic linking to work with the current version of SimConnect.
Unless Dovetail start deprecating SimConnect functions, this approach will work regardless of the number of updates to SimConnect.

 

[WarpD]

Ok... I will take a look at this as it should have worked. You should not have to explicitly load the DLL as it is already loaded by the sim. I have confirmed that FSW indeed loads the DLL.