Problem with program based on DLLs, lib files and source code

[olmak]

Hi. Once again I need your help. I have developed a program based on two DLLs, DLL1.DLL and DLL2.DLL. Both DLLs interact with each other. DLL1 calls subroutines stored in DLL2 and vice versa. For some reason, I am allowed to distribute the source code of DLL1 (SRCDLL1.FOR)but not the code of DLL2. Therefore, I provide a lib file which corresponds to DLL2. However, executing a main program (MAIN.FOR) which calls a subroutine stored in SRCDLL1.FOR which then calls a subroutine in DLL2.DLL does not seem to work. But everything works fine when I link both lib files of the two DLLs to the main program. Why is that? How can I solve this problem?

[Jugoslav_Dujic]

Sorry, I don't follow you... can you describe your setup more precisely?

Both DLLs interact with each other. DLL1 calls subroutines stored in DLL2 and vice versa.

How did you manage to do that at all? You would get linker errors unless you have both libs at the same time -- it's doable but it's not easy (DllExp2 sample shows the complicated technique with makefile).

However, executing a main program (MAIN.FOR) which calls a subroutine

stored in SRCDLL1.FOR which then calls a subroutine in DLL2.DLL does not seem to work.

Can you elaborate "does not seem to work"?

Jugoslav

[olmak]

I applied the same technique as presented in the example DLLEXP2. After running nmake with a prepared makefile I got two initial lib files. After that I was able to proceed with a standard CVF (v6.6.C) project building new DLLs with new lib files.

Linking the project mentioned above is no problem at all. But when calling asubroutine from the DLL (DLL2.DLL) nothing happens. Although all routines are present during linking, the call of any routine stored in the second DLL is impossible.

In the meantime I found out that my program runs normally when I use the object file DLL2.OBJ instead of the corresponding lib file. But I still don't understand the reason for that. Using the lib file would be more convenient.

I am looking forward to your comments.

Many thanks in advance.

[Jugoslav_Dujic]

OK, method used in DllExp2 explains it (but it's pretty ugly solution in my opinion). Any reason you don'tmerge Dll1 and Dll2 into one? Such "circular" dependencies are a sign of bad design.

First, have in mind that .lib file which you get when building a dll is not "real" code. Basically, it serves only two purposes:

- it keeps linker happy

- it tells the Windows which DLL's to load when loading the process (& where to find the called routines)

Thus, if you link with the Dll2.obj file, you don't use Dll2.dll at all -- you're statically linking with Dll2.for (i.e. the result is as if you inserted Dll2.for into .exe's project).

But I still don't get "nothing happens" part -- if something is screwed up, I'd expect a crash, access violation, "dll not found" message, or something similar. Plain ommision to execute the subroutine in Dll2 is in my opinion pretty much impossible.

Also, I didn't quitesee the relationship with"redistribution of source code" you mentioned in your first post -- if you distribute only dll's to the end users, they can't see any source codes.

Jugoslav

[olmak]

You are right. Such circular dependencies are ugly. But nevertheless, I have to use them so far. The program crashes in debug mode (when executing the program it runs without calling any subroutine of DLL2). Although DLL2 is obviously loaded, it says "no matching symbolic information found". Hope this helps. DLL2.DLL is stored in a directory with path access.

I am allowed to distribute only one part of the source code (the one of DLL1). The other part must be in compiled form. But the user would like to be able to make changes to DLL1. Thus, I guess the solution with the object files is a nice "workaround".

Message Edited by olmak on 09-15-2004 08:19 AM