Can you export internal module routines from a DLL with MSFPS4.0 and/or DVF5?

[Steve Lionel]

In article <01bcb9af$153f0c00$3767adce@rldobbs>, "Rich Dobbs"
<rld...@concentric.net> writes:
|>I've written several applications that use Visual Basic 4.0 and Visual
|>Basic 5.0 to create a Window application that calls a DLL written in F90
|>(MSFPS4.0 and DVF 5.0) that does the heavy computational work. I tried
|>unsuccessfully to export some of the internal routines contained in a
|>module from the DLL, but after making no head way I wrote a set external
|>routines that call the desired internal routines passing the arguments
|>through. These routines use the appropriate compiler meta-command to mark
|>the routines for export. This has worked OK, but I grow tired of the extra
|>work of creating and maintaining these routines.
|>
|>Is there a technical reason I had problems with exporting the internal
|>routine names, or did I just not figure out how the internal names were
|>mangled by the compiler?

I'm a bit confused as to what you're referring to. "Internal routines" are
defined as those contained within another routine, and to call one of these
you need to supply an up-level context established by the host. There is no way
to properly establish this context if you were allowed to call the internal
routine directly from outside the host.

We have, recently, begun adding support for passing internal routines as
actual arguments - from within the host - this will show up in new versions of
our Fortran 90 compilers on various platforms. This is an extension to the
language.

However, you said "contained in a module" - normal "module-level" routines
can certainly be exported through an INTERFACE block and the appropriate
directives. I am guessing that you really do mean routines that are
contained within another routine.

Let me suggest to you, though, that what you want to do is a "bad idea".
Internal routines are supposed to be internal. If you have code you want to
make externally accessible, then by all means define a module-level interface
for that code, as you have done. Or, perhaps, redefine the internal routines
to be "external" and use them that way throughout your code.
--
Please send DIGITAL Visual Fortran support requests to dvf-s...@digital.com

Steve Lionel mailto:lio...@mail.dec.com
Fortran Development http://www.digital.com/info/slionel.html
Digital Equipment Corporation
110 Spit Brook Road, ZKO2-3/N30
Nashua, NH 03062-2698 "Free advice is worth every cent"

For information on DIGITAL Fortran, see http://www.digital.com/fortran

[Rich Dobbs]

Steve Lionel <lio...@mail.dec.com> wrote in article
<5v0vpn$c...@usenet.pa.dec.com>...

> ...

> I'm a bit confused as to what you're referring to. "Internal routines"
are
> defined as those contained within another routine, and to call one of
these
> you need to supply an up-level context established by the host. There is
no way
> to properly establish this context if you were allowed to call the
internal

> routine directly from outside the host. ...

Sorry that I was not precise enough. I am referring to module level
routines.

> However, you said "contained in a module" - normal "module-level"
routines
> can certainly be exported through an INTERFACE block and the appropriate

> directives. ...
> ...

Thanks for information. Is it necessary to place the directives in an
interface
block, or can the directives be placed in the implementation of the
procedure
(which works with routines that are not contained in a module)?

> ... If you have code you want to

> make externally accessible, then by all means define a module-level
interface

> for that code, as you have done. ...

But that is exactly what I haven't been able to successfully do. So far I
have
only been successful in exporting routines that are not contained in a
module.
But it helpful to know that it is possible to export module level routines
from
a DLL.

Best regards,

Rich Dobbs

[Steve Lionel]

In article <01bcbce5$b1c45ce0$1067adce@rldobbs>, "Rich Dobbs"
<rld...@concentric.net> writes:

|>Thanks for information. Is it necessary to place the directives in an
|>interface
|>block, or can the directives be placed in the implementation of the
|>procedure
|>(which works with routines that are not contained in a module)?

If you have contained routines, you don't have an INTERFACE block, as the
routine creates its own interface. (This is different if you have
MODULE PROCEDUREs.

The following works (I just tried it).

Make a "Win32 Dynamic-Link Library" project containing the following file:

MODULE MYDLLMOD
CONTAINS
SUBROUTINE FOO
!DEC$ ATTRIBUTES DLLEXPORT :: FOO
TYPE *, 'Hello from FOO!'
RETURN
END

Build it.

Now create a "Win32 Console Application" with the following file:

USE MYDLLMOD
CALL FOO
END

You'll need to modify the Include path (under Project..Settings..
Fortran..Preprocessor) to include the directory containing the MYDLLMOD.MOD
file (or move it to the DEBUG (or RELEASE) subdirectory of the current
project). Use Project..Add To Project..Files to add the .LIB file created by
the DLL project to your test project. Now build. Last, you'll need to move
the DLL itself to the same directory as the .EXE (or somewhere else on your
PATH). Run the program. Enjoy.

[Xingzeng Liu]

You can export module level subroutines without any problem if you know
the correct expoted names. It should be noted that the exported name is
not the name as you specied in "!MS$attribute dllexport" statement for
module-level subroutines. Please use the program "DUMPBIN.EXE" to find
the correct name of expoted subroutines.