Supported compilers?

We’ve done one decision in WinMerge development which will cause some unhappiness. We are dropping support for Visual Studio 6 as supported compiler in 2.9.x and later versions. We’ve been trying to do this for couple of years already, but every time there are people saying they are using VC6 and if we drop support they cannot contribute anymore. What can we say. We need every contributor.

But now it is finally time to do this. Even if it causes some unhappiness. Blame me.

The fact is VC6 is old and buggy compiler. We already need some ugly hacks to keep WinMerge 2.6 working with it. Couple of top things from top of my head:

• it has old MFC version, even if MFC hasn’t developed much, there are some improvements.
• does not support type long long ! So 64-bit support can only be done with MS-specific types. I haven’t even tried to compile 64-bit ShellExtension with VC6.
• doesn’t support 64-bit file find API/structures

The old MFC version is of course the biggest issue. It is pretty common that code written and tested in VS2003 or later does not work with VC6. As everybody wants to use those small improvements there are available. But the 64-bit file find API/structure issue is not a small issue either. Large files and filesystems are common novadays.

I’ve personally been using mainly VS2003 for couple of years. All 2.6.x WinMerge releases have been compiled with VS2003. It has been and will be in near future the only compiler we guarantee will compile WinMerge correctly. We know it works flawlessly for WinMerge. I’ve recently switched to VS2008 as my personal development compiler. At work I use VS2005 so I test compiling WinMerge with it regularly, but don’t really develop with it.

Why don’t we go directly to VS2005 or VS2008 as our supported compiler? We can not! The simple fact is one can always convert project/solution files from older version to later version. But it won’t work other way around. If we switched for VS2008 compiling with VS2003 and VS2005 would became a lot harder. Most people would need some additional tricks to get working solution/project files.

So what? Just provide project files for every compiler version? No, that we won’t do. Keeping two or three project file versions in synch won’t work. Different people have different versions and nobody has time to track every possible change. So instead of one good and working project file we would have three broken project files and big mess.

Having VS2003 project files limits us a bit, but this way we can support all modern VS versions and avoid the mess with multiple project files.

Release compiler is another issue. I’m not upgrading it from VS2003 in 2.9/2.10 time frame at least. Basically I could just update runtime files and be done with it. But I want to build releases from fresh SVN export. Simply to avoid some local change messing up the release. And SVN has VS2003 project files so using it as release compiler is the simplest solution.

I know there are projects that don’t care about compiler versions. They just support one version they’ve chosen (many times the latest available). In my opinion that restricts other contributors way too much. In worst case one needs different compilers for different projects. Testing with different compilers takes time and sometimes writing code that works in multiple compiler versions is not easy.

With WinMerge we’ve been doing this for years. Yes, its not so unusual that some compiler version gets broken by some patch. But we’ll fix it when somebody notices it. In my opinion this is still a lot better (to have sometimes broken builds) than not even trying to support more than one compiler.

I can promise we will never require one specific compiler version for WinMerge. We will support what is reasonable, not taking too much time or effort. This will ensure more people can take the sources, study them and hopefully help us to make WinMerge better! Hopefully in future we can even expand our supported compiler set with GCC!

And after all, this VC6 deprecation will also improve WinMerge. Source will be cleaner as we eventually will remove VC6-related hacks. And we can take full advantage of improvements in VS2003 and later versions.