Mail Archives: djgpp/1996/10/17/09:04:10
> >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?
ftp riceng.rice.edu, username djgpp, password betatest, binary, get mwdpmi.zip
> >There are some on-purpose holes in the security of CWSDPMI, which allow
> 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...
Sure it would be reliable - CWSDPMI just prints a message and exits on
exceptions. If you are going to do multitasking you will have to re-write
the libc anyway. I suggest CWSDPMI just provide the basic DPMI interface
to bootstrap you into PM, then you provide whatever non-DPMI enhancements
on top of it in GCC/GAS code. If you get really clever, you can probably
figure out how to bypass the protection on other DPMI providers too.
> >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.
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?)
> 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.
- Raw text -