Lazarus

Programming => General => Topic started by: GypsyPrince on November 16, 2020, 09:01:39 pm

Title: [SOLVED] FreePascal book covering only DLLs...
Post by: GypsyPrince on November 16, 2020, 09:01:39 pm
Has anyone considered writing a book which covers only the concept of creating and using DLLs in OP/FP?

I need to create a DLL which contains a class, which subsequently contains public properties, events, enums, records, functions, and procedures - all of which need to be exported to a client/linked application.
 
I just can't seem to find any examples to help guide me through creating such a monster in OP (it's easy to do in .NET).  Most examples I see of classes within DLLs just show exporting simple procedures, so they're not a lot of help.
 
I'm thinking there are so many implementations which could go into an object pascal DLL, it would require a very thick book to thoroughly explain them all.
 
I may just find someone to hire to write the DLL for me.
Title: Re: FreePascal book covering only DLLs...
Post by: trev on November 16, 2020, 11:08:01 pm
Has anyone considered writing a book which covers only the concept of creating and using DLLs in OP/FP?

A Wiki article might be a more achievable goal with ongoing multiple author contributions and accessibility being the main advantages.
Title: Re: FreePascal book covering only DLLs...
Post by: GypsyPrince on November 16, 2020, 11:54:23 pm
@trev

Quote
A Wiki article might be a more achievable goal with ongoing multiple author contributions and accessibility being the main advantages.

I believe you are quite correct on this. However, because we are dealing with DLLs, each article should be thorough, articulate (easy for newbies to understand), and cover real-world usage scenarios rather than returning a simple integer when the user clicks a button.

All examples for DLLs I've seen so far are very brief, especially those I've seen in wiki articles. I've tried using those examples to think my way through creating the DLL I actually need, but can't seem to make it work.
Title: Re: FreePascal book covering only DLLs...
Post by: winni on November 17, 2020, 12:19:33 am
Hi!

Why not start searching this forum???
Is it as complicated as your idea?

https://forum.lazarus.freepascal.org/index.php?topic=41794.0 (https://forum.lazarus.freepascal.org/index.php?topic=41794.0)

Winni
Title: Re: FreePascal book covering only DLLs...
Post by: GypsyPrince on November 17, 2020, 12:27:28 am
@winni

Quote
Is it as complicated as your idea?

I'm not really sure. I can't make any sense of what they're saying. LOL

My failure - not theirs.
Title: Re: FreePascal book covering only DLLs...
Post by: GetMem on November 17, 2020, 08:49:25 am
@GypsyPrince

You wish to create a dll in freepascal, then use it with another programming language? Or a pascal dll with another pascal application?
Title: Re: FreePascal book covering only DLLs...
Post by: PascalDragon on November 17, 2020, 09:10:30 am
I just can't seem to find any examples to help guide me through creating such a monster in OP (it's easy to do in .NET).  Most examples I see of classes within DLLs just show exporting simple procedures, so they're not a lot of help.

There is a reason for this: because that is the only ensured way that works (aside maybe COM on Windows). Providing access to classes from a library to a program or the other way round using Object Pascal means will lead to trouble sooner or later. You need to flatten such classes so that you're only working with ordinary functions and procedures.
This is the way.

The only feature that will improve this is dynamic packages, but then this will be restricted to Free Pascal code only, but you also don't need any manual for that, cause in most cases it's transparent for the user.
Title: Re: FreePascal book covering only DLLs...
Post by: cdbc on November 17, 2020, 10:46:56 pm
Hi
tomorrow i'll be on my other workstation, I've got an example there for you shows you exactly how it is done...
regards Benny
Title: Re: FreePascal book covering only DLLs...
Post by: BlueIcaro on November 18, 2020, 05:25:03 pm
Hello, for me will be interesting have in one place all information about dll/so.

I think there is two subjects about external dll/so.

One is how to make dll/so in free pascal that can be used in other languajes, for example Python.
Second, is how use external dll/so in free pascal. In this days there are many libraries write in C and in C++.

There a  few entries in wiki, but, IMHO  the information is not very complete. Where I had to deal with a C library I used to ask in forum. And now I looking how to deal with a C++ library, but I'm not sure how to start.

Also, I think is this information is more complete,and  the information is more at hand, we can give more visibility to Pascal. Because we can use more external libraries, and make libraries in pascal to other people who use other languaje.

I have a few notes, about the last C library that I use. You  can read about this here: https://forum.lazarus.freepascal.org/index.php/topic,51824.msg381298.html#msg381298 (https://forum.lazarus.freepascal.org/index.php/topic,51824.msg381298.html#msg381298)



/BlueIcaro
Title: Re: FreePascal book covering only DLLs...
Post by: trev on November 19, 2020, 07:22:15 am
Quote
There a  few entries in wiki, but, IMHO  the information is not very complete.

I wrote the following Wiki articles for macOS which I hope are complete:

* macOS Dynamic Libraries (https://wiki.freepascal.org/macOS_Dynamic_Libraries)
** Overview
** Library extensions and prefixes
** Example FPC dynamic library
** Example application to load FPC dynamic library
** Alternative example application to load FPC dynamic library
** Additional steps using a Lazarus project
** Example application to load libc dynamic library
** Observe the dynamic linker in action
** Standard locations for dynamic libraries
** See also

* macOS Static Libraries (https://wiki.freepascal.org/macOS_Static_Libraries)
** Overview
** Library extensions and prefixes
** Example FPC static library
** Example FPC application to use FPC static library
** Example C static library
** Example FPC application to use C static library
** See also

and updated:

* macOS Programming Tips - Libraries (https://wiki.freepascal.org/macOS_Programming_Tips#Libraries).
Title: Re: FreePascal book covering only DLLs...
Post by: PascalDragon on November 19, 2020, 09:14:00 am
And now I looking how to deal with a C++ library, but I'm not sure how to start.

You need to write a wrapper library (in C++) that flattens the C++ API to a C one.

Such things would be simpler if there'd finally be official support for FPC/Delphi in e.g. SWIG (http://www.swig.org/) (there have been various tries in the past, but none became official).


[Edited to fix link.]
Title: Re: FreePascal book covering only DLLs...
Post by: cdbc on November 19, 2020, 01:57:23 pm
Hi
As promised, here's an example for you  :)
Title: Re: FreePascal book covering only DLLs...
Post by: GypsyPrince on November 21, 2020, 07:58:59 pm
Hmm... so many wonderful replies. Thank you to all!!
 
Let me see if I can clarify my needs a little better while putting my lack of OP knowledge on display.

I can create simple DLLs easily enough, and which I can make work with my other languages (C, C++, VB.NET, etc.). For the type of DLL I'm thinking I need (perhaps mistakenly), however, it probably would be used in FreePascal/Lazarus only.
 
Here is why I said this part:
 
Quote
For the type of DLL I'm thinking I need (perhaps mistakenly),

Again, creating a DLL is easy enough. However, for programs written in some languages, if more than one program uses the same DLL, only one of those programs can be open at a time. Or rather, only one of those programs at a time can make a call to the shared DLL without creating a new instance of the DLL. Otherwise, a sharing violation error is raised.
 
Now, here is where my lack of experience in OP/FP shows:
1. If two or more programs share a DLL written in OP/FP, does each program need to create a new instance of that library using a variable (object variable?) when calling it in order to avoid a sharing violation (as is required in some other languages) if two of those programs are open at once? Or, can each program make a direct call to (load) the DLL without the need to create a new instance of it and not risk an error?
 
2.Given the info in question #1... does an OP program automatically create a new instance of the DLL when loading it? Or, would each program try to share the same instance of the shared DLL if each does not specifically create a new instance. I honestly don't know with OP/FP.
 
3. If the answer to #1 & #2 is that each program must create a new instance of the shared DLL, does doing so require that a class (or classes) be used within the DLL because one would actually be creating a new instance of the class rather than the DLL?
 
This is the source of my quandry. It is the case in some other languages that one or more classes be implemented within the DLL in order to create a new instance of the class(es), thus avoiding a sharing error when two or more programs which share a DLL are open and attempting to load the DLL at the same time.

I have about 3 DLLs that I use in all of my programs. Each DLL contains methods, records/enums, properties, and events which need to be accessed or made available to every program I write. Regarding the events... when an event is raised within the DLL, the program is notified via a "With Events" notation in the DLL's variable declaration. The program then decides how to handle the event (rather than the DLL itself) according to the info/data passed when the event within the DLL gets raised.
 
Does this clarify a bit more what I'm trying to acheive?
Title: Re: FreePascal book covering only DLLs...
Post by: PascalDragon on November 21, 2020, 09:06:27 pm
Again, creating a DLL is easy enough. However, for programs written in some languages, if more than one program uses the same DLL, only one of those programs can be open at a time. Or rather, only one of those programs at a time can make a call to the shared DLL without creating a new instance of the DLL. Otherwise, a sharing violation error is raised.

What are you talking about? Libraries are handled by the operating system and it's the explicit idea behind libraries that they can be used by multiple programs at once (even if it's only multiple instances of the same application). There is no sharing violation with libraries if used as they're supposed to be used.
 
Now, here is where my lack of experience in OP/FP shows:
1. If two or more programs share a DLL written in OP/FP, does each program need to create a new instance of that library using a variable (object variable?) when calling it in order to avoid a sharing violation (as is required in some other languages) if two of those programs are open at once? Or, can each program make a direct call to (load) the DLL without the need to create a new instance of it and not risk an error?

If you load a library dynamically you do a LoadLibrary and then the operating system ensures that your program instance has its own private “instance” of that library (even if e.g. the code or read only data sections might be shared between these multiple instances). After that you retrieve your function pointers using GetProcAddress and call them as you see fit. It's all transparently handled by the OS.
 
2.Given the info in question #1... does an OP program automatically create a new instance of the DLL when loading it? Or, would each program try to share the same instance of the shared DLL if each does not specifically create a new instance. I honestly don't know with OP/FP.

Again, that's part of the operating system. And while e.g. Windows 3.11 allowed sharing of e.g. data between libraries this is no longer the case in newer Windows versions, thus each instance of the application will get its own instance of the library even if behind the scenes the OS might share some sections to preserve memory.
 
3. If the answer to #1 & #2 is that each program must create a new instance of the shared DLL, does doing so require that a class (or classes) be used within the DLL because one would actually be creating a new instance of the class rather than the DLL?

I don't understand the question.
 
I have about 3 DLLs that I use in all of my programs. Each DLL contains methods, records/enums, properties, and events which need to be accessed or made available to every program I write. Regarding the events... when an event is raised within the DLL, the program is notified via a "With Events" notation in the DLL's variable declaration. The program then decides how to handle the event (rather than the DLL itself) according to the info/data passed when the event within the DLL gets raised.

As explained above libraries are for sharing binary code. Each running program automatically gets its own “instance” of the library when loaded. Sharing of data state between applications needs to happen explicitely (e.g. by using memory mappings and such, but these techniques depend on the operating system).
 
Does this clarify a bit more what I'm trying to acheive?

Honestly? It does not.
Title: Re: FreePascal book covering only DLLs...
Post by: GypsyPrince on November 21, 2020, 10:15:29 pm
@PascalDragon

In both .NET and Java, when you create an object from (link to or load) a DLL written in one of those managed languages, you are actually creating a new instance of a class within the DLL, rather than creating an instance of the DLL itself. Why? Because in such cases it is handled by the managed platform (.NET/Java) rather than by the OS. In reality, though, it is the managed platform by which the program communicates with the operating system, which subsequently handles the library. However, when writing a .NET/Java application which loads a DLL created in some other language such as a C/C++ based DLL, then you do create an instance of the actual DLL itself, because there is no managed platform acting as a virtual machine liason between the program and the operating system. Therefore, the library is handled immediatley by the OS without a managed platform/virtual machine (and classes) acting as an intermediary.
 
What I just explained to you above is the entire basis for my query. Since I am not as deeply familiar with Pascal as I am with Assembly, C, C++, and .NET, I did not know whether a Pascal program communicates with a library via the operating system, or via a managed platform.
 
This is basically the answer I needed to know:

Quote
If you load a library dynamically you do a LoadLibrary and then the operating system ensures that your program instance has its own private “instance” of that library (even if e.g. the code or read only data sections might be shared between these multiple instances). After that you retrieve your function pointers using GetProcAddress and call them as you see fit. It's all transparently handled by the OS.

This tells me the OS handles a program's communication with libraries rather than it being handled by a managed platform, and that I have no need of dealing with classes in my DLL.
 
So... armed with this specific info, I already know how to create the particular DLL that I need.
Title: Re: FreePascal book covering only DLLs...
Post by: GypsyPrince on November 21, 2020, 11:30:54 pm
Out of the numerous Pascal affilated books I've purchased here in the last month,  'Sam's Teach Yourself Borland Delphi 4' and the 'Borland Delphi 6 Developer's Guide' used together seem to offer the broadest and most thorough, yet most down-to-earth laymen explanation on DLLs in OP.

https://www.amazon.com/Sams-Teach-Yourself-Delphi-Days/dp/0672312867 (https://www.amazon.com/Sams-Teach-Yourself-Delphi-Days/dp/0672312867)

https://www.amazon.com/Delphi-Developers-Guide-Sams-Guides/dp/0672321157/ref=sr_1_3?dchild=1&keywords=Delphi+Developer%27s+guide&qid=1605997766&sr=8-3 (https://www.amazon.com/Delphi-Developers-Guide-Sams-Guides/dp/0672321157/ref=sr_1_3?dchild=1&keywords=Delphi+Developer%27s+guide&qid=1605997766&sr=8-3)
Title: Re: FreePascal book covering only DLLs...
Post by: PascalDragon on November 22, 2020, 12:57:22 pm
In both .NET and Java, when you create an object from (link to or load) a DLL written in one of those managed languages, you are actually creating a new instance of a class within the DLL, rather than creating an instance of the DLL itself. Why? Because in such cases it is handled by the managed platform (.NET/Java) rather than by the OS. In reality, though, it is the managed platform by which the program communicates with the operating system, which subsequently handles the library. However, when writing a .NET/Java application which loads a DLL created in some other language such as a C/C++ based DLL, then you do create an instance of the actual DLL itself, because there is no managed platform acting as a virtual machine liason between the program and the operating system. Therefore, the library is handled immediatley by the OS without a managed platform/virtual machine (and classes) acting as an intermediary.

You are mixing loading of the library and the data state here. First of Java does not know libraries (at least not in this sense) and if it uses precompiled libraries though JNI or such it uses the same mechanisms as any C or Pascal program would. And for .NET libraries the same holds true as for a library written in C or Pascal: if the program loads a library the operating system maps the library into the applications virtual memory and then it can call there as it sees fit. No data state is shared between different “instances” by default (while the code is shared).

So assume you have the following code:

Code: Pascal  [Select][+][-]
  1. library Test;
  2.  
  3. {$mode objfpc}
  4.  
  5. var
  6.   i: LongInt = 0;
  7.  
  8. function GetValue: LongInt; stdcall;
  9. begin
  10.   if i = 0 then begin
  11.     Randomize;
  12.     i := Random(High(LongInt) - 1) + 1;
  13.   end;
  14.   Result := i;
  15. end;
  16.  
  17. exports
  18.   GetValue;
  19.  
  20. begin
  21. end.

Then you'll get a different number when calling GetValue for each run of the program no matter if your program is written in Java, C#, Free Pascal or whatever.

Also an important point that I had already mentioned earlier: You do not pass classes or other Pascal types like AnsiString or such across library boundaries. This will only lead to problems rather sooner than later. The only safe ones are primitive types, records, pointers (though these need to be freed by whoever allocated them or you need to pass the memory manager along as well) and interfaces (especially the COM ones where designed for this). On Windows you can also pass WideString, because it uses operating system functionality.

Passing classes and such around will only work once dynamic packages are supported, but these are not ready for prime time yet.
Title: Re: [SOLVED] FreePascal book covering only DLLs...
Post by: GypsyPrince on November 22, 2020, 06:34:45 pm
Okay, this is getting way out of range from what I'm talking about and doesn't reflect what I'm saying. From the beginning there seems to be a complete misinterpretation or a loss in translation, so I'm just going to say here that I got the information I needed and finished my DLL - it works perfectly.
 
All is good.


@cdbc
Thank you for grasping what I was asking! Your examples were invaluable!!!
Title: Re: [SOLVED] FreePascal book covering only DLLs...
Post by: cdbc on November 23, 2020, 03:33:39 pm
No worries mate, I'm glad you got it to work  :)
Regards Benny
Title: Re: [SOLVED] FreePascal book covering only DLLs...
Post by: PascalDragon on November 23, 2020, 04:33:25 pm
Okay, this is getting way out of range from what I'm talking about and doesn't reflect what I'm saying. From the beginning there seems to be a complete misinterpretation or a loss in translation, so I'm just going to say here that I got the information I needed and finished my DLL - it works perfectly.

It's getting out of hand, because you either have a wrong concept of how libraries work or because there's a language barrier in the way.
Title: Re: [SOLVED] FreePascal book covering only DLLs...
Post by: GypsyPrince on November 23, 2020, 06:41:59 pm
Quote
It's getting out of hand, because you either have a wrong concept of how libraries work

I have a very good concept of how libraries work, as I've been programming in various languages since 1984. cdbc knew exactly was I was asking and provided the material I needed, so I can only assume that the issue must be a language barrier.
TinyPortal © 2005-2018