GetWindowLongにANSIとUnicodeのバリエーションがあるのはなぜですか？

Question

引数を持たないにもかかわらず、GetWindowLong（およびGetWindowLongPtr）には 'ANSI'（A）と 'Unicode'（W）のフレーバーがあることがわかりました。 MSDN page on GetWindowLongは、これらの亜種が存在することを示していますが、理由は言及していません。

CreateWindowEx（A/Wの味もあります）またはRegisterClassのエンコーディングと一致する必要がありますが、これは意味があるとは思えません。どうやら、それは重要です。なぜなら、someone reported that the Unicode version may fail on XP（XPはNTですが、私が理解しているように、すべてのUnicodeがフードの下にあります）。私はまた、（両方のフレーバーがGetWindowLongを含む）の32ビットバージョンを逆アセンブルしようとしました。また、明らかなエンコードの違いに基づいて余分な作業が行われています*。

どの機能を選択する必要がありますか？

---

* GetWindowLongの味は、彼らが他の関数に渡す周りのブール値を除いて、同一です。このブール値は、メモリ構造のフラグビットと比較されます。スタティックコード分析を使用して追跡することはできません。

Answer 1

私は、現在のウィンドウプロシージャがGetWindowLongPtrの呼び出し元と互換性がない場合、あなたはそれを呼び出すことができないので、その後、実際の関数ポインタを返すことができないWhat are these strange values returned from GWLP_WNDPROC?

、理由はレイモンド陳氏の記事で説明されていると考えています。代わりに、 "魔法のクッキー"が返されます。このCookieの唯一の目的は、CallWindowProcによって認識されるため、メッセージパラメータをウィンドウプロシージャが期待する形式に変換することができます。

たとえば、Windows XPを実行していて、ウィンドウがUNICODEウィンドウであるが、ANSIとしてコンパイルされたコンポーネントがGetWindowLong（hwnd、GWL_WNDPROC）を呼び出すとします。呼び出し元がANSIウィンドウメッセージを使用しているが、ウィンドウプロシージャがUNICODEウィンドウメッセージを必要とするため、RAWウィンドウプロシージャは返されません。代わりに、魔法のクッキーが返されます。この魔法のクッキーをCallWindowProcに渡すと、「ああ、メッセージをANSIからUNICODEに変換し、そのウィンドウプロシージャにUNICODEメッセージを渡す必要があります」と認識します。