DLL-Funktionen in Lazarus/FP einbindbar / wie einzubinden?

[igel457]

Zitat:

Ich begreife zudem nicht, was dieses ganze Rumgemache mit Loadlibrary und GetProcAddress überhaupt soll. Bisher lernte ich in Delphi die Aufrufe externer DLL-Funktionen so kennen (hat bisher, bei mir jedenfalls, immer so geklappt), Beispiel:

Delphi-Quellcode:

interface

function OpenThread(dwDesiredAccess: DWORD; bInheritHandle: BOOL; dwProcessId: DWORD): THandle; stdcall;

implementation

function OpenThread; external kernel32 name 'OpenThread';

Was spricht dagegen, dass auch mit FPC so zu machen? Diese Methode nennt sich statisches Laden

Und folgender Code von dir zum dynamischen Laden mit LoadLibrary ist ziemlicher Unsinn (siehe Kommentare):

Delphi-Quellcode:

procedure TForm1.FormCreate(Sender: TObject);
  var
  DLLHandle,hProcessSnap: THandle;
  Beispielfunktion: function(dwFlags:Integer;th32ProcessID:Integer):THandle;//alternativ Funktionsergebnistyp:Pointer, mit dem klappt es aber auch nicht
begin
  DLLHandle := LoadLibrary(kernel32);
  if (DLLHandle < HINSTANCE_ERROR) then showmessage('DLL konnte nicht geladen werden!')
  else
    begin
    Beispielfunktion := @GetProcAddress(DLLHandle, 'CreateToolhelp32Snapshot'); //Du möchtest nicht mit dem Pointer auf GetProcAddress arbeiten
    //hProcessSnap:=CreateToolHelp32SnapShot(2{TH32CS_SNAPPROCESS},0);

    FreeLibrary(kernel32) //Du willst die Funktion doch noch verwenden, also darfst du die Bibliothek nicht entladen
    end
end;

[Delphi-Laie]

Danke auch für Deine Mühe!

Zitat von igel457:

Was spricht dagegen, dass auch mit FPC so zu machen? Diese Methode nennt sich statisches Laden

Na gut, statisch und dynamisch nahm ich auch schon irgendwo unterschwellig wahr. Edit: So, wie ich es von Delphi kenne (oben genannt, wohl die statische Variante), funktioniert es in Lazarus ja nicht, deshalb eben all' diese (bisher erfolglosen) Verrenkungen!

Zitat von igel457:

Du möchtest nicht mit dem Pointer auf GetProcAddress arbeiten

Dieser Kommentar verschließt sich mir leider völlig. Wieso möchte ich nicht mit dem Pointer auf GetProcAddress arbeiten?
Ich möchte einfach nur eine Funktion einer DLL benutzen. Diese muß ich anscheinend in der Weise extrahieren, daß ihre Funktionalität einer anderen Funktion übergeben wird, damit letztere (die neue, selbstdefinierte Funktion) die Funktionalität der ersteren übernimmt. Ich begreife nicht, warum das so kompliziert ist und der Lazarus/FP-Compiler sich so hartnäckig weigert. Sicher, irgendetwas stimmt nicht, doch was, weiß ich immer noch nicht.

Zitat von igel457:

Du willst die Funktion doch noch verwenden, also darfst du die Bibliothek nicht entladen

Daß nach dem Entladen die Funktionsbenutzung nicht mehr möglich ist, ist mir durchaus klar. Ich möchte die Funktion an jener Stelle überhaupt nicht mehr benutzen. Ich hätte ja schon einen Glückshormonausstoß, wenn das erfolgreich kompilieren und - optimalerweise - die Funktion sogar erfolgreich aufgerufen würde.

[Delphi-Laie]

Die ganze Kunst scheint darin zu bestehen, den Kommandozeilenschalter

{$mode DELPHI} zu verwenden, damit scheint es erstmal zu klappen.

Tausend Dank für die Geduld an alle! Problem (erstmal?) geklärt....

[igel457]

"External" sollte auch ohne {$MODE DELPHI} funktionieren.

Schau dir mal die folgenden Header an, vielleicht helfen die dir:

OGG-Header (wird mit FPC mitgeliefert, statisches Laden):
http://audorra.svn.sourceforge.net/v...26&view=markup

Acinerella Header (von mir, statisches Laden):
http://audorra.svn.sourceforge.net/v...=1&view=markup

Libao Header (von mir, dynamisches Laden, AcGetProcAddress ist (fast) nur ein Synonym für GetProcAddress)
http://audorra.svn.sourceforge.net/v...36&view=markup

[Delphi-Laie]

Zitat von igel457:

"External" sollte auch ohne {$MODE DELPHI} funktionieren.

Tut es aber leider nicht, wenigstens bei mir nicht. Ohne den Delphimodus bricht das Compilieren an der (beispielhafte) Zeile

function OpenThread; external kernel32 name 'OpenThread'; mit der Fehlermeldung

unit1.pas(32,20) Fatal: Syntax error, ":" expected but ";" found ab. Auch alle Bemühungen, den Fehlermeldungen des Compilers entsprechend, diesem die Codezeile schmackhaft zu machen (und sich damit immer mehr vom ursprünglichen Delphi-Quelltext bzw. der Delphi-Syntax zu entfernen), schlugen fehl.

Danke für die Mühe, aber bei Dingen, die ich nur knapp bewältige, die eher mich regieren als umgekehrt, bin ich Dünnbrettbohrer. Bin froh, daß es jetzt überhaupt läuft...

[igel457]

Eine Funktion benötigt auch einen Rückgabewert. Und im verlinkten OGG-Header von FPC geht es auch ohne "Mode DELPHI".

[JamesTKirk]

So... *Ärmel hochkrempelt*

Delphi-Quellcode:

procedure TForm1.FormCreate(Sender: TObject);
  var
  DLLHandle,hProcessSnap: THandle;
  Beispielfunktion: function(dwFlags:Integer;th32ProcessID:Integer):THandle;//alternativ Funktionsergebnistyp:Pointer, mit dem klappt es aber auch nicht
begin
  DLLHandle := LoadLibrary(kernel32);
  if (DLLHandle < HINSTANCE_ERROR) then showmessage('DLL konnte nicht geladen werden!')
  else
    begin
    Beispielfunktion := @GetProcAddress(DLLHandle, 'CreateToolhelp32Snapshot');//klappt auch nicht, wenn ich das „@“ weglasse
    //hProcessSnap:=CreateToolHelp32SnapShot(2{TH32CS_SNAPPROCESS},0);

    FreeLibrary(kernel32)
    end
end;

Ich erkläre dir mal die Ursache im ObjFPC-Modus:
Das Problem ist hier, dass du der Variable "Beispielfunktion" einen Verweis auf die GetProcAddress-Funktion übergibst, welche sich natürlich unterscheiden. Richtig wäre hier folgendes:

Delphi-Quellcode:

procedure TForm1.FormCreate(Sender: TObject);
type
  // wir benötigen einen Typ, zu dem wir casten können 
  TCreateToolhelp32SnapshotProc = function(dwFlags: Integer; th32ProcessID: Integer): THandle; stdcall; // vergiss hier das stdcall nicht!
var
  DLLHandle,hProcessSnap: THandle;
  Beispielfunktion: TCreateToolhelp32SnapshotProc; 
begin
  DLLHandle := LoadLibrary(kernel32);
  if (DLLHandle < HINSTANCE_ERROR) then showmessage('DLL konnte nicht geladen werden!')
  else
    begin
    // hier müssen wir jetzt auf den korrekten Typ casten
    Beispielfunktion := TCreateToolhelp32SnapshotProc(GetProcAddress(DLLHandle, 'CreateToolhelp32Snapshot'));
    //hProcessSnap:=CreateToolHelp32SnapShot(2{TH32CS_SNAPPROCESS},0);
    // aufrufen würdest du sie jetzt so:
    hProcessSnap := Beispielfunktion(2, 0);

    FreeLibrary(kernel32)
    end
end;

Ich weiß jetzt allerdings nicht aus dem Stegreif, ob der Code so dann auch unter Delphi funktioniert.

Du hast folgenden Code als Beispiel gepostet:

Delphi-Quellcode:

interface

function OpenThread(dwDesiredAccess: DWORD; bInheritHandle: BOOL; dwProcessId: DWORD): THandle; stdcall;

implementation

function OpenThread; external kernel32 name 'OpenThread';

Das Problem hier ist, das dies in meinen Augen eine Unsauberkeit des Delphi-Compilers ist. Dies sehen auch die Entwickler von Free Pascal so, weswegen sie dies nur im Delphi-kompatiblen Modus erlauben. Sowohl unter Delphi, als auch unter FPC (egal ob Modus ObjFPC oder Delphi) funktioniert folgender Code:

Delphi-Quellcode:

interface

function OpenThread(dwDesiredAccess: DWORD; bInheritedHandle: BOOl; dwProcessId: DWORD): THandle; stdcall; external kernel32 name 'OpenThread';

implementation

Hier stehen beide Angaben im Interface, was meiner Ansicht nach auch sauberer aussieht.

Und jetzt noch ein Tip am Rande: Unter Free Pascal findet sich die CreateToolHelp32SnapShot Funktion in der Unit jwatlhelp32.pas, die sich im Ordner %FPCDIR%\packages\winunits-jedi\src befindet (wobei %FPCDIR% z. B. "C:\lazarus\fpc\2.2.4" sein kann). Du brauchst den Pfad allerdings nicht mit angeben, da die Units in den Unterverzeichnissen von Packages alle in der Konfiguration von Free Pascal eingetragen sind (insofern sie für die jeweilige Plattform kompiliert wurden).
Allgemein finden sich - meines Wissens - fast alle WinAPI Funktionen in winunits-jedi. Ein Teil davon bzw die übrigen sind dann in packages/winunits-base oder rtl/win zu finden.

Gruß,
Sven

[Delphi-Laie]

Das war/ist mehr, als das kühnste Horoskop zu träumen bwz. zu prognostizieren wagte, tausend Dank(s), JamesTKirk!

So ungefähr kann ich auch alles nachvollziehen. Das wichtigste ist aber, daß ich auf die Unit „tlhelp32.pas“ bzw. auf die Verrenkungen, einzelne ihrer Funktionen zu extrahieren und woanders einzubinden, verzichten kann, wenn die mit Lazarus mitgelieferte Unit „jwatlhelp32.pas“ eine ähnliche oder sogar die gleiche Funktionalität liefert.

Bevor mir diese Informationen vorlagen, gelang es mir, die Unit „tlhelp32.pas“ mit dem o.g. Delphi-Compilerschalter fehlerfrei zu compilieren. Mit deren Funktionen wäre wohl auch ein Weiterarbeiten möglich gewesen, aber ich benutze natürlich lieber die Lazarus-Lieferpakete.

Zuguterletzt sind die in dieser Diskussion gespeicherten Kenntnisse hoffentlich auch für andere nützlich. Die 1:1-Mal-Eben-So-Portiert-Kompatibilität zwischen Delphi und Lazarus sieht in der Praxis eben doch ganz anders aus: Der Teufel steckt auch hier, wie bekanntlich (fast) überall, im Detail.

[JamesTKirk]

Schön, dass ich dir weiterhelfen konnte.

Möchtest du eigentlich an dem Programm, in dem du tlhelp32 benötigst, parallel mit Delphi und Lazarus arbeiten oder nur mit Lazarus?

Bei ersterem hätte ich noch zwei verschiedene Vorschläge, mit denen du dir dein Leben erleichtern könntest.

Gruß,
Sven

[Delphi-Laie]

Zitat von JamesTKirk:

Schön, dass ich dir weiterhelfen konnte.

Möchtest du eigentlich an dem Programm, in dem du tlhelp32 benötigst, parallel mit Delphi und Lazarus arbeiten oder nur mit Lazarus?

Bei ersterem hätte ich noch zwei verschiedene Vorschläge, mit denen du dir dein Leben erleichtern könntest.

Gruß,
Sven

Ich möchte mein hookgesteuertes 32-Bit-Programm, das außer mir wohl kaum jemand mag (bei mir leistet es tagtäglich treue und nützliche Dienste), nach 64 Bit portieren (für mein heißgeliebtes 64-Bit-Windows-XP, das Windows finde ich richtig großartig), und dazu kommt zur Zeit leider nur Lazarus infrage. Also, die 32-Bit-Version für Delphi liegt schon vor.

Aber mit Vorschlägen mußt Du trotzdem keinesfalls geizen, die können - wem auch immer - in Situationen helfen, die man vorher gar nicht ahnt.