winapi - 为什么 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的 flavor 是相同的，除了它们传递给其他函数的 bool 值。这个 bool 值与内存结构中的标志位进行比较，我无法使用静态代码分析来追踪。

Answer 1

我相信在 Raymond Chen 的文章中解释了原因，What are these strange values returned from GWLP_WNDPROC?

If the current window procedure is incompatible with the caller of GetWindowLongPtr, then the real function pointer cannot be returned since you can't call it. Instead, a "magic cookie" is returned. The sole purpose of this cookie is to be recognized by CallWindowProc so it can translate the message parameters into the format that the window procedure expects.

For example, suppose that you are running Windows XP and the window is a UNICODE window, but a component compiled as ANSI calls GetWindowLong(hwnd, GWL_WNDPROC). The raw window procedure can't be returned, because the caller is using ANSI window messages, but the window procedure expects UNICODE window messages. So instead, a magic cookie is returned. When you pass this magic cookie to CallWindowProc, it recognizes it as a "Oh, I need to convert the message from ANSI to UNICODE and then give the UNICODE message to that window procedure over there."