🚀 go-pugleaf

In article <143@cf_su20.cf_su10.Sbi.COM> nee@cf_su14.Salomon.Com (Robert Nee) writes:
>I am having a problem implementing a Hook function in windows.  I feel 
>I must be doing something wrong.  I have two programs that both install
>WH_GETMESSAGE hooks.  Either will work fine by itself but if I run
>both it seems that the second program (it doesn't matter which one)
>prevents the first's hook function from getting called.  Both hook
>functions are in DLLs and have a structure similar to the following:

You should always call DefHookProc if you want hook functions down the
chain to be called.  This may not have been documented too clearly but 
this should solve your problem.

>where NextHook is a pointer to a pointer to the next hook.  Even if this
>nexthook parameter is wrong it shouldn't matter because each program
>installs only one hook.  The documentation claims that this NextHook is 
>only for multiple hooks in one program.  Is this correct?

Nope, next hook is a pointer (actually, better to treat it as a magic
cookie) to the next hook in the chain regardless of where it is.


>SetWindowsHook returns the Proc Instance of the previous hook function
>installed.  Do I need to call that function manually when I am done?
>(the sample above does not do that)

No, don't do this... For the magic cookie reasons stated above.

>I am certain I am installing these functions properly.  And they are in 
>DLLs as recomended.  One final question; If the application is not really
>designed for real mode can I place the hook function in my main program,
>or more specifically a non-discardable segment of my program without any
>side effects?

No, don't place the hook function in your app. Very very bad idea.
First, most apps are written SS==DS.  Your hook function is pretty
much always called SS!=DS.  Bad things happen if you runn SS==DS
runtime libraries in a SS!=DS environment etc...

Also, there are some "future compatibility" issues so Microsoft is telling
you this for your own good...

--Dave