为什么 GetWindowLong 有 ANSI 和 Unicode 变体？

Question

我今天发现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 都在幕后）。我还尝试反汇编了USER32.DLL 的32 位版本（包含GetWindowLong 的两种风格），并且基于一些明显的编码差异做了额外的工作*。

我应该选择哪个功能？

---

*GetWindowLong 的风格是相同的，除了它们传递给其他函数的布尔值。这个布尔值与内存结构中的标志位进行比较，我懒得使用静态代码分析来追踪。

Answer 1

相信原因在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 消息提供给那边的那个窗口过程。”