Date: Fri, 8 Apr 94 15:05:05 -0400
From: dj AT ctron DOT com (DJ Delorie)
To: turnbull AT shako DOT sk DOT tsukuba DOT ac DOT jp
Cc: djgpp AT sun DOT soe DOT clarkson DOT edu
Subject: Re: uploads to cygnus - dll, farptr, V2.0 src

> I looked in src200 for a theory of operation, and didn't find any
> such.  I suppose that what will happen is that
> (1) the stub loader sets up the necessary DPMI info, loads the
>     program, enters protected mode, and starts the program
> (2) the program runs as usual for GO32 programs until it requires DOS
>     services or virtual memory, at which point
> (3) services that GO32 used to provide are provided directly through
>     the library using DPMI, and then we are returned to the program.

Bingo!

>     Does this mean that under DPMI there will be nothing left of GO32
> in real memory (or only a very small stub), as opposed to the current
> situation where GO32 has a 130KB footprint, plus an additional
> requirement of of 50KB of scratch or other pageable space for a new
> GO32?

There is *no* go32 at all.  In fact, the stub loader itself is tossed
and the space is used as a buffer (the stub is less than 4K) so there
is *nothing* in DOS except the mandatory buffer that DPMI requires
(~100K for QDPMI, ~10K for Windows).

>     Is it also true that output of the compiler and GNU assembler will
> be the same .o files as the current DJGPP, and that difference is
> entirely in the libraries?  That is, with the same compilation, if I

> link with
> 		     LIBRARY_PATH=/djgpp/lib-1.11
> I'll get a GO32 v1.11 app, and with
> 		     LIBRARY_PATH=/djgpp/lib-2.0
> I'll get a GO32-less DJGPP 2.0 beta app?

Yes, except that either <dpmi.h> or <dos.h> has the register structure
modified (name only; it's still link compatible).

>     And finally, can I therefore hope to build Make and/or GCC under
> 2.0, and thus avoid the out of memory condition that plagues
> RAM-crammed systems when we use make, especially for recursive
> makefiles?  (I would probably continue to use the current compiler
> suite otherwise, or rebuild it too, depending on how stable 2.00 is.)

It can be done.  I haven't done it yet due to a lack of time and disk
space.  All the required functions still work properly.

>     Or is 2.00 just not stable enough to hope for this yet?

Don't know.  Try and see!

>     Just out of curiosity, does the "DPMI *at the moment*" clause mean
> that you (DJ) plan to supply a DPMI server in the future?  Or that
> some alternative protected mode interface will be provided?  Or just
> wishful thinking?

I expect that the future will require some form of public DPMI 1.0
host to satisfy the masses.  Charles Sandmann has mutated go32 into
enough of a DPMI provider to run V2.0 apps, but it's not a good
solution (one app per go32 still).