Mail Archives: djgpp-workers/1997/06/12/11:20:27
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).
- Raw text -