Das ist eine lange Geschichte. Früher als der Hauptspeicher sehr knapp (90) war wurde sehr viel Wert drauf gelegt die Komponenten in der
GUI (
BPL) zu trennen von den gelinkten 'Libraries' (DCP).
In der
BPL waren der sichtbar Teil mit dabei (Property Editoren bspw.). In PHP Welt wäre der Teil heute eher ein Smarty Template (auch wenn der Vergleich hinkt).
Im
DB Bereich fließt diese Trennung eher im Rahmen der Schichtung (Layering) bei Devart, FireDAC, DBX (stackable drivers bspw.) und ZEOS eher in der Architektur ein.
In einer
BPL steht salopp formuliert der Teil noch zusätzlich drinnen der in den Lazarus noch muss reinkompiliert werden. Hernach kann man frisch von der Leber rumpfrimmeln.
---
Borland hat ein wenig vermischt.
An sich gibt es in der 'C' Welt (Pascal fällt schon auch in diese Kategorie ob des PC) Libraries die statisch oder dynamisch gelinkt werden.
---
Ein Modul läuft im Kontext eines geschlossenen Systems (IBM,
DEC, Tandem, ...). In moderner Sprache wurden diese Module gejittet. In der Library waren die .obj Files verpackt.
COM/MTS,
DCOM,
COM+ wäre so ähnlich gelagert und verbandelt mit ASP (MS rund um 2k). Ganz zu Beginn von .net war man eigentlich wieder an dem Punkt. (ASP.net Forms und Winforms). Das war der Übergang zu den Assemblies und damit verbunden die Namespaces. Namespaces wäre eine Art Klammerung aus der architektonischen Sicht.
Ein Model wird aktiviert. Bei die ursprünglichen Module (findet man heute noch im Großrechner Modula) wurde angegeben ob bspw. bei jedem Aufruf eine Instanz wird erzeugt. Damit hat sich wieder vermischt bspw. die Vorgabe 'eine Prozedur darf nur ca. eine Bildschirmseite (Terminal) lange sein). 24 + 1 Zeilen (Propertied DOS Promt, Terminal Size Linux bpsw.)
Daraufhin wurden oft einzelne Prozeduren in Module verpackt. Das merkt man noch beim Import Statement import Modul.Funktionsame (bspw.) (ähnlich Java, allein dass Java keine Prozeduren kennt und somit auf jeden Fall mal in dem Kontext ein Modul importiert). Das gab es auch in Java. Klassen mit einer Methode die per HTTP Request wurde aufgerufen. Die Java Welt war die zweite Schiene den Host/Mainframe über CS abzulösen. Bevor J2EE kam.
---
Libraries sind Verbunde von übersetzten Compilation Units. C kennt keine Module. Module kommen mehr oder weniger aus der Mainframe Welt. Der UNIX Ansatz war die Executable.
Ein
Package selbst ist Klammerung von Source Code Files. Mehr an sich nicht. Deswegen handelt es sich auch um eine
Package Library. Deswegen wird die
Package auch gecached. Damit die das
RAD Studio schnell nachschauen kann. Das dreht sich für den Programmier um und geht zu seinem Bücherregal wo die gute alte 20m
DEC Dokumentation zur PDP 11 steht.
---
Derweil lass dich von DCL und DCPs nicht schrecken. Irgendwann mal vor/rund um 2000 wurde die Trennung aufgegeben. Der Overhead der
GUI Repräsentation wurde in Relation zum Hauptspeicherzugewinn immer geringer. Dann, glaube ich, kam erst die Änderung (aber mich nicht schlagen wenn dem nicht so ist), dass die DCPs automatisch gefunden werden sobald die Position der
BPL im Filesystem bekannt ist. (Das kann ich nicht mit Sicherheit sagen).
Sauberer ist wie Stevie implizit sagt die Trennung. Heute eher aus dem Gesichtspunkt der Schichtung und der Architektur und nicht mehr einer technisch bedingten Erfordernis geschuldet.
Also kompilieren und einbinden klappt, war halt meine Eigene Schuld das zu übersehen!
Ich geh da nach Anleitung weiter vor bzw. hätte ich es eh so gehandhabt, die DCUs auch im Library Pfad und fertig sollte es sein, wenn da doch noch mal nach einem Source gefragt wird kann ich ja nachreichen.
Vielen Dank an alle für Eure Geduld mit mir!!