www.delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/1996/12/18/23:42:51

From: "John M. Aldrich" <fighteer AT cs DOT com>
Newsgroups: comp.os.msdos.djgpp
Subject: Re: windows <-> cwsdpmi
Date: Wed, 18 Dec 1996 19:18:06 -0800
Organization: Two pounds of chaos and a pinch of salt
Lines: 59
Message-ID: <32B8B3EE.7AEC@cs.com>
References: <Pine DOT SUN DOT 3 DOT 91 DOT 961216173308 DOT 18715I-100000 AT is> <32B8766B DOT 318B AT nlc DOT net DOT au>
Reply-To: fighteer AT cs DOT com
NNTP-Posting-Host: ppp102.cs.com
Mime-Version: 1.0
To: shaman AT nlc DOT net DOT au
DJ-Gateway: from newsgroup comp.os.msdos.djgpp

Lord Shaman wrote:
> 
[snip]
>         Interestingly, I've had similar problems. I wrote a program which
> handles huge amounts of maths tables. (13 megs) I thought that it would
> fit considering I've got 16M and dos only uses 600k or so. I tried to
> allocate the memory using "new" in 1 meg blocks, but I could never
> allocate more than 8 megs! It just said it ran out of memory and crashed
> to dos. The code at the time was simple, basically all it did was
> allocate the memory and nothing else.
> 
>         I tried every bootup (except windows, because I really didn't expect
> 13M to be free out of 16M under 95), but nothing worked. Odd.
> 
>         If this guy has the same problem, and he is allocated 8 megs on a 16
> meg system, then he'd run out of memory because his program and DOS
> might take up enough to "go over the edge". Maybe cwsdpmi detects the
> "out of memory" and starts using virtual memory. My program didn't do
> that because I use cwsdpr0.

The malloc() used by DJGPP rounds the size of allocated memory blocks to
the next higher power of 2.  So, allocating 300 bytes gets you 512;
allocating 1500 bytes gets you 2048, and allocating 8 MB + 1 gives you
16 MB.  This, unfortunately, is a speed optimization of the GNU C
compiler, so it can't easily be changed.  Normally, the malloc()
rounding isn't a problem when running in DPMI, because the host will use
virtual memory if it runs out of physical, and even though malloc()
grabs a 16 MB chunk, only the amount you requested will actually be used
or swapped.  Virtual memory is the greatest of boons to 32-bit
programmers.  :)

You have a couple of options here:

First, make your code grab memory in smaller blocks, to avoid rounding
problems.  Getting 13 1 MB blocks instead of 1 13 MB block will work,
but this of course depends on your code.

Second, if you do not intend to realloc() or free() the memory you use,
call sbrk() directly with the size of memory you want.  This bypasses
malloc() and its size rounding, but the memory _cannot_ be freed by your
program.

Third, allow your program to use virtual memory, and lock any code or
data that must not be swapped out.  Look up _g032_dpmi_lock_code() and
_go32_dpmi_lock_data() for details on how to do this.

BTW, your program would have worked in Windows, assuming it had
allocated sufficient DPMI memory to DOS programs.  If not, use the PIF
Editor and edit _default.pif and dosprmpt.pif to set maximum memory
sizes to -1 (win31), or set DPMI memory to 64 MB in the Control Panel
(win95).

-- 
---------------------------------------------------------------------
| John M. Aldrich, aka Fighteer I  |        fighteer AT cs DOT com         |
| Call me for your free AOL disk!  |   http://www.cs.com/fighteer   |
|  Chain letters, work-at-home schemes, free long distance, etc.,   |
|    are ILLEGAL!  Keep the Internet litter-free... don't SPAM.     |
---------------------------------------------------------------------

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019