Pourquoi Windows place-t-il les fichiers système 64 bits dans System32 et les fichiers 32 bits dans SysWOW64 ?

📅 2026-10-20

Résumé :

Dans Windows 11, il existe une conception qui a longtemps dérouté les utilisateurs : sur un système 64 bits, C:WindowsSystem32 stocke en fait les fichiers système 64 bits, tandis que le répertoire C:WindowsSysWOW64 avec "64" dans le nom stocke les fichiers 32 bits à la place. Pour les utilisateurs qui ne connaissent pas l’historique de Windows, ce schéma de dénomination peut sembler complètement inversé.

Les ingénieurs de Microsoft ont récemment expliqué à nouveau les raisons de cette conception. La réponse n'est pas que Microsoft a simplement inversé les noms de répertoires, mais plutôt pour éviter de casser de nombreux logiciels qui reposaient sur les anciens chemins. Lorsque Windows a migré d'une architecture 32 bits vers une architecture 64 bits, il a choisi de conserver le nom de répertoire System32 déjà largement utilisé, puis a utilisé le mécanisme de redirection du système de fichiers pour permettre aux programmes 32 bits d'accéder automatiquement à un autre ensemble de fichiers système.

Windows Latest a publié un article le 20 octobre 2026 qui présentait ce problème et expliquait le mécanisme correspondant en conjonction avec les documents techniques officiels de Microsoft. Le rapport souligne que cette conception reflète pleinement l'insistance à long terme de Windows sur la compatibilité logicielle : même si l'ancienne méthode de dénomination n'est plus intuitive, tant que des modifications irréfléchies peuvent empêcher un grand nombre de programmes de fonctionner, Microsoft a tendance à conserver la structure d'origine et à résoudre le problème via la couche de compatibilité.

Pour comprendre cette conception, vous devez revenir aux débuts de Windows.

À l'ère Windows 16 bits, les fichiers système étaient principalement stockés dans le répertoire C:WindowsSystem. Lorsque Microsoft a lancé Windows 32 bits, le système avait besoin d'un nouveau répertoire pour accueillir les fichiers système 32 bits, c'est pourquoi C:WindowsSystem32 a été utilisé. Le « 32 » est en effet lié à l’architecture système 32 bits de l’époque.

Mais lorsque Windows 64 bits est sorti, les choses se sont compliquées. Un grand nombre de logiciels ont programmé System32 dans le code du programme et utilisent directement ce chemin pour accéder aux fichiers système au lieu d'obtenir dynamiquement le répertoire système correct via l'interface système fournie par Windows.

Si Microsoft renomme directement System32 en System64 lors du lancement de Windows 64 bits, de nombreux anciens programmes, installateurs et scripts batch risquent de ne pas être en mesure de trouver les fichiers système dont ils ont besoin. Même si les développeurs recompilent le logiciel, ils ne seront peut-être pas en mesure de corriger tous les chemins codés en dur à temps.

Ce qui est encore plus gênant, c'est que certains logiciels lisent toujours les composants système correspondants de System32 par défaut après avoir été mis à niveau vers une version 64 bits. Si Microsoft modifie System32 pour stocker uniquement les fichiers 32 bits, ces programmes 64 bits ne pourront pas charger normalement les bibliothèques de liens dynamiques requises.

Par conséquent, Microsoft a finalement décidé de conserver le nom historique System32 et de lui permettre de stocker des fichiers correspondant à l'architecture native du système d'exploitation sous Windows 64 bits. Pour la version x64 grand public de Windows 11, cela signifie que System32 stocke la version 64 bits des composants du système, tandis que la version 32 bits est placée dans un autre répertoire.

Ce répertoire est SysWOW64.

WOW64 est l'abréviation de « Windows 32 bits sur Windows 64 bits », qui est un mécanisme de compatibilité permettant d'exécuter des applications Windows 32 bits sur Windows 64 bits. Le « 64 » dans SysWOW64 fait référence à l'environnement Windows 64 bits dans lequel il se trouve, et non au fait que le fichier lui-même soit en 64 bits. En d’autres termes, le nom décrit la plate-forme ciblée par le mécanisme de compatibilité, et non le nombre de bits du binaire du répertoire.

Raymond Chen, ingénieur senior chez Microsoft, a expliqué un jour dans un article technique que le « 32 » dans System32 est progressivement devenu un nom historique, tout comme certains noms de marque, même s'ils ne reflètent plus pleinement la signification originale, seront toujours conservés en raison d'une utilisation à long terme.

Si l'ensemble du système peut être repensé, il pense qu'un nom de répertoire plus idéal pourrait être quelque chose comme SysExec, qui est utilisé pour stocker les fichiers exécutables correspondant à l'architecture système actuelle. Mais Windows existe depuis des décennies et System32 est depuis longtemps une voie fixe sur laquelle s'appuient d'innombrables programmes, de sorte que les risques potentiels liés au changement de nom dépassent de loin les avantages du nom.

En plus de la dénomination des répertoires, Windows 64 bits doit également résoudre un problème plus pratique : les programmes 32 bits ne peuvent pas charger directement les bibliothèques de liens dynamiques 64 bits, et les programmes 64 bits ne peuvent pas charger directement les bibliothèques de liens dynamiques 32 bits.

Par exemple, kernel32.dll est un composant système important de Windows. Des fichiers portant le même nom peuvent être trouvés dans System32 et SysWOW64, mais ils sont compilés pour des architectures différentes et ne peuvent pas être simplement échangés. Lorsque Windows Latest a vérifié ces deux répertoires dans le système Windows 11 26H2, il a également trouvé des différences dans la taille des fichiers correspondants.

Si un programme 32 bits charge directement la version 64 bits dans System32, il risque de ne pas pouvoir s'exécuter en raison d'une architecture binaire incompatible. Pour éviter cette situation, Windows a introduit le redirecteur de système de fichiers WOW64.

Sous Windows 64 bits, lorsqu'un programme 32 bits tente d'accéder à C:WindowsSystem32, le système redirige généralement automatiquement la demande d'accès vers C:WindowsSysWOW64. Ce processus est fondamentalement transparent pour le programme lui-même, il pense toujours qu'il accède à System32 et le système d'exploitation trouve le fichier 32 bits correct dans les coulisses.

La documentation officielle de Microsoft indique clairement que le répertoire System32 dans Windows 64 bits est réservé aux applications 64 bits et que WOW64 est responsable de la redirection de l'accès des programmes 32 bits à certains chemins système vers les répertoires 32 bits correspondants.

Ce mécanisme implique non seulement la bibliothèque de liens dynamiques du système, mais affecte également certains outils système. Par exemple, lorsqu'un programme 32 bits accède à certains outils du répertoire Windows, il peut être redirigé vers la version correspondante dans SysWOW64. Cela empêche les programmes 32 bits d'utiliser à mauvais escient les outils 64 bits ou d'effectuer des opérations incorrectes si l'architecture du système d'exploitation ne correspond pas.

Task-Manager-montre-quelle-invite-de-commande-s'exécute-comme-un-processus-32-bits.jpg

WOW64 gère également les problèmes de compatibilité tels que l'accès au registre et les chemins d'installation des programmes. Pour les applications 32 bits, Windows peut fournir une vue de registre distincte, un emplacement typique est HKEY_LOCAL_MACHINESoftwareWow6432Node. Le système pointe également généralement le chemin des fichiers de programme des programmes 32 bits vers C:Program Files (x86), afin que les logiciels d'architectures différentes puissent être gérés séparément autant que possible.

Ensemble, ces mécanismes font partie du système de compatibilité Windows, permettant à un grand nombre de logiciels écrits pour les premières versions de Windows 32 bits de continuer à fonctionner sur Windows 11 64 bits, sans que les développeurs n'aient à réécrire tout le code de chaque ancien programme.

Cependant, la redirection du système de fichiers peut également entraîner certaines situations qui peuvent facilement dérouter les développeurs.

Par exemple, une invite de commande 32 bits et une invite de commande 64 bits, même si elles utilisent le chemin apparemment identique pour accéder à C:WindowsSystem32kernel32.dll, les fichiers réels obtenus peuvent être différents. Le premier est généralement redirigé vers SysWOW64, tandis que le second accède directement à System32.

Matt Pitrek, un ancien membre de l'équipe Microsoft Visual Studio, a mentionné dans un article technique qu'il avait également passé du temps à résoudre le problème car il obtenait des résultats confus lorsque l'invite de commande 32 bits répertoriait les fichiers portant le même nom dans deux répertoires. Cela montre que même si la redirection du système de fichiers peut maintenir la compatibilité logicielle, elle complique également le travail de débogage et de développement du système.

Pour résoudre certaines situations particulières, Microsoft propose également un chemin virtuel appelé Sysnative. Si un programme 32 bits a vraiment besoin d'accéder au répertoire System32 natif de Windows 64 bits, il peut utiliser C:WindowsSysnative pour contourner la redirection habituelle du système de fichiers.

Il est à noter que Sysnative n'est pas un véritable dossier sur le disque, mais un alias de chemin spécialement fourni par Windows. Les applications 64 bits ne peuvent pas utiliser cet alias comme les programmes 32 bits. Ainsi, lorsque les utilisateurs recherchent Sysnative directement dans l'Explorateur de fichiers, ils peuvent constater que le système indique que le chemin n'existe pas.

32-bit-apps-get-their-own-registry-view-under-WOW6432Node-on-Windows-11.jpg

Microsoft répertorie également un certain nombre de sous-répertoires System32 qui ne sont pas affectés par la redirection normale du système de fichiers, notamment :

C:WindowsSystem32catroot

C:WindowsSystem32catroot2

C:WindowsSystem32driverstore

C:WindowsSystem32driversetc

C:Fichiers journaux WindowsSystem32

C:WindowsSystem32spool

Ces répertoires impliquent des fonctions telles que les répertoires de composants système, le stockage des pilotes, les fichiers de configuration réseau, la journalisation et l'impression. La documentation Microsoft répertorie clairement ces chemins d'exception, mais ne fournit pas d'explication unifiée des raisons de conception spécifiques pour chaque exception. Windows Latest estime que certains de ces répertoires peuvent contenir des données auxquelles des programmes avec des architectures différentes doivent accéder conjointement, comme le fichier hosts dans les pilotes, etc.

En plus de la plate-forme x64, le mécanisme de compatibilité de Windows sur l'architecture Arm a également connu une conception multi-répertoire similaire.

Dans certains premiers systèmes Windows sur Arm, les programmes x86 32 bits utilisent SysWOW64, tandis que les programmes Arm 32 bits peuvent accéder aux composants système correspondants via SysArm32. Étant donné que la plate-forme Arm doit résoudre des problèmes de compatibilité entre différentes architectures de jeux d'instructions, Windows utilise également les mécanismes de simulation et de conversion correspondants.

Cependant, la dernière documentation de développement Arm de Microsoft indique que Windows sur Arm ne prendra plus en charge les applications Arm 32 bits et que les binaires système associés seront également supprimés du répertoire SysArm32. Dans le même temps, les applications x86 ordinaires peuvent toujours fonctionner via le mécanisme de compatibilité, et certains programmes x86 sont pris en charge par la technologie d'émulation Prism.

Sysnative-only-works-for-32-bit-apps-so-64-bit-File-Explorer-cant-find-it.jpg

Cela montre également que le système de compatibilité Windows n'est pas complètement statique. À mesure que les plates-formes matérielles et les écosystèmes logiciels évoluent, Microsoft continuera de supprimer progressivement la prise en charge de certaines anciennes architectures, mais pour les applications encore largement utilisées, la société tentera de maintenir la compatibilité autant que possible.

D'un point de vue technique, la dénomination de System32 et SysWOW64 n'est en effet pas assez intuitive. Pour les utilisateurs ordinaires, il est naturel de penser que les fichiers 64 bits sont stockés dans le répertoire lorsqu'ils voient « 64 ». Mais sous Windows, les noms de répertoires reflètent l’histoire plutôt qu’un ensemble de règles conçues dès le départ pour suivre l’intuition.

La principale raison pour laquelle Microsoft n'a pas simplement renommé les deux répertoires était la compatibilité. Windows doit exécuter de nombreux logiciels historiques, et ces programmes peuvent s'appuyer sur des chemins fixes, des interfaces système héritées et des présentations de fichiers binaires spécifiques. Une modification imprudente de ces infrastructures peut entraîner des échecs d'installation de logiciels, des anomalies des outils système et même affecter les processus métier qui reposent sur d'anciens composants.

Par conséquent, Microsoft a choisi de résoudre le problème via des mécanismes tels que la redirection du système de fichiers, la redirection du registre et les chemins virtuels, plutôt que de reconstruire complètement le système de dénomination des répertoires.

Cette conception n'est pas parfaite, mais elle reflète une différence importante dans le chemin de développement de Windows et des autres systèmes d'exploitation : Windows doit toujours trouver un équilibre entre une modernisation continue et une compatibilité avec des logiciels vieux de plusieurs décennies. La dénomination apparemment inversée de System32 et SysWOW64 est une trace typique laissée par cette stratégie de compatibilité à long terme.

Tags associés

Articles similaires

Commentaires

0/500
Captcha (click to refresh)
Aucun commentaire