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

[JamesTKirk]

Zitat von Delphi-Laie:

Also Du hattest recht: Die Lazarus-Unit „jwatlhelp32“ scheint in der 64-Bit-Version des Lazarus' (gibts auch eine 64-Bit-Version dieser Unit?) die Toolhelpfunktionen nicht zu unterstützen.

Inwiefern äußert sich das? Kompiliert alles? Funktioniert es nur zur Laufzeit nicht?

Zitat von Delphi-Laie:

Sooo schnell gebe ich allerdings nicht auf. Auf Dateinamensgleichheit geprüft (müßte aber stimmen, sonst gäbe es ja eine Fehlermeldung), und tatsächlich, auch unter meinem Windows XP 64 Bit heißt die angesprochene, angeforderte DLL „kernel32.dll“. Zur Sicherheit auch noch den Dependency Walker darübergejagt, doch auch die Funktionen in(nerhalb) der DLL schmücken sich inkonsequenterweise mit dem Zusatz (der Endung) „32“.

Kannst du mal bitte eine Liste der exportierten Namen deiner kernel32.dll, die hier verwendet werden, posten? Ich habe leider noch kein 64-Bit Windows, mit dem ich rumspielen könnte.

Zitat von Delphi-Laie:

Nun tauschte ich alle DWORD-Typdeklarationen in der „tlhelp32.pas“ mit „Int64“ aus. Auch das wird fehlerfrei compiliert und eingebunden. Doch die Toolhelpfunktionen scheinen immer noch nicht zu klappen, zu funktionieren, verfügbar zu sein, was auch immer. Es gibt keine Fehlermeldung, jedoch auch keine Funktionswirkung.

Nein, das ist meiner Meinung nach nicht das Problem. Unter Windows 64-Bit haben sich diese Strukturen nicht geändert (ich hab im MSDN nachgeschaut) und auch ein DWord ist und bleibt 32-Bit.

Zitat von Delphi-Laie:

Weißt Du oder weiß jemand anderes noch einen Rat, Toolhelpfunktionen unter Lazarus 64 Bit verfügbar zu machen?

Funktioniert es denn, wenn du deine Anwendung als 32-Bit Anwendung kompilierst?

Zitat von implementation:

1. DWord ist vorzeichenlos und Int64 vorzeichenbehaftet. Das 64bit-Pendant zu DWord ist QWord/LongWord/UInt64.

Unter Free Pascal sind das nur QWord und UInt64, wobei letzteres ein Alias auf QWord ist. LongWord ist ganz falsch, da dieser auch unter 64-Bit ein 32-Bit unsigned ist.

Zitat von implementation:

2. Wie schon geschrieben wurde, sind sehr viele Assemblerblöcke drin, die eben alle für 32 bit geschrieben sind. Die müsste man alle nochmal umschreiben, damit alles vernünftig liefe.

Und direkt danach habe ich geschrieben, dass die Assemblerblöcke in der jwatlhelp32 (falls du diese meinst) alle nicht verwendet werden, da die Units mit deaktivierten DYNAMIC_LINK Define kompiliert werden und stattdessen statisches Linken (mit "external (...)") verwendet wird.

Zitat von implementation:

Zitat von Delphi-Laie:

Weißt Du oder weiß jemand anderes noch einen Rat, Toolhelpfunktionen unter Lazarus 64 Bit verfügbar zu machen?

Direkte Nutzung der Win32-API (ja, die heißt immer noch so , sagt zumindest das Windows SDK).
Das macht zwar die Portierung auf andere Plattformen unmöglich, aber das scheint ja so wie so keine Rolle zu spielen.

Ähm... was anderes macht Delphi-Laie ja gerade nicht... nur dass er schon vorgefertigte Importunits verwendet...

Gruß,
Sven

[implementation]

Zitat von JamesTKirk:

Zitat von implementation:

Zitat von Delphi-Laie:

Weißt Du oder weiß jemand anderes noch einen Rat, Toolhelpfunktionen unter Lazarus 64 Bit verfügbar zu machen?

Direkte Nutzung der Win32-API (ja, die heißt immer noch so , sagt zumindest das Windows SDK).
Das macht zwar die Portierung auf andere Plattformen unmöglich, aber das scheint ja so wie so keine Rolle zu spielen.

Ähm... was anderes macht Delphi-Laie ja gerade nicht... nur dass er schon vorgefertigte Importunits verwendet...

Ähm ja, damit waren andere OS (Linux, Mac, BSD, ...) oder vollkommen unterschiedliche Architekturen gemeint. AMD64/Intel64 ist ja nur eine Erweiterung für die i386-Plattform.

[JamesTKirk]

Zitat von implementation:

Zitat von JamesTKirk:

Zitat von implementation:

Zitat von Delphi-Laie:

Weißt Du oder weiß jemand anderes noch einen Rat, Toolhelpfunktionen unter Lazarus 64 Bit verfügbar zu machen?

Direkte Nutzung der Win32-API (ja, die heißt immer noch so , sagt zumindest das Windows SDK).
Das macht zwar die Portierung auf andere Plattformen unmöglich, aber das scheint ja so wie so keine Rolle zu spielen.

Ähm... was anderes macht Delphi-Laie ja gerade nicht... nur dass er schon vorgefertigte Importunits verwendet...

Ähm ja, damit waren andere OS (Linux, Mac, BSD, ...) oder vollkommen unterschiedliche Architekturen gemeint. AMD64/Intel64 ist ja nur eine Erweiterung für die i386-Plattform.

So meinst du das... darauf bin ich gar nicht gekommen, da Delphi-Laie ja eigentlich klar gestellt hat, dass es ihm erstmal nur um Windows 64-Bit geht, vor allem weil er das Programm ja nur für den persönlichen Gebrauch zu benötigen scheint.

Gruß,
Sven

[Delphi-Laie]

Tausend Dank für Euer Engagement!

Nun, die Sache ließ mir keine Ruhe. Hier das vorläufige Ergebnis:
Ich benutze die beiden Funktionen (die erste stammt weitgehend von Luckie(s Programm „WinInfo“)) zur Ermittlung des Exe-Dateinamens eines Vordergrundfensters:

Delphi-Quellcode:

  function GetExeStringFromProcID_Processsnapshot(PID:DWORD):string;
  var hProcSnap:THandle;
  pe32:TProcessEntry32;
  begin
  hProcSnap:=CreateToolHelp32SnapShot(TH32CS_SNAPPROCESS, 0);
  if hProcSnap<>INVALID_HANDLE_VALUE then
    begin
    pe32.dwSize:=SizeOf(TProcessEntry32);
    if Process32First(hProcSnap,pe32) then
      begin
      if pe32.th32ProcessID=PID then
        begin
        result:=ExtractFileName(pe32.szExeFile);//ohne Extraktion wird unter ME (jedes 9.x?) der gesamte Pfad zurückgeliefert
        CloseHandle(hProcSnap);
        exit
        end;
      while Process32Next(hProcSnap,pe32)do if pe32.th32ProcessID=PID then
        begin
        result:=ExtractFileName(pe32.szExeFile);
        break
        end
      end;
    CloseHandle(hProcSnap)
    end;
  end;

und (Luckies obige Funktion diente auch hier als Vorlage)

Delphi-Quellcode:

  function GetExeStringFromProcID_Modulsnapshot(PID:DWORD):string; //stdcall;
  var hModuleSnap:THandle;
  me:TModuleEntry32;
  begin
  hModuleSnap:=CreateToolhelp32Snapshot(TH32CS_SNAPMODULE,PID);
  if hModuleSnap<>INVALID_HANDLE_VALUE then
    begin
    me.dwSize:=SizeOf(TModuleEntry32);
    if Module32First(hModuleSnap,me) then
      begin
      if uppercase(ExtractFileExt(me.szExePath))='.EXE' then
        begin
        result:=ExtractFileName(me.szExePath);
        CloseHandle(hModuleSnap);
        exit
        end;
      while Module32Next(hModuleSnap,me) do if lowercase(ExtractFileExt(me.szExePath))='.exe' then
        begin
        result:=ExtractFileName(me.szExePath);
        break
        end
      end;
    CloseHandle(hModuleSnap)
    end
  end;

Benutze ich die unit „jwatlhelp32“, scheinen sie überhaupt nicht zu funktionieren. In erster Funktion sind alle „32.th32ProcessID“ gleich 0, was natürlich falsch ist (nur der Systemprozeß hat die Nr. 0). Die „me.szExePath“ liefern verstümelte Resultate, z.B. „er.exe“ beim „explorer.exe“ oder „rus.exe“ bei „lazarus.exe“.

Unter Windows 32 Bit, mit Lazarus 32 Bit compiliert, funktioniert aber alles tadellos! Die Funktion „CreateToolHelp32SnapShot“ funktioniert allerdings auch in der 32-Bit-Version unter Windows 64 Bit, wie ich anhand meines Programmes „Prozesse“ (auch hier im Forum abgelegt) feststellen konnte.

Setze ich Lazarus (64 Bit) die unit „tlhelp32“ von Delphi 2.0 vor, scheint jetzt wenigstens der Modulschnappschuß zu funktionieren (weiß nicht, ob ich vorhin die gleiche Unit oder doch „jwatlhelp32“ benutzte, der Prozeßschnappschuß immer noch nicht. Jedenfalls sind die Ergebnisse völlig inkonsistent, so daß ich allmählich einen Fehler im Free-Pascal-Compiler vermute.

Alles Rumgemache, die Variablentypen „DWORD“ und auch „THandle“ mit „Int64“ auszutauschen, auch, einen „Int64“, auch als Konstante schon an die Funktionen zu übergeben, brachten leider auch keinen Erfolg.

Zum Glück funktioneren die Hooks unter Windows 64 Bit. Diese Hooks sind allerdings der Grund, daß ich kein 32-Bit-Compilat unter Windows 64 Bit benutzen kann.

[implementation]

Zitat von Delphi-Laie:

Setze ich Lazarus (64 Bit) die unit „tlhelp32“ von Delphi 2.0 vor, scheint jetzt wenigstens der Modulschnappschuß zu funktionieren (weiß nicht, ob ich vorhin die gleiche Unit oder doch „tlhelp32“ benutzte, der Prozeßschnappschuß immer noch nicht. Jedenfalls sind die Ergebnisse völlig inkonsistent, so daß ich allmählich einen Fehler im Free-Pascal-Compiler vermute.

Was bitte hat der Compiler denn mit den ToolHelps zu tun? Worin liegt deine Vermutung? Vielleicht lässt sich der Bug (wenn ein solcher existiert) irgendwie umgehen.

[Delphi-Laie]

Zitat von implementation:

Zitat von Delphi-Laie:

Setze ich Lazarus (64 Bit) die unit „tlhelp32“ von Delphi 2.0 vor, scheint jetzt wenigstens der Modulschnappschuß zu funktionieren (weiß nicht, ob ich vorhin die gleiche Unit oder doch „tlhelp32“ benutzte, der Prozeßschnappschuß immer noch nicht. Jedenfalls sind die Ergebnisse völlig inkonsistent, so daß ich allmählich einen Fehler im Free-Pascal-Compiler vermute.

Was bitte hat der Compiler denn mit den ToolHelps zu tun? Worin liegt deine Vermutung? Vielleicht lässt sich der Bug (wenn ein solcher existiert) irgendwie umgehen.

Ich meinte natürlich:

Setze ich Lazarus (64 Bit) die unit „tlhelp32“ von Delphi 2.0 vor, scheint jetzt wenigstens der Modulschnappschuß zu funktionieren (weiß nicht, ob ich vorhin die gleiche Unit oder doch „jwatlhelp32“ benutzte), der Prozeßschnappschuß immer noch nicht. Jedenfalls sind die Ergebnisse völlig inkonsistent, so daß ich allmählich einen Fehler im Free-Pascal-Compiler vermute.

und korrigierte es weiter oben schon.

Ja, „eigentlich“ werden die externen Funktionen aus der DLL ja nur aufgerufen, also ist der Compiler nicht so recht als Schuldiger einzugrenzen. Selbst, wenn die DLL nur 32 Bit ist (die vielen „32“, im DLL-Namen und ihre immanenten Funktionen suggerieren das ja), dann müßten sie doch erst recht funktionieren.

Ich denke mir das alles nicht aus. Inskonsitente Ergebnisse sind schwer zu beschreiben, deshalb auch eine gewisse Langatmigkeit.

[JamesTKirk]

Ich sollte echt mal ein 64-Bit Windows installieren... ich melde mich dann im Laufe der Woche wieder, sobald ich das geschafft hab und du dein Problem nicht eh schon gelöst hast.
So wird das nämlich nichts.

Gruß,
Sven

[Delphi-Laie]

Zitat von JamesTKirk:

Ich sollte echt mal ein 64-Bit Windows installieren... ich melde mich dann im Laufe der Woche wieder, sobald ich das geschafft hab und du dein Problem nicht eh schon gelöst hast.
So wird das nämlich nichts.

Gruß,
Sven

Wenn Du dafür die Zeit hast?! Freuen würde es mich natürlich, auch wenn ich mir keine allzugroßen Hoffnungen mehr mache. Ich will nicht voreilig eine Schuld zuweisen, aber inzwischen steht für mich ziemlich fest, daß Lazarus 64 Bit eine „Macke“ hat. Derselbe Code funktioniert nämlich in Delphis und Lazarus' (32 Bit) Compilaten tadellos.

Die Lazarus-64-Bit-Version, die ich habe, scheint nicht einmal einen integrierten Debugger zu besitzen (32-Bit-Lazarus hat einen), damit ist es natürlich gänzlich aussichtslos. Ich behalf mich mit Piepton- und Messageboxausgaben, und davon wurde ich immerhin so schlau, daß es ein Process32First gar nicht gibt (heute nachmittag gab es sogar mehrere Process32Next, doch es ergab sich als Process-ID immer nur die Null).

Ich band sogar nur die relevanten Codeteile der tlhelp32-Unit in meine beiden Programmdateien (DLL und Hostprogramm) ein, doch ein Erfolgsfortschritt will sich auch damit nicht einstellen.

Welch ein Glück, der Modulschnappschuß scheint zu funktionieren. So richtig funktioniert auch nur der eine der beiden Hooks (der Shellhook), allerdings der, den ich ohnehin bevorzuge.

Auch viele andere Abstriche mußte ich machen, aber mein Programm läuft nunmehr „gerade so“, daß es noch erträglich ist, aber in der gewünschten Grundfunktionalität: Ich öffne irgendein (Explorer- oder anderes Programm-)Fenster mit skalierbaren Dateianzeigelisten und - flupp, wie von Zauberhand - haben die Spalten automatisch die richtige Breite; etwas, was die Büroklammerntanzprogrammierer bis heute nicht hinbekamen (korrekterweise wohl eher: nicht programmieren durften, denn ich bediene mich auch nur der mitgelieferten Bordmittel). Ich werde an dem 64-Bit-Programm deshalb auch keine Zeit mehr ver(sch)wenden, es sei denn, ich bekomme noch irgendwelche interessanten Anregungen oder eine neue Lazarus-64-Bit-Version.

Es kann aber durchaus sein, daß ich mein Programm „Prozesse“ nach Lazarus und dann natürlich auch zu 64 Bit migrieren werde - auch wenn das beileibe nicht so einfach ist, wie von jemandem in diesem Forum behauptet - den Beweis, daß mein o.a. Vermutung richtig ist, hätte ich nämlich selbst gern.

Spannend und zukunftsträchtig („zukunftssicher“) sind 64 Bit allemal, nicht nur die aus Redmond!

[Delphi-Laie]

Mein gestriger Verdacht hat sich erhärtet, ja eigentlich schon bestätigt.

Um das festzustellen, bediente ich mich auf die Schnelle Luckies Programmes „WinInfo“, daß ich mal eben so nach Lazarus portierte (wenn alle Portierungen so reibungslos wären!). Lediglich die beiden Vergleiche „= true“ in der Funktion „GetExeStringFromProcID“ entfernte ich, und dieses Entfernen hat seine Richtigkeit, wie er mir schon vor Jahren bestätigte (ich zettelte dazu sogar mal eine Diskussion an, die sehr lebhaft wurde).

Kurzum, erwartungsgemäß bleibt das Feld „Anwendung“, das sich dieser o.g. Funktion bedient (die wiederum kernel32-Funktionen benutzt) und den Exe-Dateinamen ausspucken soll, in der 64-Bit-Version leer. Das 32-Bit-Compilat funktioniert jedoch unter beiden Umgebungen.

Merkwürdigerweise bekam ich die das Programm mit eingebundener Unit „jwatlhelp32“ weder unter Lazarus 32 noch 64 Bit compiliert - die IDEs fanden sie wohl nicht. Nur mit tlhelp32 ließ es sich kompilieren.

Ich lege zum schnellen Ausprobieren (wen es interessiert) den Quelltext (der ja ursprünglich von Luckie stammt, das sei hier noch einmal wiederholt) und die beiden Compilate als Komprimat hier ab.

Also, trotz Einbindung externer DLL-Funktionen, für die der Compiler auf den ersten Blick ja nicht verantwortlich ist, stimmt irgendetwas mit dem 64-Bit-Lazarus nicht.

Viele Grüße

Delphi-Laie

Unit jwatlhelp32 wird doch gefunden, war ein Schreibfehler (verdammt schmales kleines L!) meinerseite im Quelltext. Funktioniert aber, wie schon hier in dieser Diskussion vermutet, auch nicht.

[implementation]

Das ist keine Macke, sondern das liegt einfach daran, dass tlhelp32 für 32 Bit geschrieben ist.
Wenn du eine 64-Bit-Version davon gefunden hast, und es immer noch nicht läuft, dann solltest du dich wundern.
Aber 32 und 64 Bit sind nunmal unterschiedlich. Da kannste nix machen.

Bist du dir sicher, dass die Daten nicht heil bei der DLL ankommen? Vielleicht liegt auch in der der Fehler. Oder ist es gar eine 32-Bit-DLL?