From: Newsgroups: comp.os.msdos.djgpp Subject: Re: __djgpp_base_address Date: Sun, 9 Mar 1997 0:26:19 Organization: Rice University, Houston, Texas Message-ID: <332203ab.SANDMANN@clio.rice.edu> References: <199703061902 DOT NAA90652 AT audumla DOT students DOT wisc DOT edu> Reply-To: SANDMANN AT clio DOT rice DOT edu NNTP-Posting-Host: clio.rice.edu Lines: 28 To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp > Why should I modify the code when it is trivial to put the code into the > program? The only real problem with the code that you mentioned is that I > didn't lock the stack. Is this the only thing you found wrong with it? I > can easily add that, and I will. It's not trivial, see my other message. Using sbrk(), W95, locking with the default algorithm is a disaster waiting to happen. There are workarounds, but you better look at the code in crt0.s to know what to expect. It may work fine on one machine for a while, but I know how to break it unless you switch to unixy sbrk(). > I do just that, but not with those particular functions. I use dmpi > functions to get the mem info, sbrk to get the mem and then lock it using > dpmi fucntions and finally use a simple for loop which touches all the > memory to make sure that it's there, much like the code I posted previously. 1) DPMI memory info functions are notoriously buggy. For example, W95 reports the amount of lockable memory way too conservatively (like 1/2 what it will really accept). Beware. Custom hack code needed. 2) sbrk() to get the mem is the right way, but use the unixy sbrk and then don't sbrk() afterwards. You might feed sbrk() a negative increment after your big call to leave some for the libc (an ugly hack). I think that still works - check it if you try it ... 3) If the lock call succeeds, there is no need to touch the memory - locking it pages it in. Touching is only needed when you want to live dangerously and not lock, and hope it doesn't kill you. Have fun, good luck.