Date: Wed, 5 Feb 92 13:50:33 EST
From: DJ Delorie <dj AT ctron DOT com>
To: abentley%peruvian AT cs DOT utah DOT edu
Cc: abentley%peruvian AT cs DOT utah DOT edu, djgpp AT sun DOT soe DOT clarkson DOT edu,
        ressler AT cs DOT cornell DOT edu
Subject:  Bootstrapping djgpp
Status: O

>   So, I get the feeling that malloc() get's help from sbrk(), which keeps
>trak of what memory goes where.  Can I safely assume that sbrk() must make
>some kind of interface with one of the memmory managers? Like qemm?

The interface between the application and the OS (go32, in this case),
is sbrk() and only sbrk() (well, brk() also).  All sbrk does is change
the size of the one big linear block of memory that the OS calls
"data".  Hence, two expanations:

* In go32, sbrk() is passed back to real mode, where a table value is
modified to represent the new size of that block of memory.  As this
memory gets referenced, physical memory blocks are allocated and
mapped into the appropriate spot (paging as required to get free
pages).  References outside this region are trapped as page faults.

* In the application, normally malloc() maintains information about
the memory that is between the top of the data area and the mark set
by sbrk().  Information about malloc() is unseen by the OS, so various
versions of malloc can be made available.

DJ
dj AT ctron DOT com
Life is a banana.