Почему для 64-битной Windows требуется отдельная папка «Файлы программ (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 представит новую папку без законной технической причины.

175 голосов | спросил Stephen Jennings 27 J0000006Europe/Moscow 2012, 21:19:07

11 ответов


89

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

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

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

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

ответил David Schwartz 27 J0000006Europe/Moscow 2012, 22:18:50
65

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


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

Я не работаю для 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 и просто сбой. Некоторые программисты хотят использовать некоторые DLL Office, без проблем, они знают, где их найти! C:\Program Files\Microsoft\Office\14.0\wizards.dll ... и еще один сбой!

Все эти запросы 32-битным приложением перенаправлены в 32-разрядные копии, чтобы избежать сбоев приложений.

Для построения такой системы нам нужны имена фиксированных папок. Если для поддержки этого перенаправления нет структуры папок, то как вы собираетесь заставить ее работать?

Хорошо, теперь я понял. Но почему бы не использовать C:\Program Files\x86\, то?

Теперь мы становимся философскими ...

Что пойдет не так, если я каким-то образом избегаю механизма перенаправления и заставил все установить на реальный C:\Program Files\?

Скорее всего ничего (пока другие приложения не зависят от фиксированного местоположения для этого приложения).

Механизм WOW64 подключается к CreateProcess и будет выполнять более сложные (более сложные, чем проверка имени папки исполняемого файла) проверяет исполняемый образ, чтобы определить, 32 или 64 бит.

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

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

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

ответил Der Hochstapler 27 J0000006Europe/Moscow 2012, 21:31:19
14

TL; ДР:

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


Ну, все, кажется, бросают свое мнение по этому поводу, поэтому я буду бросать свои 2 ¢. Другие уже предположили, что по причинам почему Microsoft решила создать отдельные папки верхнего уровня для 32-разрядных и 64-разрядных версий программ, поэтому я оставлю эту часть (лучшая причина Дэвид объясняет, что это удобство для программистов). Конечно, даже тогда, это не совсем касается прямого вопроса , почему это даже необходимо? , к которому, по-видимому, ответ: это не .

Вместо этого я обращусь к основному вопросу вопроса

  

Как-то иначе Windows проявляет себя по-разному в программе, заканчивающейся «Program Files (x86)»?

Не совсем, но расположение программы может влиять на поведение, но не так, как вы думаете.

При запуске программы Windows создает среду для ее запуска (я имею в виду память, адресацию и т. д., а не только переменные среды). Эта среда зависит от содержимого исполняемого файла (32-разрядная и 64-разрядная программы отличаются друг от друга). Когда вы запускаете 32-разрядную программу в 64-разрядной системе, она запускается в 32-разрядной подсистеме, которая эмулирует 32-битную среду. Он называется WoW64 (WoW64 означает Windows на Windows 64-разрядный ) и аналогичен тому, как 16 -битные приложения будут запускаться в XP с помощью NTVDM .

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

(Я использую другой компьютер, поэтому я не могу полагаться на историю браузера, чтобы отменить мои шаги, но на днях отвечая Вопрос SU. Я оказался в этом вопросе SO , что привело меня к Google PROCESSOR_ARCHITEW6432 , которые привели к этот вопрос SO и это публикация в блоге Microsoft .)

Где-то по пути я прочитал сообщение StackOverflow о том, как переменная envirnoment %processor_architecutre% дает разные результаты в зависимости от того, где вы запускаете командную строку из (I попытаюсь найти точную цитату).

Ответ оказался причиной того, была ли выполнена 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 27 J0000006Europe/Moscow 2012, 23:23:07
11

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

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

ответил Canadian Luke 27 J0000006Europe/Moscow 2012, 21:36:53
8
  

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

     

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

Источник

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

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

Wiki говорит:

  

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

ответил avirk 28 J0000006Europe/Moscow 2012, 20:28:16
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 - Danny Pflughoeft 27 J0000006Europe/Moscow 2012, 22:48:03
5

Программы, которые запускаются в «Program Files (x86)», используют WOW64 подсистему (Windows 32-бит в Windows 64-бит - это набор драйверов и 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.

ответил Diogo 27 J0000006Europe/Moscow 2012, 21:32:31
5

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

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

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

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

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

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

ответил RockPaperLizard 16 +04002014-10-16T23:57:46+04:00312014bEurope/MoscowThu, 16 Oct 2014 23:57:46 +0400 2014, 23:57:46
3

Наличие отдельных папок позволяет сохранить собственные 64-разрядные приложения и thos, для которых требуется 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)»?

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

ответил Dennis 27 J0000006Europe/Moscow 2012, 22:40:19
3

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

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

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

В соответствии с этим, DLL DLL может сосуществовать с другими версиями на одном компьютере. Например, вы можете иметь 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

ответил Jason Locke 28 J0000006Europe/Moscow 2012, 18:43:38
0

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

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

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

ответил Wernfried Domscheit 8 Mayam15 2015, 11:40:03

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132