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