Date: Fri, 18 Oct 1996 12:34:41 +0200 (MET DST) From: Mark Habersack Reply-To: grendel AT ananke DOT amu DOT edu DOT pl To: Charles Sandmann cc: djgpp AT delorie DOT com Subject: Re: CWSDPMI enhancements In-Reply-To: <9610171242.AA14379@clio.rice.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Thu, 17 Oct 1996, Charles Sandmann wrote: >> It'd be necessary to handle only timer and page fault in separate tasks. >Nope. Think about it a long time, and all the exception situations you can >end up in (especially with SS/ESP) and you will become convinced that >all HW interrupts and exceptions need to be tasks if you run at ring 0 >for a robust system. (Hints - what happens if the stack at ESP-4 is >paged out right before any hardware interrupt? What if ESP is corrupted?) Right... OTOH, exceptions don't happen that often (only PF possibly does, of course) so the time penalty wouldn't be that big. And as for HW interrupt handlers, the multitasker really needs to handle timer only. Timer interrupt would at times trigger the scheduler which certainly requires running as a separate task. All the other HW ints that are necessary for the OS to run would be handled by means call gates and reside in locked memory area, possibly switching stacks on entry to be 100% sure nothing bad happens.. I guess that's the way Windows work. >> Maybe it should be designed as a 'shell' running other processes? > >This would work - but it could also just be a subroutine library which >initializes and determines if it's the first one to install the extensions. I guess thats the trade between size and speed, right? /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ 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 \/\/\/\/\/\/\/\/\/