For now I've taken out acquiring the point that the user clicks, etc. I
just want a message box to indicate that the DLL has noted a WM_LBUTTONUP.
Trecius <Trecius@discussions.microsoft.com> wrote:
First, in DllMain(HINSTANCE hinstDLL ...), is the hInstance the
instance of the DLL? MSDN says so, but I'm just confirming it.
Yes. Note that HINSTANCE is only meaningful within the current process.
Every time a DLL is loaded into a new process, its DllMain is called
with its HINSTANCE for that process.
Second, as I see it, when I have a global variable, the variable is
global ONLY to the process with which it was called unless declared
within a #pragma. For example, let's use my g_hEvent variable. If I
have two programs running, and each program calls LoadLibrary(), then
I will have TWO SEPARATE g_hEvents. If delcared in a #pragma,
INITIALIZED, and #pragma comment(linker, ...) then ALL references of
the DLL will share those variables contained in the #pragma section.
So if one reference of the DLL changes a variable, then it will be
reflected in all other references. Is this correct?
Correct. However, g_hEvent is a particularly bad example: you don't
_want_ it to be shared between multiple processes, as the handle is only
valid within the process that created or opened it (unless you jump
through hoops - see DuplicateHandle). You can use a named event to have
each process open its own handle to the single underlying event object
(see the last parameter to CreateEvent).
On the other hand, you definitely want to share g_hHook, as the hook
won't work correctly otherwise (you need HHOOK handle in
CallNextHookEx).
See KB article KB100634 "How to specify both shared data and
non-shared data in a DLL in Visual C++". But realize that:
a) g_hInstance should not be shared this way - in fact, it should
not be shared at all, it is only meaningful within a process.
You're telling me not to include g_hInstance in the #pragma
data_seg("shared"), correct?
Correct.
Well, does it really matter? If my
first question holds true -- that hinstDLL is the instance of the DLL
-- then all programs that load the DLL will have the same hinstDLL
Not necessarily. What makes you think so?
so in a sense, it could be shared? Am I wrong here?
You are.
b) g_hEvent cannot be shared this way - event handles are only valid
within a single process. You need to use a named event, or some other
IPC mechanism.
Again, are you telling me not to put g_hEvent in the #pragma data_seg?
Correct.
Second, are you telling me to use CreateEvent(NULL, TRUE, FALSE,
"MyEvent") instead of CreateEvent(NULL, TRUE, FALSE, NULL)?
Yes. You might want to choose a name that is more likely to be unique
though. A name based on a GUID is usually a good idea.
In this
case, the event will be opened in the other process as it is now
named.
Yes. Of course, both processes should call CreateEvent with the same
name.
c) You have a race condition. Multiple mouse events may arrive into
your hook before the other process reacts to the signalled event and
uninstalls the hook.
Lastly, Igor, I would like to ask WHAT is being injected into the
other process when I call SetWindowsHookEx().
Your DLL, as if loaded with LoadLibrary.
SetWindowsHookEx has the following arguments...
SetWindowsHookEx(idHook, lpfn, hMod, dwThreadId)
So when I call SetWindowsHookEx(...), am I injecting ONLY the lpfn,
or am I injecting the ENTIRE DLL?
Entire DLL. There's no way for the OS to somehow pull a single function
out. Who knows what other functions or data it might depend on?
--
With best wishes,
Igor Tandetnik
With sufficient thrust, pigs fly just fine. However, this is not
necessarily a good idea. It is hard to be sure where they are going to
land, and it could be dangerous sitting under them as they fly
overhead. -- RFC 1925