Date: Thu, 6 Mar 1997 13:09:21 +0200 (IST) From: Eli Zaretskii To: djgpp AT delorie DOT com Subject: Re: __djgpp_base_address In-Reply-To: <199703051831.MAA141402@audumla.students.wisc.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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.