Почему 64-разрядные библиотеки DLL попадают в System32, а 32-разрядные библиотеки DLL - в SysWoW64 в 64-разрядной Windows?

227

Я хотел бы знать, когда нам нужно поместить файл под

C: \ Windows \ System32 или C: \ Windows \ SysWOW64, в 64-битной системе Windows.

У меня было две библиотеки DLL, одна для 32-битных, одна для 64-битных.

Логично, что я решил поместить 32-битную DLL в C: \ Windows \ System32, а 64-битную DLL в C: \ Windows \ SysWOW64.

К моему удивлению, все наоборот ! 32 -битовый один переходит в C: \ Windows \ SysWOW 64 , и 64 - битный DLL входит в C: \ Windows \ System 32 .

Очень запутанные вещи. В чем причина этого?

dll 32bit-64bit system32 syswow64 Ганеш Астровед
источник
2
Кроме того, это: Windows смотрит в текущем рабочем каталоге, а также в системном PATH. Нет способа указать иное. Ой, подождите, есть. Вы можете встроить путь поиска в вашу DLL. Это поле длиной 8 байтов. Да. 8 символов.
Jeroen Baert
Похоже, что это не так в Windows 7. Запуск файла на DLL в файле system32 C: \ Windows \ system32 \ user32.dll C: \ Windows \ system32 \ user32.dll; Исполняемый файл PE32 для MS Windows (DLL) (GUI) Intel 80386 32-разрядный Но для 64-разрядной DLL он печатает исполняемый файл PE32 + для MS Windows (DLL) (консоль) Сборка Mono / .Net Обратите внимание, что эта DLL не является .Net сборка. Это родная DLL.
user877329
Связывание аналогичного вопроса на суперпользователя .
dma_k
11
Интервью с экс-Microsoftie . (Серьезное объяснение того, как это произошло, см. В этом ответе .)
Tgr
superuser.com/a/157301/241386 «Причины обратной совместимости. Многие приложения предполагают вещи, которые они не должны принимать, и пути жесткого кода»
phuclv

Ответы:

225

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

SysWoW64 не был предназначен для dll 64-битных систем, на самом деле это что-то вроде «Windows on Windows64», то есть биты, которые вам нужны для запуска 32-битных приложений в 64-битных окнах.

Эта статья объясняет немного:

«Windows x64 имеет каталог System32, который содержит 64-разрядные библиотеки DLL (sic!). Таким образом, собственные процессы с разрядностью 64 находят« свои »библиотеки DLL там, где они ожидают: в папке System32. Второй каталог, SysWOW64, содержит 32 -битные библиотеки DLL. Перенаправитель файловой системы полностью скрывает настоящий каталог System32 для 32-разрядных процессов и показывает SysWOW64 под именем System32. "

Изменить: Если вы говорите об установщике, вам действительно не нужно жестко кодировать путь к системной папке. Вместо этого позвольте Windows позаботиться об этом за вас, основываясь на том, работает ли ваш установщик на уровне эмуляции.

Rytmis
источник
27
Тьфу, я только что столкнулся с этой странностью сегодня. Какая обманчивая вещь, которую они сделали.
Энди Уайт
16
Столкнулся с этим и сегодня ... это сбивает с толку - Glut 32-битная DLL входит в / SysWOW64, Glut 64-битная DLL входит в / System32. Кто-то должен записать это. В интернете.
Йерун Баерт
8
Хорошая новость заключается в том, что, как пример инженерного гения Microsoft, это в значительной степени самодокументируется.
Spike0xff
8
Одна вещь, которую я не понимаю, - если файловая система может определить, что это 32-разрядное приложение, и перенаправить его в SysWOW64папку, почему они не могут вместо этого обнаружить 64-разрядное приложение и перенаправить его в System64?!
Коул Джонсон
6
System32 - это 32-разрядная версия системных библиотек Windows. Система является 16-битной версией. Та же самая компания, которая предоставила нам Windows 8, предоставила нам SysWow64 для 32-битных DLL и System32 для 64-битных DLL при работе на 64-битной ОС. В 64-разрядных системах папка System по-прежнему является старым 16-разрядным мусором, только System32 не является 32-разрядной, как это было предложено, а 32-разрядная структура находится в системном каталоге с 64-кратным именем. Я не вижу, как это помогает кому-либо. это усложняет вещи и ломает все. Все, чтобы спасти людей от адаптации жестко запрограммированного "System32" к "System64" при переходе на 64-битную. Идиотизм
Арманд
26

Я должен добавить: вы не должны помещать ваши DLL в \ system32 \ в любом случае! Измените свой код, измените ваш установщик ... найдите дом для ваших битов, который НЕ находится где-нибудь в c: \ windows \

Например, ваш установщик помещает ваши dll в:

\program files\<your app dir>\

or

\program files\common files\<your app name>\

( Примечание : способ, которым вы на самом деле делаете это, это использование среды var:% ProgramFiles% или% ProgramFiles (x86)%, чтобы найти, где находятся Program Files .... вы не предполагаете, что это c: \ program files \ .. ..)

а затем устанавливает тег реестра:

HKLM\software\<your app name>
-- dllLocation

Код, который использует ваши dll, читает реестр, а затем динамически связывается с dll в этом месте.

Выше это умный путь.

Вы никогда не устанавливаете свои dll или dll сторонних разработчиков в \ system32 \ или \ syswow64. Если вам нужно статически загрузить, вы помещаете свои dll в exe dir (где они будут найдены). Если вы не можете предсказать exe dir (например, какой-то другой exe собирается вызвать вашу dll), вам, возможно, придется поместить dll dir в путь поиска (избегайте этого, если это вообще возможно!)

system32 и syswow64 предназначены для файлов, предоставляемых Windows ... ни для каких других файлов . Единственная причина, по которой у людей появилась плохая привычка размещать материал, заключается в том, что он всегда находится в пути поиска, а многие приложения / модули используют статическое связывание. (Так что, если вы действительно дойдете до этого, настоящий грех - статическое связывание - это грех в нативном коде и управляемом коде - всегда всегда динамически связывать!)

Джонсом Восстановить Монику
источник
9
+1 ... но я бы добавил, что вы должны использовать такие переменные, как% PROGRAMFILES% not \ Program Files \
Род МакФерсон
Во времена XP это была обычная (и предполагаемая) практика для разработчиков использовать реестр для таких вещей. С Windows 7 это больше не так! По причинам UAC, многопользовательских сеансов и т. Д. Реестр в Windows 7 следует использовать с осторожностью и по усмотрению разработчиков.
ryyker
@RodMacPherson Мой ответ был улучшен, чтобы учесть ваше предложение. Вы правы!
Jonesome Восстановить Монику
После некоторого рассмотрения я думаю, что это лучше отвечает на вопрос - «Когда нам нужно поместить файл в% SYSTEMROOT%». Никогда. Этот ответ не удовлетворяет любопытство по поводу папки syswow64, но это то, что разработчики действительно должны прочитать.
Томас
7

Столкнулся с той же проблемой и исследовал ее в течение нескольких минут.

Меня учили пользоваться Windows 3.1 и DOS, помните те времена? Вскоре после того, как я некоторое время строго работал с компьютерами Macintosh, после покупки 64-битной машины начал возвращаться к Windows.

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

Большинство изменений упомянуты выше:

  • Program Files против Program Files (x86)

    Вначале 16/86-битные файлы были записаны на процессорах Intel '86'.

  • System32действительно значит System64(на 64-битной Windows)

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

  • SysWOW64 действительно означает SysWOW32

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

Вот две ссылки со всей необходимой базовой информацией:

Надеюсь, это прояснит ситуацию!

хрустящий
источник
4
Если вы хотите, чтобы вас воспринимали всерьез, вы, вероятно, должны смягчить сленг и улучшить грамматику. Кроме того, вы можете структурировать свой ответ немного больше, использовать абзацы.
Клас Меллборн
2
@ Криспи убрал ответ. В будущем вам следует подумать о том, что предлагает Клас, и отформатировать свой ответ, чтобы увеличить шансы на повышение голосов. :)
RekindledPhoenix
ОП необходимо полностью переписать или даже удалить. Это вводит в заблуждение и не очень полезно.
Jonesome Reinstate Моника
5
SysWOW64 на самом деле означает: [Sys] tem [W] indows 32-bit [o] n [W] indows [64] -bit, таким образом, сокращенная форма SysWoW64 (которая действительно не имеет смысла, и Microsoft просто оставила System32 для 32-битных файлов) и создал System64, проблем совместимости действительно не было бы. Что Microsoft делает в изолированной программной среде WoW, это создает перенаправление в памяти 32-битного доступа к System32 как запрос к SysWoW64 ... как это не сложнее, чем просто разоблачение файловая система в необработанном виде без необходимости магическим образом переназначать ее для разных платформ? Как отмечалось в предыдущем комментарии - Идиотизм.
Арманд
1
ответ приносит больше недоразумений, чем ясности в вопросе, комментарий Армандса - хорошее объяснение.
Нахаб
5

System32 - это место, где Windows исторически размещала все 32-битные DLL, а System была для 16-битных DLL. Когда Microsoft создала 64-битную ОС, все, кого я знаю, ожидали, что файлы будут находиться под System64, но Microsoft решила, что имеет смысл размещать 64-битные файлы под System32. Единственная причина, которую я смог найти, это то, что они хотели, чтобы все, что было 32-битным, работало в 64-битной Windows без необходимости что-либо менять в программах - просто перекомпилировать, и все готово. Чтобы решить эту проблему, чтобы 32-битные приложения могли работать, было создать 32-битную подсистему Windows под названием Windows32 На Windows64. Таким образом, аббревиатура SysWOW64 была создана для системного каталога 32-битной подсистемы. Sys - сокращение от System, а WOW64 - сокращение от Windows32OnWindows64.
Поскольку Windows 16 уже отделена от Windows 32, не было необходимости в эквивалентности Windows 16 On Windows 64. В 32-битной подсистеме, когда программа использует файлы из каталога system32, они фактически получают файлы из каталога SysWOW64. Но процесс несовершенен.

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

Armand
источник
2

Другие люди уже проделали хорошую работу по объяснению этой загадки насмешки ... и я думаю, что Крис Хоффман проделал еще лучшую работу здесь: https://www.howtogeek.com/326509/whats-the-difference-between-the- system32-и-Syswow64-папка-в-окно /

Мои две мысли:

  1. Мы все совершаем глупые недальновидные ошибки в жизни. Когда Microsoft назвала их (в то время) каталог Win32 DLL "System32", это имело смысл в то время ... они просто не учитывали, что произойдет, если / когда 64-битная (или 128-битная) версия их ОС были разработаны позже - и серьезная проблема обратной совместимости, вызываемая таким именем каталога. Задним числом всегда 20-20, поэтому я не могу винить их (слишком много) за такую ​​ошибку. ... ОДНАКО ... Когда Microsoft позже разработала свою 64-битную операционную систему, даже с учетом ретроспективного взгляда, почему бы им не только совершить точно такую ​​же недальновидную ошибку СНОВА, но и сделать ее еще хуже, НАДЕЖНО предоставив это такое вводящее в заблуждение имя?!? Позор им !!! Почему бы не НАЧАТЬ на самом деле назвать каталог "SysWin32OnWin64", чтобы избежать путаницы ?! ? И что происходит, когда они в конечном итоге производят 128-битную ОС ... тогда куда они собираются помещать свои 32-битные, 64-битные и 128-битные библиотеки DLL?!?

  2. Вся эта логика все еще кажется мне совершенно ошибочной. В 32-разрядных версиях Windows System32 содержит 32-разрядные библиотеки DLL; в 64-разрядных версиях Windows System32 содержит 64-разрядные библиотеки DLL ... так что разработчикам не придется вносить изменения в код, верно? Проблема с этой логикой заключается в том, что эти разработчики либо сейчас создают 64-битные приложения, требующие 64-битные DLL, либо 32-битные приложения, нуждающиеся в 32-битных DLL ... в любом случае, они все еще не работают? Я имею в виду, что если они все еще делают 32-битное приложение, чтобы оно теперь работало в 64-битной Windows, им теперь нужно будет изменить код, чтобы найти / обратиться к той же самой 32-битной DLL, которую они используется раньше (сейчас находится в SysWOW64). Или, если они работают над 64-битным приложением, им все равно нужно будет переписать старое приложение для новой ОС ... так что в любом случае потребуется перекомпиляция / перестройка !!

Microsoft просто причиняет мне боль иногда.

Рич Бэйлесс
источник