forums.silverfrost.com

[stenlou]

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?

[davidb]

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".
_________________
Programmer in: Fortran 77/95/2003/2008, C, C++ (& OpenMP), java, Python, Perl

[stenlou]

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

[PaulLaidler]

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.

[davidb]

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.
_________________
Programmer in: Fortran 77/95/2003/2008, C, C++ (& OpenMP), java, Python, Perl

[stenlou]

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

[PaulLaidler]

[stenlou]

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

[stenlou]

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

[mecej4]

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.

[JohnCampbell]

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

[mecej4]

[stenlou]

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

[mecej4]

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:

[JohnCampbell]

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