Pourquoi les DLL 64 bits vont-elles à System32 et les DLL 32 bits à SysWoW64 sur Windows 64 bits?


227

Je voudrais savoir quand devons-nous placer un fichier sous

C: \ Windows \ System32 ou C: \ Windows \ SysWOW64, sur un système Windows 64 bits.

J'avais deux DLL, une pour 32 bits, une pour 64 bits.

Logiquement, je pensais placer la DLL 32 bits sous C: \ Windows \ System32 et la DLL 64 bits sous C: \ Windows \ SysWOW64.

À ma grande surprise, c'est l'inverse ! Celui 32 bits va dans C: \ Windows \ SysWOW 64 , et la DLL 64 bits va dans C: \ Windows \ System 32 .

Des trucs très déroutants. Quelle est la raison derrière cela?


2
De plus, ceci: Windows regarde dans le répertoire de travail actuel ainsi que dans le PATH du système. Il n'y a aucun moyen de spécifier le contraire. Oh attendez, il y en a. Vous pouvez intégrer le chemin de recherche dans votre DLL. Il s'agit d'un champ de 8 octets de long. Oui. 8 caractères.
Jeroen Baert

Cela ne semble pas être vrai sous Windows 7. Exécution d'un fichier sur une DLL dans le fichier system32 C: \ Windows \ system32 \ user32.dll C: \ Windows \ system32 \ user32.dll; Exécutable PE32 pour MS Windows (DLL) (GUI) Intel 80386 32 bits Mais pour une DLL 64 bits, il imprime l'exécutable PE32 + pour MS Windows (DLL) (console) Assemblage mono / .Net Notez que cette DLL n'est pas un .Net Assemblée. Il s'agit d'une DLL native.
user877329


11
Entretien avec un ex-Microsoftie . (Pour une explication sérieuse de la façon dont cela s'est produit, voir cette réponse .)
Tgr

superuser.com/a/157301/241386 "Raisons de compatibilité ascendante. Beaucoup d'applications supposent des choses qu'elles ne devraient pas assumer et des chemins de code en dur"
phuclv

Réponses:


225

Je crois que l'intention était de renommer System32, mais tellement d'applications codées en dur pour ce chemin, qu'il n'était pas possible de le supprimer.

SysWoW64 n'était pas destiné aux DLL des systèmes 64 bits, c'est en fait quelque chose comme "Windows sur Windows64", ce qui signifie les bits dont vous avez besoin pour exécuter des applications 32 bits sur des fenêtres 64 bits.

Cet article explique un peu:

"Windows x64 possède un répertoire System32 qui contient des DLL 64 bits (sic!). Ainsi, les processus natifs avec un bit de 64 trouvent" leurs "DLL là où ils les attendent: dans le dossier System32. Un deuxième répertoire, SysWOW64, contient les 32 DLL de bits. Le redirecteur du système de fichiers fait la magie de masquer le véritable répertoire System32 pour les processus 32 bits et d'afficher SysWOW64 sous le nom de System32. "

Edit: Si vous parlez d'un programme d'installation, vous ne devriez vraiment pas coder en dur le chemin d'accès au dossier système. Au lieu de cela, laissez Windows s'en occuper pour vous selon que votre programme d'installation s'exécute ou non sur la couche d'émulation.


27
Ugh, je viens de rencontrer cette bizarrerie aujourd'hui. Quelle chose trompeuse qu'ils ont faite.
Andy White

16
Ran dans cela aujourd'hui aussi ... si déroutant - Glut 32 bits dll va dans / SysWOW64, Glut 64 bits dll va dans / System32. Quelqu'un devrait l'écrire. Sur Internet.
Jeroen Baert

8
La bonne nouvelle est que, comme exemple du génie de l'ingénierie de Microsoft, il s'agit à peu près d'auto-documentation.
Spike0xff

8
Une chose que je ne comprends pas, c'est que si le système de fichiers peut dire qu'il s'agit d'une application 32 bits et la rediriger vers le SysWOW64dossier, pourquoi ne pourrait-il pas plutôt détecter une application 64 bits et rediriger vers un System64?!
Cole Johnson

6
System32 est la version Windows 32 bits des DLL système. Le système est la version 16 bits. La même société qui nous a donné Windows 8 nous a donné SysWow64 pour les DLL 32 bits et System32 pour les DLL 64 bits lors de l'exécution sur un système d'exploitation 64 bits. Dans les systèmes 64 bits, le dossier System est toujours l'ancien code indésirable 16 bits, seul le System32 n'est pas 32 bits comme suggéré, et le contenu 32 bits est dans le répertoire System avec 64 dans le nom. Je ne vois pas comment cela peut aider quelqu'un. cela complique les choses et brise tout. Tout pour éviter aux gens d'adapter "System32" codé en dur à "System64" lors de la conversion en 64 bits. Idiotie
Armand

26

Je devrais ajouter: vous ne devriez pas mettre vos DLL dans \ system32 \ de toute façon! Modifiez votre code, modifiez votre installateur ... trouvez une maison pour vos bits qui n'est PAS n'importe où sous c: \ windows \

Par exemple, votre programme d'installation place vos DLL dans:

\program files\<your app dir>\

or

\program files\common files\<your app name>\

( Remarque : La façon dont vous effectuez cette opération consiste à utiliser l'environnement var:% ProgramFiles% ou% ProgramFiles (x86)% pour trouver où se trouvent Program Files .... vous ne supposez pas qu'il s'agit de c: \ program files \ .. ..)

puis définit une balise de registre:

HKLM\software\<your app name>
-- dllLocation

Le code qui utilise vos DLL lit le registre, puis établit un lien dynamique vers les DLL à cet emplacement.

Ce qui précède est la façon intelligente de procéder.

Vous n'installez jamais vos DLL ou des DLL tierces dans \ system32 \ ou \ syswow64. Si vous devez charger statiquement, vous mettez vos dlls dans votre répertoire exe (où ils seront trouvés). Si vous ne pouvez pas prédire le répertoire exe (par exemple, un autre exe va appeler votre dll), vous devrez peut-être mettre votre répertoire dll dans le chemin de recherche (évitez-le si possible!)

system32 et syswow64 sont pour les fichiers fournis par Windows ... pas pour les fichiers de quiconque . La seule raison pour laquelle les gens ont pris la mauvaise habitude de mettre des choses là-dedans, c'est parce qu'elles sont toujours dans le chemin de recherche, et de nombreuses applications / modules utilisent des liens statiques. (Donc, si vous y arrivez vraiment, le vrai péché est la liaison statique - c'est un péché dans le code natif et le code managé - toujours toujours toujours dynamiquement!)


9
+1 ... mais j'ajouterais que vous devez utiliser des variables comme% PROGRAMFILES% not \ Program Files \
Rod MacPherson

À l'époque de XP, c'était une pratique courante (et suggérée) pour les développeurs d'utiliser le registre pour de telles choses. Avec Windows 7, ce n'est plus vrai! Pour des raisons d'UAC, plusieurs sessions utilisateur, etc. Le registre de Windows 7 doit être utilisé avec parcimonie et discrétion par les développeurs.
ryyker

@RodMacPherson Ma réponse a été améliorée pour prendre en compte votre suggestion. Vous avez raison!
Jonesome Reinstate Monica

Après réflexion, je pense que cela répond mieux à la question - "Quand devons-nous placer un fichier sous% SYSTEMROOT%". Jamais. Cette réponse ne satisfait pas la curiosité du dossier syswow64, mais c'est celle que les développeurs ont vraiment besoin de lire.
Thomas

7

Ran dans le même problème et fait des recherches pendant quelques minutes.

On m'a appris à utiliser Windows 3.1 et DOS, vous vous souvenez de ces jours? Peu de temps après avoir travaillé strictement avec les ordinateurs Macintosh, j'ai ensuite recommencé à basculer vers Windows après avoir acheté une machine x64 bits.

Il y a des raisons réelles derrière ces changements (certains diraient une signification historique), qui sont nécessaires pour que les programmeurs continuent leur travail.

La plupart des changements sont mentionnés ci-dessus:

  • Program Files contre Program Files (x86)

    Au début, les fichiers 16 / 86bit étaient écrits sur des processeurs Intel «86».

  • System32signifie vraiment System64(sur Windows 64 bits)

    Lorsque les développeurs ont commencé à travailler avec Windows7, il y avait plusieurs problèmes de compatibilité là où d'autres applications étaient stockées.

  • SysWOW64 signifie vraiment SysWOW32

    Essentiellement, en anglais simple, cela signifie «Windows sur Windows dans une machine 64 bits» . Chaque dossier indique où se trouvent les DLL pour les applications qu'ils souhaitent utiliser.

Voici deux liens avec toutes les informations de base dont vous avez besoin:

Espérons que cela arrange les choses!


4
Si vous voulez être pris au sérieux, vous devriez probablement atténuer l'argot et améliorer la grammaire. En outre, vous voudrez peut-être structurer un peu plus votre réponse, utilisez des paragraphes.
Klas Mellbourn

2
@Crispy a nettoyé la réponse. À l'avenir, vous devriez considérer ce que Klas suggère et formater votre réponse pour augmenter les chances de votes positifs. :)
RekindledPhoenix

L'OP doit être complètement réécrit, voire supprimé. C'est trompeur et pas vraiment utile.
Jonesome réintègre Monica

5
SysWOW64 signifie en fait: [Sys] tem [W] indows 32 bits [o] n [W] indows [64] -bit ainsi la forme abrégée SysWoW64 (qui n'a vraiment aucun sens, et Microsoft avait laissé System32 pour les trucs 32 bits et créé un System64, il n'y aurait vraiment pas de problèmes de compatibilité. Ce que Microsoft fait dans le sandbox WoW est de créer une redirection en mémoire à partir d'un accès 32 bits vers System32 en tant que demande à SysWoW64 ... comment est-ce que ce n'est pas plus compliqué que de simplement exposer le système de fichiers à l'état brut sans devoir le remapper comme par magie pour les différentes plateformes? Comme indiqué dans un commentaire précédent - Idiotie
Armand

1
La réponse apporte plus de malentendu que de clarté sur la question, le commentaire d'Armands est une bonne explication.
nahab

5

System32 est l'endroit où Windows a historiquement placé toutes les DLL 32 bits, et System était pour les DLL 16 bits. Lorsque Microsoft a créé le système d'exploitation 64 bits, tous ceux que je connais s'attendaient à ce que les fichiers résident sous System64, mais Microsoft a décidé qu'il était plus logique de placer les fichiers 64 bits sous System32. Le seul raisonnement que j'ai pu trouver, c'est qu'ils voulaient que tout ce qui était 32 bits fonctionne dans un Windows 64 bits sans avoir à changer quoi que ce soit dans les programmes - juste recompiler, et c'est fait. La façon dont ils ont résolu ce problème, afin que les applications 32 bits puissent toujours fonctionner, a été de créer un sous-système Windows 32 bits appelé Windows32 sur Windows64. En tant que tel, l'acronyme SysWOW64 a été créé pour le répertoire système du sous-système 32 bits. Le Sys est l'abréviation de System et WOW64 est l'abréviation de Windows32OnWindows64.
Étant donné que Windows 16 est déjà séparé de Windows 32, il n'était pas nécessaire d'avoir une équivalence Windows 16 sur Windows 64. Dans le sous-système 32 bits, lorsqu'un programme utilise des fichiers du répertoire system32, il obtient en fait les fichiers du répertoire SysWOW64. Mais le processus est défectueux.

C'est un design horrible. Et d'après mon expérience, j'ai dû faire beaucoup plus de changements pour écrire des applications 64 bits, que changer simplement le répertoire System32 pour lire System64 aurait été un très petit changement, et que les directives de précompilateur sont censées gérer.


2

D'autres personnes ont déjà bien expliqué cette énigme ridicule ... et je pense que Chris Hoffman a fait un travail encore meilleur ici: https://www.howtogeek.com/326509/whats-the-difference-between-the- system32-and-syswow64-folder-in-windows /

Mes deux pensées:

  1. Nous faisons tous des erreurs stupides à courte vue dans la vie. Lorsque Microsoft a nommé son (à l'époque) répertoire DLL Win32 "System32", cela avait du sens à l'époque ... ils n'ont tout simplement pas pris en considération ce qui se passerait si / quand une version 64 bits (ou 128 bits) de leur système d'exploitation a été développé plus tard - et le problème de compatibilité ascendante massif qu'un tel nom de répertoire causerait. Le recul est toujours de 20 à 20, donc je ne peux pas vraiment les blâmer (trop) pour une telle erreur. ... CEPENDANT ... Quand Microsoft a développé plus tard leur système d'exploitation 64 bits, même avec le recul, pourquoi oh pourquoi feraient-ils non seulement exactement la même erreur à courte vue, mais aggravent encore la situation en donnant à dessein un tel nom trompeur?!? Honte à eux!!! Pourquoi ne pas au moins nommer le répertoire "SysWin32OnWin64" pour éviter toute confusion?! ? Et que se passe-t-il lorsqu'ils finissent par produire un système d'exploitation 128 bits ... alors où vont-ils placer leurs DLL 32 bits, 64 bits et 128 bits?!?

  2. Toute cette logique me semble encore complètement viciée. Sur les versions 32 bits de Windows, System32 contient des DLL 32 bits; sur les versions 64 bits de Windows, System32 contient des DLL 64 bits ... afin que les développeurs n'aient pas à apporter de modifications au code, n'est-ce pas? Le problème avec cette logique est que ces développeurs créent maintenant des applications 64 bits nécessitant des DLL 64 bits ou qu'ils créent des applications 32 bits nécessitant des DLL 32 bits ... de toute façon, ne sont-ils toujours pas vissés? Je veux dire, s'ils font encore une application 32 bits, pour qu'elle fonctionne maintenant sur un Windows 64 bits, ils devront maintenant faire un changement de code pour trouver / référencer la même ancienne DLL 32 bits qu'ils utilisé auparavant (maintenant situé dans SysWOW64). Ou, s'ils travaillent sur une application 64 bits, ils devront de toute façon réécrire leur ancienne application pour le nouveau système d'exploitation ... donc une recompilation / reconstruction allait être nécessaire de toute façon !!

Microsoft me fait parfois mal parfois.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.