Date: Thu, 12 Jun 1997 09:27:29 -0700 From: Bill Currie Subject: Re: more patches for minkeep issures To: Charles Sandmann Cc: DJ Delorie , 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 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit References: <9706111459 DOT AA14837 AT clio DOT rice DOT edu> Precedence: bulk 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.