Date: Wed, 10 Sep 1997 21:05:22 -0400 (EDT)
Message-Id: <199709110105.VAA23739@delorie.com>
From: DJ Delorie <dj AT delorie DOT com>
To: djgpp-workers AT delorie DOT com
In-reply-to: <341541B4.2462@bo.dada.it> (message from Diego Zuccato on Tue, 09
	Sep 1997 14:31:48 +0200)
Subject: Re: fread slowstart
Precedence: bulk


> > Do we have any real reason for this?  It makes less DOS memory
> > available for subprocesses, which means less nested programs.  I
> Well, couldn't we have a 'locked' memory out the first MB and use it for
> all DJGPP programs that need a lot of arguments ?

It would be reasonable for the first stub loaded to allocate 64k or
more of dos memory, and store the DOS pointer somewhere (say, an
unused interrupt vector?).  Later stubs could locate that common DOS
buffer while still in real mode, allocate a 2k buffer for themselves,
and re-use the 64k shared buffer.  Since DOS programs run
sequentially, the only thing that will be in the shared buffer when a
program starts is its own environment and command line data, which it
would then copy into its own space as usual, freeing up the shared
buffer for its own I/O use.

I haven't analyzed the stub to see if it supports non-local transfer
buffers, though, but crt0 could be told to look for this as well, and
possibly resize the local TB to 2K and switch to the common one.

Heck, we've still got 32 bytes of space in the stub!  Plenty for this.