DLL

Can someone give me a quick guide how to create a DLL.

As far as I can see, it cannot be done from Plato.

It look I have to be in command line mode (how do I get there?)

What else do I need to do?

You can create a DLL project from the New Project dialog in Plato. Alternatively click Project menu, then Set Target ... and pick DLL.

If you want the command line, shift and right-click with the mouse, then pick 'Open command window here'.

David

I am still a bit lost.

What I want to do is to have a 'main' program that 'calls' a DLL. In other word, I would like the DLL to be co0mpiled as a 'standalone' file that I can change as I like nd then just replace in a folder whenever I need.

I may have got it all wrong but from you message it looks like I have to save the project as a Dll and that is not what I want.

Please lift me up to the DLL level!

Sten

In essence you need two projects. One for the main program and one for the dll. Plato allows you to form two projects and to combine them into a 'Solution', but it may be simpler if you just keep them separate.

The help file ftn95.chm has full details.

As Paul says, create two projects, (1) the DLL Project, and (2) the Program project.

It is best to try this out on the simplest DLL Project and Program Project you can imagine. For example, create a DLL with one subroutine that is exported that just adds up to arguments and returns the result in a third argument (that is it implements C = A + B). Then create a Program to call this DLL and test it works.

Don't try to create the DLL you really want first off. There is a learning curve to go up and it helps to keep things simple at first. If you just dive in with a more difficult example it is unlikely to work first time IMHO.

David/Paul

I have a 'main' program' where I 'call' an integer function. This integer function I want to place in a DLL.

However, I cannot make a DLL out of my integer function but I can obviously make my integer function into a main but how do I then 'attach' this additional main to my primary Main?

Lets say that I call my DLL: Program X

in X I calculate a variable Data_y

In the main program do I then make a Call X

in in both the Dll and in the main program have a data module where data_y is defined?

Sten

program main
integer k
integer,external::func
k = func(4)
print*, k
end

integer function func(i)
integer i
func = i*i
end

func can go in a DLL if you prefer.

you confused me by first letting me know that a DLL had to be a main. Will try for suggestion!

actually

Still confused.

I made my function into a main, saved it as a target (=DLL).

Put it in under refrences in my original main but not sure how I actually gets the varianble calculated in the DLL?

Sten

Stenlou: There is no need to make things complicated and add to the confusion, so here is a brief recipe, to be used with discretion at the FTN95 command line.

1. Build the DLL containing the function. 1a. Compile the source code for the function.

   ftn95 isqr.f90

1b. Build the DLL using the linker. Note the symbol being exported.

slink /DLL isqr.obj /export:ISQR

Here are the contents of isqr.f90:

integer function isqr(i)
integer i
isqr=i*i
return
end function

2. Build the client program that will be linked to the DLL. 2a. Compile the source code.

   ftn95 risqr.f90

2b. Build the EXE using the linker

slink risqr.obj isqr.dll

Here are the contents of risqr.f90

program useisqr
integer i,j
i=5
j=isqr(i)
print *,i,j
end program

mecej4,

Thanks for the example, I shall give it a try. It's been a very long time since I created a dynamic link library (not since Pr1mos !), as I have found static libraries created by SLINK to be suitable.

The .dll does give more flexibility when testing. Potentially could I have two different versions of a .dll to test different approaches, as long as the routine interfaces do not change ?

In the example, there is no reference to isqr.lib. Is such a file not required with SLINK ?

Also, to clear up other confusion, is there any restrictions on using modules or common in a .dll ?

John

Quoted from JohnCampbell The .dll does give more flexibility when testing. Potentially could I have two different versions of a .dll to test different approaches, as long as the routine interfaces do not change ?

That, precisely, is one reason to use DLLs.

In the example, there is no reference to isqr.lib. Is such a file not required with SLINK ?

Unlike other linkers, SLINK is able to link directly with DLLs, and has no need for import libraries in most cases.

Also, to clear up other confusion, is there any restrictions on using modules or common in a .dll ?

Good question. Sharing data between a DLL and a client program is a bit more complicated than sharing routines, and I have no experience writing code that uses shared data with FTN95. Probably worth studying, although some people would argue that a well-designed interface should make global variables unnecessary, and some large libraries such as IMSL and NAG have few routines that consume shared data.

Gents

Got it to work, Thanks

Also for you info, I 'linked' the Dll with the same data Module as one of the data module I have in my main program and things work just like having the function within the main program (as it should).

I actually first tried this with Slink but then tested it in Plato using set target and that works as well. I think this is easier than using the Slink. Matter of taste, I assume.

Sten

Glad to hear that you got it working. However, I don't think the module data is properly shared. There will be two private copies of the data, one in the EXE and one in the DLL. Changing some or all of those module data variables in the EXE will not result in those values being used in the DLL. Here is a modification of the example that I gave above to alert you to this issue.

The module with the data intended to be shared, mymod.f90:

module mymod
implicit none
integer :: xyz
end module

The source of the function to put into the DLL, isqr.f90:

integer function isqr(i)
use mymod, only : xyz
integer i
isqr=i*i
xyz=+1000
return
end function

The source of the main program that calls the DLL, risqr.f90:

program useisqr
use mymod, only : xyz
integer i,j
i=5
xyz=-2000
j=isqr(i)
print *,i,j,xyz
end program

Building the EXE and DLL as before, but after compiling the module and including mymod.obj in the two invocations of SLINK, and running the EXE produces the output:

            5          25       -2000

You can see that changing the value of xyz in the DLL had no effect on the value of xyz in the EXE.

Thanks for the info. I shall test out what I can do with a module in a DLL. I am expecting that if the module is used only within the DLL, then this module information should be consistent between the routines in the DLL. I have a number of static libraries which previously used common. I have converted them to use modules and now provide routine interfaces for my program to access the data in the module. I think this change will be sufficient, as the same module data should be available to all the routines in the same DLL. This has tidied up the use of these libraries, as previously I included the common in the main program and initialised the common variables in the program. There is/was a question about the scope of the common or module and if the data could be considered static if not declared in the main program. I'm not sure what the standard says about this. It was significant when using an overlay linker. Fortunately, those days are past. I doubt if any modern linkers would make the modules dynamic and loose the information when out of scope, although I don't know for sure.

John

Will check the module issue a little bit. However, the primary use of the DLL would be for parts that rarely would change and therefore the module data would also not change.

Sten