Interface to a DLL using derived types

An existing module, apparently written for Intel Fortran, for interfacing to a DLL uses derived types containing only an integer as an argument for functions or procedures as well as the result of functions.

MODULE intdll
IMPLICIT NONE
TYPE dt
  INTEGER i
END TYPE
INTERFACE
  TYPE(dt) FUNCTION xxx(k)
  !DEC$ATTRIBUTES C, DLLIMPORT, ALIAS:'_xxxA':: xxx
  IMPORT
  TYPE(dt) k
  END FUNCTION
END INTERFACE
END MODULE intdll

Is there a particular reason for using such a derived type?

Is there another (better) way than remplacing this derived type with an integer and suppressing the IMPORT statement when using FTN95?

In the absence of ISO_C_BINDING all Fortran arguments are passed by reference. So the address of a TYPE argument containing only one integer member should be the same as the address of the integer.

How the function return value is processed is more problematical and might be compiler dependent.

For FTN95 it is not possible to share module data between an executable and a DLL (only module routines can be shared). This means that there is little or no motivation for using modules in this context.

Don't forget that the FTN95 code will need to use an alias for the function name otherwise it will assume the DLL uses uppercase letters.

Perhaps the only way forward is to create an Intel DLL and then look at the interfacing at the assembler level.

Paul

Thanks for all these explanations and advice. It helped me a lot.