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

Question

Je voudrais savoir quand est-ce que nous devons placer un fichier sous

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

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

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

À ma grande surprise, il est l'inverse ! Le 32 -bit on va dans C: \ Windows \ SYSWOW 64 et 64 -bit DLL va dans C: \ Windows \ System 32 .

choses très déroutant. Quelle est la raison derrière cela?

Answer 1

Je crois que l'intention était de renommer System32, mais tant d'applications codées en dur pour ce chemin, qu'il était impossible de l'enlever.

SysWoW64 n'a pas été conçu pour les DLLs des systèmes 64bit, il 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 un ordinateur Windows 64 bits.

Cet article explique un peu:

"Windows 64 bits a un répertoire System32 qui contient les DLL 64 bits processus ainsi natifs avec un nombre de bits de 64 trouver (sic!). « Leurs » DLLs où ils les attendent:. Dans le dossier System32 Un deuxième répertoire, SysWOW64, contient les DLL 32 bits. le système de fichiers redirecteur fait la magie de cacher le vrai répertoire System32 pour les processus 32 bits et montrant SysWOW64 sous le nom de System32. "

Edit: Si vous parlez d'un programme d'installation, vous avez vraiment ne devrait pas hard-code le chemin du dossier système. Au lieu de cela, laissez Windows prendre en charge pour vous en fonction de si oui ou non votre installateur est en cours d'exécution sur la couche d'émulation.

Answer 2

Je dois ajouter: Vous ne devriez pas mettre votre dll dans \ system32 \ quand même! Modifiez votre code, modifiez votre installateur ... trouver une maison pour vos bits qui est nulle part sous c: \ windows \

Par exemple, votre installateur met votre dll dans:

\program files\<your app dir>\

or

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

( Remarque : La façon dont vous avez réellement faire ce est d'utiliser l'environnement var:% ProgramFiles% ou % ProgramFiles (x86)% pour trouver où Program Files est .... vous ne supposez pas qu'elle est c: \ program files \ ....)

et définit ensuite une balise de registre:

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

Le code qui utilise votre dll lit le Registre, puis relie dynamiquement aux DLLs à cet endroit.

Ce qui précède est la façon intelligente d'aller.

Vous n'installez jamais votre dll, ou dll tiers dans \ system32 \ ou \ syswow64. Si vous devez charger statiquement, vous mettez votre dll dans votre exe dir (où ils se trouvent). Si vous ne pouvez pas prédire l'exe dir (par exemple un autre exe va appeler votre dll), vous pouvez avoir à mettre votre répertoire dll dans le chemin de recherche (à éviter si tout poss!)

et syswow64 sont system32 pour Windows fourni des fichiers ... pour personne elses fichiers . Les seuls gens de raison ont pris la mauvaise habitude de mettre des choses là-bas est parce qu'il est toujours dans le chemin de recherche, et de nombreuses applications / modules utilisent la liaison statique. (Donc, si vous avez vraiment à lui, le vrai péché est la liaison statique - ce qui est un péché en code natif et le code managé - toujours toujours toujours un lien dynamique)

Answer 3

Ran dans la même question et fait des recherches ce pendant quelques minutes.

On m'a appris à utiliser Windows 3.1 et DOS, rappelez-vous ces jours? Peu de temps après avoir travaillé avec les ordinateurs Macintosh strictement pendant un certain temps, puis a commencé à se balancer à Windows après l'achat d'une machine x64 bits.

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

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

• Program Files vs Program Files (x86)

  Au début, les 16 / fichiers 86bit ont été écrits sur, '86' processeurs Intel.

• 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 où stockées.

• SysWOW64 signifie vraiment SysWOW32

  Pour l'essentiel, en clair, cela signifie que de Windows sous Windows dans une machine 64 bits '. Chaque dossier est indiquant où les DLL sont situés pour les applications, ils souhaitent les utiliser.

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

• MSDN système de fichiers redirecteur

• SysWow64 Expliqué

Espérons que cela efface les choses!

Answer 4

System32 est historiquement dans lequel Windows placé toutes les DLL 32bit, et le système a été pour les DLL 16bit. Lorsque Microsoft a créé le système d'exploitation 64 bits, tout le monde que je connais les fichiers devrait résider dans System64, mais Microsoft a décidé qu'il était plus logique de mettre des fichiers sous 64bit System32. Le seul raisonnement que j'ai pu trouver, est qu'ils voulaient tout ce qui était 32bit pour travailler dans un Windows 64bit w / o avoir à changer quoi que ce soit dans les programmes - tout recompiler, et il est fait. La façon dont ils ont résolu ce problème, de sorte que les applications 32 bits pourraient encore fonctionner, était 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 court pour Sys est système et WOW64 est l'abréviation de Windows32OnWindows64.
Puisque les fenêtres 16 est déjà séparés à partir de Windows 32, il n'y avait pas besoin d'un Windows 16 sur l'équivalence Windows 64. Au sein du sous-système 32 bits, lorsqu'un programme va utiliser des fichiers à partir du répertoire system32, ils obtiennent effectivement les fichiers du répertoire SysWOW64. Mais le processus est défectueux.

Il est un design horrible. Et dans mon expérience, je devais faire beaucoup plus de changements pour écrire des applications 64 bits, que le simple changement dans le répertoire System32 de lire System64 aurait été un changement très petit, et qui directives pré-compilateur sont destinés à gérer.

Answer 5

D'autres personnes ont déjà fait un bon travail d'expliquer cette énigme ridiculus ... et je pense que Chris Hoffman a fait un travail encore mieux ici: https://www.howtogeek.com/326509/whats-the-difference-between-the- -et-system32 SYSWOW64-dossiers dans windows /

Mes deux pensées:

1. Nous faisons tous des erreurs stupides à courte vue dans la vie. Lorsque Microsoft nommé leur (à l'époque) répertoire Win32 DLL « System32 », il était logique à l'époque ... ils ont juste ne pas prendre en considération ce qui se passerait si / quand un 64 bits (ou 128 bits) Version de leur système d'exploitation développé plus tard mais j'ai - et la question de la compatibilité ascendante massif un nom de répertoire causerait. Hindsight est toujours 20-20, donc je ne peux pas vraiment les blâmer (trop) pour une telle erreur. ... mais ... Lorsque Microsoft plus tard a développer 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 à nouveau, mais le rendre encore pire en donnant Délibérément un tel nom trompeur?!? Honte à eux!!! Pourquoi ne pas au moins le nom en fait le répertoire « SysWin32OnWin64 » pour éviter toute confusion?!? Et ce qui se passe quand ils produisent éventuellement un système d'exploitation 128 bits ... alors où vont-ils mettre leur 32 bits, 64 bits et DLL 128 bits?!?

2. Toutes cette logique semble encore tout à fait erronée pour moi. Sur les versions 32 bits de Windows, System32 contient DLL 32 bits; sur les versions 64 bits de Windows, System32 contient DLL 64 bits ... afin que les développeurs ne doivent modifier le code, correct? Le problème avec cette logique est que les développeurs sont soit en train de faire des applications 64 bits besoin 64 bits DLL ou ils font des applications 32 bits ont besoin DLL 32 bits ... De toute façon, ils ne sont pas encore visse? Je veux dire, s'ils continuent à faire une application 32 bits, pour qu'il fonctionne maintenant sur un ordinateur Windows, 64 bits ils ont maintenant besoin de faire un changement de code pour trouver / référence à la même ol » DLL 32 bits ils utilisé avant (maintenant situé dans SysWOW64). Ou, s'ils travaillent sur une application 64 bits, ils vont avoir besoin de réécrire leur ancienne application pour le nouveau système d'exploitation de toute façon ... donc recompiler / reconstruction allait être nécessaire de toute façon !!!

Microsoft me fait parfois mal.