[Lazarus] RE : Forms in DLL

[Dimitri Smits]

----- "Michael Schnell" <mschnell at lumino.de> schreef:

> Some more background:
> 
> (AFAIK:)
> 
> A normal Lazarus/FPC (and Delphi) created SO (shared object)  ( = 
> Windows DLL, Linux .so, Mac ???, ...???) instantiates its own 
> independent memory manager. This is perfectly fine, as it does not
> know 
> in what language the calling program is done and what memory manager 
> same uses.
> 
> The Plus is that it just works, the Minus is that the interface
> between 
> the program and the SO always needs to be "flat" (just using simple C
> 
> compatible types, no Objects no Pascal Strings etc.)
> 
> The SO is not supposed to do anything on it's own but is just a 
> "library" of functions that can be called
> 

well, all of this would be a moot conversation if fpc actually did something with the "package" application.

In delphi, the program type "package" is just that what you are trying to do:
- a SO that has a shared environment with the exe, thus allowing to do away of all the limitations you described

Take for instance Delphi 7.

Every program can be build in one of 2 ways =>
1) monolithic build 
- everything you need is build-in one giant exe and smartlinking is applied (if optioned)
- if you want to use so's; you would have to load them manually through LoadLibrary
- if you want to use packages (*.bpl) from this setup => use LoadPackage. It would instantiate one (!) new rtl environment shared by all the loaded packages, but still separate from your main program

2) with a set of "runtime packages", dynamically linking
- your set of "runtime packages" are scanned recursively for dependancy on other packages, who are all added to a set of "selected runtime packages"
- the "selected runtime packages" and their units' contents are dynlinked in the main program
- EVERY package has as a requirement the RTL package (in Delphi 7 rtl70.bpl)

A smart algorithm is used to "register" the packages (and the main program is one as well in this context) on startup/initialization of the package in an "in order" fashion, which does the loop over the package's units' initializations.

in other words, with this setup, one would get following:
=== setup
main.exe build with runtime packages "mypackage" 
mypackage.bpl has dependencies rtl70
=== real runtime packages
main.exe is dynlinked with rtl70.bpl, mypackage.bpl
=== load order
main.exe -- rtl70.bpl -- mypackage.bpl
=== rtl70.bpl:registerpackage call order/initialization order
rtl70.bpl -- mypackage.bpl -- main.exe


And guess what is contained in rtl70? the SHARED memory manager, sysutils/system, classes, ...

Likewise, the classtypes are unique because the used units are scanned in that registerpackage procedure to ensure that there are no 2 packages/exe that share the same unit!


There are however 3 different kinds of packages (to make this again about Lazarus and draw the parallels with Delphi)
- runtime only => the real workhorse with the definitions/code of your library
- designtime only => stuff that interacts with the IDE (Delphi) and a runtime package, like property editors, designers, ...
- designtime+runtime => all rolled into one => the question is, why would you need IDE-specific property editors in your production code for instance?


kind regards,
Dimitri Smits