----- "Michael Schnell" <[email protected]> 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 -- _______________________________________________ Lazarus mailing list [email protected] http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
