Changes to how we build our software

Starting with our first software release of 2015, we will start shipping software that uses the Visual Studio 2010 C runtime and MFC libraries. The purpose of this article is to explain why we’re making this change and how this will affect users of our software.

Some of our past choices have been about technology and some about ease of doing the work. If the operating system or development environment fights you, you are less likely to use it.

Compiler History

When we started the company the current version of Visual Studio was Visual Studio 6.0. So naturally our software shipped with C runtime and MFC libraries for Visual Studio 6.0.

We didn’t really like the direction the Visual Studio team went in with subsequent releases,in particular with some subtle changes to the debugger that, it seems, many people have never noticed. These changes removed a particular feature from the debugger that we find very useful (drag an address to the disassembly view and automatically get the disassembly displayed – the workaround to do this in current versions of Visual Studio is clumsy, error prone and occasionally fails). Because of this we continued using Visual Studio 6.0 to build our software. Anything requiring support for more recent versions of Visual Studio would be built using that version of Visual Studio (library stubs, Visual Studio editor support, etc).

When we started exploring 64 bit support we started with Visual Studio 2008 because that was the current toolset at the time. Our 64 bit tools ship with the Visual Studio 2008 C runtime and MFC libraries.

For our .Net tools we’d be using Visual Studio 6.0 for the GUI, but Visual Studio 2010 (or 2012) for the profiler backend.

This resulted in our routinely using multiple versions of Visual Studio to do development.

OS History

Historically we have supported all operating systems from Windows NT 4 onwards. We have always wanted to support our customers using Windows NT 4 and Windows 2000. Many people using Windows embedded are still on old versions of Windows.

We made the rather unusual decision to develop on Windows XP x64 but to test on Windows 7 and Windows 8. This decision was mainly due to UX blunders Microsoft had made with the Start Menu on both Windows 7 (no fly out start menu) and 8 (no start menu!), and also to the file search functionality which is very easy to use on XP x64 and very hard to use from Windows Vista onwards.

These may seem like trivial things but we use file search a lot and often the Visual Studio file search is not the tool you need. Simply put we found XP much, much easier to be productive with compared to anything that came after.

Reason for change

Since April 2014, Microsoft no longer supports Windows XP. From a security standpoint this isn’t good. For us, or for you (if we get compromised, how can you rely on us?). As such we had to move away from Windows XP x64 whether we wanted to or not. We’ve written some tools to allow us to do fast easy searching without needing to go near the UX disaster that is the current version of Windows search. The removes one of our main objections to working on Windows 7 or Windows 8 on a daily basis.

We also tested a lot of start menu replacements. We finally settled on Classic Shell as this not only provides a very useful start menu on Windows 8 but also allows you to have a proper fly out menu (like XP) rather than the cramped and very awkward to use compressed menu you get with Windows Vista/7 (no wonder Microsoft’s UX metrics showed start menu use was down – they’d made it too hard to use).

So that’s the two UX reasons out of the way, what about the software?

We would also like to take the software tools in new directions – to support .Net alongside C++ rather than in separate tools. This can be done using our current arrangement but it’s harder than necessary. In particular it makes automating our builds harder. Visual Studio 2010 is a lot easier to control from the command line that Visual Studio 6.0. So moving to one Visual Studio for this is a major bonus. Also, debugging software built using multiple different versions of Visual Studio, some of which can’t read debug info from other versions of Visual Studio, that is horrible.

We noticed that no one has discussed Windows NT 4 or Windows 2000 with us for quite some time so we decided to drop support for Windows NT 4 and Windows 2000. Removing this constraint meant we could move to the Visual Studio 2010 runtime and thus use one main version of Visual Studio to do most development work.

The reasons the Visual Studio 2010 runtime is important is because this is the most recent runtime that supports Windows XP and many people are still using Window XP.

Implications

An unfortunate consequence of this change to Visual Studio 2010 runtimes is that if you are using more than one of our 32 bit tools or more than one of our 64 bit tools then you will need to install new versions for all of the 32 bit tools (or all of the 64 bit tools). The reason for this is due to DLL dependencies and memory allocated by DLLs all needing to come from the same allocator. Mixing VS 2010 built DLLs with VS 2008 built DLLs or VS 6 built DLLs will give unspecified results.

We realise this is inconvenient and certainly not ideal. We won’t be changing the runtime we use again until none of our customers need support for Windows XP. We anticipate people using XP for many years into the future (based on comments made to us by customers).

The Future

We aim to roll all the functionality of our .Net tools into our C++ tools. C++ Coverage Validator will be able to collect coverage data for .Net code, C++ Memory Validator will be able to collect and analyse .Net memory data, C++ Performance Validator will be able to profile .Net code. The .Net specific tools will then be phased out.

If you are using our .Net tools, you will still be supported – we’ll move your .Net licences to the C++ licences where you will get the .Net data previously provided by the .Net tools.

If you are using our C++ tools, you will get additional .Net data in the tool.

The intention is that the tools will simply get better. We aren’t going to damage the C++ side of the tools to provide the .Net support. I mention this because we’ve had some questions from customers asking about this (having seen what some of our competitors did when they decided to support .Net).

Visual Studio

We will continue to support every version of Visual Studio from Visual Studio 6 through Visual Studio 2013 (and what comes after it, Visual Studio 2014 CTP, now renamed Visual Studio 2015 CTP) and future versions.

Windows NT 4, Windows 2000 support

If you need support for Windows NT 4 or Windows 2000, please contact us. We will be able to support these operating systems, but only via a special build facility.