Date:	Thu, 6 Mar 1997 13:09:21 +0200 (IST)
From:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
To:	djgpp AT delorie DOT com
Subject:	Re: __djgpp_base_address
In-Reply-To:	<199703051831.MAA141402@audumla.students.wisc.edu>
Message-ID:	<Pine.SUN.3.91.970306130859.20341D-100000@is>
MIME-Version:	1.0

On Wed, 5 Mar 1997, Scott Fleischman wrote:

> It also says this in the faq:
> 
> "Note that _CRT0_FLAG_LOCK_MEMORY is only recommended for small programs
> that run on a machine where enough physical memory is always available,
> because the startup code currently doesn't test if memory is indeed locked,
> and you can end up with unlocked, or partially unlocked memory, which will
> crash your program."
> 
> 
> The entire program (a game) is quite large, and the data may not in fact get
> locked.  There are command line options that allow the user to say whether
> or not the program should lock memory or not (defaulting to lock).  Who
> knows what computer will try to run the game.  If the program cannot lock
> the mem, it exits and displays an error message, stating that the program
> could be run with an option to disable mem locking (useful in Win95
> sometimes.)

If the problem that bugs you is that the _CRT0_FLAG_LOCK_MEMORY is not
tested by the startup code, then I suggest that you change the startup
code so it does ensure memory is locked.  The sources are available
and people who wrote it are still around and may be reached via the
DJGPP forum, in case you have any questions.

> IMHO anyway. After it grabs all available memory, the mem is locked and
> paged in, and not given back until the program finishes.

No, I don't think this will work like you intend.  Do I understand
correctly that you malloc all available physical memory and then lock
it?  If so, it might still fail to lock, because memory isn't paged in
until it is really accessed (at least with some DPMI hosts, CWSDPMI is
one such), and `malloc' doesn't access it.  If you need to allocate
the memory *and* page it in, you need to call `calloc', *then* lock
it.

Another problem with your approach is that the stack isn't locked, so
automatic variables aren't locked at all.

The _CRT0_FLAG_LOCK_MEMORY bit works at the `sbrk' level, where all
the DPMI memory allocations are handled, and it locks every page that
is actually allocated.  This is the correct method to use, AFAIK.  If
it is broken for your case, it's better to fix it than use unsafe
work-arounds.

- Raw text -