From: sandmann AT clio DOT rice DOT edu (Charles Sandmann)
Message-Id: <9706151910.AA13381@clio.rice.edu>
Subject: Re: Latest stub
To: eliz AT is DOT elta DOT co DOT il (Eli Zaretskii)
Date: Sun, 15 Jun 1997 14:10:57 -0600 (CDT)
Cc: billc AT blackmagic DOT tait DOT co DOT nz, djgpp-workers AT delorie DOT com
In-Reply-To: <Pine.SUN.3.91.970615114436.14561C-100000@is> from "Eli Zaretskii" at Jun 15, 97 11:45:08 am
Content-Type: text
Precedence: bulk

> I don't think you can easily resize the transfer buffer.  

In many environments, this is probably true, since some piece of dos memory
may be allocated after the transfer buffer.  The ones which come to mind
are: 1) DPMI private memory area, 2) Unixy-sbrk DOS code 3) File handle 
resize block 4) CWSDPMI exec.  #1 and #4 will go high if possible; #4
could be pre-loaded or avoided with another DPMI.  #2 is a problem for 
environments using it (it probably should have been put high too...) and 
#3 can usually be avoided until later after a resize.

But maybe the easiest fix for all of this is a new field in the stub header -
extra DOS memory paragraphs to allocate.  This avoids the backward 
compatibility problems; the true transfer buffer stays 63.5K or less, 
the extra memory gets allocated contiguously for things like clipboard stuff.