OK, I've been toying with this idea for a couple of days, and it sounds good to me.
Windows, when it dies, does so rather ungracefully and screams at users with the dreaded BSOD. IMHO, this is really frustrating and quite rude. Instead, the operating system should attempt to handle the exception and recover.
Recovery can be as simple as skipping over the faulty instruction (though this has a 'domino' effect) or as complex as finding the source process and killing it, then somehow switching to a new task (gracefully?).
The first can be quite complex in implementation, requiring tables of opcodes and their lengths and a matching algorithm to ensure that the faulting instruction is skipped.
Any input?
Crash Recovery and Seamless Return
Probably best todo just do what Windows (and Linux, FreeBSD, OpenBSD, Solaris and whatever other operating system run on an x86) does and kill any application that faults.
For one thing, Windows (NT) never blue screens on an application failure, only kernel problem. If you begin skipping opcodes in kernel mode you have a serious chance of messing up people's computers..
For one thing, Windows (NT) never blue screens on an application failure, only kernel problem. If you begin skipping opcodes in kernel mode you have a serious chance of messing up people's computers..
Yes, that's how I understand it. Unfortunately, NT is rather monolithic in design and faults in kernel-mode device drivers can equally cause a BSOD.Tyler wrote:For one thing, Windows (NT) never blue screens on an application failure, only kernel problem.
In a microkernel environment, however, it should be easier to restart a driver. For example, consider that the display driver crashes (quite a common occurence on my XP machine, unfortunately). The kernel needs to detect this somehow (as the error might not cause an exception), close down the process, inform all clients that the driver is not currently responding to messages and that all recently sent messages might not have been processed, and then restart it, informing clients that it has done so.
To take it one step further, what if the microkernel itself does something silly and needs to be shut down? We could have control transferred to a watcher program that simply reloads the kernel and attempts to restart it whilst maintaining process information, but I don't know how feasible this is. Besides, what watches the watcher?
Regards,
John.
The way I understand it with Vista is that it's farmed as much of the driver code as possible in to userland making it less likely that drivers will crash the kernel...jnc100 wrote:Yes, that's how I understand it. Unfortunately, NT is rather monolithic in design and faults in kernel-mode device drivers can equally cause a BSOD.Tyler wrote:For one thing, Windows (NT) never blue screens on an application failure, only kernel problem.
In a microkernel environment, however, it should be easier to restart a driver....
If that's true then it can only be a good thing. I have no experience with Vista and no current desire to upgrade. Something about having 20 different versions with only the most expensive being a home os with the ability to support that most modern of concepts: domain logons.AJ wrote:The way I understand it with Vista is that it's farmed as much of the driver code as possible in to userland making it less likely that drivers will crash the kernel...
Regards,
John.