29 comments

[ 3.2 ms ] story [ 78.3 ms ] thread
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.
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.

+1 for OWL. It was my first "real" C++ framework, and it was a great way to start.

Borland had a nice tool suite but somehow just couldn't hang on to market share.

"Somehow?" Microsoft did its best, including hiring away Anders Hejlsberg.
Borland got rid of Anders, he was constantly criticizing the move away from dev tools to enterprise platforms.
I followed only from afar, I don't have any inside info. If you know more details than this, please tell:

"Borland Charges Microsoft Stole Away Its Employees" (1997)

http://online.wsj.com/articles/SB863034062733665000

"According to the suit, Microsoft also offered Mr. Hejlsberg a $1.5 million signing bonus, a base salary of $150,000 to $200,000 and options for 75,000 shares of Microsoft stock. After Borland's counteroffer last October, Microsoft offered another $1.5 million bonus, the complaint says."

I believed MSFT offered a lot, Hejlsberg told that to Borland, Borland offered him to stay and MSFT then offered 1.5 mil more, which Borland passed.

By the way, I didn't like much OWL. The transition between OWL 1 and OWL 2 was a mess, if I remember they were practically incompatible (and also if I remember correctly, only the name was the same, I believe different companies made 1 and 2 (!) independently) whereas it was easier to upgrade the code that depended on one MFC version to the next. I liked VCL from Delphi, then also accessible from C++ Builder, but VCL lacked Unicode for too long.

At the time of Delphi 2, VCL was very nice. Delphi 2 was really, really nice way to make native Windows applications rapidly.

I don't have any inside info, but the common perception in the industry at the time was that Microsoft raided Borland's talent, and thereafter Microsoft's development tools started getting better. Borland at the time was easily the most innovative programming tools company. They had "Visual" tools long before Microsoft, so it's not surprising that Redmond focused their wallet on disrupting that narrative.
I loved Borland's tools. But they got Microsofted just like dozens of other apps, one by one over the years (word proc, spreadsheet, browser, etc.)
At the time, the battle over products like Quattro were with competitors like Lotus, and not MS.

And Borland sure did their part. There were a number of great products they acquired and then destroyed. The Brief editor is a near and dear example for us developers, but they also went out of their way, it seems, to destroy dBase and the whole Ashton Tate thing. And Sidekick was a really cool app that they managed not to handle well, too.

I think dBase screwed up before they were acquired by Borland.
No, the game was written directly on the Win16 API, something from which I have still not completely recovered.
Were you also responsible for MVP Paint?
No, but it was developed at about the same time. The late Dave Snyder, founder of the company, rounded up young programmers on Compuserve and put out a ton of shareware games during that period. There was also another version of MVP Backgammon later, but I had no involvement with that one.
"How did you debug applications on it? "

With this bad boy:

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

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.
Was it the old VGA/Hercules combination? That was so badass It was also the only way to run dual-screen for a while, since it used a different memory region than colour displays. There was literally no way to run multiple colour adapters on the same computer at one point
Man I am just not sure. I had a Hercules green screen / more shades than CGA setup myself, but if it helps I do think both of their screens were color. I know Hercules probably did other stuff, but I guess I think monochrome whenever I think about it, heh. I do believe this was the old DOS version, not the Windows version of SoftICE, although when I was over there seemed was just before the time of Windows 95 possibly.
I used the DOS version of SoftICE on a retail Windows 95 machine, to circumvent the upgrade prevention check in Windows 95 OSR2. OSR2 was an OEM only release, but I figured there had to be a way. Setting breakpoints and single stepping through the setup, I discovered that it checked for krnl386.exe. If that for existed, it was considered an upgrade. If you were a clever young hacker, you renamed that file and went ahead with the upgrade.
Talk about a blast from the past! Watcom C/C++ with external amber debugging display was the best.
Watcom was the best - with Dos Extender and 16-32 cross compiler. Worst IDE, though.
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.
I used to trigger NMI by shorting the first two pins on an empty ISA slot with a screwdriver (conveniently NMI and GND); stopped when the screwdriver slipped once. Thankfully nothing died on that day, but the cascade of sparks convinced me to install a proper button. ;)
Same, but that was all we used it for. I do recall running into some horrible memory issues on another project (Iona's Orbix, but that's another story) and wishing I had SoftICE to tear it apart with. But for most application issues it was overkill. The existing debugging tools (and 3rd party stuff like Bounds Checker) were usually good enough.
(comment deleted)
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.

You can still do remote debugging with WinDbg for example.
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.