If 16-bit Windows had a single input queue, how did you debug applications?

[snarfy]

"How did you debug applications on it? "

With this bad boy:

http://en.wikipedia.org/wiki/SoftICE

[th0ma5]

I remember meeting some hackers at their house a friend of mine took me to in the middle of nowhere, and I asked them where they got their software cracks, and they kind of blinked, and showed me the first dual monitor setup I had ever seen in person, with a regular system on the left, and the output of SoftICE on the right. I guess before that I had just assumed lower level things were unknowable, but after that I sure didn't.

[zwieback]

We used SoftICE extensively for driver debugging. I seem to remember a pushbutton that slid into the ISA slot to trigger a NMI but now I'm not quite sure anymore if it was SoftICE or Periscope that had that.

[markbnj]

Sounds much more complicated than I remember it. I wrote a game called MVP Backgammon in 1991 using Borland C++ (5.x) and their integrated debugger, and do not recall any specific issues related to input queue deadlocks. You set up your PeekMessage loop or whatever and hung a breakpoint on the switch statement for the message type you needed to debug, and followed it down from there. I assume the debugger was smart enough to run its own PeekMessage loop while waiting for commands.

[zwieback]

Did you use OWL with BC++? That was so much better than MFC although the non-standard C++ extension was a little unsavory.

I also remember the BC++ debugger being pretty nice although I preferred CodeView.

[bluedino]

Were you also responsible for MVP Paint?

[breadbox]

I loved having the debugger separated out onto its own screen, even if it was a monochrome screen showing a bunch of tiled windows drawn with CP437 text-mode characters. To this day I miss the perfection of that setup.

One of the first times I had to use a "modern" 32-bit debugger, one with its own top-level window on the normal desktop, I was trying to find a bug triggered by focus events. Every time I hit a breakpoint, the focus would change to the debugger, dropping another focus event into the event queue, which would naturally trigger the breakpoint again once I stopped single-stepping. Having the debugger embedded in the system you're trying to debug can be very, very annoying.

[yuhong]

You can still do remote debugging with WinDbg for example.

[yuhong]

http://blogs.msdn.com/b/matt_pietrek/archive/2005/02/14/3724...

I am surprised Raymond did not mention it.

[henderson101]

I was just remembering my first job, where we still developed 16-bit based clients. I was thinking "Wow, I don't remember it being so difficult to debug...", then it dawned on me, everything we were doing was on machines running Win NT 4!! 16bit Delphi 1 was an amazing achievement though, and the 32bit transition was fairly painless for us too.