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

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...

- Raw text -