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 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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 Precedence: bulk > >> 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 :-)