X-Authentication-Warning:	delorie.com: mailnull set sender to djgpp-workers-bounces using -f
From:	sandmann AT clio DOT rice DOT edu (Charles Sandmann)
Message-Id:	<10112211527.AA17994@clio.rice.edu>
Subject:	Re: RFC - Dynamic loading
To:	djgpp-workers AT delorie DOT com
Date:	Fri, 21 Dec 2001 09:27:21 -0600 (CST)
In-Reply-To:	<250B3114DA16D511B82C00E0094005F8055AC7ED@MSGWAW11> from "=?iso-8859-2?Q?Wojciech_Ga=B3=B1zka?=" at Dec 21, 2001 08:02:38 AM
X-Mailer:	ELM [version 2.5 PL2]
Mime-Version:	1.0
Reply-To:	djgpp-workers AT delorie DOT com
Errors-To:	nobody AT delorie DOT com
X-Mailing-List:	djgpp-workers AT delorie DOT com
X-Unsubscribes-To:	listserv AT delorie DOT com

> >> Can both a TSR and a non-TSR programs use the same copy of dynamic
> >> library at the same time ?
> >
> > Not really - there is no way to pass this information about it being
> > loaded.  Any writable variables would need their own instance and need
> > to be correctly relative to the start of the selector pointing to them.
> 
> I'm bit confused here
> So two programs running at the same time couldn't share the same copy of the
> library loaded (even in 'readonly' mode) ?

Today there is no communications center between loaded DJGPP applications,
so if the first one in memory loads it, the next one has no idea another
DJGPP image is even running.

Much of the DJGPP code isn't completely read-only clean, this would 
need to be fixed.

Almost all of our current library routines include static or
global variables which are specific to the caller.  Much of this should
be restructured to be an "init" type code instead of all the bss_count
stuff.

Yes, we could solve all these problems, break the loadable libraries
into "text" which was readonly and "bss/data" which were private.  But
the library in any image is typically only around 100K or less - so 
saving the multiple copies isn't a huge win for memory savings.

I don't think anyone has the time to re-write that much of the libc
code, but I might be wrong :-)

- Raw text -