Import External DLL published function () into FTN95 .f95

Dear Paul

Greetings I have a question, perhaps, very fundamental, hence I am asking here for quick help. I have just searched in our FTN95 forum, but not able to spot of this kind of question's discussion.

I want to import the externally available DLL reference into my .f95 code. In this, I want to create (or instantiate) an object referring to the DLL (exported function object) in .f95 code and then use the published function out of the DLL through the instantiate object handle in .f95.

Let me give an example here.

Assume the external DLL is MyComponent.dll and it has a function SquareIt()

Its code looks like this, it a activex DLL developed in VB, called Mycomponent.dll

Option Explicit 

      Public Function SquareIt(lngNumber As Long) 
         SquareIt = lngNumber ^ 2 
      End Function

So this function is developed in project 'MyComponent' and class module name is MyClass. So, the MyClass has this function SquareIt() as above.

Now, let me show the Main program code, which import the reference to MyComponent.dll

Public Sub ma() 

      'begin procedure 

      'create a object reference to the component 
      Dim obj As MyComponent.MyClass 
      Dim lngArgument As Long 
      Dim lngResult As Long 

      'create an instance of the object 
      Set obj = New MyClass 
      lngArgument = 2 

      'call the objects SquareIt method 
      lngResult = obj.SquareIt(lngArgument) 

      MsgBox 'The Square of ' & lngArgument & _ 
             ' is ' & lngResult 

      'end procedure 
    
End Sub 

For explanation, I use the VB6 code here as above. If you notice the codelines in the above code, An object 'obj' is created from MyComponent.MyClass, then the object instance is created using 'Set obj..', which allocates the memory instance as well here. Further, the SquareIt is called as given in the next line

 lngResult = obj.SquareIt(lngArgument)

The covenience to the programmer is that when i type 'obj.' then the published functions will be displayed in our IDE editor, which is one important.

How to do this in our FTN95, by importing the external DLL references. Could you please let me know how this is done in V8.10. And also, if there are, our study reference in FTN95.chm, or PDF, pls. let me know.

You talk in terms of objects, instantiation, etc. I will skirt around that terminology and show how to create a Fortran DLL function and how to use that function.

The source for the DLL:

function squareit(L)
implicit none
integer L,squareit
squareit=L*L
return
end function

We build the DLL as follows:

ftn95 squareit.f90
slink /dll squareit.obj /export:SQUAREIT

The source code for the caller of the DLL:

program getsquare
implicit none
integer x,xsq,squareit
!
x=7
xsq=squareit(x)
print *,'square of ',x,' is = ',xsq
end program

Building the EXE:

ftn95 gsq.f90
slink gsq.obj squareit.dll

The output from the EXE:

 square of            7 is =           49

Thanks a lot mecej4. Let me try this.

By the way, to All, please mark this post of mecej4 as an example of ideal way of explaining things in these groups and even in general. Genial simplicity.

I agree Dan, thanks mecej4 for the example. I will be taking this and experimenting with what I can use a .dll for. Can the 64-bit version be provided, although it appears slink64 may have some useful updates in the next version.

I remember when Pr1me provided dynamic link libraries, which were sold as a way of changing the .exe with upgraded .dll files. As I had (and have now) access to the full build based on .obj and .lib static libraries, I don't appear to required the .dll capabilities.

There is also the problem of accessing modules (and possibly common) in a .dll. This may just be a misunderstanding of the restrictions. Is there any authoritative discussion of this in FTN95.chm or elsewhere ?

I also observe a slight performance penalty with using .dll system libraries, although that may be confused by the longer initial startup delay with larger static .exe build files.

Quoted from JohnCampbell Can the 64-bit version be provided, although it appears slink64 may have some useful updates in the next version.

ftn95 squareit.f90 /64
slink64 squareit.obj /file:squareit.dll
ftn95 gsq.f90 /64
slink64 gsq.obj squareit.dll /file:gsq

I get the impression that slink64 does not require and does not understand EXPORT directives, but it does export the function/subroutine name.

There is also the problem of accessing modules (and possibly common) in a .dll. This may just be a misunderstanding of the restrictions. Is there any authoritative discussion of this in FTN95.chm or elsewhere ?

Here is where things get complicated. Using shared modules and global data can violate thread safety, and support from the OS is needed to get things to work correctly and safely. It is best to stick to sharing data through argument lists. Even with simple entities such as file unit numbers, if the DLL and the EXE write to the same unit, one of them may complain that the file is not open or the output may not be in logical sequence.

I was forced to use a DLL for a 'C' library that could not be compiled using SCC. It is used a lot when I run one particular program, but the performance penalty does not appear to be too great.

This might be different when/if more DLL-based routines are run (compute intensive), but really, the interface is pretty clean for the DLL interface.

Thanks mecej4 on /64

Using shared modules and global data can violate thread safety, and support from the OS is needed to get things to work correctly and safely. It is best to stick to sharing data through argument lists. Even with simple entities such as file unit numbers, if the DLL and the EXE write to the same unit

I agree with you. I am facing the problem, when I try use the same modules which consist of public function, while attempting to make use of the same data between DLL and EXE.Thats where I face this issue of what you said. If I keep the MOD as part of DLL and USE MOD in EXE, but compilation fails for EXE as the MOD code is missing. Is there any better way to handle this to avoid this compilation error?

Alternatively, the solution to this would be to share by addresses passing, and use the same address location for read/write transactions.But, I agree that this option should handled with extra care as part of program logical flows.

Here is one more bit info, forgot to mention earlier.

I am facing the problem, when I try use the same modules which consist of public function, while attempting to make use of the same data between DLL and EXE.Thats where I face this issue of what you said. If I keep the MOD as part of DLL and USE MOD in EXE, but compilation fails for EXE as the MOD code is missing. Is there any better way to handle this to avoid this compilation error?

This error happens, even after the /MOD_PATH <MOD file> is defined for the EXE project compilation and building EXE file..