Date:	Wed, 07 Dec 1994 07:59:52 -0500 (EST)
From:	"Martin R. Miller" <MRMILLER AT delphi DOT com>
Subject:	Re: Virtual memory file mapping?
To:	djgpp AT sun DOT soe DOT clarkson DOT edu
Cc:	dj AT stealth DOT ctron DOT com

Previously I wrote:
> It would be nice to be able to "map" an existing file into virtual
> memory instead of allocating memory for it with new or malloc() and
> then reading its contents into virtual memory (which can simply cause
> some or all of it to be written out again into the vm swap file). I
> think some other DOS extenders have calls to do this (PharLap's?).
 
sandmann AT new-orleans DOT NeoSoft DOT com <Charles Sandmann> wrote:
> This feature is how the executable code is read in V1.1x - see
> paging.c in GO32 on the implementation.  This feature does not exist
> in DPMI, so it really cannot be provided universally.  It could be
> added as an extension to the free dpmi (with a backup implementation
> if it was not found), but I don't think something like this will be
> in the first release (too many things to do).
 
and DJ wrote:
> The DPMI 0.9 spec doesn't let you map files to virtual memory, else
> V2.0 (and probably V1.x) would already support it.
 
Sorry I keep getting DPMI and non-DPMI modes confused -- as I prefer
and usually use the latter, and tend to forget about all the
limitations imposed by the first.
 
As a simple experiment, I compiled the following C++ file "huge.cc"
using 1.12m2:
 
    #include <stdio.h>
 
    char whopper[1024][8192];
 
    int main( int argc, char *argv[] )
    {
        printf( "howdy world\n" );
        return 0;
    }
 
As expected (because of a previously discovered bug in the g++
compiler), this generated a large .o/.exe file (a little over 8Mb).
 
Running the program takes < 1 sec at my normal DOS (non-DPMI enabled)
command-line, but around 26 secs at a DOS prompt shelled-out from
within Windows (ie, under DPMI mode).  The additional time, I assume,
is because the whole executable is being read in (and maybe back-out
again into a swap file).
 
There has also been other discussions in the list regarding the lack of
graphics support, etc, in DPMI mode.  I'd really hate to see the linear
graphics memory access go away, :-(, which to me is almost as good
having the 32-bit addressing and many other cool features of djgpp.
 
Why all the slavish devotion to DPMI (which sounds like it's only going
to intensify in V2)?  Besides a lot of limitations, what exactly does it
buy?  At least now one more-or-less has the option.
 
----
Martin                                          mrmiller AT delphi DOT com
/\/\./\/\.

- Raw text -