Windows 数据类型...为什么如此冗余/不具描述性？

Question

有人能问一下为什么定义了以下typedefs/#defines吗？与原版相比，它们有什么价值？

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（反之亦然）？ typedefed 不是都是 64 位宽吗？

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

但是，我am问他们为什么使用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，这些只是“越抽象越好”的例子，考虑到未来的变化。请记住，Windows 也可以在 x86 以外的平台上运行——您可以考虑一种架构，其中浮点数以非标准格式表示，并且 API 函数经过优化以利用这种表示。这可能与 C 的 float 数据类型发生冲突。

Answer 2

25 年前首次构建 Windows API 头文件时，int 为 16 位，long 为 32 位。头文件随着时间的推移而演变，以反映编译器和硬件的变化。

此外，Microsoft C++ 并不是唯一可以处理 Windows 头文件的 C++ 编译器。当 Microsoft 添加 size_t 关键字时，并非所有编译器都支持它。但他们可以轻松地创建一个宏 SIZE_T 来表达它。

此外，有（或曾经有）将 API 头文件从 C/C++ 转换为其他语言的自动化工具。其中许多工具最初是为使用当前（当时）的标头定义而编写的。如果 Microsoft 只是按照您的建议更改头文件以简化它们，那么其中许多工具将停止工作。

基本上，头文件将 Windows 类型映射到最小公分母，以便多个工具可以使用它们。有时看起来确实有些混乱，我怀疑如果微软愿意放弃任何向后兼容的表象，他们可以减少大部分混乱。但是这样做会破坏很多工具（更不用说很多文档了）。

所以，是的，Windows 头文件有时是一团糟。这就是我们为进化、向后兼容性和使用多种语言的能力付出的代价。

附加信息：

我同意乍一看所有这些定义似乎很疯狂。但是作为一个看到 Windows 头文件随时间演变的人，我理解它们是如何产生的。这些定义中的大多数在引入时都非常有意义，即使现在它们看起来很疯狂。至于具体情况ULONGLONG和DWORD64，我想它们是为了一致性而添加的，因为旧的头文件有ULONG和DWORD，所以程序员会期待另外两个。至于为什么ULONG和DWORD在同一个东西的时候都被定义了，我可以想到几种可能，其中两种是：

• 一个 API 团队使用 ULONG，另一个使用 DWORD，当合并头文件时，他们只是保留两者，而不是通过转换为一个或另一个来破坏代码。
• 有些程序员更愿意考虑ULONG 而不是DWORD。 ULONG 表示您可以对其进行数学运算的整数类型，而 DWORD 仅表示某种通用的 32 位值，通常是您不想修改的键、句柄或其他值.

您最初的问题是，看似疯狂的定义背后是否有某种推理，或者您是否没有遗漏抽象。简单的答案是定义在演变，当时的变化是有意义的。没有特别的抽象，但目的是如果您编写代码以使用标头中定义的类型，那么您应该能够将您的代码从 32 位移植到 64 位没有麻烦。也就是说，DWORD 在两种环境中都是相同的。但是如果你在 API 说返回值为HANDLE 时使用DWORD 作为返回值，你就会遇到麻烦。

Answer 3

一个原因是为了在 C 编译器之间保持某种可移植性。

尤其是DWORD64，理论上你只需要改变DWORD64的定义就可以让代码在其他编译器上编译。