help understand DLL's (process hooks)

[m_m]

I'm trying to read as much as i can but i'm getting confused. I understand how a DLL works within MY proccess space, but when you hook a DLL to another process, do you still use the DLL the same way? (meaning i have my program load the DLL located in another folder, and use it as i would if it was only ment for my program and in my programs folder?)

Also, when writing an ADDON to another pogram such AS mine sweeper or WORD, you can say search for a button's HWND, and use sendmessage to press the button. if all i want to do is grab information from another programs window, and i can do it with standard win32 API calls, is there any benifit to grabbing the information through subclassing the window with the use of DLL hooks?

please help.
mitch

[m_m]

this must be a tough subject.
i can never get an answer/help on it.

=/

[filthy_mcnasty]

DLL_PROCESS_ATTACH
and DLL_PROCESS_DETACH messages are sent when your DLL is loaded on another process. my knowledge here is rather limited but i think it's safe to say they dont behave in exactly the same manner but remain somewhat consistent.

i dont really understand your first question though. if you load a DLL in your project through GetModuleHandle or LoadLibrary with subsequent GetProcAddress calls then it functions like it would anywhere else.

the advantage of subclassing in your second question is just to intercept messages. if all you're concerned with is obtaining values then there is no real benefit but if you want to catch or modify values externally then yes.

[galathaea]

when you hook a DLL to another process, do you still use the DLL the same way?

No. When the dll is in the other process, you usually do not use it by calling exported functions or getting exported classes from it. Instead, if it is not your processes space, you normally structure your dll in a way so that it operates with the interface of the application whose space it resides in, or it operates on its own (setting up its own execution on the process attach notification). This means that for something like MSWord, you often make your dll into a COM module that deals specifically with the Word object model and the dispatch interface of Word. Or for something like hooks, you make your hook procedure be a central "message loop" of the dll that drives its execution. In any way, dlls residing in other processes have to set themselves up to perform some useful activity at some point that normally uses methods that are not necessary if you are using the dll directly in a process that is expecting it to be there (like your own apps).

is there any benifit to grabbing the information through subclassing the window with the use of DLL hooks?

filthy_mcnasty's post gave the answer to this. I just want to point out that this is related to what I just mentioned. To reiterate, dll's sitting in other process need some kind of activity that it sets itself up with in order to execute its code. All dlls get process and thread attachment/detachment notifications, but these often don't give enough of a messaging system to do anything useful. Setting up notifications for a messaging system (like in hooks) gives you a lot of power to operate as a fully messaging executable that supercedes the messaging of the application one has hooked. You should only use this power when you need this power. If you do not see any benefits for what you are doing, then you likely do not need it.

[m_m]

i understand more now, and i appreciate your comments.

thanks for the help!