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


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

Под «необходимым» я не имею в виду «почему Microsoft не могла принимать какие-либо другие проектные решения?» потому что, конечно, они могли бы. Скорее, я имею в виду, «почему, учитывая текущий дизайн 64-разрядной Windows, должны ли 32-разрядные программы иметь отдельную папку верхнего уровня из 64-битных программ?» Иными словами, «что пойдет не так, если я каким-то образом избегаю механизма перенаправления и заставил все установить на реальную C:\Program Files\

Есть много вопросов о Суперпользователе и в других местах, которые утверждают: «один для 32-битных программ, один для 64-битных программ», но ни один из них не может найти причину. По моему опыту, это не казаться чтобы определить, установлена ​​ли 32-разрядная программа в нужном месте или нет.

Разве Windows каким-то образом отличается от программы «Program Files (x86)»? Есть ли описание, которое точно показывает, что отличается от программы, установленной в «Program Files (x86)» вместо «Program Files»? Я думаю, маловероятно, что Microsoft представит новую папку без законной технической причины.


175
2018-06-27 17:19


происхождения


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


ответы:


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

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

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

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


89
2018-06-27 18:18



Им не пришлось перепрыгивать через эти обручи, чтобы 32-разрядные и 16-разрядные программы были в одной и той же системе. Я не помню, чтобы когда-либо видел ProgramFiles (16) или некоторые такие. Кроме того, как именно 32-разрядная программа «найдет 64-битную DLL и попытается ее загрузить»? Какие программы идут вокруг поиска случайных DLL в %programfiles%? Если это общая DLL, то она идет в WinSxS; если он не используется совместно, то программист может самостоятельно управлять своими DLL. Тем не менее, часть об этом делается для удобства программистов. - Synetech
У IIRC Win3.1 не было каталога программных файлов (или большинство приложений игнорировали его); в результате не было бы никаких старых приложений win16, которые искали бы файлы в файлах программ для начала. Вместо этого разделяемые библиотеки IIRC часто выкладывались где-то в самой папке Windows. Win32 с окнами \ system и windows \ system32 является артефактом этого. - Dan Neely
Windows 3.1 не поддерживала длинные имена файлов, поэтому у нее не было бы папки «программных файлов». - Darth Egregious
@JarrodRoberson: Напротив, это потому, что Microsoft высоко ценит обратную совместимость. - David Schwartz
@Jarrod: На самом деле, как знает каждый разработчик, Microsoft поддерживает обратную совместимость слишком высоко. Буквально каждый API, который у них есть, имеет унаследованные методы, которые они отказываются удалить, и часто серьезный которые они отказываются исправлять, потому что они боятся нарушать старые программы, которые были написаны для этого API. То же самое относится и к большинству API, но не к каким-либо близким к Microsoft. - BlueRaja - Danny Pflughoeft


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


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

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

Так что давайте сломаем это!

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

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

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

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

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


65
2018-06-27 17:31



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


TL; DR:

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


14
2018-06-27 19:23



Месть вниз-голосовать! Muahahaha! вздох - Synetech
Вниз-голос странный: \. BTW хорошее объяснение +1. - avirk


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

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


11
2018-06-27 17:36



Это не объясняет. Кто именно использует переменную окружения и почему он заботится о том, является ли программа 32-разрядной или 64-разрядной? - Synetech
@Synetech - автор программ использует переменную окружения. Что касается причины, о которой это позаботится, это из-за ссылок на DLL. Вы не можете загрузить 32-разрядную DLL в 64-битный процесс и наоборот. - Ramhound
И как сделать %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-битных приложений и версию non-x86 для 64. - Andy
я думаю, что люди не будут так смущены, если не будет скрытого перенаправления - kommradHomer


Решение 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», и ничего не произойдет, программа будет работать одинаково.

Wiki говорит:

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


8
2018-06-28 16:28



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


Причина заключается в том, чтобы упростить разработку программы до 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 иметь чтобы обе версии были установлены, или рискуя разрушить их огромную базу существующих аддонов.


6
2018-06-27 18:48



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


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


5
2018-06-27 17:32



Но почему он должен помещать его в разные папки? Windows уже полностью способна определять архитектуру исполняемого файла, просматривая заголовок PE. Почему он не может загрузить соответствующую среду при загрузке исполняемого файла? - Synetech
Я думаю, что это просто выбор из Microsoft, чтобы легко показать пользователям, какая архитектура они хотят от двух программных версий при открытии программы. Я имею в виду, если бы не были эти две папки, и если бы они были прозрачными для пользователей (если они автоматически переключаются), они не будут знать, работает ли 32 или 64-битное приложение, даже они не будут знать, какую программу открыть если работает на 64 бит. - Diogo
64-битная версия IE имеет репутацию страшного. - Samuel Edwin Ward
MS рекомендует использовать office32, если вы не работаете с наборами данных, достаточно большими, чтобы превышать ограничения памяти. Я считаю, что нужно перекомпилировать двоичные аддоны для работы с office64; в сочетании с отсутствием каких-либо преимуществ в нормальных случаях использования, находится за решением. - Dan Neely
Я думаю, вы обнаружите, что 64-разрядная программа, явно установленная в папку Program Files (x86), будет работать нормально (и, в большинстве случаев, наоборот). Windows не использует местоположение папки, чтобы определить, как обрабатывать исполняемый файл. - Harry Johnston


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

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

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

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

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

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


5
2017-10-16 19:57