Date: Thu, 12 Jun 1997 18:16:27 +0300 (IDT) From: Eli Zaretskii To: Bill Currie cc: Charles Sandmann , robert DOT hoehne AT mathematik DOT tu-chemnitz DOT de, djgpp-workers AT delorie DOT com Subject: Re: Latest stub In-Reply-To: <339EFABB.18E8@blackmagic.tait.co.nz> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk On Wed, 11 Jun 1997, Bill Currie wrote: > Actually it ought to be 63.5K - the maximum sector aligned size. Since > DOS can't handle anything >= 64K, and making the size not a 512 multiple I might be missing something here, but I don't understand why everybody is talking about numbers like 63.5K or 0xfff0. These are close, but not exactly what I see in stub.asm. What I see is this: The stub allocates the transfer buffer by resizing the PSP block. Since the PSP needs to be left intact, the stub adds the size of PSP to the requested size of transfer buffer, then rounds it down to the nearest paragraph (it shifts right 4 bits), and that's the size that is passed to the DOS Resize Memory Block function. If the above is correct, then the largest possible request is FEFFh (which is FFFFh - 100h, the 100h being the size of the PSP block). This causes the actual transfer buffer be FEF0h, which is 65254 in decimal. I actually tested this by stubediting a program to different values. Passing values above 65279 (FEFFh) to stubedit always either crashes the program, wedges the system or causes QEMM to barf with Exception 13 but values below that mark all work. Charles, am I missing something here? > Our stubedit proc should only > write values in the 0x0 to 0xffff range, ever. If the description above is correct, the maximum number written by `stubedit' should be 0xfeff, not 0xffff. Also, IMHO, if it's not too painful, we shouldn't limit the transfer buffer size to 64K. Charles' points (about DOS I/O limitations) are well-taken, but nonetheless people should be able to allocate any size DOS will let them have. At least in the long run (like in the next DJGPP release).