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

[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

[dummzeuch]

Nur, um sicherzustellen, dass ich das richtig verstehe: Es geht um ein relativ einfaches Rahmenprogramm, welches Funktionalität mittels verschiedener Plugins als DLL anbietet? Und dieses System existiert so bereits?

Solange da die DLLs sich nicht gegenseitig aufrufen sondern nur ein vorgegebenes (prozedurales?) Interface für das Hauptprogramm zur Verfügung stellen, kann Dein Vorhaben durchaus sinnvoll sein, denn es spart für jede DLL alles das, was in den Standard-Packages zur Verfügung steht. Auch das Hauptprogramm kann dadurch kleiner werden.

Aber ich würde es bei den Standard-Packages für RTL und VCL, plus evtl. von wenigen Fremdkomponenten belassen. Sobald Du anfängst, eigenen Code in Packages zu verlagern, wird es komplex und lohnt in der Regel auch nicht.

Wichtig ist eine feste, dokumentierte Schnittstelle und eine Versionierung der DLLs, aber das sollte es für ein solches Programm bereits sowieso geben, unabhängig davon, ob Packages verwendet werden oder nicht.

[himitsu]

Nja, grundsätzlich spricht nichts dagegen, Packages anstatt DLLs zu verwenden.
Dynamisch laden lassen auch sie sich

LoadLibrary
LoadLibraryEx
SafeLoadLibrary
FreeLibrary

LoadPackage
UnloadPackage

und zusätzlich hat man den Vorteil erstmal ohne ShareMem rumzuspielen und auch stärker gemeinsamten Code, Klassen, usw. verwenden zu können.
OK, "DLLs" aus fremden Programmiersprachen fallen dann außen vor.
Und bei RuntimePackages muß man unbedingt aufpassen, dass die EXE, DLLs und BPLs in der selben Delphi-Version, Unterversion und selten sogar mit dem selben Patch kompiliert sein müssen.

Hier bietet es sich inzwischen an, mit dem automatischen Suffix zu arbeiten. (LibSuffix AUTO, siehe Projektoptionen > Beschreibung)
http://docwiki.embarcadero.com/RADSt...jects_(Delphi)


Alternativ kann man natürlich auch klassisch mit COM-Interfaces arbeiten,
sowie ganz einfache "Funktionen" in DLLs aufrufen,
oder Dergleichen.



Ja, praktisch ist es also auch möglich Erweiterungen in der Delphi-IDE zu nutzen, ohne dass beim (de)installieren die IDE beendet und neu gestartet werden muß.

[Commander Tom]

TMSSoftware bietet dazu auch etwas an: https://www.tmssoftware.com/site/tms...framework.asp#

Ob das allerdings passend sein könnte, kann ich nicht beurteilen.