XRRR and its MFD perform this kind of interoperation, though when I wrote it I wasn't aware of Enjo's solution and I may look to incorporate that in the future.
The source for XRRR is open, and it is in bitbucket
here; the relevant portions that deal with intercommunication are kind of all over the place (refactoring is in progress in another branch, but it breaks everything at the moment).
If I recall correctly (it's been some years since I wrote it), it works like this; since I'm writing both modules, they can and thus do share a header file (XRRR.h) which contains most of the definitions for data structures and so on. Then each module also has a private header, to contain things which only need be present in one module. That approach means both modules know about my data structures and I can handle the same objects in each module.
The plugin interacts with vessel objects, and the MFD interacts with the data the plugin generates, using an exported method from XRRR.dll which the MFD calls;
plugin.h (XRRR.dll)
Code:
// Export our method to return a pointer to the hash map object
// Check the .def file for export stuff too.
XRRR_FleetReference * __stdcall MFDGetter(XRRR_FleetClasses::XRClass_t *VesselClass);
extern XRRollingRepair *g_XRRR;
bitbucket view
XRRR.def (export definitions);
Code:
LIBRARY XRRR
DESCRIPTION "XR Rolling Repair"
EXPORTS
MFDGetter @1
Bitbucket view
And the method itself, which is really basic, is just:
Code:
XRRR_FleetReference * __stdcall MFDGetter(XRRR_FleetClasses::XRClass_t *VesselClass)
{
return &XRRR_VesselReference[*VesselClass];
}
Bitbucket view
This works, but, I needed the actual data the plugin DLL was currently using, not a null pointer (which is all I got when I called it as-was), so the MFD makes use of LoadLibrary to reference the currently loaded copy of XRRR.dll;
Code:
// Load the XRRR module and pull in the function address of our MFD helper function
hXRRRModule = LoadLibrary("Modules\\Plugin\\XRRR.dll");
if (hXRRRModule != NULL)
{
XRRRData = (FindXRRRType)GetProcAddress(hXRRRModule, "MFDGetter");
}
Bitbucket view.
That horrible little piece of code looks up the in-memory address of the exported function from the currently-running XRRR.dll, and calls it, returning a pointer to the in-memory data that the plugin is using, which the MFD can then interact with.
Cleanup - in the MFD's dtor we have to call FreeLibrary to remove that reference to XRRR.dll, otherwise it doesn't get unloaded and we have problems:
Code:
// Unload XRRR module now; We're done with it.
FreeLibrary(hXRRRModule);
Bitbucket view
And I think that's all there was to sharing the same in-memory object between two of your own DLL modules.
Disclaimer: I wrote that code five years ago. Some of the terminology and mechanics might be nonsense but the code does work. XRRR is open source, so you're free to use that code as-is if you wish to.
