Date: Thu, 11 Sep 1997 16:54:48 +0300 (IDT)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
To: Diego Zuccato <dz AT bo DOT dada DOT it>
cc: DJ Delorie <dj AT delorie DOT com>, djgpp-workers AT delorie DOT com,
        Charles Sandmann <sandmann AT clio DOT rice DOT edu>
Subject: Re: fread slowstart
In-Reply-To: <3417DC6B.62CF@bo.dada.it>
Message-ID: <Pine.SUN.3.91.970911164928.13452B-100000@is>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Precedence: bulk


On Thu, 11 Sep 1997, Diego Zuccato wrote:

> 64K should be enough. (Uh, deja-vu :-) ) And it shouldn't too hard to
> modify startup code to save it to flat memory on startup and restore it
> when exiting main() or when a fatal error (Exception 13 or similars)
> occours.

DJ told me that the reason for enlarging the transfer buffer is to make 
larger command lines possible.  If that is the *only* reason, then the 
code to allow for this is already in the libc sources, it is just 
disabled by an #ifdef.  (It allocates a larger buffer when spawning a 
program, based on the actual length of the command line + the environment 
we pass to the child.)

I think this enabling that code is much easier than saving/restoring the 
global transfer buffer.

> > and store the DOS pointer somewhere (say, an unused interrupt
> > vector?).
> Maybe one of those 'reserved' for ROM BASIC ? :-)

Err, didn't Charles just say that the IDT is also private in DPMI 1.0?  
If so, doesn't this preclude using the interrupt table for storing the 
address?  Charles?

> bins), why not use 2 of those 32 bits for a 'release' magic number ?
> So, when installing a new package (eg make) that needs to call other
> executables, it could check that version number to be sure that no known
> troubles will arise.

More code bloat in the spawn functions, and more possible combinations 
when spawning child programs.  Sigh...