c - Windows 数据类型...为什么如此冗余/缺乏描述性？

Question

有人可以确切地知道为什么定义了以下 typedefs/#defines 吗？与原件相比，它们有什么值(value)？

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(反之亦然)？这两个 typedef 不是都是 64 位宽的吗？

或者，作为另一个例子:即使在一个旨在在各个方面欺骗我们的“假设的”编译器中，ULONG_PTR 和 UINT_PTR 之间的区别是什么？ DWORD_PTR？这些抽象数据类型不都是同一个意思吗 -- SIZE_T？

但是，我想问他们为什么使用 ULONGLONG 而不是 long long - 两者在含义上是否存在潜在差异？ long long 还是 DWORDLONG？

Answer 1

大多数这些冗余名称的存在主要有两个原因:

• 它们是为向后兼容而保留的历史类型
• 它们是来自不同开发人员团队的同一类型的不同名称(对于团队来说，在像 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 位时代，当时有常规的 16 位“近”指针和 32 位的“远”指针。类型上的 L 前缀代表“long”或“far”，现在没有意义，但在那些日子里，这些可能是这样定义的:

typedef void near *PVOID;
typedef void far *LPVOID;

---

更新:至于FLOAT、UINT和ULONG，这些只是“更多抽象是好”，考虑到 future 的变化。请记住，Windows 也可以在 x86 以外的平台上运行——您可以想到一种体系结构，其中 float 以非标准格式表示，并且 API 函数经过优化以利用这种表示形式。这可能会与 C 的 float 数据类型发生冲突。