Эти имена DLL датируются 23 года назад, когда была выпущена первая 32-разрядная версия Windows. Windows версии с 1 по 3 были 16-битными и использовали kernel.dll, user.dll и т. Д. Они склеили «32» после имени DLL, чтобы отличить их от 16-разрядных версий и убедиться, что 32-разрядный процесс не может случайно загрузить 16-разрядную DLL.
Они не сделали этого снова, когда выпустили 64-битную версию Windows. Слишком много программ жестко закодировали эти имена к тому времени, как правило, в вызове LoadLibrary(), и изменение имен затруднило бы перенос таких программ на 64-разрядные. Даже каталог, в котором хранятся эти библиотеки DLL, был переименован, он по-прежнему «system32».
Итак, у машины теперь есть две копии kernel32.dll и др., 64-разрядная версия находится в c: \ windows \ system32 и 32-разрядной версии в c: \ windows \ syswow64. По-прежнему очень важно, что 32-битный процесс никогда не пытается загрузить 64-битную DLL, а наоборот, так же, как это было важно 23 года назад. Таким образом, они придумали еще один трюк, File System Redirector гарантирует, что 32-битный процесс может видеть только копию в syswow64.
Обратите внимание на странность наличия 64-разрядных библиотек DLL в каталоге с именем «system32» и 32-разрядной библиотекой DLL в «syswow64». Сначала выезжайте по многим программистам, теперь вы знаете, как это произошло.
То же самое для файлов .lib, в каталоге SDK есть каталог x86 и x64 для хранения этих файлов. Также довольно автоматизировано, когда компоновщик ищет файл .lib, настроен в Project> Properties> VC++ Directories> Library Directories. Целевая платформа платформы Win32/x86 использует $ (WindowsSDK_LibraryPath_x86), а для целевого объекта x64 используется $ (WindowsSDK_LibraryPath_x64).
ahh - ok - я вижу. Меня также раздражало ходунщик зависимостей (2.1.xx), который показал, что exe должен быть 64-битным, но зависимые dlls нет. с обновленной версией (2.2.xxx) зависимости также отмечены как 64 бит - вопреки их именам (как вы также объяснили) –