Date: Thu, 17 Oct 1996 11:04:32 +0200 (MET DST) From: Mark Habersack 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: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 \/\/\/\/\/\/\/\/\/