typedef char CHAR; #define CONST const typedef float FLOAT; typedef unsigned __int64 DWORD64; //A 64-bit "double"-word?! typedef ULONGLONG DWORDLONG; //What's the difference? typedef ULONG_PTR DWORD_PTR; //What's the difference? typedef long LONG_PTR; //Wasn't INT_PTR enough? typedef signed int LONG32; //Why not "signed long"? typedef unsigned int UINT; //Wait.. UINT is "int","LONG" is also int? typedef unsigned long ULONG; //ULONG is "long",but LONG32 is "int"? what? typedef void *PVOID; //Why not just say void*? typedef void *LPVOID; //What?! typedef ULONG_PTR SIZE_T; //Why not just size_t?
最重要的是：
#define VOID void //Assuming this is useful (?),why not typedef?
这些背后的原因是什么？是不是有些抽象我不明白？
编辑：
对于那些提到编译器交叉兼容性的人：
我的问题不在于为什么他们不使用unsigned long long而不是DWORD64。我的问题是为什么任何人使用DWORD64而不是ULONG64(反之亦然)？那些不是64位宽的类型？
或者，作为另一个例子：即使在一个“假设”编译器，这意味着欺骗我们在各方面，ULONG_PTR和UINT_PTR和DWORD_PTR之间的区别是什么？所有抽象数据类型不是仅仅意味着同样的事情 – SIZE_T？
但是，我问为什么他们使用ULONGLONG而不是长久 – 有什么潜在的意义上的差异，既不长久也不是DWORDLONG？
>它们是为了向后兼容而保留的历史类型
>他们是来自不同开发人员团队的同一类型的不同名称(对于像Windows这样的巨大项目，团队来说，保持一致性是非常困难的)
typedef char CHAR;
char的符号可以在平台和编译器之间变化，所以这是一个原因。原始开发人员也可能会保留这个开放的字符编码的未来变化，但是当然这是不再相关的，因为我们现在为了这个目的而使用TCHAR。
typedef unsigned __int64 DWORD64; //A 64-bit "double"-word?!
在64位移动期间，他们可能发现一些DWORD参数真的需要64位长，并且可能将其重命名为DWORD64，以便这些API的现有用户不被混淆。
typedef void *PVOID; //Why not just say void*? typedef void *LPVOID; //What?!
这一个可以追溯到16位的日子，当时有一个常规的“近”指针，它们是32位的16位和“远”指针。类型上的L前缀代表“长”或“远”，现在是无意义的，但在那些日子里，这些可能定义如下：
typedef void near *PVOID; typedef void far *LPVOID;
更新：对于FLOAT，UINT和ULONG，这些只是“更抽象是好的”的例子，考虑到未来的变化。请记住，Windows还可以在除x86之外的平台上运行 – 您可以想到一种以非标准格式表示浮点数的架构，并且API函数已优化以利用此表示。这可能与C的浮点数据类型相冲突。