From: sandmann AT clio DOT rice DOT edu (Charles Sandmann)
Message-Id: <10206131827.AA23287@clio.rice.edu>
Subject: Re: DJGPP 2.04
To: djgpp-workers AT delorie DOT com
Date: Thu, 13 Jun 2002 13:27:22 -0500 (CDT)
In-Reply-To: <200206131629.g5DGT6t18248@envy.delorie.com> from "DJ Delorie" at Jun 13, 2002 12:29:06 PM
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

> > I think we should rationalize how we want to support all the
> > internationalization (instead of 1Mb of linked data in each image)
> > at the same time.
> 
> It would be great if we could use a DXE for that, if we can keep the
> exe's footprint small enough.

I have a prototype in my v2.04 cvs work area which allows both multiple
symbol exports and imports from the main image.  It analyzes the DXE
you propose to build, creates a transfer vector, and an interface
.o which looks like the library calls normally might.

It's completely backward compatible with the current DXE, the 
loader size is similar to the DXE footprint (a few hundred bytes).

The tools to keep transfer vectors consistent if you add something
doesn't work properly, there's a little problem with statics (like
errno) which you want to be external when linking.  The current 
libc has multiple procedures/declarations in some modules which
need to be split up.  There are C++ issues I haven't messed with.
I don't have libc working that way yet.

I haven't analyzed how many sharable modules there should be, or
what should be in them.