www.delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/1996/10/17/05:31:01

Date: Thu, 17 Oct 1996 11:04:32 +0200 (MET DST)
From: Mark Habersack <grendel AT ananke DOT amu DOT edu DOT pl>
Reply-To: grendel AT ananke DOT amu DOT edu DOT pl
To: SANDMANN AT clio DOT rice DOT edu
cc: djgpp AT delorie DOT com
Subject: Re: CWSDPMI enhancements
In-Reply-To: <32650f27.SANDMANN@clio.rice.edu>
Message-ID: <Pine.NEB.3.95.961017105858.16494L-100000@ananke.amu.edu.pl>
MIME-Version: 1.0

On Wed, 16 Oct 1996 SANDMANN AT clio DOT rice DOT edu wrote:

>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
Yes, I noteced. I stepped upon some of them ;-)))

>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
Is the kernel available anywhere?

>> 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.
But would the code thus hacked be really reliable? Multitasking done this way
would have to bypass all exception handling provided by CWSDPMI. This would in
turn involve modifying libc code...

>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
That's the pain. Virtual memory is too precious to sacrifice it.

>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).
It'd be necessary to handle only timer and page fault in separate tasks. 

>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.
Maybe it should be designed as a 'shell' running other processes?

/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
Stand straight, look me in the eye and say goodbye
Stand straight, we drifted past the point of reasons why,
Yesterday starts tommorow, tommorow starts today,
The problems always seem to be
  we're picking up the pieces on the ricochet
/\/\/\/\/\/\/\/\/\/\ http://ananke.amu.edu.pl/~grendel \/\/\/\/\/\/\/\/\/

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019