Re: System-wide hooking, VB+ASM

"J French" <erewhon@xxxxxxxxxx> wrote in message
news:42a17489.8343638@xxxxxxxxxxxxxxxxxxx
>
> Sure - it is just a lashup job - I'm not proud of it
>
> www.jerryfrench.co.uk/hooktest.zip

The CallNextHookEx function needs the handle to the current hook, which is
returned by the SetWindowsHookEx function used to set the hook. You are
doing that, except the handle is not available in any other address space.
When the DLL is injected into the other address spaces, an uninitialized
value (probably zero) will be used for the hook handle (hHook). I don't know
how much of a problem that is, but it could be a problem.

>>I was wondering about that as well. It's not clear to me if Sub Main in a
>>DLL corresponds to a call to LibMain or what exactly.
>
> I don't think it does, as LibMain is expected to return pretty
> promptly with a success/failure result
>
> I have just been reading this article :
> http://www.windowsdevcenter.com/pub/a/windows/2005/04/26/create_dll.html
>
> He says that:
> <quote>
> A DLL also includes an optional entry point, which is called when a
> process or thread loads or unloads the DLL. Windows calls this entry
> point when a process loads and unloads the DLL.
> <quote>
>
> He calls it DllMain #0
> The key is that it is /optional/ - something I did not realize
>
> However if it really is optional, then it should not be needed for a
> system wide hook.
> In the Delphi Hook DLL it does use it or something like it, but it
> does not need to.
>
> Alhough delving deeper, Delphi has something called _InitLib that does
> the same.
>
> I just wonder whether that DllMain that he talks about is a red
> herring.
>
> This is getting quite interesting.

Look up DllMain in the SDK documentation. It's prototype is:

BOOL WINAPI DllMain(
HINSTANCE hinstDLL, // handle to the DLL module
DWORD fdwReason, // reason for calling function
LPVOID lpvReserved // reserved
);

The DllMain is called by Windows twice for each process the DLL is used for
and twice for each thread. The fdwReason parameter indicates what the call
is for. In a DLL I wrote using C++ that has system-wide hooks in it, the
only thinkg my DllMain does is to store the hinstDLL when fdwReason is
DLL_PROCESS_ATTACH. If I were to get the DLL's instance handle using
something else, then I don't need the DllMain in that DLL.

I don't know if VB uses a DLL entry point (called DllMain, LibMain or
whatever) but it probably does. We don't know what it is doing but it could
be causing a problem somehow.


.

Relevant Pages

  • Re: System-wide hooking, VB+ASM
    ... >returned by the SetWindowsHookEx function used to set the hook. ... The reason is that only the /first/ instance of the DLL ... >Look up DllMain in the SDK documentation. ... standard entry point. ...
    (microsoft.public.vb.winapi)
  • Re: WM_INITMENU and GetSystemMenu different, why ?
    ... You can do your menu modifying in dllmain. ... > that you care about from the point of view of the hook itself is that it ... it simply means that your DLL will get loaded when any ... -GJC [MS Windows SDK MVP] ...
    (microsoft.public.win32.programmer.ui)
  • Re: Using Visual Basic to Write System-Wide Hooks
    ... >I've spent about an hour looking into writing a system-wide hook using only ... a system-wide callback function must be located within a DLL. ... >system-wide hook DLL. ... The reason is that Visual Basic has some large runtime ...
    (microsoft.public.vb.winapi)
  • Re: Preventing a program from gaining the focus with a CBT hook
    ... Giving focus back to the losing window... ... Hooks being intrusive / DLL unload issues... ... Why not "memset(caption, 0, sizeof(caption))"? ... It is easy to forget how utterly intrusive a system hook is. ...
    (microsoft.public.win32.programmer.kernel)
  • Re: SetWindowsHookEx
    ... automatically inject into all programs. ... It sets the global hook on the ... DLL injecting - in all likelyhook SetWindowsHook returns before the DLL has ... with your shared-section, then the gHook variable (which contains ...
    (microsoft.public.vc.language)