How to target several versions of Windows

Question

I need to write a simple command line program that will work on Windows XP (most machines will have SP3, but some may not) all the way up to Windows 7.

I'd like to be able to compile it into a single portable file that does not require me to install additional frameworks like .NET or Java. I should be able to drag the file onto a machine and be able to click and run. I do not mind if I have to compile for different versions of Windows, but it would be nice to be able to write one version that works across the board. I don't care if I have to write it in a language that I am unfamiliar with, the program is simple enough. What language should I write my code in to achieve this?

The friend I'm developing for doesn't know much about computers, but looking at his sample target machine I see Java 6 installed, and Windows Visual C++ 2008 (Windows XP SP3). As an alternative, assuming that these two frameworks are installed on all of these target machines, which one do you recommend utilizing for maximum cross-platform support (only across Windows versions)?

P.S. I am developing on a 64 bit Windows 7 Machine with Visual Studio 2012 installed. I have experience with Python, some Java, and some C#.

Thanks in advance for your help!

Answer 1

This is going to be difficult to answer in an objective and unbiased fashion because of the general rule that the "best" language to write something in is generally the language with which you are most familiar. This is the language you will be most productive working in, and even if there are a couple of snags that you have to work out/around, you will be in the best position to do so if you're already experienced with the language you chose.

So, because I am primarily a C++ developer, I would recommend that you write the app in C++. If you are not a C++ developer, this would be a very stupid recommendation. It would take you longer to learn and become even minimally proficient in C++ (much less debug and/or maintain the code over the long term) than it would for you to just write the app in another language, work around any problems, and get on with your life.

The issue of required runtimes isn't one that is going to settle the decision much. Just about every popular language requires some type of runtime to be installed first, and you can't simply rely on those being installed everywhere. About the only difference is the size and metaphoric "weight" of the runtime package that needs to be installed. Here's my very basic attempt at a breakdown of a couple of the popular languages and their requirements:

• Java Everyone knows that Java applications require a Java runtime to be installed. This is often a pretty darn big runtime environment, and you certainly can't depend on it being installed everywhere. Lots of people don't have a JVM installed (and may not even want one if they buy into the bad press it's been getting recently).

• .NET (includes C#, VB.NET, etc.) Like Java applications, those that target the .NET Framework require the .NET Framework to be installed. Statistically speaking, it is probably more likely that any given machine will have this installed than the Java runtime (if only because Microsoft pushes it out via Windows Update), but you still can't count on it being there. It's also a large, heavy dependency.

• C++ Even though C++ apps compile down to native, unmanaged code that does not require a runtime environment, if you use Microsoft's compiler, you will need to install the appropriate version of the C++ Redistributable Runtime Library. For example, if you compile using version 10 of the compiler (bundled with VS 2010), you will need the Visual C++ 2010 Runtime to be installed. Just like with the managed runtimes, you cannot count on this being installed on the machine already. Another app might have installed it, but it might not. You always have to manage your own dependencies. Luckily, it's a very small dependency (relatively speaking), so it's not that big of a deal to distribute.

  Alternatively, you could statically link the runtime environment into your C++ application. This increases its size slightly, but means that you don't have to distribute the redistributable. The disadvantage of this is that you don't benefit from any security updates to the CRT because the code is statically linked into your app. You'll have to recompile and redistribute to get all of those benefits, and that's a lot of work. But if you absolutely have to have something that runs without any dependencies, this is what you'll need to do.

• VB 6 Somewhat ironically, you can be guaranteed that an old VB 6 app will run out-of-the-box on any existing Windows installation. This is not because VB 6 requires no runtime environment—it mostly certainly does, it's just that it has been included with Windows itself for the past several versions and isn't ever going to get upgraded since VB 6 has been end-of-lifed for quite a few years. That's one reason why this isn't a good option for you; another one is that you can't (at least not easily) create command line apps with VB 6.

So in a lot of cases, you pretty much either have to have a controlled environment where you know that your target runtime is already installed, or you have to distribute the runtime dependency along with your application (and ideally an installer that manages all of this seamlessly for the user). And now we're back to what I started with—the language decision is best made based on which one you already know and are most comfortable working with/in.