From:	Charles Sandmann <sandmann AT new-orleans DOT NeoSoft DOT com>
Subject:	Re: object file format change?
To:	turnbull AT shako DOT sk DOT tsukuba DOT ac DOT jp (Stephen Turnbull)
Date:	Sat, 3 Dec 1994 09:37:36 -0600 (CST)
Cc:	dj AT stealth DOT ctron DOT com, djgpp AT sun DOT soe DOT clarkson DOT edu,
	dylan AT takoyaki DOT demon DOT co DOT uk, justin AT qdeck DOT com

>     On the other hand, despite your sanguine attitude (in another
> message) toward support of (non-X) programs in DV/X windows in V2.0,
> it's not clear to me whether this is going to be easily done.  QDPMI
> and DV/X apparently communicate through proprietary extensions to the
> DPMI 0.9 standard (well that's what I was told, I don't know the
> standard myself).  The alpha versions of the free DPMI "sort of" work
> in a DV/X window, but if the reason they don't really work is due to
> the proprietary extensions and not to a CWSDPMI bug?  

Since GO32 works in a window, I am guessing I just have a bug (or some
features removed from GO32...) which makes this work.  The proprietary
extension problem I think is only when loading before DVX.

> If we have to go
> with QDPMI, there won't be that much benefit (initially) to using
> V2.0:  besides being idiosyncratic, QDPMI makes almost as large demands
> on low RAM as GO32 does.  DV/X users may have to live with V1.x for a
> while in any case.

The QDPMI ram issue really isn't true.  GO32 takes like 130K+ per
implementation; QDPMI + V2 stub takes less than that amount.  And on
nested programs QDPMI doesn't take very much, so you still should be
able to run many more nested programs.  The lack of virtual memory
support could be a problem (the biggest I see) but I suspect it is a
bug in their realloc() code and there may be a workaround for this.

- Raw text -