Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.
28450 Discussions

Calling external DLL and project property settings

mraviator
Novice
804 Views

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?

 

 

 

 

 

0 Kudos
1 Solution
mraviator
Novice
802 Views

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". 

View solution in original post

0 Kudos
8 Replies
mraviator
Novice
803 Views

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". 

0 Kudos
mecej4
Honored Contributor III
742 Views

The command

dumpbin /dependents xyz.dll

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

0 Kudos
JohnNichols
Valued Contributor III
731 Views

@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.  

 

0 Kudos
mraviator
Novice
717 Views
0 Kudos
Steve_Lionel
Honored Contributor III
767 Views

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.

0 Kudos
mraviator
Novice
721 Views

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.

0 Kudos
Steve_Lionel
Honored Contributor III
706 Views

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.

0 Kudos
mecej4
Honored Contributor III
676 Views

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.

Reply