Difference between revisions of "packages"

From Free Pascal wiki
Jump to navigationJump to search
(New page: FPC/Lazarus unfortunately are a bit ambiguous with respect to the term packages. Some meanings: # A set of units in FPC that are treated together. # A set of units in Lazarus (with design...)
Line 1: Line 1:
 
FPC/Lazarus unfortunately are a bit ambiguous with respect to the term packages. Some meanings:
 
FPC/Lazarus unfortunately are a bit ambiguous with respect to the term packages. Some meanings:
  
# A set of units in FPC that are treated together.
+
# A set of units in FPC that are treated together. Both using the older [[fpcmake]] as the newer [[fppkg]] packagemanager.
# A set of units in Lazarus (with designtime parts that require registration into the DLL)
+
# A set of units in Lazarus (with designtime parts that require registration into the DLL). See [[Lazarus Packages]]
 
# Delphi packages, which are like DLLs.
 
# Delphi packages, which are like DLLs.
  

Revision as of 00:14, 26 May 2007

FPC/Lazarus unfortunately are a bit ambiguous with respect to the term packages. Some meanings:

  1. A set of units in FPC that are treated together. Both using the older fpcmake as the newer fppkg packagemanager.
  2. A set of units in Lazarus (with designtime parts that require registration into the DLL). See Lazarus Packages
  3. Delphi packages, which are like DLLs.

This article is meant as a brainstorm session about the latter, one of the missing pieces of the Delphi compability.

A Delphi package is essentially a DLL with some extra's.

  • One of those extra's are two procedures, a pascal level initializer ("Initialize") and a module finalizer ("Finalize"). I'm not sure if they are library procedures that traverse compiler generated tables, or if they are wholly compiled generated.
  • If your system uses packages,
    • the RTL and other units the packages use, must also be in a package.
    • A unit can exist only once in one package (see Swart reference below), and probably the EXE too . On load of a package this is checked, but possibly only when packages are dynamically loaded by the program. This combined with the previous bordercondition avoids problems like multiple definitions of the VMTs.
    • Since they are DLLs, the Windows DLL symbol resolving can probably survive some minor patching (allowing implementations to be fixed), but in general it must be pretty much the same packages as the program was compiled with.
  • Packages can use higher level functions (like ansistrings and classes) over packages borders. This means they use the same memory manager. It is not know if this automatically is changed to COM compatible memmanager sharemem (e.g. in the rtl BPL creation) or if this is the normal suballocator.
  • Like DLLs, packages can be statically linked (so that its presence is required for startup), and programs can load additional packages using loadpackage (unloadpackage?). Since a package can only depends on existing packages, and not on the exe (RTL also in package remember!), this means that dynloaded packages can be crafted AFTER .exe generation, allowing for plugin systems.
  • packages are loaded by a procedure called "safeloadlibrary" which is a loadlibrary wrapper that saves the FPU statusword and disables some windows errorwindows on failure to load. (?!?)

References