我刚刚开始学习WinAPI。在MSDN中，为WORD数据类型提供了以下说明。
它很简单，并且与我一直在学习中使用的其他资源相匹配，但是怎么可以确定地说它是16位呢？ Wikipedia上的C data types页面指定
因此，根据C标准，short的大小很可能为32位。但是谁决定要使用什么位大小呢？我在这里找到了practical explanation。具体来说，该行:
因此，这就是ISA，我认为这是有道理的。这是我迷路的地方。看一下Wikipedia上的Windows page，我在侧栏中看到了这一点:
我真的不知道这些是什么，但我认为它们是处理器，每个处理器都有一个ISA。也许Windows支持这些平台，因为它们都可以保证对unsigned short使用16位吗？这听起来不太正确，但是我对这方面的知识还不够了解，无法进一步研究。
回到我的问题:当C标准本身不保证typedef unsigned short WORD;始终为16位时，Windows API如何可以WORD然后说short是16位无符号整数？
最佳答案
简而言之，WORD始终为16位。
由于WORD始终为16位，但unsigned short并非为16位，因此WORD并不总是unsigned short。
对于Windows SDK支持的每个平台，Windows头文件都包含#ifdef样式宏，这些宏可以检测编译器及其平台，并将Windows SDK定义的类型(WORD，DWORD等)与适当大小的平台类型相关联。
这就是为什么Windows SDK实际上使用内部定义的类型(例如WORD)而不是使用语言类型的原因:这样它们可以确保其定义始终正确。
Microsoft工具链附带的Windows SDK可能很懒，因为Microsoft c++工具链始终使用16位无符号短裤。
我不希望Visual Studio C++附带的windows.h如果掉入GCC，clang等中时会正常工作，因为许多细节(包括使用Platform SDK分发的.iib文件导入dll的机制)是Microsoft特定的执行。
另一种解释是:
微软说WORD是16位。如果“某人”想要调用Windows API，则他们必须传递一个16位值，其中API将字段定义为WORD。
微软还可能说，为了使用其Windows SDK中存在的Windows头文件来构建有效的Windows程序，用户必须选择具有16位short的编译器。
C++规范没有说编译器必须将short实现为16位-微软表示，您选择构建Windows可执行文件的编译器必须这样做。
关于c - Microsoft如何说WinAPI中单词的大小为16位？，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/37308438/