2016-04-19 10 views
2

Я преобразовал старый проект визуальной студии с vs2015 и добавил конфигурацию 64-битной платформы.64-битные листы свойств используют 32-битные dll winapi

Интересно, почему атрибуты компоновщика содержат 32-битные библиотеки (такие как kernel32.lib; user32.lib; gdi32.lib; winspool.lib; comdlg32.lib; advapi32.lib; shell32.lib; ole32.lib; oleaut32. Lib).

Сначала я подумал, что это ошибка от меня, так как я выбрал, чтобы скопировать настройки из настроек платформы win32, но затем я увидел, что эти параметры импортируются листом свойств, который был вставлен студией: «Microsoft.Cpp .x64.user "

Действительно ли это так, как это должно работать? Я где-то читал (здесь, на SO: Can a 64 bit EXE link against 32-bit DLLs?), что 64-битное приложение не может ссылаться на 32-разрядные DLL.

Может ли кто-нибудь просветить меня?

ответ

4

Эти имена 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).

+0

ahh - ok - я вижу. Меня также раздражало ходунщик зависимостей (2.1.xx), который показал, что exe должен быть 64-битным, но зависимые dlls нет. с обновленной версией (2.2.xxx) зависимости также отмечены как 64 бит - вопреки их именам (как вы также объяснили) –