Pourquoi Windows 64 bits a-t-il besoin d'un dossier "Program Files (x86)" distinct ?

La raison en est de faciliter la mise à niveau d'un programme vers le 64 bits pour les développeurs. Ils n'ont pas besoin d'écrire de code personnalisé pour vérifier si le programme se trouve dans un répertoire lors de la compilation en mode 32 bits et dans un autre répertoire lors de la compilation en mode 64 bits ; ils vérifient simplement que C:\Program Files et lorsqu'il est exécuté en mode 32 bits, il est automatiquement modifié en C:\Program Files (x86) par Windows 64 bits. De même, les entrées du registre sont isolées entre les programmes 32 bits et 64 bits.

Cela permet d'éviter les conflits causés par des développeurs inconscients qui se contentent de changer leur mode de compilation en 64 bits sans y réfléchir, et évite une énorme quantité de travail aux développeurs qui souhaitent que les utilisateurs puissent installer simultanément les versions 32 et 64 bits de leurs logiciels.

Mais pourquoi un programme voudrait-il permettre l'installation simultanée des deux versions ? Un exemple : Photoshop et IE ont des extensions qui sont des .dll natives. Il n'est pas possible de mélanger les codes 32 et 64 bits dans le même processus, de sorte qu'un module complémentaire pour la version 32 bits ne peut pas être utilisé avec la version 64 bits, et vice-versa. Ainsi, Photoshop/IE ont de permettre l'installation des deux versions, sous peine de briser leur énorme base d'addons existants.

Les programmes qui s'exécutent dans "Program Files(x86)" utilisent l'option de l'utilisateur. WOW64 (Windows 32 bits sur Windows 64 bits est un ensemble de pilotes et d'API destinés à exécuter des applications x32 sur un système d'architecture x64) :

Le sous-système WoW64 comprend une couche de compatibilité légère qui a des interfaces similaires sur toutes les versions 64 bits de Windows. Il vise à créer un environnement 32 bits qui fournit les interfaces nécessaires pour exécuter des applications Windows 32 bits non modifiées sur un système 64 bits. Techniquement, WoW64 est mis en œuvre à l'aide de trois bibliothèques à liaison dynamique (DLL) :

• Wow64.dll, l'interface centrale du noyau Windows NT qui assure la conversion entre les appels 32 bits et 64 bits, y compris la manipulation des pointeurs et de la pile d'appels. d'appel
• Wow64win.dll, qui fournit les points d'entrée appropriés pour les applications 32 bits.
• Wow64cpu.dll, qui se charge de faire passer le processeur du mode 32 bits au mode 64 bits

Les systèmes 64 bits doivent "émuler" les applications 32 bits, c'est la raison pour laquelle Windows doit "séparer" deux dossiers Program Files.

Il est intéressant de constater que les réponses données ici et sur Internet varient considérablement. Trouver une réponse précise à cette question importante a été un défi. Il semble qu'il y ait beaucoup de fausses informations présentées sur Internet, ce qui entraîne une certaine confusion.

J'ai effectué un grand nombre de recherches et j'ai tiré la conclusion suivante, qui me semble exacte :

• L'endroit où une application est stockée ne fait aucune différence. Au moment de l'exécution, Windows déterminera si l'application est 32 ou 64 bits et utilisera automatiquement les DLL et la section de registre appropriées.

Cette opération est automatique et indépendante de l'endroit où l'application est stockée. Il n'y a aucun avantage en termes de vitesse, de fiabilité ou d'autres avantages fonctionnels à avoir des dossiers 32 bits et 64 bits séparés.

La seule raison de la séparation par défaut en deux dossiers ("Program Files" et "Program Files (x86)") est que si vous avez deux versions du même programme (une version 32 bits et une version 64 bits), cela fournit un moyen simple de séparer les fichiers qui se chevauchent. Même dans ce cas, tant que tous les noms de fichiers sont uniques, ils peuvent exister dans le même dossier sans aucune conséquence.

Il y a un bémol à la conclusion ci-dessus, et c'est celui des applications mal codées. Si une application contient des chemins codés en dur, elle n'utilisera que ce chemin. En règle générale, les chemins ne devraient jamais être codés en dur dans une application, mais il arrive qu'un programmeur fasse cette erreur. Dans ce cas, le programme utilisera le chemin codé en dur ; le répertoire dans lequel l'application est installée n'affectera pas l'endroit où elle recherche réellement les fichiers.

Le fait de séparer les dossiers permet de conserver les applications 64 bits natives et celles qui nécessitent l'utilisation de l'option d'extension. WoW64 à part.

Cela peut être utile - comme @OliverSalzburg déjà signalé - si vous souhaitez installer à la fois le 64 bits et le 32 bits d'un navigateur web (par exemple), car certains plug-ins et add-ons peuvent n'être disponibles que pour l'un des deux.

Le fait de devoir séparer les dossiers rend cette séparation automatique en utilisant des techniques telles que redirection du registre .

Supposons qu'un programme d'installation tente de déterminer le dossier des fichiers de programmes en lisant le registre en utilisant, par exemple, la commande suivante RegQueryValueEx .

Dans tous les cas, il essaie de lire la clé de registre

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion

qui pointe normalement vers C:\Program Files .

Toutefois, si le programme d'installation est une application 32 bits, la redirection du registre fera en sorte que la clé de registre

HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion

à lire à la place, qui pointe normalement vers C:\Program Files (x86) .

Pourquoi ces particulier Les noms des dossiers qui ont été utilisés ne peuvent trouver de réponse que chez les personnes qui ont fait ce choix. Vous pouvez toujours changer les noms des dossiers par défaut si vous le souhaitez.

Est-ce que Windows se présente différemment pour un programme qui s'exécute à partir de "Program Files (x86)" ?

J'en doute. La plupart des installateurs vous permettent de choisir un dossier d'installation personnalisé, ce qui n'a pas vraiment d'importance. où un programme est installé.

Je ne peux pas croire à la confusion qui règne ici Tout d'abord, je suis un développeur à plein temps.

MS a fait cela pour résoudre le cas où une DLL est utilisée à la fois par les anciennes applications 32 bits et les nouvelles applications 64 bits. L'ancienne méthode ne pouvait pas être modifiée (System32, Program Files, etc.) car cela aurait cassé les anciens programmes qui ne peuvent pas être recompilés.

MS a donc créé un dossier pour stocker les programmes, assemblages et bibliothèques spécifiques à 64 bits afin que les nouveaux programmes puissent se lier aux bibliothèques appropriées et que les anciens programmes continuent de fonctionner normalement.

À l'heure actuelle, les DLL .Net peuvent coexister avec d'autres versions sur la même machine. Par exemple, vous pouvez avoir Library.1.0.1, Library.1.0.2, Library 1.1.0, etc. Et ceci uniquement pour une taille de bit spécifique (32 ou 64). Si des dossiers séparés ne sont pas utilisés, alors chaque assemblage doit avoir une version 32 et 64 bits. Cela encombrerait gravement un répertoire qui contient déjà plusieurs versions du même assembly.

Ce sont tous des trucs de développeurs. En tant qu'utilisateur, je n'y suis confronté que lorsque je travaille avec un programme 32 bits sous Windows 7 64. Et je préfère avoir la possibilité d'exécuter une version 32 bits et la même application en 64 bits également. Lorsque je travaille sur une application 32 bits que je dois compiler en 64 bits, il me suffit de demander au compilateur de le faire. Les noms de Dll et tout le reste restent les mêmes.

La raison pour laquelle cela n'existait pas avec Windows 95/98 est que ces systèmes simulaient un runtime 32 bits ; ce n'était pas un véritable système d'exploitation 32 bits. Il simulait l'exécution 32 bits avec quelque chose appelé "thunking".

Voici une bonne définition : http://searchwinit.techtarget.com/definition/thunk