Mailing-List:	contact cygwin-developers-help AT sourceware DOT cygnus DOT com; run by ezmlm
Sender:	cygwin-developers-owner AT sourceware DOT cygnus DOT com
Delivered-To:	mailing list cygwin-developers AT sourceware DOT cygnus DOT com
Date:	Sun, 27 Jun 1999 23:12:03 -0400
Message-Id:	<199906280312.XAA00996@envy.delorie.com>
From:	DJ Delorie <dj AT delorie DOT com>
To:	cgf AT cygnus DOT com
CC:	khan AT xraylith DOT wisc DOT EDU, cygwin-developers AT sourceware DOT cygnus DOT com
In-reply-to:	<19990627231051.B8904@cygnus.com> (message from Chris Faylor on
	Sun, 27 Jun 1999 23:10:51 -0400)
Subject:	Re: running two independent Cygwin DLLs?
References:	<199906280258 DOT VAA23658 AT mercury DOT xraylith DOT wisc DOT edu> <199906280305 DOT XAA00938 AT envy DOT delorie DOT com> <19990627231051 DOT B8904 AT cygnus DOT com>

> This shouldn't be an issue should it?  There's only going to be one
> DLL linked into the process address space at any time.

That depends on how Windows maps DLLs.  I'm fearful that two
applications that both import from "cygwin1.dll" will share a dll,
even if the search path would result in different dlls being found.

If you're debugging a dll yet relying on a stock dll at the same time,
it's prudent to give them separate names.

> Actually, all you have to do is "configure --enable-debugging".  That
> will cause the shared memory regions to be named based on the date/time.

What about the mount tables, though?  Depending on *what* you're
experimenting with, you may still need to isolate other parts of the
dll's shared resources.

- Raw text -