Date:	Tue, 11 Mar 1997 23:40:54 +0200 (IST)
From:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
To:	Roland Acton <malyon AT netcom DOT com>
cc:	djgpp AT delorie DOT com
Subject:	Re: Locking entire program in memory?
In-Reply-To:	<malyonE6v85x.E54@netcom.com>
Message-ID:	<Pine.SUN.3.91.970311234028.2704N-100000@is>
MIME-Version:	1.0

On Tue, 11 Mar 1997, Roland Acton wrote:
> Shawn Hargreaves (Shawn AT talula DOT demon DOT co DOT uk) wrote:
> : Somewhere in your program, add a global variable:
>
> : #include <crt0.h>
>
> : int _crt0_startup_flags = _CRT0_FLAG_NONMOVE_SBRK | 
> :                           _CRT0_FLAG_LOCK_MEMORY;
>
>   There's something I'm curious about. When I looked through crt0.h, it
> mentioned that the LOCK_MEMORY flag could be turned on and off during
> execution. But none of the programs I've looked through do this; they all
> use the method of surrounding interrupt code with dummy functions and
> locking the memory in between, which has always seemed chancy to me. CAN you
> turn it on and off? Is there a reason why no one does?

LOCK_MEMORY flag indeed CAN be turned on and off at run time.  You can
see in the sources for crt0.s that this bit is tested every time an
additional chunk of memory is requested from the DPMI host: if the bit
is ON, the chunk of memory is immediately locked.

However, if you think that turning the bit ON and OFF at appropriate
times can entirely solve the problem of locking interrupt handlers'
code and data, think again.  First, how would you lock the code?  If
you set the bit like in the above fragment (which is how most people
do it), ALL of your program's code is locked, so if the size of code
is larger than the free physical memory, the program won't run, or,
worse, some or all of its code (possibly, your interrupt handlers)
won't be locked.  Second, the space for the stack and the static data
is usually allocated at startup, and therefore will be locked if that
bit is set like above: again, locking all of the 256KB of stack and
all the .data and .bss sections might be much more than you actually
need to lock.  Third, memory is requested from the DPMI host in 64KB
chunks, so if you set the bit, call "malloc (10)", then unset it, and
`malloc' doesn't have enough free memory to give you those 10 bytes,
the entire 64KB chunk allocated by a call to DPMI host will be locked
when you only needed to lock 10 bytes.  Bottom line is, you end up
locking much more than you really need anyway.

People use the not-so-safe method of defining dummy variables when
they write their handlers in C, since in C, there is no way you can
know the size of your function code (which is required to lock its
code).  Hardware interrupt handlers should really be written in
assembly, and then there's no problem to lock them properly.

- Raw text -