🚀 go-pugleaf

Remy Lebeau (TeamB) wrote:
> Your first instance is likely deactivating the hook during its shutdown, 
> thus it is no longer available for any instances that are still running. 
> The behavior you desacribe would suggest that the hook is being associated 
> with the first instance (per the hMod parameter of SetWindowsHookEx()). 

I played around with the message boxes a little more, having them also 
report the hMod parameter that came in to the DllEntryPoint() function 
and which was subsequently used in the call to SetWindowsHookEx().  The 
value of hMod is the same for each of the app instances that are 
started, so I'm not sure how the hook could be deactivated by one 
particular instance (the first one) terminating.

By putting a MessageBox() call in the hook procedure itself, though, I 
found that it's not the termination of the first app instance that 
deactivates the hook, but instead the detaching of Explorer.exe from the 
DLL that immediately follows the detaching of the first app instance, 
even though it was in the context of the first app process that the hook 
was set.  I'm still not clear on why Explorer.exe associates itself with 
the DLL only when the first app instance loads the library (but not 
subsequent loads), or why it even wants to be involved in this at all, 
but it seems to be causing the problem.

> To do what you are attempting, I suggest moving the hook code into a 
> separate .exe of its own.  The first instance of your app can launch the 
> hook .exe, which then loads the DLL hook.  The last instance of your app can 
> terminate the hook .exe, unloading the DLL.  That way, the hook is 
> associated with its own process, not any particular instance of your app.

If you have any idea what's going on as things stand now, I'd like to 
hear it.  In the meantime, though, I'm going to try the approach you 
suggested (for which, thanks).  Just working it out on paper at this 
point, I think I see how to go about it -- something like this:

1. hook.dll will contain the hook procedure itself (as it has to).

2. hook.exe will load the DLL and set the hook.

3. the first app instance will start hook.exe with CreateProcess(), but 
subsequent app instances will not; I think a named mutex created by the 
first app will work for this.

4. all of the app instances should be able to take advantage of the 
registered message coming from the hook procedure in the DLL.

5. the instances of the app somehow need to 'know' if they are the last 
to terminate so they can terminate hook.exe (which will unload the DLL) 
before closing.  I'm thinking shared memory through a FileMapping object 
would be the simplest way to maintain a reference count of the number of 
instances running.

6. when the last instance is closing, it signals hook.exe which calls 
ExitProcess() on its own process, allowing it clean up and unload the 
DLL.  Since there's really no reason for hook.exe to have a message 
loop, I'm thinking an event would be a good signal, with hook.exe using 
WaitForSingleObject() after it loads the DLL.

At least on paper, this seems reasonable, and I think it's at least 
roughly what was suggested.  Anyone feel free to tell me how stupid it 
really is, though.

Thanks -- Steve