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

Je sais que sur une version 64 bits de Windows, le dossier "Program Files" est réservé aux programmes 64 bits et le dossier "Program Files (x86)" aux programmes 32 bits, mais pourquoi cela est-il encore nécessaire?

Par "nécessaire", je ne veux pas dire "pourquoi Microsoft n'aurait-il pas pu prendre d'autres décisions de conception?" parce que bien sûr ils auraient pu. Je veux dire plutôt "pourquoi, étant donné la conception actuelle de Windows 64 bits, les programmes 32 bits doivent-ils avoir un dossier de niveau supérieur distinct des programmes 64 bits?" En d'autres termes, "que se passerait-il si j'évitais d'une manière ou d'une autre le mécanisme de redirection et que je forçais tout à s'installer dans le réel C:\Program Files\?"

Il y a beaucoup de questions sur Super User et ailleurs qui affirment "l'une est pour les programmes 32 bits, l'autre pour les programmes 64 bits", mais aucune que je puisse trouver ne donne la raison. D'après mon expérience, il ne semble avoir d' importance si un programme 32 bits est installé au bon endroit ou non.

Windows se présente-t-il d'une manière ou d'une autre différemment d'un programme utilisant "Program Files (x86)"? Existe-t-il une description qui montre exactement ce qui est différent pour un programme installé dans "Program Files (x86)" au lieu de "Program Files"? Je pense qu'il est peu probable que Microsoft introduise un nouveau dossier sans raison technique légitime.

Réponse courte: pour garantir que les applications 32 bits héritées continuent à fonctionner de la même manière qu'avant, sans imposer de règles laides aux applications 64 bits qui créeraient un désordre permanent.

Ce n'est pas nécessaire. C'est simplement plus pratique que d'autres solutions possibles, telles que demander à chaque application de créer son propre moyen de séparer les DLL et les exécutables 32 bits des DLL et des exécutables 64 bits.

La raison principale est de faire en sorte que les applications 32 bits ne sachant même pas qu'il existe des systèmes 64 bits, même si des DLL 64 bits sont installées à des endroits où les applications pourraient ressembler. Une application 32 bits ne pourra pas charger une DLL 64 bits; une méthode était donc nécessaire pour garantir qu'une application 32 bits (qui précède les systèmes 64 bits et n'a donc aucune idée des fichiers 64 bits même exister) ne trouve pas une DLL 64 bits, essaie de la charger, échoue, puis génère un message d'erreur.

La solution la plus simple consiste à ranger systématiquement des répertoires distincts. En réalité, la seule alternative consiste à demander à chaque application 64 bits de "masquer" ses fichiers exécutables quelque part qu'une application 32 bits n'aurait pas l'air, comme un bin64répertoire à l'intérieur de cette application. Mais cela imposerait une laideur permanente aux systèmes 64 bits uniquement pour prendre en charge les applications héritées.

Il vous permet d'installer à la fois les versions 32 bits et 64 bits d'une application sans que cela ne se écrase.

Après avoir examiné ce fil de réponses et de commentaires le lendemain, je me rends compte que ma réponse pourrait comporter un oubli majeur. J'ai faussement assumé un contexte de programmation et lorsque je parlais de vous dans mes commentaires, je ne parlais pas de l'utilisateur, mais du programmeur.

Je ne travaille pas pour Microsoft et je ne sais pas quel est le véritable raisonnement derrière ces dossiers, mais je pense que la raison d'avoir ces dossiers est si évidente que je n'ai aucun problème à le discuter.

Alors décomposons-le!

1. Les dossiers sont géniaux!

   D'accord sur quelque chose. Les dossiers sont super! Nous n'en avons pas besoin, nous avons suffisamment de noms de fichiers possibles pour placer chaque fichier à la racine de votre disque dur, alors pourquoi avoir des dossiers?

   Eh bien, ils nous aident à commander nos affaires. Et commander des choses est super. Cela nous aide à traiter les choses plus facilement. Ceci est particulièrement utile lorsque vous travaillez avec une machine nécessitant une structure.

2. La séparation des données et de la logique est excellente!

   Un paradigme souvent trouvé en programmation consiste à séparer les données de la logique. Vous voulez une partie qui sait comment faire quelque chose et que vous voulez une autre partie que vous pouvez faire quelque chose avec .

   Cela se trouve également dans le système de fichiers.

   Nous avons des dossiers pour application (logique) et des dossiers pour nos objets de valeur (données):

   Logique

   • %WINDIR%
   • %PROGRAMFILES%
   • %PROGRAMFILES(x86)%

   Les données

   • %PROGRAMDATA%
   • %HOMEDRIVE%%HOMEPATH%

   Donc, il semble que les dossiers sont géniaux et il est logique de mettre les programmes dans leur propre petit dossier. Mais pourquoi en avoir 2? Pourquoi ne pas laisser l'installateur gérer cela et tout mettre dans un Programsdossier?

3. Les installateurs ne sont pas magiques

   Aujourd'hui, nous utilisons souvent de petits programmes pour installer nos plus gros programmes. Nous appelons ces installateurs de petits programmes .

   Les installateurs ne sont pas magiques. Elles doivent être écrites par des programmeurs et sont des applications (avec des bogues possibles) comme toute autre application existante. Voyons maintenant la situation à laquelle un programmeur imaginaire devrait faire face avec et sans le système actuel:

   1 dossier Program Files

   Le développeur maintient 2 installateurs. Un pour la version 32 bits et un pour la version 64 bits de son application. Le programme d’installation 32 bits écrira C:\Program Files\App\et le programme d’installation 64 bits écrira C:\Program Files\App\sixtyfour\.

   2 dossiers Program Files

   Le développeur maintient 1 installateur. Le programme d' installation toujours écrire %PROGRAMFILES%et dépendent du système d'exploitation pour étendre le chemin en conséquence (vous ne fait pas utiliser des variables d'environnement pour ces cas, vous utiliseriez SHGetKnownFolderPath avec FOLDERID_ProgramFilespour récupérer le bon chemin).
   Tout trouve sa place automatiquement et le motif est identique pour chaque application que vous installez .

4. La cohérence a du sens

   Lorsque vous apprenez quelque chose, cela implique généralement qu'un comportement observé était cohérent. Sinon, il n'y a vraiment rien à observer et à apprendre.

   La même chose est vraie pour notre petit système de fichiers. Il est logique de toujours mettre les mêmes choses dans les mêmes dossiers. De cette façon, nous saurons où chercher lorsque nous cherchons quelque chose.

   Le système de distinction des applications 32/64 poursuit cet objectif. Les applications sont séparées en 2 emplacements pour éviter les conflits de noms, le comportement de chargement binaire et la sécurité (dans une certaine mesure).

Je ne comprends toujours pas. Cela semble inutile

Vous ne devriez jamais oublier une chose. Les gens sont incroyablement stupides. Cela inclut les utilisateurs, les super utilisateurs et surtout les programmeurs.

C'est pourquoi nous avons besoin d'éléments tels que la redirection de système de fichiers pour rendre nos systèmes utilisables.

Les programmeurs vont juste y aller et essayer de charger C:\Windows\system32\awesome.dllsans se soucier de s’ils fonctionnent sur un système 32 ou 64 bits. Ils essaieraient de charger la DLL 64 bits et se planteraient tout simplement. Certains programmeurs veulent utiliser une DLL Office, pas de problème, ils savent où la trouver! C:\Program Files\Microsoft\Office\14.0\wizards.dll... et un autre crash!

Toutes ces demandes émanant d'applications 32 bits sont redirigées vers les contreparties 32 bits afin d'éviter tout blocage de l'application.

Nous avons besoin de noms de dossiers fixes pour construire un tel système. S'il n'y a pas de structure de dossier pour prendre en charge cette redirection, comment allez-vous la faire fonctionner?

Ok, maintenant je comprends. Mais pourquoi ne pas utiliser C:\Program Files\x86\alors?

Maintenant nous obtenons philosophique ...

Que se passerait-il si j'évitais d'une manière ou d'une autre le mécanisme de redirection et que je forçais tout à s'installer au réel C:\Program Files\?

Très probablement rien (tant que les autres applications ne dépendent pas d'un emplacement fixe pour cette application).

Le mécanisme WOW64 s'accroche dans CreateProcesset effectuera des contrôles plus sophistiqués (plus sophistiqués que la vérification du nom de dossier de l'exécutable) sur l'image exécutable afin de déterminer si elle est en 32 ou 64 bits.

Oui, mais je veux dire, comme, TOUTES les applications!

• Que se passerait-il si je mettais à la fois du diesel et de l'essence dans ma voiture?
• Que se passerait-il si j'essayais d'utiliser à la fois du courant alternatif et du courant continu sur la même ligne?
• Que se passerait - il si je continue à la fois mon chat et mon poisson dans le même aquarium?

Certaines questions ne nécessitent pas de réponses. Ce n'est pas destiné à être fait, ne le faites pas. Il n'y a rien à gagner ici. La quantité de problèmes qu'un tel changement pourrait causer l' emportera toujours sur les avantages potentiels que quelqu'un pourrait y voir.

TL; DR:

Pour résumer, non, ce n'est pas nécessaire ; ils auraient pu utiliser un seul dossier, et non, Windows ne se présente pas différemment à un programme exécuté depuis un emplacement ou un autre.

Eh bien, tout le monde semble avoir son opinion à ce sujet, alors je vais lui donner 2 ¢. D’autres ont déjà spéculé sur les raisons pour lesquelles Microsoft a choisi de créer des dossiers de niveau supérieur distincts pour les versions 32 bits et 64 bits des programmes. C’est pourquoi je laisserai cette partie commodité pour les programmeurs). Bien sûr, même alors, cela ne répond pas tout à fait à la question directe: pourquoi cela est-il même nécessaire? , à laquelle la réponse est probablement: ce n'est pas .

Au lieu de cela, je vais aborder le corps de la question

Windows se présente-t-il d'une manière ou d'une autre différemment d'un programme utilisant "Program Files (x86)"?

Pas vraiment, mais l'emplacement du programme peut influer sur le comportement, mais pas de la manière que vous pensez.

Lorsque vous exécutez un programme, Windows configure un environnement dans lequel l'exécuter (en termes de mémoire, d'adressage, etc., et pas uniquement de variables d'environnement). Cet environnement dépend du contenu de l'exécutable (les programmes 32 bits et 64 bits diffèrent en interne). Lorsque vous exécutez un programme 32 bits sur un système 64 bits, il s'exécute dans le sous-système 32 bits qui émule un environnement 32 bits. Il s'appelle WoW64 (WoW64 signifie Windows sur Windows 64 bits ) et est similaire à la façon dont les applications 16 bits seraient exécutées dans XP à l'aide du NTVDM .

Lorsque vous exécutez un programme avec ou sans privilèges d'administrateur, cela a une incidence sur son exécution, mais l'emplacement ne devrait pas l'affecter (bien qu'il existe des exemples de dépendance d'emplacement, comme certains pilotes, par exemple).

(J'utilise un autre ordinateur. Je ne peux donc pas me fier à l'historique de mon navigateur pour revenir en arrière. Mais l'autre jour, en répondant à cette question du SU, je me suis retrouvé face à cette question SO qui m'a amené à Google PROCESSOR_ARCHITEW6432 qui a conduit à cette question SO et cet article de blog Microsoft .)

En cours de route, j'ai lu un article de StackOverflow sur la façon dont la variable d'environnement %processor_architecutre% donne des résultats différents selon l'endroit où vous exécutez l'invite de commande (je vais essayer de trouver la citation exacte).

La réponse s'est avérée être due si la version 32 bits ou 64 bits de l'invite de commande a été exécutée (c'est-à-dire, à partir de System32\ou SysWoW64\). En d'autres termes, si l'emplacement semble affecter le comportement du programme, c'est uniquement parce qu'il existe différentes versions du programme et non pas parce que Windows traite le dossier de manière particulière.

Cela a du sens, car le contenu du fichier exécutable indique s'il s'agit d'un fichier 32 bits ou 64 bits. Vous pouvez donc placer une copie 32 bits et 64 bits du même programme (par exemple, foobar32.exeet foobar64.exe) dans le même dossier et lorsque vous le souhaitez. exécutez-les, ils seront chargés correctement (la version 64 bits sera exécutée de manière native et la version 32 bits sera exécutée dans la couche d'émulation WoW64).

FreePascal vous permet d'installer les versions DOS et Windows et ils vont dans le même dossier: %programfiles%\FreePascal. Il gère les différentes architectures en gardant les fichiers exécutables ( .exe, .sys, .dll, .ovr, etc.) dans des dossiers séparés et le partage de fichiers de ressources comme des images, source-fichiers, etc.) Il n'y a aucune raison technique que cela ne pouvait être fait aussi pour et 32- Versions 64 bits d'un programme. Comme David l'a dit, il est tout simplement plus facile pour le programmeur de les garder séparés (en utilisant des variables pour donner l'impression qu'il n'y a qu'un seul jeu de fichiers, etc.)

Une autre raison est que la plupart des programmes utilisaient des variables environnementales telles que% PROGRAMFILES% pour indiquer l'emplacement d'installation de leur programme. Pour les programmes 64 bits, cela va à la place normale. Pour les programmes 32 bits, cela sera redirigé vers le nouveau Program Files (x86)dossier.

Bien qu'au moins avec les nouveaux éléments .Net dans Visual Studio, ils disposent désormais de la variable App.Local, qui en élimine la totalité du besoin.

La solution de Microsoft pour cette transition de 32 bits à 64 bits a été d’ajouter un support hérité pour la plupart des applications 32 bits. En d'autres termes, la plupart des applications 32 bits fonctionneront dans l'environnement d'exploitation 64 bits. N'oubliez pas que les autres systèmes d'exploitation fonctionnant sur une architecture 64 bits ne peuvent ni charger ni exécuter d'applications 32 bits.

Pour faciliter la transition, Microsoft a indiqué que toutes les applications 32 bits devraient, par défaut, être chargées dans le dossier Program Files (x86) plutôt que mélangées avec de vraies applications 64 bits dans le dossier Program Files normal.

La source

"Que se passerait-il si j'évitais d'une manière ou d'une autre le mécanisme de redirection et que je forçais tout à s'installer sur le vrai C: \ Program Files \?"

Rien. Les deux répertoires de programmes sont uniquement destinés à l'organisation, ou à la séparation des programmes comportant deux versions, une version 32 bits et une version 64 bits, comme Internet Explorer. Mais vous pouvez installer un programme 32 bits dans "Program Files" et un programme 64 bits dans "Program Files x86" et rien ne se passera, le programme s'exécutera de la même manière.

Wiki dit:

Certains installateurs d'applications rejettent les espaces dans l'emplacement du chemin d'installation. Pour les systèmes 32 bits, le nom abrégé du dossier Program Files est Progra ~ 1 . Pour les systèmes 64 bits, le nom abrégé du dossier Program Files 64 bits est Progra ~ 1 (comme sur les systèmes 32 bits). alors que le nom abrégé du dossier Program Files (x86) 32 bits est maintenant Progra ~ 2 .

La raison en est de faciliter la mise à niveau d'un programme en 64 bits pour les développeurs. Ils n'ont pas besoin d'écrire de code personnalisé pour rechercher le programme 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 se contentent de vérifier C:\Program Files, et en mode 32 bits, C:\Program Files (x86)Windows 64 bits le remplace automatiquement . De même, les entrées de registre sont isolées entre les programmes 32 bits et 64 bits.

Cela évite les conflits aux développeurs ignorants qui modifient simplement leur mode de compilation en mode 64 bits sans y apporter beaucoup de réflexion, et évite une charge de travail énorme pour les développeurs qui souhaitent que les utilisateurs puissent installer les versions 32 et 64 bits de leur logiciel. logiciel simultanément.

Mais pourquoi un programme voudrait-il autoriser les deux versions à être installées simultanément? Un exemple: Photoshop et IE ont des extensions natives .dll. Vous ne pouvez pas mélanger du code 32 bits et 64 bits dans le même processus, de sorte qu'un addon pour la version 32 bits ne peut pas être utilisé avec la version 64 bits, et inversement. Ainsi, Photoshop / IE ont pour permettre aux deux versions à installer, ou un risque de rupture de leur énorme base d'addons existants.

Les programmes exécutés sur "Program Files (x86)" utilisent le sous-système WOW64 (Windows 32 bits sur Windows 64 bits est un ensemble de pilotes et d'API conçus pour 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 dotée d'interfaces similaires sur toutes les versions 64 bits de Windows. Son objectif est de créer un environnement 32 bits fournissant les interfaces nécessaires à l'exécution d'applications Windows 32 bits non modifiées sur un système 64 bits. Techniquement, WoW64 est implémenté à l'aide de trois bibliothèques de liens dynamiques (DLL):

• Wow64.dll, l'interface principale du noyau Windows NT qui traduit les appels 32 bits et 64 bits, y compris les manipulations de pointeur et de pile d'appels
• Wow64win.dll, qui fournit les points d'entrée appropriés pour les applications 32 bits
• Wow64cpu.dll, qui prend en charge le basculement du processeur du mode 32 bits au mode 64 bits

Le système 64 bits doit "émuler" les applications 32 bits, ce qui explique pourquoi Windows doit "séparer" deux dossiers Program Files.

Il est intéressant de noter que les réponses ici et sur Internet varient un peu. Trouver une réponse précise à cette question importante a été un défi. Il semble y avoir un peu de fausses informations présentées sur Internet, ce qui mène à la confusion.

J'ai effectué de nombreuses recherches et j'ai tiré la conclusion suivante, qui, à mon avis, est exacte:

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

Cela se produit automatiquement et est indépendant du lieu où l'application est stockée. Avoir des dossiers séparés 32 bits et 64 bits ne présente aucun avantage fonctionnel en termes de vitesse, de fiabilité ou autre.

La séparation par défaut entre deux dossiers ('Program Files' et 'Program Files (x86)') s'explique uniquement par le fait que, si vous disposez de deux versions du même programme (versions 32 bits et 64 bits), elle fournit une 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 pourraient en fait exister dans le même dossier sans aucune conséquence.

La conclusion ci-dessus appelle une mise en garde, à savoir celle des applications mal codées. Si une application contient des chemins codés en dur, elle utilisera uniquement ce chemin. En règle générale, les chemins d'accès ne doivent jamais être codés en dur dans une application, mais parfois un programmeur commettra 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 la recherche des fichiers.

Le fait de séparer les dossiers permet de garder les applications 64 bits natives et celles qui requièrent le WoW64 .

Cela peut être utile - comme l' a déjà souligné @OliverSalzburg - si vous souhaitez installer un navigateur Web 64 bits et 32 ​​bits (par exemple), car certains plug-ins et add-ons ne sont disponibles que pour l'un des deux. les deux.

Le fait de séparer les dossiers rend cette séparation automatique , à l'aide de techniques telles que la redirection du registre .

Supposons qu'un programme d'installation tente de déterminer le dossier des fichiers du programme en lisant le registre à l'aide, par exemple, de 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 entraîne l’enregistrement de la clé de registre.

HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion

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

Pourquoi ces particuliers noms de dossiers ont été utilisés on ne peut répondre par les gens qui ont fait ce choix. Vous pouvez toujours changer les noms des dossiers par défaut si vous le souhaitez.

Windows se présente-t-il d'une manière ou d'une autre différemment d'un programme utilisant "Program Files (x86)"?

J'en doute. La plupart des installateurs vous permettent de choisir un dossier d'installation personnalisée, donc il ne compte pas vraiment où un programme est installé.

Je ne peux pas croire à la confusion ici .. premièrement, je suis un développeur à temps plein.

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

Ainsi, MS a créé un dossier pour stocker des programmes, des assemblys et des bibliothèques spécifiques 64 bits, de sorte que les nouveaux programmes puissent être liés aux bibliothèques appropriées et que les programmes plus anciens continuent de fonctionner normalement.

Dans l'état actuel des choses, les DLL .Net peuvent coexister avec d'autres versions sur le même ordinateur. Par exemple, vous pouvez avoir Library.1.0.1, Library.1.0.2, Library 1.1.0, etc. Et cela ne concerne qu'une taille de bit spécifique (32 ou 64). Si des dossiers distincts ne sont pas utilisés, chaque assemblage doit avoir une version 32 et 64 bits. Cela encombrerait gravement un répertoire contenant déjà plusieurs versions du même assemblage.

Ceci est tout truc de développeur. En tant qu'utilisateur, je n'ai à m'en occuper 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, je ne fais que dire au compilateur de le faire. Les noms de DLL et tout le reste reste le même.

La raison pour laquelle cela n'existait pas avec Windows 95/98 est que ces systèmes ont simulé une exécution 32 bits; ce n'était pas un véritable système d'exploitation 32 bits. Il simulait une exécution 32 bits avec un nom nommé "thunking".

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

Ce n'est pas nécessaire du tout. Par exemple, sur mon ordinateur de travail, j'installe chaque application dans un dossier C:\MyPrograms\afin de les séparer des applications installées par notre service informatique.

Bien sûr, cela ne m’empêche pas d’installer les deux versions (32 et 64 bits) d’une application, mais ce n’est pas un problème dans mon cas.

Chaque fois que vous lancez un programme, la première DLL C:\Windows\System32\ntdll.dllest toujours exécutée. Cette DLL détermine si votre programme est une application 32 ou 64 bits. En fonction de cela, vous êtes redirigé, WoW64ce qui est déjà mentionné dans plusieurs réponses.