Question Pourquoi Windows 64 bits nécessite-t-il un dossier distinct "Program Files (x86)"?


Je sais que sur une version 64 bits de Windows, le dossier "Program Files" est destiné aux programmes 64 bits et le dossier "Program Files (x86)" aux programmes 32 bits. pourquoi est-ce même nécessaire?

Par "nécessaire", je ne veux pas dire "pourquoi Microsoft n’a-t-il pas pris d’autres décisions en matière de conception?" car bien sûr ils pourraient avoir. Je veux dire plutôt "pourquoi, compte tenu de 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, "qu'est-ce qui irait mal si, d'une manière ou d'une autre, j'évitais le mécanisme de redirection et forçais tout à installer sur le vrai C:\Program Files\? "

Il y a beaucoup de questions sur Super User et ailleurs qui affirment que «l'un est pour les programmes 32 bits, l'autre est pour les programmes 64 bits», mais aucun ne peut en donner la raison. De mon expérience, il ne fait pas sembler importe si un programme 32 bits est installé au bon endroit ou non.

Windows se présente-t-il différemment à un programme fonctionnant avec "Program Files (x86)"? Y a-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.


175
2018-06-27 17:19


origine


Plutôt que de répondre à votre question, je vous demanderais comment vous gérez \ les fichiers programme \ les fichiers communs? - sgmoore
One-liner answer (et donc un commentaire): comme vous pouvez facilement exécuter n'importe quelle application à partir de n'importe quel dossier sans connaître son architecture, il n'y a pas de obligatoire raison de cette séparation. C'est une question de commodité prendre en charge les doubles installations d'applications avec les deux architectures. Dans certains cas, cela fait une différence car ce ne sont pas nécessairement de simples recompilations. Le problème principal est que les applications 32 bits ne peuvent pas charger les DLL 64 bits, vous ne pouvez donc généralement pas installer les deux versions au même endroit. L'autre alternative est d'avoir deux dossiers "bin" pour chaque application. - Sklivvz
@Synetech J'ai même eu des programmes installant sous (x86) juste pour avoir des binaires x64 .. C'est parfois horrible. - sinni800
Je me suis toujours demandé pourquoi Microsoft ne mettait pas les programmes 64 bits dans un "Program Files (x64)" au lieu de "déplacer" le répertoire "Program hérité" vers Program Files (x86). - LawrenceC
Le vrai désordre de la différenciation 64 / 32bit est que / Windows / System32 contient un contenu de 64 bits, tandis que / Windows / SysWOW64 contient le contenu de 32 bits ... - poke


Réponses:


Réponse courte: pour garantir que les applications 32 bits héritées continuent à fonctionner de la même manière sans imposer de règles désagréables sur les applications 64 bits, ce qui créerait un désordre permanent.

Ce n'est pas nécessaire. Il est juste plus pratique que d’autres solutions possibles, par exemple, exiger que chaque application crée sa propre façon de séparer les DLL et exécutables 32 bits des DLL et exécutables 64 bits.

La principale raison est de faire en sorte que les applications 32 bits qui ne connaissent même pas les systèmes 64 bits existent "juste pour fonctionner", même si des DLL 64 bits sont installées à des endroits où les applications peuvent apparaître. Une application 32 bits ne pourra pas charger une DLL 64 bits. Une méthode était donc nécessaire pour garantir une application 32 bits (pouvant être antérieure aux systèmes 64 bits et donc ne pas avoir de fichiers 64 bits même exister) ne trouverait pas une DLL 64 bits, essayez de le charger, échouez, puis générez un message d'erreur.

La solution la plus simple consiste à créer des répertoires distincts. La seule alternative est d’exiger que chaque application 64 bits "cache" ses fichiers exécutables quelque part où une application 32 bits n’aurait pas l’air, bin64 répertoire dans cette application. Mais cela imposerait une laideur permanente sur les systèmes 64 bits uniquement pour prendre en charge les applications héritées.


89
2018-06-27 18:18



Ils n'ont pas eu à passer par ces obstacles 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 contournent la recherche de DLL aléatoires dans %programfiles%? S'il s'agit d'une DLL partagée, elle se trouve dans WinSxS; s'il n'est pas partagé, il appartient au programmeur de gérer ses propres DLL. La partie à propos de ce fait comme une commodité pour les programmeurs raisonnable. - Synetech
IIRC Win3.1 n’avait pas de répertoire de fichiers programme (ou la plupart des applications l’ignoraient); En conséquence, il n'y aurait pas d'anciennes applications win16 à la recherche d'éléments dans les fichiers de programme. Au lieu de cela, les bibliothèques partagées par l'IIRC étaient souvent placées quelque part dans le dossier Windows lui-même. Win32 ayant Windows \ System et Windows \ System32 en est un artefact. - Dan Neely
Windows 3.1 ne supportant pas les noms de fichiers longs, il n'aurait donc pas été possible d'avoir un dossier 'program files'. - Darth Egregious
@JarrodRoberson: Au contraire, c'est parce que Microsoft accorde une très grande importance à la rétrocompatibilité. - David Schwartz
@Jarrod: En fait, comme tous les développeurs le savent, Microsoft accorde une grande importance à la compatibilité aussi très. Littéralement, toutes les API qu’elles ont ont des méthodes héritées qu’elles refusent de supprimer, et souvent sérieux bugs qu'ils refusent de corriger, car ils ont peur de briser les anciens programmes écrits pour cette API. La même chose est vraie pour la plupart des API, mais nulle part près de celle de Microsoft. - BlueRaja - Danny Pflughoeft


Il vous permet d’installer à la fois la version 32 bits et la version 64 bits d’une application sans l’écraser.


Après avoir examiné cette réponse et commenté le fil de discussion le lendemain, je me rends compte d’une possible erreur majeure dans ma réponse. J'ai faussement assumé un contexte de programmation et quand je parlais de toi 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éal raisonnement derrière ces dossiers est, mais je pense que la raison d'avoir ces dossiers est tellement évident que je n'ai aucun problème à en discuter.

Alors, brisons-le!

  1. Les dossiers sont géniaux!

    Soyons d'accord sur quelque chose. Les dossiers sont géniaux! Nous n'en avons pas besoin, nous avons assez de noms de fichiers possibles pour placer chaque fichier sur la racine de votre disque dur, alors pourquoi avoir des dossiers?

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

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

    Un paradigme souvent trouvé dans la programmation est de séparer les données de la logique. Vous voulez une partie qui sait Comment faire quelque chose et vous voulez une autre partie vous peut faire quelque chose avec


65
2018-06-27 17:31



Est-ce la raison originale, cependant? Ne pourrais-je pas installer l'application pour C:\Program Files\App32 et C:\Program Files\App64? - Stephen Jennings
@StephenJennings: Mais cela nécessiterait que vous preniez manuellement la décision. La façon dont cela fonctionne maintenant est que le processus est automatique, car Windows sait quel dossier fournir lorsqu’une application appelle SHGetSpecialFolderPath pour déterminer l'emplacement d'installation. - Der Hochstapler
@Synetech: Pourquoi installer dans %PROGRAMFILES% en 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
@Synetech: Oui, vous avez donné un très bon 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 il est en train de se faire maintenant. Il suffit d'écrire un fichier dans% PROGRAMFILES% et de vous assurer qu'il se retrouvera dans le bon dossier. Vérifier par vous-même quel dossier est le correct l'un est un autre. Si vous ne voyez pas les avantages de la première approche, je ne pourrai pas vous convaincre. La question était pourquoi il y a 2 dossiers. Je pense que ma réponse est parfaitement raisonnable à cet égard. - Der Hochstapler
@OliverSalzburg, pas tout à fait. La question est pourquoi deux dossiers sont Champs obligatoires, pas pourquoi sont. En fait, il l'a même mis en gras: pourquoi est-ce même nécessaire? Vous n'avez pas expliqué pourquoi c'est nécessaire et l'exemple que j'ai donné (et même votre propre exemple sarcastique) montre simplement qu'il ne avoir se faire comme il est. - Synetech


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 d'un programme exécuté à partir d'un emplacement ou d'un autre.


Eh bien, tout le monde semble donner son avis là-dessus, alors je vais ajouter mes 2 ¢. D'autres ont déjà conjecturé sur les raisons de Pourquoi Microsoft a choisi de créer des dossiers de premier niveau distincts pour les versions 32 bits et 64 bits des programmes. Je vais donc laisser cette partie (la meilleure raison était l'explication de David que cela était pratique pour les programmeurs). Bien sûr, même à ce moment-là, cela ne répond pas tout à fait à la question directe pourquoi est-ce 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 différemment à un programme fonctionnant avec "Program Files (x86)"?

Pas vraiment, mais l'emplacement du programme pouvez affecter le comportement, mais pas de la façon dont vous penseriez.

Lorsque vous exécutez un programme, Windows configure un environnement dans lequel il doit être exécuté (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. On l'appelle WoW64 (WoW64 signifie Windows sur Windows 64 bits) et est similaire à la façon dont les applications 16 bits seraient exécutées sous XP en utilisant le 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 des exemples de dépendances d’emplacement, comme certains pilotes par exemple).

(J'utilise un autre ordinateur, donc je ne peux pas compter sur l'historique de mon navigateur pour revenir en arrière, mais l'autre jour, tout en répondant cette question de SU Je me suis retrouvé à cette question SO ce qui m'a amené à Google PROCESSOR_ARCHITEW6432qui conduisent à cette question SO et cette publication de blog Microsoft.)

En cours de route, je lis un article de StackOverflow sur la façon dont la variable envirnoment %processor_architecutre%  donne des résultats différents selon l'endroit où vous exécutez l'invite de commande à partir de (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 commandes était exécutée (c’est-à-dire depuis System32\ ou SysWoW64\). En d'autres termes, alors que l'emplacement semble être affecter le comportement du programme, c'est seulement parce qu'il existe différentes versions du programme, pas parce que Windows traite le dossier d'une manière spéciale.

Cela a du sens parce que le contenu du fichier exécutable dicte s'il est 32 bits ou 64 bits, vous pouvez donc mettre à la fois une copie 32 bits et 64 bits du même programme (par exemple, foobar32.exe et foobar64.exe) dans le même dossier et quand vous les exécuterez, ils seront correctement chargés (la version 64 bits sera exécutée en mode natif et celle 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 conservant les fichiers exécutables (.exe, .sys, .dll, .ovr, etc.) dans des dossiers séparés et en partageant des fichiers de ressources tels que des images, des fichiers sources, etc.) Il n’ya aucune raison technique pour que cela ne soit pas possible pour les versions 32 et 64 bits d’un programme. Comme l’a dit David, c’est plus facile pour le programmeur s’il est séparé (c’est-à-dire, en utilisant des variables pour faire croire qu’il n’ya qu’un seul ensemble de fichiers, etc.).


14
2018-06-27 19:23



Vengeance contre le vote! Muahahaha! soupir - Synetech
Down-vote étrange: \. BTW bon expliquer +1. - avirk


Une autre raison est que la plupart des programmes utilisaient des variables environnementales telles que% PROGRAMFILES% pour indiquer où leur programme était installé. Pour les programmes 64 bits, il passe à l’endroit normal. Pour les programmes 32 bits, il redirigera cela vers le nouveau Program Files (x86) dossier.

Bien que, au moins avec les nouvelles fonctionnalités de .Net dans Visual Studio, elles disposent désormais de la variable App.Local qui élimine tout ce besoin.


11
2018-06-27 17:36



Cela ne l'explique pas. Qui utilise exactement la variable d'environnement et pourquoi se soucierait-elle qu'un programme soit 32 bits ou 64 bits? - Synetech
@ Synetech - L'auteur des programmes utilise la variable d'environnement. Pour ce qui est de la raison, cela est dû aux références à dlls. Vous ne pouvez pas charger une DLL 32 bits dans un processus 64 bits et inversement. - Ramhound
Et comment %programfiles%, %programfiles(x86)%, ou %programw6432% faire la 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 directement avec l'exécutable. Cela importerait seulement si, pour une raison quelconque, les versions 32 bits et 64 bits du même programme étaient installées et même si vous conserviez les DLL 32 bits avec l'exécutable 32 bits et la DLL 64 bits avec l'exécutable 64 bits. Vous pouvez le faire comme ça: %programfiles%\CoolApp\bin\32 et% programfiles% \ CoolApp \ bin \ 64`, pourquoi les dossiers de niveau supérieur séparés? - Synetech
@Synetech Bien sûr que oui; % programfiles% a été autour d'un moment. Si vous installez un programme 32 bits sur un ordinateur 64 bits, le fait d’avoir un emplacement unique entraînerait des problèmes pour cette application 32 bits. WoW peut cependant rediriger% programfile% vers la version (x86) pour les applications 32 bits et la version non-x86 pour 64. - Andy
Je pense que les gens ne seraient pas si confus, s'il n'y avait pas de redirection implicite - kommradHomer


La solution de Microsoft à cette transition de 32 bits à 64 bits consistait à ajouter une prise en charge héritée 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. Gardez à l'esprit que les autres systèmes d'exploitation fonctionnant sur une architecture 64 bits ne peuvent pas charger ou exécuter des 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 de se mélanger aux véritables applications 64 bits du dossier Program Files standard.

La source 

"Que se passerait-il si j'évitais en quelque sorte le mécanisme de redirection et forçais tout à installer sur le vrai C: \ Program Files \?" 

Rien. Les deux répertoires de programme sont uniquement destinés à l'organisation ou pour conserver des 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 programmes d'installation 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 (identique à celui des systèmes 32 bits); alors que le nom abrégé du dossier Program Files (x86) 32 bits est maintenant Progra ~ 2.


8
2018-06-28 16:28



Hehe. Bel article. Les commentaires sur cet article ressemblent exactement à ceux présentés ici. Pire encore, cet article date de plus de deux ans, ce qui montre que cette question n’est pas nouvelle et qu’il ne peut toujours pas y être répondu de manière officielle, alors je suppose que ce ne sera jamais le cas (à moins que l’équipe Windows ne le fasse). Eh bien, je suppose que nous devrions tous 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
@Synetech merci! Ouais, l'idée de mettre le lien d'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 encore l'obtenir. Cependant, la MS doit écrire un KB ou une documentation pour ce problème :) - avirk
Oui, surtout parce que ce ne sont pas seulement les développeurs qui demandent, même les utilisateurs normaux se posent la question. Malheureusement, la documentation de Microsoft n'est pas souvent trop bonne. - Synetech
@ Synetech yup! La documentation MS moque la plupart du temps. Mais oui, ils ont aussi écrit de bons articles et je suis sûr qu'ils sont dénombrables;) - avirk


La raison en est de rendre la mise à niveau d'un programme à 64 bits plus facile 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 vérifient juste C:\Program Files, et en mode 32 bits, cela devient automatiquement C:\Program Files (x86) par Windows 64 bits. De même, les entrées de registre sont isolées entre les programmes 32 bits et 64 bits.

Cela évite les conflits de la part de développeurs inconscients qui modifient simplement leur mode de compilation en 64 bits sans y penser beaucoup, et préviennent une énorme quantité de travail pour les développeurs souhaitant que les utilisateurs puissent installer les versions 32 et 64 bits de leur ordinateur. logiciel simultanément.


Mais pourquoi n'importe quel programme voudrait-il permettre que les deux versions soient installées simultanément? Un exemple: Photoshop et IE ont des extensions qui sont natives .dll. Vous ne pouvez pas mélanger du code 32 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 avoir pour permettre aux deux versions d'être installées, ou risquer de casser leur énorme base d'addons existants.


6
2018-06-27 18:48



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


Les programmes qui s'exécutent sur "Program Files (x86)" utilisent le WOW64 sous-système (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   possède des interfaces similaires sur toutes les versions 64 bits de Windows. Il vise à   créer un environnement 32 bits fournissant les interfaces nécessaires pour   exécuter des applications Windows 32 bits non modifiées sur un système 64 bits.   Techniquement, WoW64 est implémenté en utilisant trois bibliothèques de liens dynamiques   (DLL):

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

Le système 64 bits doit "émuler" les applications 32 bits, c'est pourquoi Windows doit "séparer" deux dossiers Program Files.


5
2018-06-27 17:32



Mais pourquoi faut-il le mettre dans des dossiers différents? Windows est déjà entièrement capable de déterminer l'architecture d'un exécutable en examinant l'en-tête PE. Pourquoi ne peut-il pas charger l'environnement approprié lorsqu'il charge l'exécutable? - Synetech
Je pense que ce n'est qu'un choix de Microsoft pour montrer facilement aux utilisateurs l’architecture qu’ils souhaitent à partir de deux versions de programmes lors de l’ouverture d’un programme. Je veux dire, s’il n’y avait pas ces deux dossiers et s’il était transparent pour les utilisateurs (s’il change automatiquement), ils ne sauraient pas exécuter une application 32 ou 64 bits, même ils ne sauraient pas quel programme ouvrir si fonctionne sur 64 bits .. - Diogo
La version 64 bits d'IE a la réputation d'être terrible. - Samuel Edwin Ward
MS recommande d'utiliser office32 sauf si vous travaillez avec des ensembles de données suffisamment importants pour dépasser les contraintes de mémoire. Je crois que le besoin de recompiler les addons binaires pour travailler avec office64; combinée à ne pas donner des avantages dans les cas d'utilisation normale est derrière la décision. - Dan Neely
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, vice versa). Windows n'utilise pas l'emplacement du dossier pour déterminer comment traiter l'exécutable. - Harry Johnston


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

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

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

Cela se produit automatiquement et est indépendant de l'endroit où l'application est stockée. Il n'y a pas de vitesse, de fiabilité ou d'autres avantages fonctionnels à avoir des dossiers 32 bits et 64 bits distincts.

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) moyen simple de garder les fichiers superposés séparés. Même dans ce cas, tant que tous les noms de fichiers sont uniques, ils pourraient exister dans le même dossier sans aucune conséquence.

Il y a une mise en garde à la conclusion ci-dessus, et c'est celle des applications mal codées. Si une application contient des chemins codés, elle utilisera uniquement ce chemin. En règle générale, les chemins ne doivent jamais être codés en dur dans une application, mais parfois un programmeur commet cette erreur. Dans ce cas, le programme utilisera le chemin d'accès codé en dur; le répertoire dans lequel l'application est installée n'affectera pas l'endroit où elle recherche les fichiers.


5
2017-10-16 19:57





La nécessité de séparer les dossiers permet de conserver les applications natives 64 bits et celles qui nécessitent WoW64 une part.

Cela peut être utile - comme @OliverSalzburg déjà indiqué - si vous souhaitez installer à la fois le 64-bit et 32-bit d'un navigateur Web (par exemple), puisque certains plug-ins et add-ons peuvent uniquement être disponibles pour l'un des deux.

Avoir à séparer des dossiers fait cette séparation automatique, en utilisant des techniques telles que redirection du registre.

Supposons qu'un installateur essaie de déterminer le dossier des fichiers programme en lisant le registre en utilisant, par exemple, RegQueryValueEx.

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

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion

qui indique normalement C:\Program Files.

Cependant, si le programme d’installation est une application 32 bits, la redirection du registre provoquera la clé de regitry

HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion

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

Pourquoi ces particulier les noms de dossiers utilisés ne peuvent être répondus que par les personnes qui ont fait ce choix. Vous pouvez toujours modifier les noms des dossiers par défaut si vous le souhaitez.

Windows se présente-t-il différemment à un programme fonctionnant avec "Program Files (x86)"?

J'en doute. La plupart des installateurs vous permettent de choisir un dossier d'installation personnalisé, cela n'a donc pas d'importance  un programme est installé.


3
2018-06-27 18:40



Désolé j'ai mélangé "permis" avec "interdit" - Wernfried Domscheit


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

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

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

En l'état, 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 est uniquement pour 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 assembly.

C'est tout ce qui concerne les développeurs. En tant qu'utilisateur, je n'ai à gérer que lorsque je travaille avec un programme 32 bits sur 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. Lorsque je travaille sur une application 32 bits que je dois compiler en 64 bits, tout ce que je fais est de demander au compilateur de le faire. Dll noms 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 simulaient une exécution 32 bits; ce n'était pas un véritable système d'exploitation 32 bits. Il a simulé une exécution de 32 bits avec quelque chose appelé "thunking".

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


3
2018-06-28 14:43



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 sont utilisées). CommonFiles pour les ressources et autres. En outre, vous faites croire que les applications vident leurs DLL dans un compartiment commun. Il est assez facile de conserver les DLL 32 bits d'une application avec ses exes 32 bits et ses DLL 64 bits avec ses exes 64 bits. - Synetech
Oh, et pour 95/98, qui a dit quelque chose à ce sujet? Même XP avait un sous-système 16 bits (le NTVDM). - Synetech
Je pensais que tu voulais une explication. Peu d'applications utilisent les CommonFiles? J'ai 35 applications différentes qui ont des entrées là-bas. 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 l'utilisent est discutable. En vous citant: "Ils n'ont pas eu à passer par ces obstacles 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 certains de ces programmes [...] La partie à propos de cela étant une commodité pour les programmeurs raisonnable. " Eh bien, oui, les programmeurs le font. Nous écrivons les applications après tout. - Jason Locke
Hein? - 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 pourriez ne pas voir le but. - Jason Locke


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 m'empêche 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, alors toujours la première DLL C:\Windows\System32\ntdll.dll est exécuté. Cette DLL détermine si votre programme est une application 32 ou 64 bits. Selon que vous êtes redirigé vers WoW64 qui est déjà mentionné dans plusieurs réponses.


0
2018-05-08 08:40