Minimalistisches PlugIn-System

[Stevie]

Zitat von hanspeter:

Mit dll als Plugin kann man früher oder später auch ganz schön auf die Schn... fliegen.
Es verstecken sich 4 größere Problemchen.
1. Ich muss mit BPL arbeiten. Die müssen alle mit der gleichen Compilerversion in der gleichen Umgebung compiliert sein.
Wird (ausversehen) mal eine Init neu compiliert kommt gerne der Fehler ... wurde mit unterschiedlicher Version compiliert- und das erst beim Kunden.
2. Verwechselt jemand völlig gleichnamige BPL in unterschiedlichen Verzeichnissen, dann ist die BPL Hölle los.
3. Der Linker ist garnicht mehr so smart. Liegt auch daran, das im Initialisierungsteil einer Unit Code liegt.
Ich habe mein Programm mal auf einem Delphi-freien Rechner installiert und die von mir als Laufzeit angegebenen BPL dazu.
Danach musste ich noch 76 weitere BPL kopieren, darunter die BDE bis das Programm startfähig war.
4. Delphi registriert bei Windows Klassen über den Klassennamen.
Wird diese Klasse (z.B. Fastreport) in einer weiteren Dll verwendet, dann kommt die Fehlermeldung ...kann nicht geladen werden Klasse bereits registriert.
Der Fehler kommt irgendwann beim Kunden wenn in irgendeiner Konstellation dll A und B geladen werden und bei die gleiche Klasse verwenden wollen.
Die BPL ist so ein alter überflüssiger Zopf und Technologie des vorigen Jahrhunderts.

Dem kann ich nicht ganz zustimmen:
zu 1. Entwickelt euer Kunde eigene Plugins? Dann muss er natürlich die korrekten Dateien der BPLs bekommen. Wenn nicht, dann kann der "wurde mit unterschiedlicher..." Fehler nicht kommen. Oder die Anwendung wurde einfach schlampig getestet (auf einem Rechner, der keine Delphi Installation enthält)

zu 2. BPLs im Programm Verzeichnis -> keine Probleme

zu 3. Dann hast du wohl die falschen Runtime packages in deinem Programm angegeben oder in deiner eigenen BPL required. Ich hab selber schon erlebt, dass Leute null Plan von BPLs haben und was in welchen Packages zu finden ist, so dass total unnötige Packages required und demzufolge und ausgeliefert wurden.

zu 4. Genau deshalb benutzt man ja Runtime packages. In dem Fall würde man das Fastreport Package requiren.

Die BPL Technologie mag schon alt sein, deshalb ist sie aber nicht schlecht. Wie bei vielem kann man sich aber viel Ärger einhandeln, wenn man sie nicht zu beherrschen weiß.

[hanspeter]

Zitat von Stevie:

Oder die Anwendung wurde einfach schlampig getestet (auf einem Rechner, der keine Delphi Installation enthält)

zu 3. Dann hast du wohl die falschen Runtime packages in deinem Programm angegeben oder in deiner eigenen BPL required. Ich hab selber schon erlebt, dass Leute null Plan von BPLs haben und was in welchen Packages zu finden ist, so dass total unnötige Packages required und demzufolge und ausgeliefert wurden.
Wie bei vielem kann man sich aber viel Ärger einhandeln, wenn man sie nicht zu beherrschen weiß.

Ich möchte mir die Anwürfe und Unterstellungen ausdrücklich verbitten.
Genau wegen der beschriebenen Probleme haben wir die Neuentwicklung in Delphi schon vor längerer Zeit eingestellt.
Aber schön wenn Delphi noch von einigen Fanatikern verteidigt wird.

Peter

[neo4a]

Zitat von hanspeter:

Genau wegen der beschriebenen Probleme haben wir die Neuentwicklung in Delphi schon vor längerer Zeit eingestellt.
Aber schön wenn Delphi noch von einigen Fanatikern verteidigt wird.

Hallo Peter,

Dein Post-Counter zeigt, dass Du lange und aktiv hier im Forum unterwegs bist. Ein Wechsel der Entwicklungsumgebung weg von Delphi ist für mich nachvollziehbar.

Wie kommt es aber, dass aus einem aktiven Delphi-Entwickler und einem, der noch jetzt aktiv in einem Delphi-Forum unterwegs ist, einer wird, der seinen Mitstreitern bei Delphi-Lösungen Fanatismus vorwirft?

Wenn es nur eine ungeschickte Wortwahl ist, okay - aber ansonsten finde ich Deine Attitüde ("Ihr Armleuchter - ich weiß es besser, sage aber nicht was") befremdlich, um es einmal höflich zu formulieren.

[ehX]

Ich verwende ein PlugIn-System meist so, wie es viele Spiele machen: keine DLL's, die nativen Code beinhalten, sondern das Hauptprogramm stellt alle für das PlugIn-System verfügbaren Funktionen als Lua-API zur Verüfgung, auf die man dann Scripten kann.
Die Plugins selbst bestehen dann aus einer oder mehreren lua-Dateien (oder compilierte luac-files) und haben zusätzlich eine TOC-File mit z.b. Versions-Informationen, welche Dateien zusammengehören, API-Version usw. Insgesamt so ähnlich wie z.B. das Addon-System von WoW.

Für mich war das ein gangbarer Weg für ein Plugin-System, da man so die volle Kontrolle vom Host hat, was ein Plugin darf und was nicht (keine Dlls, die geladen werden) Der Nachteil dabei ist natürlich, dass die interne API alle möglichen Dinge abdecken muss wie z.B. neue GUI-Elemente über die Lua-API dynamisch erstellen, binden etc. Das macht das Ganze natürlich aufwändiger.
Die Host-Anwendungen sind bei mir dann auch meistens in vollständiger Modul-Bauweise gebaut und werden über ein "Core-Plugin" verbunden.
So ist man auch flexibel, die Reihenfolge beim Start der eigenen Anwendung vollständig selbst festzulegen, welche Fenster geöffnet werden, was initialisiert wird etc. und alles über das Core-Plugin zu ändern.
(dazu muss natürlich die API jegliche GUI-create-Funktionen, Initialisierungs-Routinen der Module, Berechungsfunktionen o.Ä. nach aussen porten und braucht zumindest eine kleine Schicht, die das Window-Management übernimmt)

Ich weiss nicht, ob so ein Ansatz für dich in Frage käme, ich bin damit bis jetzt eigentlich immer ganz gut gefahren.

[Florian Hämmerle]

Zitat von ehX:

Ich verwende ein PlugIn-System meist so, wie es viele Spiele machen: keine DLL's, die nativen Code beinhalten, sondern das Hauptprogramm stellt alle für das PlugIn-System verfügbaren Funktionen als Lua-API zur Verüfgung, auf das man dann Scripten kann.
Die Plugins selbst bestehen dann aus einer oder mehreren lua-Dateien (oder compilierte luac-files) und haben zusätzlich eine TOC-File mit versions-Informationen, welche Dateien zusammengehören etc. So ähnlich wie das Addon-System von WoW.

Für mich war das ein gangbarer Weg für ein Plugin-System, da man so die volle Kontrolle vom Host hat, was ein Plugin darf und was nicht (keine Dlls, die geladen werden) Der Nachteil dabei ist natürlich, dass die interne API alle möglichen Dinge abdecken muss wie z.B. neue GUI-Elemente über die Lua-API dynamisch erstellen, binden etc. Das macht das Ganze natürlich aufwändiger.
Die Host-Anwendungen sind bei mir dann auch meistens in vollständiger Modul-Bauweise gebaut und werden über ein "Core-Plugin" verbunden.
So ist man auch flexibel, die Reihenfolge beim Start der eigenen Anwendung vollständig selbst festzulegen und über das Core-Plugin zu ändern.
(dazu muss natürlich die API jegliche GUI-create-Funktionen, Initialisierungs-Routinen der Module o.Ä. nach aussen porten)

Was auch meinen früheren Vorschlag der Verwendung von littleDaves ScriptEngine wieder ins Gespräch bringt =D

[ehX]

Zitat:

Was auch meinen früheren Vorschlag der Verwendung von littleDaves ScriptEngine wieder ins Gespräch bringt =D

Jau, die ScriptEngine ist schon eine coole Sache!
Ich persönlich bin halt ein Lua-Fan, deswegen verwende ich das....auch wenn sich die ScriptEngine wohl für ein Delphi-Projekt insgesamt mehr anbietet..

[neo4a]

Zitat von ehX:

Ich persönlich bin halt ein Lua-Fan, deswegen verwende ich das

Kannst Du dazu vielleicht ein simples Beispiel posten?

[DeddyH]

Vielleicht sollte ich doch einmal erklären, wozu das Ganze eigentlich gut sein soll: meine Frau ist Lehrerin an einer hiesigen Förderschule und betreut dort die Werkstufe (die 16- bis 21-jährigen). Die Schüler dieses Alters lernen hauptsächlich, im täglichen Leben möglichst ohne fremde Hilfe zurecht zu kommen. Nun habe ich mir gedacht, ich könnte ein kleines Programm schreiben, das sich auf einfache Weise beliebig erweitern lässt. So könnte es z.B. Mini-Spiele und Mathe-Übungen anbieten (Wechselgeld zählen und solche Dinge). Man könnte natürlich auch viele kleine Exen erstellen und die dann einfach starten, ich möchte aber verhindern können, dass der Schüler Hans über den Explorer immer "Fang den Ball" startet, sondern nach 3 mal auch wieder etwas "Gescheites" machen muss. So kam ich auf die DLL-Idee. COM und *.bpl-Geschichten mögen ja durchaus ihre Berechtigung haben, sind mir für dieses Vorhaben aber viel zu oversized.

[BUG]

Wenn es nur darum geht, dann könntest du das schnell das mit einer "Seriennummer" lösen, das einfach als Parameter übergeben wird.

zB. in der Form (salt + hash(salt + geheimnis + systemzeitInMinuten))
Im aufgerufenen Programm prüft du, ob das Passwort für diese oder die letzte Minute gültig war.

Besonders sicher ist es zwar nicht, aber einfach zu implementieren.


Interessant wäre aber auch, wenn man die "Startberechtigung" bei einem zentralen Server abruft. Von dort aus könnte man dann leicht Berechtigungen verteilen.