OSDev.org

I'm told Win9x crashes were primarily caused by bad drivers. I did have one machine on which Win98 didn't crash, so I think it could be right, but that machine also had tons of RAM, relatively speaking, so maybe that helped.

I think the Atari ST's crash screen is a little bit interesting. The machine had a framebuffer; no hardware text. The crash routine blanked it to white and drew some bombs - no text, but the number of bombs was a simple error code. Later machines drew the bombs one at a time, perhaps to make them easier to count.

Re. multitasking: Y'all forgot about early Unix. Related: There seems to be a trend these days to write off some things as "not an OS" when frankly, they were OSs and were very valuable in the past. CP/M is one.

To get back to the question that prompted this discussion, I wouldn't say that a BSOD is a priority when writing an OS (particularly not for a self-confessed beginner!). There are better ways of tracking errors when developing the OS. And I don't think, in a mature OS, that such a screen is particularly useful. I think the OS X way of a short message saying that there has been an error, and then the details of that error being saved in a crash dump of some sort, is far more useful. How many people ever take note of the information displayed on a BSOD?

It's more useful for bug reports where non-kernel-programming users send in photographs of the screen. I saw that a lot with 9front and I think it happened in the earlier days of Linux too. 9front's cinap_lenrek would look at a photo and say in moments which function the kernel was in when it panicked. Sometimes he'd compile an altered kernel and post a link to it with "try this".

Despite all that, I don't know why the data wasn't written to disk instead. Perhaps it's because 9front filesystems are userspace programs, but the system isn't averse to writing plain text to raw disk partitions. I'm thinking I'd prefer crash data to be written to the disk, serial port, or network rather than the screen.

PeterX wrote:Just what I said Or I didn't express clearly. Anyway that's what I was trying to say.

Oh, then I misunderstood, sorry.

PeterX wrote:Windows probably was the holder of the world record of crash screens. It's name BLUE s.o.d. for a reason: Because the Win crash screen was blue. When I used Windows 95, ANY time a crash could occur. For example in the middle of writing a text.

Yes. I've mentioned on the wiki page that it was so common that it made to the pop culture. (Actually "Blue Screen of Death" was never an official name, yet everybody knows what that is )

PeterX wrote:I don't know if BSOD is an imprtant feature. But perhaps it improves debugging a lot. I'm not sure.

No not really important. Can help debugging specially in early stages, sure. The main reason behind creating that wiki page was that newcomers are keep asking about it, and newbies tend to spend enormous time on creating an ASCII art for it. Just go through this forum's history, showing crash screen is an extremely popular topic (including but not limited to "When your OS goes crazy"). My personal favourite is the crash screen with the exploding HIndenburg picture

iansjack wrote:There are better ways of tracking errors when developing the OS.

I agree. I've added more sentences to the wiki page to clearify that MacOSX and Windows do save dumps. However at early OS development stages (when you can't save dumps yet) crash screens can be useful.

iansjack wrote:How many people ever take note of the information displayed on a BSOD?

I think the question is more like when people take note. For me it was very helpful when my OS already ran perfectly on the triumvirate (bochs+qemu+vb), and I started real hw tests, and the OS crashed on some real hardware. I couldn't solve those issues without a crash screen (my OS can be built with an integrated debugger, also capable of displaying the syslog, memory maps etc.).

eekee wrote:Despite all that, I don't know why the data wasn't written to disk instead.

Because that involves considerably bigger complexity than writing text on screen. And if the crash was triggered by your VFS module (or by the disk driver) for example, then you'll get a nice infinite crash loop without any information about it (there'll be no dump on disk).

Cheers,
bzt

One thing to note is that the term 'BSOD' presupposes a GUI, which is probably a bit premature for the OP even if they are taking a James T. Klik approach to OS dev (which given their screenshots does seem to be the case). The Unix term 'kernel panic', while carrying a rather different loading, is perhaps more general anyway, even if not as familiar to non-Unix users.

Perhaps we need a more neutral term for this, one which doesn't carry the loaded implications of either of those. 'Irrecoverable State Report' might do.

Basically, the essence of this topic is,

• something has happened which has put the system as a whole into an irrecoverable condition
• the kernel was able to detect the irrecoverable condition, and is able to shut itself down (or try to) before it hangs completely
• the kernel error handler tries to collect some information about it's state when this happens before it finishes shutting down
• the error handler tries to send some sort of message to the admin/user as one of the last actions before automatic shut down, to let them know what happened and perhaps pass some debugging information for fixing the problem in the future

Does that help at all, or am I just being excessively pedantic? I had the impression that the essence of the problem was getting lost in all the discussion of other systems.

Schol-R-LEA wrote:One thing to note is that the term 'BSOD' presupposes a GUI, which is probably a bit premature for the OP even if they are taking a James T. Klik approach to OS dev (which given their screenshots does seem to be the case). The Unix term 'kernel panic', while carrying a rather different loading, is perhaps more general anyway, even if not as familiar to non-Unix users.

BSOD doesn't really presuppose a GUI. While the whole point of Windows was that it had a GUI, the original Windows 3 BSOD was displayed in text mode. One can imagine an alternate history in which the Windows GUI and OS/2 Presentation Manager were not just similar, but actually the same codebase, and then there was an even bigger falling out between IBM and Microsoft over OS/2, with IBM and Microsoft fighting over the rights to the Presentation Manager codebase, and neither company able to release a project using that code until the case was settled. If the VDM/DPMI part of things was still on track, Microsoft might have released Windows 3 without the GUI (presumably under some different name), which would still provide multitasking between DOS programs. In such a situation, Not-Windows 3.0 could still have had the same bluescreen as the Windows 3 we know.

Schol-R-LEA wrote:One thing to note is that the term 'BSOD' presupposes a GUI

Not really. It could use the kernel console (by calling the same kprintf the kernel is using to display other messages). That kprintf could be implemented to use 0xB8000 text mode. And for example my kernel has an LFB, and my kpanic function writes to the framebuffer directly (mapped in kernel space specifically for that purpose), not relying on the GUI at all. Yes, I had to implement putchar twice, once in the GUI and once in the kernel for the console, but that's about 10 SLoC, not a big price I think.

Otherwise my kprintf supports just a few escape sequences (only the ones the kernel actually uses with kprintf), while the one in the GUI implements full ANSI VT support with VT220 extensions. Yet another difference that the putchar in kprintf also sends the characters to the serial port (if compiled with debug), while the GUI version only prints to screen.

For example:

Here the background is the IDE, the smaller window is a terminal with redirected vm serial output using CSI, and the LFB screen with the actual on-screen characters. This allows me to debug using a serial cable in headless mode, without the need to implement a debugger protocol or porting gdb-server. I can use minicom just as-is with real hardware too.

Cheers,
bzt