Currently, these methods have no way for users to provide user data parameters if the hook is ran in the hooker process (in process). This can be problematic in advanced scenarios, where multiple hooks can be desired (I scope my hooks as much as possible because hooking all events can cause system slowdowns).
Currently, none of the possible solutions are pretty:
Generate thunks, which involves dynamic codegen (a security can of worms) and is not portable at all. I even have a whole project that I started due to this problematic API: https://github.com/sylveon/member_thunk
Store a static pointer and have the callback access this pointer. This results in a great loss of flexibility because you cannot "create" static variables at runtime to accommodate the need for dynamically created hooks.
Use something like std::unordered_map<HWINEVENTHOOK, std::function<...>>, pass the same callback to all hooks and have that callback lookup the map. This is frankly just janky and results in increase memory usage and increased callback execution time, which is critical for system responsiveness.
As far as I know, these two functions are some of the only callback-based functions having this limitation. Even window procedures have a way to store a custom user data pointer.
Additionally, adding this feature for out of process hooks would also be useful as it would allow the hooker process to pass information like a handle acquired with DuplicateHandle, or the handle of a window to use for communication with, to the callback running in the hooked process. Currently, I rely on Detours' DetoursCreateRemotePayload to transfer this information but this solution is far less than ideal, and does some pretty questionable things to the target process (like create a memory allocation that's practically not freeable because Detours never gives you the base pointer and doesn't have an API to free such payloads).
Currently, these methods have no way for users to provide user data parameters if the hook is ran in the hooker process (in process). This can be problematic in advanced scenarios, where multiple hooks can be desired (I scope my hooks as much as possible because hooking all events can cause system slowdowns).
Currently, none of the possible solutions are pretty:
std::unordered_map<HWINEVENTHOOK, std::function<...>>, pass the same callback to all hooks and have that callback lookup the map. This is frankly just janky and results in increase memory usage and increased callback execution time, which is critical for system responsiveness.As far as I know, these two functions are some of the only callback-based functions having this limitation. Even window procedures have a way to store a custom user data pointer.
Additionally, adding this feature for out of process hooks would also be useful as it would allow the hooker process to pass information like a handle acquired with DuplicateHandle, or the handle of a window to use for communication with, to the callback running in the hooked process. Currently, I rely on Detours' DetoursCreateRemotePayload to transfer this information but this solution is far less than ideal, and does some pretty questionable things to the target process (like create a memory allocation that's practically not freeable because Detours never gives you the base pointer and doesn't have an API to free such payloads).