From:	Charles Sandmann <sandmann AT new-orleans DOT NeoSoft DOT com>
Subject:	Re: Virtual memory file mapping?
To:	MRMILLER AT delphi DOT com (Martin R. Miller)
Date:	Wed, 7 Dec 1994 21:14:48 -0600 (CST)
Cc:	djgpp AT sun DOT soe DOT clarkson DOT edu (DJGPP Mailing List)

> 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.

Currently non-DPMI is superior for almost all tasks.  DPMI support
was added into GO32 in V1.10 to allow running under Win 3.1 and OS/2.
It was not a particularly good match - the original Japanese concept
used a completely different DPMI-only GO32 since there was very little
code overlap.  

I have learned alot since then, DJ and other contributors have offered
some excellent ideas.  The current running V2 is faster than non-DPMI
V1.x, if that is a concern, for virtually everything.  It also has
a well defined structure which will allow adding features like signals
which have been lacking.  It will be much more maintainable and 
easy to extend (anyone looked through all the code in GO32 lately?)
There will only be a single run mode (DPMI) which will eliminate a lot
of the bugs in one mode but not the other.

> As a simple experiment, I compiled the following C++ file "huge.cc"
> 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).

This is a bogus test.  Yes, in DPMI mode you read the entire
exe file in at the start of the program.  Under V1.12 non-DPMI you
only read in the pages you touch.  Modify your program to read every
element in the array and then compare the times.  BTW, V1.x DPMI loads
the image 4096 bytes at a time, V2.x loads it 60Kb at a time, which
once again cuts the time.  Since each pagefault in V1.x non-DPMI
mode only reads 4K (or 8K) at a time, V2 images actually can do real
work faster than V1.x images.

> 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.

We are discussing having some sort of support for page fault emulated
linear graphics in the free dpmi provider or under DPMI 1.0 providers.
Since graphics are not finalized, it may go either way.  But if you
rely on this feature, you will never be able to run under any future
operating system like Windows 95, all of which require DPMI to access
protected mode.  It makes your programming more convenient now, but
it is somewhat slower and will be much less "portable" in the future.

> 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.

A single documented API which is supported by many vendors (IBM OS/2,
Windows 3.0, 3.1, NT 3.1, NT 3.5, 95, QEMM/QDPMI, 386MAX, and others).
A single "emulation" layer; all of the libc code lives in GCC/GAS code
and nothing to be maintained in TCC/16 bit code.  Speed and maintainability.
New features and extensibility.

The only disadvantage is that you are somewhat at the mercy of your
DPMI provider.  This is why I have chosen to write a DPMI provider and
make it available with source.  All the GO32 hackers out there will feel
right at home if they want to add custom features.  Having the equivalent
of "GO32" being 49K instead of 180K, being reentrant (one shared copy)
I think is more attractive than the current setup anyway.  Or better
yet, under an advanced OS, you don't need this code at all, it is
provided by the OS.  With source availability, I am convinced the free
version will become superior to anything commercially available!

- Raw text -