From: 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: 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.