Hello !

It seems you're approaching the problem from a wrong point of view. If you
have a static library that contains the data, then you put this data into a
database, and have several dynamic-link libraries that use this data, then
why don't you use the database itself to share the data ?

The static library can be linked with multiple DLLs, but the instance of
data is not consistent (= is not the same) across DLLs linked with the
library. Each DLL will get a seperate copy of the data via the static
library. If the static library is not linked with the DLL, the DLL will not
have the data at all.

The best solution to this problem is to utilize the database. This means
that the static library contains routines that will automatically invoke a
connection to the database, download the necessary data, and place it into a
data structure usable by the DLL to which it's linked. The advantage is that
whenever the DLL is loaded, the data received by the static library is
dictated by the database. Thus, if the database access is updatable
(refreshable recordset), each DLL will constantly have an updated copy of
the data to work with. The downside of this solution is it's complexity:
database access and synchronization are not the easiest of tasks.

Other alternative solutions might exist, such as using the Clipboard, but
they're quite prone to errors caused by simultaneous execution of other
software (like a drawing program or Office program accessing the clipboard).

I hope this answers your question. If it does not, post a follow-up,
describing your problem in further detail. The original scenario post wasn't
very clear on what you were trying to do, and what available resources you
had to do it with.

-Antti Keskinen

Rich,

dll's have a seperate data segment, so each dll must contain all data it
needs. You'll see this quickly enough: your linker will complain about
'unreselved externals'.

If you really want to keep the data in memory, this could be a way:
- have a function in your main program that gives access to the data. This
function must be exported using the dllexport keyword
- let each dll find that function and use it (use GetProcAddress to find the
function pointer)

Jürgen Devlieghere

What about Win32 shared memory?  Seems like your dlls are behaving like out
of process dlls which are like separate applications except they run on the
same thread.  You could map a chunk of shared memory and stuff the data in
there.  Of course from what I've seen, shared memory is a fixed length so
you'd have to make a guess about the size of your segment.

Bill