How can I export a generic interface from a DLL?

[OP1]

I want to create a DLL which contains subroutines SUB_A, and SUB_B, but I want these to be accessed by a generic name MY_GENERIC_SUB outside the DLL. How can I do this? The pseudo-code below indicates what I want, but won't link properly with my code (I'll get an unresolved external symbol error).

This is the main file for my DLL:

MODULE MY_DLL
IMPLICIT NONE
...
INTERFACE MY_GENERIC_SUB
MODULE PROCEDURE SUB_A,SUB_B
END INTERFACE MY_GENERIC_SUB
...
CONTAINS
...
SUBROUTINE SUB_A(...)
!DEC$ ATTRIBUTES DLLEXPORT :: SUB_A
...
END SUBROUTINE SUB_A
...
SUBROUTINE SUB_B(...)
!DEC$ ATTRIBUTES DLLEXPORT :: SUB_B
...
END SUBROUTINE SUB_B
...
END MODULE MY_DLL



Thanks for your help!

Olivier

[Steven_L_Intel1]

What you show above should work fine, and I've done this myself, as long as the executable USEs the same module. You may want to make everything PRIVATE except the generics you want to export.

[OP1]

Quoting - Steve Lionel (Intel)

What you show above should work fine, and I've done this myself, as long as the executable USEs the same module. You may want to make everything PRIVATE except the generics you want to export.

Thanks Steve,

I think I found the source of my problems. My *.dll file has to be copied in the same directory as the one where the debug version of my executable file is. My VS solution contains the dll and the main program - I was expecting that when launched the path info for the *.exe would include the location of the *.dll.
Is there a way to avoid making a manual copy of the *.dll file every time the *.dll is built?

Olivier

[Steven_L_Intel1]

What I do is add a "Post-Build Event" for the DLL project that copies, with the COPY command, the DLL into the executable folder. EXEs do not contain DLL paths - just the DLL name. Windows has a list of places it looks in for DLLs.

[IanH]

Alternatively, you could play with the Output Directory properties (General tab) for the DLL project and the EXE project, and make then the same (in an absolute path sense). Perhaps set both to something like "$(SolutionDir)$(ConfigurationName)", which is what MS's C++ projects use by default. A few other things (like the import libs, pdb's, various manifest file droppings and the ocasional kitchen sink) might then get poked into that directory too, which may not suit depending on your taste in plumbing.

Alternatively, you could specify in the Environment property for the executable (Debugging tab) "PATH=the_directory_with_the_dll;%PATH%" to ensure that the exe has half a chance of finding the DLL. the_directory_with_the_dll might be something like "$(SolutionDir)dll_project_name$(ConfigurationName)". This approach is handy if the exe that works with the DLL is not something that you've built, but rather a third party thing like excel or matlab. Be wary of multiple copies of the DLL though, because immense confusion can result if the wrong version gets picked up.

In both the above, be mindful of which configurations (Debug/Release/etc) you apply the property changes to.

Alternatively, you could have a final (ie. it depends on all other projects) "install" project that includes some custom build rules (post build events on steroids) to take the outputs from other projects and install them (plus things like configuration files etc) into a final directory tree (bit like a setup/deployment project that doesn't actually build an msi file). This will earn you credits for snazziness, but if its anything like my attempts you'll spend 80% of your time trying to get it to work properly and end up wishing that you'd just opted for a couple of post-build events that called copy...