Message-ID: <3418FD68.34BA@bo.dada.it>
Date: Fri, 12 Sep 1997 10:29:28 +0200
From: Diego Zuccato <dz AT bo DOT dada DOT it>
Organization: CyberSpace Software Labs BBS
MIME-Version: 1.0
To: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
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
References: <Pine DOT SUN DOT 3 DOT 91 DOT 970911164928 DOT 13452B-100000 AT is>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Precedence: bulk

Eli Zaretskii wrote:

> 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.)
Well, then why not to allocate a big tb (64K) and then forget
enlarge/shrink functions ? Just a bit of 'slack' space...

> I think this enabling that code is much easier than saving/restoring the
> global transfer buffer.
Well, having a constant-size tb is even easier :-)

> 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?
Well, in my previous post to DJ, I suggested that a tb could be
identified by its size and an ID string at the beginning of an allocated
memory block, so there's no need to store its pointer (well, DOS stores
it for us :-) ).

> More code bloat in the spawn functions, and more possible combinations
> when spawning child programs.  Sigh...
Uh, no ! Not at runtime. Just an helper. Like a setup-checker. DJ told
that a version string is already present in the stub, so there's no need
to add another.