11.1.067 Compiler can not find GetProcAddress

[aelliott]

In compiling a module using 11.1.067 Wx64 which includes this excerpt:

!---------------
MODULE DLL_Interface

USE Kernel32

IMPLICIT NONE

! Defined TYPEs:

TYPE DLL_Type

INTEGER(4) :: FileAddr
INTEGER(4) :: ProcAddr
CHARACTER(1024) :: FileName
CHARACTER(1024) :: ProcName

END TYPE DLL_Type

CONTAINS
=======================================================================
SUBROUTINE LoadDLL ( DLL )

USE NWTC_LIBRARY, ONLY: ProgAbort
IMPLICIT NONE

! Passed Variables:

TYPE (DLL_Type), POINTER :: DLL ! The DLL to be loaded.

! Load the DLL and get the file address:

DLL%FileAddr = LoadLibrary( TRIM(DLL%FileName)//CHAR(0) )

IF ( DLL%FileAddr == 0 ) CALL ProgAbort ( ' The DLL '//TRIM(DLL%FileName)//' could not be loaded.' )

! Get the procedure address:

DLL%ProcAddr = GetProcAddress( DLL%FileAddr, TRIM(DLL%ProcName)//CHAR(0) )

IF ( DLL%ProcAddr == 0 ) CALL ProgAbort ( ' The procedure '//TRIM(DLL%ProcName)//' could not be loaded.' )

RETURN
END SUBROUTINE LoadDLL

!---------------------

I get the following error:

C:\\\\\\FAST\\\\Source\\\\BladedDLLInterface.f90(119): error #6284:
There is no matching specific function for this generic function reference. [GETPROCADDRESS]

DLL%ProcAddr = GetProcAddress( DLL%FileAddr, TRIM(DLL%ProcName)//CHAR(0) )

I am a bit confused because GetProcAddress is in kernel32 along with LoadLibrary, and this code previously compiled using v10 for 32-bit. I expect I am missing something?

Andy Elliott

[Steven_L_Intel1]

You misinterpret the error. It's not that the compiler can't find the routine, but that its definition of the routine doesn't match the arguments you passed. In this case, addresses and handles must be 64-bits on x64, and you are using 32-bit values. Rather than INTEGER(4), use INTEGER(HANDLE) for the "Addr" fields.

Note also that when you return a value from LoadLibrary, that is a 64-bit value but you assign it to a 32-bit value, which will cause run-time errors.

[Paul_Curtis]

LoadLibrary() returns a handle to the module, which is not at all the same as your suggested %fileaddr. Suggest you review the argument definitions for LoadLibrary() at the msdn website.

[aelliott]

Thanks much. Its not my code, and Iam often not good when trying to figure out what other folks have done when it fails. It looks like I will need to carefully examine the entire package to make it 64-bit compatible. :(

[Steven_L_Intel1]

Mainly you will have to pay attention to Win32 calls that deal with handles or addresses. In most cases, as you found, the compiler will complain. For straight Fortran code, it should not be an issue, unless there is use of %LOC or LOC intrinsics assigning to INTEGER(4) variables.

[aelliott]

Thanks much. Its not my code, and Iam often not good when trying to figure out what other folks have done when it fails. It looks like I will need to carefully examine the entire package to make it 64-bit compatible. :(

[IanH]

Quoting Paul Curtis

LoadLibrary() returns a handle to the module, which is not at all the same as your suggested %fileaddr.

Actually, you and the component's name (sort of) are both right ... a Win32 module handle is the same as the address of the module in memory.