我今天发现GetWindowLong（和GetWindowLongPtr）有'ANSI'（A）和'Unicode'（W）风格，即使它们没有TSTR个参数。 MSDN page on GetWindowLong仅表示存在这些变体，但未提及原因。
我可以想象它必须匹配CreateWindowEx（也有A / W风格）或RegisterClass的编码，但由于种种原因，我认为这没有道理。显然，这很重要，因为someone reported that the Unicode version may fail on XP（即使XP是NT，据我所知，所有的Unicode都在引擎盖下）。我还试图反汇编32位版本的USER32.DLL（包含GetWindowLong的两种风格），并且基于一些明显的编码差异*进行了额外的工作。
我应该选择哪种功能？
* GetWindowLong的风格是相同的，除了它们传递给其他函数的布尔值。这个布尔值与内存结构中的标志位进行比较我无法使用静态代码分析进行跟踪。
答案 0 :(得分：7)
我相信Raymond Chen的文章What are these strange values returned from GWLP_WNDPROC?
中解释了这个原因如果当前窗口过程与GetWindowLongPtr的调用者不兼容，则无法返回真实函数指针，因为您无法调用它。相反，返回“魔术cookie”。此cookie的唯一目的是由CallWindowProc识别，因此它可以将消息参数转换为窗口过程所期望的格式。
例如，假设您运行的是Windows XP，窗口是UNICODE窗口，但编译为ANSI的组件调用GetWindowLong（hwnd，GWL_WNDPROC）。无法返回原始窗口过程，因为调用者正在使用ANSI窗口消息，但窗口过程需要UNICODE窗口消息。因此，返回一个神奇的cookie。当您将此魔术cookie传递给CallWindowProc时，它会将其识别为“哦，我需要将消息从ANSI转换为UNICODE，然后将UNICODE消息提供给该窗口过程。”