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

Il vous permet d'installer à la fois la version 32 bits et la version 64 bits d'une application sans que celle-ci ne s'écrase.

Après avoir examiné cette réponse et le fil des commentaires le lendemain, je me suis rendu compte d'une erreur majeure possible dans ma réponse. J'ai supposé à tort que j'avais des connaissances en programmation et quand 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 n'ai aucune idée de ce que le réel Je ne connais pas le raisonnement qui sous-tend ces dossiers, mais je pense que la raison d'avoir ces dossiers est si évidente que je n'ai aucun problème à la défendre.

Alors, décomposons-la !

1. Les classeurs sont géniaux !

   Soyons d'accord sur quelque chose. Les dossiers, c'est génial ! 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 trucs, c'est génial. Ça nous aide à traiter les choses plus facilement. C'est particulièrement utile quand on travaille avec une machine qui nécessite une structure.

2. Séparer les données et la logique, c'est génial !

   Un paradigme souvent rencontré en programmation consiste à séparer les données de la logique. Vous voulez une partie qui connaît comment faire quelque chose et vous voulez une autre partie que vous peut faire quelque chose avec .

   On le trouve également dans le système de fichiers.

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

   Logique

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

   Données

   • %PROGRAMDATA%
   • %HOMEDRIVE%%HOMEPATH%

   Il semble donc que les dossiers soient géniaux et qu'il soit logique de placer les programmes dans leur propre petit dossier. Mais pourquoi en avoir deux ? Pourquoi ne pas laisser l'installateur s'en charger et tout mettre dans un seul dossier ? Programs dossier ?

3. Les installateurs ne sont pas magiques

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

   Les installateurs ne sont pas magiques. Ils doivent être écrits par des programmeurs et sont des applications (avec des bogues possibles) comme toutes les autres applications existantes. Examinons donc la situation à laquelle un programmeur imaginaire devrait faire face. avec と なくしては le système actuel :

   1 dossier Program Files

   Le développeur maintient 2 installateurs. Un pour la version 32bit et un pour la version 64bit de son application. L'installateur 32bit écrira à C:\Program Files\App\ et l'installateur 64bit écrira dans C:\Program Files\App\sixtyfour\ .

   2 dossiers Program Files

   Le développeur maintient 1 installateur. L'installateur écrira toujours dans %PROGRAMFILES% et dépendent du système d'exploitation pour étendre le chemin d'accès en conséquence (en fait, vous n'utilisez pas de variables d'environnement dans ces cas-là, vous utiliseriez plutôt SHGetKnownFolderPath mit FOLDERID_ProgramFiles pour récupérer le chemin correct).
   Chaque chose trouve sa place automatiquement et le motif est identique avec chaque application que vous installez .

4. La cohérence a du sens

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

   Il en va de même pour notre petit système de fichiers. Il est logique de toujours mettre la même chose dans les mêmes dossiers. Comme ça, on saura où regarder quand on cherchera quelque chose.

   Le système de distinction des applications 32/64 va dans ce sens. Les applications sont séparées en 2 endroits 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 devez 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 de choses comme redirection du système de fichiers pour rendre nos systèmes utilisables.

Les programmeurs vont juste entrez là-dedans et essayer de charger C:\Windows\system32\awesome.dll et ne pas se soucier de savoir 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 d'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 de l'application 32bit sont redirigé dans leurs homologues 32 bits pour éviter les plantages d'applications.

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 supporter cette redirection, alors comment allez-vous la faire fonctionner ?

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

Maintenant, nous devenons philosophiques...

Que se passerait-il si j'évitais le mécanisme de redirection et que je forçais tout à s'installer sur le vrai serveur de l'entreprise ? C:\Program Files\ ?

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

El WOW64 Le mécanisme s'accroche à CreateProcess et effectuera des contrôles plus sophistiqués (plus sophistiqués que la vérification du nom du dossier de l'exécutable) sur l'image de l'exécutable pour déterminer s'il s'agit d'un 32 ou 64 bits.

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

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

Certaines questions n'ont pas besoin de réponses. Il n'est pas prévu de le faire, ne le faites pas. Il n'y a rien à gagner. La quantité de problèmes qu'un tel changement pourrait causer toujours l'emportent sur les éventuels avantages que quelqu'un pourrait y voir.

TL;DR :

Pour résumer, non, ce n'est pas nécessaire ; ils pourrait ont utilisé un seul dossier, et non, Windows ne se présente pas différemment à un programme exécuté à partir d'un emplacement ou d'un autre.

Tout le monde semble donner son avis sur la question, alors je vais ajouter mon grain de sel. D'autres ont déjà fait des conjectures sur les raisons pour lesquelles pourquoi Microsoft a choisi de créer des dossiers de premier niveau distincts pour les versions 32 bits et 64 bits des programmes, je laisserai donc cette partie (la meilleure raison étant l'explication de David selon laquelle il s'agit d'une commodité pour les programmeurs). Bien sûr, même dans ce cas, cela ne répond pas tout à fait à la question directe pourquoi est-ce nécessaire ? à laquelle la réponse est vraisemblablement : ce n'est pas .

Je vais plutôt répondre à l'essentiel de la question.

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

Pas vraiment, mais l'emplacement du programme peut affectent le comportement, mais pas de la manière dont on pourrait le penser.

Lorsque vous exécutez un programme, Windows met en place un environnement dans lequel l'exécuter (je veux dire en termes de mémoire, d'adressage, etc., et pas seulement 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 est appelé WoW64 (WoW64 signifie Windows sur Windows 64 bits ) et est similaire à la façon dont les applications 16 bits sont exécutées sous XP en utilisant le module de gestion de l'environnement. NTVDM .

Lorsque vous exécutez un programme avec ou sans privilèges d'administrateur, cela affecte son fonctionnement, mais l'emplacement devrait ne l'affecte pas (bien qu'il existe quelques exemples de dépendance à l'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 sur mes pas, mais l'autre jour, en répondant à cette question SU Je me suis retrouvé à cette question SO ce qui m'a poussé à Google PROCESSOR_ARCHITEW6432 ce qui conduit à cette question SO と cet article du blog de Microsoft .)

Quelque part, j'ai lu un message sur StackOverflow qui expliquait comment la variable d'environnement %processor_architecutre% donne des résultats différents selon l'endroit d'où vous lancez l'invite de commande (Je vais essayer de trouver la citation exacte).

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

Cela est logique car le contenu du fichier exécutable détermine s'il s'agit d'un fichier 32 bits ou 64 bits. Vous pourriez donc mettre une copie 32 bits et 64 bits du même programme (par ex, foobar32.exe と foobar64.exe ) dans le même dossier et lorsque vous les exécuterez, 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 de WoW64).

FreePascal vous permet d'installer les deux versions DOS et Windows et elles vont dans le même dossier : %programfiles%\FreePascal . Il gère les différentes architectures en conservant les fichiers exécutables ( .exe , .sys , .dll , .ovr Il n'y a aucune raison technique pour laquelle cela ne pourrait pas être fait pour les versions 32 et 64 bits d'un programme. Comme l'a dit David, il est simplement plus facile pour le programmeur de les séparer (par exemple, en utilisant des variables pour faire croire qu'il n'y a qu'un seul ensemble de fichiers, etc.)

Une autre raison est que la plupart des programmes avaient l'habitude d'utiliser des variables d'environnement telles que %PROGRAMFILES% pour indiquer l'endroit où leur programme était installé. Pour les programmes 64 bits, il va à l'endroit normal. Pour les programmes 32 bits, elle sera redirigée vers le nouvel emplacement "%PROGRAMFILES%". Program Files (x86) dossier.

Cependant, au moins avec la nouvelle version de .Net dans Visual Studio, ils ont maintenant la variable App.Local qui élimine tout besoin de cela.

La solution de Microsoft à cette transition de 32 à 64 bits a été d'ajouter un support 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 pas du tout charger ou exécuter des applications 32 bits.

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

Source :

"qu'est-ce qui se passerait si j'évitais le mécanisme de redirection et que je forçais tout à s'installer sur le vrai serveur de l'entreprise ? C:\Program Files\"

Rien. Les deux répertoires de programmes ne servent qu'à l'organisation, ou à garder séparés les programmes qui ont 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 fonctionnera 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 court du dossier Program Files est le suivant Progra~1 . Pour les systèmes 64 bits, le nom court du dossier Program Files 64 bits est Progra~1 (comme sur les systèmes 32 bits) ; tandis que le nom court du dossier Program Files (x86) 32 bits est désormais Progra~2 .