Somehow, there is a claim of a 30-year mystery surrounding Microsoft’s Blue Screen of Death. The argument goes that there are three conflicting sources of authorship: Steve Ballmer, John Vert, and me.
But really, there is no conflict. There are three different blue-colored screens, and each has a different author.
First is the Windows 3.1 Ctrl+Alt+Del screen, which is a blue screen of unhappiness, not death:
| Contoso Deluxe Music Composer
This Windows application has stopped responding to the system.
* Press ESC to cancel and return to Windows. * Press ENTER to close this application that is not responding. You will lose any unsaved information in this application. * Press CTRL+ALT+DEL again to restart your computer. You will lose any unsaved information in all applications. |
The text for this message was written by Steve Ballmer. (He didn’t write the code to display the message; he just wrote the text that goes into the message.)
Windows 3.1 did not have a blue screen of death. If Windows crashed, you got what could anachronistically be called a black screen of death:
| Could not continue running Windows because of paging error. C:\>_ |
Next is the Windows 95 kernel error, which you could consider a “blue screen of death”, although Windows 95 lets you ignore the error, so it’s not a true death. (Then again, there’s no guarantee that ignoring the error will return you to a usable system.)
|
Windows
An exception 0D has occurred at 0028:80014812 in VxD CONTOSO(03) + 00000152. This was called from 0028:80014C34 in VxD CONTOSO(03) + 00000574. It may be possible to continue normally.
* Press any key to attempt to continue.
* Press CTRL+ALT+DEL to restart your computer. You will
lose any unsaved information in all applications.
|
I was the one who brought this version of the Windows 95 kernel error blue screen message to its final form. (Some people have misidentified an early version of it as a Windows NT blue screen.)
The third blue screen of death is the Windows NT kernel error, and that’s the one authored by John Vert.
| *** STOP: 0x00000019 (0x00000000,0xC00E0FF00xFFFFEFD4,0xC0000000) BAD_POOL_HEADER eax=ffdff13c ebx=80089a10 ecx=08000800 edx=ff69bf60 esi=80088010 edi=8008b0f0 Dll Base DateStmp – Name Dll Base DateStmp – Name Address dword dump Build [v1.528] – Name Restart your computer. If this message reappears, do not restart. |
This is a true “blue screen of death”: The system is unrecoverably dead at this point.
So we have the following table:
| OS | Author | Release year |
|---|---|---|
| Windows 3.1 | Steve Ballmer (text) | 1992 |
| Windows 95 | ends with me¹ | 1995 |
| Windows NT | John Vert | 1993 |
¹ I did not write the early version of the Windows 95 blue screen message, but I was the one who brought it to its final form.
NT had not only Blue Screen On Death but also Blue Screen Of Birth (or Boot to make it less fancy)
Sorry to ask an unrelated question.
I found that GetStockObject can actually obtain a stock bitmap, but this is not mentioned in the documentation. In other words, <code> and the only difference is that the latter has a clearly defined behavior in the documentation, while the former is an "internal undocumented behavior that should not be relied upon"?
You have answered yourself. If it is not documented, it is undocumented. Welcome to Tautology Club!
I don’t understand the point of relying in undocumented (and potentially unreliable) behavior when there is an easy and completely legal way to achieve the same. It’s taking a risk (and putting a burden on application compatibility people) without earning anything.
In response to the comment below, DeleteDC doesn't delete any objects associated with the device context so I don't think that it's a memory leak concern per se. I also don't think that it matters whether the original bitmap is a stock object or not (what would be different if it wasn't a stock object?).
I think that the question here is the need to restore the original objects (pen, brush, bitmap, etc.) of a memory...
GetStockObject doesn't need additional parameters, so I think it is more convenient to use.
But if the documentation for GetStockObject had recorded it, people would (more likely) know that the initially selected "1-by-1 monochrome bitmap" in the memory device context is actually a stock object, and there is no need to save it and restore it before DeleteDC.
<code>
Although it is mentioned in the Memory Device Contexts section that "The original bitmap in a memory...
When I read about this on SlashDot a few days ago, all I could think is "when would some journalists learn to do their legwork and verify things before writing an article?". Today's post should be completely unnecessary (Raymond doesn't add anything he hasn't said in the past), yet it is needed to sum it up in a single place because of lazy people who can't bother to do a couple of clicks.
But maybe it...
Just remember this next time you feel inclined to trust them on something you’re not expert in.
“The phenomenon of a person trusting newspapers for topics which that person is not knowledgeable about, despite recognizing the newspaper as being extremely inaccurate on certain topics which that person is knowledgeable about.” Gell Mann amnesia effect.
I read SlashDot mainly to know “the opinions of the other side”. But sometimes they are unbearable. For example, in the last days they have talked daily about the “Microsoft-CrowdStrike outage”, as if they could convince anyone not already in their ship that Microsoft is the culprit…