Xref: news-dnh.mv.net comp.os.msdos.djgpp:3737 Path: news-dnh.mv.net!mv!news.sprintlink.net!newsfeed.internetmci.com!in1.uu.net!EU.net!peer-news.britain.eu.net!yama.mcc.ac.uk!news.york.ac.uk!tower.york.ac.uk!slh100 From: Shawn Hargreaves Newsgroups: comp.os.msdos.djgpp Subject: Memory locking woes Date: Sat, 9 Dec 1995 18:02:50 +0000 Organization: The University of York, UK Lines: 23 Nntp-Posting-Host: tower.york.ac.uk To: djgpp AT sun DOT soe DOT clarkson DOT edu Dj-Gateway: from newsgroup comp.os.msdos.djgpp I've been struggling with page locking using djgpp v2. My program traps a lot of interrupts, and calls a lot of C library routines from these interrupts, so there is no easy way to figure out exactly what memory needs to be locked. I decided that I would just lock everything, which is an ok solution, since I do my own loading and discarding of data, rather than relying on dpmi to provide virtual memory). Unfortunately things turn out not to be as simple as this. 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()... 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... Shawn Hargreaves If God is omnipotent, can he make a http://www.york.ac.uk/~slh100/ rock so heavy that he cannot lift it?