(no title)
dbcurtis | 1 month ago
Woah, back up a bit. In the article, it looks like the blue screen is a 0x0 (iopr) exception, likely a wild jump into the weeds. But back in the day, the majority of blue screens were 0xE exceptions -- page fault in the kernel. Why? Buggy driver that didn't wire down a page and it got swapped out from under the driver. Not under Microsofts direct control... BUT... they had a great example in OS/2. In WinNT, there are 2 security rings, kernel and user space. But x86 supports 4 rings. OS/2 used ring 1 for drivers, so that the kernel could both blame the correct driver and also stay alive. So simple. (Of course, it means it is hard to port to hardware with only 2 security rings.) WinNT drivers are not things of beauty. The dev experience is cranky, and validation is a nightmare -- and the lowest bidding Asian contractor that is writing your driver for your el-cheapo peripheral rarely signs up for that nightmare.
delta_p_delta_x|1 month ago
I think one could say the same for any platform; in general, developing drivers is just difficult, full stop. That driver quality for peripherals can be bad is not the fault of the platform. I'm sure I could find dodgy drivers in the Linux tree that were merged in only because 'shrug it makes PineappleCorp's device work, who cares if it is littered with UB'.
dbcurtis|1 month ago
p_ing|1 month ago
And Microsoft has made the least stable of the drivers a recoverable fault, at least.