Зачем 64-битной Windows нужна отдельная папка «Program Files (x86)»?

178

Я знаю, что в 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 представит новую папку без уважительной технической причины.

windows 64-bit Стивен Дженнингс
источник
13
Вместо того, чтобы ответить на ваш вопрос, я бы спросил - как бы вы справились с \ программными файлами \ общими файлами?
sgmoore
8
Однострочный ответ (и, следовательно, комментарий): поскольку вы можете легко запускать любое приложение из любой папки, не зная его архитектуры, тогда нет явных причин для такого разделения. Удобно поддерживать двойную установку приложений с обеими архитектурами . В некоторых случаях это имеет значение, поскольку они не обязательно просто перекомпилируются. Основная проблема заключается в том, что 32-разрядные приложения не могут загружать 64-разрядные библиотеки DLL, поэтому обычно вы не можете установить обе версии в одном месте. Другой альтернативой является наличие двух папок «bin» для каждого приложения.
Sklivvz
1
@Synetech У меня даже были программы, устанавливаемые в (x86) только для того, чтобы иметь двоичные файлы x64 .. Иногда это ужасно.
sinni800
10
Я всегда удивлялся, почему Microsoft не помещала 64-разрядные программы в «Program Files (x64)» вместо «перемещения» «устаревшего» каталога Program Files в Program Files (x86)
LawrenceC
30
Реальный беспорядок в 64/32-битной дифференциации состоит в том, что / Windows / System32 содержит 64-битный контент, в то время как / Windows / SysWOW64 содержит 32-битный материал…
ткните

Ответы:

92

Краткий ответ: для обеспечения того, чтобы унаследованные 32-разрядные приложения продолжали работать так же, как раньше, без навязывания некрасивых правил для 64-разрядных приложений, которые создавали бы постоянный беспорядок.

Это не обязательно. Это просто удобнее, чем другие возможные решения, такие как требование, чтобы каждое приложение создавало свой собственный способ отделения 32-разрядных библиотек DLL и исполняемых файлов от 64-разрядных библиотек DLL и исполняемых файлов.

Основная причина заключается в том, что 32-разрядные приложения, которые даже не знают о существовании 64-разрядных систем, «просто работают», даже если 64-разрядные библиотеки DLL установлены в местах, где приложения могут выглядеть. 32-битное приложение не сможет загружать 64-битную DLL, поэтому был необходим метод, чтобы гарантировать, что 32-битное приложение (которое может предшествовать 64-битным системам и, следовательно, не имеет представления о 64-битных файлах) даже не существует) не найдет 64-битную DLL, попробуйте загрузить ее, не удалось, а затем сгенерировать сообщение об ошибке.

Самое простое решение для этого - последовательно отдельные каталоги. На самом деле единственная альтернатива - требовать от каждого 64-разрядного приложения «прятать» свои исполняемые файлы там, где 32-разрядное приложение не будет выглядеть, например, в bin64каталоге внутри этого приложения. Но это наложило бы постоянное уродство на 64-битные системы только для поддержки устаревших приложений.

Дэвид Шварц
источник
52
Им не нужно было прыгать через эти обручи, чтобы учесть 32-битные и 16-битные программы в одной системе. Я не помню, чтобы когда-либо видел ProgramFiles (16)или некоторые такие. Кроме того, как именно 32-битная программа «найдет 64-битную DLL и попытается ее загрузить»? В каких программах охотятся за случайными DLL %programfiles%? Если это общая DLL, то она идет в WinSxS; если он не является общим, то программист может самостоятельно управлять своими DLL. Часть о том, что это делается для удобства программистов, разумна.
Synetech
30
IIRC Win3.1 не имел каталога программных файлов (или большинство приложений игнорировали его); в результате не было бы никаких старых приложений win16, ищущих вещи в программных файлах для начала. Вместо этого общие библиотеки IIRC часто добавлялись где-то в самой папке Windows. Win32, имеющий windows \ system и windows \ system32, является артефактом этого.
Дэн Нили
15
Windows 3.1 не поддерживала длинные имена файлов, поэтому у нее не было бы папки с «программными файлами».
Дарт Эгредиус
14
@JarrodRoberson: Наоборот, это потому, что Microsoft очень высоко ценит обратную совместимость.
Дэвид Шварц
24
@Jarrod: На самом деле, как знает каждый разработчик, Microsoft слишком высоко ценит обратную совместимость . Буквально у каждого API есть свои методы, которые они отказываются удалять, и часто серьезные ошибки, которые они отказываются исправлять, потому что они боятся ломать старые программы, написанные для этого API. То же самое относится и к большинству API, но не ближе к существующим Microsoft.
BlueRaja - Дэнни Пфлюгофт
65

Это позволяет вам устанавливать как 32-битную, так и 64-битную версию приложения без перезаписи.

Посмотрев этот ответ и цепочку комментариев на следующий день, я осознал возможный серьезный недосмотр в своем ответе. Я ложно предположил опыт программирования, и когда я говорил о вас в своих комментариях, я имел в виду не пользователя, а программиста.

Я не работаю на Microsoft, и я понятия не имею, какова реальная причина этих папок, но я думаю, что причина наличия этих папок настолько очевидна, что у меня нет проблем с этим спорить.

Итак, давайте разберемся!

  1. Папки потрясающие!

    Давайте договоримся о чем-то. Папки отличные! Они нам не нужны, у нас достаточно возможных имен файлов, чтобы поместить каждый отдельный файл в корень жесткого диска, так зачем вообще иметь папки?

    Ну, они помогают нам заказать наши вещи. И заказывать вещи отлично. Это помогает нам легче обрабатывать вещи. Это особенно полезно при работе с машиной, которая требует структуры.

  2. Разделение данных и логики это здорово!

    Парадигма, часто встречающаяся в программировании, заключается в отделении данных от логики. Вы хотите , чтобы одна часть , которая знает , как сделать что - то и вы хотите другую часть , которую вы можете сделать что - то с .

    Это также находится в файловой системе.

    У нас есть папки для приложения (логика) и папки для наших ценностей (данных):

    логика

    • %WINDIR%
    • %PROGRAMFILES%
    • %PROGRAMFILES(x86)%

    Данные

    • %PROGRAMDATA%
    • %HOMEDRIVE%%HOMEPATH%

    Таким образом, кажется, что папки - это круто, и имеет смысл помещать программы в свою маленькую папку. Но почему 2? Почему бы не позволить установщику справиться с этим и поместить все в одну Programsпапку?

  3. Установщики не волшебны

    Сегодня мы часто используем небольшие программы для установки наших больших программ. Мы называем эти маленькие программы- установщики .

    Установщики не волшебство. Они должны быть написаны программистами и являются приложениями (с возможными ошибками), как и любое другое приложение. Итак, давайте посмотрим на ситуацию, с которой воображаемому программисту придется столкнуться при наличии и отсутствии текущей системы:

    1 папка Program Files

    Разработчик поддерживает 2 установщика. Один для 32-битной и один для 64-битной версии его приложения. 32-битный установщик запишет, C:\Program Files\App\а 64-битный установщик запишет C:\Program Files\App\sixtyfour\.

    2 папки с программными файлами

    Разработчик поддерживает 1 установщик. Программа установки всегда будет писать %PROGRAMFILES%и зависит от операционной системы , чтобы расширить путь соответствующим образом (вы на самом деле не использовать переменные среды для этих случаев вы будете использовать SHGetKnownFolderPath с , FOLDERID_ProgramFilesчтобы получить правильный путь).
    Все находит свое место автоматически, и шаблон идентичен для каждого приложения, которое вы устанавливаете .

  4. Последовательность имеет смысл

    Когда вы чему-то учитесь , это обычно означает, что наблюдаемое поведение было последовательным. Иначе действительно нечего наблюдать и учиться.

    То же самое верно для нашей маленькой файловой системы. Имеет смысл всегда помещать один и тот же материал в одни и те же папки. Таким образом, мы будем знать, где искать, когда мы что-то ищем.

    Система различения приложений 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-разрядным.

Да, но я имею в виду, как, ВСЕ приложения!

  • Что произойдет , если я ставлю как дизельное топливо и газ в мою машину?
  • Что произойдет, если я попытаюсь использовать как переменный, так и постоянный ток на одной линии?
  • Что произойдет , если я держу как мой кот и мою рыбу в том же аквариуме?

Некоторые вопросы не требуют ответов. Это не должно быть сделано, не делайте этого. Здесь нечего получить. Количество проблем, которое может вызвать такое изменение, всегда перевешивает любые возможные выгоды, которые кто-либо может увидеть в этом.

Der Hochstapler
источник
3
Это первоначальная причина, хотя? Не могу ли я просто установить приложение на C:\Program Files\App32и C:\Program Files\App64?
Стивен Дженнингс
4
@StephenJennings: Но это потребует от вас ручного принятия решения. Теперь он работает так, что этот процесс происходит автоматически, поскольку Windows знает, какую папку предоставить при вызове приложения SHGetSpecialFolderPathдля определения места установки.
Der Hochstapler
6
@Synetech: Зачем устанавливать в %PROGRAMFILES%первую очередь? Почему бы не поместить 32-разрядную версию на рабочий стол пользователя, а 64-разрядную - в корзину? То, что это можно сделать, не означает, что это хорошая идея. Извините, я не понимаю ваших рассуждений.
Der Hochstapler
4
@Synetech: Да, вы дали очень хороший пример того, как это можно сделать. Другой вполне хороший пример того , как это можно было бы сделать так , как это будет на самом деле делается прямо сейчас. Просто записать файл в% PROGRAMFILES% и быть уверенным, что он окажется в нужной папке - это одно. Проверяя для себя, какая папка правильная, другая. Если вы на самом деле не видите преимущества прежнего подхода, я не смогу вас убедить. Вопрос был в том, почему есть 2 папки. Я думаю, что мой ответ вполне разумен в этом отношении.
Der Hochstapler
3
@OliverSalzburg, нет совсем. Вопрос заключается в том, почему две папки требуется , а не почему это . На самом деле он даже обдумал это: зачем это вообще нужно? Вы не объяснили, почему это необходимо, и приведенный мною пример (и даже ваш собственный саркастический пример) просто показывают, что это не обязательно должно быть так, как есть.
Synetech
14

TL; DR:

Подводя итог, нет, это не обязательно ; они могли бы использовать одну папку, и нет, 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 о том, как переменная envirnoment %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-битные версии программы. Как сказал Дэвид, программисту будет проще, если они будут храниться отдельно (т. Е. Использовать переменные, чтобы они выглядели так, будто существует только один набор файлов и т. Д.)

Synetech
источник
Месть понижающего голосования! Muahahaha! вздох
Synetech
Голосование странное: \. Кстати хорошо объяснить +1.
avirk
11

Другая причина в том, что большинство программ использовали переменные среды, такие как% PROGRAMFILES%, чтобы указать, где была установлена ​​их программа. Для 64-битных программ он идет в обычное место. Для 32-битных программ он перенаправит их в новую Program Files (x86)папку.

Хотя, по крайней мере, с новыми вещами .Net в Visual Studio, у них теперь есть переменная App.Local, которая устраняет всю потребность в этом.

Канадский Люк
источник
4
Это не объясняет это. Кто именно использует переменную окружения и почему это должно волновать, является ли программа 32-битной или 64-битной?
Synetech
4
@Synetech - автор программ использует переменную окружения. Что касается причины, это будет заботиться из-за ссылок на DLL. Вы не можете загрузить 32-битную DLL в 64-битном процессе и наоборот.
Ramhound
1
И как сделать %programfiles%, %programfiles(x86)%или %programw6432%сделать разницу там? Любые разделяемые библиотеки DLL помещаются в один каталог WinSxS, а любые неиспользуемые библиотеки DLL находятся рядом с исполняемым файлом. Это имеет значение только в том случае, если по какой-то причине у вас установлены как 32-разрядные, так и 64-разрядные версии одной и той же программы, и даже тогда вы сохраните 32-разрядные библиотеки DLL с 32-разрядным исполняемым файлом и 64-разрядные библиотеки DLL с 64-битный исполняемый файл. Вы можете сделать это так: %programfiles%\CoolApp\bin\32а% programfiles% \ CoolApp \ bin \ 64`, почему отдельные папки верхнего уровня?
Synetech
@Synetech Конечно, это так; % programfiles% уже давно. Если вы устанавливаете 32-разрядную программу на 64-разрядном компьютере, наличие одного места может вызвать проблемы для этого 32-разрядного приложения. Хотя WoW может перенаправить% programfile% на версию (x86) для 32-битных приложений и версию не на x86 для 64.
Энди
я думаю, что люди не были бы так смущены, если бы не было неявного перенаправления
kommradHomer
8

Решение Microsoft для этого перехода с 32-разрядного на 64-разрядное решение заключается в добавлении устаревшей поддержки для большинства 32-разрядных приложений. Другими словами, большинство 32-битных приложений будут работать в 64-битной операционной среде. Помните, что другие операционные системы, работающие на 64-битной архитектуре, вообще не могут загружать или запускать 32-битные приложения.

Чтобы упростить переход, Microsoft назначила, что все 32-разрядные приложения должны по умолчанию загружаться в папку Program Files (x86), а не смешиваться с настоящими 64-разрядными приложениями в обычной папке Program Files.

Источник

"что бы пошло не так, если бы я как-то избежал механизма перенаправления и заставил все установить на настоящий C: \ Program Files \?"

Ничего. Два каталога программ предназначены только для организации или для разделения программ с двумя версиями, 32-разрядной и 64-разрядной, например, Internet Explorer. Но вы можете установить 32-разрядную программу в «Program Files» и 64-разрядную программу в «Program Files x86», и ничего не произойдет, программа будет работать одинаково.

Вики говорит:

Некоторые установщики приложений отклоняют пробелы в месте установки. Для 32-разрядных систем короткое имя для папки Program Files - Progra ~ 1 . Для 64-битных систем короткое имя для папки 64-битных программных файлов - Progra ~ 1 (то же самое, что и в 32-битных системах); в то время как короткое имя для папки 32-разрядных программных файлов (x86) теперь Progra ~ 2 .

avirk
источник
1
Хехе. Хорошая статья. Комментарии к этой статье звучат так же, как здесь. Хуже того, эта статья была написана более двух лет назад и показывает, что этот вопрос не нов, и если на него все еще нельзя ответить авторитетно, то, я думаю, этого не произойдет (если кто-то из команды Windows не вмешается). О, хорошо, я полагаю, мы все должны просто перестать беспокоиться и научиться любить бомбу, я хочу жить с ней. +1 За то, что указал на статью и показал, что этот вопрос был так давно.
Synetech
1
@Synetech спасибо! Да, идея размещения ссылки на статью такая же, как и у вас. Это очень старый вопрос времени, но IDK почему люди еще не могут его получить. Однако MS должен написать KB или Документацию для этой проблемы :)
avirk
Да, они должны, особенно потому, что это задают не только разработчики, но и обычные пользователи. К сожалению, документация Microsoft не часто слишком хороша.
Synetech
@ Synetech да! MS документация отстой большую часть времени. Но да, они тоже написали несколько хороших статей, и я уверен, что они
исчисляются
6

Причина в том, чтобы сделать обновление программы до 64-битной проще для разработчиков. Им не нужно писать какой-либо специальный код для проверки программы в одном каталоге при компиляции в 32-битном режиме и в другом каталоге при компиляции в 64-битном режиме; они просто проверяют C:\Program Files, и при работе в 32-битном режиме это автоматически заменяется C:\Program Files (x86)64-битной Windows. Аналогично, записи реестра изолированы между 32-битными и 64-битными программами.

Это предотвращает конфликты от незнания разработчиков, которые просто меняют режим компиляции на 64-битный, не вдаваясь в подробности, и предотвращает огромный объем работы для разработчиков, которые хотят, чтобы пользователи могли устанавливать как 32-, так и 64-битные версии своих Программное обеспечение одновременно.

Но почему любая программа хочет, чтобы обе версии были установлены одновременно? Один пример: Photoshop и IE имеют собственные расширения .dll. Нельзя смешивать 32- и 64-разрядный код в одном и том же процессе, поэтому дополнение к 32-разрядной версии нельзя использовать с 64-разрядной версией, и наоборот. Таким образом, Photoshop / IE должен разрешить установку обеих версий или рискнуть сломать их огромную базу существующих дополнений.

BlueRaja - Дэнни Пфлугхофт
источник
2
+1 По крайней мере, вы обратились к основному вопросу о том, почему обычные пользователи будут иметь обе версии.
Synetech
5

Программы, работающие в «Program Files (x86)», используют подсистему WOW64 (32-битная Windows в 64-битной Windows - это набор драйверов и API, предназначенных для запуска приложений x32 в системе архитектуры x64):

Подсистема WoW64 содержит облегченный уровень совместимости, который имеет схожие интерфейсы во всех 64-разрядных версиях Windows. Он направлен на создание 32-разрядной среды, которая обеспечивает интерфейсы, необходимые для запуска неизмененных 32-разрядных приложений Windows в 64-разрядной системе. Технически WoW64 реализован с использованием трех динамически подключаемых библиотек (DLL):

  • Wow64.dll, основной интерфейс к ядру Windows NT, который транслирует между 32-битными и 64-битными вызовами, включая манипуляции указателя и стека вызовов
  • Wow64win.dll, который обеспечивает соответствующие точки входа для 32-битных приложений
  • Wow64cpu.dll, который заботится о переключении процессора из 32-битного в 64-битный режим

64-битная система должна «эмулировать» 32-битные приложения, поэтому Windows должна «разделять» две папки Program Files.

Диого
источник
7
Но почему он должен положить его в разные папки? Windows уже полностью способна определить архитектуру исполняемого файла, посмотрев на PE-заголовок. Почему он не может загрузить соответствующую среду, когда он загружает исполняемый файл?
Synetech
1
Я думаю, что это просто выбор от Microsoft, чтобы легко показать пользователям, какую архитектуру они хотят от двух версий программы при открытии программы. Я имею в виду, что если бы не было этих двух папок и если бы они были прозрачными для пользователей (если они переключались автоматически), они не знали бы, работает ли 32- или 64-битное приложение, даже они не знали бы, какую программу открывать. если работает на 64 битах ..
Диого
1
64-битная версия IE имеет репутацию ужасной.
Сэмюэль Эдвин Уорд
1
MS рекомендует использовать office32, если вы не работаете с наборами данных, достаточно большими, чтобы превышать ограничения памяти. Я считаю, что необходимо перекомпилировать бинарные дополнения для работы с office64; в сочетании с отказом от каких-либо преимуществ в нормальных случаях использования стоит за решением.
Дэн Нили
1
Я думаю, вы обнаружите, что 64-битная программа, явно установленная в папку Program Files (x86), будет работать нормально (и, в большинстве случаев, наоборот). Windows не использует местоположение папки, чтобы определить, как обращаться с исполняемым файлом.
Гарри Джонстон
5

Интересно, что ответы здесь и в интернете довольно сильно различаются. Найти точный ответ на этот важный вопрос было непросто. Похоже, что в Интернете представлено немало ложной информации, что приводит к путанице.

Я провел значительное количество исследований и сделал следующий вывод, который я считаю точным:

  • Не имеет значения, где хранится приложение. Во время выполнения Windows определит, является ли приложение 32-разрядным или 64-разрядным, и автоматически использует соответствующие разделы DLL и реестра.

Это происходит автоматически и не зависит от того, где хранится приложение. Отсутствие скорости, надежности или других функциональных преимуществ для отдельных 32-битных и 64-битных папок.

Единственная причина разделения по умолчанию на две папки («Program Files» и «Program Files (x86)») заключается в том, что если у вас есть две версии одной и той же программы (32-битная и 64-битная версия), она обеспечивает простой способ разделять перекрывающиеся файлы. Даже в этом случае, если все имена файлов уникальны, они могут фактически существовать в одной папке без каких-либо последствий.

Существует оговорка к приведенному выше выводу, а именно к плохо закодированным приложениям. Если в приложении есть какие-либо жестко запрограммированные пути, оно будет использовать только этот путь. Как правило, пути никогда не должны быть жестко закодированы в приложении, но иногда программист допускает эту ошибку. В этом случае программа будет использовать жестко заданный путь; каталог, в котором установлено приложение, не влияет на то, где оно фактически ищет файлы.

RockPaperLizard
источник
3

Необходимость разделять папки позволяет сохранить родные 64-битные приложения и те, которые требуют WoW64, отдельно.

Это может быть полезно - как уже указывал @OliverSalzburg - если вы хотите установить как 64-битный, так и 32-битный веб-браузер (например), так как некоторые плагины и дополнения могут быть доступны только для одного из два.

Необходимость разделять папки делает это разделение автоматическим , используя такие методы, как перенаправление реестра .

Предположим, установщик пытается определить папку с программными файлами, читая реестр с помощью, например, RegQueryValueEx .

В любом случае он пытается прочитать раздел реестра

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion

который обычно указывает на C:\Program Files.

Однако, если установщик является 32-разрядным приложением, перенаправление реестра вызовет ключ regitry.

HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion

читать вместо этого, что обычно указывает на C:\Program Files (x86).

Почему эти конкретные имена папок были использованы можно ответить только те люди , которые сделали этот выбор. Вы всегда можете изменить имена папок по умолчанию, если хотите.

Windows как-то отличается от программы, в которой не хватает «Program Files (x86)»?

Я сомневаюсь. Большинство инсталляторов позволяют вам выбрать пользовательскую папку для установки, поэтому не имеет значения, где установлена ​​программа.

Деннис
источник
Извините, я смешал «разрешить» с «запретить»
Вернфрид Домшайт
3

Я не могу поверить в замешательство здесь ... во-первых, я полный рабочий день разработчика.

MS сделала это, чтобы решить случай, когда DLL используется как более старыми 32-битными приложениями, так и более новыми 64-битными приложениями. Более старый метод не может быть изменен (System32, Program Files и т. Д.), Потому что это сломает старые программы, которые не могут быть перекомпилированы.

Поэтому MS создала папку для хранения 64-битных специальных программ, сборок и библиотек, чтобы новые программы могли ссылаться на нужные библиотеки, а старые программы продолжали работать в обычном режиме.

На самом деле DLL-библиотеки .Net могут сосуществовать с другими версиями на той же машине. Например, у вас может быть Library.1.0.1, Library.1.0.2, Library 1.1.0 и т. Д. И это только для определенного размера бита (32 или 64). Если отдельные папки не используются, то каждая сборка должна иметь 32- и 64-разрядную версию. Это может сильно загромождать каталог, который уже содержит несколько версий одной и той же сборки.

Это всё для разработчиков. Мне, как пользователю, приходится иметь дело с ним только тогда, когда я работаю с 32-разрядной программой в Windows 7 64. И я предпочитаю иметь возможность запускать 32-разрядную версию и такое же приложение в 64-разрядной версии. Когда я работаю над 32-разрядным приложением, которое мне нужно скомпилировать в 64-разрядном, все, что я делаю, - это говорю компилятору сделать это. Имена Dll и все остальное остается прежним.

Причина, по которой этого не было в Windows 95/98, заключается в том, что эти системы имитировали 32-разрядную среду выполнения; это была не настоящая 32-битная операционная система. Это симулировало 32-битное исполнение с чем-то под названием "thunking".

Вот хорошее определение: http://searchwinit.techtarget.com/definition/thunk

Джейсон Лок
источник
1
Как работает 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` или \blah\32; в любом случае, они разделены. Во всяком случае, текущий способ разделяет компоненты приложения (а также дублирует их без необходимости, поскольку лишь немногие приложения используют CommonFilesдля ресурсов и т. Д. Кроме того, вы делаете так, будто приложения сбрасывают свои библиотеки DLL в общую корзину. Достаточно легко сохранить приложение 32-разрядные библиотеки DLL с 32-разрядными библиотеками и 64-разрядные библиотеки DLL с 64-разрядными библиотеками
Synetech
Ох, а что касается 95/98, кто что-нибудь говорил по этому поводу? Даже у XP была 16-битная подсистема (NTVDM).
Synetech
Я думал, ты хотел объяснения. Немногие приложения используют CommonFiles? У меня есть 35 различных приложений, которые имеют записи там. Это более безопасное место для хранения общих компонентов, чем каталог System32. Ваше утверждение о том, что некоторые приложения используют это, является спорным. Цитирую вас: «Им не нужно было прыгать через эти обручи, чтобы учесть 32-битные и 16-битные программы в одной системе. Я не помню, чтобы когда-либо видел ProgramFiles (16) или некоторые подобные [...] Часть о том, что это делается для удобства программистов, разумна. " Ну, да .. программисты делают. Мы пишем заявки в конце концов.
Джейсон Локк
А?
Synetech
Просто перечитайте это .. он сказал это лучше в своих ответах - superuser.com/a/442253/142951 . Если вы не разработчик, вы можете не увидеть цель.
Джейсон Локк
0

Это совсем не обязательно. Например, на моем рабочем компьютере я устанавливаю каждое приложение в папку C:\MyPrograms\, чтобы отделить их от приложений, установленных нашим ИТ-отделом.

Конечно, это мешает мне установить обе версии (32- и 64-битную) одного приложения, но в моем случае это не проблема.

Когда вы запускаете программу, всегда C:\Windows\System32\ntdll.dllвыполняется первая DLL . Эта DLL определяет, является ли ваша программа 32- или 64-битным приложением. В зависимости от того, что вы перенаправлены на WoW64который уже упоминается в нескольких ответах.

Вернфрид Домшайт
источник