Shared Data Segment

Shared Data Segment

Post by Jonathan W » Fri, 03 Jun 2005 05:09:40

I'm researching how feasible it is to write a system-wide hook in Visual
Basic 6.

Basically, everything seems to work except that DLLs mapped into the
addresses space of other processes cannot access variables needed to contact
the parent app. (Please don't tell me that this can't be done because VB
DLLs are ActiveX and not "regular"--I don't buy it.)

In C, I could declare a shared data segment that would allow the DLL to
access a few, select, global variables. VB doesn't give me this kind of

I'm just wondering if anyone knows a trick to duplicate the shared-data
segment by calling APIs or something. Memory-mapped files have been
considered but don't seem efficient enough for a hook.

Thanks for any tips.

Jonathan Wood
Available for consulting:

Shared Data Segment

Post by Jonathan W » Sat, 04 Jun 2005 02:42:17

Thanks, but we're trying to determine if something can be done using only

We're looking at memory-mapped files as one possible approach.

Jonathan Wood
Available for consulting:



Shared Data Segment

Post by Craig Kell » Sat, 04 Jun 2005 06:32:07


A few people at one time had worked on intercepting the compiler and linker
that VB uses (c2 and link in the VB install directory). I don't remember
who that was, but if you can google it that might help. Regardless, those
tools are modified versions of the VC6 compiler so if you can play with
invocation and command line parameters you could set up the section

Also, a VB DLL maintains module-level variables in standard modules: you
could wrap these in lazy functions that check for init and only use the
memory-mapped file when necessary. You might to profile the memory mapped
file: I would think that synchronizing access might create more overhead
than read/write to the mapped file.

My opinion is that your problem won't necessarily be that VB DLL's are
ActiveX, but that VB doesn't play well with threads (and you'll need to
assume that CoInitialize hasn't been called on the thread that your VB code
is executing on).

Why not create a C++ hook DLL that instantiates a VB class and calls it for
hook stuff? I'm not saying that you shouldn't do what you're talking about
(there's a lot of info out there about the various techniques available for
hacking threading in VB6): it just seems like doing some shim work in C++
would be a lot less effort... of course, the effort might be the point :)

Good luck!


Shared Data Segment

Post by Jonathan W » Sat, 04 Jun 2005 15:04:41



That's an interesting thought. But if it was done as a compiler/linker flag,
I assume you'd have to specify that the entire data segment was shared. I'm
not certain what the ramifications of that might be.


Yeah, what I seem to be finding is that the hook "breaks" as soon as Windows
tries to map the DLL into another process. For example, I installed a
keyboard hook (not low-level) and it works when the app is active. It also
works if I activate another app and then go back to the original app. But if
I activate another app and type some keys, then the hook stops getting
called, even if I reactivate the original app.

I'm thinking it may have something to do with either initializing the VB
runtimes, or that the VB runtimes just don't like being mapped this way.


Yeah, kind of. Some folks have made some assertions about VB and I'd like to
prove them. Unfortunately, there may be issues unrelated to those in
contention that prevent me from doing so.


Jonathan Wood
Available for consulting:

Shared Data Segment

Post by Gary Chans » Sat, 04 Jun 2005 15:37:26

Why should a memory mapped file be inefficient? Ultimately, all a shared
segment is, is a memory mapped file using the page file instead of a file
(which you can also do).

-GJC [MS Windows SDK MVP]
-Software Consultant (Embedded systems and Real Time Controls)

Shared Data Segment

Post by Jonathan W » Sun, 05 Jun 2005 00:36:13



I don't know that they are inefficient. I know that they need to be opened,
which normal memory doesn't require. But I don't know all that much abouty
how either one works internally.

Jonathan Wood
Available for consulting:

Shared Data Segment

Post by Craig Kell » Sun, 05 Jun 2005 08:21:06


Well, that could get goofy :) I took a quick look at the command line
options for the compiler and linker for VC6 and the only thing I saw was the
/SECTION parameter to the linker. So, if you could get particular variables
into their own section, you could add a single parameter to the linker
invocation. Now, how you do that is beyond me: I've never done that with
anything other than #pragma. Oh, well.

This makes sense: I know that in a VB DLL with a Sub Main it doesn't get
called until the first object is created... You can call LoadLibrary and
FreeLibrary on it all day long but that won't trigger a call to Main.

Ah: I know the feeling. Although C++ is my favorite language, I've done a
lot of (strange) VB 6 around here just prove that it could be done (because
the "it's a toy language" thing really irks me).

<unrelated rant>

I remember back before .Net was announced and hearing that the new VB would
have Option Strict, exception handling, native multi-threading, and
implementation inheritance. If not for an annoying personal lack of
coordination I would have done backflips. I'm not bashing .Net, but I wish
they had actually done a VB 6.something with just those features added
(well, that and direct access to the compiler/linker tool chain).

</unrelated rant>


Shared Data Segment

Post by Jonathan W » Mon, 06 Jun 2005 07:53:07



VB makes some things very easy. For the other things, you're often out of

Sounds about right.


C++ is definitely may favorite language as well. But writing an application
in VB is generally many, many times faster.


Right. VB.NET is not nearly as accessible as VB is. VB.NET is way more
complex. I'm not bashing VB.NET either, but it's not VB, and that's kind of
a shame.


Jonathan Wood
Available for consulting: