Date: Wed, 11 Jun 1997 12:21:31 -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: <339EFABB.18E8@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:
> 
> > As to why IO is slower with a `64k' buffer, that's easy... 64k in 16
> > bits is 0 which is less than the 2k minimum, and so the transfer buffer
> > size winds up being 2k instead of 64k. (64k expressed in paragraphs
> > would be 1000h (4k if misinterpreted, which is better than 0))
> 
> It's worse than that - the transfer buffer ends up being like 2500 bytes,
> but not even on a 512 byte boundary.

Ugh... Hmm.. what are the consequences of the size ton being on a 512
byte boundary.

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

Actually, I have just made the required mods to implement the
re-definition of stubinfo_minkeep and the only problem I had when I
stubedited my program to 64k was and `Abort!' (probably in getchar(),
I'll have to look at it) but 64k-16 (0xfff0) worked just fine as far as
I could tell.

I'll post my patches in separately.

Bill
-- 
Leave others their otherness.