64 Bit Entwicklung und Betriebssysteme

HaJo.

Hallo!

Ich bin mir nicht ganz sicher ob ein Teil meiner Frage hierher gehört, jedoch handelt es sich um den Microsoft C++ Compiler und MFC.

(1) Wenn man echte 64 Bit Applikationen "entwickeln" möchte, reicht es dem Compiler/Linker mitzuteilen, dass er Code für 64 Bit Plattformen erzeugen soll oder muss auch "anders" programmiert werden?

(2) Nun eine Frage zu 64 Bit Betriebssystemen - genauer Windows XP x64/2003 64 Bit/Vista 64 Bit. Bringt es mittleiweile Vorteile auf ein 64 Bit Betriebssystem umzusteigen - in meinem Fall existieren sämtliche Treiber etc. als 64 Bit Versionen ? Also genauer: Habe ich dadurch Geschwindigkeitesvorteile (doppelte Wortbreite...) oder zumindest KEINE Geschwinigkeitseinbußen oder laufen 32 Bit Programme und Spiele immer etwas langsamer auf 64 Bit Plattformen?

Jochen Kalmbach

HaJo. schrieb:

(1) Wenn man echte 64 Bit Applikationen "entwickeln" möchte, reicht es dem Compiler/Linker mitzuteilen, dass er Code für 64 Bit Plattformen erzeugen soll oder muss auch "anders" programmiert werden?

Wenn Du alles richtig gemacht hast, reicht es aus neu zu kompilieren

HaJo. schrieb:

(2) Nun eine Frage zu 64 Bit Betriebssystemen - genauer Windows XP x64/2003 64 Bit/Vista 64 Bit. Bringt es mittleiweile Vorteile auf ein 64 Bit Betriebssystem umzusteigen - in meinem Fall existieren sämtliche Treiber etc. als 64 Bit Versionen ? Also genauer: Habe ich dadurch Geschwindigkeitesvorteile (doppelte Wortbreite...) oder zumindest KEINE Geschwinigkeitseinbußen oder laufen 32 Bit Programme und Spiele immer etwas langsamer auf 64 Bit Plattformen?

Naja, minimal langsamer laufen sie. Aber man merkt es nicht. MS hat sehr viel dafür getan, dass 32-Bit Anwendungen ohne Probleme laufen... ich habe mein Vista als x64 installiert. Wenn ich "native" 32-Bit brauchen nehme ich VPC.

sri

Man muss schon darauf achten, dass einige Datentypen jetzt 64 bit breit sind. Unter Win32 hat man ja gerne mal ein DWORD für eine Adresse verwendet, unter x64 ist das ein absolutes No-go. Letztlich hängt alles davon ab, wie sauber Du unter Win32 programmiert hast. Im Optimalfall kann man für beide Ziele (Win32 und x64) den gleichen Quellcode verwenden. Beim ersten Kompilieren eines größeren Projektes wirst Du aber vermutlich erst einmal mit Warnungen (und Fehlern) überschüttet.

Auf der MSDN-Seite (bzw. in der Hilfe zum Platform SDK/VS 2008) findest Du ein paar grundlegende Richtlinien zur Entwicklung.

Wenn Du für x64 entwickeln willst, dann liegt der Vorteil eines 64-bit Systems eindeutig darin, dass Du x64- und Win32-Kompilate problemlos nebeneinander entwickeln und testen kannst. Speichertechnisch kannst Du so auch volle 4 GiB oder mehr verwenden.

HaJo.

Jochen Kalmbach schrieb:

Wenn Du alles richtig gemacht hast, reicht es aus neu zu kompilieren

Klingt gut. Also ich nehme an solche Dinge, wie sie von sri angesprochen wurden oder so etwas banales wie

size_t size1 = 0,
       size2 = 1;
memcpy(&size2, 0x30, 4); // Falls size_t unter x64 8 Bytes wäre

sri schrieb:

Man muss schon darauf achten, dass einige Datentypen jetzt 64 bit breit sind. Unter Win32 hat man ja gerne mal ein DWORD für eine Adresse verwendet, unter x64 ist das ein absolutes No-go. Letztlich hängt alles davon ab, wie sauber Du unter Win32 programmiert hast. Im Optimalfall kann man für beide Ziele (Win32 und x64) den gleichen Quellcode verwenden. Beim ersten Kompilieren eines größeren Projektes wirst Du aber vermutlich erst einmal mit Warnungen (und Fehlern) überschüttet.

Wollte es nachher einmal ausprobieren, Wie sich die gängigen Datentypen verhalten. Habe noch ein Vista x64 in einer virtuellen Maschine schlummern.

Also ein DWORD ist dann auch 64 BIt lang? Hmm, scheinbar lassen sich dann die Applikationen wirklich nicht eins zu eins übersetzen? Also wäre es sinnvoll, wenn man die "Windows-API-Datentypen" in Zukunft verwendet, gleich explizit deren Größe anzugeben. Also bei DWORD dann DWORD32? Oder wie ist das gemeint, denn dann hätte ich ja immer nur 32 Bit Datentypen.

Btw: Habe den MSDN Artikel noch nicht gelesen. Wenn ich Zeit habe, werde ich es nachholen.

Jochen Kalmbach schrieb:

Naja, minimal langsamer laufen sie. Aber man merkt es nicht. MS hat sehr viel dafür getan, dass 32-Bit Anwendungen ohne Probleme laufen... ich habe mein Vista als x64 installiert. Wenn ich "native" 32-Bit brauchen nehme ich VPC.

Also bei mir geht es halt um die Überlegung, da ich demnächst zusätzliche 2GB Speicher bekomme also dann 4GB habe und Memory Remapping ja leider nicht der Software hilft den oberen Speicher tatsächlich verwenden zu können, wollte ich ggf. auf "die" x64 Systeme von Windows umsteigen. Was allerdings nur ganz oder gar nicht in Frage kommen würde. Also entweder im Produktiveinsatz oder nicht. Ich spiele aber gerne auch mal das ein oder andere Spiel bzw. gibt es und habe ich noch eine ganze Reihe von 32 Bit Applikationen. Wenn das nun alles nur noch sehr schleppend laufen sollte bzw. die Spiele auf einemal ruckeln ist es z. Zt. uninteressant.

sri schrieb:

Wenn Du für x64 entwickeln willst, dann liegt der Vorteil eines 64-bit Systems eindeutig darin, dass Du x64- und Win32-Kompilate problemlos nebeneinander entwickeln und testen kannst. Speichertechnisch kannst Du so auch volle 4 GiB oder mehr verwenden.

Ja, das würde ich gerne machen. Zum anderen kann ich mich nicht ganz dem "Vorurteil" des gemeinen Volkes lösen 64 Bit sei schneller. Irgendetwas muss es ja bringen nicht nur die hörere Speicheradressierbarkeit. Schließlich sind doch auch die Befehle die die CPU verarbeiten kann, doppelt so breit. Lasse mich an dieser Stelle gerne korrigieren.

Gruß HaJo

Jochen Kalmbach

Um x64 zu compilieren brauchst Du kein x64 OS. Das geht auch auf x86 OSen. Kannst halt nur nicht ausführen

Alle Datentypen sind gleich gross wie unter x86, bis auf *Zeiger* und size_t.
Ein DWORD bleibt somit 32-Bit, auch int und long.

sri

HaJo. schrieb:

Also ein DWORD ist dann auch 64 BIt lang? Hmm, scheinbar lassen sich dann die Applikationen wirklich nicht eins zu eins übersetzen? Also wäre es sinnvoll, wenn man die "Windows-API-Datentypen" in Zukunft verwendet, gleich explizit deren Größe anzugeben. Also bei DWORD dann DWORD32? Oder wie ist das gemeint, denn dann hätte ich ja immer nur 32 Bit Datentypen.

Nein, ein DWORD ist unter x64 auch nur 32 Bit groß. Allerdings passen die nun verwendeten 64 Bit-Adressen nicht mehr in ein DWORD. Im MSDN-Artikel ist das alles wunderbar erklärt, ebenso wird beschrieben, wie man portable Programme schreibt. Beim DWORD-Beispiel wäre es z.B. die Verwendung von DWORD_PTR, der ist unter Win32 32 Bit und unter x64 64 Bit groß. Allerdings gilt das nur, wenn man das DWORD für Adressen verwendet. Für alle anderen Fälle reicht auch ein einfaches DWORD.

HaJo. schrieb:

Btw: Habe den MSDN Artikel noch nicht gelesen. Wenn ich Zeit habe, werde ich es nachholen.

Die Zeit solltest Du Dir als allererstes nehmen. Damit werden viele Fragen nämlich gleich beantwortet.

HaJo. schrieb:

Also entweder im Produktiveinsatz oder nicht. Ich spiele aber gerne auch mal das ein oder andere Spiel bzw. gibt es und habe ich noch eine ganze Reihe von 32 Bit Applikationen. Wenn das nun alles nur noch sehr schleppend laufen sollte bzw. die Spiele auf einemal ruckeln ist es z. Zt. uninteressant.

Bei mir läuft Vista x64 auch im Produktiveinsatz und ich kann keine Probleme feststellen. Lediglich die Verwendung von DOS-Anwendungen wird nicht mehr unterstützt. Für gelegentliche Spiele empfiehlt sich aber ein XP als Dual-Boot.

Jochen Kalmbach schrieb:

Alle Datentypen sind gleich gross wie unter x86, bis auf *Zeiger* und size_t.

Hinzuzufügen wären noch WPARAM, LPARAM und LRESULT.

HaJo.

sri schrieb:

Die Zeit solltest Du Dir als allererstes nehmen. Damit werden viele Fragen nämlich gleich beantwortet.

Wird meine nächste Lektüre werden.

sri schrieb:

Bei mir läuft Vista x64 auch im Produktiveinsatz und ich kann keine Probleme feststellen. Lediglich die Verwendung von DOS-Anwendungen wird nicht mehr unterstützt. Für gelegentliche Spiele empfiehlt sich aber ein XP als Dual-Boot.

Das finde ich sehr unpraktisch. Denn schon oft verspürte ich Lust "mal eben" etwas zu zocken, jedoch nicht sehr lange. Einfach nur um den Kopf etwas frei zu bekommen. Hierfür nun jedesmal zu booten ist ganz schön anstrengend bzw. impliziert "lange" Wartezeiten. Btw.: Ich habe irgendwie eine merkwürdige Beobachtung beim Spielen unter Vista gemacht. Die Spiele laufen etwas flüssiger bei gleicher oder teilweise höherer Qualität, obwohl doch eigentlich DX9 "emuliert" werden muss. Das hieße aber noch ein Vista x86 zu installieren, was auf Grund der primären Partitionsbeschränkung nicht geht.

zwutz

bei mir läuft ebenfalls ein x64-System (Vista) und auch bei Spielen kann ich keine wesentlichen Nachteile erkennen (was nicht heißt, dass es keine gibt). So oder so profitieren neuere Spiele durchaus von 4GiB RAM.

Problematisch könnte es nur bei älteren Spielen werden (also vll sogar noch vor XP-Zeiten). Dazu kann ich aber keine Erfahrungserichte bringen... am besten, du probierst es selber aus...

Zusätzlich:
unsigned long -> 64 bit
long -> 64 bit
Alles was davon abgeleitet oder über typedef damit benutzt wird, ist ebenfalls 64 bit groß (zumindest in meinem Linux-System ist das so.)

Außerdem ist ein 64-bit System dann, wenn irgendwo 64-bit-Integer auftreten (wie zB in manchen High-Number-Libs) im Vorteil, da man da keine umständliche Ersatzlösung für 64-bit braucht: long long int (sizeof auch ist da halt ein nativer Typ und funktioniert viel schneller als die nicht native Lösung in 32-bit-Systemen.
Nativer 64-bit-Code (beispielsweise ein Spiel das mit 2 Images geliefert wird, einer 64-bit und einer 32-bit-Executable) wird auch nicht langsamer laufen.
Auf Linux sind die Vorteile von 64-bit derzeit meist größer, da die Executables da ja meist extra für 64-bit-Systeme kompiliert werden, wenn man denn Besitzer eines solchen Systems ist (mit wenigen Ausnahmen).

Auch unter Vista läuft DX9 direkt, also ohne irgendwelchen Emulationen, insofern die entsprechende Operation auf der Hardware ausführbar ist (bzw. streng genommmen vom Treiber angeboten wird).

Kann mir jemand von euch 64Bit usern sagen was für eine Größe der Typ uintptr_t und intptr_t beim msc hat? Ich nehme zwar schwer an, dass es sich dabei um 8Byte handelt, aber möchte sicher gehen.

sri

Zacc schrieb:

Zusätzlich:
unsigned long -> 64 bit
long -> 64 bit
Alles was davon abgeleitet oder über typedef damit benutzt wird, ist ebenfalls 64 bit groß (zumindest in meinem Linux-System ist das so.)

Aber auch nur in Linux. In Windows ist die Größe dieser beiden Datentypen weiterhin 32 Bit.

Windowzer schrieb:

Kann mir jemand von euch 64Bit usern sagen was für eine Größe der Typ uintptr_t und intptr_t beim msc hat? Ich nehme zwar schwer an, dass es sich dabei um 8Byte handelt, aber möchte sicher gehen.

Deine Annahme ist richtig.

Jochen Kalmbach

*Alle* "ptr" typen haben die entsprechende Größe des Targets (also entweder 32 oder 64 Bit).

Wunderbar danke

luxfare

also zu den bedenken wegen älteren gmes unter vista x64 kann ich nur sagen das selbst diablo II und älter ohne probleme laufen, im notfall halt als komatibilitätsmodus, was allerdings bei derart alten games keine rolle mehr spielt da aktuelle rechner für sowas mehr als genug leistung haben