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 Files
place? 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 Files
pour 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 Files
alors 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.
la source
%ProgramFiles%
variable d'environnement aurait résolu ce problème. Je ne sais pas comment il gère la différence x86 / 64 bits.Réponses:
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.
la source
Si vous utilisez autre chose que
%ProgramFiles%
(ouCSIDL_PROGRAM_FILES
, ou sous .NETEnvironment.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.C:\Archivos de Programa
,C:\Programmes
,C:\Programme
,C:\Program
etc.
la source
%ProgramFiles%
est exactement ce qui cause le problème.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!
la source