iconic wrote:HookAPI() requires the name of the module that the API exists in, in this case SetWindowsHookExA() does *not* exist in the export table of ntdll.dll at all. It only exists inside user32.dll so the behavior is completely normal. It will never trigger on ntdll.dll, only when SetWindowsHookExA() is called from user32.dll because it only exists inside this DLL.
--Iconic
madshi wrote:Maybe it should. But there could be situations where you want a different behaviour. For example, let's say you do "HookAPI(weird.dll, weirdApi)", and let's say that there are different versions of "weird.dll" around, some of which export the "weirdApi" and some don't. Now if a process loads an old version of "weird.dll" which doesn't contain the API, then obviously you would expect HookAPI() to fail. But what happens if the process unloads "weird.dll" and loads a newer version of it which *does* export "weirdApi"? In that situation madCodeHook would actually automatically successfully hook the "weirdApi" for you in the moment when the process loads the new version of the dll.
Now I admit, the above scenario will be rare. But it *can* happen.
I'd like to make the following argument: If your code isn't buggy, then you will have a good reason to ask madCodeHook to hook a specific API in a specific DLL, won't you? So madCodeHook tends to trust that your code isn't buggy, and that the API will actually exist in some version of the dll somewhere. If it didn't, you wouldn't ask madCodeHook to hook it, would you? So based on that madCodeHook just thinks to itself: "Well, the API isn't available now, but clearly wineggdrop thinks that some version of the dll does export this API, so I'd better prepare for that situation, in case a new version of the dll gets loaded later".
Makes sense?
madshi wrote:I guess I could do that, but it would really only help during development, but it would not improve anything on the PC of the end user, or would it?
Users browsing this forum: No registered users and 23 guests