Developing Windows Applications in C++: The Tools You Need

To build Windows applications with C++, you’ll need some tools. The good news is that you don’t need to spend money to do so. You can use a collection of command line tools (compiler, linker, and so on) that you can use with the editor of your choice. Or, if you prefer an integrated development environment, you can use Visual Studio or Visual Studio 2010 Express. Express is a version that you can download for free and use to develop Windows applications, even those you intend to sell. There are other versions, at various price points, that add capabilities you may find useful for some kinds of applications. The choice is yours.

Windows SDK

The Windows Software Development Kit is a free download from the Microsoft Download Center. There are SDKs available for many versions of Windows: make sure you get the Microsoft Windows SDK 7.1 for Windows 7 and .NET Framework 4, released in May 2010.

Note: if you use Visual Studio 2010 and have installed Service Pack 1 for Visual Studio 2010, installing the SDK will be a two-step process. First, install the SDK 7.1 without the C++ compilers, and then install the update to the SDK (available at the Microsoft Download Center under the name Microsoft Visual C++ 2010 Service Pack 1 Compiler Update for the Windows SDK 7.1) to restore the compilers. This process addresses an issue in the service pack that affects C++ developers.

  • Documentation about developing both managed and native applications for Windows 7
  • Sample code in a variety of languages
  • Header files you will need to include in your Windows applications
  • Libraries you may link to from your Windows applications
  • Tools to build your applications
  • Helpful utilities

The first thing you are likely to want to do is to build some old code of your own or to build some of the samples that come with the SDK. By default, the SDK installs the samples in the Program Files directory. However, I recommend that you set up a working directory that is not under the Program Files directory, and put your code there or copy the samples there from where they are installed under Program Files. There are two reasons for this.  First, it’s normal to run the samples, change them a bit, run them, and generally experiment with them. Keeping a clean original copy saves you from having to download the SDK again if you want the original samples back again. Second, and more urgently, compiling applications under the Program Files directory is difficult on a Windows 7 machine. That part of the directory tree is protected by UAC, User Account Control, and can only be written to by elevated applications. (If you’re new to Windows 7, UAC is the feature that prevents non-administrative applications from writing to protected directories, and requires the end user to consent to elevating an application that will perform administrative tasks.) It’s irritating to run your developer tools elevated, since you’ll need to consent to the UAC prompt each time, and worse you could easily write applications that only work elevated, since you’d be testing in the elevated environment and might not notice what you had done. Working in a directory that is not under Program Files is the best way to set up your development environment.

The compilers and tools that come with the SDK may be installed in two places in your file system: the tools and samples are under the SDK directory (for example, a typical installation location on a 64-bit machine is C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1. The compilers may be under Visual Studio (for example on a 64-bit machine, C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC). This is typical on a machine that installed Visual Studio followed by the SDK, because the SDK and Visual Studio can use the same compiler and linker. You generally don’t need to know the path to the tools, because the environment variables are set for you so that the right tools will be found when you issue commands. Knowing these paths can help you find the SDK samples. If the samples are in a zip file, don’t try to extract them in-place – as mentioned above, UAC prevents writing to anything under Program Files unless you are elevated. Extract to a working directory elsewhere.

To build an application or library, start by opening a Windows SDK command shell. You can find this on the Start menu:

Click Start, All Programs, Microsoft Windows SDK v7.1, Windows SDK 7.1 Command Prompt. This will launch a command prompt with the environment variables set for you.

To build, use the cd command in the shell to navigate to the folder where the code you plan to build has been copied. The simplest applications might be a single .cpp file, but it’s more usual to have another file that contains a list of all the files in your application and the options you want to use when compiling each, along with their dependencies. You may issue a number of different commands, depending on what file you have that describes all the files in your application:

  • To compile and link a single file, use the cl command with appropriate command line arguments
  • To make a project using a make file, use the nmake command (no arguments)
  • To make a Visual Studio 2010 solution (.sln file) use the msbuild command with the /p command line argument
  • To make a Visual C++ project (.vcxproj file) use the msbuild command with the /p command line argument

Note: not all .sln files are Visual Studio 2010 .sln files. Some samples that ship with the SDK (and some examples you may find elsewhere) have Visual Studio 2008 .sln files, or .vcproj files. The two .sln files can be distinguished in Windows Explorer by their icons:

The Visual Studio 2008 .sln files have a 9 in their icon and a segmented multi-color logo. The Visual Studio 2010 .sln files have a 10 and a smooth purple-and-blue logo. You will not be able to build the Visual Studio 2008 files directly with version 7.1 of the SDK, but you can upgrade the project files to Visual Studio 2010 versions, which you can build with version 7.1 of the SDK.

To upgrade a project from Visual Studio 2008 format to Visual Studio 2010 format, open an SDK command prompt and cd to the solution directory. For each .vcproj file, issue a command like this:

>vcupgrade.exe ProjectName.vcproj

It is not possible to upgrade the .sln files from the command line, so simply ignore them and build each upgraded project in turn as described below.

If the sample has a Visual Studio 2010 .sln file, building that with msbuild is your first choice. If there is no .sln file, but there is a .vcxproj file, build that. You must specify the platform for which you want to build. This will be either win32 – for a 32 bit x86 application, X64 – for a 64 bit x64 application, or IA64 for an Itanium application. (If you don’t specify it, the first configuration in the project or solution file, alphabetically, will be used, which will almost never be what you want.) For example, to build a 32-bit version of the Secure CRT sample:

>msbuild SecureCRT.sln /p:platform=win32

You may want to redirect the output to a file:

>msbuild SecureCRT.sln /p:platform=win32 >out.txt

An easy way to look at the output afterwards is to issue this command:

>notepad out.txt

A number of the C++ samples come with a solution file and several project files. In some cases the projects are all part of the same solution and depend on each other. For example a large executable might depend on some libraries, and they could all be built together using the solution file. In other cases, the projects are independent, and can be built alone.  To build a 32-bit version of a single project, CD to the folder with the .vcxproj file and use this command:

>msbuild ProjectName.vcxproj /p:platform=win32

As before you may want to redirect the output to a file.

If you are comfortable editing make files by hand and want to build your applications this way, you’re all set. Editing .sln and .vcxproj files by hand is not recommended. For that, you should use Visual Studio.

Visual Studio Express

Visual Studio is available in a number of free versions, each designed to provide a simple experience for a particular programming language or task. The Express products are a subset of the full professional versions of Visual Studio. Visual C++ Express is a free download – you can get it from the Visual C++ 2010 Express web site and it can build C++ applications including the SDK samples.

Once you have downloaded and installed Visual C++ Express, you can open any .sln or .vcproj file with it. As above, if you have a .sln file, open that in preference to any .vcproj files in the application. Many of the SDK samples are in Visual Studio 2008 format. If you open them with Visual Studio 2010, it will offer to convert them to the new format. The wizard starts like this:

The samples all convert without issues, so just click Next. There’s no need to keep another backup of the project if it’s a sample you’ve copied from the SDK directory:

Click Next. Read the summary:

Click Finish. For some projects, you may be told about warnings:

Often, the warnings just refer to options and settings that are no longer needed and so have been removed from the project file. If the converted project builds successfully, and it was just a small sample, you need not worry about conversion warnings.

Visual C++ Express lets you edit, compile, and debug your applications all in the same tool. Here’s a project open in Visual C++ Express:

On the left is the Solution Explorer view – a tree control that lets you edit any of the files in your solution. This solution has two projects in it, called SCRTafter and SCRTbefore. (Projects are shown in alphabetical order in the solution explorer.) To edit a file, you can double-click it in solution explorer.

To build the application, use the Debug menu and choose Build Solution. Any error messages will appear in the Output Window, which should appear automatically when you build. If the status at the lower left says Build Failed, but you can’t see your errors, choose Debug, Windows, Output. Often, the syntax errors will be highlighted with red “squiggles” under them even before you build your solution. This annotated screenshot shows red squiggles, the output window, and the build result on the status line:

You can double-click a line in the output window and the editor will open the file and scroll to the line with that error. You get plenty of feedback when you do that:

Notice the gray marker in the margin of the line with the error, the blue highlighting of the selected line in the output window, and the status bar at the bottom which repeats the error message. You can get still more information by hovering the mouse over anything marked with red squiggles to see the error message.

(The green lines in the margins in these screen shots indicate lines that have recently saved changes. Yellow lines denote lines with recent unsaved changes. Since compiler errors are usually on the lines you changed recently, these can be helpful while you are working to get your code building.)

To run the application under the debugger, press F5 or choose Debug, Start Debugging. If you start debugging when the application has not been built since your most recent changes, the solution will be built for you automatically.

Many of the samples are console applications, designed to be run from the command line. When you run them from Visual Studio, they may run to completion and disappear before you can see the output. There are two simple solutions to this problem: either run without debugging (which pauses the application when it’s complete) or set a breakpoint on the last line. Debugging will be discussed later. You can also add code to the application so that it pauses – a popular approach is to call cin.getline, which will wait until the user presses enter.

To run without debugging, press Ctrl+F5. (The simplied menus of Visual Studio Express don’t show you this option, but it’s there.) The black console window will appear on top of Visual Studio and execution will pause so that you can read the output:

This is not an issue with Windows applications, because they stay open until the user exits them explicitly. It’s just a small hurdle you may encounter if you decide to get started by compiling and running sample applications, or command-line applications you’ve written for other platforms.

Detailed instructions on creating and editing Windows applications are in the chapters that follow.

Other versions of Visual Studio

Visual C++ Express is free and you can download and install it, then get started developing for Windows in C++ right away. Yet there are other versions of Visual Studio available, for various prices. You don’t need any of them specifically to do Windows development, but you might appreciate some of their features as you continue developing on Windows. All the solution and project files you develop with Visual Studio Express are perfectly usable in other Visual Studio editions.

You can check Visual C++ Editions for specific C++ features that are not in Visual C++ Express. Some notable differences:

  • Express builds 32-bit applications. By default, it does not build 64-bit applications, though if you install the Windows SDK, you will gain a 64-bit compiler that can be used by Express.
  • The ATL and MFC libraries are not included in Express. While many Windows developers use these libraries, they are not required for writing Windows applications, as you’ll see in the chapters that follow.
  • Profile Guided Optimization, a tool that makes certain applications run faster, is available only in Premium and Ultimate. The Express compiler has an optimizer, of course – PGO is an additional optimization based on actual usage patterns for your application. If you come to need it, that can be a good reason to move up to another edition of Visual Studio.
  • Remote debugging and static code analysis are not available in Express. These are also not mandatory for Windows developers. If you later feel you could use them, you can upgrade to a different version of Visual Studio.

The instructions in the chapters that follow will assume you are using Visual Studio Express. It’s possible you have access to higher versions of Visual Studio. Your screenshots may not match what you see exactly, because those versions have more menu items and may show more choices or information under certain circumstances, but the instructions (what menu item to choose, what button to click) will work for your version of Visual Studio also.