Pourquoi les DLL 64 bits vont-elles dans System32 et les DLL 32 bits dans SysWoW64 sous Windows 64 bits ?

Question

J'aimerais savoir à quel moment il faut 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, j'ai pensé placer la DLL 32 bits sous la rubrique C:\Windows\System32 et la DLL 64 bits sous C:\Windows\SysWOW64.

A ma grande surprise, c'est dans l'autre sens ! Le site 32 -Le premier bit va dans C:\Windows\SysWOW 64 et le 64 -Le DLL de bit va dans C:\Windows\System 32 .

C'est très déroutant. Quelle est la raison de tout cela ?

Answer 1

Je crois que l'intention était de renommer System32, mais tant d'applications ont codé 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", c'est-à-dire les bits dont vous avez besoin pour exécuter des applications 32 bits sur un Windows 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 bitness de 64 trouvent "leurs" DLLs là où ils les attendent : dans le répertoire System32. Un deuxième répertoire, SysWOW64, contient les DLL 32 bits. Le redirecteur du système de fichiers fait la magie de cacher le vrai répertoire System32 pour les processus 32 bits et d'afficher SysWOW64 sous le nom de System32."

Edit : Si vous parlez d'un installateur, vous devez vraiment ne devrait pas coder en dur le chemin d'accès au dossier système. Au lieu de cela, laissez Windows s'en charger pour vous en fonction du fait que votre installateur fonctionne ou non sur la couche d'émulation.

Answer 2

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

Par exemple, votre installateur place vos dlls dans :

\program files\<your app dir>\

or

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

( Note : La façon dont vous faites ça est d'utiliser la variable d'environnement : %ProgramFiles% ou %ProgramFiles(x86)% pour trouver où se trouve Program Files.... vous ne devez pas supposer que c'est c : \program fichiers\ ....)

puis définit une balise de registre :

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

Le code qui utilise vos dlls lit le registre, puis établit des liens dynamiques avec les dlls qui se trouvent à cet endroit.

Ce qui précède est la meilleure solution.

Vous n'installez jamais vos dlls, ou celles d'un tiers dans \system32\ ou \syswow64. Si vous devez charger statiquement, vous placez vos dlls dans votre répertoire exe (où elles seront trouvées). Si vous ne pouvez pas prévoir le répertoire de l'exe (par exemple, un autre exe va appeler votre dll), vous devrez peut-être placer votre répertoire de dll dans le chemin de recherche (évitez cela si possible !).

system32 et syswow64 sont pour les fichiers fournis par Windows... pas pour les fichiers de quelqu'un d'autre . La seule raison pour laquelle les gens ont pris la mauvaise habitude de mettre des choses à cet endroit est qu'elles se trouvent toujours dans le chemin de recherche, et que de nombreuses applications/modules utilisent la liaison statique. (Donc, si on y réfléchit bien, le vrai péché est la liaison statique -- c'est un péché dans le code natif et le code géré -- toujours toujours lier dynamiquement).

Answer 3

J'ai rencontré le même problème et j'ai fait des recherches pendant quelques minutes.

On m'a appris à utiliser Windows 3.1 et DOS, vous vous souvenez de cette époque ? Peu après, j'ai travaillé avec des ordinateurs Macintosh strictement pendant un certain temps, puis j'ai commencé à revenir à Windows après avoir acheté une machine x64-bit.

Il y a des raisons réelles derrière ces changements (certains diraient qu'ils ont une importance historique), qui sont nécessaires pour que les programmeurs puissent continuer leur travail.

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

• Program Files vs Program Files (x86)

  Au début, les fichiers 16/86 bits étaient écrits sur des processeurs Intel '86'.

• System32 signifie vraiment System64 (sur Windows 64 bits)

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

• SysWOW64 signifie vraiment SysWOW32

  En clair, cela signifie que Windows sur Windows dans une machine 64 bits". . Chaque dossier indique où se trouvent les DLL pour les applications qui souhaitent les utiliser.

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

• Redirecteur de système de fichiers MSDN

• SysWow64 expliqué

J'espère que cela va clarifier les choses !

Answer 4

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, tout le monde, à ma connaissance, s'attendait à 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 - il suffit de 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 On Windows64. C'est ainsi que l'acronyme SysWOW64 a été créé pour le répertoire System du sous-système 32 bits. Sys est l'abréviation de System, et WOW64 est l'abréviation de Windows32OnWindows64.
Puisque Windows 16 est déjà séparé de Windows 32, il n'y avait pas besoin d'une équivalence Windows 16 sur Windows 64. Dans le sous-système 32 bits, lorsqu'un programme va utiliser des fichiers du répertoire system32, il obtient en fait les fichiers du répertoire SysWOW64. Mais le processus est défectueux.

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

Answer 5

D'autres personnes ont déjà fait un bon travail d'explication de 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-folders-in-Windows/

Mes deux pensées :

1. Nous faisons tous des erreurs stupides et irréfléchies dans la vie. Lorsque Microsoft a nommé son répertoire DLL Win32 (à l'époque) "System32", cela avait du sens à l'époque... ils n'ont 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 serait développée plus tard - et l'énorme problème de rétrocompatibilité qu'un tel nom de répertoire causerait. La rétrospective est toujours 20-20, donc je ne peux pas vraiment les blâmer (trop) pour une telle erreur. ...CEPENDANT... Lorsque Microsoft a développé plus tard son système d'exploitation 64 bits, même avec le bénéfice du recul, pourquoi oh pourquoi ont-ils fait non seulement exactement la même erreur à court terme, mais l'ont-ils aggravée en lui donnant à dessein un nom aussi trompeur ? !? Honte à eux ! !! Pourquoi ne pas au moins nommer le répertoire "SysWin32OnWin64" pour éviter toute confusion ? !? Et que se passera-t-il quand ils produiront un jour un système d'exploitation 128 bits... alors où mettront-ils leurs DLL 32 bits, 64 bits et 128 bits ? !?

2. Toute cette logique me semble encore complètement erroné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 à modifier le code, n'est-ce pas ? Le problème avec cette logique est que ces développeurs sont soit en train de créer des applications 64 bits nécessitant des DLL 64 bits, soit en train de créer des applications 32 bits nécessitant des DLL 32 bits ... dans les deux cas, ne sont-ils pas encore dans la merde ? Je veux dire, s'ils font toujours 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 vieille DLL 32 bits qu'ils utilisaient avant (maintenant située dans SysWOW64). Ou, s'ils travaillent sur une application 64 bits, ils vont devoir réécrire leur ancienne application pour le nouveau système d'exploitation de toute façon ... donc une recompilation/reconstruction allait être nécessaire de toute façon !!!

Microsoft me fait mal parfois.