function export by DLL's

Hi, apparently the compiler switch /F_STDCALL given in the help under the item compiler options is valid only for subroutines, but not for functions. As functions by the help of the function assistant can more easily accessed in Excel as subroutines (by means of the VBA-declaration of this functions in a separate XLA-file and the installation of this XLA-file as Add-In in Excel), this is a pity. Instead of that you have to declare F_STDCALL (which implies the necessary call by reference) just before every function defined in your source code which shall be exported as WIN32-DLL to Excel, which is really cumbersome with hundreds of functions.
As I now have to link the same source as .NET DLL, I will remove these F_Stdcall declarations in front of the function declarations in my source code in compliance with the hint Win32 only, but is there any other declaration necessary in my source not mentioned under the link 'Releasing FTN95.NET executables and DLLs)? (Unfortunately I have no chance to test this .NET-DLL in a .NET environment.)

/F_STDCALL is designed for both subroutines and functions. The help file is not accurate in this detail.

That was exactly what I assumed, but if I tried to call the functions exported to an Excel-Add-In it doesn't work, therefore I inserted before each function the F_Stdcall declaration, and only then all of my functions have been exported to my Excel- XLA or XLAM-Add-In.

many thanks for your response

The exporting is enabled by using 'exportall' or 'export' with SLINK. There is also a comment embedded directive called DLLEXPORT (but this presumably only works with /LINK on the compiler command line). The compiler switch /F_STDCALL should have no effect on what is exported.

surely I have used the compiler switch /exportall, but to my experience additionally you needs the F_STDCALL declaration preceding every function definition in your source code if exporting your functions to an Excel XLA- oder XLAM-Add-In..

There must be something wrong, either in the compiler or in the way that you are doing things. At the moment I do not have sufficient information to know where the problem lies.

Hi, the way I am doing the job is:

in the sourcecode for building test.dll (/OPTIMISE /WIDE_SOURCE /FPP) :

F_STDCALL DOUBLE PRECISION FUNCTION Property_A(X,Y) following the fortran code for this function

F_STDCALL DOUBLE PRECISION FUNCTION Property_B(X,Y) following the fortran code for this function

in a module of test.xla or test.xlam, installed in Excel as Add-In: Public Declare Function PROPERTY_A Lib 'TEST.DLL' (ByRef X As Double, ByRef Y As Double) As Double Public Declare Function PROPERTY_B Lib 'TEST.DLL' (ByRef X As Double, ByRef Y As Double) As Double

then with the help of the function assistant you will find in the userdefined category the function PROPERTY_A(X,Y) and PROPERTY_B(X,Y) for the calculation of the PROPERTY_A and PROPERTY_B dependent of the input parameters X and Y (all defined as double precision)

(test.dll together with salflibc.dll should be copied to windows\system32 or any path defined in your environment variables)

Your code samples look OK to me. I will log this as requiring investigation.

There is no difference between the assembly code produced by FTN95 when you use F_STDCALL in the program and when you use /F_STDCALL as a compiler switch. You can test this by using /EXPLIST and comparing the resulting .lis files.

This means that the failure must be for some other reason.

Hi, yes, if I'm looking with the dependency walker or with dumpbin /exports in the DLL, all functions seem exported, but if I call the functions in Excel, only those functions preceded by F_STDCALL can be called in Excel. If I additionally use /F_STDCALL as compiler switch, also the two test functions with a preceding F_STDCALL are no longer callable like all the other functions in my source code.

There must be something else happening to create this effect. My tests show that there is no difference in the object code.