From:	<SANDMANN AT clio DOT rice DOT edu>
Newsgroups:	comp.os.msdos.djgpp
Subject:	Re: CWSDPMI enhancements
Date:	Wed, 16 Oct 1996 16:36:55
Organization:	Rice University, Houston, Texas
Lines:	50
Message-ID:	<32650f27.SANDMANN@clio.rice.edu>
References:	<Pine DOT NEB DOT 3 DOT 95 DOT 961016191201 DOT 14188I-100000 AT ananke DOT amu DOT edu DOT pl>
Reply-To:	SANDMANN AT clio DOT rice DOT edu
NNTP-Posting-Host:	clio.rice.edu
To:	djgpp AT delorie DOT com
DJ-Gateway:	from newsgroup comp.os.msdos.djgpp

> It's certainly possible. But you must remember that CWSDPMI is a very delicate
> structure and I suppose that Charles is the only one who knows it good enough
> to modify it (I once tried to add DPMI 1.0 services to it but all I achieved
> is dead computer). Yet Charles says there won't be (probably) any further
> releases of CWSDPMI... Maybe just a little guide over the code, Charls? ;-)

CWSDPMI is a fairly rotten piece of code.  It evolved instead of being 
designed.  There are lots of landmines and bandaids in the code.  It was
originally planned to be a prototype/interim solution until the real, full
1.0 DPMI implementation was written.  A few personal disasters put 
development 2 years behind schedule (yes, early CWSDPMI prototypes existed in 
April '94) and so the prototype becomes the final release.

If I were to write the real DPMI 1.0 provider, it would be based on the
Morten Welinder DPMI kernel which he started after discussions on CWSDPMI
(Morten made several great contributions to CWSDPMI).  The COFF linking
capabilities in DJASM were added by Morten so much of the DPMI provider
could be written in GCC itself.  Virtual memory handling and an extender
were to be layered on the DPMI kernel - all structures would live in
extended memory (instead of the current DOS memory setup).

But I don't use DOS anymore (I run/develop under NT, Unix or VMS) which
means I don't have any incentive to mess with major new enhancements.

> Sure, implementing it inside CWSDPMI would make things easier since it can run
> some parts of code in ring 0 and this is required to do task switching in PM.

There are some on-purpose holes in the security of CWSDPMI, which allow
you to get to ring 0 if you want to - or modify the IDT, etc - so you can 
bypass/enhance the current structure at will.  With a 386+ processor 
handbook, and looking at the source of CWSDPMI, you can get away with
just about anything.  I've shown some people how to browse/change the GDT and
page tables before.

You could also run under the PMODE DPMI provider, which is a ring 0 provider,
and accomplish much of the same things - and it's code has fewer landmines.
But virtual memory and ring 0 really don't mix, so you have to run any
portion of your code you plan to page at non-ring 0, or fill the IDT with 
a lot of tasks (slow, lots of memory usage).

> There's just another small 'but' here. Adding task switching capabilities to
> CWSDPMI would mean making it into a small OS kernel. It'd be small if to look
> at it as on an OS but as DPMI server it would be rather big. Well, I suppose
> that 'with a little help of my friends' we could do it. Charls, would it be
> very time-consuming for you to enlighten us as to obscure CWSDPMI internals?

You would be better of layering the kernel in 32-bit space on top of 
CWSDPMI or PMODE.  I wouldn't want to modify either of these to have the
features in it internally.  Using 32-bit tools for development will be
a win in the long term.

- Raw text -