From: sandmann AT clio DOT rice DOT edu (Charles Sandmann)
Message-Id: <10212200707.AA24651@clio.rice.edu>
Subject: LibC loaded Dynamically
To: djgpp-workers AT delorie DOT com (DJGPP developers)
Date: Fri, 20 Dec 2002 01:07:35 -0600 (CST)
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

I have a simple prototype which loads libc.dxe; "hello world" is 
about 7Kb in size.  It doesn't search for the DXE (assumes libc.dxe
in current directory) so production image would be larger.

I had to write mini-versions of _open, _read and _close since our 
current versions touch way too many things.  There is a hook I
added to crt0 before setting up the frame stuff which calls it.
There are still some variable addressing issues to be resolved; 
but I don't see any issues that would stop from finishing it.

Now for the hard question - what do we do with this?  It would
certainly make fixing bugs in libc much easier - upgrade libc.dxe
and all images get the fix.  It would knock 50-100K off each 
image in the distribution.  FAQ questions on image size go away;
replaced by FAQ questions on my image doesn't run on a different
machine ....  It makes loading other DXEs easier since you can
end up with a registry of entry points and names for run-time
resolution.

But we would need to support both static and dynamic link libraries,
and what about libm, libgcc, libiconv?  It's a huge shift in
development and philosophy.  It could make libc updates much more
difficult to maintain backward compatibility.

For small memory machines, loading a libc.dxe in each memory space
would add 500K or so overhead to each activation (pageable, but
slower).  DXEs can't be UPXed so you lose a bit on disk cache
efficiency (loading 500K vs maybe 50K-compressed of libc in each
image).

So it's an interesting exercise, but I'm not sure it's useful yet ,,,