From:	sandmann AT clio DOT rice DOT edu (Charles Sandmann)
Message-Id:	<10108011646.AA15315@clio.rice.edu>
Subject:	Windows 2000/sbrk
To:	acottrel AT ihug DOT com DOT au (Andrew Cottrell)
Date:	Wed, 1 Aug 2001 11:46:50 -0500 (CDT)
Cc:	eliz AT is DOT elta DOT co DOT il (Eli Zaretskii), djgpp-workers AT delorie DOT com
In-Reply-To:	<000901c11a76$14551d30$0a02a8c0@acceleron> from "Andrew Cottrell" at Aug 01, 2001 08:38:17 PM
X-Mailer:	ELM [version 2.5 PL2]
Mime-Version:	1.0
Reply-To:	djgpp-workers AT delorie DOT com
Errors-To:	nobody AT delorie DOT com
X-Mailing-List:	djgpp-workers AT delorie DOT com
X-Unsubscribes-To:	listserv AT delorie DOT com

> I think you are correct in spotting Make does not crash with the Unixy sbrk
> flag set. Let me run a series of tests again with the following combination,
> this may take a few days:
> 1) Make & GCC - no Unixy SBRK, no malloc_debug
> 2) Make & GCC - no Unixy SBRK, malloc_debug set to 4 for both
> 3) Make & GCC - Unixy SBRK set, no malloc_debug
> 4) Make & GCC - Unixy SBRK set, malloc_debug set to 4 for make only
> 5) Make & GCC - Unixy SBRK set, malloc_debug set to 4 for both make and GCC
> Are there any other combinatios that would help give more info?
> 
> This may take me a three or four days to complete as I need build GCC and
> Make 4 times to get the combinations required. I will double check the
> correct exe's are installed before before running the tests.

After looking at my notes, I remember bad things about the Unixy sbrk.
 1) Requires extra DOS memory for helper function
 2) Many DPMI providers don't allow you to allocate as much memory with resize
 3) Locking issues, near pointer issues

Since unixy sbrk() requires the dos memory helper - you can at any time
switch from unixy to non-move on the fly, but not the other way around.

Since we want the same images to run out of the box on NT/Win 2000, it's 
obvious that we need to fix sbrk() to just always work.  I'm a bit time
constrained, but I did look at crt0.S enough to hate myself (it's worse
than I remembered, I was in denial).

My first thought is to add a new flag for the non-move sbrk() which will
prevent memory wrapped dpmi blocks from being used.  This flag would always
be forced on if running on NT.  It would also be useful option on Win9X 
systems to prevent weird selectors that span the entire memory space. 
This is probably easier to implement, but since we sbrk() the stack before 
calling any setup code we would either leave a window of breakage or would
need to move dos version queries to crt0 :-P

My next thought was to check the limit we set, and if it didn't "stick" to
toss the block and try again.  Looking at how each bit is carefully crafted
in crt0 makes be believe this will cause some hair loss.

In any case this is something we need soon so everyone doesn't have to 
rebuild everything for testing.  Thoughts? 

- Raw text -