Date:	Wed, 21 Dec 1994 16:25:17 +0900
From:	Stephen Turnbull <turnbull AT shako DOT sk DOT tsukuba DOT ac DOT jp>
To:	RGRUNWAL AT wasp DOT cs DOT cowan DOT edu DOT au
Cc:	djgpp AT sun DOT soe DOT clarkson DOT edu
Subject:	QEMM's VM manager and V2.0

Ron--

   The current version of GO32 (1.12m2) was found to be incompatible 

By who?  What evidence?  What else was running at the time?

   with QEMM's DPMI virtual memory management unit. Are there any plans 
   to correct this in V2.0?

The question indicates that you're not paying attention to what's
going on on the list.  So, a brief elementary lesson is in order.  If
you already know all this, "I have done something without bowing."

(0) What version of QEMM are you using?

(1) Current GO32s are known to be incompatible with DPMI in general if
you are running a graphics program.  (There are ways to do graphics
under DPMI, I understand, but these are not standard and require a
real effort to use.)

(2) QDPMI is not a virtual memory management unit; it is a DPMI host.
I don't even know if it provides VM (I use DESQview/X which has its
own VM manager so I don't worry about whether QDPMI does this).  Are
you sure it's VM, or could it be some other aspect of DPMI, such as
the well-known conflict with SVGA and VESA graphics?
    Quarterdeck's Tech Support was in the habit of blaming non-DOS4GX
extender's virtual memory mechanisms for all DV/X crashes not
otherwise explainable.  I never saw any evidence supporting or
disconfirming this hypothesis; when the faults got fixed, the fixes
were random tweaks that had nothing apparent to do with DPMI (except
that not running QDPMI usually worked) or VM.  When the faults weren't
fixed, no further explanation was forthcoming from QD Tech Support:
"The developers are busy developing; if they give us any information
we'll pass it on to you."
    In this particular matter, QD's statements are very weak evidence.

(3) There is no GO32 at all in V2.0.  V2.0 will run under any DPMI
server, including QDPMI.  We hope.  There are good reasons to believe
this (#1:  DJ.  #2:  Charles Sandmann.  #3:  Casba Biegl.)  It is
believed that Csaba's V2.0 GRX library will go like gangbusters under
DJGPP V2.0 and therefore DPMI.

(4) Charles Sandmann is the (primary) developer of a derivative of
GO32 that will provide DPMI 0.9 services.  CWSDPMI will be (a) free;
(b) with source (requiring TP2.0 to compile, I believe); and (c) is
intended (but not promised) to eventually become a free DPMI 1.0 host.
(This would immediately fix the graphics problems, but not if you were
using a different DPMI host.)  As of a couple of development cycles
ago (I'm currently out of the alpha test loop), progress was being
made on making it compatible with DESQview/X; Justin Wilmsmeyer of
Quarterdeck says he believes there is no reason this can't be done,
but he isn't an expert on memory management for Quareterdeck.

That's more and less what's known to regular readers of the list.

- Raw text -