www.delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/1996/04/27/20:09:39

From: Sengan DOT Short AT durham DOT ac DOT uk
Message-Id: <11201.9604272355@bylands.dur.ac.uk>
Subject: Re: ELF?
To: elf AT netcom DOT com (Marc Singer)
Date: Sun, 28 Apr 1996 00:55:05 +0100 (BST)
Cc: djgpp AT delorie DOT com
In-Reply-To: <199604272156.OAA16743@netcom6.netcom.com> from "Marc Singer" at Apr 27, 96 02:56:04 pm
Mime-Version: 1.0

> 
> > 
> > > >If somaday djgpp will use ELF, will then it use shared libraries?
> > > 
> > >   Well, what's the use of shared libraries in a non-multitasking environment?
> > 
> > 	1. Less used disk space.
> > 	2. Updating the library updates ALL programs that use it.
> > 	3. Dynamic binding "objects."
> > 
> > In number 3 I mean, you could make (for example) a general compression
> > library interface and just make a new library for each compression type
> > (LZ, Huffman, etc) and let the program (or the user) decide which one to
> > use based on which ones are available.  You could also do this with
> > image loaders.  Just make a new DLL for each format.  This was done on
> > the Amiga (and is the basis of OpenDOC) and is VERY powerful.  It allows
> > your program to be updated long after you quit updating it. :)
> 
> I agree that the idea is very romantic.  While I have found them to be
> useful in principle, teh reality for DOS is that we don't have an
> adequate OS infrastructure to make them interesting.  On Linux, shared
> LIBC is a BIG win because nearly every program uses it.  DOS, being
> inherently a real-time OS, does not run more than one process at a
> time, so we're left with only one benefit: dynamic linking.  Nice, but
> it isn't stopping anyone I know from developing the software they want
> to write.

True, but would it not reduce swapping? For instance, if one works with
gnu c++, rcs, make, gdb/fdsb/edebug32, emacs/vim or RHIDE and info, one uses
many djgpp programs.  If there were one library, all these programs would be
smaller, and swapping would be less intensive if there were some means of
ensuring the lib stays in memory (I don't know the limitations of DPMI... but
if memory can be locked for interrupt services). Since disk access is slow
(swapping, loading in executables, and so on), it seems a good idea to reduce
it. The major issue seems to me whether this is worth the effort put into it,
which depends on how difficult it is. For instance why did DJ and friends
decide on DXEs for the fp emulator, if lib sharing would have been as easy to
implement?

Sengan

- Raw text -


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