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

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

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

Existe-t-il un moyen de modifier la valeur par défaut pour être C:\Program Files place? Est-ce que cela dérangerait si je mettais tout dans C:\Program Files ?

Si, en effet, il y a un avantage pour avoir un dossier distinct pour les applications de 64 bits, il semble que le défaut plus raisonnable aurait été d'utiliser C:\Program Files pour les applications x86 et de créer un nouveau dossier C:\Program Files (x64) pour Les nouvelles applications 64 bits. Cela aiderait à maintenir une compatibilité ascendante. Je travaille comme développeur de logiciels et certains de mes projets contiennent des références de chemin vers des bibliothèques sous C:\Program Files . Maintenant, ces références sont brisées sur la machine Windows 7 qui les a placées dans C:\Program Files (x86) . J'ai même essayé de modifier l'emplacement cible dans le programme d'installation pour être C:\Program Files , mais cela a été ignoré et l'application est passée dans C:\Program Files (x86) toute façon.

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

Édition concernant les variables d'environnement: (Utiliser uniquement les valeurs par défaut des variables anglaises pour la simplicité.) Sur une machine 64 bits %ProgramFiles% sera C:\Program Files alors que la nouvelle variable %ProgramFiles(x86)% sera C:\Program Files (x86) . Donc, si vous avez un programme 32 bits qui doit trouver le chemin de dossier qu'il serait installé sous, il faudrait vérifier s'il fonctionnait sur une version 32 bits ou 64 bits de Windows dans l'ordre Pour savoir quelle variable d'environnement à utiliser. Toutes les applications 32 bits qui ont été écrites sans cette considération devront être mises à jour pour fonctionner correctement sur une machine 64 bits. Donc, même en utilisant des variables d'environnement, la compatibilité ascendante est interrompue.

En outre, %ProgramFiles(x86)% n'existe pas sur les versions 32 bits de Windows. Si tel était le cas, les applications 32 bits pourraient toujours utiliser cette variable d'environnement et ne nécessiteraient aucune logique conditionnelle basée sur le système d'exploitation OS sur lequel elles fonctionnent.

La raison en est tout simplement que de nombreux installateurs plus anciens ne comprennent pas la nouvelle structure de fichier et ne font pas appel à tout ce qui se trouve dans le répertoire des fichiers de programme standard ou si vous regardez un programme intelligent comportant quelques composants de 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 se installe juste pour exclure un problème avec votre machine.

En ce qui concerne les choses dérangeantes, cela peut, mais cela dépend vraiment du programme, il n'y a pas une seule réponse pour tous … certains programmes plus petits et compacts avec quelques fichiers ne devraient pas avoir de problème, où, si vous parlez d'Office , Adobe ou tout autre "suite" ou un grand programme, il risque d'échouer, car il existe de nombreux composants partagés qui sont des architectures croisées.

Si vous utilisez autre chose que %ProgramFiles% (ou CSIDL_PROGRAM_FILES ou sous .NET Environment.GetFolderPath(Environment.SpecialFolder.ProgramFiles) ), vous rencontrez toujours des problèmes, 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.

Windows espagnol: C:\Archivos de Programa ,
Français Windows: C:\Programmes ,
Windows allemand: C:\Programme ,
Swedish Windows: C:\Program

etc.

Notez 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 que confirmer cela pour Win 7 64 bits), il existe une différence entre l'emplacement de votre% ProgramFiles% Dans l'explorateur et dans DOS.

Sous Windows 7, l'emplacement du dossier physique réel de% ProgramFiles% (et la variable associée% ProgramFiles (x86)% environemnt) est corrigé selon la version anglaise ; C'est-à-dire "C: \ Program Files" et "C: \ Program Files (x86)" respectivement, mais est affiché dans l'exploitant localisé, le cas échéant.

Fournir un exemple spécifique; Sur une installation suédoise Windows 7 à 64 bits, si vous ouvrez l'Explorateur et regardez dans le lecteur du système (généralement C 🙂 vous voyez les dossiers " Programme " et " Programme (x86) ". Tapez% ProgramFiles% dans la barre d'adresse vous transforme en "C: \ Program".

Cependant, si vous ouvrez une zone DOS et tapez SET, vous verrez que la valeur réelle de% ProgramFiles% est "C: \ Program Files" et que l'utilisateur du dossier "C: \ Program" ne vous présente pas. En explorant davantage avec CD et DIR, vous pouvez le voir physiquement "C: \ Program Files"

La morale est que si vous utilisez les varaibles ou les programmes environnementaux via l'API, tout fonctionnera encore, mais soyez conscient de ce changement subtil lors de l'exploration du système de fichiers!