Newsgroups: comp.os.msdos.djgpp
Date: Sun, 18 Aug 1996 19:05:49 +0200 (MET DST)
From: Mark Habersack <grendel AT ananke DOT amu DOT edu DOT pl>
Reply-To: grendel AT ananke DOT amu DOT edu DOT pl
To: djgpp AT delorie DOT com
Subject: Memory mapped files using djgpp on DOS
Message-ID: <Pine.NEB.3.95.960818184854.9877A-100000@ananke.amu.edu.pl>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII


With Win95 memory mapped files become available for every programmer working
on average PC, not only on server-class machines running under WinNT. I
thought it might be useful to have such a "gadget" under DOS. The problem
seemed quite easy in theory: one just has to put one or two "guard" pages in
memory, sit silently until one of these pages is hit and only then expand/move
the buffer corresponding to a file on disk. All that is needed to do it seemed
to be present in djgpp environment: means to manipulate specific pages, DPMI
call to install interrupt handler. However, when I tried to implement the
scheme described above, I encountered some serious problems. First, and the
most grave, is that DPMI 1.0 spec says that the client application doesn't
receive "transparent" processor exceptions signals. AFAIK, all available DPMI
servers that comply to either 0.9 or 1.0 DPMI spec, behave just so - they do
not send those exceptions to the clients. Unfortunately, Page Fault (0x0E)
exception is one of them - it is supposed to be serviced entirely by server to
provide virtual memory and, in case of bad access to page, to gracefully
terminate the client app. The only exception to this rule is CWSDPMI (thanks,
Charles) which gives the client a chance to look at the exception if it hasn't
been dealt with. This helps much as DPMI server doesn't care about PFs caused
by access to uncommited pages (and that attribute should have all the
"guards"). This feature is, however, specific for CWSDPMI only. 
When program that installs PF handler is run under, for example, WinXX, it
doesn't receive PF signals of any nature.
Having said that, it seems that there is no way to provide mmapped files under
DOS (at least in DPMI environment). Well, there might be, in fact, another way
- hardware breakpoints. All DPMI servers allow the client app to set ones,
even virtualize them, so that clients can forget that i386 has only four
breakpoint registers. This technique, however, conflicts with GDB and perhaps
with all other 32-bit debuggers.
So my question is: is there a way to implement mmaped files using PF scheme?
How client can make the server reflect PF faults? Should it be done by
directly modifying IDT?

Mark

/************************************************************/
/** Maybe it was infatuation or the thrill of a chase?   **/          
/** Maybe you were always beyond my reach and my heart **/
/**   was playing safe?                     ***********/ 
/** But was that love in your eyes I saw, **/
/**   or the reflection of mine?        **/
/** I'll never really know for sure,  **/
/** You never really gave me time!  **/
/** Won't you give me that time?  **/ 
/**          "Cindirella Search" **/
/********************************/
Visit my homepage: http://ananke.amu.edu.pl/~grendel