64 Bit Entwicklung und Betriebssysteme



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



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



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



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



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



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



  • Wunderbar danke 🙂



  • 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


Anmelden zum Antworten