我一直在学习Visual C++ Win32编程一段时间。 为什么使用DWORD,WCHAR,UINT等数据类型代替unsigned long,char,unsigned int等？为什么在Win32 API中不使用标准数据类型？
我必须记住什么时候使用WCHAR而不是const char *，这真的让我烦恼。 为什么首先不使用标准数据类型？如果我记住Win32等价物并将它们用于我自己的变量，它会有帮助吗？
是的，你应该使用正确的数据类型作为函数的参数，否则你可能会发现自己有麻烦。
而且这些类型的定义会是这样的，而不是使用int，char等的原因是，它消除了“无论编译器认为一个int的大小应为”从OS的界面。这是一件非常好的事情，因为如果你使用编译器A，编译器B或编译器C，它们都将使用相同的类型 - 只有库接口头文件需要做正确的类型定义。
通过定义非标准类型的类型，例如，很容易将int从16位更改为32位。 Windows的第一个C/C++编译器使用16位整数。只是在20世纪90年代中后期，Windows获得了一个32位的API，并且直到那时，你使用的是16位的int。想象一下，你有一个运行良好的程序，使用几百个变量，突然之间，你必须将所有这些变量改为别的东西......不会很好，对 - 尤其是其中的一些变量不需要改变，因为对于你的一些代码移动到32位int不会有什么区别，所以在改变这些位时没有意义。
应当指出的是，WCHAR是不一样的const char - WCHAR是“宽字符”所以wchar_t是可比的类型。因此，基本上，“定义我们自己的类型”是一种保证可以更改底层编译器体系结构而不必更改（大部分）源代码的方法。所有执行机器相关编码的大型项目都会这样做。
如果您使用的是非Microsoft编译器，则'wchar_t'不一定与'WCHAR'匹配。 – 2013-02-20 16:53:55
好点...... – 2013-02-20 16:59:35
我怀疑......为什么GNU/Linux没有这样的问题？ – 2014-08-27 08:33:53
内置类型（如int和long）的大小和其他特性可能因编译器而异，通常取决于运行代码的系统的基础体系结构。
例如，在最初实现Windows的16位系统上，int仅为16位。在更现代的系统上，int是32位。
微软得到定义类型如DWORD，以便它们的大小在其编译器的不同版本或用于编译Windows代码的其他编译器中保持不变。
这些名称旨在反映微软定义的底层系统的概念。 A DWORD是一个“双字”（如果我正确地记得，它是Windows上的32位，即使机器“字”在现代系统上可能是32甚至64位）。
它可能是更好的使用<stdint.h>定义的固定宽度的类型，如uint16_t和uint32_t - 但这些都只能由1999年的ISO C标准（微软的编译器不完全引入到C语言即使是今天也支持）。
如果您正在编写与Win32 API交互的代码，那么您一定要使用该API定义的类型。对于不与Win32交互的代码，请使用您喜欢的任何类型，或者您使用的接口提供的任何类型。
我认为这是一次历史性事故。
我的理论是，原始的Windows开发人员知道标准C类型的大小取决于编译器，也就是说，一个编译器可能有16位整数，另一个编译器可能有32位整数。所以他们决定使用一系列类型定义让不同编译器之间的Window API可移植：无论您使用何种编译器/体系结构，DWORD都是32位无符号整数。自然，现在您将使用uint32_t从<stdint.h>，但是当时不可用。
然后，与UNICODE的事情，他们得到了TCHAR与CHAR与WCHAR问题，但这是另一回事。
然后，它发展成失控，你得到如此完美的东西typedef void VOID, *PVOID;完全是无稽之谈。
+1对于PVOID废话:) – 2013-02-20 17:08:26
我想冒险一个像PVOID这样的东西是过去处理近远指针的遗迹。显然，它今天看起来很愚蠢，但人们并不理解Windows API的历史。 – Luke 2013-02-20 18:02:10
'WCHAR'与'char *'不一样......（我明白你的意思了） – 2013-02-20 16:44:16
这些是Macro Assembler的数据类型。这是Windows 1.0主要编写的语言。 – 2013-02-20 16:46:36