Visual Studio

10 April 2010
Historically most of my programming has, one way or another, been command-line. Back in the 1990s when I first started it was Borland Turbo C (and DJGPP) under DOS, University used Solaris boxes, and at least for the last 10 years my preferred development platform has been Linux. Even when I was using Windows, I had a tendency to use LCC.

One area where Linux sucks is programming Windows Mobile devices. There is CeGCC, but getting it working under Linux is an utter mission, and I gave up after trying several Subversion source branches. Even if it did work there are no Linux-based emulators, and even though I could use SynCE to deploy to a PDA, I did not want to use my mobile for experimental programming. I managed to get CeGCC working under Cygwin, but since that involves rebooting to Windows, I decided I may as well get back up to speed with Visual Studio.

Getting emulators working

Even under Windows, this is a mission. Various bits have to be installed in a certain order, whereas the sane thing will be for the emulator to notice when there have been new emulator images installed. It is possible to install standalone emulators (separate from Visual Studio), but it is pretty clear from the lack of polish that this is not intended as a common path. Getting ActiveSync to work as a non-administrator user was particularly painful.

Hard tabs

Oh dear. Hard tabs are a well-known road to ruin. Different editors use different amounts of space when showing tabs, and it causes merry hell when mixed with soft tabs (use of a few space characters rather than an actual tab character). Hard tabs are OK when you only ever edit source code within Visual Studio (big assumption if portability is ever a concern), and anyone you share source code with has identical user preferences.


This is one of Visual Studios best features, and I am not aware of any other editor that has a similar feature (looks like Eclipse IDE also has similar features, but seems to really be aimed at Java).

Automatic indentation

Not quite to my tastes, but it just about works to a tolerable extent. The increase/decrease indentation (an idea that seems pinched from Word's bullet list editing) is quite nice though. I have may times tried finding an editor that has automatic indentation to my personal tastes (a variant of Whitesmiths), and pretty much always end up using XEmacs.

Sensitivity to build changes

This is something that seems to break easily. I wanted to add build targets other than Windows Mobile 6 (eg PocketPC 2003) to a project, but for some reason they kept breaking. Only way I could get it working was to create a new project with all the required build targets selected, and then manually import all my source/resource files.

A bit embarrassing that I was using version control to roll back screwed up project files far more often than I was rolling back programming mess-ups.

Code folding

Visual Studio supports code folding, and from what I vaguely remembered of my C# programming (bit over 7 years ago) it was quite good. However i found the automated folding it does for C/C++ exceptionally annoying. It only does folding at the top-level (eg functions), unlike SCiTE that allows folding of function blocks such as for loops. To make matters worse it insists in including whitespace lines off the end of the folding block, and it lumps anything that is not a function together. For example:

/* MyCode.cpp - Some source code */ #include "windows.h" Global_t data; // TimerProc - Handle timer callbacks // wParam = // 1: Clock update // 2: Stopwatch update LRESULT CALLBACK TimerProc( /* .. */ ) {

Everything before the function definiton is lumped together. This is particularly annoying when you have function description comments, and I have taken to putting them after the function:

LRESULT CALLBACK TimerProc( /* .. */ ) // TimerProc - Handle timer callbacks // wParam = // 1: Clock update // 2: Stopwatch update {

Mercifully I discovered Visual Studio has an equivilent of C#'s #region & #endregion folding tags:

#pragma region RegionName #pragma endregion LongComment

The equivilent Xemacs folding.el tokens are:

/* {{{ RegionName LongComment */ /* }}} */

Visual Studio vs Visual C++

I suspect Visual Studio and Visual C++ are not maintained by the same team at Microsoft, as even back in 2003 I found Visual Studio quite nice, whereas Visual C++ (from what I remember) has neither the nice GUI of Visual Studio nor the gets-things-done-quickly of GCC & makefiles.