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

Question

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

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 .

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

Answer 1

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

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

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

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

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

Answer 2

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

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

\program files\<your app dir>\

or

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

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

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

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

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

Вышесказанное - разумный путь.

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

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

Answer 3

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

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

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

• Перенаправитель файловой системы MSDN

• Объяснение SysWow64

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

Answer 4

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

Answer 5

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

Две мои мысли:

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 только иногда причиняет мне боль.