4

GetWindowLong(and ) には、引数GetWindowLongPtrがなくても 'ANSI' (A) と 'Unicode' (W) のフレーバーがあることを今日知りました。MSDN のページにTSTRは、これらの亜種が存在することが示されているだけで、その理由については言及されていません。GetWindowLong

CreateWindowEx(A/W フレーバーもある) またはのエンコーディングと一致する必要があると想像できますRegisterClassが、多くの理由から、これは意味がないと思います。Unicode バージョンが XP で失敗する可能性があると誰かが報告したため(XP は NT であり、私が理解しているように、フードの下にあるすべての Unicode ですが) 、明らかに重要です。USER32.DLLの 32 ビット バージョン(の両方のフレーバーを含む)の逆アセンブルも試みましたがGetWindowLong、明らかなエンコーディングの違いに基づいて追加の作業が行われています*。

どの機能を選択すればよいですか?

* のフレーバーはGetWindowLong、他の関数に渡されるブール値を除いて同じです。このブール値は、メモリ構造内のフラグ ビットと比較されます。静的コード分析を使用して追跡することはできません。

4

1 に答える 1

7

その理由は Raymond Chen の記事で説明されていると思います。GWLP_WNDPROC から返されるこれらの奇妙な値は何ですか?

現在のウィンドウ プロシージャが GetWindowLongPtr の呼び出し元と互換性がない場合は、呼び出すことができないため、実際の関数ポインターを返すことはできません。代わりに、「マジック クッキー」が返されます。この Cookie の唯一の目的は、メッセージ パラメータをウィンドウ プロシージャが期待する形式に変換できるように、CallWindowProc によって認識されることです。

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

于 2012-01-27T16:41:41.800 に答える