Units in bpl auslagern und als Package in Exe/Dll einbinden

[hschmid67]

Hallo zusammen,

ich bin gerade dabei, ein größeres Projekt in kleinere Teile aufzuteilen. Dabei habe ich einzelne Module in dll-Dateien gepackt und binde diese dynamisch ein. Um die Dateigrößen - auch der Module - kleiner zu halten, habe ich begonnen, mit Runtime-Packages zu kompilieren. Damit ist jetzt jedes Modul (mit Formular) nur noch 1-2 MB groß, obwohl verschiedene Dritt-Komponenten eingebunden sind (z.B. DevExpress, UniDAC...). Soweit funktioniert es ganz gut.

Nun suchte ich noch nach weiteren größeren Units, die ich überall verwende und daher auch gerne auslagern würde. Dabei bin ich z.B. auf die Unit SuperObject gestoßen, die ich für die Json-Verarbeitung sehr praktisch finde. Wenn ich diese einbinde, wird meine Exe (oder die dll) auch gleich um über ein MB größer. Das würde sich also lohnen, sie auch in eine bpl-Datei auszulagern.

Aber hier bin ich ratlos. Wie geht das? Geht das überhaupt? Oder kann ich nur Komponenten auslagern? Aber für die rtl gibt es doch auch die rtl290.bpl. Auf der Suche nach einer rtl290.dpk bin ich auch nicht fündig geworden. Hat mir jemand einen Tipp? Oder geht das gar nicht so, wie ich mir das vorstelle? Wie könnte man gemeinsam verwendeten Code aus solchen Units (auch mehrere meiner eigenen Utility-Units wären dafür Kandidaten) einmal kompilieren, dann überall einbinden und damit die Dateien insgesamt kleiner halten?

Vielen Dank für Euer Mitdenken und Eure Erfahrungen
Harald

[dummzeuch]

Überleg Dir das gut. Man landet dann ganz schnell in der DLL/BPL(-Abhängigkeiten)-Hölle.
Heutzutage sind große Programmdateien wirklich kein Problem mehr.

[Uwe Raabe]

Wenn es wirklich ein Größenproblem ist, muss man genau prüfen, ob das Ganze damit nicht schlimmer wird. In der Regel ist die Größe aller BPLs plus der EXE bei Verwendung von Packages größer als die EXE wenn sie ohne Packages compiliert wird. Nur im letzten Fall kann der Linker allen nicht benötigten Code eliminieren. Packages enthalten immer den kompletten Code, da man ja nicht weiß, ob er später benötigt wird oder nicht. Nur bei eine sehr hoher Wiederverwendung der Packages von mehreren EXEs kann sich das dann rechnen.

Beispiel: Eine neue VCL-Forms Anwendung mit nicht mehr als einem leeren Form ohne weiteren Code erzeugt eine EXE von 2.417.392 Byte unter Delphi 12.1, die sich bei Compilieren mit Packages auf 188.928 Byte reduziert. Allerdings muss man dann die rtl290.bpl mit 12.734.440 Byte und die vcl290.bpl mit 4.419.048 Byte mitliefern. Dazu kommen noch die Sprachdateien rtl290.de und vcl290.de mit 136.680 Byte respektive 329.200 Byte. Das macht insgesamt 17.808.286 Byte - mehr als 7x so viel wie die ursprüngliche EXE hat. Und das sind nur zwei BPLs, die da verwendet werden.

[hschmid67]

Hmmm, ja, über diese Abhänigkeiten habe ich schon länger gegrübelt. Da es sich um ein relativ einfaches Rahmenprogramm mit aktuell ca. 15 eingebundenen Dll-Modulen und in Zukunft wohl noch ein paar Duzend dazukommen werden, schien mir dieser Weg mit den bpl-Abhänigkeiten geeignet. So muss ich nicht bei jedem neuen Modul alles wieder (mit zig MB) neu ausliefern - und könnte auch neue Funktionen/Module an einzelne User ausliefern, ohne die anderen mit einem riesigen Update zu belasten...

Naja, dass das mit den bpl-Dateien nicht ganz einfach ist und manche (neue) Probleme schafft, habe ich schon erfahren. Aber wenn ich das Ganze modular erweiterbar machen möchte, fiehl mir keine bessere Lösung ein. Denn ich will ja nicht mit jeder neuen dll-Datei wieder 20-30 MB ausliefern. Das wäre auch insgesamt mit einigen Dutzend Modulen zu riesig.

Deshalb doch meine Frage: Ist das möglich - und wie? - eine eigene oder fremde Unit in eine bpl zu verpacken, ohne daraus eine Komponente machen zu müssen und diese dann zu registrieren? Kann ich einfach nur die Unit in eine bpl packen und dann auf den Code zugreifen? Und wie ginge das dann? Oder geht das nur, indem ich z.B. wie in einer dll eine Funktion, z.B.

Delphi-Quellcode:

SuperObject.SO()

exportiere und diese dann einbinde. Das hieße ja dann, ich müsste in jedem meiner Dll-Module Code einbauen zum dynamischen Laden der Dll und ihrer Funktionen. Oder ich schreibe eine Unit, die alle dll-Funktionen importiert und binde diese dann statisch ein...

Ich verstehe die Interna leider nicht gut - aber es schien mir doch charmant, ähnlich wie bei der rtl290.bpl einfach nur eine bpl-Datei einzubinden (in den Projekt-Optionen) und dann alle Funktionen des Interfaces einer Unit verfügbar zu haben.

Viele Grüße
Harald

[freimatz]

Zitat:

Zitat von hschmid67 (Beitrag 1537543)

Denn ich will ja nicht mit jeder neuen dll-Datei wieder 20-30 MB ausliefern.

MB? MB??? :-D Ich habe hier privat ein System mit mehreren Anwendungen. Die kleinste hat ein halbes, das grösste 42 GB.
Das lohnt sich nur zur Befriedigung eines Perfektionsbedürnisses (kenne ich nur zu gut). Finanziell lohnt sich das ganz sicher nicht. Selbst beim Aspekt CO2 habe ich starke Zweifel.

[Uwe Raabe]

Zitat:

Zitat von hschmid67 (Beitrag 1537543)

So muss ich nicht bei jedem neuen Modul alles wieder (mit zig MB) neu ausliefern - und könnte auch neue Funktionen/Module an einzelne User ausliefern, ohne die anderen mit einem riesigen Update zu belasten...

Das wird in den seltensten Fällen so funktionieren, wie du dir das vorstellst. Wenn du einzelne Module austauschen willst, dann geht das nur, wenn sie im Interface-Teil unverändert bleiben. Das ist übrigens auch der Grund warum bei Delphi-Updates bestimmte Dinge nicht gemacht werden können. Will oder muss man das wirklich machen, landete man bei umständlichen und schlecht wartbaren Hacks, deren einziger Zweck die Wahrung der Kompatibilität ist.

Ich schließe mich da auch meinen Vorrednern an: Deine Intention ist vermutlich fehlgeleitet. Wenn du keine besseren Argumente hast als die bisher vorgetragenen, würde ich von dem Vorhaben abraten. Viele von uns waren in der Vergangenheit sicher auch schon an dem Punkt (mich eingeschlossen) und haben es am Ende dann doch wieder fallen gelassen. Es gibt sicher Anwendungen, die von Packages profitieren oder anders gar nicht realisierbar wären. Deine Anwendung gehört offenbar nicht dazu.

[TomyN]

Und Du müsstest extrem viel auf die Kompatibilität achten oder halt immer irgendwas nachladen oder mit in den Installer packen, so wie es immer noch Programme gibt, die irgendeine bestimmter C-- Runtimeversion aus 2013 o.ä. verlangen und installieren..... :-(

[Sherlock]

Noch anders formuliert: Wenn Du nicht gerade auf Disketten auslieferst, hast Du durch eine Auslagerung in BPL oder DLL nichts gewonnen außer Bauchschmerzen. Und selbst dann, konnte man schon vor 30 Jahren Zip auf mehrere Disketten aufteilen lassen (disk spanning seit V2.0 von 1993 des ZIP Formats).

[johndoe049]

Also wenn die Größe für Updates der einzige Grund ist. Dem kann geholfen werden.

In einigen Gebieten (Inland/Ausland) gibt es langsame Internetverbindung. Daher ist das ein Thema für uns.

Lösung: Binäre Delta Updates. D.h. eine Komprimierte Übertragung von Änderungen.

Etwas teuer aber gut wäre z.B. RTPatch von Pocketsoft.

Patch Management kosten zwar etwas, man muss aber nichts an der Entwicklung ändern, nur um Platz für Updates einzusparen.

[himitsu]

Und vergiss nicht, dass du dann auch schnell noch weitere Packages mitgeben mußt.
z.B. RTL, VCL uvm.

in der RTL liegen z.B. die System.pas (Speichermanagement/Strings), SysUtils usw.

C:\Program Files (x86)\Embarcadero\Studio\22.0\Redist\win32