From: "Charles Sandmann" <sandmann AT clio DOT rice DOT edu>
Newsgroups: comp.os.msdos.djgpp
Subject: Re: Locking memory.
Date: Wed,  4 Jun 1997 11:10:52
Organization: Aspen Technology, Inc.
Message-ID: <33954d3c.sandmann@clio.rice.edu>
References: <3 DOT 0 DOT 16 DOT 19970605110427 DOT 2d5f0684 AT hem1 DOT passagen DOT se>
Reply-To: sandmann AT clio DOT rice DOT edu
NNTP-Posting-Host: spica.dmccorp.com
Lines: 18
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp
Precedence: bulk

> I have 8MB of physical RAM installed on my computer (I know, it sux).
> I was just thinking then that the following programs would both fail to
> allocate that memory, but they don't... Why?

The memory declared is static, and is allocated in the stub when the image
is loaded.  When crt0 starts the image, it tries to lock it, and fails.
This is a feature (bug?) in the crt0 locking behavior - that it does not
treat a locking failure as fatal (and doesn't even have a status flag to
indicate failure).  There is no real workaround other than to avoid 
using this feature and transverse the memory handles allocated by sbrk and
lock them manually.

> Both program swap to disk hence using virtual memory. Why is that,
> shouldn't the crt0 flags prevent this? Isn't there a way to make sure that
> all memory is locked securely?

Manually do it and check the status, or use a DPMI provider which doesn't
allow virtual memory.