Call a Sub In One Fortran DLL From Another Fortran DLL

[m_cash_stramel]

I have read/searched the help and this forum for the answer to my question but I am still confused.

Basically, I have a Fortran DLL (IVF10) containing subroutines that are called from VB.NET (2005). This works fine and has worked fine for quite some time. Now I need to create a second DLL to also be called from VB.NET, but the trick is that some of the subroutines in my new DLL need to call subroutines in my original DLL. The requirement for a second DLL exists because new source code has been provided by a third party and some naming conflicts exist (variable names, subroutine names, etc.).

My confusion lies with the INTERFACE, USE, etc. I'm not sure exactly which components I need or even exactly where they need to go.

Inside my ORIGINAL.DLL I have a subroutine TEST that looks like this...

SUBROUTINE TEST (A, B, C)
!DEC$ ATTRIBUTES STDCALL, REFERENCE, DLLEXPORT :: TEST
!DEC$ ATTRIBUTES ALIAS:"TEST" :: TEST
... code code code ...
END

Inside by NEW.DLL I have a subroutine DUMMY that needs to call subroutine TEST inside ORIGINAL.DLL.

SUBROUTINE DUMMY (T, U, V, W, X, Y, Z)
!DEC$ ATTRIBUTES STDCALL, REFERENCE, DLLEXPORT :: DUMMY
!DEC$ ATTRIBUTES ALIAS:"DUMMY" :: DUMMY
... code code code ...
CALL TEST (V, X, Z)
... code code code ...
END

I believe that I need an interface for subroutine TEST, but does this go in ORIGINAL.DLL or NEW.DLL. Right now I have the interface in a separate .FOR file inside NEW.DLL. It looks like this...

MODULE TEST_mod
INTERFACE
SUBROUTINE TEST(A,B,C)
!DEC$ ATTRIBUTES STDCALL, REFERENCE, DLLIMPORT :: TEST
!DEC$ ATTRIBUTES ALIAS:"TEST" :: TEST
CHARACTER(LEN=4), INTENT(IN) :: A
INTEGER(KIND=4), INTENT(OUT) :: B
CHARACTER(LEN=60), INTENT(OUT) :: C
END SUBROUTINE VAPTID
END INTERFACE
END MODULE TEST_mod

The error I get when compiling the NEW.DLL is that it can't find subroutine TEST (unresolved external symbol).

I have attempted to try "USE ORIGINAL" and "USE TEST_mod" inside subroutine DUMMY, but still I get the same error. Under tools --> options --> Intel Fortran --> general, I do have the directory that where ORIGINAL.DLL and ORIGINAL.LIB are located listed in both the Libraries and Includes location lists.

Which do I need? The DLL or the LIB? Obviously I need ORIGINAL.DLL to call from VB, but I've read some help/threads that indicate that I only need the LIB to call from the NEW.DLL. And how is NEW.DLL suppossed to know that subroutine TEST is found inside ORIGINAL.DLL? I am not sure what I'm missing here? Or even if I'm way off base.

Thanks in advance.

[Steven_L_Intel1]

I think you're mostly doing everything right, including the interface. The key you may be missing is that new.dll must link against original.lib.

[m_cash_stramel]

I've done some more research and it appears as if I had confused static vs dynamic binding. The method I was trying to use (static) would have forced me to include the ORIGINAL.LIB every time I built NEW.DLL. But this isn't what I wanted. Both DLL's are under continual development and I don't want to rebuild NEW.DLL every time I make a change to ORIGINAL.DLL.

I was able to put together the following call (using API) inside my NEW.DLL to subroutine TEST, which is located in ORIGINAL.DLL. I don't need the LIB file, and I don't need an interface. It works fine.

C------------------------------------

SUBROUTINE DUMMY (T, U, V, W, X, Y, Z)

USER KERNEL32
IMPLICIT NONE

INTEGER LOAD, UNLOAD
POINTER (pTEST, TEST)

LOAD = LOADLIBRARY("ORIGINAL.DLL")
pTEST = GETPROCADDRESS(LOAD, "TEST")

CALL TEST (V, X, Z)

UNLOAD = FREELIBRARY(LOAD)

RETURN
END

C------------------------------------

Now, obviously my files and subs aren't call ORIGINAL, NEW, TEST, etc. So if I made any slight errors in transcribing my real code into the illustration code above, my apologies.

[Steven_L_Intel1]

I think you're still a bit confused. The .lib that is created when you build a DLL is an export library - it has no code. So you could link against original.lib and then rebuild original.dll as many times as you wanted, as long as you did not introduce an incompatibility.

You can, of course, use dynamic loading too if that works for you.

[m_cash_stramel]

thanks Steve... no doubt i'm probably a little confused... i'm somewhat new to Fortran in general (but experienced in some other languages)... when I was in college in the late 90's my engineering professors all said not to bother with it because no one uses it anymore... ha! academics...

[Steven_L_Intel1]

This isn't a Fortran thing, really. It's general Windows programming.

Welcome to Fortran - not dead yet!