Delayed binding of DLL's with SLINK

In 'FTN95: Fortran 95 for Windows - Features' I have found the information, that it is possible to have a delayed binding of DLL's. SLINK should have an option which delays the binding of DLL's until they are actually used.

This feature would be very helpfull for my application.

But I cant't find any information about this option neither in the manual nor in the FTN95 help.

How can I use this feature?

Detlef

If the website refers to delayed binding then I am not sure that this is the correct terminology.

If you compile with FTN95 and link with SLINK then a missing routine will be reported at link time but this will not be a fatal error (at least not by default). You will still be able to run the exe or use the dll. At runtime a failure will occur only when the missing routine is called. If the routine is in a dll then the call could be made conditional upon the dll being accessible.

Hi Paul,

normally one would you use the LOAD xxx.DLL in the link list. But in this case the DLL must exist when launching the executable file.

In my application I want to make calls to the DLL's functions or subroutines only if this DLL is available. So I have omitted the LOAD xxx.DLL line in the link list.

Now I can launch the executable file although the DLL doesn't exist.

But if the DLL exist I can't call any functions or subroutines of the DLL.

How can I manage to call the DLL's functions or subroutines?

Do I have to use LoadLibrary and all the other stuff like GetProcAddress, or is there any easier way to get access to the DLL?

Detlef

Hi Paul,

I have just found a description of delayed DLL loading for C++:

http://msdn.microsoft.com/en-gb/library/151kt790%28v=VS.80%29.aspx

This is the way I want to do it with FTN95 and SLINK.

Detlef

normally one would you use the LOAD xxx.DLL in the link list. But in this case the DLL must exist when launching the executable file.

Are you sure this is the case? I have not tried this but the SLINK load command is needed at link time in order to provide a stub for the routine. It does not mean that the dll is to be loaded when the executable is started (or rather I did not think so).

Try a simple test to see how it works out.

Until now we are using the LOAD xxx.DLL line. If we are launching our application and the DLL is missing we will get before start-up of the application a system error message that xxx.DLL is missing on the computer.

Detlef

I think you are not understanding what I am saying. You certainly need the dll at link time. Question is, does it need to be accessible at run time?

If the dll is not available at link time (i.e. when running SLINK) then I guess that you will need something like GetProcAddress. You will find this in win32api.ins but it would take me a while to work out how to use it in Fortran. Normal usage is in C/C++.

Of cause the DLL is available for building our application. But not all of our customers have this DLL. In this case they should be able to start our application. If they would try to use some features of our application, which will need this DLL, the customer should get a message that he isn't allowed to use this feature.

But at present the customer would not be able to launch the application without the DLL.

OK I have now tried this out and can confirm that the dll needs to be present.

How about creating a dummy dll with the same name. It could even have the same routines interfaces but returning without doing anything.

I am not sure that you will need the same interfaces but it appears that you do need a valid dll header to the dll file.

I will think about this further and see if there is an standard way to do this.

OK. If I create a dll from the code

subroutine tester(x)
real x
x = 2.0*x
end

and a program from

program one
integer i
real x
x = 2.0
read*, i
if(i==1) call tester1(x)
print*,x  
end

then I can link and run and I only get a failure at runtime when i == 1. So the dummy dll only needs to contain one dummy routine that does anything you like. You could even use it to report whether this was the real dll or the dummy!

Hi Paul,

this is the way, we have done actually in our application. For those customers, who did not own the original DLL, we have built a dummy DLL.

But we don't want to work with this dummy DLL furthermore!!!

Did you really read the microsoft article I have mentioned above?

This is the way we want to work! And if I read the description of FTN95 on your website it sounds as SLINK would have such an option (like linkers of other manufacturers).

Detlef

I have had a look at SLINK and I cannot find an option that allows the exe to run without the dll. I have also started to look at the code for SLINK to find out how the exe is built with the view to modifying it to make it work the way you want. I am still working on this.

Can you confirm that your code is written in Fortran. GetProcAddress uses function pointers which may be impossible to implement in FTN95.

Hi Paul,

our code is written in Fortran (just as your small example). We don't use LoadLibrary and GetProcAddress. We just call functions or subroutines of the DLL.

Detlef

GetProcAddress uses function pointers which may be impossible to implement in FTN95.

This may work using a C layer though (SCC), but this would add one wrapper-function per function in the DLL that may be called.

I have checked this out as best I can for now and my only suggestion is to have a dummy dll with the same name and just one routine in it.

Other options require a wrapper of one kind or another and would be very cumbersome.

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

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.

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.

Hi Paul,

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

Thanks

Detlef

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