Pourquoi Windows 7 installe-t-il des applications 64 bits dans le dossier Program Files (x86)? Puis-je changer le comportement?

12

J'utilise la version 64 bits de Windows 7 depuis le CTP et j'ai rencontré quelques problèmes avec les applications installées dans le C:\Program Files (x86)dossier. Quel est le but d'avoir 2 répertoires Program Files distincts de toute façon?

Chaque programme que j'ai installé est entré dans le C:\Program Files (x86)dossier. Peu importe que l'application soit en 32 ou 64 bits. Pourquoi les applications 64 bits ne sont-elles pas placées C:\Program Files?

Existe-t-il un moyen de modifier la valeur par défaut à la C:\Program Filesplace? Est-ce que ça gâcherait quelque chose si je mettais tout dedans C:\Program Files?

S'il y a effectivement un avantage à avoir un dossier séparé pour les applications 64 bits, il semble que la valeur par défaut la plus raisonnable aurait été d'utiliser C:\Program Filespour les applications x86 et de créer un nouveau C:\Program Files (x64)dossier pour les nouvelles applications 64 bits. Cela aiderait à maintenir la compatibilité descendante. Je travaille en tant que développeur de logiciels et certains de mes projets contiennent des références de chemin d'accès aux bibliothèques sous C:\Program Files. Maintenant, ces références sont rompues sur la machine Windows 7 qui les a placées C:\Program Files (x86). J'ai même essayé de changer l'emplacement cible dans le programme d'installation C:\Program Files, mais cela a été ignoré et l'application est entrée de C:\Program Files (x86)toute façon.

C'est très frustrant car j'ai besoin de partager le code source entre des machines 32 et 64 bits et je ne veux pas avoir à jouer avec un fichier de configuration qui définit le chemin d'accès à ces bibliothèques différemment sur différentes machines.

Modifier en ce qui concerne les variables d'environnement: (. En utilisant uniquement les valeurs par défaut en anglais des variables pour la simplicité) Sur une machine 64 bits %ProgramFiles%sera C:\Program Filesalors la marque nouvelle variable %ProgramFiles(x86)%sera C:\Program Files (x86). Donc, si vous avez un programme 32 bits qui doit trouver le chemin du dossier sous lequel il serait installé, il devra vérifier s'il fonctionne sur une version 32 bits ou 64 bits de Windows afin pour savoir quelle variable d'environnement utiliser. Toutes les applications 32 bits écrites sans cette considération devraient être mises à jour pour fonctionner correctement sur une machine 64 bits. Ainsi, même en utilisant des variables d'environnement, la compatibilité descendante est rompue.

N'existe %ProgramFiles(x86)%pas non plus sur les versions 32 bits de Windows. Si c'était le cas, les applications 32 bits pourraient simplement toujours utiliser cette variable d'environnement et n'auraient pas besoin de logique conditionnelle en fonction du système d'exploitation sur lequel elles s'exécutent.

CoderDennis
la source
6
Êtes-vous certain que ces applications sont en effet 64 bits? Dans la plupart des cas, vous trouverez des programmes qui ne sont compatibles qu'avec 64 bits, mais qui sont en fait des applications 32 bits.
John T
Je me demande si l'utilisation de la %ProgramFiles%variable d'environnement aurait résolu ce problème. Je ne sais pas comment il gère la différence x86 / 64 bits.
ceejayoz

Réponses:

7

La raison en est simplement que de nombreux installateurs plus anciens ne comprennent pas la nouvelle structure de fichiers et ne placent pas tout dans le répertoire des fichiers de programme standard ou vous regardez un programme intelligent qui a quelques composants 32 bits qui y sont copiés.

Votre meilleur pari est de télécharger un nouveau programme - tel que x64 Winrar et de voir où il s'installe pour simplement exclure un problème avec votre machine.

En ce qui concerne les problèmes, cela peut, mais cela dépend vraiment du programme, il n'y a pas de réponse unique à tous ... certains programmes plus petits et compacts avec seulement quelques fichiers ne devraient avoir aucun problème, où, si vous parlez d'Office , Adobe ou tout autre "suite" ou programme volumineux, il échouera très probablement car ils ont de nombreux composants partagés qui sont multi-architectures.

William Hilsum
la source
Alors, pourquoi Microsoft n'a-t-il pas fait de "C: \ Program Files" l'emplacement des applications 32 bits pour que ces anciens installateurs ne causent pas de problèmes. De plus, je ne comprends pas vraiment pourquoi il doit y avoir une séparation. Pourquoi ne peuvent-ils pas tous aller dans "C: \ Program Files"?
CoderDennis
La raison pour laquelle les deux ne le peuvent pas est que certaines applications (en particulier celles avec des composants partagés) ont des fichiers portant le même nom sur 32 bits que sur 64 bits. Quant à savoir pourquoi il en est ainsi - je n'en ai aucune idée, quelqu'un avait probablement une très bonne raison à l'époque et c'est tout simplement "la chose à faire".
William Hilsum
4

Si vous utilisez autre chose que %ProgramFiles%(ou CSIDL_PROGRAM_FILES, ou sous .NET Environment.GetFolderPath(Environment.SpecialFolder.ProgramFiles)), vous avez des problèmes de toute façon, car les installations personnalisées peuvent avoir des programmes installés sous d'autres volumes (D: par exemple) et les installations internationales ont souvent d'autres dossiers par défaut.

  • Espagnol Fenêtres: C:\Archivos de Programa,
  • Windows français: C:\Programmes,
  • Allemand de Windows: C:\Programme,
  • Fenêtres suédoises: C:\Program

etc.

Zano
la source
Je n'ai pas mentionné les variables d'environnement dans ma question d'origine pour rester simple. Je viens d'ajouter une modification qui montre comment l'utilisation %ProgramFiles%est exactement ce qui cause le problème.
CoderDennis
3

Veuillez noter que sous les versions 64 bits de Windows 7 (cela peut également s'appliquer à d'autres versions de système d'exploitation plus récentes, mais je ne peux le confirmer que pour Win 7 64 bits), il existe une différence entre l'emplacement apparent de votre% ProgramFiles% dans l'explorateur et sous DOS.

Sous Windows 7, l'emplacement réel du dossier physique de% ProgramFiles% (et la variable d'environnement% ProgramFiles (x86)% associée) est fixé selon la version anglaise ; c'est-à-dire "C: \ Program Files" et "C: \ Program Files (x86)" respectivley, mais est affiché dans l'explorateur localisé comme approprié.

Pour fournir un exemple spécifique; sur une installation suédoise de Windows 7 64 bits, si vous ouvrez l'Explorateur et regardez dans le lecteur système (généralement C :), vous voyez les dossiers " Program " et " Program (x86) ". Taper% ProgramFiles% dans la barre d'adresse vous déplace dans "C: \ Program".

Cependant, si vous ouvrez une boîte DOS et tapez SET, vous verrez que la valeur réelle de% ProgramFiles% est "C: \ Program Files" et non l'explorateur de dossier "C: \ Program" vous le montre. En explorant davantage avec CD et DIR, vous pouvez voir que c'est physiquement "C: \ Program Files"

La morale est que si vous utilisez les variables d'environnement ou le programme via l'API, tout fonctionnera toujours, mais soyez conscient de ce changement subtil lorsque vous explorez le système de fichiers!

Pete Stensønes
la source
Dans la version polonaise "Program Files (x86)" est "Pliki programów (x86)", tandis que "Program Files" est, eh bien ... "Program Files". Le polonais a une grammaire bizarre. Aussi, ne l'appelez pas une boîte DOS. Il n'y a pas de DOS là-bas.
kinokijuf