Re: exporting functions/subs from fortran?
From: Jeff D. Hamann (jeff.hamann_at_forestinformatics.com)
Date: 07/06/04
- Next message: glen herrmannsfeldt: "Re: stack overflow with reshape and transpose"
- Previous message: Bazip: "Re: What is Gerry Thomas's Contribution to NG's"
- In reply to: Gerry Thomas: "Re: exporting functions/subs from fortran?"
- Next in thread: Gerry Thomas: "Re: exporting functions/subs from fortran?"
- Reply: Gerry Thomas: "Re: exporting functions/subs from fortran?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Tue, 6 Jul 2004 13:55:52 -0700
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...
> > 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.
>
>
>
- Next message: glen herrmannsfeldt: "Re: stack overflow with reshape and transpose"
- Previous message: Bazip: "Re: What is Gerry Thomas's Contribution to NG's"
- In reply to: Gerry Thomas: "Re: exporting functions/subs from fortran?"
- Next in thread: Gerry Thomas: "Re: exporting functions/subs from fortran?"
- Reply: Gerry Thomas: "Re: exporting functions/subs from fortran?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
