Re: silverfrost IDE

Craig Powers wrote:
e p chandler wrote:
Elijah Cardon wrote:
I took my first swing at fortran since when Reagan was president, and think
that I did ok with the IDE from silverfrost f95. With the IDE, I'm trying
to make a dll that gets picked up by VB. Elsethread (subject: general
query), e.p. chandler suggested the following make file for this dll in a
fortran that looks to be the analog of gcc:

make.bat:

g95 -s -shared -mrtd -o test.dll test.def test.f95

g95 is the MinGW version. The options are:

-s = strip debug info
-shared = make a dll
-mrtd = calling convention is stdcall
-o = output file


http://www.billfordx.net/screendumps/dump1.htm

Anyways, the trick I think is going to be what a person does about the name
mangling, and figuring out where files belong in the IDE. I can't really
show output, because the night's only half over, and I'm going to fire up
the VB end. Any comment appreciated. EC

As posted you have messed up the Fortran source code a bit. Check your
variable names. I do not believe that Salford Fortran uses .def files
as g95 (or g77) does.

.def files are fundamental to the Windows linker, rather than to a
particular compiler. As long as Salford/Silverfrost does some sort of
name mangling on exported routines, and passes a .def file through to
the linker, then it is appropriate to use the .def file to rename the
exports according to your preference.

Salford provides its own linker (SLINK) which AFAIK does not use .def
files. In addition it has command line options to un-mangle exported
symbols or map exported symbols to aliases. Salford's docs for Fortran
77 describe how the linker works in detail and how it searches various
system dlls and import libraries. So I've never used MS-LINK or gcc's
ld for this purpose.

Once I work through the process for Salford Fortran 95 (FTN95) I will
post it here.



(The calling convention bit that I snipped is a more serious problem...
DVF and CVF (and presumably IVF) allow one to use compiler directives to
influence the choice of calling convention.)

That's a key problem on Windows. I suspect that even the F2003
C-interop does not help here. Each compiler has its own (non-standard)
way to handle sepcifying a dll, exporting symbols, name mangling,
calling convention, argument passing, etc., etc.
Add in the complexities of passing arguments other than simple integers
or reals plus the possibilities of different object file formats (OMF
vs COFF) and it's a real can of worms. :-).

g95 and gfortran, Salford, Open Watcom, Lahey, DVF/CVF/IVF all are
different here.
One of the problems for me was finding out how to get g77 and later
gfortran and g95 to use stdcall in exported routines. [Thanks to Mummit
Khan for pointing out the -mrtd switch. It sure was better than writing
wrappers in C as in my first attempts.]

-- Elliot
-- e-mail: epc8 at juno dot com

.

Relevant Pages

  • Re: DLL declarations created by VC++ app wizard
    ... As of now I just want to call one or two functions in my DLL from a VB ... There is no random code involved. ... some .DEF files in its example code. ... "exports" is not valid for the platform so ignored it. ...
    (microsoft.public.vc.language)
  • Re: Convert C-Builder program to Delphi?
    ... > quite separate from the function declaration itself. ... >this DLL ... >way the only place anything needs to be changed is in the #define macro. ... Exports SomeDLL_Open Name 'SomeDLL_Open'; ...
    (comp.lang.pascal.delphi.misc)
  • Re: Convert C-Builder program to Delphi?
    ... > quite separate from the function declaration itself. ... >this DLL ... >way the only place anything needs to be changed is in the #define macro. ... Exports SomeDLL_Open Name 'SomeDLL_Open'; ...
    (comp.lang.cpp)
  • Re: Export C++ class from a Borland DLL and use it in Microsoft VC
    ... Borland uses a different C runtime than Visual Studio. ... Of course, it is not impossible to use a DLL across compilers, even across different languages. ... You still need to use pure extern "C" exports, but the functions themselves can accept and return C++ classes. ... You must either not use enums in your interface, or modify Borland's compiler settings for your particular cpp file. ...
    (microsoft.public.dotnet.languages.vc)
  • Re: Export C++ class from a Borland DLL and use it in Microsoft VC
    ... Borland uses a different C runtime (including a different memory ... Use a C-style DLL. ... use pure extern "C" exports, but the functions themselves can accept and ... You must either not use enums in your interface, ...
    (microsoft.public.dotnet.languages.vc)