forums.silverfrost.com

[dpannhorst]

Hi Paul,

thanks for your answers!

Nevertheless you should try to implement this feature to the next FTN version.

As you can see, other compilers do support delayed binding of DLL's, and also your website is promising something like that.

Our management requires this feature for our application and maybe they will force us to change to another compiler (that really means: goodby Silverfrost).

Detlef

[PaulLaidler]

If by "delayed binding" we mean the equivalent of LoadLibrary/GetProcAddress then FTN95 does not provide this in a direct way. I will pass this to the website manager for clarification.

You can call both LoadLibrary and GetProcAddress from FTN95 and the result will be an integer which is a function pointer. It would be interesting to see what would happen if you passed this integer to a subprogram that is expecting a function as an argument. Given some work-around of this kind, you would need to provide such a wrapper for every call to the dll.

If you do find an alternative Fortran compiler that solves the problem in a more direct way then I would be interested to see what the syntax looks like.

[PaulLaidler]

Most of what I have written on this subject can now be ignored because I have been advised that there is a SLINK command for this purpose.

Create the DLL with the usual SLINK commands.

When creating the executable, use rlo instead of lo (or load) in order to load the dll. You can do this from a SLINK script. I have not tried it from the command line.

The result is that the dll does not need to be present when the executable is loaded at runtime.

In your code you will need to test if the dll is present before allowing a call to the dll. Otherwise if it is not present then an exception will be raised because of the missing routine.

[dpannhorst]

Hi Paul,

it is working fine! We will add a check if the DLL is present.

Thanks

Detlef

[PaulLaidler]

I should add that a call to LoadLibrary is probably the best way to test if a DLL is accessible.