Thread: DLL intercomunication

Hi all, I have another question.

I hope this is an interesting topic and thanks for all the help you can give.

I have two dlls:
1 - dll_prep links against a static library, lib1. Lib1 contains a vector of objects, various classes and member functions. When the main program executes, dll_prep is loaded and its objects (defined in the static library) are correctly initialized. This lib1 is written in C++ and contains an STL vector of objects, amongst other things.

2 - dll_calc is a dll generated by compiling/linking fortran subroutines. It is called by dll_prep at runtime. dll_calc performs some calculations on objects defined in the lib1, part of dll_prep. dll_calc is linked against the lib1 static library.

dll_prep loads a function pointer in dll_calc and executes the corresponding Fortran subroutine.
dll_calc also makes some function calls into dll_prep.

The problem is that when the Fortran subroutine in dll_calc calls the functions defined in its static library lib1, it seems to be returning bogus/uninitialized memory (the vector of objects is now empty).

So to summarize:
- dll_prep depends on a static library, lib1.
- dll_calc also depends on the same static library, lib1.

I suspect that both dlls have an independent copy of the same static library, lib1 and therefore what one dll does the other doesn't know.

So my question and request for help:
when two dll are loaded and call functions (defined in a static librarY) between each other, what should I do?

I set up the project such that:
dll_prep depends on lib1
dll_calc depend on lib1 (I'm using the VS 2005 project dependencies dialog box here).

Again, thanks for the help.
a72.

matsp, you say:

Another solution is to turn lib1 into a DLL too - this may of course not work right, depending on what lib1 contains.

This could be possible. If lib1 becomes a dll itself, is this really all it takes?
In other words: is the problem the fact that lib1 is a static library linked in both original dlls?
Thanks!
and72.

The issue here is that when you create an instance of the library in one DLL that instance does not exist in the other DLL. So anything you do to the state of the library internally will not be evident in the other DLL.

We have run into this at work and as I understand it, DLL's by nature have their own independent memory. So if you were to create an instance of an object in DLL1 that instance does not exist across module boundaries. DLL2 has no instance of the object. So you are working with two independent instances.

There are several solutions but they are highly dependent on what you are trying to do and how much dev time you want to devote to the project. The easiest solution is to create a common wrapper that instantiates the object being shared and then have both DLL's call into the wrapper. This way they are both guaranteed to be accessing the same object and allows you to create a common interface to the object. So both DLLs will access the object in exactly the same manner.

DLL1 ---> Wrapper -> Library ---> Object instance <--- Library <--- Wrapper <---- DLL2

This isn't a completely accurate diagram since there is really only one instance of the wrapper.

Yes, much better.