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

[JamesTKirk]

Zitat von Delphi-Laie:

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.

Hmm... ich hab mir den Code in der jwatlhelp32 mal angeschaut... 64-Bit könnte hier kritisch werden, da dort (32-Bit) Assembler-Routinen verwendet werden, um die eigentlichen Methoden anzuspringen. Ich habe zwar keine Ahnung, warum die Jedis das gemacht haben, aber auf jeden Fall ist das äußerst hinderlich

Mal schauen, dass ich das mal an die FPC Entwickler melde...

Zitat von Delphi-Laie:

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.

Diese beiden Vorschläge hätte ich:

Binde die (jwa)tlhelp32 Units folgendermaßen ein:

Delphi-Quellcode:

uses
  // andere Units
{$ifdef fpc}
  jwatlhelp32,
{$else}
  tlhelp32,
{$endif}
  // andere Units

Die andere Möglichkeit ist es die Units im Verzeichnis %FPCDIR%\packages\winunits-jedi\src in den Unit-Suchpfad von Delphi einzutragen und einfach die jwatlhelp32 Unit sowohl in Delphi, als auch in Free Pascal zu verwenden. Eventuell solltest du dann allerdings noch deinen DCU-Ausgabepfad anpassen oder du kopierst den jedi Ordner woanders hin, damit der Ordner nicht mit DCUs vollgestopft wird. So weit ich das sehe sollten die jwa* Units alle Delphi kompatibel sein.

Dadurch kannst du den Code (im Idealfall) sowohl unter Delphi, als auch unter Free Pascal verwenden.

EDIT: ok... hab nochmal genauer nachgeschaut. In den Includes von Free Pascal ist das DYNAMIC_LINK Define deaktiviert, das dafür sorgt, dass diese Assembleroutinen verwendet werden... also ist alles im grünen Bereich (das statische Linken mit "external" wird verwendet) und 64-Bit sollte kein Problem darstellen

EDIT2: doppeltes Wort entfernt -.-

Gruß,
Sven

[Delphi-Laie]

Herzlichen Dank!

Mit bedingten Compilierungen bzw. Compilerschaltern dafür innerhalb des uses-Befehles hatte ich schon mit Delphi bisher nur schlechte Erfahrungen. Schon bei einem anderen Programm probierte ich nämlich erfolglos, abhängig von der Delphiversion, bestimmte units nur optional einbinden. Auch mit Lazarus will es nicht funktionieren. Alternativ jeweils den kompletten uses-Befehl in die Compilerschalter einzubinden (müßte doch eigentlich auch möglich sein?!), funktioniert in meiner DLL-Quelltextprojektdatei auch nicht - beißt sich das evtl. mit dem Delphi-Modus, den ich vorher deklarieren muß, damit es keinen Fehler gibt? Mein unter WindowsXP(64) laufendes Lazarus compilierte die im selben Verzeichnis befindliche tlhelp32.pas (diese natürlich im Delphi-Modus) erst, nachdem ich die Schalter und auch jwathelp32 aus dem uses-Befehl meiner DLL-Quelltextdatei entfernte (auskommentierte). Es handelt sich ohnehin um ein reines Windowsprogramm, warum also solche Verrenkungen, die wohl eine gewisse Plattformunabhängigkeit erreichen sollen? Ich glaube kaum, daß andere Betriebsprogramme die gleichen Hooks verwenden, ja, ich weiß nicht einmal, ob die überhaupt welche oder ersatzweise ähnliche Funktionalitäten zur Verfügung stellen.

Unter 32- und unter 64-Bit-Windows-Lazarus konnte ich immerhin die DLL-Quelltexte erfolgreich compilieren und bin damit schon weiter, als ich es zu hoffen wagte. Das 32-Bit-Compilat funktioniert in Zusammenarbeit mit dem in Delphi geschriebenen 32-Bit-Hostprogramm sogar schon (jippie!), und das immerhin zur Zufriedenheit: Die Hooks werden eingeschaltet und lösen die gewünschten Aktionen aus; es kommt von der Funktionalität her knapp an das Delphi-Compilat heran. Zwei kleine Dinge funktionieren nicht, aber die sind beide nicht(s) weltbewegend(es).

Nunmehr stehe ich vor der Aufgabe, das Hostprogramm 64 Bit mit Lazarus zu schreiben, denn das 32-Bit-Delphi-Compilat des Hostprogrammes verweigert, wie zu erwarten, die Zusammenarbeit mit der 64-Bit-DLL (es findet die DLL nicht einmal, obwohl im selben Verzeichnis liegend). Mit einem einfach Umbenennen der dpr- in eine lpr-Datei ist es natürlich beileibe nicht getan. Entweder funktioniert das dann mit einer DLL, in die units tlhelp32- und/oder einer tlhelp32 eingebunden werden, oder eben nicht. Ich lasse mich überraschen.

Dir nochmals unzählige Danks!

[JamesTKirk]

Zitat von Delphi-Laie:

Alternativ jeweils den kompletten uses-Befehl in die Compilerschalter einzubinden (müßte doch eigentlich auch möglich sein?!), funktioniert in meiner DLL-Quelltextprojektdatei auch nicht - beißt sich das evtl. mit dem Delphi-Modus, den ich vorher deklarieren muß, damit es keinen Fehler gibt? Mein unter WindowsXP(64) laufendes Lazarus compilierte die im selben Verzeichnis befindliche tlhelp32.pas (diese natürlich im Delphi-Modus) erst, nachdem ich die Schalter und auch jwathelp32 aus dem uses-Befehl meiner DLL-Quelltextdatei entfernte (auskommentierte).

Würdest/könntest du mir bitte den Code zeigen, den du ausprobiert hast? Vielleicht kann ich dir helfen und für die Zukunft das Problem lösen.

Zitat von Delphi-Laie:

Es handelt sich ohnehin um ein reines Windowsprogramm, warum also solche Verrenkungen, die wohl eine gewisse Plattformunabhängigkeit erreichen sollen? Ich glaube kaum, daß andere Betriebsprogramme die gleichen Hooks verwenden, ja, ich weiß nicht einmal, ob die überhaupt welche oder ähnliche Funktionalitäten zur Verfügung stellen.

Das war jetzt auch nicht für Cross-Plattform gedacht - wobei ich Defines da äußerst gerne verwende - sondern, um die parallele Nutzung des Codes mit Delphi und FPC zu ermöglichen (wobei das ja, wie oben geschrieben, nur eine der beiden Möglichkeiten ist). Da sich Units zwischen Delphi und FPC unterscheiden können, ist es manchmal angebracht da einige solcher Verrenkungen zu betreiben, wenn man mit beiden Compilern arbeiten möchte.

Zitat von Delphi-Laie:

Nunmehr stehe ich vor der Aufgabe, das Hostprogramm 64 Bit mit Lazarus zu schreiben, denn das 32-Bit-Delphi-Compilat des Hostprogrammes verweigert, wie zu erwarten, die Zusammenarbeit mit der 64-Bit-DLL (es findet die DLL nicht einmal, obwohl im selben Verzeichnis liegend).

Dass die DLL nicht gefunden wird, ist meiner Ansicht nach sogar eine sehr gute Lösung (von Windows - ich weiß aus dem Stegreif nicht, ob Linux da ähnlich vorgeht), da man so nicht auf die dumme Idee kommen kann eine 64-Bit DLL in einem 32-Bit Prozess zu nutzen oder umgekehrt. Dies geht nämlich spätestens bei der Annahme SizeOf(Integer)=SizeOf(Pointer) in die Hose

Zitat von Delphi-Laie:

Mit einem einfach Umbenennen der dpr- in eine lpr-Datei ist es natürlich beileibe nicht getan. Entweder funktioniert das dann mit einer DLL, in die units tlhelp32- und/oder einer tlhelp32 eingebunden werden, oder eben nicht. Ich lasse mich überraschen.

Dann noch viel Erfolg beim Umstellen und ärgere dich nicht, wenn was nicht auf Anhieb funktioniert... dafür ist ja dann das Forum da

Gruß,
Sven

[Delphi-Laie]

Zitat von JamesTKirk:

Würdest/könntest du mir bitte den Code zeigen, den du ausprobiert hast? Vielleicht kann ich dir helfen und für die Zukunft das Problem lösen.

Da will es aber einer ganz genau wissen...also bitteschön, weder

Delphi-Quellcode:

{$mode DELPHI}{$H+}

uses Windows,
     Classes,
     
    {$ifdef fpc}
     jwatlhelp32,
     
     {$else}
     tlhelp32,
     
     {$endif}
     
     SysUtils;

noch

Delphi-Quellcode:

{$mode DELPHI}{$H+}

{$ifdef fpc}
uses Windows,
     Classes,
     jwatlhelp32,
     SysUtils;

{$else}
uses Windows,
     Classes,
     tlhelp32,
     SysUtils;

{$endif}

compilieren die tlhelp32-unit, erst, wenn ich die explizit aufrufe und damit das Compilieren erzwinge. Übrigens, {$mode DELPHI}{$H+} scheint auch ohne {$H+} zu funktioneren, also nur {$mode DELPHI} bzw. {$mode DELPHI}//{$H+}

Zitat von JamesTKirk:

Zitat von Delphi-Laie:

Es handelt sich ohnehin um ein reines Windowsprogramm, warum also solche Verrenkungen, die wohl eine gewisse Plattformunabhängigkeit erreichen sollen? Ich glaube kaum, daß andere Betriebsprogramme die gleichen Hooks verwenden, ja, ich weiß nicht einmal, ob die überhaupt welche oder ähnliche Funktionalitäten zur Verfügung stellen.

Das war jetzt auch nicht für Cross-Plattform gedacht - wobei ich Defines da äußerst gerne verwende - sondern, um die parallele Nutzung des Codes mit Delphi und FPC zu ermöglichen (wobei das ja, wie oben geschrieben, nur eine der beiden Möglichkeiten ist). Da sich Units zwischen Delphi und FPC unterscheiden können, ist es manchmal angebracht da einige solcher Verrenkungen zu betreiben, wenn man mit beiden Compilern arbeiten möchte.

Delphi schreibe ich allmählich ab, und Delphi 64 Bit ohnehin. Falls es noch kommen sollte, wann? Dann wird der Zeitpunkt, das noch kostendeckend, geschweige denn profitabel am Markt abzusetzen, längst vorbei sein. Freie Software war schon manches Mal schneller, und so wird es auch hier wohl sein. Aber das ist ein anderes Thema und wurde hier schon zuhauf diskutiert.

Zitat von JamesTKirk:

Zitat von Delphi-Laie:

Nunmehr stehe ich vor der Aufgabe, das Hostprogramm 64 Bit mit Lazarus zu schreiben, denn das 32-Bit-Delphi-Compilat des Hostprogrammes verweigert, wie zu erwarten, die Zusammenarbeit mit der 64-Bit-DLL (es findet die DLL nicht einmal, obwohl im selben Verzeichnis liegend).

Dass die DLL nicht gefunden wird, ist meiner Ansicht nach sogar eine sehr gute Lösung (von Windows - ich weiß aus dem Stegreif nicht, ob Linux da ähnlich vorgeht), da man so nicht auf die dumme Idee kommen kann eine 64-Bit DLL in einem 32-Bit Prozess zu nutzen oder umgekehrt. Dies geht nämlich spätestens bei der Annahme SizeOf(Integer)=SizeOf(Pointer) in die Hose

Das ändert aber nichts daran, daß die Fehlermeldung falsch und damit irritierend ist. Die DLL im selben Verzeichnis muß gefunden werden. Vielmehr dürften Kompatibilitätsprüfungen negativ ausfallen.

Zitat von JamesTKirk:

Zitat von Delphi-Laie:

Mit einem einfach Umbenennen der dpr- in eine lpr-Datei ist es natürlich beileibe nicht getan. Entweder funktioniert das dann mit einer DLL, in die units tlhelp32- und/oder einer tlhelp32 eingebunden werden, oder eben nicht. Ich lasse mich überraschen.

Dann noch viel Erfolg beim Umstellen und ärgere dich nicht, wenn was nicht auf Anhieb funktioniert... dafür ist ja dann das Forum da

Naja, ich kann mich durchaus noch an einen Fall erinnern, bei dem die Butter zu dick aufgetragen wurde (öffentlich versprochene Hilfe kam nicht, selbst auf Nachfrage per persönlicher Mitteilung nicht), aber das war wirklich die Ausnahme. Letztlich konnte ich mit Hilfe der Foren und auch der im Internet verstreuten sog. Tutorials alle Probleme entweder lösen oder ziemlich treffsicher (?) als unlösbar abhaken. Dafür gebührt auch diesem Forum mein Dank, und speziell natürlich an Dich!

[JamesTKirk]

Delphi-Quellcode:

{$mode DELPHI}{$H+}

uses Windows,
     Classes,
     
    {$ifdef fpc}
     jwatlhelp32,
     
     {$else}
     tlhelp32,
     
     {$endif}
     
     SysUtils;

Delphi-Quellcode:

{$mode DELPHI}{$H+}

{$ifdef fpc}
uses Windows,
     Classes,
     jwatlhelp32,
     SysUtils;

{$else}
uses Windows,
     Classes,
     tlhelp32,
     SysUtils;

{$endif}

Hmm... beide Varianten müssten zumindest mit Free Pascal funktionieren... Unter Delphi sollten sie auch komplieren, wenn du den Mode-Schalter folgendermaßen ergänzt:

Delphi-Quellcode:

{$ifdef fpc}
  {$mode delphi}{$H+}
{$endif}

Das liegt daran, dass Delphi den Modeswitch nicht kennt und im Gegensatz zu Free Pascal unbekannte Switches nicht ignoriert... Nach allem was ich weiß und verwende, sollte es dann funktionieren... Wenn nicht bleibt mir nur noch ein erstauntes "WTH?! ".

Zitat von Delphi-Laie:

compilieren die tlhelp32-unit, erst, wenn ich die explizit aufrufe und damit das Compilieren erzwinge. Übrigens, {$mode DELPHI}{$H+} scheint auch ohne {$H+} zu funktioneren, also nur {$mode DELPHI} bzw. {$mode DELPHI}//{$H+}

Der {$H+} Switch wurde irgendwann für den Delphi-Modus als Standard übernommen, aber ich weiß nicht ab wann dies der Fall war... vor 2.4.0 aber auf jeden Fall nicht. Der Switch dient übrigens dazu, dass der Datentyp String als Alias für AnsiString gilt, statt für ShortString. Letzteres (also {$H-}) ist der Standard für alle Modi außer Delphi.

Zitat von Delphi-Laie:

Delphi schreibe ich allmählich ab, und Delphi 64 Bit ohnehin. Falls es noch kommen sollte, wann? Dann wird der Zeitpunkt, das noch kostendeckend, geschweige denn profitabel am Markt abzusetzen, längst vorbei sein. Freie Software war schon manches Mal schneller, und so wird es auch hier wohl sein. Aber das ist ein anderes Thema und wurde hier schon zuhauf diskutiert.

Ich selbst verwende Delphi nur noch in der Arbeit und ansonsten achte ich auf Delphi-Kompatibilität nur, wenn ich Source Code veröffentliche, den auch Delphi-Benutzer verwenden könnten.

Zitat von Delphi-Laie:

Das ändert aber nichts daran, daß die Fehlermeldung falsch und damit irritierend ist. Die DLL im selben Verzeichnis muß gefunden werden. Vielmehr dürften Kompatibilitätsprüfungen negativ ausfallen.

Du sagst also, dass beim Laden einer 64-Bit DLL in einem 32-Bit Prozess mit LoadLibrary GetLastError einen Fehlercode zurückliefert, der besagt, dass die Datei nicht gefunden wurde? Gut... das ist in der Tat irreführend und Microsoft hätte das besser implementieren können. Ich denke, dass der Loader die DLL schon findet, nur dann erkennt er, dass es sich um eine 64-Bit DLL handelt und gibt dummerweise ein "File not found" zurück... Ich kann es leider nicht austesten, da ich kein 64-Bit Windows zur Hand habe... mein Windows 7 ist 32-Bit und die VM mit Windows Server 2008 R2 x64 (legal über Universität erworben ) muss ich erst noch aufsetzen...

Gruß,
Sven

[Delphi-Laie]

Zitat von JamesTKirk:

Hmm... beide Varianten müssten zumindest mit Free Pascal funktionieren... Unter Delphi sollten sie auch komplieren, wenn du den Mode-Schalter folgendermaßen ergänzt:

Delphi-Quellcode:

{$ifdef fpc}
  {$mode delphi}{$H+}
{$endif}

Fehlt da nicht noch irgendetwas? Zwischen ifdef und endif ist nur ein Schalter gesetzt, der für Lazarus relevant ist, jedoch kein „echter“ Quelltext.

Zitat von JamesTKirk:

Das liegt daran, dass Delphi den Modeswitch nicht kennt und im Gegensatz zu Free Pascal unbekannte Switches nicht ignoriert... Nach allem was ich weiß und verwende, sollte es dann funktionieren... Wenn nicht bleibt mir nur noch ein erstauntes "WTH?! ".

Wenn Delphi den Modeswitch nicht kennt, was soll es denn damit anfangen, wenn es das nicht ignoriert? Compilerfehler?

Eine Kompatibilität bezüglich Lazarus und Delphi reizt mich durchaus auch, aber ich verbeiße mich nicht darin.

Auf ein animiertes TrayIcon (sehr komfortabel und ergonomisch, eben lässig) werde ich aber verzichten müssen, weil das die TTrayIcon-Komponente in Lazarus nicht kennt - vielleicht wird die ja noch nachgerüstet. Ich kenne das noch von CoolTrayIcon, und erstaunlicherweise hat auch die Delphi-TTrayIcon-Komponente (oder meinetwegen auch -Klasse) diese Königsdisziplin-Funktion(alität) aufzuweisen.

Wenn ich nicht weiterkomme oder fertigbin, melde ich mich wieder, dann im ersten Fall hier, im anderen Falle im Thread, wo ich schon die 32-Bit-Variante vorstellte; Dich werde ich dann persönlich informieren.

Nochmals allerbesten Dank!

[JamesTKirk]

Zitat von Delphi-Laie:

Fehlt da nicht noch irgendetwas? Zwischen ifdef und endif ist nur ein Schalter gesetzt, der für Lazarus relevant ist, jedoch kein „echter“ Quelltext.

Stell dir ifdefs einfach nur als Preprozessorkennzeichnungen vor, die vor dem Kompilieren durchgegangen werden. Alles was in einem aktiven ifdef drinsteht wird vom Compiler "bearbeitet", alles andere wird ignoriert. Und für den Compiler ist {$mode ...} ein "echter Quelltext".

Zitat von Delphi-Laie:

Wenn Delphi den Modeswitch nicht kennt, was soll es denn damit anfangen, wenn es das nicht ignoriert? Compilerfehler?

Schneller Test mit Delphi 6 (bin an der Arbeit) ergibt:

Code:

Fehler: Ungültige Compileranweisung: 'mode'

Free Pascal ist da freizügiger, weil man ja nicht weiß, auf was für Ideen (bzgl. Compilerswitches) die Jungs von Borland/CodeGear/Embarcadero noch so kommen...

Zitat von Delphi-Laie:

Auf ein animiertes TrayIcon (sehr komfortabel und ergonomisch, eben lässig) werde ich aber verzichten müssen, weil das die TTrayIcon-Komponente in Lazarus nicht kennt - vielleicht wird die ja noch nachgerüstet. Ich kenne das noch von CoolTrayIcon, und erstaunlicherweise hat auch die Delphi-TTrayIcon-Komponente (oder meinetwegen auch -Klasse) diese Königsdisziplin-Funktion(alität) aufzuweisen.

Ich glaube das Problem ist, dass dies nicht wirklich Cross-Plattform möglich ist... genau kann ich's dir jedoch nicht sagen, da ich mich noch nicht mit Trayicons mit Lazarus beschäftigt hab (mein Window Manager unter Linux hat nicht mal die Möglichkeit Trayicons anzuzeigen ).

Gruß,
Sven

[Delphi-Laie]

Danke!

Jetzt - auf einmal - ist mir der Schalter für den FP-Compiler klar.

Ich muß auch ein wenig um Nachsicht bitten, denn ich irrte mich. Compilerschalter in der uses-Anweisung in Delphi benutzte ich doch schon erfolgreich, wie meine Recherche ergab.

Was die TrayIcons unter Lazarus anbetrifft, schaue bitte bei Interesse hier.

Ganz klar ist mir das dort zwar noch nicht, aber ich kämpfe mich voran. Warum ausgerechnet die mit Delphi gleichnamige Klasse mit Delphi inkompatibel sein soll, verschließt sich mir. Auch gelang es mir nicht, ein Objekt der (angeblich) delphikompatiblen Klasse Systrayicon zu erzeugen, weil ich nicht mal die genaue Typbezeichnung kenne (SysTrayIcon, was dort steht, funktioniert jedenfalls nicht, auch nicht als TSysTrayIcon). Benötigt man dafür mal wieder eine spezielle Unit, die dort nicht steht, analog jwatlhelp32, die mir auch unbekannt war? Und welchen Sinn soll eine nichtvisuelle TrayIcon-Klasse haben?! Egal, das sind nur rhetorische Fragen, mit TTrayIcon mache ich gerade herum, das funktioniert wenigstens. Die Delphikompatibilität behalte ich weiterhin im Auge, aber sie ist (für mich) nicht zwingend.

[Delphi-Laie]

Grüezi!

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.

So schnell gebe ich naütürlich nicht auf. Lazarus die Unit „tlhelp32.pas“, also in Quelltextversion (die simpelste von Delphi 2.0, da sind alle für mich relevanten, entscheidenden Funktionen schon enthalten) untergeschoben, wird auch fehlerfrei compiliert und eingebunden, also die Exe wird erstellt. Wiederum sind jedoch keine Toolhelpfunktionen verfügbar.

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

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.

Nunmehr bin ich mit meinem Latein, äh, Lazarus allmählich am Ende.

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

Immer und immer wieder dieser Scheibenkleister (Übergangsprobleme), wenn in der Computerbranche Standards wechseln.

Gruß Delphi-Laie

[implementation]

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

... ist auch bei Vista und 7 so. Sehr verwirrend.

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.

1. DWord ist vorzeichenlos und Int64 vorzeichenbehaftet. Das 64bit-Pendant zu DWord ist QWord/UInt64.
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.

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.

[edit]LongWord oben entfernt. Ist mir so dazwischengerutscht. Danke an JamesTKirk für den Hinweis ;D[/edit]