From:	sandmann AT clio DOT rice DOT edu (Charles W. Sandmann)
Subject:	go32.com (DPMI)
To:	djgpp AT sun DOT soe DOT clarkson DOT edu (djgpp)
Date:	Mon, 19 Apr 1993 08:59:11 -0600 (CDT)

Humm, what a timely set of messages...
Here is what I currently know about GO32.COM and DPMI support for GO32:

There is currently a GO32.COM that supports DPMI under Win 3.0 (and ONLY 3.0)
as per this part of a 12 Mar 1993 message:

Ken> Yes, that's right- If you obtain the DPMI converted Go32 from
Ken>     ftp.sigmath.osaka-u.ac.jp:/pub/Msdos/GO32/DPMI.support,
Ken> you can get full GNU Emacs working just fine for the PC under Windows 3.0.
Ken> However, it doesn't seem to work under 3.1.  The instructions are in
Ken> Japanese (see attachment), and there is a reference within them to "Windows
Ken> 3.1".  I presume (because the text is near the end of the doc) that it's a
Ken> "soon to be added" feature.

This version will not work under QDPMI, 386Max, NT, Win 3.1, or any version
of OS/2 DOS box I have tested.  Ken Stillson is trying to get it to work
under Win 3.1, and I am working on getting it to work on OS/2 DOS box.

The GO32.COM version is based on a V1.04 GO32 (or thereabouts) and has
problems loading V1.07 or later images (ie, everything you are likely to
have lying around).  There are other limitations too numerous to be listed
here at this time.

I spent a few hours this weekend and merged the V1.08 (first step to V1.10..)
paging.c and control.c versions, increased the fixed stack size to 2.0Mb,
and decreased the required DPMI memory.  COMPRESS.EXE, my testbed, requires
almost 5Mb of DPMI memory to load and run.  The image hangs when
calling Pmemset() under OS/2 DOS box (and much earlier under Win 3.1).
I have also incorporated the patches suggested by Makoto Kobayashi in
the version I am working on.  

The way it currently works (probably to be changed) is that you have both
a GO32.COM and GO32.EXE in your /bin directory.  GO32.COM executes first,
checks for DPMI, and if it does not exist, calls GO32.EXE.  So the DPMI
upgrade is currently a 1 file solution, but slows down load times outside
of DPMI, and won't run "aligned" V1.07 or later images.

I would suggest waiting a while and let the code be fully updated (exphdlr
is next, and event library?) and hopefully fix the problems with Win 3.1
and other DPMI providers.  If you have Win 3.0 and can't wait, want to
run V1.07 or later images, I supposed I could send you a pre-alpha update.

In a nutshell, there are problems with library and version compatibilites
(V1.04 to V1.09) *AND* problems with the DPMI.ASM code interface to DPMI
services.  I can't even get DJ's DPMII.COM to work under 386MAX or QDPMI
which makes me wonder about DPMI at all...

- Raw text -