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

178

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.

windows 64-bit Stephen Jennings
la source
13
Plutôt que de répondre à votre question, je vous demanderais: comment géreriez-vous \ programmes \ programmes?
Sgmoore
8
One-Liner answer (et par conséquent un commentaire): puisque vous pouvez facilement exécuter n’importe quelle application à partir de n’importe quel dossier sans connaître son architecture, il n’existe à l’évidence aucune raison obligatoire de cette séparation. C’est une question de commodité de prendre en charge la double installation d’applications avec les deux architectures . Dans certains cas, cela fait une différence car ils ne sont pas nécessairement simples à recompiler. Le principal problème est que les applications 32 bits ne peuvent pas charger de dll 64 bits, vous ne pouvez donc pas installer les deux versions au même endroit. L'autre alternative est d'avoir deux dossiers "bin" pour chaque application.
Sklivvz
1
@ Synetech, j'avais même des programmes installés sous (x86) juste pour avoir des binaires x64 .. C'est parfois horrible.
Sinni800
10
Je me suis toujours demandé pourquoi Microsoft n'avait pas placé de programmes 64 bits dans un "Program Files (x64)" au lieu de * déplacer "le répertoire" hérité "de Program Files dans Program Files (x86)
LawrenceC
30
Le vrai bazar de la différenciation 64/32 bits est que / Windows / System32 contient un contenu 64 bits, alors que / Windows / SysWOW64 contient les fichiers 32 bits…
poke

Réponses:

92

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.

David Schwartz
la source
52
Ils n'ont pas eu à franchir ces étapes pour autoriser les programmes 32 bits et 16 bits sur le même système. Je ne me souviens pas avoir jamais vu un ProgramFiles (16)ou un tel. En outre, comment un programme 32 bits "trouverait-il une DLL 64 bits et essaierait-il de le charger"? Quels programmes recherchent des DLL aléatoires dans %programfiles%? Si c'est une DLL partagée, alors il va dans WinSxS; s'il n'est pas partagé, il appartient au programmeur de gérer ses propres DLL. La partie concernant le fait que cela soit pratique pour les programmeurs reste cependant raisonnable.
Synetech
30
IIRC Win3.1 n’avait pas de répertoire de fichiers programme (ou la plupart des applications l’ignoraient); par conséquent, il n'y aurait pas d'ancienne application Win16 à la recherche d'éléments dans les fichiers de programme. Au lieu de cela, les bibliothèques partagées de l'IIRC étaient souvent placées quelque part dans le dossier Windows lui-même. Win32 ayant Windows \ System et Windows \ System32 est un artefact de cela.
Dan Neely
15
Windows 3.1 ne supportait pas les noms de fichiers longs, il n'aurait donc pas pu avoir un dossier 'fichiers de programme'.
Dark Egregious
14
@JarrodRoberson: Bien au contraire, c'est parce que Microsoft attache énormément d'importance à la compatibilité avec les versions antérieures.
David Schwartz
24
@ Jarrod: En réalité, comme le savent tous les développeurs, Microsoft accorde trop d' importance à la compatibilité avec les versions antérieures . Littéralement, chaque API qu'ils ont possède des méthodes héritées qu'ils refusent de supprimer, et souvent des bogues sérieux qu'ils refusent de corriger, car ils craignent de supprimer les anciens programmes écrits pour cette API. Il en va de même de la plupart des API, mais pas de celles de Microsoft.
BlueRaja - Danny Pflughoeft Le
65

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.

Der Hochstapler
la source
3
Est-ce que c'est la raison initiale, cependant? Ne pourrais-je pas simplement installer l'application sur C:\Program Files\App32et C:\Program Files\App64?
Stephen Jennings
4
@StephenJennings: Mais cela nécessiterait que vous preniez la décision manuellement. La procédure actuelle est que le processus est automatique, car Windows sait quel dossier fournir lorsqu'une application appelle SHGetSpecialFolderPathpour déterminer l'emplacement d'installation.
Der Hochstapler
6
@ Synetech: Pourquoi installer en %PROGRAMFILES%premier lieu? Pourquoi ne pas mettre la version 32 bits sur le bureau des utilisateurs et la version 64 bits dans la corbeille? Ce n’est pas parce que cela peut être fait que c’est une bonne idée. Désolé, je ne suis pas votre raisonnement.
Der Hochstapler
4
@ Synetech: Oui, vous avez donné un excellent exemple de la façon dont cela pourrait être fait. Un autre très bon exemple de la façon dont cela pourrait être fait est la façon dont cela se fait actuellement. Écrire un fichier dans% PROGRAMFILES% et être certain qu’il se retrouvera dans le bon dossier est une chose. Vérifier par vous-même quel est le bon dossier en est un autre. Si vous ne voyez vraiment pas l'intérêt de l'ancienne approche, je ne pourrai pas vous convaincre. La question était de savoir pourquoi il y a 2 dossiers. Je pense que ma réponse est parfaitement raisonnable à cet égard.
Der Hochstapler
3
@ OliverSalzburg, pas tout à fait. La question est pourquoi deux dossiers sont nécessaires , pas pourquoi il y a . En fait, il l'a même fait comprendre : pourquoi cela est-il même nécessaire? Vous n'avez pas expliqué pourquoi c'était nécessaire et l'exemple que j'ai donné (et même votre propre exemple sarcastique) montre simplement que cela ne doit pas nécessairement être fait tel qu'il est.
Synetech
14

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.)

Synetech
la source
Vengeance vote à la baisse! Muahahaha! soupir
Synetech
Vote négatif étrange: \. BTW bien expliquer +1.
avirk
11

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.

Canadien Luke
la source
4
Cela ne l'explique pas. Qui utilise exactement la variable d'environnement et pourquoi se soucierait-il qu'un programme soit 32 bits ou 64 bits?
Synetech
4
@ Synetech - L'auteur de programmes utilise la variable d'environnement. Quant à la raison pour laquelle cela serait utile, c'est à cause des références aux dll. Vous ne pouvez pas charger une DLL 32 bits dans un processus 64 bits et inversement.
Ramhound
1
Et comment faire %programfiles%, %programfiles(x86)%ou %programw6432%faire une différence là - bas? Toutes les DLL partagées vont dans le seul répertoire WinSxS et toutes les DLL non partagées se trouvent là avec l'exécutable. Cela n’aurait d’importance que si, pour une raison quelconque, les versions 32 bits et 64 bits du même programme étaient installées, et même dans ce cas, vous conserveriez les DLL 32 bits avec l’exécutable 32 bits et les DLL 64 bits avec l'exécutable 64 bits. Vous pouvez le faire comme %programfiles%\CoolApp\bin\32suit : et% programfiles% \ CoolApp \ bin \ 64`, pourquoi les dossiers de niveau supérieur distincts?
Synetech
@ Synetech Bien sûr que si; % programfiles% existe depuis un moment. Si vous installez un programme 32 bits sur un ordinateur 64 bits, le fait d'avoir un seul emplacement poserait des problèmes pour cette application 32 bits. Cependant, WoW peut rediriger% programfile% vers la version (x86) pour les applications 32 bits et la version non x86 pour la version 64.
Andy
Je pense que les gens ne seraient pas si confus s'il n'y avait pas de redirection implicite
kommradHomer
8

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 .

avirk
la source
1
Héhé. Bel article. Les commentaires de cet article sonnent exactement comme ceux d’ici. Pire encore, cet article datait de plus de deux ans, ce qui montre simplement que cette question n'est pas nouvelle et si on ne peut toujours pas y répondre avec autorité, alors j'imagine que ce ne sera jamais le cas (à moins que quelqu'un de l'équipe Windows ne vienne nous entendre). Oh bien, je suppose que nous devrions tous simplement cesser de nous inquiéter et apprendre à aimer la bombe, euh, je veux vivre avec. +1 Pour avoir souligné l'article et montré que cette question existait depuis si longtemps.
Synetech
1
@ Synetech merci! Ouais, l'idée de mettre le lien de l'article est la même que celle que vous avez. C'est une question très ancienne mais IDK, pourquoi les gens ne pouvaient pas l'obtenir pour le moment. Cependant, le MS devrait écrire une base de connaissances ou de la documentation pour résoudre ce problème :)
2012
Oui, ils le devraient, surtout parce que ce ne sont pas seulement les développeurs qui le demandent, même les utilisateurs normaux s’interrogent. Malheureusement, la documentation de Microsoft n'est pas souvent très bonne.
Synetech
@ Synetech yup! La documentation MS est nulle la plupart du temps. Mais oui, ils ont aussi écrit de bons articles et je suis sûr qu'ils sont dénombrables;)
avril
6

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.

BlueRaja - Danny Pflughoeft
la source
2
+1 Au moins, vous avez abordé la question sous-jacente de savoir pourquoi les utilisateurs moyens disposeraient des deux versions.
Synetech
5

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.

Diogo
la source
7
Mais pourquoi doit-il le mettre dans des dossiers différents? Windows est déjà pleinement capable de déterminer l'architecture d'un exécutable en regardant l'en-tête PE. Pourquoi ne peut-il pas charger l'environnement approprié lorsqu'il charge l'exécutable?
Synetech
1
Je pense que c'est juste un choix de Microsoft de montrer facilement aux utilisateurs quelle architecture ils veulent à partir de la version à deux programmes lors de l'ouverture d'un programme. Je veux dire, s'il n'y avait pas ces deux dossiers et s'ils étaient transparents pour les utilisateurs (s'ils basculaient automatiquement), ils ne sauraient pas si ils utilisaient une application 32 ou 64 bits, même s'ils ne savaient pas quel programme ouvrir. si vous utilisez 64 bits ..
Diogo
1
La version 64 bits d'IE a la réputation d'être terrible.
Samuel Edwin Ward
1
MS recommande d'utiliser office32 sauf si vous travaillez avec des jeux de données suffisamment volumineux pour dépasser les contraintes de mémoire. Je crois que le besoin de recompiler des addons binaires pour travailler avec office64; combinée avec le fait de ne donner aucun avantage dans les cas d'utilisation normale est à l'origine de la décision.
Dan Neely
1
Je pense que vous constaterez qu'un programme 64 bits explicitement installé dans le dossier Program Files (x86) fonctionnera parfaitement normalement (et, dans la plupart des cas, inversement). Windows n'utilise pas l'emplacement du dossier pour déterminer comment traiter l'exécutable.
Harry Johnston
5

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.

RockPaperLizard
la source
3

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é.

Dennis
la source
Désolé j'ai mélangé "permis" avec "interdit"
Wernfried Domscheit
3

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

Jason Locke
la source
1
Comment fait ProgramFiles(x86)` avoid clutter? There are still both 32- and 64-bit versions of files, so avoiding clutter doesn't make sense. There is no difference between putting them in \ 32 \ blah` ou \blah\32; de toute façon, ils sont séparés. En fait, la méthode actuelle sépare les composants de l'application (et les duplique également inutilement, car peu d'applications utilisent CommonFilesdes ressources, etc.). De plus, vous donnez l'impression que les applications déchargent leurs DLL dans un compartiment commun. Il est assez facile de conserver les applications DLL 32 bits avec ses exes 32 bits et ses DLL 64 bits avec ses exes
Synetech
Oh, et pour 95/98, qui a dit quoi que ce soit à ce sujet? Même XP avait un sous-système 16 bits (NTVDM).
Synetech
Je pensais que tu voulais une explication. Peu d'applications utilisent CommonFiles? J'ai 35 applications différentes qui ont des entrées ici. C'est un endroit plus sûr pour stocker des composants partagés que le répertoire System32. Votre déclaration selon laquelle peu d'applications utilisent cela est discutable. En vous citant: "Ils n'ont pas eu à franchir ces étapes pour autoriser des programmes 32 bits et 16 bits sur le même système. Je ne me souviens pas d'avoir jamais vu un ProgramFiles (16) ou quelque chose de ce genre [...] La partie concernant le fait que cela soit pratique pour les programmeurs reste toutefois raisonnable. " Eh bien, oui ... les programmeurs le font. Nous écrivons les applications après tout.
Jason Locke Le
Huh?
Synetech
Il suffit de relire ceci .. il l’a dit mieux dans ses réponses - superuser.com/a/442253/142951 . Si vous n'êtes pas un développeur, vous ne verrez peut-être pas le but.
Jason Locke Le
0

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.

Wernfried Domscheit
la source