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

[himitsu]

Zitat von DeddyH:

Kann ich denn mit einem 32Bit-Programm eine 64Bit-DLL laden, um die Existenz eben dieser Funktion zu ermitteln?

Nein.

32 Bit kann nicht in 64 Bit und 64 Bit nicht in 32 Bit geladen werden.
(die Unterschiedliche Speicherverwaltung macht das quasi Unmöglich)

Genauso wie man nicht einfach eine .Net-DLL in einem Win32-Programm laden kann.


Eine Ausnahme stellen OutOfProcess-Server (DLLs) und sogenannte "Brücken" dar.
(im Code-Center von Emba liegt soeine Brücke rum, um eine 64-Bit-DLL indirekt in ein 32 Bit-Programm einzubinden)



PS: Nein, wenn ich lustig bin, dann erstell ich mir ein meinem 32 Bit-Windows einfach eine Umgebungsvariable namens "ProgramW6432" und was ist dann?


@DeddyH:
Diese Funktion existiert in den 32-Bit-SystemDLLs und in den 64-Bit-SystemDLLs, seit WinXP SP2.
Man kann sie also von überall aus aufrufen, auch von Win32-Programmen.

[DeddyH]

Gelöscht, war Quatsch.

[Union]

Vielleicht diese Routine verwenden:

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

[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"?

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

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

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

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