Date: Tue, 11 Mar 1997 23:40:54 +0200 (IST) From: Eli Zaretskii To: Roland Acton cc: djgpp AT delorie DOT com Subject: Re: Locking entire program in memory? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 > > : 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.