Date: Thu, 12 Jun 1997 20:47:45 +0300 (IDT)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
To: Vik Heyndrickx <Vik DOT Heyndrickx AT rug DOT ac DOT be>
cc: djgpp-workers AT delorie DOT com
Subject: Re: Latest stub
In-Reply-To: <33A0270F.B00@rug.ac.be>
Message-ID: <Pine.SUN.3.91.970612204046.9931C-100000@is>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Precedence: bulk


On Thu, 12 Jun 1997, Vik Heyndrickx wrote:

> But why would people want to allocate more than 64K. As CS says DOS
> can't transfer more than 64Kb at a time. And I don't know of any BIOS
> calls either that use this amount of sparse memory.

You can never know what the ingenious might invent one day.  The transfer 
buffer isn't only for I/O, it's for any communications with real-mode 
software.  It is bad for basic software such as libc to have limitations 
that can be reasonably lifted.

I even have an example for you: Emacs support of the Windows clipboard. 
The clipboard is not limited to 64K, you can theoretically move up to 1MB
of data (practically it is limited by 640K).  Right now, Emacs allocates
its own DOS buffer if the amount of data is larger than the transfer
buffer size, then deallocates it after the data was moved, but that makes
the support code much more involved (and also crashes Emacs on NT, btw). 

But I agree with Charles on this one: the implications of changing the 
stubinfo meaning is probably too painful at this point.