Xref: news-dnh.mv.net comp.os.msdos.djgpp:2280 Path: news-dnh.mv.net!mv!news.sprintlink.net!cs.utexas.edu!bcm.tmc.edu!academ!news.sesqui.net!rice!news!sandmann From: Charles Sandmann Newsgroups: comp.os.msdos.djgpp Subject: Re: Locking mem under DPMI Date: Fri, 29 Sep 1995 07:51:32 CDT Organization: Rice University, Houston, Texas Lines: 22 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 > Last question, is there any reason preventing auto-locking of the > iret/callback wrappers and interrupt stack space in subsequent compiles > of libc.a? It seems that right after the malloc would be the perfect > place to go ahead and lock it. For the .beta3 release I went ahead and > patched the libc sources, are there any side effect I should be aware of? This should be done. If you have patches to do this, please put them on ftp.delorie.com in the incoming directory. Everyone has just been too busy with other things to get to it. I would also suggest locking 4096 bytes after the starting address of the wrapped function. Since most interrupt routines should be fairly short, I would guess this would automatically handle 99% of the cases, and locking an extra page of memory won't hurt anything. At that point, it would be up to the user to lock any data they touch or any subroutines they might call (and to make sure their code is less than 4096 bytes or lock the rest...). This seems like it would not be too difficult. I also think we need a simple wrapper function that automatically adds the CS base to this, so something like __djgpp_lock_memory(void *, unsigned size_in_bytes) (which could even use the global value declared in sys/nearptr.h to make it even easier). I think Mat posted a routine that did this once.