Help: Visual C ++ and Fortran DLL

[Intel_C_Intel]

Please tell me any way that will work to export a fortran dll to use with Visual C++. I do not know fortran; I just want to add exports to working code and call it from C++.

The dll I exported compiles and links to the C project but gives a page fault when the subroutine is called. This is because the calling convertions are wrong in one or both programs. All I need are the compatible dll import and export lines for the C and the Fortran.

Thanks
JB

[Steven_L_Intel1]

Have you read the chapter of the Programmer's Guide that deals with mixed-language programming?

For an example, see this sample from our web site

Steve

[Intel_C_Intel]

Steve

I was glad to hear that you are suggesting the same convention I'm trying to get accepted here - have "foreign" callers pass string lengths by value as "hidden" arguments so that "downstream" Fortran routines can protect their caller's memory when returning a variable length string argument. Unfortunately, we started out using "stdcall" attributes and didn't pass lengths - now we've got a goodly number of Fortran DLLs out there and our users will fuss when we want to change the method. I've drafted a short white paper on the subject complete with VB to Fortran and C++ to Fortran examples that illustrates the approach, but acceptance is still slow in coming.

An old customer for our models has apparently had performance problems using DLLs he build using the Lahey F95 compiler. I cannot explain why linking objects statically would improve performance in this manner, but it may be related to DLL handling problems in his compiler. I'm proposing to send him some test DLLs developed here and see what happens then. The customer wants us to release our source code for this proprietary software, but our policy now discourages such releases. As a side note, according to the documentation I've looked at LF95 also passes strings with a "hidden" length by value.

I also wondered if there is any inherent performance advantage to be gained by using an explicit loadlibrary, getprocaddress, (many calls to entries), and freelibrary approach. Can't see any reason there should be, but thought someone out there in CVF land might know.
Otherwise, could non-CVF linkers handle an object library built by CVF? I haven't had time to check this out either.

Thanks

John

P.S. Steve - if this is too rambling or you want to parcel it up over a couple of categories, please do. So far, I like the looks of the new forum.

John

[Steven_L_Intel1]

John,

The only Fortrans I know of that DON'T pass string lengths as a separate argument are those which pass a descriptor instead, such as on OpenVMS. A length is necessary to get Fortran semantics. The usual method is to pass all the lengths at the end of the argument list, but this can cause problems with omitted arguments. MS did it by putting the length right after the address, so we do too. But this causes problems for people who mismatch types deliberately. Sigh.

Calling a DLL routine involves two extra instructions including a jump to the actual routine call - these extra instructions are in the DLL. Static linking avoids this. It would take an unusual application to notice the difference, but it is there.

All DLLs look the same from the calling perspective. The issues are how to resolve references to DLL routines at link time. The MS linker requires an "import library", some other linkers synthesize this information from the DLL. We have a utility called MAKILIB that will create an import library from a DLL.

As for object libraries, the other linker would have to understand the MS COFF format. Some do, some don't.

Steve

[Intel_C_Intel]

Steve

Thanks for confirming my guess on the DELL overhead. I poked about with the debugger and came to pretty much the same conclusion - I still can't speak to the LF95 approach.

I'd forgotten about MS and Files11 - God - was it that long ago? I was always impressed that DEC followed the ANTI standard - seemed like no one else did.

The only reason I might have to consider static libraries are because we're now getting requests for our models on on-Windows platforms. Mostly NIX, LINUX, and their blood relatives. Our strategy is leaning toward building the models as static libraries and wrapping them inside a DELL wrapper program for the WIN32 world. We've done this before and it does give you good control over what the external user sees of the model's innards.

Thanks for the ever-helpful advice.

John