_WIN32_WINNT定义在标头中更改，这是否会导致二进制不兼容？

在VS2010中，我正在更新应用程序到新版本的第三方库，要求_WIN32_WINNT至less为0x501，但提供二进制共享库的另一个第三方共享库将其定义为包含在应用程序。

如果这被修改，是否会有二进制不兼容或者这是一个微不足道的变化？ 我必须从库中请求新的二进制文件，它定义为0x500？ 我不知道如何判断这是否需要新的分档 – 我想如果任何类/结构体的大小或命名发生了变化，或者任何方法/function签名发生变化，那么就需要新的编译。

Linux分发二进制兼容性

Windows上C库的二进制交叉编译器兼容性

使用Visual C ++ 2005/2008/2010的便携式Windows应用程序（不是源代码！

是否改变类私人数据成员的顺序会打破ABI

简短的回答：可能不会，但是如果是这样的话，你就是在一个漂亮的泡菜。

很长的回答：

_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之间扩展， 那么事情就会爆炸。 令人高兴的是，由于版本范围很窄，我不期望会有这么多的结构。 但是，如果这是一个担心，那么你肯定会要求新的二进制文件，因为在它周围工作将是困难和繁琐的，有很多错误的机会。

除此之外，我认为你（可能）是安全的。