DLL best practices?

[dwwade]

Since Fortran 2003 gives the ability to have cross language compatibility, is it now good standard practice to bindc and use iso c bindings for all functions/subroutines exported to DLLs and in particular those that may be used by other languages?  The "MixedLanguage" samples in the 2013 samples directory doesn't seem to show this, but they are also dated as copyright 2007.

[IanH]

"All" is a bit strong - BIND(C) significantly limits the allowable characteristics of a procedure.  In addition, on 32 bit Windows some languages and all (?) base operating system "call backs" need to be something that is not what BIND(C) typically implies.

If the design intent is that the procedure could be directly called from other C compatible languages (which could include other Fortran compilers) then BIND(C) is very reasonable way of specifying aspects of the binary interface to your DLL in a way that is far more likely to be interoperable than not. 

(Mixed languages and DLL's are somewhat orthogonal concepts.)

[Steven_L_Intel1]

Several of the samples have been updated to use the C interoperability features, including "Fortran Calls C". You're looking at the C Calls Fortran sample which has not been updated.

[dwwade]

IanH wrote:

"All" is a bit strong - BIND(C) significantly limits the allowable characteristics of a procedure.  In addition, on 32 bit Windows some languages and all (?) base operating system "call backs" need to be something that is not what BIND(C) typically implies.

If the design intent is that the procedure could be directly called from other C compatible languages (which could include other Fortran compilers) then BIND(C) is very reasonable way of specifying aspects of the binary interface to your DLL in a way that is far more likely to be interoperable than not. 

(Mixed languages and DLL's are somewhat orthogonal concepts.)

Very insightful, thank you.  The intent wouldn't be to make it compatible with the win32 data types, but just to ensure that as you said C compatible languages relatively easy access.  I know that for clean up, unless otherwise specified as a __stdcall, that IVF assumes __cdecl, but that only says how the data is removed from the stack and not the standards for the data types, right?  Am I am wrong in assuming that most every language that can use DLLs has a relatively simple way of using C data types?

I'll agree that mixed languages and DLL's are different topics, but the Venn diagram of the two does have a sizeable intersection.  I thought that perhaps there had been some discussions on a "right" way to create dynamic libraries be it for Windows or Linux.

[dwwade]

Steve Lionel (Intel) wrote:

Several of the samples have been updated to use the C interoperability features, including "Fortran Calls C". You're looking at the C Calls Fortran sample which has not been updated.

That is true, however, that is the one that makes the most sense to me in this case.  I did notice that the dynamic load DLL example had the program doing ISO C binding in the main program to setup the library with Windows, but that the library itself doesn't use it, which made sense to me since the library was only going to be called from Fortran. It also uses the C_INTPTR_T sized integer, but I've never used the intptr_t typedef in C, so I wasn't really sure the purpose other than to just make sure that it fit the size to the Windows given pointer to the function within the library.

The excel DLL didn't use it, but I wasn't sure if that was that it didn't make sense to do so or that the example just hadn't been updated.  Yes, the Fortran calls C did use it, but it is interacting directly with the C routine, which makes sense since the other side of the interface is a known static routine.  I wasn't sure if it was considered more correct for Fortran to always be the accomodator regardless of what is being called.

I was just trying to seek from the wisdom that has been gained through use of these new faculties rather than fumbling around and finding out something after a couple of weeks of bashing my head against a wall.

Darren

[Steven_L_Intel1]

The Excel sample won't use it as that's not C.  The Fortran_calls_C sample should use it.  C_INTPTR_T is the appropriate kind to use for a pointer-sized integer.

[dwwade]

That really goes back to my original question then.  Is there a best practice for creating DLLs that will have to interface with non-Fortran that involves using bind(c) and use instrinsic, iso_c_binding?  It isn't a question of how to do it, though that is good to know and an example of how the other side of the interface might be implemented would be helpful (F calling C is showing the other side), but if it should be used in general when you are writing something that will be interacted with by the rest of the universe since most things aren't particularly Fortran aware. 

Ian's suggestion of using it where the language is C compatible is likely the one I'll use for now unless there is some general concensus that this isn't the right approach. 

For the current task at hand, all of the functions that I'm going to create are actually just interaces to my real library and most of them turn even my subroutines into functions in order that the dll can be used by both MATLAB (loadlibrary) and Excel.  Using these two pieces of software make it such that I don't have to write a sophisticated interactive calculator system that encompasses my library (emulating an earlier software and using those complicated scrolling functions from a prior thread).  If this works out well, then I may consider using this method for some of my other code, thus my reasoning for wanting to see if there is a set of best practices.

Thanks,

Darren

[IanH]

(Just to be clear - you can't put BIND(C) on procedures intended to be called from 32 bit Excel - it can only do stdcall.  On the other hand, I'm pretty sure you can convince 32 bit Matlab to call using either stdcall or cdecl on Windows.  In the 64 bit world life is simpler.)

I still think "it depends".  Further rambling... my approach for those two environments is to write thin wrapper procedures around the real Fortran library that can take advantage of the particular characteristics of each environment - i.e. the Excel wrapper can work with COM handles to ranges and worksheets, the Matlab wrapper can work with matlab variables (mxStructs, mxArrays, etc). Fortrain clients don't have to use a wrapper.

In the Matlab case I do use BIND(C) and a lot of ISO_C_BINDING stuff, because I think that is the most robust way of matching the Fortran to Matlab's binary interface.  I recall sitting down one day and translating one of their C header files across to a Fortran module.  I'm a few versions off the pace these days, but back when I was current I thought it a shame that the vendor behind that product doesn't do that for its Fortran clients - its been a while since use of the C preprocessor was the best way of providing Fortran interfaces.  Anyway, obviously that code is tied to that particular host software - but it is potentially platform (OS, compiler) portable.

In the Excel case I think I only use C_INTPTR_T from ISO_C_BINDING as a "standard" way of doing INT_PTR_KIND() or whatever the ifort intrinsic extension is, because using things that are closer to the standard makes me feel all warm and snuggly (note that this is delusional on my part, because with the strong Excel binding and all the COM and DEC$ ATTRIBUTES gunk portability is never going to be relevant).

If I was providing a general purpose binary only library (static or DLL) then BIND(C) would probably be one (and maybe the only one) of the interfaces I'd provide, given there tends to be less variation in C ABI between compilers (you can still get variation though!). If reasonable I'd also consider a separate, higher fidelity Fortran interface - using things like elemental procedures, allocatable/pointer/assumed shape/optional/polymorphic arguments, etc, etc.  All those things can be quite handy, depending on the nature of the library.  That decision would need to be mindful of the fact that the Fortran interface is definitely compiler, and may well be compiler option and compiler version, specific.

For a sort of example - see the HDF5 libraries. (In that case the higher fidelity Fortran interface is actually on top of a fundamentally C api, but the Fortran programmer really doesn't need to know that.)

While precompiled binaries can be convenient this also shows why there are good reasons to provide Fortran libraries in source form... the source is the portable thing, not the binary library.  Personally I'd appreciate it if the language developed further in ways that made it easier to write and use such source libraries.

[SergeyKostrov]

>>...For the current task at hand, all of the functions that I'm going to create are actually just interaces to my real >>library and most of them turn even my subroutines into functions in order that the dll can be used by both MATLAB >>(loadlibrary) and Excel... In that case I would consider an ActiveX based solution. ActiveX controls could be easily integrated with MATLAB ( I could provide some generic guidance with some C/C++ examples... ) and Excel, and many other applications. That "magic" ActiveX control could work as a "gate" and could interact with Fortran DLLs internally. Does it make sense?

[dwwade]

Sergey Kostrov wrote:

>>...For the current task at hand, all of the functions that I'm going to create are actually just interaces to my real
>>library and most of them turn even my subroutines into functions in order that the dll can be used by both MATLAB
>>(loadlibrary) and Excel...

In that case I would consider an ActiveX based solution. ActiveX controls could be easily integrated with MATLAB ( I could provide some generic guidance with some C/C++ examples... ) and Excel, and many other applications. That "magic" ActiveX control could work as a "gate" and could interact with Fortran DLLs internally. Does it make sense?

That would actually make sense if I didn't have the small issue that all administrator and power user rights have been taken from me on my workstation.  If I remember right you have to register ActiveX just like you do COM controls in the registry and my company's IT department hasn't made it easy to do my job in that respect.  I know that I had written some c# ActiveX plugins for STK, but that now I can't do anything to change them since they are already registered.

[SergeyKostrov]

>>...If I remember right you have to register ActiveX just like you do COM controls in the registry... Yes, that is correct, and an ActiveX control needs to be registered.