From:	sandmann AT clio DOT rice DOT edu (Charles Sandmann)
Message-Id:	<9706121627.AA17535@clio.rice.edu>
Subject:	Re: Latest stub
To:	eliz AT is DOT elta DOT co DOT il (Eli Zaretskii)
Date:	Thu, 12 Jun 1997 11:27:13 -0600 (CDT)
Cc:	billc AT blackmagic DOT tait DOT co DOT nz, robert DOT hoehne AT mathematik DOT tu-chemnitz DOT de,
	djgpp-workers AT delorie DOT com
In-Reply-To:	<Pine.SUN.3.91.970612181518.9257T-100000@is> from "Eli Zaretskii" at Jun 12, 97 06:16:27 pm

> 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

You are completely correct.

> If the description above is correct, the maximum number written by
> `stubedit' should be 0xfeff, not 0xffff.

Probably so - but due to the round-down issues, sector alignment, etc
I would say limit it at 0xfe00, 63.5K, and leave it at that.

> 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).

Since re-defining this requires a change in the meaning of a stub field,
this has some ugly compatibility issues (like running a V2.01 stubedit
on a V2.02? stub).   We don't check version id now, so you will generate
problems in the future.  Problems with cross version debugging.  This
will be a mess - and I don't see any reason for it at all.  If an 
application needs a bigger DOS memory buffer, it can allocate one (or
even resize the transfer buffer once running.  Since this is a rarely
needed (if ever?) feature, and there are multiple workarounds, why break
compatibility for it?

- Raw text -