As soon EasyHook EasyHook64.dll intercepts the first DefWindowProcW message, and from it starts a thread, it does not catch any DefWindowProcW anymore:
|___ DefWindowProcW (caught)
|--
|--
|--
|-- DefWindowProcW (don't 'intercept' anymore)
|-- ...
It stops 'catching' all DefWindowProcW messages until the thread end.
I was told:
This is by design, it is part of the thread deadlock barrier.
And:
You could install two hooks for the same function, leaving the second disabled until you enter your first hook, you would enable it by setting its ACL inclusive to the current thread, then disable it again as you leave the first hook.
Then I tried to call it like:
HOOK_TRACE_INFO hHook = { NULL };
HOOK_TRACE_INFO hHook2 = { NULL };
HOOK_TRACE_INFO hHook3 = { NULL };
LRESULT __stdcall DefWindowProcW_Hook( HWND hWnd, UINT Msg, WPARAM wParam, LPARAM lParam)
{
switch (Msg) {
//......
}
ULONG ACLEntries[1] = { 0 };
LhSetInclusiveACL(ACLEntries, 1, &hHook);
ULONG ACLEntries2[1] = { 0 };
LhSetInclusiveACL(ACLEntries2, 1, &hHook2);
ULONG ACLEntries3[1] = { 0 };
LhSetInclusiveACL(ACLEntries2, 1, &hHook3);
return DefWindowProcW(hWnd, Msg, wParam, lParam);
}
// =======================================
void __stdcall NativeInjectionEntryPoint(REMOTE_ENTRY_INFO* inRemoteInfo)
{
LhInstallHook(
GetProcAddress(GetModuleHandle(TEXT("user32")), "DefWindowProcW"),
DefWindowProcW_Hook, NULL, &hHook);
ULONG ACLEntries[1] = { 0 };
LhSetExclusiveACL(ACLEntries4, 1, &hHook);
LhInstallHook(
GetProcAddress(GetModuleHandle(TEXT("user32")), "DefWindowProcW"),
DefWindowProcW_Hook, NULL, &hHook2);
LhInstallHook(
GetProcAddress(GetModuleHandle(TEXT("user32")), "DefWindowProcW"),
DefWindowProcW_Hook, NULL, &hHook3);
}
But now, looks like all hooks are doing the same thing:
Result:
Would like to ask someone who uses or already used EasyHook how to properly read the same function when there is a 2nd or more nested call.
There is no elegant solution for this in EasyHook, however if you are happy to install as many intermediate hooks as you need for the nesting levels you can chain them together.
The outermost hook will be the only one enabled initially.
It will first ensure all innermost hooks are disabled, then enable the next hook.
To prevent calling the hook for the same DefWindowProcW call, we can retrieve the next hook's bypass address and call that instead of the original DefWindowProcW like you would normally do.
As you have already discovered, once within a hook handler for a hook it will not trigger that same hook again until after the return statement has completed and we have gone back up the call stack. This is due to the thread-deadlock barrier in EasyHook.
Example:
HOOK_TRACE_INFO hHook = { NULL };
HOOK_TRACE_INFO hHook2 = { NULL };
HOOK_TRACE_INFO hHook3 = { NULL };
typedef LRESULT __stdcall DefWindowProcFunc(HWND, UINT, WPARAM, LPARAM);
// Innermost hook handler
LRESULT __stdcall DefWindowProcW_Hook( HWND hWnd, UINT Msg, WPARAM wParam, LPARAM lParam)
{
switch (Msg) {
//......
}
// Innermost hook just call original
return DefWindowProcW(hWnd, Msg, wParam, lParam);
}
// Middle hook handler
LRESULT __stdcall DefWindowProcW_Hook2( HWND hWnd, UINT Msg, WPARAM wParam, LPARAM lParam)
{
switch (Msg) {
//......
}
// Activate next hook handler for next nesting level
ULONG ACLEntries[1] = { 0 };
LhSetInclusiveACL(ACLEntries, 1, &hHook);
PVOID* bypass_address;
LhGetHookBypassAddress(&hHook, &bypass_address);
//return DefWindowProcW(hWnd, Msg, wParam, lParam);
// Bypass the handler for THIS call to DefWindowProcW - the next nested call will be captured in DefWindowProcW_Hook
return ((DefWindowProcFunc*)bypass_address)(hWnd, Msg, wParam, lParam);
}
// Outermost hook handler
LRESULT __stdcall DefWindowProcW_Hook3( HWND hWnd, UINT Msg, WPARAM wParam, LPARAM lParam)
{
// Outermost hook handler - this will be called first for new calls to DefWindowProcW
switch (Msg) {
//......
}
// Disable innermost hook(s) - do this for each inner hook that isn't the next hook
ULONG disableACLEntries[1] = { 0 };
LhSetExclusiveACL(disableACLEntries, 1, &hHook);
// Activate next hook handler for first nesting level
ULONG ACLEntries[1] = { 0 };
LhSetInclusiveACL(ACLEntries, 1, &hHook2);
PVOID* bypass_address;
LhGetHookBypassAddress(&hHook2, &bypass_address);
//return DefWindowProcW(hWnd, Msg, wParam, lParam);
// Bypass the handler for THIS call to DefWindowProcW - the next nested call will be captured in DefWindowProcW_Hook2
return ((DefWindowProcFunc*)bypass_address)(hWnd, Msg, wParam, lParam);
}
// =======================================
void __stdcall NativeInjectionEntryPoint(REMOTE_ENTRY_INFO* inRemoteInfo)
{
// NOTE: the last installed hook handler will be the first called i.e. hHook3, then hHook2 then hHook.
LhInstallHook(
GetProcAddress(GetModuleHandle(TEXT("user32")), "DefWindowProcW"),
DefWindowProcW_Hook, NULL, &hHook);
LhInstallHook(
GetProcAddress(GetModuleHandle(TEXT("user32")), "DefWindowProcW"),
DefWindowProcW_Hook2, NULL, &hHook2);
LhInstallHook(
GetProcAddress(GetModuleHandle(TEXT("user32")), "DefWindowProcW"),
DefWindowProcW_Hook3, NULL, &hHook3);
// Activate outermost hook (ie last installed hook which will be the first called - hHook3)
ULONG ACLEntries[1] = { 0 };
LhSetExclusiveACL(ACLEntries, 1, &hHook3);
}
Related
I want to use the Windows API to get keyboard input from a window. From what I have heard, I can create a callback function that will be called when some events happen. I just don't know how.
ModuleManager::ModuleManager() {
HWND getGameWindow = FindWindow(NULL, TEXT("GameName"));
wndProc = (WNDPROC)SetWindowLongPtrA(getGameWindow, GWLP_WNDPROC, 0);
}
LRESULT CALLBACK ModuleManager::WndProc(const HWND hwnd, unsigned int message, uintptr_t wParam, long lparam) {
if (message == WM_CHAR) {
for (Module* m : modules) {
if (m->getKeybinding() == wParam) {
m->isActive = !m->isActive; // toggle
}
}
}
return CallWindowProcA(wndProc, hwnd, message, wParam, lparam);
}
Here is my current code. I want to set a callback on WndProc function.
It seems i figured it out.
The callback function must be a static function for some reason.
So the correct code is following:
ModuleManager::ModuleManager() {
HWND getGameWindow = FindWindow(NULL, TEXT("GameName"));
wndProc = (WNDPROC)SetWindowLongPtrA(getGameWindow, GWLP_WNDPROC, (LONG_PTR) &ModuleManager::WndProc);
}
LRESULT CALLBACK ModuleManager::WndProc(const HWND hwnd, unsigned int message, uintptr_t wParam, long lparam) {
if (message == WM_CHAR) {
for (Module* m : modules) {
if (m->getKeybinding() == wParam) {
m->isActive = !m->isActive; // toggle
}
}
}
return CallWindowProcA(wndProc, hwnd, message, wParam, lparam);
}
I apologize if I'm overlooking something, but I'm trying to just create a placeholder window within an ATL dialog, which will be used to host a preview handler. I thought placing a custom control might be the thing to do, since it's blank and would occupy a designated place, but that's causing the dialog to crash, and I get the feeling doing something with a custom control is more complicated than I'm looking for. So is there a way to just put a dummy window inside a dialog for use as a host site? Thanks for any input.
Update: I seem to have achieved the desired result using a simple blank picture control. But I'm still wondering if there's a more official way of doing this.
for placeholder we need use exactly custom control. the point - need specify window class name. and this class must be registered.
let name of class will be MyClass
so in .rc file must be
CONTROL "Custom1",IDC_CUSTOM1,"MyClass",...
and we need register "MyClass", minimal code
class MyWndCls
{
LRESULT CALLBACK WindowProc(HWND hwnd, UINT uMsg, WPARAM wParam, LPARAM lParam)
{
switch (uMsg)
{
case WM_NCDESTROY:
delete this;
break;
}
return DefWindowProcW(hwnd, uMsg, wParam, lParam);
}
static LRESULT CALLBACK _WindowProc(HWND hwnd, UINT uMsg, WPARAM wParam, LPARAM lParam)
{
return reinterpret_cast<MyWndCls*>(GetWindowLongPtrW(hwnd, GWLP_USERDATA))->WindowProc(hwnd, uMsg, wParam, lParam);
}
static LRESULT CALLBACK StartWindowProc(HWND hwnd, UINT uMsg, WPARAM wParam, LPARAM lParam)
{
if (uMsg == WM_NCCREATE)
{
if (MyWndCls* p = new MyWndCls)
{
SetWindowLongPtrW(hwnd, GWLP_USERDATA, (LONG_PTR)p);
SetWindowLongPtrW(hwnd, GWLP_WNDPROC, (LONG_PTR)_WindowProc);
return p->WindowProc(hwnd, uMsg, wParam, lParam);
}
return 0;
}
return DefWindowProcW(hwnd, uMsg, wParam, lParam);
}
inline static const WCHAR clsname[] = L"MyClass";
public:
static ULONG Register()
{
WNDCLASS wndcls = {
0, StartWindowProc, 0, 0, (HINSTANCE)&__ImageBase, 0,
LoadCursorW(0, IDC_HAND), (HBRUSH)(COLOR_INFOBK + 1), 0, clsname
};
return RegisterClassW(&wndcls) ? NOERROR : GetLastError();
}
static ULONG Unregister()
{
return UnregisterClassW(clsname, (HINSTANCE)&__ImageBase) ? NOERROR : GetLastError();
}
};
of course we need call MyWndCls::Register(); before create any dialog with this custom control
I am attempting to add a low level mouse hook to a class. I am able to do so by placing this function in my CPP file:
LRESULT CALLBACK MouseHookProc(int nCode, WPARAM wParam, LPARAM lParam)
{
//my hook code here
return CallNextHookEx(0, nCode, wParam, lParam);
}
Then, I set up the hook in the class constructor like so:
HHOOK mousehook = SetWindowsHookEx(WH_MOUSE_LL, MouseHookProc, NULL, 0);
This works fine for intercepting mouse events, however since the callback function is not defined in my class, it does not have access to any of my class variables.
Therefore, I tried defining the callback function in my header file like so:
LRESULT CALLBACK MouseHookProc(int nCode, WPARAM wParam, LPARAM lParam);
and in my CPP file like this (TMainForm being the class):
LRESULT CALLBACK TMainForm::MouseHookProc(int nCode, WPARAM wParam, LPARAM lParam)
{
//my hook code here
return CallNextHookEx(0, nCode, wParam, lParam);
}
However, when I attempt to compile like this, I get the following errors:
[bcc32 Error] MainFormU.cpp(67): E2034 Cannot convert 'long (__stdcall * (_closure )(int,unsigned int,long))(int,unsigned int,long)' to 'long (__stdcall *)(int,unsigned int,long)'
[bcc32 Error] MainFormU.cpp(67): E2342 Type mismatch in parameter 'lpfn' (wanted 'long (__stdcall *)(int,unsigned int,long)', got 'void')
What exactly am I doing wrong here? How is the method now different since I have made it a part of my TMainForm class?
You cannot use a non-static class methods as the callback. Non-static methods have a hidden this parameter, thus the signature of the callback does not match the signature that SetWindowsHookEx() is expecting. Even if the compiler allowed it (which can only be done with casting), the API would not be able to account for the this parameter anyway.
If you want to make the callback be a member of the class (so it can access private fields and such), it has to be declared as static to remove the this parameter, but then you will have to use the form's global pointer to reach it when needed, eg:
class TMainForm : public TForm
{
private:
HHOOK hMouseHook;
static LRESULT CALLBACK MouseHookProc(int nCode, WPARAM wParam, LPARAM lParam);
void MouseHook(int nCode, WPARAM wParam, LPARAM lParam);
public:
__fastcall TMainForm(TComponent *Owner);
__fastcall ~TMainForm();
};
extern TMainForm *MainForm;
__fastcall TMainForm::TMainForm(TComponent *Owner)
: TForm(Owner)
{
hMouseHook = SetWindowsHookEx(WH_MOUSE_LL, &MouseHookProc, NULL, 0);
}
__fastcall TMainForm::~TMainForm()
{
if (hMouseHook)
UnhookWindowsHookEx(hMouseHook);
}
LRESULT CALLBACK TMainForm::MouseHookProc(int nCode, WPARAM wParam, LPARAM lParam)
{
MainForm->MouseHook(nCode, wParam, lParam);
return CallNextHookEx(0, nCode, wParam, lParam);
}
void TMainForm::MouseHook(int nCode, WPARAM wParam, LPARAM lParam)
{
// my hook code here
}
With that said, you should consider using the Raw Input API instead of SetWindowsHookEx(). The LowLevelMouseProc documentation even says so:
Note Debug hooks cannot track this type of low level mouse hooks. If the application must use low level hooks, it should run the hooks on a dedicated thread that passes the work off to a worker thread and then immediately returns. In most cases where the application needs to use low level hooks, it should monitor raw input instead. This is because raw input can asynchronously monitor mouse and keyboard messages that are targeted for other threads more effectively than low level hooks can. For more information on raw input, see Raw Input.
Using Raw Input, the mouse will send WM_INPUT messages directly to your window.
If you are using VCL, you can override the virtual WndProc() method to handle the WM_INPUT message, no static method needed:
class TMainForm : public TForm
{
protected:
virtual void __fastcall CreateWnd();
virtual void __fastcall WndProc(TMessage &Message);
};
void __fastcall TMainForm::CreateWnd()
{
TForm::CreateWnd();
RAWINPUTDEVICE Device = {0};
Device.usUsagePage = 0x01;
Device.usUsage = 0x02;
Device.dwFlags = RIDEV_INPUTSINK;
Device.hwndTarget = this->Handle;
RegisterRawInputDevices(&Device, 1, sizeof(RAWINPUTDEVICE));
}
void __fastcall TMainForm::WndProc(TMessage &Message)
{
if (Message.Msg == WM_INPUT)
{
HRAWINPUT hRawInput = (HRAWINPUT) Message.LParam;
UINT size = 0;
if (GetRawInputData(hRawInput, RID_INPUT, NULL, &size, sizeof(RAWINPUTHEADER)) == 0)
{
LPBYTE buf = new BYTE[size];
if (GetRawInputData(hRawInput, RID_INPUT, buf, &size, sizeof(RAWINPUTHEADER)) != 0)
{
RAWINPUT *input = (RAWINPUT*) buf;
// use input->data.mouse or input->data.hid as needed...
}
delete[] buf;
}
}
TForm::WndProc(Message);
}
If you are using FireMonkey, there is no WndProc() method for handling window messages (FireMonkey does not dispatch window messages to user code at all). However, you can subclass the window that FireMonkey creates internally so you can still receive the WM_INPUT message. A static method is needed, but you do not have to rely on a global pointer, the Form object can be passed as a parameter of the subclassing:
class TMainForm : public TForm
{
private:
static LRESULT CALLBACK SubclassProc(HWND hWnd, UINT uMsg, WPARAM wParam, LPARAM lParam, UINT_PTR uIdSubclass, DWORD_PTR dwRefData);
protected:
virtual void __fastcall CreateHandle();
};
void __fastcall TMainForm::CreateHandle()
{
TForm::CreateHandle();
HWND hWnd = Platform::Win::WindowHandleToPlatform(this->Handle)->Wnd;
SetWindowSubclass(hWnd, &SubclassProc, 1, (DWORD_PTR)this);
RAWINPUTDEVICE Device = {0};
Device.usUsagePage = 0x01;
Device.usUsage = 0x02;
Device.dwFlags = RIDEV_INPUTSINK;
Device.hwndTarget = hWnd;
RegisterRawInputDevices(&Device, 1, sizeof(RAWINPUTDEVICE));
}
LRESULT CALLBACK TMainForm::SubclassProc(HWND hWnd, UINT uMsg, WPARAM wParam, LPARAM lParam, UINT_PTR uIdSubclass, DWORD_PTR dwRefData)
{
TMainForm *pThis = (TMainForm*) dwRefData;
switch (uMsg)
{
case WM_INPUT:
{
// ...
break;
}
case WM_NCDESTROY:
{
RemoveWindowSubclass(hWnd, &SubclassProc, uIdSubclass);
break;
}
}
return DefSubclassProc(hWnd, uMsg, wParam, lParam);
}
I came across the same issue and I found that the best method, for my particular case, was to create a static array of pointers to my class. Then inside the static hook method, I just iterate through my class pointers and call their hook functions.
kb_hook.h
typedef KBDLLHOOKSTRUCT khookstruct;
typedef LRESULT lresult;
typedef void (*h_func)(uint64_t key_message, khookstruct* kbdhook);
typedef std::vector<kb_hook*> h_array;
class kb_hook
{
public:
kb_hook();
virtual ~kb_hook();
h_func hook_func;
private:
static h_array hook_array;
static lresult static_hook(int code, uint64_t key_message, khookstruct* kbdhook);
};
kb_hook.cpp
kb_hook::kb_hook() : hook_func(NULL)
{
this->hook_array.push_back(this);
}
lresult kb_hook::static_hook(int code, uint64_t key_message, khookstruct* kbdhook)
{
if(code == HC_ACTION)
{
for(auto it=kb_hook::hook_array.begin();it!=kb_hook::hook_array.end();it++)
{
if((*it)->hook_func) std::thread((*it)->hook_func, key_message, kbdhook).detach();
}
}
return CallNextHookEx(NULL, code, key_message, reinterpret_cast<LPARAM>(kbdhook));
}
I know it's an old question but I just wanted to throw in my two cents. I hope this is helpful to someone.
I created a DLL to hook some events using a CBT hook. It seems to work only for the windows created by the process launching the hook...
My system is Windows 7 x64, but the behaviour is the same also on the x32.
This is the code (sorry but I'm no C++ expert):
#include "windows.h"
extern "C"
{
static LRESULT CALLBACK CbtProcCb(int nCode, WPARAM wParam, LPARAM lParam);
HINSTANCE g_hDll = NULL;
HWND g_hNotifyWin = NULL;
DWORD g_uNotifyMsg = NULL;
HHOOK g_hHook = NULL;
__declspec(dllexport) HHOOK SetCbtHook(HWND hWnd, LPCWSTR lStrMsg, DWORD threadId)
{
g_hNotifyWin = hWnd;
g_uNotifyMsg = RegisterWindowMessage(lStrMsg);
g_hHook = SetWindowsHookEx(WH_CBT, (HOOKPROC)CbtProcCb, g_hDll, threadId);
return g_hHook;
}
__declspec(dllexport) int UnsetCbtHook()
{
if ( !g_hHook )
return 0;
return UnhookWindowsHookEx(g_hHook);
}
}
static LRESULT CALLBACK CbtProcCb(int nCode, WPARAM wParam, LPARAM lParam)
{
SendNotifyMessage(g_hNotifyWin, g_uNotifyMsg, nCode, wParam); // Send nCode to check the received event
return CallNextHookEx(g_hHook, nCode, wParam, lParam);
}
BOOL APIENTRY DllMain(HINSTANCE hinstDLL, DWORD fdwReason, LPVOID lpvReserved)
{
if ( fdwReason == DLL_PROCESS_ATTACH )
g_hDll = hinstDLL;
return true;
}
Any hints?
When Windows installs globals hook, the DLL implementing the hook function is often loaded in other processes. In those processes, the g_hNotifyWin and g_uNotifyMsg global variables are NULL. That global variables are only not NULL in the context of the process in which the SetCbtHook call took place.
You must have a way to retrieve the correct value for g_hNotifyWin and 'g_uNotifyMsg', in an arbitrary process.
Add:
const char * g_pszClassName = "MyClassName";
const char * g_pszRegisteredMsg = "MyMessage";
to your DLL, and replace "MyClassName" by the class name of the g_hNotifyWin window. See the RegisterClass call in your EXE. Update also "MyMessage".
Then, use the following CbtProcCb function:
static LRESULT CALLBACK CbtProcCb(int nCode, WPARAM wParam, LPARAM lParam)
{
if ( nCode >= 0 ) {
if ( g_hNotifyWin == NULL ) g_hNotifyWin = FindWindow( g_pszClassName, NULL );
if ( g_uNotifyMsg == 0) g_uNotifyMsg = RegisterWindowMessage(g_pszRegisteredMsg);
if ( g_hNotifyWin && g_uNotifyMsg )
SendNotifyMessage(g_hNotifyWin, g_uNotifyMsg, nCode, wParam); // Send nCode to check the received event
}
return CallNextHookEx(NULL, nCode, wParam, lParam); // first arg useless see MSDN
}
EDIT:
As you noted in comment, same problem for g_uNotifyMsg See updated function. You could set up those variables in DllMain, indeed.
The first argument to CallNextHookEx may be NULL.
I guess your ThreadId is not zero, so hook is attached only to the calling process / thread respectively. Read documentation:
http://msdn.microsoft.com/en-us/library/windows/desktop/ms644990(v=vs.85).aspx
How can I access to the handle of a hook from his procedure ?
Example :
HHOOK hook = SetWindowsHookEx(WH_KEYBOARD_LL, (HOOKPROC)hookProc, GetModuleHandle(NULL), 0);
LRESULT CALLBACK hookProc(int nCode, WPARAM wParam, LPARAM lParam)
{
//I want my HHOOK here :O
}
You need to store the HHOOK variable in global memory. Don't declare it as a local variable of whatever function is calling SetWindowsHookEx().
Edit: Here is a class-based example for 32-bit CPUs:
class THookKeyboardLL
{
private:
HHOOK hHook;
void *pProxy;
static LRESULT CALLBACK ProxyStub(THookKeyboardLL *This, int nCode, WPARAM wParam, LPARAM lParam);
LRESULT CALLBACK HookProc(int nCode, WPARAM wParam, LPARAM lParam);
public:
THookKeyboardLL();
~THookKeyboardLL();
};
.
#include <pshpack1.h>
struct sProxy
{
unsigned char PopEax;
unsigned char Push;
void *ThisPtr;
unsigned char PushEax;
unsigned char Jmp;
int JmpOffset;
};
#include <poppack.h>
long CalcJmpOffset(void *Src, void *Dest)
{
return reinterpret_cast<long>(Dest) - (reinterpret_cast<long>(Src) + 5);
}
LRESULT CALLBACK THookKeyboardLL::ProxyStub(THookKeyboardLL *This, int nCode, WPARAM wParam, LPARAM lParam)
{
return This->HookProc(nCode, wParam, lParam);
}
THookKeyboardLL::THookKeyboardLL()
: hHook(NULL), pProxy(NULL)
{
sProxy *Proxy = (sProxy*) VirtualAlloc(NULL, sizeof(sProxy), MEM_COMMIT, PAGE_READWRITE);
Proxy->PopEax = 0x58;
Proxy->Push = 0x68;
Proxy->ThisPtr = this;
Proxy->PushEax = 0x50;
Proxy->Jmp = 0xE9;
Proxy->JmpOffset = CalcJmpOffset(&(Proxy->Jmp), &ProxyStub);
// Note: it is possible, but not in a portable manner, to
// get the memory address of THookKeyboardLL::HookProc()
// directly in some compilers. If you can get that address,
// then you can pass it to CalcJmpOffset() above and eliminate
// THookKeyboardLL::ProxyStub() completely. The important
// piece is that the Proxy code above injects this class
// instance's "this" pointer into the call stack before
// calling THookKeyboardLL::HookProc()...
DWORD dwOldProtect;
VirtualProtect(Proxy, sizeof(sProxy), PAGE_EXECUTE, &dwOldProtect);
FlushInstructionCache(GetCurrentProcess(), Proxy, sizeof(sProxy));
pProxy = Proxy;
hHook = SetWindowsHookEx(WH_KEYBOARD_LL, (HOOKPROC)pProxy, GetModuleHandle(NULL), 0);
}
THookKeyboardLL::~THookKeyboardLL()
{
if (hHook != NULL)
UnhookWindowsHookEx(hHook);
if (pProxy)
VirtualFree(pProxy, 0, MEM_RELEASE);
}
LRESULT CALLBACK THookKeyboardLL::HookProc(int nCode, WPARAM wParam, LPARAM lParam)
{
// ...
return CallNextHookEx(hHook, nCode, wParam, lParam);
// when this method exits, it will automatically jump
// back to the code that originally called the Proxy.
// The Proxy massaged the call stack to ensure that...
}
If you look at the documentation for CallNextHookEx you see that the HHOOK parameter is optional on Windows NT, if you need to support Windows 9x then you need to store the HHOOK in a global variable.
Your example code shows that you are creating a global hook, global hooks are expensive so if you want to register more than one callback function you should abstract this so that your application only sets one hook and the callback function you register there calls your real functions (in a linked list etc).