🚀 go-pugleaf

In article <1991Oct28.175353.27604@src.honeywell.com>, bergstro@src.honeywell.com (Pete Bergstrom) writes:
> Allen Gordon (gordon@news.colorado.edu) writes:
> >On version 1.04 of the djgpp port of gcc, I have run a small program which
> >continually allocates memory with malloc, until it returns a null pointer.
> >However, it never seems to to this.  For example, malloc (50*1024*1024)
> >returns a non-null pointer.

malloc() will never return a NULL in djgpp, because it never knows
when you're about to run out of memory.  What happens if it reports
that you're out of memory just before you remove a big file and make
more virtual memory available?  Even if you allocate more memory than
is available, it doesn't actually get around to needing it until you
access that memory.  You can malloc 200Mb of memory and still run, as
long as you don't try to use that memory.

> >  Furthermore,
> >the 9+ MB of extended memory which was available prior to running the
> >program is not available after, as determined by a memory checking program.
> >The memory manager is himem.sys.

This is himem.sys at work.  It doesn't actually allocate extended
memory for XMS programs until the first one asks for it.  At that
point, the memory is allocated, DOS shows it as in use, and it's
available through himem.sys as XMS memory only.

> Doesn't the DOS extender give you up to 512 MB (256 MB RAM and 256 MB
> disk) of virtual memory?  If so (or in the ballpark for numbers),
> it sounds like a conflict with the extender and your DOS.

Close.  Up to 128M of physical RAM, plus up to 128M of disk space, combine
for up to 256M of virtual address space.

Note: 1.05 is out - it supports VCPI as well as XMS.

DJ
dj@ctron.com
Life is a banana.