DLLs als Windows-Plugin mit Lazarus

[Lincoln Six Echo]

Von marktführenden Bildbearbeitungsprogrammen über diverse seit Jahrzehnten ausgereifte Musik- und Videoprogramme bis zur Business-Software bieten diese fast alle die Möglichkeit über Plugins den Leistungskatalog zu erweitern.

Im Bereich Multimedia sind darauf ganze Unternehmen aufgebaut die nur solche Plugins produzieren, virtuelle Musikinstrumente, virtuelle Tonstudiotechnik uvm.

Ich habe nun selbst solche Plugins gebaut. Das sind erstmal ganz normale DLLs, die kann man mit Lazars wunderbar erstellen. In meinen Programmen (die ebenfalls mit Lazarus gebaut sind) laufen die alle fehlerfrei.

Nun nehme ich aber so ein Megaprodukt und will mein Plugin darin laufen lassen. Programm A : Alles läuft so wie es soll. Programm B: dito. Programm C aber meldet es sei eine 32bit DLL die nicht mehr unterstützt wird. Programm D hängt sich ohne weitere Fehlermeldung auf und Programm E verkündet per Bildschirm-Dialog die entsprechende DLL sei keine korrekte Windows 64 DLL.

Ich habe nun sämtliche Einstellungen und Compiler-Schalter durchprobiert, es ändert nichts. Es bleibt dabei das einige Programme melden, es sei keine korrekte Windows-64 DLL.

Hat hier vielleicht jemand ein ähnliches Problem ? Sind mit Lazarus und dem FPC erstellte DLLs inkompatibel ?

[af0815]

Das liegt vermutlich and dem, das DLL nicht gleich DLL ist. Da hängt einiges davon ab, was das Target der DLL ist und auch wie die Parameterübergaben definiert sind. In welchen Format wird die die DLL vom Programm erwartet ? C oder C++ kompatibel, mit welchen originalen Compiler erstellt. Das macht die Sache nicht übersichtlich. Über das stolpert man auch, wenn man Header Dateien für den Zugriff auf Dll's versucht zu übersetzen.

Schon einmal die originalen Erweiterung mit einem PE-Viewer angeschaut und mit deiner DLL verglichen ?

[Lincoln Six Echo]

Da die Hosts alle in C++ gebaut sind habe ich alle Parameterübergaben als "cdecl" definiert. In den meisten Programmen laufen die ja auch ohne Fehler.

Es gibt aber auch ein sehr beliebtes Programm das komplett in Delphi erstellt ist. Da wird mir angezeigt das mein Plugin beim Laden einen Fehler verursacht und deshalb nicht ausgeführt wird. Nur welcher das ist behält das Programm leider für sich.

Ich frage mich ob ich als Entwickler überhaupt mit Lazarus die Möglichkeiten habe DLLs zu erstellen die dann auch in allen Hosts laufen.

Bin mir nicht sicher was du mit PE-Viewer meinst. Ich habe hier natürlich eine Menge solcher Tools, einen Resource-Editor, ein Tool um die Sprungadressen einer beliebigen DLL anzuzeigen, Hex-Viewer uvm.

[Lincoln Six Echo]

Ich hatte zuerst vermutet das es an der Ausrichtung von Records liegen könnte Aber $A+ oder $A- ändert leider nichts. Auch $H+ und $H- ergibt keine Änderung des Problems. Resources sind keine eingebunden. Aber auch wenn ich welche einbinde ändert das nichts.

[af0815]

CFF Explorer ist so ein spezielles Tool. Damit kann man sich einiges der internas von exe und dll ansehen.

Screenshot 2023-04-05 132358.jpg (83.54 KiB) 1356 mal betrachtet

Ich frage mich ob ich als Entwickler überhaupt mit Lazarus die Möglichkeiten habe DLLs zu erstellen die dann auch in allen Hosts laufen.

Nein, das kannst du nicht, es müssen immer beide Seiten mitspielen bzw. auch die Schnittstellen dokumentieren.
Wenn ein Programm externe Schnittstellen anbietet dann sollten die auch Dokumentiert sein.

Es gibt aber auch ein sehr beliebtes Programm das komplett in Delphi erstellt ist. Da wird mir angezeigt das mein Plugin beim Laden einen Fehler verursacht und deshalb nicht ausgeführt wird. Nur welcher das ist behält das Programm leider für sich.

Da wird es schwierig wenn die Schnittstelle nicht dokumentiert ist. Gerade bei Delphi habe ich auch Probleme mit den UCS2 Strings gehabt, bis ich die sauber in Lazarus/fpc bekommen habe. Nur dort war das Interface bei mir umgekehrt Delphi-dll in Lazarus verwenden.

[Socke]

Da die Hosts alle in C++ gebaut sind habe ich alle Parameterübergaben als "cdecl" definiert. In den meisten Programmen laufen die ja auch ohne Fehler.

Willst du ein identisches Plugin in verschiedenen Programmen einbinden? Dann könnte es vielleicht einfach daran liegen, dass du eine 32-Bit DLL erzeugt hast, das Programm aber ein 64-Programm ist. Programm und Plugin müssen immer für die selbe Architektur erstellt sein.

[Lincoln Six Echo]

Die Schnittstellen sind umfassend dokumentiert, da gibt es keinerlei ungeklärtes.

Die DLLs sind alle 64Bit. Das seltsame ist ja das sie in vielen Anwendungen laufen und in einigen die verschiedensten Fehlermeldungen erzeugen. Heute habe ich noch einige weitere getestet, da bekomme ich u.a. die Fehlermeldung das das Plugin "nicht richtig installiert sei". Dabei gibt es da gar nichts zu installieren, es sind einfach nur einzelne Dateien die vom Host-Programm geladen werden. Bei vielen Doc's der Programme findet man die Erklärung man sollte das neue Plugin einfach in den entsprechenden Ordner kopieren.

Ich habe es auch umgekehrt gemacht, d.h. eine Host-Anwendung geschrieben und damit versucht meine und andere Plugins zu laden.

Bei einigen tritt eine Exception "Division durch 0" auf. Starte ich das Host-Programm "ohne Debugger starten" erhalte ich diesen Fehler bei diesen Plugins nicht mehr. Es muss also an Lazarus bzw. FPC liegen, denke ich.

Und Dank an af0815, den CFF Explorer habe ich mir sofort besorgt.

[PascalDragon]

Bei einigen tritt eine Exception "Division durch 0" auf. Starte ich das Host-Programm "ohne Debugger starten" erhalte ich diesen Fehler bei diesen Plugins nicht mehr. Es muss also an Lazarus bzw. FPC liegen, denke ich.

FPC (und auch Delphi) schaltet FPU Exceptions ein, da dies Object Pascal Code normal erwartet. C oder C++ rechnet nicht damit und daher kommt es dann zu Problemen, wenn dann eine entsprechende Exception im nicht-Object Pascal Code auftritt.

Nun nehme ich aber so ein Megaprodukt und will mein Plugin darin laufen lassen. Programm A : Alles läuft so wie es soll. Programm B: dito. Programm C aber meldet es sei eine 32bit DLL die nicht mehr unterstützt wird. Programm D hängt sich ohne weitere Fehlermeldung auf und Programm E verkündet per Bildschirm-Dialog die entsprechende DLL sei keine korrekte Windows 64 DLL.

Welche FPC Version verwendest du? Es kann auch sein, dass die Programme nach den falschen Funktionsimporten suchen.

[Lincoln Six Echo]

Die IDE ist 2.2.2, FPC ist 3.2.2

Ich habe hier viele Plugins von anderen Herstellern die beim Laden Exceptions auslösen. Die lassen sich aber auch ganz ohne Abstürze behandeln obwohl diese Plugins in C++ mit VC geschrieben wurden.

Genau genommen treten die Fehler auch nicht beim Laden auf, also ich meine z.B.

h := dynlibs.loadlibrary(filename)

Das geht alles fehlerfrei. Die Plugins stürzen ab sobald sie einen Window-Handle zugewiesen bekommen und es an die Darstellung des GUI geht.

Die meisten machen das alles fehlerfrei aber einige stürzen ab und teilweise das Host-Programm gleich mit.

Von einem Hersteller habe ich drei, die machen das alle. Nur wenn ich dem zugewiesenen TForm ein TPanel mit dem Align alTop gebe, laufen sie. Den Hersteller habe ich bereits mehrfach angeschrieben, bis heute keine Antwort.