Xref: news-dnh.mv.net comp.os.msdos.djgpp:3763 Path: news-dnh.mv.net!mv!news.sprintlink.net!newsfeed.internetmci.com!in1.uu.net!noc.near.net!das-news2.harvard.edu!oitnews.harvard.edu!newsfeed.rice.edu!rice!news!sandmann From: Charles Sandmann Newsgroups: comp.os.msdos.djgpp Subject: Re: Memory locking woes Date: Sat, 09 Dec 1995 22:59:09 CST Organization: Rice University, Houston, Texas Lines: 25 References: Reply-To: sandmann AT clio DOT rice DOT edu Nntp-Posting-Host: clio.rice.edu To: djgpp AT sun DOT soe DOT clarkson DOT edu Dj-Gateway: from newsgroup comp.os.msdos.djgpp > 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 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