我今天发现GetWindowLong(and GetWindowLongPtr) 有 'ANSI' (A) 和 'Unicode' (W) 风格，即使它们没有TSTR参数。上的MSDN 页面GetWindowLong仅表明存在这些变体，但没有提及原因。
我可以想象它必须与CreateWindowEx（也有 A/W 风格）或的编码相匹配RegisterClass，但由于许多原因，我认为这没有意义。显然，这很重要，因为有人报告说 Unicode 版本在 XP 上可能会失败（即使 XP 是 NT 并且据我所知，所有 Unicode 都在引擎盖下）。我还尝试反汇编 32 位版本USER32.DLL（其中包含 的两种风格GetWindowLong），并且基于一些明显的编码差异做了额外的工作*。
我应该选择哪个功能？
GetWindowLong*除了传递给其他函数的布尔值外，它们的风格是相同的。这个布尔值与内存结构中的标志位进行比较，我懒得使用静态代码分析来追踪。
我相信原因在 Raymond Chen 的文章中有解释，GWLP_WNDPROC 返回的这些奇怪的值是什么？
如果当前窗口过程与 GetWindowLongPtr 的调用者不兼容，则无法返回真正的函数指针，因为您无法调用它。相反，会返回一个“魔法 cookie”。此 cookie 的唯一目的是被 CallWindowProc 识别，以便它可以将消息参数转换为窗口过程期望的格式。
例如，假设您正在运行 Windows XP 并且窗口是 UNICODE 窗口，但编译为 ANSI 的组件调用 GetWindowLong(hwnd, GWL_WNDPROC)。无法返回原始窗口过程，因为调用者正在使用 ANSI 窗口消息，但窗口过程需要 UNICODE 窗口消息。因此，返回的是一个魔术 cookie。当您将这个神奇的 cookie 传递给 CallWindowProc 时，它会将其识别为“哦，我需要将消息从 ANSI 转换为 UNICODE，然后将 UNICODE 消息提供给那边的那个窗口过程。”