Zusammenfassung:
In Windows 11 gibt es ein Design, das Benutzer lange verwirrt: Auf einem 64-Bit-System speichert C:WindowsSystem32 tatsächlich 64-Bit-Systemdateien, während das Verzeichnis C:WindowsSysWOW64 mit „64“ im Namen stattdessen 32-Bit-Dateien speichert. Für Benutzer, die die Geschichte von Windows nicht kennen, könnte dieses Benennungsschema völlig umgekehrt erscheinen.
Microsoft-Ingenieure haben kürzlich erneut die Gründe für dieses Design erläutert. Die Antwort liegt nicht darin, dass Microsoft einfach die Verzeichnisnamen umgekehrt hat, sondern vielmehr darin, zu verhindern, dass viele Softwareprogramme beschädigt werden, die auf den alten Pfaden basieren. Als Windows von einer 32-Bit-Architektur auf eine 64-Bit-Architektur migrierte, beschloss es, den bereits weit verbreiteten System32-Verzeichnisnamen beizubehalten und nutzte dann den Dateisystemumleitungsmechanismus, um 32-Bit-Programmen den automatischen Zugriff auf einen anderen Satz von Systemdateien zu ermöglichen.
Windows Latest veröffentlichte am 20. Oktober 2026 einen Artikel, der dieses Problem vorstellte und den relevanten Mechanismus in Verbindung mit den offiziellen technischen Dokumenten von Microsoft erläuterte. In dem Bericht wurde darauf hingewiesen, dass dieses Design das langjährige Beharren von Windows auf Softwarekompatibilität voll und ganz widerspiegelt: Auch wenn die alte Benennungsmethode nicht mehr intuitiv ist, tendiert Microsoft dazu, die ursprüngliche Struktur beizubehalten und das Problem über die Kompatibilitätsschicht zu lösen, solange vorschnelle Änderungen dazu führen können, dass eine große Anzahl von Programmen nicht ausgeführt werden kann.
Um dieses Design zu verstehen, müssen Sie zu den Anfängen von Windows zurückkehren.
In der 16-Bit-Windows-Ära wurden Systemdateien hauptsächlich im Verzeichnis C:WindowsSystem gespeichert. Als Microsoft 32-Bit-Windows startete, benötigte das System ein neues Verzeichnis, um 32-Bit-Systemdateien aufzunehmen, daher wurde C:WindowsSystem32 verwendet. Die „32“ hängt tatsächlich mit der damaligen 32-Bit-Systemarchitektur zusammen.
Aber als 64-Bit-Windows herauskam, wurde es kompliziert. Viele Softwareprogramme haben System32 in den Programmcode einprogrammiert und verwenden diesen Pfad direkt, um auf Systemdateien zuzugreifen, anstatt das richtige Systemverzeichnis dynamisch über die von Windows bereitgestellte Systemschnittstelle abzurufen.
Wenn Microsoft beim Starten von 64-Bit-Windows System32 direkt in System64 umbenennt, können viele alte Programme, Installationsprogramme und Batch-Skripte möglicherweise nicht die benötigten Systemdateien finden. Selbst wenn Entwickler die Software neu kompilieren, können sie möglicherweise nicht alle hartcodierten Pfade rechtzeitig reparieren.
Noch problematischer ist, dass einige Software nach dem Upgrade auf eine 64-Bit-Version immer noch standardmäßig entsprechende Systemkomponenten von System32 liest. Wenn Microsoft System32 so ändert, dass nur 32-Bit-Dateien gespeichert werden, können diese 64-Bit-Programme die erforderlichen dynamischen Linkbibliotheken nicht normal laden.
Daher entschied sich Microsoft schließlich, den historischen Namen System32 beizubehalten und es Dateien speichern zu lassen, die der nativen Architektur des Betriebssystems in 64-Bit-Windows entsprechen. Für die Mainstream-x64-Version von Windows 11 bedeutet dies, dass System32 die 64-Bit-Version der Systemkomponenten speichert, während die 32-Bit-Version in einem anderen Verzeichnis abgelegt wird.
Dieses Verzeichnis ist SysWOW64.
WOW64 ist die Abkürzung für „Windows 32-bit on Windows 64-bit“, ein Kompatibilitätsmechanismus zum Ausführen von 32-bit-Windows-Anwendungen unter 64-bit-Windows. Die „64“ in SysWOW64 bezieht sich auf die 64-Bit-Windows-Umgebung, in der sie sich befindet, nicht darauf, dass die Datei selbst 64-Bit ist. Mit anderen Worten: Der Name beschreibt die Plattform, auf die der Kompatibilitätsmechanismus abzielt, und nicht die Anzahl der Bits in der Binärdatei im Verzeichnis.
Der leitende Ingenieur von Microsoft, Raymond Chen, erklärte einmal in einem technischen Artikel, dass die „32“ in System32 nach und nach zu einem historischen Legacy-Namen geworden sei, genau wie einige Markennamen aufgrund der langfristigen Verwendung dennoch erhalten bleiben, auch wenn sie die ursprüngliche Bedeutung nicht mehr vollständig widerspiegeln.
Wenn das gesamte System neu gestaltet werden kann, glaubt er, dass ein idealerer Verzeichnisname etwa SysExec sein könnte, das zum Speichern ausführbarer Dateien verwendet wird, die der aktuellen Systemarchitektur entsprechen. Aber Windows gibt es schon seit Jahrzehnten und System32 ist seit langem ein fester Pfad, auf den unzählige Programme angewiesen sind, sodass die potenziellen Risiken einer Namensänderung die Vorteile der Benennung bei weitem überwiegen.
Neben der Verzeichnisbenennung muss 64-Bit-Windows auch ein praktischeres Problem lösen: 32-Bit-Programme können 64-Bit-Dynamic-Link-Bibliotheken nicht direkt laden, und 64-Bit-Programme können 32-Bit-Dynamic-Link-Bibliotheken nicht direkt laden.
Kernel32.dll ist beispielsweise eine wichtige Systemkomponente von Windows. Dateien mit demselben Namen finden sich in System32 und SysWOW64, sie sind jedoch für unterschiedliche Architekturen kompiliert und können nicht einfach ausgetauscht werden. Als Windows Latest diese beiden Verzeichnisse im Windows 11 26H2-System überprüfte, stellte es auch Unterschiede in der Größe der entsprechenden Dateien fest.
Wenn ein 32-Bit-Programm die 64-Bit-Version direkt in System32 lädt, kann es aufgrund einer inkompatiblen Binärarchitektur möglicherweise nicht ausgeführt werden. Um diese Situation zu vermeiden, hat Windows den WOW64-Dateisystem-Redirector eingeführt.
Wenn ein 32-Bit-Programm unter 64-Bit-Windows versucht, auf C:WindowsSystem32 zuzugreifen, leitet das System die Zugriffsanforderung normalerweise automatisch an C:WindowsSysWOW64 um. Dieser Vorgang ist für das Programm selbst grundsätzlich transparent, es denkt immer noch, dass es auf System32 zugreift, und das Betriebssystem findet hinter den Kulissen die richtige 32-Bit-Datei dafür.
In der offiziellen Dokumentation von Microsoft heißt es eindeutig, dass das System32-Verzeichnis in 64-Bit-Windows für 64-Bit-Anwendungen reserviert ist und WOW64 dafür verantwortlich ist, den Zugriff von 32-Bit-Programmen auf einige Systempfade auf die entsprechenden 32-Bit-Verzeichnisse umzuleiten.
Dieser Mechanismus betrifft nicht nur die dynamische Linkbibliothek des Systems, sondern wirkt sich auch auf einige Systemtools aus. Wenn beispielsweise ein 32-Bit-Programm auf bestimmte Tools im Windows-Verzeichnis zugreift, wird es möglicherweise auf die entsprechende Version in SysWOW64 umgeleitet. Dies verhindert, dass 32-Bit-Programme 64-Bit-Tools missbrauchen oder falsche Vorgänge ausführen, wenn die Betriebssystemarchitektur nicht übereinstimmt.
WOW64 kümmert sich auch um Kompatibilitätsprobleme wie Registrierungszugriff und Programminstallationspfade. Für 32-Bit-Anwendungen kann Windows eine separate Registrierungsansicht bereitstellen. Ein typischer Speicherort ist HKEY_LOCAL_MACHINESoftwareWow6432Node. Außerdem verweist das System den Programmdateipfad von 32-Bit-Programmen normalerweise auf C:Programme (x86), sodass Software unterschiedlicher Architekturen weitestgehend separat verwaltet werden kann.
Zusammen bilden diese Mechanismen einen Teil des Windows-Kompatibilitätssystems, das es ermöglicht, dass eine große Anzahl von Software, die für frühe 32-Bit-Windows geschrieben wurde, weiterhin auf 64-Bit-Windows 11 läuft, ohne dass Entwickler den gesamten Code für jedes alte Programm neu schreiben müssen.
Die Dateisystemumleitung kann jedoch auch zu Situationen führen, die Entwickler leicht verwirren können.
Zum Beispiel eine 32-Bit-Eingabeaufforderung und eine 64-Bit-Eingabeaufforderung: Selbst wenn sie den scheinbar identischen Pfad für den Zugriff auf C:WindowsSystem32kernel32.dll verwenden, können die tatsächlich erhaltenen Dateien unterschiedlich sein. Ersteres wird normalerweise auf SysWOW64 umgeleitet, während letzteres direkt auf System32 zugreift.
Matt Pitrek, ein ehemaliges Mitglied des Microsoft Visual Studio-Teams, erwähnte in einem technischen Artikel, dass er auch Zeit damit verbracht habe, das Problem zu beheben, weil er verwirrende Ergebnisse erhielt, als die 32-Bit-Eingabeaufforderung Dateien mit demselben Namen in zwei Verzeichnissen auflistete. Dies zeigt, dass die Dateisystemumleitung zwar die Softwarekompatibilität aufrechterhalten kann, aber auch das Debuggen und die Entwicklung des Systems komplizierter macht.
Um einige spezielle Situationen zu lösen, stellt Microsoft auch einen virtuellen Pfad namens Sysnative bereit. Wenn ein 32-Bit-Programm wirklich auf das native System32-Verzeichnis von 64-Bit-Windows zugreifen muss, kann es C:WindowsSysnative verwenden, um die übliche Dateisystemumleitung zu umgehen.
Es ist zu beachten, dass es sich bei Sysnative nicht um einen echten Ordner auf der Festplatte handelt, sondern um einen speziell von Windows bereitgestellten Pfadalias. 64-Bit-Anwendungen können diesen Alias nicht wie 32-Bit-Programme verwenden. Wenn Benutzer also direkt im Datei-Explorer nach Sysnative suchen, werden sie möglicherweise feststellen, dass das System Sie darauf hinweist, dass der Pfad nicht existiert.
Microsoft listet außerdem eine Reihe von System32-Unterverzeichnissen auf, die nicht von der regulären Dateisystemumleitung betroffen sind, darunter:
C:WindowsSystem32catroot
C:WindowsSystem32catroot2
C:WindowsSystem32driverstore
C:WindowsSystem32driversetc
C:WindowsSystem32logfiles
C:WindowsSystem32spool
Diese Verzeichnisse umfassen Funktionen wie Systemkomponentenverzeichnisse, Treiberspeicher, Netzwerkkonfigurationsdateien, Protokollierung und Drucken. Die Microsoft-Dokumentation listet diese Ausnahmepfade klar auf, bietet jedoch keine einheitliche Erklärung der spezifischen Designgründe für jede Ausnahme. Windows Latest geht davon aus, dass einige dieser Verzeichnisse möglicherweise Daten enthalten, auf die Programme mit unterschiedlichen Architekturen gemeinsam zugreifen müssen, beispielsweise die Hosts-Datei in driversetc.
Zusätzlich zur x64-Plattform hat der Kompatibilitätsmechanismus von Windows auf der Arm-Architektur auch ein ähnliches Multi-Verzeichnis-Design erfahren.
In einigen frühen Windows on Arm-Systemen verwenden 32-Bit-x86-Programme SysWOW64, während 32-Bit-Arm-Programme über SysArm32 auf entsprechende Systemkomponenten zugreifen können. Da sich die Arm-Plattform mit Kompatibilitätsproblemen zwischen verschiedenen Befehlssatzarchitekturen auseinandersetzen muss, verwendet Windows auch entsprechende Simulations- und Konvertierungsmechanismen.
In der neuesten Arm-Entwicklungsdokumentation von Microsoft heißt es jedoch, dass Windows on Arm keine 32-Bit-Arm-Anwendungen mehr unterstützt und zugehörige Systembinärdateien ebenfalls aus dem SysArm32-Verzeichnis entfernt werden. Gleichzeitig können normale x86-Anwendungen weiterhin über den Kompatibilitätsmechanismus ausgeführt werden, und einige x86-Programme werden von der Prism-Emulationstechnologie unterstützt.
Dies zeigt auch, dass das Windows-Kompatibilitätssystem nicht völlig statisch ist. Da sich Hardwareplattformen und Software-Ökosysteme ändern, wird Microsoft die Unterstützung für einige alte Architekturen immer noch einstellen, aber für Anwendungen, die immer noch weit verbreitet sind, wird das Unternehmen versuchen, die Kompatibilität so weit wie möglich aufrechtzuerhalten.
Aus technischer Sicht ist die Benennung von System32 und SysWOW64 tatsächlich nicht intuitiv genug. Für normale Benutzer ist es selbstverständlich zu glauben, dass 64-Bit-Dateien im Verzeichnis gespeichert sind, wenn sie „64“ sehen. Aber in Windows spiegeln Verzeichnisnamen eher den Verlauf wider als eine Reihe von Regeln, die von Grund auf so entwickelt wurden, dass sie der Intuition folgen.
Der Hauptgrund, warum Microsoft die beiden Verzeichnisse nicht einfach umbenannt hat, war die Kompatibilität. Windows muss eine Menge historischer Software ausführen, und diese Programme sind möglicherweise auf feste Pfade, veraltete Systemschnittstellen und bestimmte Binärdateilayouts angewiesen. Eine rücksichtslose Änderung dieser Infrastrukturen kann zu Fehlern bei der Softwareinstallation und Anomalien bei Systemtools führen und sogar Geschäftsprozesse beeinträchtigen, die auf alten Komponenten basieren.
Daher entschied sich Microsoft, das Problem durch Mechanismen wie Dateisystemumleitung, Registrierungsumleitung und virtuelle Pfade zu lösen, anstatt das Verzeichnisbenennungssystem vollständig neu zu erstellen.
Dieses Design ist nicht perfekt, spiegelt aber einen wichtigen Unterschied im Entwicklungspfad von Windows und anderen Betriebssystemen wider: Windows muss immer ein Gleichgewicht zwischen kontinuierlicher Modernisierung und Kompatibilität mit jahrzehntealter Software finden. Die scheinbar umgekehrte Benennung von System32 und SysWOW64 ist eine typische Spur, die diese langfristige Kompatibilitätsstrategie hinterlässt.
Kommentare