P3D v4 Upgrading a DLL from 32bit to 64bit

[delivery guy]

I have the source code / file TrafficRadar.DLL from Doug Dawson website. Download

This is open source as long as you give credit to the original developer Arne Bartels.

I have no issues loading this source code into Visual C++ 2017 and exporting as a x64 platform. But P3D V4 will crash. (Also make sure you create a DLL.cfg in APPDATA to load the DLL for testing.)

So i realize the platform conversion is easy but there must be some code that needs to suit P3D V4. Any C++ coders can help would be appreciated.
I was thinking maybe the XML_TOKEN list is wrong. I also looked for a AI list whichi could not find as this would not be the same list.

Thanks,

 

[ddawson]

I myself have run into an issue with what I believe is a problem with calling conventions.
The module loads fine into P3D. However, if an xml gauge accesses the MyGaugeCDrawable:raw method, the module crashes when the method returns. The error indicates a stack corruption.
Anyone have any thoughts as to how to track something like this down?

 

[JB3DG]

Look for pointers being cast into 32bit integers. Make a type definition based whether X64 is active that will automatically switch between a 64bit integer and a 32bit integer and use that type for the integer castings. Or use UINT_PTR which also automatically switches.

 

[delivery guy]

Look for pointers being cast into 32bit integers. Make a type definition based whether X64 is active that will automatically switch between a 64bit integer and a 32bit integer and use that type for the integer castings. Or use UINT_PTR which also automatically switches.

Can you explain in a more simple way. I do not code in C++. But i do use VB 2017 and it also can export C++. If you could give me an example of what codes to change as a test i can try.
Like unit32 converted to unit64?
I tried doing this and i end up with only 4 errors. But can't fix those errors.

 

[JB3DG]

If you use the ESP GDI+ example as your template, there will be 3 key areas where you will need to change the UINT32 to a UINT_PTR. The first 2 are the 3rd parameters of your gauge callback function. The last is where the gauge class pointer is stored in the gau struct's userdata member. In the v4 Gauges.h, this is a UINT_PTR, which automatically changes between 32bit and 64bit depending on compiler state, while in the non v4 gauges.h, it is a UINT32. Best bet is to change the cast type from UINT32 to UINT_PTR.

 

[ddawson]

Jon,
We're not talking about a gauge here. It is a module, loaded at run time through dll.xml.

DG.
There are a couple of new methods in the gauge, panel and aircraft callback classes that have to be define, even though they are not used:
MyGaugeCCallback::SetPropertyValue(SINT32 id, LPCWSTR szValue)
MyGaugeCCallback::GetPropertyValue(SINT32 id, LPCWSTR* pszValue)
Also, make sure you have expunged all references to fsxgauges_sp2.h
I've got the thing compiling. Just have to get it to stop crashing.

 

[delivery guy]

Also, make sure you have expunged all references to fsxgauges_sp2.h
I've got the thing compiling. Just have to get it to stop crashing.

_sp2...... It says was to just distinguish the version. So anything can be put there i assume.
And yes i can compile with no issues but it crashes in p3d.

Editing LPCWSTR created more errors.

 

[ddawson]

I've finally got something that will survive loading and unloading, but it will require further testing.
I don't think it's quite ready for prime time.
I'll send you a link later today.

 

[delivery guy]

I've finally got something that will survive loading and unloading, but it will require further testing.
I don't think it's quite ready for prime time.
I'll send you a link later today.

Awesome news. I also thought of making a TCAS using XML coding later this year if we could not pull this off. I figure it would be simple compared to C++.