Я хотел бы знать, когда нам нужно поместить файл под
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.
Очень запутанный материал. В чем причина этого?
Я считаю, что намерение было переименовать System32, но так много приложений были жестко закодированы для этого пути, что было невозможно удалить его.
SysWoW64 не был предназначен для DLL 64-разрядных систем, это фактически что-то вроде "Windows на Windows64", что означает, что вам нужно запускать 32-разрядные приложения на 64-битных окнах.
Эта статья немного объясняет:
"Windows x64 имеет каталог System32, который содержит 64-разрядные библиотеки (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)%, чтобы найти файлы программ... вы не считаете, что это 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... не для всех файлов elses. Единственная причина, по которой люди попали в плохую привычку вкладывать вещи, потому что она всегда находится в пути поиска, и многие приложения/модули используют статическое связывание. (Итак, если вы действительно справитесь с этим, настоящий грех - это статическое связывание - это грех в собственном коде и управляемом коде - всегда всегда всегда динамически связывать!)
Перейдите в ту же самую проблему и исследовали ее в течение нескольких минут.
Меня учили использовать Windows 3.1 и DOS, помните те дни? Вскоре после того, как я работал с компьютерами Macintosh строго некоторое время, он начал возвращаться к Windows после покупки x64-разрядной машины.
Есть фактические причины этих изменений (некоторые скажут историческое значение), которые необходимы, чтобы программисты продолжали свою работу.
Большинство изменений упомянуты выше:
Program Files vs 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 - для Windows32OnWindows64.
Поскольку окна 16 уже отделены от Windows 32, не было необходимости в эквиваленте Windows 16 On Windows 64. В 32-битной подсистеме, когда программа переходит к использованию файлов из каталога system32, они фактически получают файлы из каталога SysWOW64. Но этот процесс испорчен.
Это ужасный дизайн. И, по моему опыту, мне пришлось сделать намного больше изменений для написания 64-битных приложений, что простое изменение каталога System32 для чтения System64 было бы очень небольшим изменением, и для тех, которые предназначены для предкомпилятора, предназначены для обработки.