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

[Delphi-Laie]

Hallo Delphifreunde!

Zur Zeit beschäftige ich mich gerade damit, wie ein 32-Bit-Programm unter 32- und 64-Bit-Windows natürlich lauffähig sein soll und zusätzlich die Bitanzahl des OS selbständig erkennen kann. Bisherige Recherchen waren erfolglos.

Also, sizeof(Pointer) fällt als Erkennungsmerkmal aus, weil das auch unter 64 Bit nur 4 liefert, wohl wegen des 32-Bit-Subsystems.

Nun könnte man natürlich die IsWow64Process-Funktion benutzen, doch die ist in der 32-Bit-Version der kernel32.dll nicht enthalten, so daß das Programm an dieser Stelle mit einer Fehlermeldung abbricht ("Prozedureinsprungpunkt wurde .... nicht gefunden"). Fände man diese Funktion in besagter DLL, dann ist es ein 64-Bit-Windows, anderenfalls ein 32-Bit-Windows.

Um den Programmabbruch abzufangen, versuchte ich es mit try...except...end, bekam es aber nicht - kann try solche Mißerfolge wie fehlende DLLs oder fehlende Funktionen in den DLLs nicht abfangen? Oder wie erreicht man das?

Was ich nicht möchte: Mit OSVersionInfo "rumzumachen", um 32 von 64 Bit zu unterscheiden, weil das verdammt umständlich ist und künftige OS-Versionen logischerweise noch nicht berücksichtigen kann.

Gibt es einen einfachen Weg?

Natürlich kann man immer für beide Bitanzahlen zwei getrennte Programme erstellen, doch ist das vergleichsweise unelegant.

Vielen Dank & viele Grüße

Delphi-Laie

[himitsu]

IsWow64Process dynamisch einginden?

Wenn es dieses nicht gibt oder es False liefert, dann ist das Windows 32 Bit :zwinker:

Zitat:

Also, sizeof(Pointer) fällt als Erkennungsmerkmal aus, weil das auch unter 64 Bit nur 4 liefert, wohl wegen des 32-Bit-Subsystems.

Jupp, du hast ein 32 Bit Programm erstellt und das bleibt auch 32 Bit, egal wo es läuft.
Darum auch WOW64 ... das ist ein 32-Bit-Subsystem (Windows on Windows aka Windows32 on Windows64), worin dein Win32-Programm ausgeführt wird.

PS: In Win7 64 wurde das 16-Bit Subsystem entfernt, daum laufen dort auch keine 16 Bit Programme mehr ... soviel zu den Subsystemen, welche quasi "eigenständig" arbeiten ... dein Programm kommt also nicht direkt mit dem 64-Bit-System in Berührung.

Und zu deinem Try-Except:
Statische Bindungen werden zum Programmstart aufgelöst/hergestellt.
Es kommt also niemals bis zum Try-Except, da es gleich zu Anfang knallt.
(Es sei denn du hast es schon dynamisch eingebunden, aber "vergessen" die Rückgabewerte zu prüfen :stupid: )



Wozu mußt du das überhaupt wissen?

[Union]

Prüfe ob die Environment Variable %ProgramW6432% existiert (gibt es nur bei 64) bit. Und nein, es ist nicht unelegant 32- und 64-bit Programme zu trennen.

[DeddyH]

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

[Steku]

Oder vielleicht eine WMI Abfrage?

Unter Win32_ComputerSystem gibt es auch den
Schlüssel SystemType...

Gruß,
Steku

[himitsu]

Zitat:

Zitat von DeddyH (Beitrag 1122877)

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.

[CCRDude]

No offense meant, but himitsu hat mMn bereits die optimale Lösung genannt.

Das Environment ist "beliebig" (spätestens wenn das Programm von einem anderen ferngestartet wird, kann der ein beliebiges Environment übergeben oder auch mal aus Versehen ein leeres).

Und WMI ist eine viel zu hohe Ebene, das kann aus diversen Gründen auch mal scheitern, während die Möglichkeit, DLLs dynamisch zu laden, so grundlegend ist, daß das System, wenn das nicht mehr ginge, eh nicht mehr laufen würde ;)

[Delphi-Laie]

Dank Euch, das sollte als erstes für weitere "Forschungen" reichen!

Zitat:

Zitat von himitsu (Beitrag 1122874)

IsWow64Process dynamisch einginden?

Statisch und dynamisch einzubinden, kenne ich nur von DLLs.

Definiert ist die Funktion im interface:

Delphi-Quellcode:

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

, und sie wird dann im Programm aufgerufen.

Zitat:

Zitat von himitsu (Beitrag 1122874)

Es kommt also niemals bis zum Try-Except, da es gleich zu Anfang knallt.

Es "knallt" jedenfalls erst unter 32 Bit, wenn diese Funktion aufgerufen wird. Das Programm startet zunächst.

Zitat:

Zitat von DeddyH (Beitrag 1122877)

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

Zu meinem Erstaunen funktioniert o.g. Funktion auch mit einem 32-Bit-Programm - natürlich nur unter 64-Bit-Windows.

[DeddyH]

Gelöscht, war Quatsch.

[Union]

Vielleicht diese Routine verwenden:

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