Re: Using Visual Basic to Write System-Wide Hooks

Tech-Archive recommends: Fix windows errors by optimizing your registry

On Sun, 5 Jun 2005 12:27:10 +0200, "Mark Yudkin"
<myudkinATcompuserveDOTcom@xxxxxxxxx> wrote:

>
>"Jonathan Wood" <jwood@xxxxxxxxxxxxxxxx> wrote in message
>news:e1QhCsEaFHA.3784@xxxxxxxxxxxxxxxxxxxxxxx
>> Mark,
>>
>>> This is correct. There is no compiler-based technique that allows
>>> cross-process memory sharing.

>> Most of the system-wide hooks examples I've seen use the shared data
>> segment
>> approach so, unless you can provide some reason why this isn't as good as
>> memory mapped files, I'm pretty much going to assume you're just guessing.

The memory mapped file stuff is a red herring here
One really does not need shared memory of any sort

>Read my post.
><quote>
>Karl already said that memoy mapped files are
>the simplest way to go if you need to go the shared memory route. There are
>also much simpler means of dealing with simple IPC, and for VB6, DCOM /
>COM[+], whilst not quite so "simple" from a system viewpoint, is trivial to
>code from a VB6 viewpoint.
></quote>

Also good old SendMessage
- with a WM_BROADCAST to start it off
- or if one is feeling lavish, just use WM_BROADCAST all the time

>There is no techniques for user-mode sharing of memory across processes in
>the NT4/W2K/WXP/W2K3 family except memory mapped files.

Is that so ?
So the C shared memory stuff simply does not work in NT+
Interesting

>Of course, if you were to read the documentation, you'd have seen the
>section "Using Shared Memory in a Dynamic-Link Library", which describes
>what Karl said.

>>
>>> Also there is no need for any form of shared storage whatsoever for
>> calling
>>> CallNextHookEx. The only parameters you need to pass to CallNextHookEx
>>> are
>>> those your DLL was passed when your hook was called.
>>
>> Well, there, you are clearly wrong. Ever look at the docs?

><Quote from MS docs>
>The CallNextHookEx function passes the hook information to the next hook
>procedure in the current hook chain. A hook procedure can call this function
>either before or after processing the hook information.

Yes, but the funny thing is that 'hhk' can be zero in all but the
first DLL to be loaded
- that is what I've seen in my Delphi example
- it had me puzzled until I realized that all instances except the
first DLL are not really 'hooking' at all

My Win32 Help file does not point out that hhk is 'ignored'
- but checking your post against MSDN
.... shows that hhk is 'ignored'

There really is no need for any form of shared memory

Actually I reckon that the use of memory mapped files is very likely
to be fairly inefficient as it has to guarantee that the current
thread does not give up its time slice to any other thread/process
- Windows probably jumps through hoops to achieve that


.