В VS2010 я работаю над обновлением приложения до новой версии сторонней библиотеки, для которой значение _WIN32_WINNT должно быть не менее 0x501, но другая сторонняя общая библиотека, которая предоставляет двоичные общие библиотеки, определяет его как 0x500 в заголовке, который включен в приложение.
Если это изменить, может ли быть двоичная несовместимость или это незначительное изменение? Нужно ли будет запрашивать новые двоичные файлы из библиотеки, которая определяет его как 0x500? Я не уверен, как определить, требуются ли для этого новые бины — я бы подумал, что если какие-либо классы / структуры меняются в размере или в именовании, или меняются сигнатуры любых методов / функций, то необходима новая компиляция.
Короткий ответ: Наверное, нет, но если это произойдет, вы в довольно рассол.
Длинный ответ:
_WIN32_WINNT
контролирует версию WinAPI (и связанных с ней библиотек, таких как MFC), которую будет использовать ваш код. Цель состоит в том, чтобы гарантировать, что ошибки компилятора генерируются, если вы используете функции Windows, которые были представлены после целевой версии Windows.
В основном это контролирует, какие функции, структуры и т. Д. Видны вам. Эта часть не может вызвать бинарную несовместимость, за исключением тех версий Windows, на которые вы не ориентируетесь. Тем не мение…
В WinAPI есть некоторые структуры, которые были расширены в течение жизни Windows. Взгляните, например, на определение OPENFILENAME
:
typedef struct tagOFN {
DWORD lStructSize;
HWND hwndOwner;
HINSTANCE hInstance;
LPCTSTR lpstrFilter;
LPTSTR lpstrCustomFilter;
DWORD nMaxCustFilter;
DWORD nFilterIndex;
LPTSTR lpstrFile;
DWORD nMaxFile;
LPTSTR lpstrFileTitle;
DWORD nMaxFileTitle;
LPCTSTR lpstrInitialDir;
LPCTSTR lpstrTitle;
DWORD Flags;
WORD nFileOffset;
WORD nFileExtension;
LPCTSTR lpstrDefExt;
LPARAM lCustData;
LPOFNHOOKPROC lpfnHook;
LPCTSTR lpTemplateName;
#if (_WIN32_WINNT >= 0x0500)
void *pvReserved;
DWORD dwReserved;
DWORD FlagsEx;
#endif
} OPENFILENAME, *LPOPENFILENAME;
Видите этот последний бит в конце? Это означает потенциальную проблему — одна часть вашего кода будет предполагать, что эта структура меньше другой, если одна скомпилирована с _WIN32_WINNT
установлен в 0x400
а другой к 0x500
,
Дизайнеры WinAPI задумывались над этой проблемой. Вы заметите, что первый член OPENFILE
является lStructSize
; вы должны инициализировать это с sizeof(OPENFILE)
, Для тебя, sizeof(OPENFILE)
является постоянной времени компиляции, для функций в библиотеке времени выполнения Windows это тег, по которому они решают, какая версия OPENSTRUCT
структура ты переходишь в них.
Это создает потенциальную проблему в одном сценарии: если двоичная библиотека и весь ваш код обмениваются типами WinAPI или указателями на такие типы, и если эти типы были расширены между 0x500
а также 0x501
, затем вещи собираются взорваться. К счастью, я не ожидаю, что таких структур будет много, потому что диапазон версий очень узок. Однако, если это вызывает беспокойство, то вам определенно следует запросить новые двоичные файлы, потому что обходить их будет сложно и утомительно с множеством возможностей совершать ошибки.
Кроме этого, я думаю, что вы (вероятно) в безопасности.