Global/Thread Keyboard Hooks

I've heard two different things and I just want to clarify.

When specifying a global keyboard hook, I know that it must be in a DLL, but which hook id should be implemented for each type of hook

Is it

WH_KEYBOARD - Thread
WH_KEYBOARD_LL - Global ?

Or the other way around or what else should I know. MSDN specifies which one is low level (obvious: LL) and that should mean global input correct? Why is it required that a .dll be used anyway for a global keyboard hook?

Quote:

---

Originally Posted by Rodaxoleaux

Why is it required that a .dll be used anyway for a global keyboard hook?

---

How else could you possibly inject your code into OTHER processes? It's a global hook.

There are some global hooks that do not need to be in a DLL. For example, WH_KEYBOARD_LL is global-only and does not require a DLL since it uses a message loop to "deliver" the callback.

For hooks that global or local, the last parameter to SetWindowsHookEx() determines if it is global or local.

SetWindowsHookEx function

gg

Quote:

---

Originally Posted by brewbuck

How else could you possibly inject your code into OTHER processes? It's a global hook.

---

Oh yeah... duh... *facepalm*


@CodePlug:


dwThreadId [in]
Type: DWORD
The identifier of the thread with which the hook procedure is to be associated. If this parameter is zero, the hook procedure is associated with all existing threads running in the same desktop as the calling thread.

You did not lie.

Okay I read a bit more and WH_KEYBOARD_LL switches context to the running program in order to process the hook event. How fun |3

Quote:

---

For example, WH_KEYBOARD_LL is global-only and does not require a DLL since it uses a message loop to "deliver" the callback.

---

What MSDN doesn't tell you (or at least didn't, it seems someone's recently added a community content bit), is that the normal WH_KEYBOARD/WH_MOUSE hooks also send messages if the event occurs in an app you can't inject into (events in 64-bit apps for 32-bit hooks, and equally vice versa). If you don't have a message pump, the app sending the event freezes waiting you to retrieve the message.

EDIT: Oh, and as soon as I post it I see MSDN has added a bit at the bottom of the remarks about it. That'll show me. Well, it doesn't tell you how they can be called on the installing thread so I'm claiming that this post isn't totally useless.