3

One of the Norton utilities allowed you to do something — probably a keystroke — which caused a hung program to unhang, and often you can save your work. It saved me several times when running Gates' crappy Office software.

How did it do that?

Nonmaskable interrupt? Did it hook into the operating system somehow? Did it already have to be running? I don't remember. It couldn't have used protected mode. It ran on an 8088, right? Was it a TSR?

Did it slap the other program in the face and say "wake up" by triggering another interrupt in the hung program? Which one? Or what?

Sleeves rolled up Peter Norton was the legendary hero of the 80s.

Improve this question
6
  • 5
    Peter Norton is indeed still alive, at time of writing.
    – wizzwizz4 ♦
    Commented Oct 25 at 12:54
  • 5
    I take it you’re referring to CrashGuard — by the time that was released, Peter Norton hasn’t been involved in development in quite some time.
    – Stephen Kitt
    Commented Oct 25 at 13:04
  • 2
    Crashguard was released as part of Norton Utilities V2 for Windows 95 in 1996. It was thus not available for DOS. Therefore, it can't run on 8088. Keyboard also cannot trigger NMI. So it is likely a Windows program, not a TSR which is a DOS concept. And as a Windows program, it is really likely it's not a real mode program. However, I am unable to answer the question, just these false assumptions.
    – Justme
    Commented Oct 25 at 22:24
  • 2
    @MissUnderstands Windows 9x never had much protection, and it simply could somehow get rid of the stuck program so the unstuck program can continue and you or the Crashguard can emit a keyboard command to save work and then reboot.
    – Justme
    Commented Oct 26 at 6:34
  • 1
    My recollection of CrashGuard in Win95 was that it intercepted the Ctrl+Alt+Delete Task Manager, and gave you the option to unfreeze a selected process. It also intercepted fatal process crashes and gave the option to try and recover. I'm less certain but it might also have intercepted blue-screen style system crashes too. It didn't always work, but it worked often enough to be useful!
    – Steve
    Commented Oct 26 at 15:53

1 Answer 1

Reset to default
4

This is super speculative and I'm only writing this because no one's mentioned message loops.

A common reason for loss of responsiveness in a Windows program is it stopping processing its message queue, which it does by calling GetMessage/DispatchMessage in a tight loop. DispatchMessage returns after WinProc, a programmer-provided callback function associated with a window's "window class", has run. Trying to do slow/potentially slow things (like looking for a file on a network share that is down) directly in the WinProc would cause the program to appear to freeze. It must be added that in systems that are not very robust to begin with, freezing is almost always due to something outside the program's control. A program just going into an infinite loop would be a serious bug that would be caught early on.

I can imagine that the way Crash Guard would remedy at least this kind of freezing was by restarting the message loop, by making the program jump into its main window's WinProc, perhaps with uMsg set to a no-op like WM_NULL. Callbacks like WinProc are also externally visible entry points. Jumping into WinProc (perhaps unwinding the stack while one's at it, too) seems like a plausible mechanism to try and put the program back on track (no matter how random of a track in terms of the program's dynamic history.)

Improve this answer
1

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .