Although I have never used Visual Studio as a development environment – I generally prefer using ancient text mode DOS editors such as PMATE or EDIT for editing code and using make files to build programs, I have long been a fan of the debugging in Visual Studio 98. It is especially handy for things like fixing GPF’s caused by dereferencing null pointers, since just in time debugging will usually point you straight at an offending bit of code. When Visual Studio. NET came out I carried on using 98 because it seemed to load quicker, and because I didn’t need to use separate PDB files but could put the debug information into the executable – a real bonus if you want to be able to debug a program that has been deployed, and it didn’t insist on installing 15000 files and doubling the size of my registry like the .NET version.
Occasionally at work I have to use the 2003 version of Visual Studio. That seems to be a bit of an improvement on the original .NET version but still not a patch on the 98 version, even if the code the compiler produced was sometimes (though by no means always) faster. Later on I tried the 2005 and 2008 express products, but didn’t use them in earnest as I want to use the traditional single threading CRT libc.lib. But for porting DP4 to 64-bit Windows I was forced to use Visual Studio 2008 for debugging. What a nightmare! It seemed completely unwilling to remember break-points properly, or even stop at them. Stepping through assembly code (which I was forced to do because it was the only way I could get the debugger not to skip past the area I wanted to look at) was incredibly slow because the entire debugging window is repainted after every instruction (and I was using a mstsc connection to a very overloaded virtual server) . One false move and I might skip past the problem area and have to restart the program losing half an hour of painful progress, something which happened several times when I mistakenly thought it would be safe to jump out of a routine or use F10 instead of F11 to skip past a function call. In the end I gave up and resorted to binary chop with printf() to isolate the problem. A few weeks later I was forced into using Visual 2008 again, in order to investigate problems caused to my 32-bit software by misbehaviour of various obscure aspects of Windows. Once again I encountered the same kind of problems – in fact worse problems, because Visual Studio 2008 wasn’t even capable of relating source and disassembly properly. After 2 or 3 hours of frustration I tried copying my old 98 installation into the 64-bit machine. It worked perfectly and within half an hour I had tracked down the problem and my temper had recovered.
I simply don’t understand how Microsoft can have managed to so entirely ruin what was once an excellent product so completely. As with so much else of what they have produced lately I would willing pay extra to upgrade to an older version.