_WIN32_WINNT определение изменено в заголовке, это вызывает двоичную несовместимость?

В VS2010 я работаю над обновлением приложения до новой версии сторонней библиотеки, для которой значение _WIN32_WINNT должно быть не менее 0x501, но другая сторонняя общая библиотека, которая предоставляет двоичные общие библиотеки, определяет его как 0x500 в заголовке, который включен в приложение.

Если это изменить, может ли быть двоичная несовместимость или это незначительное изменение? Нужно ли будет запрашивать новые двоичные файлы из библиотеки, которая определяет его как 0x500? Я не уверен, как определить, требуются ли для этого новые бины — я бы подумал, что если какие-либо классы / структуры меняются в размере или в именовании, или меняются сигнатуры любых методов / функций, то необходима новая компиляция.

1

Решение

Короткий ответ: Наверное, нет, но если это произойдет, вы в довольно рассол.

Длинный ответ:

_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, затем вещи собираются взорваться. К счастью, я не ожидаю, что таких структур будет много, потому что диапазон версий очень узок. Однако, если это вызывает беспокойство, то вам определенно следует запросить новые двоичные файлы, потому что обходить их будет сложно и утомительно с множеством возможностей совершать ошибки.

Кроме этого, я думаю, что вы (вероятно) в безопасности.

3

Другие решения