フックは別のプロセスのコンテキストで呼び出されるため、グローバル Windows フックは DLL 内にある必要があります。そのため、フック プロシージャのコードをそのプロセスに挿入する必要があります。ただし、制限があります。
SetWindowsHookExDLL を別のプロセスに挿入するために使用できます。32 ビット DLL を 64 ビット プロセスに挿入することはできず、64 ビット DLL を 32 ビット プロセスに挿入することもできません。アプリケーションが他のプロセスでフックを使用する必要がある場合、32 ビット アプリケーションを呼び出しSetWindowsHookExて 32 ビット DLL を 32 ビット プロセスに挿入し、64 ビット アプリケーションを呼び出しSetWindowsHookExて 64 ビット DLL をプロセスに挿入する必要があります。 64 ビット プロセス。32 ビット DLL と 64 ビット DLL は異なる名前にする必要があります。
このため、 and の代わりに低レベルのフック and を使用したいと思いWH_MOUSE_LLます。ドキュメントからわかるように：WH_KEYBOARD_LLWH_MOUSEWH_KEYBOARD
このフックは、それをインストールしたスレッドのコンテキストで呼び出されます。呼び出しは、フックをインストールしたスレッドにメッセージを送信することによって行われます。したがって、フックをインストールしたスレッドにはメッセージ ループが必要です。
このことから、これらの特定のフック プロシージャは別の DLL に存在する必要はなく、それらをフックした EXE 内に存在するだけでよいと考えるようになりました。ただし、のドキュメントには次のように記載されています。SetWindowsHookEx
lpfn[in] フック プロシージャへのポインター。
dwThreadIdパラメーターがゼロであるか、別のプロセスによって作成されたスレッドの識別子を指定する場合、パラメーターはlpfnDLL 内のフック プロシージャを指している必要があります。
2 つの低レベルのフックに対する明示的な例外は言及されていません。
別の DLL にフック プロシージャを持たずに、低レベルのフックを使用する .NET アプリケーションをいくつか見てきました。これは、これが受け入れられることを示すもう 1 つのヒントです。ただし、ドキュメントで禁止されているため、自分でこれを行うのは少し怖いです。
DLL を使用せず、これらの低レベルのフック プロシージャを直接 EXE に挿入した場合に問題が発生すると予測する人はいますか?
編集：報奨金については、決定的な「はい、これは大丈夫です...」または「いいえ、これはうまくいかない可能性があるため...」.