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

[jaenicke]

Zitat von Delphi-Laie:

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

Zitat:

For compatibility with operating systems that do not support this function, call GetProcAddress to detect whether IsWow64Process is implemented in Kernel32.dll. If GetProcAddress succeeds, it is safe to call this function.

http://msdn.microsoft.com/en-us/library/ms684139.aspx
(Es scheint keine Möglichkeit zu geben die Quelle direkt im Quote-Tag anzugeben... )

[Delphi-Laie]

Zitat von jaenicke:

Zitat von Delphi-Laie:

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

Zitat:

For compatibility with operating systems that do not support this function, call GetProcAddress to detect whether IsWow64Process is implemented in Kernel32.dll. If GetProcAddress succeeds, it is safe to call this function.

http://msdn.microsoft.com/en-us/library/ms684139.aspx
(Es scheint keine Möglichkeit zu geben die Quelle direkt im Quote-Tag anzugeben... )

Danke, jaenicke! Das las ich durchaus, verstand das aber anders, eben nicht so, daß man diese Funktion generell nicht statisch einbinden solle.

Für reine 64-Bit-Compilate halte ich das nicht für verkehrt, denn die müssen diese Funktion ja (vor)finden.

Günstig ist die dynamische Einbindung natürlich, wenn man

- einen (1) Quelltext für 32- und 64-Bit-Compilate ohne Compilerschalter (die die Lesbarkeit immer erschweren)
- 32-Bit-Compilate haben möchte, die weder zum Programmabbruch führen noch diese Funktion ignorieren, wenn es sie denn gibt.

haben möchte.

Es gelang mir, an mein Ziel (Diskussionseröffnung) zu gelangen, besten Dank noch einmal an alle!

Da auch Windows XP die IsWow64Process-Funktion bereitstellt, ist mir allerdings nicht ganz klar, inwieweit die verlinkte und hier veröffentlichte Funktion sicher zwischen 32- und 64-Bit-Windows unterscheiden kann. Ich werde mich noch damit beschäftigen.

Dank und Gruß

Delphi-Laie

[RWarnecke]

Hallo Delphi-Laie,

in diesem Beitrag findest Du ein Beispiel einer sehr ausführlichen Beschreibung. Ich verwende den Quelltest aus dem Beispiel sehr gut in meinem Programm SystemInfo.

[Delphi-Laie]

Für ein 32-Bit-Programm ist die hier verlinkte und auch hier veröffentlichte Funktion erschöpfend. Für einen allgemeingültigen Quelltext, nämlich einen, der 32- und 64-Bit-Compilate - möglichst ohne Compilerschalter - übersetzt, taugt sie jedoch nicht(s), denn ein 64-Bit-Programm wird sich nie in einer Wow64-Umgebung wiederfinden und mithin fälschlicherweise 32 Bit zurückmelden (bzw. genaugenommen die 64 Bit verneinen).

Wird von dem Programm vorher auf 64 Bit geprüft, so z.B. mit der Größe eines Pointers, müßte dieser Quelltext "bitanzahlübergreifend" funktionieren, denn ein 64-Bit-Programm wird dann die 64 Bit zurückliefern, anderenfalls geht es wie gewohnt weiter. Diese Prüfung kann vorangestellt werden und mithin vor dem Funktionsaufruf oder am Anfang derselben geschehen (Quellcode etwas vereinfacht und an das originale PBool angepaßt):

Delphi-Quellcode:

function Is64BitWin:Boolean;
var
  IsWow64Result:BOOL;
  IsWow64Process:function(Handle:THandle;var Res:PBOOL):BOOL;stdcall;
begin
if SizeOf(Pointer)>4 {=8?!} then 
  begin
  result:=true;
  exit
  end
else
  begin
  IsWow64Process:=GetProcAddress(GetModuleHandle('kernel32'),'IsWow64Process');
  if Assigned(IsWow64Process) then
    begin
    if not IsWow64Process(GetCurrentProcess, IsWow64Result) then
      raise Exception.Create('Bad process handle');
    Result:=Boolean(IsWow64Result)
    end
  else Result:=false
  end
end;

Die Exceptionmeldung ist n.m.B. nicht nötig und stört nur. Auch wenn der Funktionsaufruf "IsWow64Process" fehlschlägt, sind die Ergebnisse korrekt.

[RWarnecke]

Irgendwie verstehe ich Dein Vorgehen nicht. Wenn ich ein Programm für 64Bit kompiliere, wozu brauche ich dann noch eine Abfrage ob mein Betriebssystem 32 oder 64 Bit ist. Ein 64Bit Programm greift auf die richtige Struktur zurück. Nur bei einem 32Bit Programm, welches auf einem 64Bit OS ausgeführt wird ist es wichtig auf die WOW6432Node - Registry Schlüssel zuzugreifen. Deshalb muss hier im Vordergrund eine Prüfung auf 32 oder 64 Bit stattfinden.

[Delphi-Laie]

Zitat von RWarnecke:

Irgendwie verstehe ich Dein Vorgehen nicht. Wenn ich ein Programm für 64Bit kompiliere, wozu brauche ich dann noch eine Abfrage ob mein Betriebssystem 32 oder 64 Bit ist. Ein 64Bit Programm greift auf die richtige Struktur zurück. Nur bei einem 32Bit Programm, welches auf einem 64Bit OS ausgeführt wird ist es wichtig auf die WOW6432Node - Registry Schlüssel zuzugreifen. Deshalb muss hier im Vordergrund eine Prüfung auf 32 oder 64 Bit stattfinden.

Das ist mir völlig klar. Ich schrieb doch oben, daß sich so der Quelltext wenigstens bei der Prüfung der "Bittigkeit" des Windows in bezug auf die Bitanzahlen vereinheitlichen läßt, man kommt demnach ohne die Compilerschalter WIN32 und/oder WIN64 aus.

[RWarnecke]

Zitat von Delphi-Laie:

Das ist mir völlig klar. Ich schrieb doch oben, daß sich so der Quelltext wenigstens bei der Prüfung der "Bittigkeit" des Windows in bezug auf die Bitanzahlen vereinheitlichen läßt, man kommt demnach ohne die Compilerschalter WIN32 und/oder WIN64 aus.

Was machst Du, wenn Du für 64Bit einen komplett anderen Quelltext brauchst als für 32 Bit und dieser unter 32Bit nicht zu kompilieren ist ? Du kommst aus meiner sicht nicht um die Compiler-Schalter drumrum. Da zum Teil die verwendeten Units unterschiedlich sein können. Hier mal ein Beispiel :

Delphi-Quellcode:

uses
  System.SysUtils, System.Types, System.UITypes, System.Classes, System.Variants,
  FMX.Types, FMX.Controls, FMX.Forms, FMX.Dialogs, {$IFDEF POSIX} Posix.SysTypes, Posix.Time, {$ENDIF}
  FMX.Layouts, FMX.Memo;

Wenn ich hier die IFDEF-Deklaration entferne, kann ich das Programm mit der USES-Klausel nur noch für MAC OSX kompilieren. Steht die IFDEF-Deklaration drin, kann ich es für 32/64Bit Windows und für Mac OSX kompilieren. Es ist eine Firemonkey-Anwendung.

Deshalb nochmal meine Frage, wozu brauche ich die IF-Abfrage auf den Pointer in der Procedure Is64BitWin ? Wenn ich das ganze über die Kompilerschalter regel habe ich es doch viel sauberer.

[Delphi-Laie]

Man kann diesen Code unabhängig für die Bitanzahl verwenden - er ist sozusagen bitanzahlneutral. Es ist ein gemeinsamer Code für beide Bitanzahlen. Mehr kann ich dazu wirklich nicht mehr sagen, zumal ich mich inzwischen wiederhole. Man muß es ja so nicht lösen, sondern es ist auch so möglich:

Zitat von RWarnecke:

Wenn ich das ganze über die Kompilerschalter regel habe ich es doch viel sauberer.

Richtig, so geht es auch. Sauberer? Womöglich übersichtlicher? Das ist mit Sicherheit (auch) eine Geschmacks-/Ansichtsfrage. Compilerschalter zerstückeln den Code ja gewissermaßen, es werden auf Ihrer Basis beim Compilieren i.d.R. nur Teile des Codes verarbeitet (sonst wären sie nicht sinnvoll). Das andere Extrem (oder neudeutsch "Ende der Fahnenstange") wären zwei in Form separater Dateien getrennte Quelltexte.

Insofern sollte mein Beispiel das eine/andere Ende der Fahnenstange aufzeigen - nicht mehr und nicht weniger.

[Assarbad]

Zitat von DeddyH:

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

Ja kannst du natürlich. Aber nicht mit LoadLibrary sondern mit LoadLibraryEx und LOAD_LIBRARY_AS_DATAFILE. Alles andere wäre Unsinn, denn man kann so sogar Ressourcen-DLLs für jede andere Architektur (bspw. Alpha) ebenfalls laden und benutzen.

Warum schreibe ich das, weil die Information daß es nicht ginge nur die halbe Wahrheit (bis Unwahrheit) ist. Ich kann sogar ermitteln ob eine Funktion exportiert wird, aber mit dem Handle in dem Falle eventuell nicht mehr über GetProcAddress, der Grund ist in den vielen Varianten zu suchen die es für Exporte gibt

Die Funktion existiert allerdings in der 32bit-Variante von kernel32.dll wenn ich mich recht entsinne. Und kernel32.dll ist in jedem Win32-Prozeß schon geladen bevor dein Haupthread startet.

[Daniel]

Moin Oliver,

schön, mal wieder etwas von Dir zu lesen.

Die Variante mit "Load_As_DataFile" ist mir bekannt, doch wie gehst Du denn mit den unterschiedlichen Calling-Conventions um, wenn Du eine DLL und die in ihr enthaltenen Funktionen tatsächlich nutzen willst? Ich hielt dies bisher für ein "No-Go" und hatte daher ebenfalls die Ansicht propagiert, dass eine normale 32bit-DLL mit Funktionen nicht im Rahmen einer 64bit-Anwendung zu nutzen sei (Ressourcen-DLLs ausdrücklich ausgenommen).