Mail Archives: djgpp/1997/03/09/06:56:23
> and you can end up with unlocked, or partially unlocked memory, which will
> crash your program."
Partially locked memory won't happen with CWSDPMI (r3) - that part was fixed.
> 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.)
The way id did this with quake was to use the unixy sbrk, then avoid calling
malloc/sbrk completely after some point so that nearptrs wouldn't move.
Due to the unpredictability of memory block locations and being contiguous,
you can't lock all memory using the standard sbrk(), period, without using
the built in crt0 flag. To have manual control over memory locking you must
use unixy sbrk, which guarantees a single contiguous memory block. But
some OSes like W95 sometimes have real problems providing a single contig
block, so if there are other programs running, W95 may puke your sbrk
request (but work just fine on your development box). YMMV.
Run another DOS window sometime with a DJGPP image in it while your first
image is running - you may find all sorts of bizzare behavior in sbrk()
values. The standard libc handles this W95 braindamage, but it may not
be what you expect!
- Raw text -