Board index » delphi » Creating class instances in DLL shared memory

Creating class instances in DLL shared memory

I've been browsing some of the shared memory
discussions here.  I have a similar issue.  What
I'd like to do is share access to a tree structure
among multiple applications. The elements of the
tree are currently (in a single app) instances of
class objects.   What I thought might be
interesting is to attempt to get Delphi to
actually construct my class instances in the
shared memory block so that when you load the DLL
you call a function that returns you a pointer to
the instance of a class member that is the root of
the tree. The instance would actually be in the
shared memory block.

The problem with this approach, as far as I know,
is that different applications don't get the same
base address for the shared memory block;
therefore internal object references won't work.

So has anyone tried this approach?  It sounds like
an interesting problem. I'll try and read follow
up postings, but email would be good too.  Please
response to thavi...@suss.com

Thanks

Tom Haviland

Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

 

Re:Creating class instances in DLL shared memory


Quote
thavi...@suss.com wrote:

: The problem with this approach, as far as I know,
: is that different applications don't get the same
: base address for the shared memory block;
: therefore internal object references won't work.
  If you change your DLLs base address so it's not relocated when loaded,
it should work. The problem is that named shared memory is static in size.
You just have a static buffer.

--
Mike Swaim, Avatar of Chaos: Disclaimer:I sometimes lie.
Home: sw...@c-com.net
Alum: sw...@alumni.rice.edu  Quote: "Boingie"^4 Y,W&D

Re:Creating class instances in DLL shared memory


On Fri, 18 Jun 1999 17:53:37 GMT, Mike Swaim <sw...@gemini.c-com.net>
wrote:

Quote
>thavi...@suss.com wrote:
>: The problem with this approach, as far as I know,
>: is that different applications don't get the same
>: base address for the shared memory block;
>: therefore internal object references won't work.
>  If you change your DLLs base address so it's not relocated when loaded,
>it should work.

But there is no way to guarantee that the DLL will not be relocated.

The only guaranteed solution is to use double indirection. Either each
application uses a lookup table, or "pointers" are actually offsets from
the start of the shared file. The latter approach is probably the
simplest, and isn't hard to do.
--
Ray Lischner (http://www.tempest-sw.com/)
author of Delphi in a Nutshell

Re:Creating class instances in DLL shared memory


In article <3778ff3e.1827059...@news.proaxis.com>,
  lisch.at.tempest-sw....@nojunkmail.com (Ray Lischner) wrote:

Quote
> On Fri, 18 Jun 1999 17:53:37 GMT, Mike Swaim <sw...@gemini.c-com.net>
> wrote:

> >thavi...@suss.com wrote:
> >: The problem with this approach, as far as I know,
> >: is that different applications don't get the same
> >: base address for the shared memory block;
> >: therefore internal object references won't work.
> >  If you change your DLLs base address so it's not relocated when
loaded,
> >it should work.

> But there is no way to guarantee that the DLL will not be relocated.

> The only guaranteed solution is to use double indirection. Either each
> application uses a lookup table, or "pointers" are actually offsets
from
> the start of the shared file. The latter approach is probably the
> simplest, and isn't hard to do.

So I guess what I would have to do is to make each internal class
reference a property that fixes up the address based on some sort of
global offset parameter...Not totally transparent, but closer that what
I had before.

Thanks for the feedback

Tom Haviland (thavi...@suss.com)

Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

Other Threads