Multiple DLLs and inter calling

[dajum]

I'm trying to create two DLLs. In the first I call routine from the second. The routine being calledin the second calls a routine in the first DLL. What is the best way to make this occur? It seems they both need to link to the other, but I don't see how to make that happen.

First DLL
SUBROUTINE INIT
USE DATA
do stuff with DATA
CALL SUBA()
RETURN
AND CONTAINS subroutine SUBB
Module DATA

Second DLL
SUBROUTINE SUBA
USE DATA
do stuff with DATA
CALL SUBB
RETURN
END

Hopefully that is clear enough.

Thanks!

[mecej4]

If you create a .DEF file for each DLL, you can use LIB.EXE to build the corresponding .LIB and .EXP files, without having to write any code for the DLLs in advance.

Let us call the DLLs DLL_A and DLL_B. You can now write the source for DLL_A, which you use together with the DLL_A.EXP and DLL_B.LIB to compile and build DLL_A.DLL.

Next, you can write the source for DLL_B, which you compile and link with DLL_B.EXP and DLL_A.LIB to produce DLL_B.DLL.

Now you can run and test an application that calls these DLLs.

[Steven_L_Intel1]

I suggest that this is not a good design. My recommendation would be to either combine the routines in a single DLL, or pass the "callback" routine as an argument from one to the other, breaking the circular dependency.

[dajum]

The first dll is basically fixed and won't change, and is always going to call the same routines out of the second. But the second will be regenerated constantly andwill actually be calling lots and lots of routines from thefirst. I've considered just dynamically loading the second from the first, and finding the entry points similarly to the DynamicLoad sample. Then I assume the first doesn't need to know about the second when it is built, and the second willalways have access to the first.

Does that sound like a better design Steve?

Thanks!

[Steven_L_Intel1]

To be honest, that looks worse to me. It would be cleaner if the first DLL passed addresses of routines it wanted used to the second.

[dajum]

DLL1 has about 500 routines exported. DLL2 has only 10 routines that always get called from DLL1 and those 10 routines will call some subset of the 500 routines.DLL2 might even be unloaded and reloaded with different source. So the dynamic load method makes pretty good sense to me. I'm not sure how I could structure the code you are suggesting. Can you elaborate?

[Steven_L_Intel1]

If it really is 500 routines, then what I proposed would be awkward. What you propose makes me uncomfortable - but it will probably work. If these 500 routines are not used by the executable caller of the first DLL, it would be cleaner to move these into a third "utility" DLL which is linked against by the second.

[dajum]

There is too much interplay between many of the routines. There are about 2000 total, and many (most)are used within DLL1 as well. Why does it make you uncomfortable? I'd like to avoid trouble, but I need to be able to swap in a generic DLL2 for base cases and only build DLL2 for special cases. And DLL1 is being controled by another process and never changes. There are modules in DLL1 that will be used in some of the routines in DLL2.

[Steven_L_Intel1]

It makes me uncomfortable because of an implicit circular dependency, even though you have broken the circle at link time. But do whatever works for you.