Recent

Author Topic: [SOLVED] FreePascal book covering only DLLs...  (Read 2234 times)

GypsyPrince

  • New Member
  • *
  • Posts: 31
[SOLVED] FreePascal book covering only DLLs...
« 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.
« Last Edit: November 22, 2020, 06:29:02 pm by GypsyPrince »

trev

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 1071
  • Former Delphi 1-7, 10.2 User
Re: FreePascal book covering only DLLs...
« Reply #1 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.
o Lazarus v2.1.0 r63871, FPC v3.3.1 r47164, macOS 10.14.6, Xcode 11.3.1
o Lazarus v2.1.0 r64160, FPC v3.3.1 Nov 27 21:16:31, macOS 11.0.1 (aarch64), Xcode 12.2
o Lazarus v2.1.0 r61574, FPC v3.3.1 r42318, FreeBSD 12.1 amd64 (VMware VM)
o Lazarus v2.1.0 r61574, FPC v3.0.4, Ubuntu 20.04 (PD VM)

GypsyPrince

  • New Member
  • *
  • Posts: 31
Re: FreePascal book covering only DLLs...
« Reply #2 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.

winni

  • Hero Member
  • *****
  • Posts: 2009
Re: FreePascal book covering only DLLs...
« Reply #3 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

Winni

GypsyPrince

  • New Member
  • *
  • Posts: 31
Re: FreePascal book covering only DLLs...
« Reply #4 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.

GetMem

  • Hero Member
  • *****
  • Posts: 3783
Re: FreePascal book covering only DLLs...
« Reply #5 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?

PascalDragon

  • Hero Member
  • *****
  • Posts: 2429
  • Compiler Developer
Re: FreePascal book covering only DLLs...
« Reply #6 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.

cdbc

  • Sr. Member
  • ****
  • Posts: 274
    • http://www.cdbc.dk
Re: FreePascal book covering only DLLs...
« Reply #7 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
If it ain't broke, don't fix it ;)

BlueIcaro

  • Hero Member
  • *****
  • Posts: 621
Re: FreePascal book covering only DLLs...
« Reply #8 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



/BlueIcaro
Remenber, the lazarus wiki is your friend: http://wiki.lazarus.freepascal.org/Main_Page
General questions (several lenguages) http://wiki.lazarus.freepascal.org/

trev

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 1071
  • Former Delphi 1-7, 10.2 User
Re: FreePascal book covering only DLLs...
« Reply #9 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
** 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
** 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.
o Lazarus v2.1.0 r63871, FPC v3.3.1 r47164, macOS 10.14.6, Xcode 11.3.1
o Lazarus v2.1.0 r64160, FPC v3.3.1 Nov 27 21:16:31, macOS 11.0.1 (aarch64), Xcode 12.2
o Lazarus v2.1.0 r61574, FPC v3.3.1 r42318, FreeBSD 12.1 amd64 (VMware VM)
o Lazarus v2.1.0 r61574, FPC v3.0.4, Ubuntu 20.04 (PD VM)

PascalDragon

  • Hero Member
  • *****
  • Posts: 2429
  • Compiler Developer
Re: FreePascal book covering only DLLs...
« Reply #10 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 (there have been various tries in the past, but none became official).


[Edited to fix link.]
« Last Edit: November 19, 2020, 09:36:20 am by trev »

cdbc

  • Sr. Member
  • ****
  • Posts: 274
    • http://www.cdbc.dk
Re: FreePascal book covering only DLLs...
« Reply #11 on: November 19, 2020, 01:57:23 pm »
Hi
As promised, here's an example for you  :)
If it ain't broke, don't fix it ;)

GypsyPrince

  • New Member
  • *
  • Posts: 31
Re: FreePascal book covering only DLLs...
« Reply #12 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?
« Last Edit: November 21, 2020, 08:08:28 pm by GypsyPrince »

PascalDragon

  • Hero Member
  • *****
  • Posts: 2429
  • Compiler Developer
Re: FreePascal book covering only DLLs...
« Reply #13 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.

GypsyPrince

  • New Member
  • *
  • Posts: 31
Re: FreePascal book covering only DLLs...
« Reply #14 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.

 

TinyPortal © 2005-2018