Minimalistisches PlugIn-System

[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?

[ehX]

Zitat:

Kannst Du dazu vielleicht ein simples Beispiel posten?

Von was jetzt genau? Von einem Lua-Script?

Wenn von einem Addon, dann wird das nicht so "simpel" (zumindest nicht für einen kleinen Code-Block hier im Forum), da ja erst mal Lua initialisiert, die API registriert werden muss, die Deklarationen eingebaut usw.
Aber ich kann evtl. das die Tage mal zu einem Mini Demo-Projekt zusammenbauen.

[neo4a]

Zitat von ehX:

Zitat:

Kannst Du dazu vielleicht ein simples Beispiel posten?

Von was jetzt genau? Von einem Lua-Script?

Wenn es hilft, die Umsetzung innerhalb Deines Plugin-Systems besser zu illustrieren, dann auch das.

[ehX]

Also, generell ist es so (stark vereinfacht, und das ganze wird natürlich dann in Plugin- / API-Klassen gekapselt):


1) Du bindest erstmal die Lua-Header (Lua, LuaLib, LualAuxlib) ein.
In meinem Fall verwende ich für Delphi Lua 5.1.4.
Die Header liegen natürlich erstmal in C vor und müssen für Delphi konvertiert werden.
Das ist aber nicht sonderlich schwer, nur nervig

2) Du deklarierst eine API-Funktion im Host, auf die Lua dann Zugriff haben soll, z.B. ein simples Showmessage:

Delphi-Quellcode:

function lua__Showmessage(L:Lua_State):Integer; cdecl ;
var
  i,pCount : Integer ;
  FAddOn : TehXAddon ;
begin
  // Ausführendes Plugin anhand des Lua-States ermitteln (diese Funktion ist dann in der Plugin -Klasse und ist für das Beispiel nun nicht sonderlich relevant)
  FAddOn := LuaHandler.FindAddOnByState(L) ;
  
  // Hole dir die Anzahl der von der Lua-Funktion auf dem Lua-Stack abgelegten Parameter
  // An der höchsten Position des Lua-Stacks befindet sich immer die Anzahl der Parameter auf dem Stack
  // In diesem Fall bedeutet jeder Parameter ein eigenes Showmessage
  pCount := lua_gettop(L) ;
  
  for i := 1 to pCount do
  begin
    // Parameter vom Lua-Stack holen, als string casten und per showmessage() ausgeben
    // Man zählt von der höchsten Lua-Stack-Position rückwärts
    Showmessage(lua_tostring(L,-i)) ;
  end;
  
  // Lua-Stack bereinigen => Parameter vom Stapel nehmen
  lua_pop(L,lua_gettop(L));
  
  // Rückgabewert 0 an Lua => Anzahl der von der Funktion auf den Stack gelegten Variablen 
  // => Es wurde in diesem simplen Beispiel nichts abgelegt
  Result := 0;
end;

3) Man initialisiert im Host einen neuen Lua-State über die Lua-API über luaL_open() ;

4) Die vorhin deklarierte Funktion muss für den Lua-State registriert werden, damit Lua sie auch verwenden kann, das geht mit lua_register.
Wir nennen die Funktion in Lua simpel "Showmessage", wie im Delphi-Original
lua_register(FLuaState,PAnsiChar('Showmessage'),lua__Showmessage);

5) Jetzt kann man die Funktion in einem Lua-Script verwenden:
Folgender Aufruf in einem Lua-Script führt nun zwei Showmessage des Hostprogramms aus, einmal mit "Hello" und einmal mit "World"

Code:

Showmessage('Hello','World');

6) Das Host-Programm muss dazu gebraucht werden, den Lua-Code auch zu laden und auszuführen, das passiert ähnlich wie bei einer DLL (Datei laden und initialisieren über lua_dofile oder auch einzelne Funktionen, um Lua-Chunks auszuführen. Die Logik, wann was passiert, wird natürlich über deine Programmlogik (Eventhandler etc.) gesteuert)

Umgekehrt geht das ganze natürlich auch, der Host kann jegliche Funktionen eigenen API über Lua, und auch alle Funktionen, die in den Scripten deklariert wurden, über call /pCall aufrufen, aber das würde jetzt das kleine Beispiel sprengen

Ich hoffe, die generelle Vorgehensweise ist nun klar?
Durch die Implementierung von Lua kannst du also nun Funktionen als API schreiben, die der Script-Engine zur Verfügung stehen sollen und deine Kunden können daraus dann Plugins und Addons basteln. Wie diese Funktionen aussehen und was sie machen, ist nicht beschränkt, da sind dir alle Möglichkeiten offen.
Zudem hast du so auch die Möglichkeit, z.B. verschiedenen User-Accesslevels auch unterschiedliche API-Funktionen über lua_register() zu registrieren, so dass nicht jeder alles verwenden darf.

[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.