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

Question

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, j'ai pensé placer le DLL 32 bits sous C:\Windows\System32 et le DLL 64 bits sous C:\Windows\SysWOW64.

À ma grande surprise, c'est l'inverse! Le 2 - bit un va dans C:\Windows\SysWOW64et le 64 - bit DLL va dans C:\Windows\System32.

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

Rytmis · Accepted Answer

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

SysWoW64 n'était pas destiné aux dll des systèmes 64 bits, c'est en fait quelque chose comme "Windows sur Windows 64", 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 a un répertoire System32 contenant des DLL 64 bits (sic!). Ainsi, les processus natifs de 64 bits trouvent" leurs "DLL où ils les attendent: dans le dossier System32. Un deuxième répertoire, SysWOW64, contient le fichier 32 fichiers .xbit. Le redirecteur du système de fichiers dissimule le véritable répertoire System32 des processus 32 bits et affiche SysWOW64 sous le nom System32. "

Edit: Si vous parlez d'un installateur, vous ne devriez pas coder en dur le chemin dans le dossier système. Laissez plutôt Windows s'en charger pour vous, que votre programme d'installation s'exécute ou non sur la couche d'émulation.

Jonesome · Answer

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 ne se trouve nulle part sous c:\windows \

Par exemple, votre installateur place vos dll dans:

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

(Note: Pour ce faire, utilisez l'environnement var:% ProgramFiles% ou% ProgramFiles (x86). % pour trouver où Program Files est .... 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 crée un lien dynamique avec les dll situées à cet emplacement.

Ce qui précède est la solution la plus intelligente.

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

system32 et syswow64 sont des fichiers fournis par Windows ... pas pour les fichiers elses. La seule raison pour laquelle les gens ont pris la mauvaise habitude de mettre des éléments là-bas est qu’ils sont toujours dans le chemin de recherche et que de nombreuses applications/modules utilisent des liens statiques. (Donc, si vous y tenez vraiment, le vrai péché est le lien statique - c'est un péché en code natif et en code managé - toujours toujours un lien dynamique!)

Crispy · Answer

Couru dans le même problème et recherché pendant quelques minutes.

On m'a appris à utiliser Windows 3.1 et DOS, vous souvenez-vous de ces jours? Peu de temps après, j’ai travaillé strictement avec des ordinateurs Macintosh pendant un certain temps, puis j’ai commencé à basculer vers Windows après avoir acheté un ordinateur x64 bits.

Il y a des raisons réelles derrière ces changements (certains diraient 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 (sous Windows 64 bits)

Lorsque les développeurs ont commencé à travailler avec Windows7, il existait plusieurs problèmes de compatibilité lorsque d'autres applications étaient stockées.
SysWOW64 signifie vraiment SysWOW32

Essentiellement, cela signifie simplement 'Windows sous Windows sur une machine 64 bits' . Chaque dossier indique l'emplacement des DLL pour les applications pour lesquelles ils souhaitent les utiliser.

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

Espérons que cela arrange les choses!

Armand · Answer

System32 est l'endroit où Windows a historiquement placé toutes les DLL 32 bits et System était destiné aux 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 est qu’ils voulaient que tout ce qui était en 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. Pour résoudre ce problème, afin que les applications 32 bits puissent toujours fonctionner, il a fallu créer un sous-système Windows 32 bits appelé Windows32 sous 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.
Windows 16 étant déjà séparé de Windows 32, une équivalence Windows 16 sur Windows 64 n’était pas nécessaire. Dans le sous-système 32 bits, lorsqu'un programme utilise des fichiers du répertoire system32, il les récupère en fait du répertoire SysWOW64. Mais le processus est imparfait.

C'est un design horrible. Et, selon mon expérience, je devais faire beaucoup plus de modifications pour écrire des applications 64 bits. Changer simplement le répertoire System32 pour lire System64 aurait été une modification minime, que les directives de pré-compilation devraient gérer.

Rich Bayless · Answer

D'autres personnes ont déjà bien expliqué ce casse-tête de ridicule ... et Chris Hoffman a fait un travail encore meilleur ici: https://www.howtogeek.com/326509/whats-the-difference- entre-le-system32-et-syswow64-folder-in-windows /

Mes deux pensées:

Nous faisons tous des erreurs stupides à courte vue dans la vie. Lorsque Microsoft a nommé (à l'époque) leur répertoire Win32 DLL "System32", il était logique à l'époque ... ils n'ont tout simplement pas pris en compte ce qui se passerait si/quand un 64 bits ( ou la version 128 bits) de leur système d’exploitation a été développée plus tard - et le problème massif de compatibilité avec les versions antérieures provoqué par un tel nom de répertoire. Le recul est toujours 20-20, donc je ne peux pas vraiment leur reprocher (trop) une telle erreur. ... TOUJOURS ... Lorsque Microsoft a par la suite développé son système d’exploitation 64 bits, même avec le recul, pourquoi pourquoi ne ferait-il pas non plus exactement la même erreur à courte vue encore, mais l’aggraverait encore en donnant PURPOSEFUL c'est un nom si trompeur?!? Honte à eux!!! Pourquoi ne pas AT MOINS nommer le répertoire "SysWin32OnWin64" pour éviter toute confusion?!? Et que se passe-t-il lorsqu'ils produisent finalement un système d'exploitation 128 bits ... alors où vont-ils placer leurs DLL 32 bits, 64 bits et 128 bits?!?
Toute cette logique me semble toujours complètement imparfaite. 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 ne soient pas obligés de modifier le 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 des applications 32 bits nécessitant des DLL 32 bits… de toute façon, ne sont-ils pas encore foutus? Je veux dire, s'ils continuent à créer une application 32 bits, pour que celle-ci s'exécute sous Windows 64 bits, ils devront maintenant modifier le code afin de trouver/référencer le même ancien 32 'bits DLL qu'ils utilisaient auparavant (maintenant situé dans SysWOW64). Ou, s'ils travaillent sur une application 64 bits, ils vont quand même avoir besoin de réécrire leur ancienne application pour le nouveau système d'exploitation ... donc une recompilation/reconstruction serait de toute façon nécessaire !!!

Microsoft me fait juste mal parfois.