Date:	Thu, 12 Jun 1997 09:27:29 -0700
From:	Bill Currie <billc AT blackmagic DOT tait DOT co DOT nz>
Subject:	Re: more patches for minkeep issures
To:	Charles Sandmann <sandmann AT clio DOT rice DOT edu>
Cc:	DJ Delorie <dj AT delorie DOT com>, djgpp-workers AT delorie DOT com
Reply-to:	billc AT blackmagic DOT tait DOT co DOT nz
Message-id:	<33A02371.45B8@blackmagic.tait.co.nz>
Organization:	Tait Electronics NZ
MIME-version:	1.0
References:	<9706111459 DOT AA14837 AT clio DOT rice DOT edu>

DJ Delorie wrote:
> > That's a lot of changes just to get an extra 512 bytes of buffer.
> > Can't we just change the stub so that if the value is zero, we use
> > 63.5k ?  That's the least amount of change to solve the problem, and
> > it doesn't have backwards compatibility issues.

I agree, it's just that I started on this track and I figured I might as 
well complete it so you had a complete modification to veto or not.

Charles Sandmann wrote:
> 
> 
> Since this is supposed to be the "transfer buffer", it doesn't make sense
> for it to be over 64K anyway.  Applications needing more than this can
> either allocate more dos memory or do a DOS resize call.  Adding
> complications for what is supposed to be a simple use is asking for
> trouble.

Things did start to get out of hand.

> DOS can't handle a 64K I/O request - it's 0xffff maximum, and the
> transfer buffer should be the same.  The stub assumes it is always
> paragraph sized (low nibble zero).  Our stubedit proc should only
> write values in the 0x0 to 0xffff range, ever.  Now, should the stub
> add a paragraph to handle the round up (so instead of 0xfff0 maximum
> you could actually get 0xffff) or should we just enforce low nibble zero
> in stubedit?  (The real thing will always be paragraph sized).

I think that stubedit should max minkeep out at 63.5k and either
paragraph 
or sector align the size for smaller buffers.

> 
> BTW, it looks like our "resize" computation is an infinite loop?

I don't THINK so, as resize returns the largest available memory in bx, 
which then gets used to recompute the tb size.  if the tb size winds up 
the same as the program size, the reallocation will always succeed.

> 
> Clearing the low nibble, and maximizing the value at 0xfff0
> in the stubedit code will solve 99.9% of the problems here without changing
> the stub or breaking compatibility ...

Yes, fixing stubedit is definity the best solution and my patches were
at least 
close. The biggest bug in stubedit is treating minkeep as a long rather
than a short.

Sorry about wasing bandwidth on useless(?) patches, but at least my
exercise has 
shown up most of the areas that can cause problems when the stubinfo
changes, so 
I guess it wasn't a complete waste of time.

Bill
-- 
Leave others their otherness.

- Raw text -