Die DesktopdateienWenn ich x64 bin

Wes Miller

Windows XP ist seit mehr als fünf Jahren systemintern für 64-Bit-Architekturen verfügbar. Aber wenn Sie nicht einer der frühen Anwender des Intel Itanium-Prozessors waren (Windows XP für den Itanium wurde zur selben Zeit wie Windows XP geliefert), haben Sie davon wahrscheinlich erst vor kurzem durch die Verfügbarkeit der Windows XP und Windows

Server 2003-Versionen für x64-Systeme gehört. x64, in der Branche auch als x86-64 bezeichnet, ist der generische Name für die AMD64-Architektur von AMD und EM64T von Intel. Wenn Sie innerhalb des letzten Jahres einen neuen PC gekauft haben, ist es durchaus möglich, dass er 64-Bit-fähig ist, auch wenn er gegenwärtig mit 32-Bit läuft (was wahrscheinlich ist).

Zurzeit arbeite ich für ein kleines, neu gegründetes Unternehmen in Austin, Texas, USA. Aufgrund der Architektur eines unserer Produkte sind wir daran interessiert, bestimmte Vorteile der x64-Architektur zu nutzen, ähnlich wie das Microsoft® Exchange 2007-Team, das den Maßstab gesetzt hat und jetzt alle Produkte für die x64-Architektur ausliefert. Außerdem ist das von mir verwaltete Entwicklungs- und Testteam ausschließlich auf x64-Versionen von Windows® XP und Windows Server® 2003 für Entwicklungsarbeitsstationen, Laptops, Server und Produktionsserver bereitgestellt. Weiterhin führe ich Windows XP Professional x64 Edition auf meinem persönlichen Laptop aus, um unser Produkt zu testen und zu debuggen.

Interessanterweise reagieren die meisten Leute anfangs ziemlich unsicher, wenn ich die Ausführung von 64-Bit Windows – dazu auf einem mobilen System – erwähne. Wenn sie sich mit 64-Bit-Computern auskennen, ist es oft eine Mischung aus Ungläubigkeit und Erstaunen, begründet durch die verbreitete Annahme, dass Gerätetreiber für 64-Bit-Systeme kaum aufzutreiben sind. Im Artikel dieses Monats wird erläutert, wie und warum ich Windows XP und Windows Server 2003 auf x64-Systemen im 64-Bit-Modus verwende. Zudem werden Vorteile und mögliche Hindernisse bei der Bereitstellung aufgezeigt. Außerdem behandle ich Aspekte zur Unterstützung, Migration und Bereitstellung von Windows Vista x64.

Ein kurzer Rückblick

Wie bereits erwähnt, beginnt die Geschichte der 64-Bit-Unterstützung in Windows eigentlich mit der Unterstützung für den Intel Itanium-Prozessor. Obwohl Windows für den 64-Bit-Alphaprozessor verfügbar war, war Windows beim Ausführen auf dem Alpha in der Praxis nie wirklich 64-Bit. Da es keine Unterstützung für Itanium in Windows XP und Windows Vista gibt, obliegt es der x64-Architektur, 64-Bit-Windows-Clientcomputer zu unterstützen. Zurzeit ist eine größere Auswahl an Windows Server 2003 Editions für x64 verfügbar als für Itanium (das mehr oder weniger für ultrahohe Datencenterarbeitslasten abgestellt wurde), ein Trend, der sich meiner Ansicht nach mit der nächsten Version von Windows Server mit dem Codenamen „Longhorn“ fortsetzen wird.

Unterstützung für Windows auf der x64-Plattform stand ab Lieferung des Windows Server 2003 Service Pack 1 (SP1) zur Verfügung. Verwirrend war, dass die x64-Version von Windows XP zum selben Zeitpunkt verfügbar wurde, was bedeutet, dass Windows XP 32-Bit-Produkte und 64-Bit-Produkte aus unterschiedlichen Codestrukturen innerhalb von Windows abgeleitet wurden. Für 32-Bit-Produkte steht zwar zurzeit ein zweites Service Pack zur Verfügung, aber die 64-Bit-Version von Windows XP verfügt praktisch über gar keine Service Pack-Version (man könnte es so sehen, dass bereits SP1 für Windows Server 2003 integriert ist).

Für die Ausführung von 64-Bit-Windows – Windows XP, Windows Server 2003, Windows Vista oder Windows Server „Longhorn“ – sind die Anforderungen im Prinzip die gleichen. Zunächst ist natürlich ein 64-Bit-fähiger Prozessor erforderlich. Im Fall von AMD bedeutet dies ein einzelnes, doppeltes oder Vierkernsystem, das AMD64-Kompatibilität verspricht (siehe amd.com/us-en/Processors/ProductInformation/0,,30_118,00.html). Für Intel bedeutet dies die Suche nach einem einzelnen, doppelten oder Vierkernsystem, das entweder EM64T-Unterstützung oder die Intel 64-Architektur bietet (siehe intel.com/technology/intel64). Hierbei kommt es aufs Detail an. Ein Intel Core Duo-System ist beispielsweise nicht 64-Bit-fähig. Ein Intel Core 2 Duo-System ist 64-Bit-fähig, auch wenn es oft einfach als ein Centrino Duo (wie im Falle meines Laptops) bezeichnet wird.

Arbeiten mit x64

Wenn Sie ermittelt haben, ob Ihr System eine 64-Bit-Version von Windows systemeigen unterstützt, müssen Sie sich als Nächstes um den Gerätesupport kümmern. Obwohl Microsoft Anbieter und OEMs in WinHEC-Sitzungen über mehr als 2 Jahre hinweg ermutigt hat, 64-Bit-Treiber für ihre Geräte und Systeme zu erstellen und zu zertifizieren, ist die größte Herausforderung bei der Verwendung von Windows x64 das Auffinden von Treibern für Hardwaregeräte oder Software. Meiner Erfahrung nach funktioniert das Ausführen von x64 auf einem Server am besten, wenn die erforderliche Geräteunterstützung eingeschränkt und der Einsatz von x64 daher logisch ist.

Am schwierigsten ist es, Treiber für Desktop- und mobile Systeme zu finden. In der Regel liegen Sie bei einem großen OEM-Anbieter oder einem aus Unternehmenskomponenten aufgebauten System eher richtig, da die Wahrscheinlichkeit eines geschäftlichen Einsatzes den Anbieter oder OEM oft dazu veranlasst, x64-fähige Treiber zu erstellen und zu signieren.

Für Windows Vista sieht es allerdings schon viel besser aus. Statt einer Welt, in der x86 die bevorzugte Architektur und x64 die ignorierte Architektur mit eingeschränkt verfügbaren Treibern für die Mehrzahl der Hardware ist, ist nun das Gegenteil der Fall. Für Windows Vista muss ein Geräteanbieter x64 Treiber für Kompatibilitätsprüfungen zur Verfügung stellen. x86-Treiber müssen dabei nicht unbedingt vorliegen. Bestimmte Hardware, insbesondere Geräte, die die Vorteile der neuen Windows Vista-Funktionen nutzen, verfügt also im Grunde nur über x64-Windows-Unterstützung und nicht über x86-Unterstützung.

Treiber sind allerdings in der Praxis nur eins der Probleme, denen Sie sich beim Versuch der systemeigenen Ausführung von 64-Bit-Windows gegenüber sehen. Das größere Problem ist, überhaupt so weit zu kommen (mit anderen Worten, die Migration). Mehr dazu weiter unten im Artikel.

Gründe für 64-Bit

AMD, Intel und Microsoft sind natürlich nicht nur zum Spaß zu einer 64-Bit-Architektur übergegangen. Die Umstellung auf 64-Bit bietet mehrere wichtige Vorteile. Wie in Abbildung 1 verdeutlicht, ist die wichtigste Verbesserung innerhalb der x64-Architektur die Möglichkeit, erheblich mehr Speicher zu verarbeiten: bis zu 16 Terabyte (TB) im Gegensatz zu den 4 GB in 32-Bit-Windows. 64-Bit-Zeiger können zwar bis zu 16 TB verarbeiten, Anwendungen haben aber nur Zugriff auf bis zu 8 TB.

Figure 1 Adressenspeicherplatzbeschränkungen

Adressbereich 64-Bit-Windows 32-Bit-Windows
Virtueller Arbeitsspeicher 16 TB 4 GB
Auslagerungsdatei 512 TB 16 TB
Ausgelagerter Pool 128 GB 470 MB
Nicht ausgelagerter Pool 128 GB 256 MB
Systemcache 1 TB 1 GB

Zusätzlich bieten x64-Versionen von Windows Hardware-basierte Datenausführungsverhinderung (DEP). Diese ist ebenfalls auf x86-Systemen mit NX (No Execute)-Unterstützung verfügbar. Dies ermöglicht eine hardwaregesteuerte Lösung, die Windows für eine Verhinderung von Pufferüberläufen einsetzt. So wird die Codeausführung von Datenseiten im Speicher verhindert. Unter support.microsoft.com/kb/875352 finden Sie weitere Informationen zu diesem Thema.

X64-Versionen von Windows ermöglichen systemeigene Unterstützung von Multiprozessor- oder Multicore-CPUs, ebenso wie x86-Versionen von Windows. Eine der größten Komplexitäten der Bilderstellung eines Windows XP-Systems wird durch Verwendung einer einzelnen Hardware-Abstraktionsschicht (HAL) über alle Windows x64-Installationen hinweg beseitigt: Es gibt also keine weiteren Probleme bei der Erkennung der auf nicht-ACPI- oder Einzel-CPU-Systemen verwendeten HAL.

Im Grunde ermöglicht Ihnen Windows x64 als Architektur die Verwendung Ihrer vorhandenen Verwaltungsinfrastruktur und vorhandener 32-Bit-Software (durch Emulation) plus 64-Bit-Software mit der Möglichkeit, auf einen erheblich erweiterten Speicher zuzugreifen. Die einzigen unangenehmen Nebenwirkungen eines Wechsels zu Windows x64 sind die folgenden: Die fehlende Unterstützung für 16-Bit-Anwendungen (einschließlich 32-Bit-Anwendungen mit 16-Bit-Installer), Probleme mit Anwendungen, die nicht zuverlässig ausgeführt werden können, wenn Hardware-DEP aktiviert ist (obwohl DEP für einzelne Prozesse nacheinander deaktiviert werden kann und das Windows-Anwendungskompatibilitätsteam einen Shim für bestimmte Anwendungen einfügt, die nicht korrekt mit aktiviertem DEP ausgeführt werden) und schließlich die Tatsache, dass alle Treiber in 64-Bit Windows Vista digital signiert sein müssen.

Dieses letzte Element wurde hinzugefügt, um eine Manipulation des Windows-Kernels im Speicher zu verhindern, ein Verfahren, das häufig von Rootkits verwendet wird. Da x64 für Microsoft die Architektur ist, für die Anbieter vorranging Treiber entwickeln sollen (um diese Treiber dann durch die Windows-Hardwarequalitätsprüfung zu bringen), ist diese Anforderung wohl nicht so abschreckend wie in der Vergangenheit.

Bei der Berücksichtigung von Windows für x64-Systeme sind noch ein paar andere Punkte in Betracht zu ziehen. Es gibt keine Versionen von Windows XP für x64-Systeme, die die Funktionalität Windows Media® Center Edition oder Windows Tablet PC Edition bereitstellen. Dies ändert sich jedoch in Windows Vista, in dem die x64-Versionen von Windows über dieselbe Funktionalität wie x86-Versionen verfügen.

Virtualisierung

Noch nicht erwähnt habe ich die Virtualisierung. Damit meine ich nicht die Virtualisierungsprodukte für Microsoft Virtual PC oder VMWare PC, sondern die Betriebssystemvirtualisierung für ausführbare 32-Bit-Dateien. In 32-Bit-Versionen von Windows werden 16-Bit-Anwendungen alle innerhalb des Kontexts des NTVDM, eines virtuellen MS-DOS®-Computers ausgeführt. Wie ich bereits erwähnt habe, gibt es keine Unterstützung für 16-Bit-Anwendungen in den 64-Bit-Versionen von Windows. Die meisten integrierten Komponenten von Windows werden zwar systemeigen als 64-Bit-Binärdateien ausgeführt, aber manche Komponenten und zahlreiche Programme von Drittanbietern als 32-Bit-Anwendungen.

Windows bietet daher eine komplett neue Emulationsschicht namens Windows On Windows (WOW), um diesen 32-Bit-Anwendungen eine andere Ansicht des Betriebssystems zu bieten, das effektiv auf einer 32-Bit-Version von Windows läuft. Unter WOW erkennen x86-Anwendungen Programmdateien (X86) einfach als Programmdateien. Ebenso sehen x86-Anwendungen %WIN­DIR%\SysWOW64 als %WINDIR%\System32. x86-Anwendungen sehen den Registrierungsschlüssel HKLM\SOFT­WARE\Wow6432Node genauso, wie sie den HKLM\SOFT-WARE-Knoten selbst sehen würden.

Mithilfe des Process Explorer-Tools erhalten Sie eine andere Perspektive der Virtualisierung. Da viele 32-Bit-Anwendungen normalerweise mit integrierten 32-Bit-Windows-Binärdateien interagieren, werden zahlreiche dieser Binärdateien sowohl in 64- als auch 32-Bitversionen bereitgestellt. Durch Hinzufügen einer zusätzlichen Spalte zum Process Explorer wird dies sichtbar. In Abbildung 2 sind zwei Instanzen von cmd.exe dargestellt, eine 32-Bit-Version und eine 64-Bit-Version. Beachten Sie, dass die markierte 32-Bit-Instanz mehrere wow64*-DLLs enthält, die im 32-Bit-Prozess geladen werden. Diese zeigen den Virtualisierungsvorgang, der 32-Bit-Anwendungen ein Funktionieren unter 64-Bit Windows ermöglichen. Beachten Sie außerdem das Arbeitsverzeichnis (Pfad), das von den 64- und 32-Bit-Versionen von cmd.exe verwendet wird.

Abbildung 2 Process Explorer zeigt die 32-Bit- und 64-Bit-Versionen von cmd.exe

Abbildung 2** Process Explorer zeigt die 32-Bit- und 64-Bit-Versionen von cmd.exe **(Klicken Sie zum Vergrößern auf das Bild)

Noch eine letzte Bemerkung zum Thema Virtualisierung: Windows führt explorer.exe als systemeigene 64-Bit-Anwendung aus, was Vor- und Nachteile hat. Der größte Nachteil ist, dass jede Explorer-Shellerweiterung für x64 erneut kompiliert werden muss, um zu funktionieren.

Das Gegenteil gilt für Internet Explorer® – dieser wird systemeigen mit der 32-Bit-Version als Standard ausgeführt. Der Grund hierfür ist, dass die Vielzahl an ActiveX®-Steuerelementen, die bereits im Internet verwendet werden, dann ohne Änderungen weiter funktionieren. Da 64-Bit-Anwendungen 32-Bit DLLs oder Treiber nicht prozessintern laden können, besteht effektiv ohne diese Funktion keine Möglichkeit, 32-Bit-ActiveX-Steuerelemente zu laden. Dabei handelt es sich um fast alle aktuell verfügbaren ActiveX-Steuerelemente auf einem 64-Bit-Browser, was bedeutet, dass ein Großteil an Internetinhalt unzugänglich würde. Um dies in der Praxis zu sehen, laden Sie C:\Program Files\Internet Explorer\iexplore.exe auf einem 64-Bit-Windows-System und rufen eine beliebige Site auf, die ActiveX-Steuerelemente (selbst Windows Update) lädt. Sie erhalten auf jeden Fall einen Fehler. In Windows Update (siehe Abbildung 3) wurde nun die Funktion aktualisiert, eine 32-Bit-Instanz von Internet Explorer in dieser Situation zu öffnen. In Zukunft wird das ActiveX-Steuerelement sicherlich aktualisiert werden, um die Vorteile des 64-Bit Internet Explorer zu nutzen. Da die Mehrzahl der Windows-Systeme heutzutage jedoch ausschließlich 32-Bit Windows ausführt, ist eine Aktualisierung des ActiveX-Steuerelementinhalts nicht unbedingt notwendig. Dies wird sich meiner Meinung nach auch so bald nicht ändern.

Abbildung 3 32-Bit ActiveX-Steuerelemente schlagen in 64-Bit Internet Explorer fehl

Abbildung 3** 32-Bit ActiveX-Steuerelemente schlagen in 64-Bit Internet Explorer fehl **(Klicken Sie zum Vergrößern auf das Bild)

Windows x64 bei Pluck

Ich habe am Anfang dieses Artikels angemerkt, dass wir bei Pluck mit dem Übergang zu Windows x64 begonnen haben. Drei verschiedene Versionen von Windows wurden migriert: Windows XP Professional x64 Edition, Windows Server 2003 Enterprise Edition x64 und Windows Vista x64.

Das Unternehmen ist so klein, dass wir zu Beginn der Entwicklung unseres neuesten Produkts mit der Migration zu Windows für x64 beginnen konnten, um dessen Vorteile zu nutzen. Dazu musste die von uns bestellte neue Hardware natürlich x64-fähig sein. Tatsächlich ermöglichen uns die erweiterten Speicherfunktionen von x64 gemeinsam mit der Virtualisierung eine Ausführung unserer Produkte, bei der alle physischen Server als 64-Bit-Server auf einem 64-Bit-Hostserver ausgeführt werden. Für jeden Hostserver sind 16 GB Arbeitsspeicher auf die darauf gehosteten virtuellen Server aufgeteilt (normalerweise 2 GB für jeden virtuellen Bereitstellungscomputer oder VM und 3 GB für jeden Produktions-VM).

Durch Einsatz von Tier 1-Systemen und virtualisierter Hardware erreichen wir nahezu 100 Prozent Geräteunterstützung. Mein Laptop verfügt beispielsweise über drei Geräte, für die keine x64-Treiber zur Verfügung stehen. Dabei handelt es sich zumeist um weniger wichtige Geräte der Rückwandplatine, und das System kommt gut ohne ihr Vorhandensein aus. Interessanterweise führte eine Installation von Windows Vista RC1 x64 zu genau derselben Geräteunterstützung. Da mein System jedoch das Windows Vista Capable-Logo trägt, werden diese fehlenden Treiber hoffentlich bald vom Anbieter geliefert.

Da unsere Verwendung des Systems hauptsächlich auf Microsoft Office, Visual Studio® und einige weitere Tools für unseren Entwicklungs- und Buildprozess beschränkt ist, verfügen wir nicht über viele Legacyanwendungen, die zu Kompatibilitätsproblemen in unserer Migration führen könnten. Ein beträchtlicher Teil unseres Unternehmens verwendet zwar noch 32-Bit-Versionen von Windows, aber für neue Hardware haben wir mit der Migration zu 64-Bit begonnen. Bisher war dies relativ problemlos.

Bereitstellung und Migration von x64

Es müssen einige Überlegungen hinsichtlich der Bereitstellung angestellt werden. Microsoft bietet eine Version der Windows-Vorinstallationsumgebung (Windows PE) speziell für die x64-Architektur. Da jedoch eine x86-Parität für x64-Systeme vorhanden ist, möchten Sie möglicherweise x86 Windows PE für die Bereitstellung verwenden, insbesondere, wenn Sie eine Imaging-Lösung einsetzen. Wenn Sie Windows XP mithilfe einer unbeaufsichtigten Installation bereitstellen, muss Windows PE architekturspezifisch sein, da winnt32.exe unter derselben Architektur ausgeführt werden muss, die es bereitstellt. Da bei Windows PE keine 32-Bit-Kompatibilitätsschicht vorliegt und winnt32.exe unter x64 eine 64-Bit-Anwendung ist, erfordert 32-Bit-Windows eine 32-Bit Windows PE. Das gleiche gilt für 64-Bit-Versionen von Windows, die eine 64-Bit Windows PE erfordern.

Remoteinstallationsdienste (RIS) arbeiten in diesem Zusammenhang anders, daher verwendet Pluck RIS. Ab Windows Server 2003 SP1 kann RIS x64- sowie x86- oder Itanium-Architekturen von Windows bereitstellen. Wenn ein x64-System eine Verbindung zu einem RIS-Server herstellt, bietet der Server (in der Standardkonfiguration) x86 und x64 RISetup- oder RIPrep-Bilder. RIS kann auch so konfiguriert werden, dass x64-Clients ausschließlich x86-Bilder oder ausschließlich x64-Bilder erhalten. Die Auswahl wurde standardmäßig angeboten, um die beste Funktion mit der x64 Hardware zu bieten.

Beachten Sie, dass ich bisher noch nicht über die Aktualisierung gesprochen habe. Dies aus gutem Grund. Leider ist der Prozess einer Aktualisierung eines gesamten Betriebssystems von x86 zu x64 mit enorm viel Arbeit verbunden. Aus diesem Grund, und hinsichtlich der eingeschränkten Bereitstellung von Windows XP Pro x64 Edition, können sie nicht von einer beliebigen x86-Version auf Windows XP aktualisieren, noch können Sie von einer beliebigen Windows XP-Version (x86 oder x64) auf Windows Vista x64 aktualisieren. Windows Vista auf x64-Systemen ist ebenso wie Windows XP Pro x64 Edition ein komplett neues Installationsprodukt. Aus diesem Grund ziehen viele Unternehmen die Migration zu x64 nur dann in Betracht, wenn eine Hardwareaktualisierung ansteht. Es wird erwartet, dass zahlreiche Unternehmen für Windows Vista selbst eine ähnliche Strategie verfolgen (eine Doppelaktualisierung zur gleichen Zeit scheint logisch).

Dies bedeutet jedoch in keinster Weise, dass Personen oder Unternehmen, die von x86 Windows zu x64 Windows übergehen, keine Tools zur Verfügung stehen. Versionen des User State Migration Tool (USMT) für Windows XP und für Windows Vista wurden erweitert, um die Migration von einer Installation von Windows zur nächsten zu unterstützen (gegenüber einer integrierten Aktualisierung des Betriebssystems). Diese Methode (deinstallieren und auf demselben PC neu laden) wird heutzutage von den meisten Unternehmen für die Bereitstellung von Windows in allen Situationen verwendet. Der Einsatz derselben Methode für den Wechsel zu Windows auf einer komplett neuen Architektur dürfte daher kein größeres Hindernis darstellen.

Schlussbemerkung

Obwohl die schrittweise Migration in unserem kleinen Unternehmen zu x64 erheblich einfacher sein mag als der umfangreiche Migrationsprozess, dem sich größere Unternehmen gegenüber sehen, muss jeder IT-Experte den Wechsel zur x64-Architektur früher oder später berücksichtigen. Die x86-Architektur und systemeigenene x86-Versionen von Windows werden zwar auch noch im nächsten Jahrzehnt zur Verfügung stehen werden, aber die Zukunft des Computereinsatzes in Unternehmen liegt in der x64-Architektur. Angesichts des vollständigen Wechsels von Microsoft zu x64-Funktionen mit Exchange Server und anderen Produkten sollten Sie darüber nachdenken, wo in Ihrer Architektur x64-Systeme zunächst eingesetzt werden könnten, und wo sie in Ihrem Windows Vista-Migrationsplan sinnvoll sind. Dabei spielt es keine Rolle, ob Sie Windows XP oder Windows Server 2003 zurzeit systemeigen auf einem x64-System einsetzen.

Wes Miller ist Entwicklungsmanager bei Pluck (www.pluck.com) in Austin, Texas. Davor arbeitete er bei Winternals Software und bei Microsoft als Programm-Manager und Produktmanager für Windows. Sie können ihn unter technet@getwired.com erreichen.

© 2008 Microsoft Corporation und CMP Media, LLC. Alle Rechte vorbehalten. Die nicht genehmigte teilweise oder vollständige Vervielfältigung ist nicht zulässig.