Date: Wed, 11 Jun 1997 09:03:41 -0700 From: Bill Currie Subject: Re: Latest stub To: Eli Zaretskii Cc: Robert Hoehne , DJGPP workers Reply-to: billc AT blackmagic DOT tait DOT co DOT nz Message-id: <339ECC5D.3315@blackmagic.tait.co.nz> Organization: Tait Electronics NZ MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit References: Precedence: bulk Eli Zaretskii wrote: > > On Tue, 10 Jun 1997, Bill Currie wrote: > > > One that I know of is you can't declare a 64k transfer buffer as that > > needs 17 bits and only 16 are provided in the transfer buffer size > > variable (this cause my programs to crash as well as all the djgpp > > programs I'd stubedited to 64k). > > Where in the stub does this limitation come from, and how would you > suggest to correct it? > > I admit I've never heard of this limitation before. Did you post > something about it to the news group? It is important that people > know about such problems. For example, a few people asked me why > stubediting their programs to 64KB transfer buffer actuallt made them > slower in I/O, and I couldn't explain that. This is the cause: stubinfo_minkeep: ; unsigned short .dw 16384 ; amount of automatic real-mode buffer and in stubedit, its treated as a long. Either stubinfo_minkeep should be changed to a dd (which is probably imposible as it would break all backwards compatability) or intead of bytes, it should be in paragraphs, which makes more sense anyway (less code to convert the values). This may also cause problems with backwards compatability, but not as serious IMHO. 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)) Bill -- Leave others their otherness.