Почему 64-разрядные библиотеки DLL идут в System32, а 32-разрядные библиотеки - в SysWoW64 в 64-разрядных системах Windows?
Я хотел бы знать, когда нам нужно разместить файл под
C:\Windows\System32 или C:\Windows\SysWOW64, в 64-битной системе Windows.
У меня было две библиотеки DLL, одна для 32-битных, одна для 64-битных.
Логично, что я решил поместить 32-битную DLL в C:\Windows\System32, а 64-битную DLL в C:\Windows\SysWOW64.
К моему удивлению, все наоборот! 32- битная библиотека переходит в C: \ Windows \ SysWOW64, а 64- битная DLL - в C: \ Windows \ System32.
Очень запутанные вещи. В чем причина этого?
4 ответа
Я полагаю, что целью было переименовать 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 позаботиться об этом за вас, основываясь на том, работает ли ваш установщик на уровне эмуляции.
Я должен добавить: вы не должны помещать ваши 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... ни для каких других файлов. Единственная причина, по которой у людей появилась плохая привычка размещать материал, заключается в том, что он всегда находится в пути поиска, а многие приложения / модули используют статическое связывание. (Так что, если вы действительно дойдете до этого, настоящий грех - статическое связывание - это грех в нативном коде и управляемом коде - всегда всегда динамически связывайте!)
Столкнулся с той же проблемой и исследовал это в течение нескольких минут.
Меня учили пользоваться 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 для приложений, которые они хотят использовать.
Вот две ссылки со всей необходимой базовой информацией:
Надеюсь, это прояснит ситуацию!
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 - сокращение от Windows32 On Windows64.
Поскольку Windows 16 уже отделена от Windows 32, не было необходимости в эквивалентности Windows 16 On Windows 64. В пределах 32-битной подсистемы, когда программа использует файлы из каталога system32, они фактически получают файлы из каталога SysWOW64. Но процесс несовершенен.
Это ужасный дизайн. И по моему опыту, мне пришлось сделать намного больше изменений для написания 64-битных приложений, что простое изменение каталога System32 для чтения System64 было бы очень небольшим изменением, и то, что директивы прекомпилятора предназначены для обработки.
Другие люди уже хорошо поработали, объяснив эту нелепую загадку... и я думаю, что Крис Хоффман справился здесь еще лучше: https://www.howtogeek.com/326509/whats-the-difference-between-the-system32-and-syswow64-folders-in-windows/
Мои две мысли:
Все мы совершаем глупые и недальновидные ошибки в жизни. Когда Microsoft назвала свой (в то время) каталог Win32 DLL "System32", в то время это имело смысл... они просто не принимали во внимание, что произойдет, если / когда появится 64-битная (или 128-битная) версия их ОС были разработаны позже, и такое имя каталога может вызвать огромную проблему обратной совместимости. Задним числом всегда 20-20, так что я не могу винить их (слишком сильно) в такой ошибке.... ОДНАКО... Когда Microsoft позже разработала свою 64-битную операционную систему, даже с учетом преимуществ ретроспективного анализа, почему, о, почему они не только сделали ту же самую близорукую ошибку СНОВА, но и сделали ее еще хуже, ЦЕЛЬНО давая это такое вводящее в заблуждение название?!? Позор им!!! Почему бы на самом деле не назвать каталог "SysWin32OnWin64", чтобы избежать путаницы?!? И что произойдет, когда они в конечном итоге создадут 128-битную ОС... тогда где они собираются разместить свои 32-битные, 64-битные и 128-битные библиотеки DLL?!?
Мне кажется, что вся эта логика полностью ошибочна. В 32-битных версиях Windows System32 содержит 32-битные библиотеки DLL; в 64-битных версиях Windows System32 содержит 64-битные библиотеки DLL... чтобы разработчикам не приходилось вносить изменения в код, верно? Проблема с этой логикой в том, что эти разработчики либо сейчас создают 64-битные приложения, требующие 64-битных DLL, либо создают 32-битные приложения, требующие 32-битных DLL... в любом случае, разве они все еще не облажались? Я имею в виду, если они все еще создают 32-битное приложение, чтобы оно теперь работало в 64-битной Windows, им теперь нужно будет внести изменения в код, чтобы найти / ссылаться на ту же самую 32-битную DLL, которую они использовался раньше (теперь находится в SysWOW64). Или, если они работают над 64-битным приложением, им все равно придется переписать свое старое приложение для новой ОС... так что перекомпиляция / перекомпиляция все равно потребуются!!!
Microsoft просто иногда причиняет мне боль.