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

Compatible calling conventions

tenuti
Beginner
502 Views
Is there a way to have compatible calling conventions in order to use the same DLLs in different scopes? The pool of DLLs I'm fixing up in this week was developed with a Fortran compiler, which was using probably the STDCALL calling convention as default.
The Visual Fortran compiler has different default calling convention. I'll looking for a set of project configuration properties in order to be able to use the same DLLs from Visual Basic 6 and for an internal IVF-developed executable file.
Past scenario:
- pool of DLLs with the default calling convention of the older compiler
- a Visual Basic 6 executable filewhich called those DLLs
- a Fortran developed executable file which called the same DLL files
Current scenario:
- pool of DLLs with a compatible calling convention of the IVF compiler
- another Visual Basic 6 executable file which calls these DLLs
- an IVF developed executable file which should call the same DLL files
At now I'm in the process to find a compatible set of parameters to avoid project duplication or source modification each time I need to compile the pool of DLLs for different targets.
I noticed that Visual Basic 6 needs basically the STDCALL calling convention in order to be able to call the DLL exposed functions, but the current Fortran project which invokes the same DLLs,doesn'ttoleratethe same conventions while passing strings.
Take care the fact that almostall theexposed functions in the DLLs havethese arguments:
subroutine MYSUBROUTINE(value,path)
!DEC$ ATTRIBUTES DLLEXPORT :: MYSUBROUTINE
!!DEC$ ATTRIBUTES ALIAS:'MYSUBROUTINE' :: MYSUBROUTINE
integer, intent(in) :: value
character*255 path
endsubroutine
In the meanwhile I'm working to prepare you a full downloadable example to test in your own computers.
0 Kudos
4 Replies
tenuti
Beginner
502 Views

Here it is the example I just prepared. It contains a ZIP file with three folders:

- FortTest project: it is a IVF Fortran project that generatesthe DLLwith the STDCALL calling convention in order to be used with the VB6 client project

- FortApp project: it is the IVF Fortran project that should use the former DLL with the STDCALL convention

- VBLaunch project: it is a Visual Basic 6 project that uses the DLL and has intrinsic STDCALL calling convention that cannot be modified

At now the VB6 project is able to call the DLL, but there's something wrong while passing the strings. However the FortApp project cannot be linked at all.

Do you have any advice?

0 Kudos
tenuti
Beginner
502 Views

I noticed a very old thread where you discussed to use with Visual Basic 6these additional options in the Fortran project properties:

/dll /iface:cvf /iface:nomixed_str_len_arg

It seems to be the solution for both the scopes. There's only the ALIAS ATTRIBUTE, that is needed for the VB6 client application, whilst it is not tolerated by the Fortran client application.

It seems that such attribute associated to the exposed function makes an unresolved external symbol when linking the Fortran client application, so I need to change the source each time I compile for each target, commenting or uncommenting suchattribute.

0 Kudos
Les_Neilson
Valued Contributor II
502 Views

Could you use a compiler pre-processor directive for conditional compilation?

You could just wrap each source line(s) to beused for a specific targetwith a

!DEC$ if defined (FOO)

!DEC$ endif

and so on

Les

0 Kudos
Steven_L_Intel1
Employee
502 Views
The solution is to have the DLL routines use the STDCALL convention and to supply a module for the Fortran code that has INTERFACE blocks that include the appropriate ATTRIBUTES directives for each routine. Then the Fortran code will call the DLL routines correctly.
0 Kudos
Reply