This is rather theoretical Win32 question without code (but it is important and directly applicable to code). If I have a DLL in which are two (or three or six) hook procedures, and hooks are set referencing all of them. (That is, SetWindowsHookEx has been called multiple times, and each hook procedure is handling a different hook. I don't care whether it is the same type of hook or different.) If I don't explicitly create any threads, is there any chance that two of my hook procedures will be operating at the same time? In other words, are there thread-safety issues with global variables?

Thanks for anyone's help,
UberGeek

Each process is going to get its own copy of the DLL mapped into the process virtual address space. There are always "issues" with global variables whether multi-threaded or not. Avoid using globals. Win32 code tends to be the "global master." If you know that an application is multi-threaded, use Win32 synchronization objects to manage access to your shared variables.



:davis:

yeah...I see what you mean. The problem is, this is supposed to be a utility DLL providing "generic" hook procedures, to save a "client" application the trouble of creating a dedicated hook DLL. So I want the DllMain(DLL_PROCESS_DETACH) to uhook all open hooks, if any. I think I'll go with the approach of having a global vector of hooks and protecting said vector with a critical section.

I don't see what benefit the client application gets by using a DLL for the purpose you've described. It sounds like you'd be better off just creating a DLL code template that "boiler-plates" the hook DLL so that it simplifies the creation of the code...rather than defining some kind of abstraction layer and then having to ensure that the relevant infrastructure necessary to handle the hooks are implemented.

A possibly more useful design might be based on an ABC that a DC could implement for the behavioral specification requirements of the hook responsibilities. You could use a layer of indirection by implementing a DC of the ABC that is a "house-keeper" that your client derives for the benefit of the commonality. This may suggest Decorator.

This sounds like it could be a candidate for a COM object...perhaps even an ActiveX COM object that includes a design-time/run-time prop sheet for enabling the hook characteristics sought by the individual program? For any app to use the information provided by the hooks, there would need to be some kind of protocol between the "ProvidesHooks" object that knows the specifics of the various system hooks and the relevant data stream from them such that it can provide it back up to the client so that the client can do something meaningful with it. IOW, it just sounds like a relatively futile layer of indirection for what gain? Though I'm not sure that I fully understand what it is you want to accomplish in your DLL.

However, probably better than a global vector of hooks would be a class that implements the hook vectors that the DLL "connects" based on the runtime interaction with the client. This way, all of the synchronization can be managed inside of the class with only the DLL maintaining a direct interface to it. Furthermore, the dtor of the class can free system/resources when the DLL is unloaded without an ugly switch statement in your detach handler.

If you've got the MSDN, check out the sources to spy++. It may help point you in a direction that better enables you to come up with a suitable design.


:davis:

I like your idea of a boiler-plate, actually. You went way over my head with the rest of your post, I'm afraid. BTW, I don't have MSVC++, and so COM and ActiveX is a pain.
edit: I love acronymfinder.com. So ABC and DC = abstract base class and derived class. That seems like a good idea--a class could encapsulate the LoadLibrary and GetProcAddress and all that, and unhook when it went out of scope. No idea what you mean by Decorator, though.

Decorator is a "Gang of Four (GoF) Design Pattern (DP)." You'll easily be able to find a lot of detail about it on the web. I'll look for a really good link and send it to you when I can find it. Another name for Decorater is "Wrapper." But, I don't feel that that name fully embellishes the concept of Decorator.


:davis: