Mail Archives: djgpp/1997/03/09/07:41:03
> 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.
- Raw text -