Visual Studio 2008 sucks.

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.

Porting software to 64 bit Windows.

I have recently ported DP4 onto 64-bit Windows, coincidentally at the same time as porting MAF to 64-bits on my Mac Pro.  I had to make exactly one source code change to get MAF to work,  though later on several dozen more to ensure that all the MAF diagnostic messages were correct in both the 32-bit and 64-bit versions.  For porting DP4, admittedly a larger project, I had to make hundreds of changes, almost all of which were in Windows specific parts of the code.  Despite its plethora of ugly data types such as DWORD,  LONG, DWORD_PTR and so on, it was in Windows specific code that I had problems.  The Win32 API’s insistence on the use of WPARAM ,  LPARAM, and LRESULT types means that programmers are forced to use casts:  casts which may well subsequently turn out to be wrong – types such as DWORD_PTR were added to the API quite late on, so older code may use DWORD instead. When this has been done in an explicit cast the code will be wrong in the 64-bit world, but the compiler probably won’t warn you. Porting older programs with a lot of user interface would probably be very difficult – I’m not surprised that Visual Studio 2008 is still a 32-bit program even in the version intended for 64-bit Windows.

Eventually I got DP4 working nicely in the 64-bit world, and 64-bit and 32-bit DP4 programs can happily live together and communicate with each other. However, I can’t help feeling that in a few years time I’ll have to go through all this pain again, because the Windows 64-bit model is broken: int and long are both still 32 bits, while size_t is 64 bits. In particular this makes life difficult when using printf() style functions, especially as support for the z size specifier cannot be relied on in a program intended to be portable. Programs can’t take advantage of the wider registers unless they use long long types, making it more difficult to make a program portable.

I Sign up to SourceForge

I only signed up for SourceForge so that I could make MAF available as an open source program. Using the SourceForge web site is a very frustrating experience. There are so many things you can do that actually doing any of them is far more difficult than it should be. The help pages are hopeless. For example the information on how to create a new project is hopelessly incomplete, and I had to contact online support to find out how to get my source code into Subversion. I wasted several hours trying to find out how to do this, and can’t believe there is no simple step by step guide for doing this.

The trick is you have to check out the project before you can add files to it.