AutoHotkey Community

I see JGR returned from the dead.

JGR, I just wanted to know the current (2010) status of all your Hooking code? I know you seemed to abandon the CBTHook dll, cuz it was unstable & moved to SetWinEventHook...is this still the case?...or could you make a stable CBTHook dll?...(or is it kinda stable {or what's not stable about it}).

I want to be able to hook messages from ALL windows, for example, windows being created/destroyed (plus all the other nice CBT msgs). I know some hooking methods "don't hook some windows", like Command Prompt windows...so, whatever method, I want it to be able to "receive events" about ANY window, if that requires a CBTHook dll, then that's what I want.

I have already downloaded everything you have ever posted on this subject & would like to discuss this with you. Especially if you are willing to make changes to the CBTHook dll & recompile...(or point me to exactly what I need to compile it like you did).

Also, since AutoHotkey (& presumably AutoHotkey_L) now has RegisterCallback, I believe the DLL only needs to be a CBTHookProc stub, that would forward msgs back into AutoHotkey. For example the ahkhook.dll\reghook function is unnecessary now, since the hook can be registered with RegisterCallback, but then you just need a pointer to a DLL function...or something along those lines, I forget, but the bottom line is AutoHotkey is much more capable now & would require less in the DLL. AutoHotkey Scripts can DllCall SetWindowsHookEx & can use RegisterCallback, if necessary, so I'd like to revisit this & create a new hook.dll, perhaps with Stubs of any Windows Hook that needs a DLL (CBT or otherwise). The HookProc Stubs would receive the hook msgs, pass them to a script & send back any result.

I don't come here very often, so you need to PM me if you want a timely response. I wouldn't have seen this at all if I hadn't searched my name as you'd done...

As for hooking, I've not done any development along those lines since I wrote those DLLs.
Command prompt windows from what I remember don't behave like regular windows in various ways, so I'm not sure about how to go about hooking them.

I would have to refresh my memory on the subject, but I am around if you still want to discuss the matter.

JGR

_________________
If you want to get my attention, PM me.

Other code:
Accent Script
npipe
TTDPatch

...I'm wondering if you'll notice this reply...or if I should login & PM? I think I'll give it a few days/weeks & see if you notice this reply (you could subscribe to this thread, if you want to {& haven't already}).


...I'm not even sure if "hooking" or "injecting dll code" (into each window/process) is the right thing (maybe it's overkill?...or maybe it's the "only way" to do it?).

All I really want it to get notified when ANY window is created/destroyed/etc (& be able to take some action on the window {before it's visible}). SetWinEventHook seems to be able to do that, kinda, but I think I read that it doesn't work if explorer.exe is not the shell. Now, explorer.exe is my shell, but I want to write the code in the most-portable way possible, just in case someone else don't use explorer.exe as their shell. Which is why I'm focusing on the CBTHookProc, it seems to be the only way to do what I want/need...is there any easier way I missed?

I want to make a Window Manager...& to be able to manage windows (for example position & size a window when it's "created", before it's visible), I need events for ALL windows. This would be dirt-simple, with a timer & checking the window list for new windows, however, that doesn't catch the windows before they are visible (although I could resort to that to handle Command Prompt windows, if absolutely necessary {why are they so difficult? Can nothing hook them?}).


...of course I do!!!

Also, for my own purposes, I'm targeting WinXP...so whatever code we come up with has to run on my WinXP (not use Vista or higher APIs)...of course I also want to support Vista/Win7, if possible...but this program would be useless to me if it don't support XP. However, since I'm curious, is "hooking windows" or even simply "receiving events about windows" any easier on Vista/Win7? Did Microsoft write any new APIs to help this problem? I don't want to have to inject code into all windows (& not be able to inject into some windows), but it seems like that's all Microsoft made possible.

Bottom line: As far as I can tell a CBT Hook, with a CBTHookProc function inside a dll, seems to be my only option. So if you could compile a CBTHookProc function in a dll (or even a dll that includes all the *Proc functions), that would send messages to an AutoHotkey window (& accept/pass responses back to Windows), I think, that would do what I need. I have ideas about the params needed to pass to/from the dll somewhere. I know 1 problem with the current dlls is I can't register the hook myself (or does the dll, need to register the hook itself?) & I can't change the window/hwnd the dll is talking to at runtime.

I've not looked into hooking at all since I wrote those dlls however many years ago that was. So at present I have no real insights into how you could do that.

Console windows do not have a (user specified) window procedure, (one that can be injected into at least), as they are managed by the system(?), or in later versions of windows, by a separate host process(?).

Have you tested the SetWinEventHook with a non-explorer shell caveat? I don't see why the shell being used should make a difference, frankly.

I do not know about any changes in the hooking API in more recent versions of windows, you should look at MSDN for that.

As I am lumbered with pathetically slow mobile internet, I cannot really research this sort of thing in a reasonable time scale, until I can go back to uni in a few weeks.
Also I'm quite busy, I've got an interview tomorrow, and I'm behind on all my work, so there's only so much time I can give you.

You probably know more about it than I do from what you've said...

_________________
If you want to get my attention, PM me.

Other code:
Accent Script
npipe
TTDPatch

...nope. I think I just read that somewhere. Also, I don't have any alternate shell to test with, if I did test, it'd just be by killing explorer.exe, having no shell & seeing if it still works.


...something about WinEventHook msgs only being generated if explorer.exe is shell? I'll search again & link to anything I find. After a little searching, I may have mixed up SetWinEventHook & RegisterShellHookWindow? Still searching... Well, right now, I can't find anything about either one working or not working with other shells, maybe I imagined it?


...I could probably look again, but I have looked at MSDN. I was just wondering if you already knew about something that I didn't know about...guess not.


...whenever you can help is fine.


...as above, however much time you can give this, is fine. Do you still have the ability to compile the dll, like you did before?


...the main problem, is I can't make the dll. I certainly can't make the dll as small/optimized as you did: for some reason you used a pragma (or something) so the dll wouldn't import ExitProcess? I would never think to optimize like that.

Anyway, if you get time & could compile a dll for me? I could use your code, rewrite it, like I think would work, then have you compile it. I'm not really good with ASM (certainly not from scratch), but I can see what's there & "tinker".

What's involved in setting up the compiler you used for those dlls?...but even if I could compile it, I still don't know ASM that well. I just need the CBTProc (I thought it was called CBTHookProc...sheesh!?!) stub in the dll & everything else in AutoHotkey.

Using phone so not logged in.

As for producing the dlls, I don't use a compiler, so I don't need to worry about pragmas or optimisation switches. I use NASM.
Assembly is not like high-level languages, at all.

It also doesn't matter what you call the callback proc, as long as you pass it to the relevant registration function.

Writing and assembling dlls is something I can definitely do.

As for SetWinEventHook, I think that you should assume that it will work, in the absence of convincing evidence otherwise.