Calling external DLL and project property settings

[mraviator]

I have Fortran code that previously included an external OBJ file. The company providing that file recently switched to providing a Windows DLL file, along with instructions on how to use it in code.

The basic gist is that you include use kernel32 so you can call LoadLibrary() to get the handle and then use that with GetProcAddress() to get the address of the function to call.

I did all of that, and it compiles error free. But LoadLibrary() always returns 0, which per the example code is an error opening the DLL.

I tried just the DLL name with extension as well as the full path to the DLL in the LoadLibrary() call, no change. 

Next I looked through the project properties and tried the following:

Fortran > Libraries > Use Common Windows Libraries: set to Yes

That also had no effect, so I played with Linker > Input > Additional Dependencies and set that to the DLL, since I previously had to se the OBJ path here. 

I'm also not sure if I need to set Fortran > Libraries > Runtime Library to the Multithread DLL or something else.

Since it compiles error free, but does not appear to find/use the DLL, I feel as if I'm missing some project property setting. Thoughts?

[mraviator · Accepted solution]

Of course, as soon as I asked the question, the solution presented itself...

I missed the small mention in the provided instructions that DFORRT.DLL might need to be included in the calling program folder. Doing that now provides a working solution. I made the false assumption it was already included "under the hood". 

[mecej4]

The command

dumpbin /dependents xyz.dll

will list the DLLs that the vendor company's xyz.dll requires.

[JohnNichols]

@mecej4 , I am always impressed by the breadth of your knowledge on all the variants of Fortran.  Why do you use all of these different compilers and what sort of code do you write/maintain?  

Someone using an old compiler is not surprising, I met with a guy last week who is using AutoCAD R14 and has to maintain old computers that will run it.  He and I both agreed that R14 was the best AutoCAD and it only got worse.  

[mraviator]

Nice, thanks!

[Steve_Lionel]

DFORRT.DLL is a DEC/Compaq Fortran DLL, not part of Intel Fortran.  The company providing your DLL is building it using a 20-year-old compiler.

[mraviator]

Yes, 20 years old indeed. I used CVF around the turn of the millennium myself. They said it could take months to get it ported and compiling in Intel Fortran. Must be a large code base, and based on the example code provided for the DLL, still F77.

[Steve_Lionel]

It should not take months. Days is more likely, unless there are bugs in the code that are revealed with a newer compiler. Sadly, Intel has removed the support article I wrote about migrating from CVF.

[mecej4]

Here is a link to the Steve Lionel white paper on porting from CVF to Intel Fortran. I have found many times that searching using Google, Bing, Yahoo, etc., can succeed even when the Intel forum search returns nothing.