Mail Archives: djgpp/1994/04/08/15:50:16
> 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.
> 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
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
> I'll get a GO32 v1.11 app, and with
> 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).
- Raw text -