Date: Wed, 11 Jun 1997 13:22:34 -0700
From: Bill Currie <billc AT blackmagic DOT tait DOT co DOT nz>
Subject: Re: Latest stub
To: Charles Sandmann <sandmann AT clio DOT rice DOT edu>
Cc: eliz AT is DOT elta DOT co DOT il, robert DOT hoehne AT mathematik DOT tu-chemnitz DOT de,
        djgpp-workers AT delorie DOT com
Reply-to: billc AT blackmagic DOT tait DOT co DOT nz
Message-id: <339F090A.161D@blackmagic.tait.co.nz>
Organization: Tait Electronics NZ
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7bit
References: <9706102144 DOT AA16090 AT clio DOT rice DOT edu>
Precedence: bulk

Charles Sandmann wrote:
> 
> The maximum should be enforced to be 63K (which is what was originally
> intended but seems to have got lost someplace).

After posting my patches, I found the cause of the problem I mentioned
it that post (the one with the aborts), and now I definitly agree with
Charles' solution, just fix stubedit to limit the maximum size to 63k.

The cause of the aborts was dos thinking the transfer buffer was 0 bytes
because the lengths to read/write were 0 due to the size being
truncated. 65k worked because it made the transfer buffer 1k in dos'
eyes.

Oh well, at least I tried.

Mind you, a transfer buffer larger than 64k could come in handy (if the
functions that use it are modified to handle such sizes).

Bill
-- 
Leave others their otherness.