- В чём разница между папками «Program Files (x86)» и «Program Files» в Windows
- 32-битная и 64-разрядная Windows
- Что хранится в каждой папке
- Почему они разделяются
- Почему 32-битная папка называется (x86)
- Обычно это не имеет значения
- Change default Program Files installation directory location in Windows 10
- Change default Program Files directory
- Зачем 64-битной Windows нужна отдельная папка «Program Files (x86)»?
- 11 ответов 11
- логика
- Данные
- 1 папка программных файлов
- 2 папки с программными файлами
- Я до сих пор не понимаю. Это кажется бесполезным
- Хорошо, теперь я понял. Но почему бы тогда не использовать C:\Program Files\x86\ ?
- Что бы пошло не так, если бы я как-то избежал механизма перенаправления и заставил все установить на настоящий C:\Program Files\ ?
- Да, но я имею ввиду ВСЕ приложения!
В чём разница между папками «Program Files (x86)» и «Program Files» в Windows
Весьма вероятно, на вашем компьютере Windows Вы обнаружите две папки «Program Files» и «Program Files (x86)». Если вы соскучитесь, вы увидите, что некоторые из ваших программ установлены в одну папку, а некоторые – в другую.
32-битная и 64-разрядная Windows
Первоначально Windows была доступна только в 32-разрядной версии. В 32-битных версиях Windows – даже 32-разрядных версиях Windows 10, которые по-прежнему доступны сегодня, – вы увидите только папку «Program Files».
Эта папка Program Files является рекомендуемым местом, где установленные программы должны хранить исполняемые файлы, данные и другие файлы. Другими словами, программы устанавливаются в папку Program Files.
В 64-разрядных версиях Windows 64-разрядные приложения устанавливаются в папку Program Files. Однако, 64-разрядные версии Windows также поддерживают 32-разрядные программы, и Microsoft не хочет, чтобы 32-битное и 64-битное программное обеспечение смешивались в одном месте. Таким образом, 32-разрядные программы устанавливаются в папку «Program Files (x86)».
Windows запускает 32-разрядные приложения в 64-разрядных версиях Windows с использованием WOW64.
Когда вы запускаете 32-разрядную программу в 64-разрядной версии Windows, уровень эмуляции WOW64 плавно перенаправляет доступ к файлу с «C:\Program Files» на «C:\Program Files (x86)». 64-разрядные программы по-прежнему используют обычную папку Program Files.
Что хранится в каждой папке
Таким образом, в 32-разрядной версии Windows у вас есть только папка «Program Files». Она содержит все установленные вами программы, все из которых являются 32-разрядными.
В 64-разрядной версии Windows 64-разрядные программы хранятся в папке «Program Files», а 32-разрядные программы хранятся в папке «Program Files (x86)».
Вот почему разные программы распределяются между двумя папками Program Files, кажущимися случайными. В папке «Program Files» находятся 64-разрядные, а в папке «Program Files (x86)» – 32-разрядные приложения.
Почему они разделяются
Это функция совместимости предназначена для старых 32-разрядных программ. Эти 32-разрядные программы могут не знать, что 64-разрядная версия Windows даже существует, поэтому Windows изолирует их от 64-битного кода.
32-разрядные программы не могут загружать 64-разрядные библиотеки (DLL-файлы) и могут вылетать, если они попытаются загрузить определенный DLL-файл и обнаружат 64-битную версию вместо 32-разрядной. То же самое касается 64-разрядных программ. Сохранение различных программных файлов для разных архитектур процессоров предотвращает подобные ошибки.
Например, предположим, что Windows использует одну папку Program Files. 32-разрядное приложение может искать файл DLL Microsoft Office, расположенный в C:\Program Files\Microsoft Office, и попытаться загрузить его. Однако, если у вас установлена 64-разрядная версия Microsoft Office, приложение будет аварийно завершено и не будет работать должным образом. С отдельными папками это приложение не сможет найти DLL вообще, потому что 64-разрядная версия Microsoft Office будет в C:\Program Files\Microsoft Office, а 32-разрядное приложение будет искать в C:\Program Files (x86)\Microsoft Office.
Это также помогает, когда разработчик создает как 32-битную, так и 64-разрядную версию приложения, особенно если они должны быть установлены сразу обе. 32-разрядная версия автоматически устанавливается в C:\Program Files (x86), а 64-разрядная версия автоматически устанавливается в C:\Program Files. Если бы Windows использовала одну папку, разработчику приложения пришлось бы установить 64-разрядную папку в другую папку, чтобы разделить их.
Почему 32-битная папка называется (x86)
Вы не всегда будете видеть термины «32-разрядная» или «64-битная». Вместо этого иногда вы можете встретить «x86» и «x64» для обозначения этих двух разных архитектур. Это потому, что на ранних компьютерах использовался чип Intel 8086. Исходные чипы были 16-битными, но более новые версии стали 32-битными. «X86» теперь относится к до 32-битной архитектуре – будь то 16-разрядная или 32-разрядная. Новую 64-битную архитектуру называют «x64».
Это означает, что «Program Files (x86)» – это реализация папки Program Files для программ с использованием старой архитектуры процессоров x86. Заметим, однако, что 64-разрядные версии Windows не могут запускать 16-разрядный код .
Обычно это не имеет значения
Обычно не имеет значения, хранятся ли файлы программ в Program Files или Program Files (x86). Windows автоматически устанавливает программы в правильную папку, поэтому вам не нужно об этом думать. Программы отображаются в меню «Пуск» и функционируют нормально, независимо от того, где они установлены. Просто позвольте вашим программам автоматически решать, какую папку Program Files использовать.
Если вы используете переносное приложение, оно может запускаться из любой папки в вашей системе, поэтому вам не нужно беспокоиться о том, где его разместить.
Вместе с тем, иногда нам нужно знать, где хранится программа. Например, вы хотите войти в свой каталог Steam для резервного копирования некоторых файлов. Вы найдете его в C:\Program Files (x86), так как Steam – это 32-разрядная программа.
Change default Program Files installation directory location in Windows 10
In Windows 10/8/7 OS, by default, software gets installed on your System Drive, usually C drive, in the Program Files folder. The typical path is normally in Windows 32-bit is C:\Program Files and in Windows 64-bit is C:\Program Files and C:\Program Files(x86).
Microsoft recommends the C:\Program Files folder for the default installation destination. It’s a convention that ensures proper inter-operation between your program and the OS’s application and security models. So, once software programs are installed they go by default to C:\Program files on the computer.
This can, however, be changed by selecting another folder or location or partition. To change the default installation folder, the data must be modified in the ProgramFilesDir key and a new path must be chosen for the installation folder.
Windows uses the System Disk for installing any new applications, That is, if your Windows is installed on the C Drive, the default folder where all the applications you install would automatically show up as C:\Program Files, unless of course, you change in manually while installing the application’s locations.
Do note that Microsoft does not support changing the location of the Program Files folder by modifying the ProgramFilesDir registry value. It states that if you change the location of the Program Files folder, you may experience problems with some Microsoft programs or with some software updates.
Change default Program Files directory
If you almost always prefer to NOT install on the System Disk, but instead on another partition, say, the D drive, then rather than changing the default location every time, you can edit the registry as follows:
Now open Regedit and navigate to the following key:
Now in the right pane look for the value ProgramFilesDir and/or ProgramFilesDir (x86) depending on whether your Windows is 32-bit or 64-bit.
Double-click on it and in the box which opens up change its Value data from C:\Program Files to say, D:\Program Files.
The default directory for the installation of all your programs shall now be D:\Program Files.
If you are using Windows 64-bit, you have to change the value of ProgramFilesDir and ProgramFilesDir (x86).
Зачем 64-битной Windows нужна отдельная папка «Program Files (x86)»?
Я знаю, что в 64-разрядной версии Windows папка «Program Files» предназначена для 64-разрядных программ, а папка «Program Files (x86)» — для 32-разрядных программ, но зачем это вообще нужно?
Под «необходимым» я не имею в виду «почему Microsoft не смогла принять никаких других дизайнерских решений?«потому что, конечно, они могли бы иметь. Скорее я имею в виду, «почему, учитывая текущий дизайн 64-битной Windows, 32-битные программы должны иметь отдельную папку верхнего уровня из 64-битных программ?»Другими словами», что могло бы пойти не так, если бы я как-то избежал механизма перенаправления и заставил все установить на настоящий C:\Program Files\ ?»
Есть много вопросов о Super User и других местах, которые утверждают, что «один для 32-битных программ, другой для 64-битных программ», но ни один, который я могу найти, не дает оснований. Исходя из моего опыта, это , кажется, не имеет значения, установлена ли 32-разрядная программа в правильном месте или нет.
Windows как-то отличается от программы, в которой заканчивается «Program Files (x86)»? Есть ли описание, которое показывает, что именно отличается от программы, установленной в «Program Files (x86)» вместо «Program Files»? Я думаю, что вряд ли Microsoft представит новую папку без уважительной технической причины.
11 ответов 11
Краткий ответ: чтобы гарантировать, что унаследованные 32-разрядные приложения продолжают работать так же, как раньше, без навязывания некрасивых правил для 64-разрядных приложений, которые создают постоянный беспорядок.
Это не обязательно. Это просто удобнее, чем другие возможные решения, такие как требование, чтобы каждое приложение создавало свой собственный способ отделения 32-разрядных библиотек DLL и исполняемых файлов от 64-разрядных библиотек DLL и исполняемых файлов.
Основная причина заключается в том, что 32-разрядные приложения, которые даже не знают о существовании 64-разрядных систем, «просто работают», даже если 64-разрядные библиотеки DLL установлены в местах, где приложения могут выглядеть. 32-битное приложение не сможет загрузить 64-битную DLL, поэтому был необходим метод, чтобы гарантировать, что 32-битное приложение (которое может предшествовать 64-битным системам и, следовательно, не имеет представления о 64-битных файлах) даже не существует) не найдет 64-битную DLL, попробуйте загрузить ее, не удалось, а затем сгенерировать сообщение об ошибке.
Самое простое решение для этого — последовательно отдельные каталоги. На самом деле единственная альтернатива — требовать от каждого 64-разрядного приложения «прятать» свои исполняемые файлы там, где 32-разрядное приложение не будет выглядеть, например, в каталоге bin64 внутри этого приложения. Но это наложило бы постоянное уродство на 64-битные системы только для поддержки устаревших приложений.
Это позволяет вам устанавливать как 32-битную, так и 64-битную версию приложения без перезаписи.
Посмотрев на этот ответ и ветку комментариев на следующий день, я осознал возможный серьезный недосмотр в своем ответе. Я ложно взял на себя опыт программирования, и когда я говорил о вас в своих комментариях, я имел в виду не пользователя, а программиста.
Я не работаю на Microsoft, и я понятия не имею, какова реальная причина этих папок, но я думаю, что причина наличия этих папок настолько очевидна, что у меня нет проблем с этим спорить.
Итак, давайте разберемся!
Давайте договоримся о чем-то. Папки отличные! Они нам не нужны, у нас достаточно возможных имен файлов, чтобы поместить каждый отдельный файл в корень жесткого диска, так зачем вообще иметь папки?
Ну, они помогают нам заказать наши вещи. И заказывать вещи отлично. Это помогает нам легче обрабатывать вещи. Это особенно полезно при работе с машиной, которая требует структуры.
Разделение данных и логики — это здорово!
Парадигма, часто встречающаяся в программировании, заключается в отделении данных от логики. Вы хотите , чтобы одна часть , которая знает , как сделать что — то и вы хотите другую часть , которую вы можете сделать что — то с.
Это также находится в файловой системе.
У нас есть папки для приложения (логика) и папки для наших ценностей (данных):
логика
- %WINDIR%
- %PROGRAMFILES%
- %PROGRAMFILES(x86)%
Данные
- %PROGRAMDATA%
- %HOMEDRIVE%%HOMEPATH%
Таким образом, кажется, что папки потрясающие, и имеет смысл помещать программы в их собственную маленькую папку. Но почему 2? Почему бы не позволить установщику справиться с этим и поместить все в одну папку « Programs »?
Установщики не волшебны
Сегодня мы часто используем небольшие программы для установки наших больших программ. Мы называем эти маленькие программы- установщики.
Установщики не волшебство. Они должны быть написаны программистами и являются приложениями (с возможными ошибками), как и любое другое приложение. Итак, давайте посмотрим на ситуацию, с которой воображаемому программисту пришлось бы столкнуться при текущей системе и без нее:
1 папка программных файлов
Разработчик поддерживает 2 установщика. Один для 32-битной и один для 64-битной версии его приложения. 32-битный установщик запишет в C:\Program Files\App\ а 64-битный установщик запишет в C:\Program Files\App\sixtyfour\ .
2 папки с программными файлами
Разработчик поддерживает 1 установщик. Установщик всегда будет записывать в %PROGRAMFILES% и зависит от операционной системы, чтобы соответствующим образом расширить путь (вы фактически не используете переменные среды для этих случаев, вы использовали бы SHGetKnownFolderPath с FOLDERID_ProgramFiles для получения правильного пути).
Все находит свое место автоматически, и шаблон идентичен для каждого приложения, которое вы устанавливаете .
Последовательность имеет смысл
Когда вы чему-то учитесь , это обычно означает, что наблюдаемое поведение было последовательным. Иначе действительно нечего наблюдать и учиться.
То же самое верно для нашей маленькой файловой системы. Имеет смысл всегда помещать один и тот же материал в одни и те же папки. Таким образом, мы будем знать, где искать, когда мы что-то ищем.
Система различения приложений 32/64 способствует достижению этой цели. Приложения разделены на 2 местоположения, чтобы избежать конфликтов в именах, поведении двоичной загрузки и безопасности (в некоторой степени).
Я до сих пор не понимаю. Это кажется бесполезным
Вы никогда не должны забывать одну вещь. Люди невероятно глупы. Это включает в себя пользователей, супер пользователей и особенно программистов.
Вот почему нам нужны такие вещи, как перенаправление файловой системы, чтобы сделать наши системы работоспособными.
Программисты просто зайдут туда и попытаются загрузить C:\Windows\system32\awesome.dll и не заботятся о том, работают ли они в 32- или 64-битной системе. Они будут пытаться загрузить 64-битную DLL и просто потерпеть крах. Некоторые программисты хотят использовать некоторую Office DLL, нет проблем, они знают, где ее найти! C:\Program Files\Microsoft\Office\14.0\wizards.dll . и еще один сбой!
Все эти запросы 32-битным приложением перенаправляются в 32-битные аналоги, чтобы избежать сбоев приложения.
Нам нужны фиксированные имена папок для построения такой системы. Если нет структуры папок, поддерживающей это перенаправление, то как вы собираетесь заставить ее работать?
Хорошо, теперь я понял. Но почему бы тогда не использовать C:\Program Files\x86\ ?
Теперь мы становимся философскими .
Что бы пошло не так, если бы я как-то избежал механизма перенаправления и заставил все установить на настоящий C:\Program Files\ ?
Скорее всего, ничего (если другие приложения не зависят от фиксированного местоположения этого приложения).
Механизм WOW64 подключается к CreateProcess и будет выполнять более сложные (более сложные, чем проверка имени папки исполняемого файла) проверки исполняемого образа, чтобы определить, является ли он 32- или 64-разрядным.
Да, но я имею ввиду ВСЕ приложения!
- Что произойдет , если я ставлю как дизельное топливо и газ в мою машину?
- Что произойдет, если я попытаюсь использовать как переменный, так и постоянный ток на одной линии?
- Что произойдет , если я продолжу и мою кошку и мою рыбу в том же аквариуме?
Некоторые вопросы не требуют ответов. Это не должно быть сделано, не делайте этого. Здесь нечего получить. Количество проблем, которое может вызвать такое изменение, всегда перевешивает любые возможные выгоды, которые кто-либо может увидеть в этом.
Подводя итог, нет, это не обязательно ; они могли бы использовать одну папку, и нет, Windows не выглядит иначе, чем программа, запускаемая из того или иного места.
Ну, все, кажется, высказывают свое мнение по этому поводу, поэтому я брошу свои 2 ¢. Другие уже предположили причины, по которым Microsoft решила создать отдельные папки верхнего уровня для 32-разрядных и 64-разрядных версий программ, поэтому я оставлю эту часть (лучшей причиной было объяснение Дэвида, что это как удобство для программистов). Конечно, даже тогда, это не совсем решает прямой вопрос, почему это вообще необходимо?, на который, по-видимому, ответ: это не так.
Вместо этого я рассмотрю основную часть вопроса
Windows как-то отличается от программы, в которой заканчивается «Program Files (x86)»?
Не совсем, но расположение программы может повлиять на поведение, но не так, как вы думаете.
Когда вы запускаете программу, Windows устанавливает среду, в которой она запускается (я имею в виду память, адресацию и т.д., А не только переменные среды). Эта среда зависит от содержимого исполняемого файла (32-битные и 64-битные программы внутренне различаются). Когда вы запускаете 32-битную программу в 64-битной системе, она запускается в 32-битной подсистеме, которая эмулирует 32-битную среду. Он называется WoW64 (WoW64 означает Windows на 64-битной Windows) и похож на то, как 16-битные приложения будут запускаться в XP с использованием NTVDM.
Когда вы запускаете программу с правами администратора или без них, это влияет на то, как она работает, но местоположение не должно влиять на нее (хотя есть некоторые примеры зависимости от местоположения, например, некоторые драйверы).
(Я использую другой компьютер, поэтому я не могу полагаться на историю своего браузера, чтобы отследить свои шаги, но на днях, отвечая на этот вопрос SU, я оказался на этом вопросе SO, который привел меня к Google PROCESSOR_ARCHITEW6432, который привел к этому вопросу SO и это публикация в блоге Microsoft.)
Где-то по пути я читал пост StackOverflow о том, как переменная окружения %processor_architecutre% дает разные результаты в зависимости от того, откуда вы запускаете командную строку (я постараюсь найти точную цитату).
Ответ оказался обусловлен тем, была ли запущена 32-разрядная или 64-разрядная версия командной строки (т. Е. Из System32\ или SysWoW64\ ). Другими словами, хотя местоположение, кажется, влияет на поведение программы, это происходит только потому, что существуют разные версии программы, а не потому, что Windows обрабатывает папку особым образом.
Это имеет смысл, поскольку содержимое исполняемого файла определяет, является ли оно 32-разрядным или 64-разрядным, поэтому вы можете поместить как 32-разрядную, так и 64-разрядную копию одной и той же программы (например, foobar32.exe и foobar64.exe ) в в ту же папку, и когда вы выполните их, они будут загружены правильно (64-битная версия будет работать изначально, а 32-битная — на уровне эмуляции WoW64).
FreePascal позволяет устанавливать версии как для DOS, так и для Windows, и они находятся в одной папке: %programfiles%\FreePascal . Он управляет различными архитектурами, храня исполняемые файлы ( .exe , .sys , .dll , .ovr и т.д.) В отдельных папках и обмениваясь файлами ресурсов, такими как картинки, исходные файлы и т.д.) Нет технической причины, по которой это нельзя было бы сделать для 32- и 64-разрядных версий программы. Как сказал Дэвид, программисту будет проще, если они будут храниться отдельно (т. Е. Использовать переменные, чтобы они выглядели так, будто существует только один набор файлов и т.д.)