32-Bit-Programm soll 32- und 64-Bit-OS erkennen

[Delphi-Laie]

Das mit der Environment-Variable erschien mir schon optimal, aber dann wurde die Idee hier eingeworfen, sie selbst zu defnieren....

Zitat von Union:

Vielleicht diese Routine verwenden:

http://www.delphidabbler.com/articles?article=23&part=5

Das sieht sehr gut aus, danke!

[himitsu]

Zitat:

function IsWow64Process(hProcess:THandle;var Wow64Process:pbool):bool;stdcall;external kernel32 name 'IsWow64Process';

Falsche Deklaration?
VAR + BOOL (delphilike)
oder
PBOOL (WinAPI-vorgabe)


Und das ist natürlich eine statiscjhe Bindung, welche vor WinXP SP2 überall knallen wird.



Mit LoadLibrary die DLL laden (falls noch nicht ist) und das Handle holen.
Und dann mit GetProcAddress den Zeiger zur Prozedur/Funktion.

Statt LoadLibrary (hier FreeLibrary am Ende nicht vergessen) kann man auch GetModuleHandle verwenden, welches das Handle einer geladenen DLL liefert (0 falls nicht geladen), aber bei eigentlich immer geladenen SystemDLLs die ideale Lösung, um sich offiziell um das FreeLibrary zu drücken.

Zitat:

Das mit der Environment-Variable erschien mir schon optimal, aber dann wurde die Idee hier eingeworfen, sie selbst zu defnieren....

Hast du den XE2-Thread gesehn, wo es sich nicht kompilieren ließ, weil eine Umgebungsvariable alles "stört"?

[Luckie]

Also diese:

Delphi-Quellcode:

function IsWOW64: Boolean;
type
  TIsWow64Process = function( // Type of IsWow64Process API fn
    Handle: THandle;
    var Res: BOOL
  ): BOOL; stdcall;
var
  IsWow64Result: BOOL;              // result from IsWow64Process
  IsWow64Process: TIsWow64Process;  // IsWow64Process fn reference
begin
  // Try to load required function from kernel32
  IsWow64Process := GetProcAddress(
    GetModuleHandle('kernel32'), 'IsWow64Process'
  );
  if Assigned(IsWow64Process) then
  begin
    // Function is implemented: call it
    if not IsWow64Process(GetCurrentProcess, IsWow64Result) then
      raise Exception.Create('Bad process handle');
    // Return result of function
    Result := IsWow64Result;
  end
  else
    // Function not implemented: can't be running on Wow64
    Result := False;
end;

Genau das haben wir ja schon gesagt: Dynamisch einbinden.

Aber ich würde sie umbenennen: Is32BitProcess bei IsWow64Process bekomme ich immer einen Knoten im Hirn. Ich muss dann immer überlegen was es eigentlich heißt.

[DeddyH]

Und die Funktion muss ja im Gegensatz zur ersten Behauptung in beiden DLL-Versionen vorhanden sein:
- 32Bit-Exe: kann keine 64Bit-DLL laden und somit die Funktion gar nicht ermitteln -> sie wäre somit nutzlos
- 64Bit-Exe: sobald sie läuft, ist das ja wohl automatisch ein 64Bit-OS

[CCRDude]

Die 32 bit .exe lädt automatisch die 32 bit kernel32.dll, eine 64 bit .exe lädt automatisch die 64 bit kernel32.dll

Somit sähe das korrekt so aus:

- 32Bit-Exe unter 32Bit-Win: lädt kernel32.dll(32Bit), findet dort kein IsWow64Process - also false.
- 32Bit-Exe unter 64Bit-Win: lädt kernel32.dll(32Bit), findet dort IsWow64Process - also true.
- 64Bit-Exe: lädt kernel32.dll(64bit), findet dort IsWow64Process, welches false zurückgeben dürfte.

Ein Umbenennen in Is32BitProcess wäre etwas anderes (bzw. das kommt halt drauf an, wie man obige Situationen auswertet) - Is32BitProcess wäre für mich aber vermutlich sinnlos, weil ich das bereits zur Compile Time per Direktive regeln könnte.

[DeddyH]

Ja eben, von daher stimmt die anfangs getroffene Behauptung, die Funktion gäbe es nur in der 64Bit-Version der DLL, nicht bzw. kann ja gar nicht stimmen.

[Delphi-Laie]

Zitat von himitsu:

Und das ist natürlich eine statiscjhe Bindung, welche vor WinXP SP2 überall knallen wird.

Kleiner Hinweis: Auf meinem XP SP1 (auf dem XE2-Compilate nicht erfolgreich starten) "knallt" es, obwohl die Funktion natürlich fehlt, auch bei statischer Einbindung nicht.

[jaenicke]

Das darf auch nicht knallen, weil die Funktion dort existieren sollte. (Bei mir jedenfalls ist die da.)

// EDIT:
Nebenbei steht bei Microsoft explizit, dass man diese Funktion nicht statisch einbinden sollte.

// EDIT2:
Ok, ist bei mir auch SP3, das wurde im virtuellen PC doch schon automatisch aktualisiert. Aber grad nochmal zurückgesetzt, die Funktion ist auch mit SP1 dabei.

[Bernhard Geyer]

Zitat von himitsu:

Statt LoadLibrary (hier FreeLibrary am Ende nicht vergessen) kann man auch GetModuleHandle verwenden, welches das Handle einer geladenen DLL liefert (0 falls nicht geladen), aber bei eigentlich immer geladenen SystemDLLs die ideale Lösung, um sich offiziell um das FreeLibrary zu drücken.

Und genau in den gleichen Fehler landen wie Borland fallen wenn mal wieder System-DLL's unbenannt werden und der LoadLibrary-Aufruf im OS damit zurecht kommt und die jetzt gültige Library(-Handle) zurückliefert aber der GetModuleHandle fehl schlägt.

[Delphi-Laie]

Zitat von jaenicke:

Das darf auch nicht knallen, weil die Funktion dort existieren sollte. (Bei mir jedenfalls ist die da.)

Laut MSDN existiert sie ab Windows XP SP2. Aber der "Minimum supported client" wird im Verlaufe der Zeit dort immer mehr nach oben verschoben. So existiert eine Unmenge Funktionen schließlich schon seit Windows 1.x, 2.x, 3.x oder 4.x, doch davon liest man nichts (mehr). Wie gesagt, auf meinem XP SP1 gibt es damit keine Fehlermeldung bzw. keinen Programmabruch.

Zitat von jaenicke:

Nebenbei steht bei Microsoft explizit, dass man diese Funktion nicht statisch einbinden sollte.

Darf ich fragen, wo? In der entsprechenden Seite auf MSDN finde ich dazu nichts.