Mike Stall has an interesting post on hardmode vs. softmode debugging.

I did a double-take when I saw "hardmode" and "softmode". Mike's using those terms in a completely different context from their original usage.

Back in the day (i.e., 16-bit Windows), debugging a GUI app with a GUI debugger was a very difficult problem. Unlike Win32, Win16 had cooperative multitasking. That is, apps had to explicitly yield control to the OS. If they didn't, only the app got any CPU cycles, and the rest of the system was effectively hung.

Consider what would happen if you put a breakpoint in the window procedure (WNDPROC) of a 16-bit app: The breakpoint is hit, and the app stops pumping messages through its message loop. As a result, all other message pumps in all other apps would be starved for CPU time, including the debugger's. The result? A hung system.

To remedy this, Microsoft outlined two modes of debugging: Hard Mode and Soft Mode. Whenever the debuggee stopped, the debugger would enter into one of these modes. When the debuggee resumed, the debugger put things back the way they were before the debuggee stopped.

Hard mode was a special mode of the windowing manager (added in Windows 3.1) that only pumped messages to one app. As I recall, the GUI debugger process entered this mode, and only the debugger would respond to user input request. Everything else was frozen, even Calc or Notepad or your email, or...

Hard mode was good because it minimally affected the target process.

In contrast, soft mode meant that the debugger took over the message pump of the debuggee. This is similar to open heart surgery, where your heart is stopped and a machine takes over the job of pumping the blood through the body until the heart can be reconnected. A debugger in soft mode subclassed all the debuggee's windows and pumped messages for it. How did the debugger know how to respond to a particular message? In general, it didn't. Soft mode debuggers made a best reasonable guess of how to handle each message.

The advantage of soft mode is that the rest of your system continued to operate normally. However, it was more intrusive of the debuggee, and prone to more errors if it didn't handle a message the way the debuggee would have.

Luckily, when Windows 95 and Windows NT came around, us debugger folks were able to put this nightmare behind us.