cod*_*mps 8 c windows assembly winapi msdn
我刚刚开始学习WinAPI.在MSDN中,为WORD数据类型提供了以下说明.
WORD
16位无符号整数.范围是0到65535十进制.
此类型在WinDef.h中声明如下:
typedef unsigned short WORD;
很简单,它与我用于学习的其他资源相匹配,但它怎么能明确地说它是16位？维基百科上的C数据类型页面指定
short/short int/signed short/signed short int
短符号整数类型.
能够至少包含[-32767,+ 32767]范围; 因此,它的大小至少为 16位.
因此short根据C标准,a的大小很可能是32位.但是谁决定使用什么比特尺寸呢？我在这里找到了实用的解释.具体来说,行:
...它取决于两个处理器(更具体地说,ISA,指令集架构,例如x86和x86-64)和包括编程模型的编译器.
那么这就是ISA,我认为这是有道理的.这是我迷路的地方.看一下维基百科上的Windows页面,我在侧栏中看到了这一点:
平台ARM,IA-32,Itanium,x86-64,DEC Alpha,MIPS,PowerPC
我真的不知道这些是什么,但我认为这些是处理器,每个都有一个ISA.也许Windows支持这些平台,因为所有这些平台都保证使用16位unsigned short？这听起来不太对劲,但我对这些东西的了解还不够深入.
回到我的问题:当C标准本身不能保证a 总是16位时,Windows API怎么能typedef unsigned short WORD;然后说WORD是16位无符号整数short？
简单地说,a WORD总是16位.
因为a WORD总是16位,但是a unsigned short不是,a WORD并不总是a unsigned short.
对于Windows的SDK支持所有平台,Windows头文件包含#ifdef风格的宏,可以检测编译器和其平台和Windows SDK定义的类型(关联WORD,DWORD等等)到适当大小的平台类型.
这就是为什么Windows SDK实际上使用内部定义的类型,例如WORD,而不是使用语言类型:这样他们可以确保它们的定义始终是正确的.
Microsoft工具链附带的Windows SDK可能很懒,因为Microsoft c ++工具链总是使用16位无符号短路.
我不希望在WINDOWS.H随Visual Studio的C++才能正常工作,如果投进GCC,铛等,如此多的细节,包括使用.iib的平台SDK分发文件导入dll的机制,是一个特定的微软实现.
不同的解释是:
微软称a WORD是16位.如果"某人"想要调用Windows API,则必须传递16位值,其中API将字段定义为WORD.微软也可能会说,为了构建一个有效的Windows程序,使用Windows SDK中的Windows头文件,用户必须选择一个16位的编译器short.
c ++规范没有说编译器必须将shorts 实现为16位 - 微软称你选择构建windows可执行文件的编译器必须.
最初假设所有打算在Windows上运行的代码都将使用Microsoft自己的编译器或完全兼容的编译器进行编译.这就是它的工作方式.Borland C:匹配Microsoft C. Zortech的C:匹配Microsoft C. gcc:不是那么多,所以你甚至没有尝试(更不用说没有运行时等).
随着时间的推移这一概念得到了编纂和扩展到其他的操作系统(或者其他的操作系统得到了它第一),现在它被称为一个ABI - 应用程序二进制接口 -一个平台,和所有的编译器为平台的假设(以练习,要求)匹配ABI.这意味着匹配对整数类型(以及其他)的大小的期望.
你没有问过的一个有趣的相关问题是:为什么16位被称为一个单词？为什么是32位的DWORD我们32-(双字),现在64位架构,其中本机"字"的大小是32或64,而不是16？因为:80286.
在 Windows 标头中，有很多基于平台的 #define 可以确保 WORD 是 16 位、DWORD 是 32 等等。在过去的某些情况下，我知道他们为每个平台分发了适当的 SDK。无论如何，没有什么神奇的，只是适当的#defines 和标题的混合。
| 归档时间： |
|
| 查看次数： |
770 次 |
| 最近记录： |