为什么Win32 API中没有使用标准数据类型？
我一直在学习Visual C ++ Win32编程。 为什么使用DWORD ， WCHAR ， UINT等数据类型而不是unsigned long ， char ， unsigned int等等？
我必须记住何时使用WCHAR而不是const char *，这真的很烦我。 为什么不首先使用标准数据类型？ 如果我记住Win32等价物并将它们用于我自己的变量会有帮助吗？
是的，您应该为函数的参数使用正确的数据类型，否则您可能会遇到麻烦。
并且这些类型以它们的方式定义的原因，而不是使用int ， char等，它是从OS的接口中删除“编译器认为int应该被设置为”的任何内容。 这是一件非常好的事情，因为如果您使用编译器A，编译器B或编译器C，它们都将使用相同的类型 – 只有库接口头文件需要做正确定义类型的事情。
通过定义非标准类型的类型，可以很容易地将int从16位更改为32位。 Windows的第一个C / C ++编译器使用16位整数。 只是在1990年代中后期，Windows获得了32位API，直到那时，你使用的是16位的int 。 想象一下，你有一个使用数百个int变量的良好工作程序，突然之间，你必须将所有这些变量改为其他东西……不会很好，对 – 特别是那些变量不需要更改，因为为某些代码移动到32位int不会产生任何差别，因此更改这些位没有意义。
应该注意的是， WCHAR与const char – WCHAR是“宽字符”，因此wchar_t是可比较的类型。
因此，基本上，“定义我们自己的类型”是一种保证可以更改底层编译器体系结构的方法，而无需更改（大部分）源代码。 所有进行机器编码的大型项目都会做这种事情。
内置类型（如int和long的大小和其他特性可能因编译器而异，通常取决于运行代码的系统的基础体系结构。
例如，在最初实现Windows的16位系统上， int只有16位。 在更现代的系统中， int是32位。
Microsoft可以定义类似DWORD类型，以便它们的大小在其编译器的不同版本或用于编译Windows代码的其他编译器中保持相同。
这些名称旨在反映微软定义的底层系统的概念。 DWORD是一个“双字”（如果我没记错的话，在Windows上是32位，即使机器“字”在现代系统上可能是32位甚至64位）。
使用uint16_t和uint32_t – 但这些只是通过1999 ISO C标准（Microsoft的编译器不完全引入）引入C语言甚至在今天支持）。
如果您正在编写与Win32 API交互的代码，那么您肯定应该使用该API定义的类型。 对于不与Win32交互的代码，请使用您喜欢的任何类型，或者您正在使用的接口建议的任何类型。
我认为这是一次历史性事故。
我的理论是，最初的Windows开发人员知道标准C类型的大小取决于编译器，也就是说，一个编译器可能有16位整数，另一个编译器可能有32位整数。 所以他们决定使用一系列typedef在不同的编译器之间移植Window API：无论你使用什么编译器/架构， DWORD都是32位无符号整数。 当然，现在你将使用uint32_t ，但当时不可用。
然后，使用UNICODE的东西，他们获得了TCHAR与CHAR与WCHAR问题，但这是另一个故事。
而且，它失去了控制，你得到了像typedef void VOID, *PVOID;这样的好东西typedef void VOID, *PVOID; 这完全是胡说八道。