From: "Charles Sandmann" <sandmann AT clio DOT rice DOT edu>
Newsgroups: comp.os.msdos.djgpp
Subject: Re: sbrk oddity
Date: Tue, 11 Nov 1997 20:47:30
Organization: Aspen Technology, Inc.
Lines: 37
Message-ID: <3468c462.sandmann@clio.rice.edu>
References: <647ne3$ecb$1 AT news DOT ox DOT ac DOT uk> <34674c48 DOT sandmann AT clio DOT rice DOT edu
Reply-To: sandmann AT clio DOT rice DOT edu
NNTP-Posting-Host: dmcap2.dmccorp.com
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp
Precedence: bulk

> Thanks very much for the advice.  Does the latter point here mean that
> even using the default non-move sbrk I can just save the areas shown
> in the zone list, or is it just not practical to do this sort of thing
> with this sbrk system?  

Yes, they could be saved, but they are essentially impossible to handle
in an efficient manner by a debugger, for example, since you don't have
control to put them back in the same place in memory.  Very special tools,
and a special core format, would be required to handle it.

> I've heard a lot of people abusing things like
> __djgpp_nearptr_enable() in ways which would break, AFAIK, under the
> unixy sbrk; it would be nice to have this working under either sbrk.
> Nothing to lose sleep over, though; it's their code that's wrong.

Since the DPMI provider may change the address of a memory block on 
resize, there is no workaround that near pointers may break with unixy 
sbrk.  That's why there are two algorithms.  The programmer chooses 
which he wants.  A true unix program is probably happier with unixy sbrk
(since it doesn't want to lock memory or use near pointers) and DOS
hackers writing interrupt routines or architecture specific hacks to
directly access memory will not expect a contiguous sbrk() behavior.
The built-in malloc() works with either.

The non-move sbrk() was chosen as default after lots of anguish, mostly
because of bugs in the resize block of some DPMI providers, which would
limit virtual memory use with the unixy sbrk to 1/2 the physical memory
size ... (ie worse than the default W95 behavior...)

If you start with the unixy sbrk() you can actually switch on the fly
during program execution to the non-contig sbrk() algorithm.  One planned
experiment was to start all programs with unixy sbrk() and have them
swap on the fly if they wanted to lock memory, use far pointers, or 
got a dpmi memory block resize failure.  This is probably what should
have been done - but I didn't have time to do, test, and document it.
And you think things are complicated now - imagine swapping arbitarily
in the middle ...