Warum diverse Compilerschalter CPU32/WIN32 und CPU64/WIN64?

[Delphi-Laie]

Hallo Lazarus-/Pascalfreunde!

Weiß jemand, warum es für CPU-Bitbreite und Windows-Bitversion verschiedene Compilerschalter gibt (s. Betreff)?

Mich beschäftigt, ob man damit überhaupt zu unterschiedlichen Ergebnissen kommen kann.

Es ist klar, daß Win64 nur auf auf CPU64 ausgeführt werden kann, so daß, wenn man auf Win64 prüft, stattdessen auch CPU64 nehmen könnte.

Doch gilt das auch umgekehrt, kann man also statt CPU64 auch WIN64 verwenden, oder wird eine 64-Bit-CPU auch mit 32-Bit-Software (32-Bit-FPC oder damit erstellte Compilate) erkannt?

Dazu experimentierte ich folgendes:

1. 32-Bit-FPC auf Windows 32 Bit mit 64-Bit-System (also mit 64-Bit-Prozessor), dort werden nur CPU32 und WIN32 erkannt
2. 32-Bit-FPC auf Windows 64 Bit; auch hier werden nur CPU32 und WIN32 erkannt.

Also, es müssen 64-Bit-Prozessor und -Windows vorhanden sein (das eine bedingt das andere, aber nicht umgekehrt), um auch 64 Bit zu erkennen, und dann werden logischerweise auch beide für die 64 Bit zuständigen Compilerschalter berücksichtigt. Sobald nur eines davon 32 Bit ist oder wenn FPC mit 32 Bit verwandt wird, sind nur die 32-Bit relevant.

Mathematisch kann man das auch so ausdrücken, daß hier zwei Äquivalenzen ("genau dann, wenn") vorliegen:

CPU32 <-> WIN32
CPU64 <-> WIN64

oder anders, daß die Lösungsmengen dieser Erkennungsfunktionen identisch sind.

Ist es also wirklich egal, ob man auf CPU oder auf WIN prüft, sind also zwei Schalter redundat? Oder gibt es einen Denkfehler meinerseits?

Vielen Dank im voraus und Grüße

Delphi-Laie

[u-boot]

In deiner komplizierten Darstellung hast du wohl noch vergessen, dass kein 64-Bit Betriebssystem mit einer 32-Bit CPU betrieben werden sollte.

[Socke]

Es gibt beim Compilieren von Quellcode ganz grob gesehen zwei Punkte die du berücksichtigen musst:

• Die Zielarchitektur
• Das Zielbetriebssystem

Ein x86 kann nur 32-Bit Code ausführen, nicht aber 64bit-Code. Ein x86_64 kann sowohl 64- als auch 32-Bit-Code ausführen.
Du solltest also auf das richtige Symbol im richtigen Zusammenhang testen.

Mathematisch kann man das auch so ausdrücken, daß hier zwei Äquivalenzen ("genau dann, wenn") vorliegen:

CPU32 <-> WIN32
CPU64 <-> WIN64

Nicht ganz; es gibt immer noch Kombinationen anderer Betriebssysteme mit diesen Architekturen:
(CPU64 ∧ WINDOWS) <-> WIN64
(CPU32 ∧ WINDOWS) <-> WIN32

Richtig ist aber, dass ein 32bit-Programm auch unter einem 64bit-Betriebssystem ein 32bit-Programm bleibt.

[Delphi-Laie]

In deiner komplizierten Darstellung hast du wohl noch vergessen, dass kein 64-Bit Betriebssystem mit einer 32-Bit CPU betrieben werden sollte.

Besten Dank für diesen Hinweis! Das war mir natürlich nicht bekannt, so daß ich diese Essentialität in meinen vorigen Beitrag nicht mit aufnehmen konnte - ich gelobe Besserung!

++++++++++++++++++++++++++++++++

Hallo Socke, Dir Dank für Deine Mühe!

Es gibt beim Compilieren von Quellcode ganz grob gesehen zwei Punkte die du berücksichtigen musst:

• Die Zielarchitektur
• Das Zielbetriebssystem

Ein x86 kann nur 32-Bit Code ausführen, nicht aber 64bit-Code. Ein x86_64 kann sowohl 64- als auch 32-Bit-Code ausführen.

Das ist natürlich bekannt.

Du solltest also auf das richtige Symbol im richtigen Zusammenhang testen.

Ja, das tat ich ausführlich, mit dem Ergebnis, daß die Ausgabemengen beider identisch sind.

Mathematisch kann man das auch so ausdrücken, daß hier zwei Äquivalenzen ("genau dann, wenn") vorliegen:

CPU32 <-> WIN32
CPU64 <-> WIN64

Nicht ganz; es gibt immer noch Kombinationen anderer Betriebssysteme mit diesen Architekturen:
(CPU64 ∧ WINDOWS) <-> WIN64
(CPU32 ∧ WINDOWS) <-> WIN32

Nunja, die 64 Bit Hardware nützen jedoch nicht nur nichts mit 32 Bit, sie werden auch gar nicht erkannt - entweder, weil es gar nicht möglich ist, oder zur Sicherheit, denn was soll es, auf diesem Meßergebnis aufbauend, zu versuchen, irgendwelche 64-Bit-Routinen aufzurufen? Also, wenn, dann werden die 64 Bit sowohl bei Architektur als auch beim Betriebsprogramm immer gemeinsam erkannt (auch wenn sie, zum x. Male nun, nicht gemeinsam vorliegen müssen).

FPC hat - im Gegensatz zu Delphi - den Riesenvorteil, für beide Bitbreiten verfügbar zu sein. Wie kann demnach ein (gemeinsamer) Quelltext geschaffen werden, der bei einem 32-Bit-Compilat 32 oder 64 Bit oder bei einem 64-Bit-Compilat nur die 64 Bit (logischerweise) erkennt, bei der also beide Compilate die jeweils richtige Bitumgebung identifizieren?

Angelangt und dann gestolpert bin ich über die "IsWow64"-Funktion von Windows, die als 64-Bit-Pendant nicht funktionieren wollte, was auch nicht möglich ist, wie mir später klarwurde, weil ja kein 32-Bit-Emulator verwendet wird. Hier mein vorläufiges, anscheinend funktionierendes Ergebnis:

Code: Alles auswählen

function Is64Bit:Boolean;
type TIsWow64Process=function(Handle:Windows.THandle;var Res:Windows.BOOL):Windows.BOOL;stdcall;
{$IFDEF WIN32}//alternativ:{$IFDEF CPU32}?
var
  IsWow64Result:Windows.BOOL;// Result from IsWow64Process
  IsWow64Process:{^}TIsWow64Process;// IsWow64Process fn reference
{$ENDIF}
begin
{$IFDEF WIN32}//alternativ:{$IFDEF CPU32}?
IsWow64Result:=false;//nur, damit der Compiler nicht meckert
Pointer(IsWow64Process):=Windows.GetProcAddress(Windows.GetModuleHandle('kernel32'),'IsWow64Process');// Try to load required function from kernel32
if Assigned(IsWow64Process) then
  begin
  //Function is implemented:call it
  if not IsWow64Process(Windows.GetCurrentProcess,IsWow64Result) then raise SysUtils.Exception.Create('IsWow64:bad process handle');
  Result:=IsWow64Result
  end
else Result:=False //Function not implemented: can't be running on Wow64
{$ENDIF}
{$IFDEF WIN64}//alternativ:{$IFDEF CPU64} oder auch {$ELSE}, aber was ist, wenn es einmal 128 Bit geben wird?
Result:=true
{$ENDIF}
end;

[Socke]

Nunja, die 64 Bit Hardware nützen jedoch nicht nur nichts mit 32 Bit, sie werden auch gar nicht erkannt - entweder, weil es gar nicht möglich ist, oder zur Sicherheit, denn was soll es, auf diesem Meßergebnis aufbauend, zu versuchen, irgendwelche 64-Bit-Routinen aufzurufen? Also, wenn, dann werden die 64 Bit sowohl bei Architektur als auch beim Betriebsprogramm immer gemeinsam erkannt (auch wenn sie, zum x. Male nun, nicht gemeinsam vorliegen müssen).

FPC hat - im Gegensatz zu Delphi - den Riesenvorteil, für beide Bitbreiten verfügbar zu sein. Wie kann demnach ein (gemeinsamer) Quelltext geschaffen werden, der bei einem 32-Bit-Compilat 32 oder 64 Bit oder bei einem 64-Bit-Compilat nur die 64 Bit (logischerweise) erkennt, bei der also beide Compilate die jeweils richtige Bitumgebung identifizieren?

Es ist nicht möglich auf einem 32bit-System ein Programm für eine 64bit-Architektur zu erstellen. Du willst also herausfinden, ob ein 32bit-Programm unter einem 64bit-Windows läuft?

Angelangt und dann gestolpert bin ich über die "IsWow64"-Funktion von Windows, die als 64-Bit-Pendant nicht funktionieren wollte, was auch nicht möglich ist, wie mir später klarwurde, weil ja kein 32-Bit-Emulator verwendet wird. Hier mein vorläufiges, anscheinend funktionierendes Ergebnis:

Code: Alles auswählen

{$IFDEF WIN64}//alternativ:{$IFDEF CPU64} oder auch {$ELSE}, aber was ist, wenn es einmal 128 Bit geben wird?
Result:=true
{$ENDIF}
end;

Wenn es in ferner Zukunft einmal 128bit-Prozessoren gibt (und sich noch jemand für den FPC auf dieser Architektur interessiert), wäre es möglich, dass dann ein CPU128-Flag vom Compiler gesetzt wird. Irgendwo in der Dokumentation taucht auch noch ein CPU16 auf, auch wenn es de facto keine 16bit-Unterstützung gibt. In deinem Code ist IFDEF WIN32 die richtige Frage an den Compiler, da du den Code nur unter Windows auf x86 ausführen willst.
Dein Funktionsname Is64Bit scheint allerdings mir ein wenig unglücklich gewählt, da es dir ausschließlich um das Betriebssystem geht. Ein 32bit-Betriebssystem wird dir nie sagen, dass es auf einem 64bit-Prozessor läuft, auch wenn dieser das unterstützt.

[marcov]

Denke auch daran das CPU64 <> x86_64 ist. Mein Mac G5 (powerpc64) hat auch "CPU64"

CPU64 meint nur das sizeof(pointer)=8; der Rest ist OS und exakte CPU abhängig.

Lese auch mal http://www.stack.nl/~marcov/buildfaq/#toc-Section-5.1" onclick="window.open(this.href);return false;

[Delphi-Laie]

Danke, Socke!

Es ist nicht möglich auf einem 32bit-System ein Programm für eine 64bit-Architektur zu erstellen.

Gut, dann deckt sich das ja mit den Ergebnissen meiner Experimente, die das gewissermaßen auch so aussagten.

Du willst also herausfinden, ob ein 32bit-Programm unter einem 64bit-Windows läuft?

Ob auf 32 oder auf 64 Bit, und zusätzlich soll das quelltextidentische 64-Bit-Compilat von vornherein wissen, daß es auf 64 Bit läuft. Mit meiner Fummellösung müßte das alles gewährleistet sein.

Wenn es in ferner Zukunft einmal 128bit-Prozessoren gibt (und sich noch jemand für den FPC auf dieser Architektur interessiert), wäre es möglich, dass dann ein CPU128-Flag vom Compiler gesetzt wird. Irgendwo in der Dokumentation taucht auch noch ein CPU16 auf, auch wenn es de facto keine 16bit-Unterstützung gibt. In deinem Code ist IFDEF WIN32 die richtige Frage an den Compiler, da du den Code nur unter Windows auf x86 ausführen willst.

Das waren meine in den Quelltext geschriebenen Gedankengänge, die theoretischer Natur waren, und eigentlich auch vor Veröffentlichung besser hätten gelöscht werden sollen. 128 Bit sind nicht in mittelnaher Sichtweite.

Dein Funktionsname Is64Bit scheint allerdings mir ein wenig unglücklich gewählt, da es dir ausschließlich um das Betriebssystem geht.

Einfach kopiert und erstmal nicht weiter darüber nachgedacht, sondern mich anderen Schwerpunkten zugewandt. Er ist aber auch nicht falsch, hätte allerdings auch konkreter Is64BitWindows heißen können.

Ein 32bit-Betriebssystem wird dir nie sagen, dass es auf einem 64bit-Prozessor läuft, auch wenn dieser das unterstützt.

Ja, so waren die Ergebnisse auch. Allerdings kann man über den "Trick" wenigstens ein 32-Bit-Programm erfahren, wenn es unter 64 Bit läuft und sein Verhalten entsprechen anpassen/variieren.

Hallo Marcov, auch Dir danke!

Denke auch daran das CPU64 <> x86_64 ist. Mein Mac G5 (powerpc64) hat auch "CPU64"

Guter Gedankengang! Allerdings ist mein Programm, für das ich das benötige, nur ein windows-kompatibles Compilat, so daß eben wohl doch WIN64=CPU64 ist (oder zumindst sein müßte).

CPU64 meint nur das sizeof(pointer)=8; der Rest ist OS und exakte CPU abhängig.

Das fand ich auch schon, allerdings funktioniert das nur für die "Bittigkeit" desselben Programmes. Ein 32-Bit-Programm hat auf Windows 64 Bit eben auch nur einen 4-Byte-Pointer.

Lese auch mal http://www.stack.nl/~marcov/buildfaq/#toc-Section-5.1" onclick="window.open(this.href);return false;[/quote]

[Socke]

Ein 32bit-Betriebssystem wird dir nie sagen, dass es auf einem 64bit-Prozessor läuft, auch wenn dieser das unterstützt.

Ja, so waren die Ergebnisse auch. Allerdings kann man über den "Trick" wenigstens ein 32-Bit-Programm erfahren, wenn es unter 64 Bit läuft und sein Verhalten entsprechen anpassen/variieren.

Jetzt bin ich aber gespannt! Inwiefern kann man denn da das Verhalten sinnvoll verändern (ich meine jetzt nicht Funktional dem Benutzer gegenüber)?

CPU64 meint nur das sizeof(pointer)=8; der Rest ist OS und exakte CPU abhängig.

Das fand ich auch schon, allerdings funktioniert das nur für die "Bittigkeit" desselben Programmes. Ein 32-Bit-Programm hat auf Windows 64 Bit eben auch nur einen 4-Byte-Pointer.

Ein 32bit-Programm wird nie einen echten Zeiger mit einer anderen Größe als 4 Byte haben. Ein 64bit-Betriebssystem stellt auch 32bit-Programmen gegenüber als 32bit-Betriebssystem dar (außer es gibt eine API, aber die ist nur eine Behauptung ). Es gibt zwar die Technologie auch unter 32bit-Betriebssystemen mehr als 4GibiByte Speicher anzusprechen und das müsste prinzipiell auch auf normale Anwendungen portierbar sein, nur habe ich noch von keiner Sprache/keinem Compiler gehört, der das ebenfalls unterstützt, zumal das OS mitspielen müsste, was doch recht tiefe Eingriffe in den Kernel benötigt.

[Delphi-Laie]

Jetzt bin ich aber gespannt! Inwiefern kann man denn da das Verhalten sinnvoll verändern (ich meine jetzt nicht Funktional dem Benutzer gegenüber)?

Das sollst Du als kleines Dankeschön gern erfahren. Mir ging es nur um einen Fall. Und zwar kann man die API-Funktion "SetThreadIdealProcessor" auch nur lesend benutzen (was der Funktionsname nicht gerade verrät), wenn man ihr für den lesenden und (normalerweise auch geschriebenen) Parameter (für Pascal lernte ich dafür einmal die Bezeichnung "Variablenparameter", wenn ich mich recht entsinne) "dwIdealProcessor" den Wert "MAXIMUM_PROCESSORS" übergibt. Hm, wie groß muß der sein, wo findet man etwas dazu? Mikroweichs API-Referenz ist leider auch hier ein Quentchen zu oberflächlich. Schließlich fand ich hier des Rätsels hoffentlich stimmige Lösung: 32 für 32 und 64 für 64 Bit. Da die Prozessoren von 0 bis n-1 gezählt werden, ist dieser Wert plausibel. Sicher ist ein 32-Bit-Programm unter 64 Bit funktionseingeschränkt, aber das Ändern des Idealprozessors (neben anderen Dingen wie Ändern der Prioriät und der Affinitätsmaske sowie das Beenden von Prozessen und Threads) könnte es für Programme, die nicht in der sog. "Service Session" laufen, noch erreichen ("hinbekommen").

Also, meine Lazaruscompilate, egal, ob 32 oder 64 Bit, sollen maximale Funktionalität haben, was erfordert, daß ein 32-Bit-Compilat eben die Bittigkeit seiner Umgegung wahrnimmt und, davon abhängig, 32 oder 64 Bit in die o.a. API-Funktion sendet, während das 64-Bit-Compilat diesen "Umgebungsdetektor" nicht benötigt und zur Compilierungszeit gleich mit dem richtigen Rückgabewert bestückt wird.

Puh, das war aber vielleicht anstrengend.....

Edit: Soeben fiel mir ein, daß es auch ohne Compilerschalter möglich sein müßte: Pointergröße auf 8 überprüfen; falls ja, sind es 64 Bit, und falls nein, dann kann man immer noch auf die "IsWow64Process"-Umgebung überprüfen.

[Socke]

Es geht also um den Wert einer Konstante. Wenn die irgendwo nur mit Namen genannt werden, kann man davon ausgehen, dass sie in einer Windows-Header-Datei deklariert sind. Also: SDK herunterladen und mit Lazarus ein "In Dateien suchen..." ausführen. Google findet zwar nicht die offiziellen Microsoft-Header, aber die des WINE-Projektes.
Ausgehen von der Tatsache, dass die Konstante MAXIMUM_PROCESSORS in der Unit jwawinnt.pas deklariert ist, habe ich geraten, dass sie für C in winnt.h definiert sein müsste und habe deine Annahme aus einem anderen Internetforum verifizieren können.
Die Funktion SetThreadIdealProcessor ist bereits in der Unit JwaWinBase.pas deklariert (sogar richtig).

Edit: Ich habe mir einmal die Freiheit genommen und einen Bug-Report verfasst.

[marcov]

Das fand ich auch schon, allerdings funktioniert das nur für die "Bittigkeit" desselben Programmes. Ein 32-Bit-Programm hat auf Windows 64 Bit eben auch nur einen 4-Byte-Pointer.

Ja, und ein 8-bit Commodore 64-bit in emulator nur 16-bit indirekt via die Zero page

Und das ist kein Witz. 32-bit Programme laufen auf 64-bit auch in eine Art Emulator (aber eine die fast unsonst ist) Gleich wie das Commodore 64 Programm nicht von win64 weißt, weißt auch das win32 Programm das nicht. Es sieht (meistens) nur der Emulator. (der heißt übrigens WOW, was für "Windows On Windows" steht)

[Socke]

Und das ist kein Witz. 32-bit Programme laufen auf 64-bit auch in eine Art Emulator (aber eine die fast unsonst ist) Gleich wie das Commodore 64 Programm nicht von win64 weißt, weißt auch das win32 Programm das nicht. Es sieht (meistens) nur der Emulator. (der heißt übrigens WOW, was für "Windows On Windows" steht)

Nicht ganz. Zumindest der Prozessor wird in den 32bit-Modus gesetzt und arbeitet dann nativ darin. Das Betriebssystem muss dann natürlich noch den Speicherzugriff abbilden. Soweit ich mich informiert habe...

[marcov]

Und das ist kein Witz. 32-bit Programme laufen auf 64-bit auch in eine Art Emulator (aber eine die fast unsonst ist) Gleich wie das Commodore 64 Programm nicht von win64 weißt, weißt auch das win32 Programm das nicht. Es sieht (meistens) nur der Emulator. (der heißt übrigens WOW, was für "Windows On Windows" steht)

Nicht ganz. Zumindest der Prozessor wird in den 32bit-Modus gesetzt und arbeitet dann nativ darin. Das Betriebssystem muss dann natürlich noch den Speicherzugriff abbilden. Soweit ich mich informiert habe...

Also ein hardware unterstutzte Compiler Die grenzen zwischen Emulation und "echt" sind nicht sehr hart. Man konnte fast alle Windows Programme als eine win32/64 Emulation über das NT api sehen.

[Socke]

Also ein hardware unterstutzte Compiler Die grenzen zwischen Emulation und "echt" sind nicht sehr hart. Man konnte fast alle Windows Programme als eine win32/64 Emulation über das NT api sehen.

Wenn man als nativ die (undokumentierte) Native-API des Windows-Kernels betrachtet, ja.

[Delphi-Laie]

Es geht also um den Wert einer Konstante. Wenn die irgendwo nur mit Namen genannt werden, kann man davon ausgehen, dass sie in einer Windows-Header-Datei deklariert sind. Also: SDK herunterladen und mit Lazarus ein "In Dateien suchen..." ausführen. Google findet zwar nicht die offiziellen Microsoft-Header, aber die des WINE-Projektes.t.

Danke, aber mit so etwas beschäftigte ich mich noch nie, und das ist mir jetzt zu aufwendig.

Ausgehen von der Tatsache, dass die Konstante MAXIMUM_PROCESSORS in der Unit jwawinnt.pas deklariert ist, habe ich geraten, dass sie für C in winnt.h definiert sein müsste und habe deine Annahme aus einem anderen Internetforum verifizieren können.

Prima, dann stimmt das, was ich fand, also.

Wenn allerdings diese Konstante von der "Bittigkeit" des Betriebsprogrammes bzw. des Prozessors abhängig ist, dann stehen auch die FPC-Programmierer vor der Aufgabe, mit Kompilerschaltern den richtigen Wert dafür einzustellen (eine echte Konstante ist es damit aber übrigens nicht mehr, zumindest nicht im Quelltext, im Compilat natürlich schon noch).
Außerdem würde diese Konstante, weil mit Kompilerschaltern zur Laufzeit auf den richtigen Wert gebracht (bzw. der richtige Wert ausgewählt), bei einem 32-Bit-Compilat eben auch nicht den richtigen Wert dafür liefern, wenn dieses in einer 64-Bit-Umgebung läuft. Ergänzung: Mein voriger Satz ist evtl. falsch, es kann sein, daß es nichts bringt, in einem 32-Bit-Programm in einer 64-Bit-Umgebung der Funktion "SetThreadIdealProcessor" den 64-Bit-Maximum_Processors-Wert mitzugeben. Das werde ich noch versuchen herauszufinden.

Die Funktion SetThreadIdealProcessor ist bereits in der Unit JwaWinBase.pas deklariert (sogar richtig).

Danke für den Hinweis! Ich übernahm einfach meine Delphi-Codeschnipsel in Lazarus, ohne an diese Möglichkeit überhaupt zu denken. In Delphi ist es ab Version 3 in der Unit "Windows" deklariert, leider wohl nicht ganz richtig, jedenfalls wird der durchaus wichtige integre Rückgabewert zu einem schnöden "bool" verkürzt.

Edit: Ich habe mir einmal die Freiheit genommen und einen Bug-Report verfasst.

Prima, danke, und was für ein Glück Du doch hast, daß das schon erstmalig bearbeitet wurde! Ich warte immer noch darauf, daß mein jüngster Bugreport dort, der immerhin schon aus dem letzten Jahrzehnt stammt, überhaupt wenigstens nach außen sichtbar zur Kenntnis genommen (bzw. wahrgenommen) wird.