Re: Using Visual Basic to Write System-Wide Hooks

On Wed, 1 Jun 2005 13:33:00 -0600, "Jonathan Wood"
<jwood@xxxxxxxxxxxxxxxx> wrote:

>Okay, hopefully, this will be my last word on this.
>
>I've spent about an hour looking into writing a system-wide hook using only
>Visual Basic. In addition, I have researched this and spent many hours in
>the past. For those who are interested, here's what I've concluded.

>First, a system-wide callback function must be located within a DLL. The
>reason for this is that the DLL must be mapped into the address space of any
>application that causes an event being hooked. SetWindowsHookEx will
>automatically (but maybe not immediately) map the DLL into the address space
>of running applications.

That is what I have observed - the mapping is 'on demand'

>Second, I'm not sure Visual Basic is the best language to use for writing a
>system-wide hook DLL. The reason is that Visual Basic has some large runtime
>requirements, which must all be mapped into the address space of other
>processes. But no one has given any reason why this prevents a VB DLL from
>working for this purpose.

>Third, I've heard a lot of times that VB DLLs cannot be used from
>system-wide hooks for the reason that VB DLLs are ActiveX DLLs, which expose
>a COM interface instead of just exporting flat functions. The fact is that
>these two items are not related. A very simple workaround is to install the
>hook from the same DLL that contains the hook using AddressOf. Problem
>solved! A DLL function does not need to be exported in order to be used as a
>callback.

>Finally, there is a complex problem that occurs with system-wide hooks. When
>an event occurs in another process, the callback (located in the DLL) is
>called. But it is running in a different address space. This means that any
>global variables (for example, the hook handle needed in order to pass the
>hook on to CallNextHookEx) are not available from the DLL.

Interestingly I observed that in Delphi CallNextHookEx is just calling
a null pointer in the 'cloned' DLLs
It is only the first hook that really does a CallNextHookEx

>In C, it is possible to declare a shared data segment that is available to
>all instances of a DLL. I don't understand all the mechanics and
>ramifications of doing this but it allows a DLL written in C to communicate
>back to the parent application. It is this reason, and not anything to do
>with how VB DLLs export functions, that I was unable to implement a
>system-wide hook using VB (so far).

The big problem that I found in Delphi was getting the Window Handle
of the thing that one sets up to listen in the host EXE

Actually I would use SendMessage HWND_BROADCAST and
RegisterWindowMessage to /ask/ the host EXE where it wants the
messages sent.

>I suspect there is a way around this. In the end, I doubt it would be very
>efficient. (I mean, one approach would be to read the shared variables from
>a disk file which would be a horrible drain on performance). But I'm not
>convinced there isn't a way to keep communication open between a DLL mapped
>into another process and its parent application. If anyone has any ideas,
>I'd love to hear them.

As you'll see in another thread, I've also been playing with this.

At present I am not sure whether the crashes were down to the mapping,
or down to the processing in the hook.

Windows definitely /tries/ to map in the DLL

Right now I'm fed up with running ScanDisk
- also when I go back to this it will be on a more robust machine


.

Relevant Pages

  • 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)
  • Re: Preventing a program from gaining the focus with a CBT hook
    ... Not for fun, just to keep a devtool from stealing focus as it ... Giving focus back to the losing window... ... Hooks being intrusive / DLL unload issues... ... It is easy to forget how utterly intrusive a system hook is. ...
    (microsoft.public.win32.programmer.kernel)
  • Re: Writing to a file within a Call Back Function
    ... the fact it is a CALLBACK function and EVERYTHING to do with the fact it is a hook ... within a DLL file that I created. ... SetWindowsHookEx(..) which MSDN says will set a hook on this function ... The most common way to handle this is to put a *window* handle in a shared data segment. ...
    (microsoft.public.vc.mfc)
  • Re: Using Visual Basic to Write System-Wide Hooks
    ... You don't need a standard DLL, ... As for storing the hook handle: memory mapped files would work well here. ... > I've spent about an hour looking into writing a system-wide hook using ... The reason is that Visual Basic has some large ...
    (microsoft.public.vb.winapi)
Quantcast