Well, I think it makes sense considering that the module containing the
hooking code ends up loaded into every process currently running on the
desktop. MSDN documents that aspect of global hooks:
"A global hook monitors messages for all threads in the same desktop as the
calling thread. ... A global hook procedure can be called in the context of
any application in the same desktop as the calling thread, so the procedure
must be in a separate dynamic-link library (DLL) module. ... If the
application installs a hook procedure for a thread of a different
application, the procedure must be in a DLL."
But rather than point out the implications of this, the documenation merely
warns against using global hooks. (As if a warning was enough!) The doc
makes references to the section on DLLs, where the topic of using shared
memory is touched on
_a_dynamic_link_library.asp), but stops short of making the connection as to
exactly why this is important.
Imo, the SDK docs are generally insufficient so it pays to dig a little
deeper. And it's easier to use Google to search MSDN than the MSDN search -
just append "site:msdn.microsoft.com" on to the query. eg:
It turns out that MSDN does cover the issue in an article titled "Win32
Hooks" by Kyle Marsh: "Filter functions for systemwide hooks must be
prepared to share any data they need across the different processes they are
running from. A DLL is mapped into the address space of each of its client
processes. Global variables within the DLL will be instance specific unless
they are placed in a shared data section. "
A good explanation of hooks can be found here:
, the code examples use a VC++
specific pragma related to shared memory.