Fortran - exporting functions/subs from fortran?

Author

exporting functions/subs from fortran?

Jeff D. Hamann

2004-06-29, 4:09 pm

FORTRAN folks,

I apologies in advanced for asking a seemingly non-FORTRAN question here,
but this project is all FORTRAN and I figured this would be a good place to
ask.

I've been looking at extending a large FORTRAN project so that developers
can utilize functions and subroutines from outside the process (the exe).
I've created a test project (an exe) and exported a couple of functions and
have been successful in calling the exported subroutines from another
process like VBA in Access. When I attempt to assign a variables some value
in the source code (when debugging) I get access violations. I thought it
had something to do with the way I was calling the exported functions, so
simply commented out my code to see if the previously existing code would
work. Again, when the debugger got a line of code with an assignment op
(usually very early into a subroutine), I got an access violation. I created
a second project that didn't contain a "program main" and it worked fine
(created a genuine dll project). I'm assuming it has something to do with
the fact that I'm calling code in an exe from another exe and the first
process has "secured" the memory so that the second "process" (now loaded as
a DLL) cannot change values. Creating a DLL "version" isn't really
acceptable because most of the others in the project don't get the concept
and I want the changes to the code in the repos to be as minimal as
possible.

If that's the case, is it possible to call code in one exe from another
using the DLL framework? And if so, how?

Thanks,
Jeff.

---
Jeff D. Hamann
Forest Informatics, Inc.
PO Box 1421
Corvallis, Oregon USA 97339-1421
541-754-1428
jeff.hamann@forestinformatics.com
www.forestinformatics.com

Jugoslav Dujic

2004-06-30, 9:05 am

Jeff D. Hamann wrote:
| FORTRAN folks,
|
| I apologies in advanced for asking a seemingly non-FORTRAN question here,
| but this project is all FORTRAN and I figured this would be a good place to
| ask.

Hmmm, you should really be better off in some win32 programming newsgroups
(comp.os.ms-windows.programmer.win32 for example).

| I've been looking at extending a large FORTRAN project so that developers
| can utilize functions and subroutines from outside the process (the exe).

For one, I knew it was possible to export functions from an .exe file,
but it never appealed to me as worthwhile to try (and I haven't find
the purpose in any case). (Out-of-process COM .exe servers are another
story).

| I've created a test project (an exe) and exported a couple of functions and
| have been successful in calling the exported subroutines from another
| process like VBA in Access. When I attempt to assign a variables some value
| in the source code (when debugging) I get access violations. I thought it
| had something to do with the way I was calling the exported functions, so
| simply commented out my code to see if the previously existing code would
| work. Again, when the debugger got a line of code with an assignment op
| (usually very early into a subroutine), I got an access violation.

I really don't know how loading an .exe into context of another process
works, but that doesn't surprise me much. What probably happened is that
you passed an argument from another process by reference (address), but
since every process has distinct address space, that address as received
in another process is meaningless (i.e. points to something totally different
in the receiving process).

| I created
| a second project that didn't contain a "program main" and it worked fine
| (created a genuine dll project). I'm assuming it has something to do with
| the fact that I'm calling code in an exe from another exe and the first
| process has "secured" the memory so that the second "process" (now loaded as
| a DLL) cannot change values. Creating a DLL "version" isn't really
| acceptable because most of the others in the project don't get the concept
| and I want the changes to the code in the repos to be as minimal as
| possible.

I'm affraid that it's about the only practical solution. As I mentioned, there
are
"out-of-process COM servers" but they have totally different architecture and
can be quite complicated to learn and to implement in Fortran.

But I don't see the problem with it. In effect, you have already created a
dll which happens to have extension .exe and erroneously runs in its own
process space.

In addition, if you need some kind of data sharing between different instances
of Access+Dll processes, you can e.g. google for "ShareBufferWin32" by Gary
L. Scott.

--
Jugoslav
___________
www.geocities.com/jdujic

Please reply to the newsgroup.
You can find my real e-mail on my home page above.

Jan Vorbrüggen

2004-06-30, 9:05 am

> As I mentioned, there are "out-of-process COM servers" but they have totally
> different architecture and can be quite complicated to learn and to implement
> in Fortran.

ISTR that DVF comes with a COM wizard...

Jan

Jugoslav Dujic

2004-06-30, 3:59 pm

Jan Vorbrüggen wrote:
|| As I mentioned, there are "out-of-process COM servers" but they have totally
| > different architecture and can be quite complicated to learn and to
| implement > in Fortran.
|
| ISTR that DVF comes with a COM wizard...

CVF 6.5+ Pro version only can create COM servers. (Not that I tried it though).

--
Jugoslav
___________
www.geocities.com/jdujic

Please reply to the newsgroup.
You can find my real e-mail on my home page above.

Jeff D. Hamann

2004-06-30, 3:59 pm

Well you've given me some food for thought. I'll post this message to one of
the win32 groups, but I think the responses you've given me are adequate.
Calling exporting functions in a simple exe isn't a workable solution and
creating an out-of-process COM interface is *way* beyond the scope of the
task.

Thanks,
Jeff.

"Jugoslav Dujic" <jdujic@yahoo.com> wrote in message
news:2kfo2cF1ofm5U1@uni-berlin.de...
> Jeff D. Hamann wrote:
> | FORTRAN folks,
> |
> | I apologies in advanced for asking a seemingly non-FORTRAN question
here,
> | but this project is all FORTRAN and I figured this would be a good place
to
> | ask.
>
> Hmmm, you should really be better off in some win32 programming newsgroups
> (comp.os.ms-windows.programmer.win32 for example).
>
> | I've been looking at extending a large FORTRAN project so that
developers
> | can utilize functions and subroutines from outside the process (the
exe).
>
> For one, I knew it was possible to export functions from an .exe file,
> but it never appealed to me as worthwhile to try (and I haven't find
> the purpose in any case). (Out-of-process COM .exe servers are another
> story).
>
> | I've created a test project (an exe) and exported a couple of functions
and
> | have been successful in calling the exported subroutines from another
> | process like VBA in Access. When I attempt to assign a variables some
value
> | in the source code (when debugging) I get access violations. I thought
it
> | had something to do with the way I was calling the exported functions,
so
> | simply commented out my code to see if the previously existing code
would
> | work. Again, when the debugger got a line of code with an assignment op
> | (usually very early into a subroutine), I got an access violation.
>
> I really don't know how loading an .exe into context of another process
> works, but that doesn't surprise me much. What probably happened is that
> you passed an argument from another process by reference (address), but
> since every process has distinct address space, that address as received
> in another process is meaningless (i.e. points to something totally
different
> in the receiving process).
>
> | I created
> | a second project that didn't contain a "program main" and it worked fine
> | (created a genuine dll project). I'm assuming it has something to do
with
> | the fact that I'm calling code in an exe from another exe and the first
> | process has "secured" the memory so that the second "process" (now
loaded as
> | a DLL) cannot change values. Creating a DLL "version" isn't really
> | acceptable because most of the others in the project don't get the
concept
> | and I want the changes to the code in the repos to be as minimal as
> | possible.
>
> I'm affraid that it's about the only practical solution. As I mentioned,
there
> are
> "out-of-process COM servers" but they have totally different architecture
and
> can be quite complicated to learn and to implement in Fortran.
>
> But I don't see the problem with it. In effect, you have already created a
> dll which happens to have extension .exe and erroneously runs in its own
> process space.
>
> In addition, if you need some kind of data sharing between different
instances
> of Access+Dll processes, you can e.g. google for "ShareBufferWin32" by
Gary
> L. Scott.
>
> --
> Jugoslav
> ___________
> www.geocities.com/jdujic
>
> Please reply to the newsgroup.
> You can find my real e-mail on my home page above.
>

Jugoslav Dujic

2004-06-30, 3:59 pm

Jeff D. Hamann wrote:
| Well you've given me some food for thought. I'll post this message to one of
| the win32 groups, but I think the responses you've given me are adequate.
| Calling exporting functions in a simple exe isn't a workable solution and
| creating an out-of-process COM interface is *way* beyond the scope of the
| task.

Just FYI, I think "dllexporting" from an .exe was enabled primarily for
the purpose of enabling "plug-in" types of architectures (and was pretty
much outfashioned by introduction of COM techniques). In such set-ups,
the .exe can export its routines which can be called by "plug-in" dlls
written e.g. by some 3rd party. FWIW, I've never heard anyone trying
the same thing as you :-).

--
Jugoslav
___________
www.geocities.com/jdujic

Please reply to the newsgroup.
You can find my real e-mail on my home page above.

James Van Buskirk

2004-06-30, 3:59 pm

"Jugoslav Dujic" <jdujic@yahoo.com> wrote in message
news:2kfo2cF1ofm5U1@uni-berlin.de...

> I really don't know how loading an .exe into context of another process
> works, but that doesn't surprise me much. What probably happened is that
> you passed an argument from another process by reference (address), but
> since every process has distinct address space, that address as received
> in another process is meaningless (i.e. points to something totally
different
> in the receiving process).

One thing that strikes me about the O.P.'s problem is that CVF by default
keeps local variables in fixed locations rather than on the stack. It would
seem to me to be impossible for this to work, so compiling with the
/automatic or /recursive or even /reentrancy might be required. It might
also be a good thing to tell the compiler to use the *.dll form of the RTL.

--
write(*,*) transfer((/17.392111325966148d0,6.5794487871554595D-85, &
6.0134700243160014d-154/),(/'x'/)); end

Gerry Thomas

2004-07-03, 8:56 am

"Jeff D. Hamann" <jeff.hamann@forestinformatics.com> wrote in message
news:8-Wdnd9eFYvHCXzdRVn-vA@scnresearch.com...
> FORTRAN folks,
>
> I apologies in advanced for asking a seemingly non-FORTRAN question here,
> but this project is all FORTRAN and I figured this would be a good place
to
> ask.
>

No need for an apology, and you've come to the right place, just see how
you'll be ignored on win32 ng's, and undestanndably so.

> I've been looking at extending a large FORTRAN project so that developers
> can utilize functions and subroutines from outside the process (the exe).

So your clients are developers. Good.

> I've created a test project (an exe) and exported a couple of functions
and
> have been successful in calling the exported subroutines from another
> process like VBA in Access. When I attempt to assign a variables some
value
> in the source code (when debugging) I get access violations. I thought it
> had something to do with the way I was calling the exported functions, so
> simply commented out my code to see if the previously existing code would
> work. Again, when the debugger got a line of code with an assignment op
> (usually very early into a subroutine), I got an access violation. I
created
> a second project that didn't contain a "program main" and it worked fine
> (created a genuine dll project).

You neglect to account for the fact that Fortran has absolutely no error
handling capabilities and undoubtedlly errors are falling through the
cracks to VBA.

j3, the Fortran intelligencia, over and above the vacuus but insistently
verbous Stg (sic Schultz) Maine, who by all reports wears a bib for drools
and dribbles, don't acknowledge such fallibility, one reason why Fortran is
NEVER considered for fail-safe, safety-critical applications.

> I'm assuming it has something to do with
> the fact that I'm calling code in an exe from another exe and the first
> process has "secured" the memory so that the second "process" (now loaded
as
> a DLL) cannot change values.

> Creating a DLL "version" isn't really
> acceptable because most of the others in the project don't get the
concept
> and I want the changes to the code in the repos to be as minimal as
> possible.
>

Perhaps you underestimate 'others in the project' ? Why would they care
whether your library resides in an exe or dll with exports? It ought to be
transparent to the client, but you'd rather it otherwise?

> If that's the case, is it possible to call code in one exe from another
> using the DLL framework? And if so, how?
>

Sure it can be done, in several ways actually, but I'll describe the
simplest, although I sense that even at that it'll show you that the nature
of Windows demands deep insight which escapes 99% of Fortraners, that being
their loss.

CVF can produce 3 types of DLL's; classic, AX (in process), and
AX(out-of-process). Others have mentioned the latter and you appear to have
dismissed these options although I don't fully know why but it's my guess
that you were attempting to trivialize Windows which doesn't wash as I
recall having to explain to a self-styled CLF dolt just recently. Best to
stick with a classic CVF DLL with exports. Given that your clients are as
dumb as you believe them to be (although I strong reserve judgement), YOU
provide them with a type library that they can reference in their client
application, you've mention VBA. This will make it a piece of cake for them
to tap into your library.

You mention going to a win32 ng's, but just say Fortran there and you're
history. With certain justification, they figure you're an egghead whose
well pass its sell-by-date.

If you want to know how to concoct a tbl for a CVF DLL, let me know via
email as the usual audience of this ng are more narrowly committed to their
own obscurity and the portability of Fortran to hell and beyond.

--
You're Welcome,
Gerry T.
______
"Things are not what they seem; or, to be more accurate, they are not only
what they seem, but very much else besides." -- Aldous Huxley.

Jeff D. Hamann

2004-07-06, 8:59 pm

Gerry,

It's nice to hear other developers with your caliber exist.

Yes I did dismiss the other options regarding the DLL development (in-proc,
out-of-proc, etc.) because one of the criteria about the project and others
in the development group is that the code be platform independent such that
it runs on Windows and AIX and *nix.

Thank you for the great response.
Jeff.

"Gerry Thomas" <gfthomas@sympatico.ca> wrote in message
news:xcuFc.94899$Ax1.1331001@news20.bellglobal.com...
>
> "Jeff D. Hamann" <jeff.hamann@forestinformatics.com> wrote in message
> news:8-Wdnd9eFYvHCXzdRVn-vA@scnresearch.com...
here,[color=darkred]
> to
>
> No need for an apology, and you've come to the right place, just see how
> you'll be ignored on win32 ng's, and undestanndably so.
>
developers[color=darkred]
exe).[color=darkred]
>
> So your clients are developers. Good.
>
> and
> value
it[color=darkred]
so[color=darkred]
would[color=darkred]
> created
>
> You neglect to account for the fact that Fortran has absolutely no error
> handling capabilities and undoubtedlly errors are falling through the
> cracks to VBA.
>
> j3, the Fortran intelligencia, over and above the vacuus but insistently
> verbous Stg (sic Schultz) Maine, who by all reports wears a bib for drools
> and dribbles, don't acknowledge such fallibility, one reason why Fortran
is
> NEVER considered for fail-safe, safety-critical applications.
>
loaded[color=darkred]
> as
>
> concept
>
> Perhaps you underestimate 'others in the project' ? Why would they care
> whether your library resides in an exe or dll with exports? It ought to be
> transparent to the client, but you'd rather it otherwise?
>
>
> Sure it can be done, in several ways actually, but I'll describe the
> simplest, although I sense that even at that it'll show you that the
nature
> of Windows demands deep insight which escapes 99% of Fortraners, that
being
> their loss.
>
> CVF can produce 3 types of DLL's; classic, AX (in process), and
> AX(out-of-process). Others have mentioned the latter and you appear to
have
> dismissed these options although I don't fully know why but it's my guess
> that you were attempting to trivialize Windows which doesn't wash as I
> recall having to explain to a self-styled CLF dolt just recently. Best to
> stick with a classic CVF DLL with exports. Given that your clients are as
> dumb as you believe them to be (although I strong reserve judgement), YOU
> provide them with a type library that they can reference in their client
> application, you've mention VBA. This will make it a piece of cake for
them
> to tap into your library.
>
> You mention going to a win32 ng's, but just say Fortran there and you're
> history. With certain justification, they figure you're an egghead whose
> well pass its sell-by-date.
>
> If you want to know how to concoct a tbl for a CVF DLL, let me know via
> email as the usual audience of this ng are more narrowly committed to
their
> own obscurity and the portability of Fortran to hell and beyond.
>
> --
> You're Welcome,
> Gerry T.
> ______
> "Things are not what they seem; or, to be more accurate, they are not only
> what they seem, but very much else besides." -- Aldous Huxley.
>
>
>

Gerry Thomas

2004-07-06, 8:59 pm

Jeff,

Implicit in the tlb approach that I mentioned is that the 'exe' has no
visible interface. If it has, then it's even easier to use a technique
called journal record hooking (hooking being roughly a lower level of
subclassing) but I don't know how to do this on anything other than
Windows. It's quite straightforward even from VBA.

Good Luck,
Gerry T.

"Jeff D. Hamann" <jeff.hamann@forestinformatics.com> wrote in message
news:QtWdnWDIfOJ-jHbdRVn-hg@scnresearch.com...
> Gerry,
>
> It's nice to hear other developers with your caliber exist.
>
> Yes I did dismiss the other options regarding the DLL development
(in-proc,
> out-of-proc, etc.) because one of the criteria about the project and
others
> in the development group is that the code be platform independent such
that
> it runs on Windows and AIX and *nix.
>
> Thank you for the great response.
> Jeff.
>
> "Gerry Thomas" <gfthomas@sympatico.ca> wrote in message
> news:xcuFc.94899$Ax1.1331001@news20.bellglobal.com...
> here,
place[color=darkred]
how[color=darkred]
> developers
> exe).
functions[color=darkred]
thought[color=darkred]
> it
functions,[color=darkred]
> so
> would
op[color=darkred]
fine[color=darkred]
error[color=darkred]
insistently[color=darkred]
drools[color=darkred]
Fortran[color=darkred]
> is
first[color=darkred]
> loaded
be[color=darkred]
another[color=darkred]
> nature
> being
> have
guess[color=darkred]
to[color=darkred]
as[color=darkred]
YOU[color=darkred]
client[color=darkred]
> them
you're[color=darkred]
whose[color=darkred]
via[color=darkred]
> their
only[color=darkred]
>
>

Sponsored Links