Message-Id:	<199703051831.MAA141402@audumla.students.wisc.edu>
Mime-Version:	1.0
Date:	Wed, 05 Mar 1997 12:32:11 -0600
To:	djgpp AT delorie DOT com
From:	Scott Fleischman <safleisc AT students DOT wisc DOT edu>
Subject:	Re: __djgpp_base_address

>
>On Tue, 4 Mar 1997, Scott Fleischman wrote:
>
>> Thank you for your reply but I diagree with never using __djgpp_base_address,
>> and in this case it is the right thing to use.
>
>Well, in your case, I fail to understand what on earth are you trying
>to achieve, so I can't judge whether you indeed need
>`__djgpp_base_address'.  If you need to lock the memory of the entire
>program, then that's NOT how it should be done.  The correct way is
>just to set the `_CRT0_FLAG_LOCK_MEMORY' bit in the
>`_crt0_startup_flags' variable, as the FAQ explains (section 18.9).
>The way you did it, you only lock static data and code, but not the
>memory allocated by the calls to `malloc' and friends, and neither the 
>stack.

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.)

As far as the calls to malloc, etc., the program swallows all available
memory and from then on uses specialized "malloc" functions.  The the amount
of things done with the mem are specific in that I know what it is being
used for, and doing it this way gives me more control over what is going on,
IMHO anyway. After it grabs all available memory, the mem is locked and
paged in, and not given back until the program finishes.

>
>`__djgpp_conventional_base' and the nearptr feature are for fast
>access to memory-mapped devices and absolute addresses, they are not
>the proper tools for locking memory, AFAIK.
>
>> If I use __djgpp_conventional_base it doesn't work.
>
>The fact that it doesn't work isn't in itself a proof that it isn't
>the right thing to do; the rest of your code might be the reason for
>that.
>

For things to be done the "right way" (I personally dislike that term) I
consider the functionality, stability, portability, and implementation time
(as well as others probably that I don't come to mind at the moment).  In
this case, the way I presented is more stable IMHO in the way that I know
what is going on.  I know whether or not the mem was locked and I have
control over more what to do about it.  For these reasons, I did it the way
I did.

Thanks again for your help.  (in fact the original problem was very trivial,
it only required fixing a (void *)0 to (void *)4096, something that was
already accounted for, yet I didn't type correctly).

- Raw text -