Extract API from Fortan Program

[morethanair]

Hi, all.

I have a question how I can get API from Fortran main program.

If the Fortran side is only subroutine, We can make it a static library or DLL, right?

In case the Fortran has main program procedure, how can we extract the subroutines(API) to the external programs (It could be C or C++ program).

Any idea to extract this?

Thanks a lot

[ZlamalJakub]

I am using routines of my exe file in dlls called from exe. I do it in following.

Use DLLEXPORT attribute on routines of your program (exe) which you need to use

Link your dll (or application?) against *.lib of your exe.

call routines exported from exe.

Jakub

[morethanair]

Hi, Jakub.

Thank you for your reply.

Could you explain more about 'Link your dll (or application?) against *.lib of your exe.'

How can I link the routines in the Fortran(.exe) and other applications?

[ZlamalJakub]

I will try to prepare example for you. Let say tomorrow

Jakub

[Jugoslav_Dujic]

Hold on. Morethanair, do you have the Fortran source code?

If you don't, nothing can be done, because the compiling process is reversible -- you cannot make a cow out of hamburger; in general, it is not possible to call methods from a binary module which are not declared as "exported" when it was built.

If you do, then Quba's exercise is rather futile: it's a real cludge to build something as an exe but export the routines from it. Instead, you need to cut off and/or rewrite the interesting pieces of Fortran code, make a static or dynamic library from that, and write an appropriate C header file. But to be more helpful, you need to show us relevant code fragments.

[ZlamalJakub]

I am including code. See Readme.txt in EXEexportDirectory. Ater you build project you must copy EXEexport.exe an callexe.dll to CalcDllandEXE debug directory to be found.

You can also study

http://software.intel.com/en-us/forums/showthread.php?t=71865

to see how to call some exported routine using LoadLibrary etc.

Jakub

[morethanair]

I'll write some test code now. Of course, if it's already .exe, I can't get any subroutine from it.

Thank you so much.

[morethanair]

I will try with your sample codes. It is really helpful.

Thank you so much.

[ZlamalJakub]

Is this exe file created by you? If you will be able to find address of routine (little bit offhand) may be you will be able to call routine from given address, but i think better is to recompile exe and export routine you need.

Because I use exes created by my, I can export routines i need.

Jakub

[IanH]

I was rather surprised to see that the Win32 program loader allows this load-time "reverse" linking from a DLL back to an EXE.

What I don't understand is - if you have the source code (or even just the object code) then why do you need to do this "reverse" dynamic linking?

If the DLL code is that tightly bound to code in the executable, why is the code from the DLL not just statically linked to the code in the EXE? If the code in the exe acts like an API that is called by multple unknown client processes, then why not put the API code in a DLL of its own? If the DLL needs to call back to some unspecified code in the exe, then pass the address of the call-back routine to call as a argument to a procedure in the DLL.

While this "reverse" linking might work and perhaps could be used in desperation, I'd still be very nervous about using it as a general solution. I'm not familiar enough with Intel Fortran's implementation to comment on specifics, but for some languages/implementations I'd anticipate problems with runtime library start-up code and initialisation of any global/module/common variables if you used this approach. The original post mentions C or C++ code calling into this EXE that's pretending to be a DLL - better hope that the C/C++ code knows how to initialise the fortran run-time before it makes that call!

[Jugoslav_Dujic]

I'm with Ian too; that was sort of point of my first post, although I wasn't sure it was the original poster's intention. Although that's possible in theory (well, and practice), it's just not the way things are normally done, and I see such setup as a disaster waiting to happen.

Isn't it much simpler just to remove the PROGRAM, put DLLEXPORT to routines that you need, and recompile the reast as a DLL or static library? If you need the same or similar program as a shell to these routines, make an .exe from it and link it against those libraries. Good code structuring in the beginning leads to much less headaches later.

"Weeks of coding can save you hours of planning" :)

[morethanair]

I appreciate all answers.

I also thought DLL or static libraries are the better choice, but my boss wanted to test that way.

That's why I should find some weird way :)