这个程序
{$APPTYPE CONSOLE}
{$TYPEDADDRESS ON}
uses
Winapi.Windows;
procedure Foo(P: PDWORD);
begin
end;
procedure Bar;
var
dw: DWORD;
begin
Foo(@dw);
end;
begin
end.
在XE3中编译，但在XE4，XE5，XE6和XE7中不编译。错误是
Foo(@dw);
[dcc32 Error] E2010 Incompatible types: 'PDWORD' and 'Pointer'
这感觉奇怪。所以，在一点挖掘后，似乎问题是由PDWORD的定义。人们可能自然地认为：
PDWORD = ^DWORD;
实际上是XE3的情况。在更高版本中，我们发现：
// Note: Not ^DWORD yet PDWORD = ^CppULongInt;
奇。那么，什么是CppULongInt？
CppULongInt = type LongWord;
{$EXTERNALSYM CppULongInt 'unsigned long'}
{$OBJTYPENAME CppULongInt 'Bul' 'Gm'}
然后看看DWORD的声明，我们发现：
//NOTE: DWORD should really be CppULongInt DWORD = LongWord;
所以，CppULongInt和DWORD是不同的类型。因此编译错误。
这里发生了什么？ CppULongInt的目的是什么？为什么RTL设计者似乎想要将DWORD别名为CppULongInt。此更改是否与基于LLVM的x64 Windows C编译器相关？我是世界上唯一使用{$ TYPEDADDRESS ON}的人吗？
注意，最后一个问题是修辞。
解决方法
它看起来有人在Embarcadero没有阅读相关的Windows文档：
http://msdn.microsoft.com/en-us/library/windows/desktop/aa383751(v=vs.85).aspx
DWORD被显式定义为32位无符号整数，因此在Delphi中它应该是一个UInt32。
PDWORD定义为指向DWORD的指针，因此在Delphi中应该是PDWORD = ^ DWORD。
它是DWORD_PTR(这不是一个PDWORD！)被定义为ULONG_PTR，后者根据平台 – Win32或Win64 – 而不是un unsigned long的编译器定义改变大小。
一个原因可能是他们正在尝试在非Windows平台上使用DWORD和其他Windows数据类型，并试图保持它们兼容。如果是这样，在这种情况下，他们失败，并引入了一个错误，因为使用的定义将无法在Windows中正常工作。