delorie.com/archives/browse.cgi   search  
Mail Archives: cygwin-developers/1999/06/27/23:12:18

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 -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019