64-Bit-Technologie von Microsoft

  • Artikel

Veröffentlicht: 16. Mrz 2006

Von Mike Becker

Man muss nur die Zahlen vergleichen, um den Fortschritt der 64-Bit-Technologie bei der Speicherverwaltung zu erkennen: 4.294.967.296 Bytes Speicher waren unter 32-Bit-Technologie möglich, die neue Maßzahl lautet 18.446.744.073.709.551.616. So viele Bytes können mit der 64-Bit-Technologie von Microsoft in einem Programm ohne spezielle technische Tricks als Speicher genutzt werden, 18 Exabytes. Die 64-Bit-Technologie durchbricht damit bisherige Grenzen für die Speicherverwaltung.

Auf dieser Seite

 Was die 64-Bit-Technologie bringt
 Hardware-Plattformen
 Betriebssysteme
 Entwicklungswerkzeuge
 Datenmodell & Pointer-Arithmetik
 Padding und Alignment
 Neue Windows APIs
 Managed Code
 32-Bit und 64-Bit in Koexistenz
 Treiber
 SQL Server 64-Bit
 Organisation des Entwicklungsprozesses
 Ressourcen

Was die 64-Bit-Technologie bringt

Neue Grenzen für die Speicheradressierung bringen Vorteile für Endanwender von IT-Systemen, für Systemverwalter und für Softwareentwickler.

Endbenutzer profitieren von 64-Bit-Technologie durch neue, unter 32-Bit vorliegenden Einschränkungen nicht realisierbare Softwareszenarien, höhere Performance sowie niedrigere Kosten beim Erstellen von Software. Die Investitionen in 32-Bit-Softwarekomponenten sind nicht verloren, sie können in der 64-Bit-Welt weiterhin laufen.

Systemverwalter (Administratoren, Service-Mitarbeiter etc.) nutzen die 64-Bit-Technologie hauptsächlich, um die Anzahl der verwalteten Maschinen zu reduzieren (Konsolidierung von Rechner).

Softwareentwickler hingegen freuen sich über die vereinfachte durchgehende (auch als „flach“ bezeichnete) Adressierung von bis zu 18 Exabytes des Speichers, was die Verarbeitung von gigantischen Datenobjekten ermöglicht, ohne sie zerkleinern zu müssen („chunking“). Das spart Programmierern Zeit, um sich auf problemorientierte Aufgaben zu konzentrieren statt auf technische Aspekte, was den „Time-to-Market“-Wert für neue Software reduzieren kann.

Zusätzlich lassen sich Vorgänge implementieren, die mit der limitierten 32-Bit-Technologie nicht denkbar waren (z.B., Verarbeitung von gigantischen multidimensionalen Datenmatrizen von Analysis Services, Analysieren von komplizierten Digitalmodellen etc.).

 

Hardware-Plattformen

Grundvoraussetzung für 64-Bit-Software sind Hardware und Computer-Architekturen, die 64-Bit-Speicheradressierung unterstützen. Für die 64-Bit-Technologie von Microsoft sind das aktuell zwei CPU-Architekturen: Intel © Itanium © Prozessoren und so genannte „Extended Technology“-Prozessoren.

Eine Intel Itanium-CPU-Architektur (IA64) entsteht auf Basis der Itanium-CPU-Familie. Diese RISC CPUs erlauben eine neue Vision von Datenverarbeitung, beispielsweise große monolithische Datenobjekte geknüpft an eine Parallelisierung der Arbeit und interne „Intelligenz“ der CPUs, und enthalten neben der 64-Bit-Speicheraddressierung zahlreiche weitere technische Innovationen. Diese CPUs laufen ausschließlich im 64-Bit-Adressierungsmodus und können x86-CPU-Befehle nicht direkt verarbeiten.

Wegen ihrer innovativen Eigenschaften sind Intel Itanium-Prozessoren für „Mission-Critical“-Serveranwendungsbereiche mit hohen Anforderungen an Skalierbarkeit geeignet.

Die „Extended Technology“-Prozessoren (auch x64 genannt) sind auf Basis der bereits etablierten Architektur der x86-CPU-Generation aufgebaut und wurden um die Möglichkeiten der 64-Bit-Speicheradressierung erweitert. Diese CPUs können sowohl die Befehle der x86-CPU als auch die neuen 64-Bit-orientierten Befehle abarbeiten. Diese Art von Prozessoren ist durch Produkte von AMD © (Athlon ©, Opteron ©, Turion ©) und Intel © (ausgezeichnet mit EM64T – Extended Memory 64 Technology) vertreten.

Die x64-Prozessoren decken eine breite Anwendungspalette vom Desktop bis zum Server ab.

 

Betriebssysteme

Microsoft bietet zwei Produktlinien von Betriebssystemen für 64-Bit-CPU-Architekturen an:

Aussehen, Verhalten, Bedienung und Benutzerführung von Microsoft Windows für alle drei unterstützten Plattformen (x86, x64 und IA64) sind sehr ähnlich (weitgehende Funktionalitätsparität). Der interne Aufbau jedoch – besonders im Bereich der Treiber- und Basisdienste – unterscheidet sich gravierend.

Beide 64-Bit-Produktlinien dienen als Basis für Software, die 64-Bit-Speicheradressierung nutzen. Trotzdem werden die traditionellen 32-Bit-Programmmodule weiter unterstützt. Speziell dafür existiert in jeder Version von 64-Bit-Windows ein Subsystem zur Unterstützung von 32-Bit-Software. Dieses „Windows-On-Windows 64“-Subsystem (WOW64) emuliert eine 32-Bit-CPU-Architektur für 32-Bit-Softwaremodule, die im User Modus laufen sollen.

Im Folgenden finden Sie noch eine kurze Übersicht mit Vergleich von wichtigen Parametern für 32-Bit- und 64-Bit-Windows:

Speicherverwaltung

32-bit Windows

64-bit Windows

Total Virtual Address Space

4 GB

16 TB

Virtual Address Space für 32-Bit-Prozesse

2GB (3 GB, wenn das System mit Option /3GB gestartet wurde)

4GB für 32-Bit-Anwendungen, die mit Option /LARGEADDRESSAWARE kompiliert sind, sonst 2GB

Virtual Address Space für 64-Bit-Prozesse

Nicht möglich

8 TB

Paged Pool

470 MB

128 GB

Non-Paged Pool

256 MB

128 GB

System Cache

1 GB

1 TB

RAM und CPU Unterstützung

32-bit Windows

64-bit Windows

Windows XP Professional (x64)

4 GB / 1-2 CPUs

32 GB / 1-2 CPUs

Windows Server 2003 Standard Edition (x64)

4 GB / 1-4 CPUs

32 GB / 1-4 CPUs

Windows Server 2003 Enterprise Edition (x64, IA64)

64 GB / 1-8 CPUs

1 TB / 1-8 CPUs

Windows Server 2003 Datacenter Edition (x64, IA64)

64 GB / 1-32 CPUs

1 TB / 1-64 CPUs

Tabelle 1 und Tabelle 2. Übersicht von technischen Parametern für 32-Bit und 64-Bit-Windows.

 

Entwicklungswerkzeuge

Softwareentwicklung für Microsoft 64-Bit Plattform erfolgt mit für Entwickler wohl bekannten Werkzeugen, die sich jedoch weiter entwickelt haben.

Das erforderliche Minimum ist das Microsoft Windows Server 2003 SP1 Plattform SDK. In diesem Paket sind die Compiler, Linker, Bibliotheken, Debugger und weitere Tools enthalten, welche die Entwicklung für sowohl für traditionelle x86-Architekturen als auch für x64 und IA64 ermöglichen. Hiermit können native Programme für 32-Bit und 64-Bit (x64 und IA64) erstellt werden. Obwohl x86-Programme und -Module auf beiden 64-Bit-Plattformen laufen, sind die nativen 64-Bit-Images nicht austauschbar: x64-Programme laufen nicht auf IA64, IA64-Programme können nicht auf einer x64-Plattform benutzt werden.

Eine komfortable Entwicklungsumgebung für 64-Bit-orientierte Softwaremodule von Microsoft ist Visual Studio 2005. Die Versionen Visual Studio 2005 Standard und Professional enthalten Werkzeuge für x86- und x64-Softwareentwicklung, mit Visual Studio 2005 Team System bekommt man zusätzlich Unterstützung für die IA64-Plattform.

Für die Programmierung von managed Code gibt es das .NET Framework 2.0 SDK. Das .NET Framework 2.0 existiert in Varianten für 32-Bit und 64-Bit-Plattformen. Auf 64-Bit-Plattformen werden beide Versionen automatisch installiert, um bei Bedarf sowohl 32-Bit (im WOW64) als auch 64-Bit managed Code-Softwaremodule zu unterstützen.

 

Datenmodell & Pointer-Arithmetik

Das erste was ein Softwareentwickler bei der Arbeit für 64-Bit Windows beachten muss ist das geänderte Datenmodell. 32-Bit Windows operiert mit dem ILP32-Datenmodel: Integer, Long und Pointer-Datentypen sind alle 32 Bit lang. Beim Pointer-Datentyp handelt es sich auch um die vom Pointer abgeleiteten Datentypen: Handles auf Window, Module, etc.

64-Bit Windows operiert mit dem LLP64 Datenmodel: Pointer- und LongLong-Datentypen sind nun 64 Bit lang. Die Integer- und Long-Typen sind 32 Bit lang geblieben.

Die Änderung des Datenmodells zeigt sich in neuen Datentypdefinitionen, z. B.: INT_PTR – Integer der Länge des Pointer-Datentyps. Eine Variable eines solchen Typs erhält zur Laufzeit eine zur aktuellen Plattform passende Länge: auf x86 Windows oder auf 64-Bit Windows im WOW64 wird eine solche Variable 32 Bit lang, auf 64-Bit Windows native IA64 oder x64 wird sie 64 Bit lang sein.

Der Hauptunterschied zwischen 32-Bit- und 64-Bit-Plattformen liegt in der Speicheradressierung. Alle Pointer – und die abgeleiteten Datentypen (HMODULE, HANDLE, etc.) – sind auf einer 64-Bit-Plattform 64 Bit lang. Die Codefragmente, die Pointer-Arithmetik enthalten, müssen auf mögliche Datenverluste durch Type Casting usw. überprüft werden.

 

Padding und Alignment

Datenstrukturen im Speicher müssen mit Rücksicht auf die aktuelle CPU-Architektur mit Daten gefüllt werden – auch wenn einzelne Strukturfelder sequenziell verlegt werden sollen. Jeder Prozessor erwartet Daten im Speicher auf bestimmte Grenzen ausgerichtet (Data Alignment). Somit werden komplexe Strukturen für die x86-Architektur im Speicher so platziert, dass die einzelnen Strukturfelder auf 4 Byte-Grenzen (4 Bytes = 32 Bit, Länge eines Pointers) ausgerichtet werden. Bei IA64- und x64-Prozessoren richten sich die Daten auf 8 Byte-Grenzen. Dadurch können Lücken im Datenlayout entstehen, die mit zufälligen Daten oder Nullen aufgefüllt werden (Padding). Benutzt man Pointer-Kalkulationen oder feste Intervalle für den Zugriff auf einzelne Datenfelder von programmeigenen Strukturen, so muss man den Unterschied des Datenlayouts im Speicher auf 32-Bit- und 64-Bit-Plattformen berücksichtigen.

Padding und Alignment Beispiel
Abb.1 Padding und Alignment Beispiel

 

Neue Windows APIs

Verglichen mit der Umstellung von Windows 16-Bit zu Windows 32-Bit haben sich die Grundfunktionen von Windows für die Softwareentwicklung auf dem Weg von 32-Bit zu 64-Bit nur gering geändert. Neu hinzugekommen sind einige neue Windows-Verwaltungsfunktionen und -strukturen (z. B. SetWindowsLongPtr()), neue Datentypen (LONG_PTR, INT_PTR etc.) oder aber Änderungen in Konstantendefinitionen (INVALID_HANDLE_VALUE ist auf 64-Bit Plattform nicht mehr 0xFFFFFFFF). Die Änderungen sind recht überschaubar und erfordern nur eine kurze Einarbeitung.

Einige neue APIs ermöglichen zur Laufzeit festzustellen, ob ein Prozess nativ 64-Bit oder im WOW64 ausgeführt wird (IsWOW64Process()) und wie die aktuelle darunter liegende CPU-Architektur aussieht (GetNativeSystemInfo()).

 

Managed Code

Die Entwicklung von managed Code-Programmen kann jetzt variable Zielarchitekturen unterstützen. Die .NET 2.0 Compiler können managed Code-Module für x64-, IA64- oder traditionelle x86-Architektur erstellen.

Generell besteht aber die Möglichkeit, eine von der CPU-Architektur unabhängige Software zu erstellen (Schlüsselwort für Compiler - „/platform:anycpu“). Solche Module sind ohne Neukompilierung auf allen Plattformen lauffähig: die entscheidet zur Startzeit, ob das Modul nativ auf der aktuellen Plattform (im .NET Framework 64-Bit – je nach Plattform IA64 oder x64) oder im WOW64 (im .NET Framework 32-Bit, das auf allen Plattformen vorhanden ist) gestartet werden soll.

 

32-Bit und 64-Bit in Koexistenz

Ein wichtiges Thema betrifft den Datenaustausch und die Kommunikation zwischen einzelnen Modulen und Prozessen auf 64-Bit-Plattformen. Grundsätzlich gilt: Zwei Prozesse können miteinander kommunizieren, egal welche „Bitness“ sie haben. Ein 64-Bit-Prozess kann Daten an einen 32-Bit-Prozess senden und von einem 32-Bit-Prozess Daten empfangen.

Eine Mischung von Modulen im Prozessraum ist dagegen verboten: Ein 64-Bit-Prozess darf keine 32-Bit-Module laden, umgekehrt darf auch ein 32-Bit-Prozess keine 64-Bit-Module laden.

Diese Regelung verhindert daher den Zugriff auf 32-Bit-DLLs aus 64-Bit-Prozessen (und umgekehrt), Daten- und Befehlaustausch zwischen 64-Bit Prozessen und 32-Bit In-Process COM-Komponenten, Einbindung von 32-Bit ActiveX-Komponenten in Internet Explorer basierte Anwendungen auf 64-Bit Plattform etc.

Alle diese Aspekte müssen bei der Neuentwicklung oder Migration von Software auf 64-Bit Windows berücksichtigt werden.

 

Treiber

Ein gesondertes Thema auf 64-Bit Windows sind Treiber. Obwohl 32-Bit-Programme auf 64-Bit Windows – dank WOW64 – unterstützt werden, handelt es sich um User-Mode-Anwendungen. Die 32-Bit-Treiber können nicht auf 64-Bit-Plattformen benutzt werden. Vielmehr sind die 64-Bit-Treiber zwischen zwei von Windows unterstützten 64-Bit CPU-Architekturen nicht kompatibel: IA64-Treiber und x64-Treiber sind nicht austauschbar.

Da 64-Bit-Windows keine 32-Bit-Treiber nutzen kann, sind die 64-Bit-Treiber für native 64-Bit-Windows-Programme und für die unter WOW64 laufenden Prozesse zuständig. Die Information zur Laufzeit, welcher Prozess – 32-Bit oder 64-Bit - gerade eine Bedienung vom Treiber angefordert hat, liefert die SPI Kernel-Funktion IoIs32bitProcess().

 

SQL Server 64-Bit

Microsoft bietet Datenbanksysteme an, die die Vorteile der 64-Bit-Technologie nutzen. Es existiert eine IA64-Version des Microsoft SQL Server 2000. Ab Microsoft SQL Server 2005 gibt es parallel zur 32-Bit-Version die Versionen für IA64- und x64-Plattformen.

Funktionalitätsparität sowie Konsistenz in Datenstrukturen und Objekten des SQL Servers ermöglichen gleiche Datenbankentwicklungsverfahren für 32-Bit- und 64-Bit-Plattformen: gleiche Unterstützung von T-SQL, gleiche Datentypen, gleiche Stored Procedures etc. Selbst die Dateiformate für Datenbankdateien sind für alle Versionen von SQL Server gleich: man kann eine mit 32-Bit SQL Server angelegte und entwickelte Datenbank als Dateien an eine 64-Bit SQL Server-Instanz anhängen („attachen“) und sofort nutzen.

Mehr Aufmerksamkeit ist im Bereich von Assemblies und Extended Stored Procedures geboten (durch die Unterstützung des SQLCLR Features in SQL Server 2005): Da die 32-Bit- und 64-Bit-Module in einem Prozessraum nicht zusammen verwendet werden dürfen, könnte es erforderlich werden, die Assemblies (managed Code) oder Extended Stored Procedures (unmanaged Code) neu zu kompilieren, um die „Bitness“-Konflikte aufzulösen.

 

Organisation des Entwicklungsprozesses

Wenn die zu entwickelnden Softwaremodule verschiedene Plattformen unterstützen sollen (man erwartet Produktversionen für 32-Bit Windows und mind. eine der unterstützten 64-Bit Windows Versionen), ist es angebracht, die „Single Codebase Policy“ einzuhalten. Das bedeutet, dass alle zu generierenden Versionen aus einem Satz der Quelldateien zu erstellen sind. Die Steuerung zur Kompilierungszeit erfolgt durch Compiler-Einstellungen (Schlüssel, Definitionen) und interne Logik im Quellcode (#ifdef, #define, etc.).

Mit Microsoft-Entwicklungswerkzeugen ist es nicht erforderlich, 64-Bit-Software direkt auf 64-Bit-Maschinen zu entwickeln. Sie kann auch auf 32-Bit Maschinen erstellt werden und dabei passende Binärversionen von Produkten gezielt generieren lassen. Lediglich zu Endtestzwecken und Performance Tuning muss eine 64-Bit-Testmaschine(n) bereitstehen.

 

Ressourcen

Entwicklerinformationen im Platform SDK und im .NET Framework SDK bieten sich weitere Ressourcen an, die für Software Designer den Ein- oder Umstieg auf eine 64-Bit-Windows-Plattform erleichtern.

Eine gute Einstiegstelle ist auf jeden Fall MSDN – mit Developer Communities, Code-Beispielen und nützlichen Werkzeugen.