Re: System-wide hooking, VB+ASM

On Sat, 4 Jun 2005 08:21:41 -0700, "Sam Hobbs"
<samuel@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote:

>"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.

That had me puzzled at first.
However I can assure you that it works in Delphi

The reason (I believe) is that only the /first/ instance of the DLL
needs to CallNextHook
- in other instances it is effectively a 'dummy'

<snip>

>> 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
> );

Yes - I've been there

>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.

My guess (and it is just a guess) is that all DLLs have this as a
standard entry point.

A bit of further digging and I've found that LibMain is the Win16
entry point and DllMain is the Win 32 entry point.

I suppose the next test is to do a LoadLibrary on a VB DLL from
another language.
.

Relevant Pages

  • Re: System-wide hooking, VB+ASM
    ... The CallNextHookEx function needs the handle to the current hook, ... When the DLL is injected into the other address spaces, ... > I just wonder whether that DllMain that he talks about is a red ... DWORD fdwReason, ...
    (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: C coding guidelines
    ... They can do what they like regarding the entry points they need ... send all startup code related to C library initialization to la la ... It's either in a DLL (if you only linked with ... What do you think calls DLLMain? ...
    (comp.lang.c)
  • Re: C coding guidelines
    ... ALL dlls will be called BY THE LOADER before the program starts. ... This call will be done to a special entry point called DllMain ... For instance, in the dll you sent me, the header ...
    (comp.lang.c)
  • Re: C coding guidelines
    ... A DLL can contain many functions. ... This is NOT a call y your user code, it is a call by the ... This call will be done to a special entry point called DllMain ...
    (comp.lang.c)