Ist Hosts 32-bittig oder 64-bittig?

Wie immer bin ich vor allem daran interessiert, was ein Paket tut. Das wird von Microsoft in den meisten "Fix it"-Artikeln freundlicherweise auch erklärt. Wie Sie sicherlich wissen, liegt die Hosts-Datei in %systemroot%\system32\drivers\etc, dort war sie schon immer, und dort wird sie wohl auch noch ein Weilchen bleiben. So weit, so gut. Hört sich einfach an, ist es aber nicht: auf 64-Bit-Systemen gibt es zwei System32-Verzeichnisse – eines für 64-Bit-Prozesse und das andere für 32-Bit-Prozesse. In welchem der beiden liegt nun die Hosts-Datei? Oder gibt es deren gleich zwei, die sich möglicherweise unterscheiden? Die Antwort lautet: Nein. Es gibt nur eine Hosts-Datei unter Windows x64, und die ist da, wo sie hingehört: im 64-Bit-System32-Verzeichnis. Wo aber findet sich dieses Verzeichnis auf der Festplatte? Es gibt schließlich zwei Kandidaten: die Verzeichnisse System32 und SysWoW64.

Umleitungschaos

An dieser Stelle macht sich oft Verwirrung breit. Viele, auch der Autor von KB972034 sehen die Zahl "64" im Namen des Ordners SysWoW64 und denken: ganz klar, das ist die 64-Bit-Version von System32. Gut gedacht, aber trotzdem falsch. Es ist genau andersherum. Aus Gründen der Abwärtskompatibilität wird das System32-Verzeichnis für diejenigen DLLs verwendet, die auf dem System "zu Hause" sind. Unter x64 also die 64-Bit-Dateien. Stellt sich noch die Frage, wo die 32-Bit-Dateien abgelegt werden, die von 32-Bit-Prozessen benötigt werden, welche ihre DLLs ebenfalls im System32-Verzeichnis erwarten! Eine DLL kann schließlich nicht unter dem gleichen Namen im gleichen Verzeichnis in zwei verschiedenen Varianten liegen (Spezialitäten wie Alternate Data Streams ignorieren wir an dieser Stelle geflissentlich). Der Bedarf an zwei unterschiedlichen System32-Verzeichnissen wurde durch die Einführung der Dateisystemumleitung erfüllt. Dabei existieren zwei unterschiedliche Verzeichnisse mit den Namen System32 und SysWoW64. 32-Bit-Prozesse bekommen das echte System32 gar nicht erst zu sehen, sondern ihnen wird durch Umleitung vorgegaukelt, SysWoW64 hieße System32. Diese Maskerade wird vom WoW64-Subsystem übernommen, welches 32-Bit-Prozessen die Ausführung unter 64-Bit-Windows ermöglicht.

Bearbeiten der Hosts-Datei

Um an die Hosts-Datei heranzukommen, benötigen wir einen 64-Bit-Prozess, da nur ein solcher das echte System32-Verzeichnis sieht. Um Hosts nach einer eventuellen Bearbeitung auch wieder speichern zu können, muss dieser Prozess mit erhöhten (vollen Admin-) Rechten laufen. Das läuft auf eine etwas hakelige Prozedur heraus:

• Klicken Sie auf Start, tippen Sie "notepad" und drücken Sie STRG+SHIFT+ENTER. Bestätigen Sie den UAC-Dialog.
• Drücken Sie STRG+O und navigieren Sie zum Verzeichnis %systemroot%\system32\drivers\etc. Wählen Sie unten rechts statt dem vorselektierten Filter für Textdateien "Alle Dateien (*.*)" aus.
• Jetzt sehen Sie die Hosts-Datei. Öffnen Sie sie, nehmen Sie Ihre Änderungen vor und speichern Sie sie wieder. Schon fertig

Unerwarteterweise kommt man auch von 32-Bit-Prozessen an die Hosts-Datei heran. Es gibt sogar zwei unterschiedliche Methoden, die jedoch beide voraussetzen, dass jeweils der volle Pfad in einem Stück angegeben werden muss. Sich gemütlich Verzeichnis für Verzeichnis von C: aus bis zu etc durchzuklicken funktioniert im ersten der beiden unten gezeigten Fälle nicht, weil das darüberliegende Verzeichnis System32 für 32-Bit-Prozesse nach SysWoW64 umgeleitet ist, und im zweiten weil Sysnative nicht in im Explorer angezeigt wird (wohl aber zum Beispiel im Total Commander).

• %systemroot%\System32\drivers\etc: Dies funtioniert, weil die Umleitung für das Unterverzeichnis etc deaktiviert ist, so dass die direkte Navigation dorthin ohne Zwischenstopp bei System32 auch für 32-Bit-Prozesse möglich ist.
• %systemroot%\Sysnative\drivers\etc: Sysnative ist ein Alias, der vom WoW64-Subsystem explizit zum Zweck des Zugriffs auf das echte System32-Verzeichnis erzeugt wird. Dieser Alias ist somit nur bei 32-Bit-Prozessen aktiv. Da er nicht in Verzeichnislistings angezeigt wird, ist er weithin unbekannt.

Verwandte Beiträge:

1. sFTP-Server unter Windows bereitstellen (Teil 3)
   In Teil 2 hatte ich ja beschrieben, wie man einen...
2. sFTP-Server unter Windows bereitstellen (Teil 2)
   Wie bereits in Teil 1 angekündigt, möchte ich hier beschreiben,...
3. sFTP-Server unter Windows bereitstellen (Teil 4)
   Wer die ersten drei Teile gelesen hat, hat bereits einen...

Zwar gibt es die Möglichkeit, auf einem Druckserver auch Treiber für andere Betriebssystemvarianten zu hinterlegen, doch die Umsetzung ist nicht ganz selbsterklärend. Kurz gefasst, muss man die Treibersoftware für die zusätzlichen Versionen vom Client aus auf dem Server installieren. Hier eine kleine Anleitung. Sie geht von Windows 7 und Windows Server 2008 R2 aus, aber mit anderen Windows-Versionen sind die Wege sehr ähnlich.

1. Auf dem Server ist in meinem Beispiel ein HP-Drucker mit dem universellen Druckertreiber installiert und freigegeben – natürlich in der x64-Fassung. Der Client läuft mit einem 32-Bit-System (x86). Die Treiberdateien für den x86-Treiber sind bereits vom Hersteller heruntergeladen und entpackt, aber noch nicht installiert worden.
2. Versucht der Client nun, den Netzwerkdrucker zu installieren, so erhält der Nutzer folgende Fehlermeldung:
   
3. Um den x86-Treiber zusätzlich auf dem Server zu hinterlegen, meldet sich am Client einmalig ein Benutzer an, der über administrative Rechte auf dem Server verfügt. Er verbindet sich per UNC-Pfad mit dem Server (hier: \\w28r2-dc01). Ein Klick auf einen der dort freigegebenen Drucker, und im Explorer-Menü taucht der Befehl auf: “Remotedrucker anzeigen”. Diesen auswählen.
   
4. Jetzt sieht man im Explorer die Drucker auf dem Server (auch die nicht freigegebenen). Per Rechtsklick auf den gewünschten Drucker öffnet man dessen Eigenschaften-Dialog:
   
5. Windows stellt nun fest, dass es keine Clientverbindung zu diesem Drucker hat (logisch, sonst würden wir das hier ja gar nicht machen ). Die entsprechende Nachfrage nun mit “Nein” beantworten – denn der nötige Treiber ist ja noch gar nicht vorhanden.
   
6. Es öffnet sich das Eigenschaften-Fenster des Druckers. Dort den Button “Zusätzliche Treiber” betätigen.
   
7. Jetzt das Häkchen für den fehlenden x86-Treiber setzen und “OK” klicken.
   
8. Windows fragt nun nach den Treiberdateien. Diese lokalisiert man. Den Namen der nötigen inf-Datei weiß Windows selbst.
   
9. Jetzt sollte der Windows-Client die Treiberdateien auf den Server kopieren und dort installieren.
   
10. Ruft man nach diesem Vorgang noch einmal die Eigenschaften des Druckers vom Server aus, sollte der x86-Treiber als vorhanden angezeigt werden.
    
11. Das war’s. Der Admin kann sich nun wieder abmelden. Diese Aktion ist nur einmalig für jeden Drucker nötig, der von Clients verschiedener Fassungen genutzt werden soll.
12. Meldet sich nun der “eigentliche” Benutzer wieder an, so kann er den Drucker vom Server als Netzwerkdrucker installieren.
    

Achtung: Damit dieses Verfahren funktioniert, muss der Druckername in den Treiberdateien für die x64- und die x86-Fassung genau identisch sein! Nur dann erkennt Windows, dass es Treiber für denselben Drucker sind. Leider schlampen manche Hersteller an dieser Stelle und tragen nicht dieselben Namen ein. Als Workaround kann man in solchen Fällen die .inf-Datei des nachträglich zu installierenden Treibers mit einem Texteditor bearbeiten und den Namen dort anpassen.

Siehe auch:

[How To Add 32bit Printer Drivers to a x64 Windows 2008 Print Server | Windows Server Administration]
http://www.msserveradmin.com/32bit-printer-drivers-on-an-x64-windows-2008-print-server/

Wer unter Windows 7 (oder Vista) in einer Domäne Drucker einrichten will, sollte auch dies beachten:

[faq-o-matic.net » Drucken unter Windows 7 in der Domäne]
http://www.faq-o-matic.net/2009/10/08/drucken-unter-windows-7-in-der-domne/

Verwandte Beiträge:

1. Wie muss ich Windows-Clients lizenzieren?
   Windows-Server kennen zwei (bzw. drei) Modelle, wie die Client-Zugriffe lizenziert...
2. VMware ESXi 5: Probleme mit LSI-Treiber
   Ein Kollege machte gerade auf Folgendes aufmerksam: Mit dem beim...
3. Windows-Clients neu in eine Domäne aufnehmen
   Windows-Rechner lassen sich seit Windows NT in eine Domäne aufnehmen....

Der Foliensatz liegt im XPS-Format vor, ein Viewer dafür ist notwendig (in Vista bereits enthalten, für andere hier auffindbar).

Verwandte Beiträge:

1. ice:2010 AD-Delegation – die Folien und Skripts
   Hier ist der Download der Folien (PDF-Format) und der Demo-Skripts...
2. \\ice:2008: Active Directory als Datenspeicher? Die Folien
   Wie eben gerade im Vortrag versprochen – hier sind die...
3. \\ice:2007: Windows Server 2008: Weniger ist mehr (Folien)
   Die Folien zu meiner Session "Windows Server 2008: Weniger ist...

Damit stehen die fertigen Produkte rechtzeitig zum deutschen Launch zur Verfügung, der vom 19. bis zum 21. Februar in Frankfurt zelebriert wird. Noch sind Plätze frei, wer teilnehmen will, sollte sich aber sputen.

Zunächst wurden von Windows Server 2008 nur die x64-Fassungen in den wichtigsten Sprachen veröffentlicht. Die 32-Bit-Versionen werden "in den nächsten Wochen" erwartet. Mehr dazu findet sich z.B. auf dem Blog von Daniel Melanchthon:

http://blogs.technet.com/dmelanchthon/archive/2008/02/04/windows-server-2008-rtm-und-windows-vista-sp1-sind-fertig.aspx

Verwandte Beiträge:

1. RDP-Neuerungen unter Windows Server 2008
   Für die tägliche Arbeit der Administratoren gehört mittlerweile die RDP-Verbindung...
2. Windows Server 2008: Service Pack 1 schon eingebaut
   Das gerade freigegebene Windows Server 2008 ist das erste Betriebssystem,...
3. Vista SP1 kommt doch früher
   Nachdem in der letzten Woche die Nachricht die Runde machte,...

"Ich möchte mehr als 4 GB in meinen Server einbauen."

Die bisher genutzten Betriebssysteme – nicht nur Windows, sondern auch Linux und andere – sind auf 32-Bit-Technik gebaut. Es stehen damit 32 Bit zur Verfügung, um Speicherinhalte zu adressieren (also Daten im Speicher ausfindig zu machen). Mit 32 Bit lassen sich maximal 4 Gigabytes RAM ansprechen (2³² = 4294967296 Bytes). Es ist also nicht möglich, mehr als 4 GB RAM mit einem 32-Bit-Betriebssystem anzusprechen.

Natürlich kann es trotzdem sinnvoll sein, mehr als 4 GB RAM zu nutzen. Der derzeit beste Weg, das zu tun, besteht im Einsatz eines 64-Bit-Betriebssystems für die sog. "x64"-Plattform. Solche Systeme sind für Windows XP, Windows 2003 und Vista verfügbar (und natürlich für andere Betriebssysteme).

"Meine Applikationen nutzen von den 4 GB immer maximal 2 GB aus!"

Die 4 GB, die ein 32-Bit-Windows adressieren kann, teilt es in zwei virtuelle Speicherbereiche auf: Das System und seine Daten (sowie Treiber usw.) haben Zugriff auf einen virtuellen Speicher von 2 GB ("Kernel Mode"). Applikationen erhalten ebenfalls einen virtuellen Speicher von 2 GB ("User Mode") – pro Applikation. Da diese virtuellen Speicher schon rechnerisch zusammen mehr als 4 GB ergeben, bringt Windows einen sehr leistungsfähigen Speichermanager mit, der die Zugriffe koordiniert. Datenbereiche, die gerade benötigt werden, liegen stets auf sog. "Speicherseiten" (Pages) im RAM. Datenbereiche, die gerade nicht aktiv benötigt werden, lagert Windows auf die Festplatte aus (in die Auslagerungsdatei oder "Page File"). Von dort werden sie bei Bedarf wieder ins RAM geladen.

Es ist zar möglich die Aufteilung von 2 GB Kernel zu 2 GB Usermode zu verändern. Dafür gibt es eine Konfigurationsoption, die den Kernelbereich auf 1 GB einschränkt und den Applikationsbereich auf 3 GB erweitert. Vorsicht aber: Das geht meist nach hinten los und ist nur für sehr wenige Applikationen geeignet, denn mit 1 GB Systemspeicher läuft Windows selbst schnell gegen die Wand. Sehr schön erläutert das Tipp 1.13 in dem Buch "Windows Server 2003 – Die Expertentipps".

In einem x64-System gibt es diese Aufteilung so nicht mehr – oder genauer: Sie spielt weniger eine Rolle, weil die Grenze viel höher liegt (derzeit 8 TB …). Allerdings wird auch hier der adressierbare Bereich nur dann von Applikationen genutzt, wenn diese das auch unterstützen. Bei professionellen Anwendungen, die für x64 entwickelt wurden, kann man davon ausgehen, dass es klappt.

"Mit der Enterprise Edition von Windows 2003 kann man aber bis zu 64 GB RAM einsetzen!"

Die Enterprise Edition von Windows Server 2003 in der 32-Bit-Fassung bietet (genau wie die von Windows 2000 Server) Unterstützung für ein Feature namens "PAE" (Physical Address Extension) bzw. "AWE" (Address Windowing Extension; so nennt Intel das). Dadurch ist es einem 32-Bit-System möglich, Speicherbereiche, die über der Grenze von 4 GB liegen, dynamisch bei Bedarf im Adressbereich unter 4 GB einzublenden. Sobald die Daten von dort gelesen oder verändert sind, werden die Zeiger auf den Speicher wieder zurückgesetzt, und der erweiterte Speicher wird wieder ausgeblendet.

Dieses Ein- und Ausblenden großer Speicherbereiche erfordert natürlich Zeit und Prozessorleistung. Auf diese Weise wird der Zugriff auf den "hohen" Speicher langsamer sein als der auf "niedrige" Speicherbereiche – die Performance leidet. Die wichtigste Einschränkung aber ist: Das ganze lässt sich ohnehin nur dann nutzen, wenn die eingesetzte Applikation dies auch unterstützt – sonst wird sie weiterhin nur 2 GB nutzen. Eine der sehr (!) wenigen Applikationen, die das Speicher-Mapping unterstützen, ist SQL Server ab Version 2000. Voraussetzung ist hier, dass in der boot.ini-Datei des Betriebssystems der Schalter "/PAE" gesetzt ist, der das Feature aktiviert (bzw. seit Windows 2003 SP1 ist PAE standardmäßig aktiviert – es sei denn, man schaltet die "No Execute"-Unterstützung pauschal ab, dann ist erst mal auch PAE abgeschaltet).

Bleibt die Schlussfolgerung: Wer mehr als 4 GB physischen Speicher braucht oder seiner Applikation mehr als 2 GB gönnen möchte, kann dies am besten mit einer x64-Version erreichen.

"Ich habe 4 GB RAM in meinem Server bzw. PC, aber Windows zeigt nur 3,24 GB an. Was macht Windows mit dem Rest?"

Auf fast allen Rechnern wird von 4 GB nur ein Teil angezeigt und genutzt. Windows ist unschuldig – das Problem liegt in der Architektur. Das Phänomen ist bekannt als "PCI Hole" und liegt vereinfacht gesagt daran, dass bereits das BIOS einen Teil des 4-GB-Adressraums vor dem Betriebssystem versteckt, um dort Adressbereiche für die Hardware-Unterstützung abzulegen.

Ob sich dieses Problem durch den Schalter "PAE" beheben lässt, wie man bisweilen liest, hängt davon ab, welche Windows-Version eingesetzt wird. Mit Windows Server 2003 (sogar Standard Edition) lassen sich via PAE die vollen 4GB RAM nutzen, wenn das BIOS Memory Remapping unterstützt (zwingende Voraussetzung!). Bei Vista und Windows XP wird, weil es Client-Betriebssysteme sind, die Nutzung auf Speicheradressen unterhalb von 4GB begrenzt. Der Hintergrund ist, dass viele Consumer-Treiber von den Herstellern nicht mit PAE getestet werden und mit Speicheradressen oberhalb von 32 Bit nicht umgehen können. Im Server ist das was anderes – die Servertreiber sind in der Regel aufwändiger getestet.

Der Microsoft-Mitarbeiter Daniel Melanchthon hat das recht hübsch für Vista beschrieben, wobei es auch für alle anderen Windows-Versionen zutrifft: "4 GB RAM mit Windows Vista"

"Wieviel RAM kann ich denn für Applikation XYZ einsetzen?"

Die meisten derzeit eingesetzten Programme laufen noch auf 32-Bit-Systemen und sind dafür optimiert. Hier ein kleiner Überblick über ein paar wichtige Applikationen:

• Windows-Dienste (Dateidienste, Druckdienste, Active Directory usw.): Auf 32-Bit-Systemen steht diesen Diensten ein Adressraum von 2 GB zur Verfügung. In größeren Netzwerken können auch diese einfachen Dienste von dem hohen Speicherausbau eines x64-Systems profitieren, denn in den x64-Versionen können alle diese Applikationen auf den großen Adressraum zugreifen. Dadurch passen mehr Daten ins RAM, und die Performance steigt.
• Terminalserver 32 Bit: Ein klassischer Terminalserver auf 32-Bit-Basis kann nicht mehr als 4 GB RAM adressieren; manche Experten legen die optimale RAM-Größe hier sogar mit 3 GB fest. Von allen Versuchen, einen 32-Bit-Terminalserver mit der Enterprise Edition und mehr RAM zu betreiben oder ihm mit dem "/3GB"-Schalter mehr RAM zuzubilligen, ist Abstand zu nehmen: Die Performance wird höchstwahrscheinlich drastisch einbrechen. Warum das so ist, erklärt wiederum Daniel Melanchthon hier: "Wieviel RAM ist sinnvoll bei Terminal Servern?"
• Terminalserver x64: Terminalserver profitieren sehr von x64-Systemen – aber nur, wenn das Gesamtsystem auch ausreichend performant ausgelegt ist (Prozessoren, interne I/O, externe I/O). Gerade bei Terminalservern gibt es einige mögliche Flaschenhälse, von denen das RAM nur einer ist.
• Exchange Server 2003: Exchange 2003 kann maximal 2 GB RAM adressieren, der maximal mögliche Speicherausbau liegt also bei 4 GB (weil das System selbst ja auch noch Platz braucht).
• Exchange 2000 Server: Exchange 2000 kommt mit mehr als 1 GB nicht klar – wer einen instabilen Exchange-2000-Server mit mehr RAM hat, sollte die überschüssigen Riegel entfernen.
• Exchange Server 2007: Das neue Exchange wird in Produktionsumgebungen nur in der x64-Version unterstützt. (Nur für Testzwecke gibt es eine 32-Bit-Variante.) Dadurch kann es mit viel RAM umgehen; für größere Kunden können 8 GB oder mehr durchaus sinnvoll sein.
• SQL Server 2000: SQL 2000 Standard kann nur 2 GB RAM ansprechen, maximaler Systemausbau also 4 GB. Die Enterprise Edition hingegen beherrscht PAE/AWE und kann damit mehr RAM ansprechen. Sinnvoller ist aber ein Umstieg auf SQL Server 2005 in der x64-Version.
• SQL Server 2005: Neue SQL Server sollten nur noch als x64-Version installiert werden (geht in allen Editionen), weil sie so auch mit viel RAM arbeiten können. Auch hier können für größere Kunden 8 GB oder mehr durchaus sinnvoll sein. Für 32-Bit-Versionen hingegen gilt dasselbe wie bei SQL Server 2000.

"Brauche ich für x64 nicht komplett neue Applikationen?"

Nein. Die x64-Technik ist in Wirklichkeit 32-Bit-Technik, die nur einen Speicherzugriff mit 64 Bit ermöglicht (eigentlich sind es derzeiit sogar "nur" 40 Bit). Das bedeutet: Applikationen, die für 32-Bit-Windows entwickelt wurden, laufen in der Regel problemlos auf einem x64-System (die meisten sogar schneller als auf einem 32-Bit-System). Schwierigkeiten gibt es allerdings mit Treibern – diese müssen tatsächlich für x64-Systeme separat entwickelt werden. Für Server sollte das heute kein Problem mehr sein, solange es Hardware betrifft. Da aber auch manche speziellen Applikationen mit Treibern arbeiten – z.B. Virenscanner, Backupsysteme usw. -, sollte in Spezialfällen erst eine Überprüfung stattfinden.

Alte 16-Bit-Software hingegen ist auf einer x64-Maschine nicht lauffähig, weil es dafür keine Emulationsschicht mehr gibt. Das betrifft DOS-Applikationen (wie so manche alte Warenwirtschaft) oder auch manche sehr alte Windows-Software, die noch aus Windows-3.1-Zeiten stammt.

"Und was heißt das nun?" 

Im Effekt heißt das: Für die meisten aktuellen Server kommt x64 durchaus in Frage. Bei Terminalservern sollte das genau geprüft werden. Für Workstations und PCs ist x64 derzeit nur im Ausnahmefall attraktiv (wegen der häufigen Treiberprobleme insbesondere mit externer Hardware).

Verwandte Beiträge:

1. RDP-Neuerungen unter Windows Server 2008
   Für die tägliche Arbeit der Administratoren gehört mittlerweile die RDP-Verbindung...
2. Windows Server Core: Windows (fast) ohne Fenster
   Vorabversionen von Windows Server 2008 sind jetzt allgemein verfügbar. Neben...
3. Webcast: “Windows 7 und Windows Server 2008 R2: Reif fürs Unternehmen?”
   Am 20. Oktober werde ich einen Webcast zu Windows 7...

Allerdings irritiert immer mehr Benutzer die Tatsache, dass oft nicht der gesamte physikalisch eingebaute Speicher vom Betriebsystem genutzt werden kann. Obwohl zum Beispiel das Mainboard vier 1 GB RAM-Riegel unterstützt und der gesamte Speicher von 4 GB im BIOS angezeigt wird, kann man oftmals nur 2.8 – 3.5 GB davon effektiv benutzen. Die Schuld schiebt der Benutzer dann schnell auf das Betriebsystem. Woran liegt es aber wirklich?

Wenn man mehr als 2 GB Hauptspeicher in x86-Systeme einbaut, ist es normal, dass nicht der gesamte physikalische Hauptspeicher benutzt werden kann. Der Grund dafür sind Ressourcenkonflikte durch die 32-bit-Technologie. Da das BIOS nicht weiß, ob ein 32-bit oder 64-bit Betriebsystem gebootet wird, startet es immer im 32-bit Mode. Darin stehen maximal 4 GB addressierbarer Speicher zur Verfügung. Deshalb müssen alle Memory- und Device-Adressräume unterhalb der 4 GB-Grenze eingeblendet werden. Wenn man nun >2 GB physikalischen Hauptspeicher einbaut, dann kommt es zum Ressourcenkoflikt zwischen physikalischem Hauptspeicher und den Device-Adressräumen.

Die meisten BIOS-Versionen lösen das Problem in der Form, dass sie ein Speicherloch unterhalb der 4 GB-Grenze einfügen. Dieses Loch wird auch als PCI-Loch (PCI Hole) bezeichnet. Der Speicher, den dieses Loch belegt, kann von keinem Betriebsystem angesteuert werden. Dadurch bleiben ~512 MB bis ~1.5 GB RAM ungenutzt. Es ist dabei unabhängig, ob es sich um ein 32-bit oder 64-bit OS handelt.

Die einzige Möglichkeit, diesen Speicher nutzbar zu machen, ist die Verlagerung in einen Bereich, der oberhalb von 4 GB liegt und nicht durch physikalischen Speicher schon belegt ist. Dazu bedarf es aber einiger Voraussetzungen:

• Betriebsystemunterstützung
  Das Betriebsystem muss Speicher >4 GB ansprechen können. Windows 2000, Windows XP, Windows Server 2003 und Windows Vista unterstützen in den Standardvarianten mit 32-bit maximal 4 GB RAM. Die Advanced-, Enterprise- und Datacenter-Produkte sowie die 64-bit-Versionen können mehr Speicher addressieren, wobei die Grenzen hier von den jeweiligen Versionen abhängen und bis zu 1 TB reichen können.
• Prozessorunterstützung
  Intel und AMD unterstützen 40-bit Addressierung in ihren aktuellen x64-Prozessoren (Intel EM64T/AMD64). Ältere Prozessoren sind auf 36-bit (PAE) oder auch 32-bit limitiert.
• Chipsatzunterstützung
  Der Chipsatz des Mainboards muss Memory Remapping oberhalb von 4GB unterstützen. Leider beherrscht die grosse Mehrheit der derzeit auf dem Markt erhältlichen Chipsätze für Desktops und mobile Computer genau diese Funktion nicht. Sie lässt sich auch nicht mittels eines BIOS-Updates nachrüsten. Erst die Workstation-Chipsätze von AMD und nVidia sowie demnächst erscheinende neue Chipsätze für Desktops und mobile Computer unterstützen mehr als 4 GB RAM und können die Hauptspeicheradressen zur Umgehung des PCI-Lochs verlagern.

Wie kann man nun die vollen 4 GB nutzen?

Windows kann prinzipiell den Hauptspeicher, der durch die Verlagerung zur Umgehung des PCI-Lochs oberhalb von 4 GB angesprochen werden kann, unterhalb der 4GB-Grenze einblenden. Voraussetzung dafür sind aber die obigen drei Punkte:

1. Kann die verwendete Windows-Version Speicher oberhalb von 4GB ansprechen?
   Die Antwort lautet nein für 32-bit und ja für 64-bit.
2. Kann der Prozessor Speicher oberhalb von 4 GB ansprechen?
   Bei aktuellen Modellen besteht eine hohe Wahrscheinlichkeit, dass Speicher oberhalb von 4 GB angesprochen werden kann. Bei AMD64 und EM64T ist die Unterstützung zum Beispiel gegeben.
3. Erlaubt der Chipsatz Memory Remapping und ist die Funktion im BIOS konfigurierbar?
   Die allermeisten Chipsätze können das nicht. Deswegen hilft auf der Umstieg auf ein 64-bit Betriebsystem nicht weiter.
   Aus diesem Grund kann auch ich mit meinem neuen Fujitsu-Siemens Celsius H240 trotz Intel Core2Duo, 4 GB RAM und 64-bit Windows Vista lediglich 3.25 GB Hauptspeicher nutzen.

(Dieser Artikel erschien zuerst unter http://blogs.technet.com/dmelanchthon/archive/2006/11/15/4-gb-ram-mit-windows-vista.aspx)

Verwandte Beiträge:

1. Windows Server 2008 und Vista SP1 sind fertig!
   Mittlerweile pfeifen es schon viele Spatzen von den Dächern: Seit...
2. Alte Hardware unter Windows Vista betreiben
   Vista wird viel gescholten: Es gebe kaum Treiber, alte Hardware...
3. Adminpak auf Windows Vista
   Update 14.3.2007: Mit dem Windows Vista Application Compatibility Update von März...