Mail Archives: djgpp/1995/12/11/06:25:00
> The sbrk() routine in crt0.s uses dpmi functions to enlarge the block of
> memory that my program is using, which can change the segment base address,
> thus messing up all my memory locking! It would be a terrible pain to have to
> relock everything after each call to malloc()...
It turns out that when 0x503 DPMI call moves a block of memory containing
locked pages, it takes the locked attribute for each page with it (on all the
DPMI providers I remember testing). But! There is another workaround for
this which will be in beta 4 as the default sbrk() which does not move the
arena.
> To get around this I have patched crt0.s to lock the memory as it
> allocates it, but this is a very ugly solution since there is no way to
> only lock certain parts of memory. It would be nice if the v2 libs could
> provide some more intelligent page locking routines, that would take
> care of re-locking memory if sbrk() alters my base address. Are there
> any plans for such a thing? If not I would be happy to do some work on it...
Actually, I have thought about adding the "lock all memory on sbrk()"
option bit to crt0 (it's a long story). The current base point is stored
in a variable declared in <sys/nearptr.h> which makes the locking process
a little easier. The entire area of sbrk(), near pointers, locking, etc
is an evolving point of V2 right now, so send me a message if you have a
good idea. The short answer is DPMI can be a real pain in the butt in
these areas ;-P
- Raw text -