Re: exporting functions/subs from fortran?

• Previous message: Richard Maine: "Re: Control host association"
• In reply to: Jeff D. Hamann: "Re: exporting functions/subs from fortran?"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Date: Tue, 6 Jul 2004 19:01:26 -0400

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...
> >
> > "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.
> >
> >
> >
>
>

• Previous message: Richard Maine: "Re: Control host association"
• In reply to: Jeff D. Hamann: "Re: exporting functions/subs from fortran?"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]