Visual C++: Windows and Console Subsystems


The Subsystem option can be found in any Visual C++ project here: Project → Properties → Linker → System → Subsystem. The choice of Subsystem decides the execution environment for the executable that is compiled from the project. For a Console application, choose /SUBSYSTEM:CONSOLE. For a Windows (GUI) application, choose /SUBSYSTEM:WINDOWS. There are other Subsystems, but these two are the most common.

Entry Point Function

The entry point function of the executable is decided based on the Subsystem. A Console executable begins from a main() function, so this should be present somewhere in the project code. A Windows executable begins from a WinMain() function, so this should be defined. If a windowing library (like wxWidgets for example) is being used, that library code would typically have the WinMain call defined inside.

Preprocessor Definitions

In older Visual C++ environments, the preprocessor definitions _CONSOLE and _WINDOWS corresponded to the above 2 subsystems. They are still defined by Visual C++ when it creates a project. These definitions are not really needed now. But, there might be header files of external libraries that you use, which might look out for these definitions. So, it might be a good idea to not delete them if you face errors.

Switching Subsystems

To switch a Visual C++ project from Console to Windows or vice versa, both the Subsystem and the Preprocessor Definitions need to be changed.


A project has a mismatched Subsystem when its code is written for Console and its Subsystem is set to Windows or vice versa. This manifests itself in errors like:

MSVCRTD.lib(crtexew.obj) : error LNK2019: unresolved external symbol _WinMain@16 referenced in function ___tmainCRTStartup

To fix this, make sure the Subsystem matches the code, else switch it.

Visual C++: CRT Source Code

The source code of the C Run-Time library (CRT) of Visual C++ can be found in the directory: C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\crt\src

Exploring the code, one sees that most of the C functions end up calling the Win32 API. The C++ library is licensed from Dinkumware. So, one can see the name of P. J. Plauger who created these files at their bottom. There are a few assembly files too (*.asm), which are mostly for memory and string operations.

C Run-Time Libraries in Visual C++

Every Visual C++ project is linked with a C run-time library. This is called the CRT in Microsoft literature.

Depending on the support for multi-threading there are 2 kinds of CRT:

  • Single threaded CRT: This can only be statically linked. This CRT is used if one of the compiler options /ML or /MLd is specified. It would be linked with libc.lib or libcd.lib respectively for Release and Debug modes. The single-threaded CRT is completely deprecated and should not be used! 😡
  • Multi-threaded CRT: This is the default kind of CRT and should be used always.

The type of linking (static or dynamic) and the configuration (Release or Debug), lead to 4 kinds of multi-threaded CRT:

  • Release mode and statically linked: Specified using the compiler option /MT. The library file used is libcmt.lib.
  • Debug mode and statically linked: Specified using the compiler option /MTd. The library file used is libcmtd.lib.
  • Release mode and dynamically linked: Specified using the compiler option /MD. The library file used is msvcrt.lib and the DLL file used at run-time is msvcr100.dll (depends on Visual C++ version).
  • Debug mode and dynamically linked: Specified using the compiler option /MDd. The library file used is msvcrtd.lib and the DLL file used at run-time is msvcr100d.dll (depends on Visual C++ version).

Reference: C Run-Time Libraries at MSDN.

CPPUnit that compiles with Visual C++ 2010

CPPUnit is a unit testing framework that is a port of the popular JUnit framework. Work on it has stalled and there has been no release since 2008. Work has continued on a fork called CPPUnit2.

The last released version of CPPUnit is 1.21.1. I needed it for a project, but compiling it with Visual C++ 2010 ended in lots of errors. I got it compiling after making some changes. This version can be downloaded from here.

The changes are:

  • The DSPlugIn project was removed.
  • The version was changed to 10.0 in the MSDevCallerListCtrl.cpp.
  • Changes made to the naming of .exe, .lib and .dll files produced by the projects in the CPPUnit solution.

Visual C++: Files and Directories

Visual C++ does not respect (or use) the underlying directory structure of your existing source code files. Some may find this to be a failing, but I personally think this is a feature. It allows you to organize your files in the way you want into one (or more) projects inside Solution Explorer.

Visual C++ Files

If a simple Visual C++ solution named Foobar is created with source files named Main.cpp and Main.h, it will have the following structure:

|   Foobar.sln

Foobar.sln is the Visual C++ solution file and Foobar.vcxproj is the Visual C++ project file. A solution can contain one or more projects. By default, when a solution is created, one project is created in the same name as that of the solution.

If another project named Foobar2 is added to the Foobar solution, the directory structure would look like this:

|   Foobar.sln
|       Foobar.vcxproj
|       Main.cpp

The solution file (Foobar.sln) and the project files (Foobar.vcxproj and Foobar2.vcxproj) are the only non-source files that are needed. Visual C++ might create a few more files and directories, all of them are not essential. So, if you plan to use a version control system (like Subversion or Mercurial) on this solution, you only need to backup .sln, .vcxproj, .cpp and .h files. For the comprehensive list of Visual C++ files that need to be checkedin to version control see this post.

Directory Structure

You can setup a convenient directory structure inside the directory that contains Main.cpp and Main.h. For example, creating a directory Foo with source files Foo.cpp and Foo.h:

|   Foobar.sln
    |   Foobar.vcxproj
    |   Main.cpp
    |   Main.h

No matter what is the directory structure, the source files can be imported into the Foobar Visual C++ solution and arranged in any fashion the user wants. The root directory of the Foobar project is Foobar/Foobar.

Including Directories

Header files at the root directory of the project can be directly included:

// Main.cpp
#include "Main.h"

For the header files lying inside directories of the project root directory, there are 2 ways to include them:

  1. Include the header file providing the relative path from the source file to the header:
    // Main.cpp
    #include "Main.h"
    #include "Foo/Foo.h"
  2. Open Project → Properties. Choose C/C++ → Additional Include Directories and add Foo. To add more include directories to the project, separate them with semicolons. The header files in the Foo directory can now be included without specifying any path in any .cpp or .h file in the project:
    // Main.cpp
    #include "Main.h"
    #include "Foo.h"

As you might deduce, strategy 1 gets messy pretty quickly since each file that includes another header needs to know the path that leads to it. For example, to include Main.h in Foo.cpp:

// Foo.cpp
#include "../Main.h"

Compared to this, using strategy 2 one can include any header file in any source file without worrying about the directory where it lies. This is much easier to apply across the directory structure of a project.

Visual C++: #pragma message

What if a programmer wants to draw attention to certain sections of code in certain source files? This could be for oneself or other team members. It could be certain work-in-progress, debugging or warning messages to watch out for. This could be for today or when one comes back to this code a long time later in the future.

One elegant and convenient way to achieve this is by using #pragma message. When the compiler finds a #pragma message, it outputs the message string to the Output window of Visual Studio. #pragma message strings can be left at the sections of code one wants to be signaled about. This way, even if a programmer comes back to some very old code, as soon as he compiles it the compiler signals him about certain information to watch out for in the code.

Using #pragma message is easy, like this:

// Foo.cpp
// ... Lots of Foo code ...

#pragma message( "HACK: Count of foo items updated! REMOVE later!" )
extern int debugCount;

// ... Lots of Foo code ...

#pragma message can be tweaked to also output other information like the filename, line number and timestamp. Please see the MSDN article on #pragma message for more on that.

Note: The #pragma message output by the compiler can easily get lost in the Output window if the code produces lots of other warnings and errors. So, this is yet another reason why it is a good habit to make sure the code compiles with ZERO warnings and errors! 😉

Visual Leak Detector: Investigate Memory Leaks in Visual C++

Memory leaks are a part of life in C++. By default, Visual C++ looks for memory leaks when the program is executed in Debug mode. If any memory leaks are found when the program exits, it reports them in the Output window like this:

Detected memory leaks!
Dumping objects ->
{1372} normal block at 0x04BE1058, 136 bytes long.
Data: < 3-kt*-k        > 9C 33 2D 6B 74 2A 2D 6B C8 11 BE 04 00 00 00 00
Object dump complete.
The program '[408] Foobar.exe: Native' has exited with code 0 (0x0).

The leak information that it spits out is about memory blocks. The information that can be gleaned from this output is:

  • Memory block allocation number: 1372
  • Memory block type: normal
  • Memory block starting address: 0x04BE1058
  • Memory block size: 136 bytes
  • First 16 bytes of memory block data

This memory leak detection by Visual C++, which is always enabled in Debug mode, is very useful since it will always find a leak if it exists. Once the leak is known however, it is hard to figure out the source of the leak by examining the above information.

More probing along this line can be done using the definitions and calls from crtdbg.h. This is quite cumbersome and cannot always point out the source of the leak. Comprehensive information on this can be found in the MSDN article on Memory Leak Detection and Isolation.

Visual Leak Detector

Visual Leak Detector (VLD) is an open-source alternative to investigate these memory leaks. Using it is very simple and straightforward:

  • Download and install VLD. The installer will prompt about adding its bin path (C:\...\Visual Leak Detector\bin) to the PATH environment variable. Accept it or add it manually yourself. Either way, you will need to log out and log back in for the addition to the PATH to take effect. vld.dll and dbghelp.dll, from the bin directory need to be available on the system path.
  • Make sure the Visual C++ project is in Debug mode.
  • Add the VLD include path (C:\...\Visual Leak Detector\include) to the Include Directories of the project.
  • Add the VLD lib path (C:\...\Visual Leak Detector\lib) to the Additional Library Directories of the project.
  • Add #include <vld.h> to any of the C++ source files in the project. This header will bring in vld.lib during the linking stage.
  • Rebuild the project and execute the compiled program in Debug mode. On program exit, VLD will print out the memory leak information it detected in the Output window.

The memory leak information printed by VLD looks like this:

---------- Block 1199 at 0x04BE1058: 136 bytes ----------
Call Stack:
d:\Foobar\FooLog.cpp (26): FooLog::getInstance
d:\Foobar\FooMain.cpp (75): FooMain::init
f:\dd\vctools\crt_bld\self_x86\crt\src\crtexe.c (578): __tmainCRTStartup
f:\dd\vctools\crt_bld\self_x86\crt\src\crtexe.c (403): WinMainCRTStartup
0x759A3677 (File and line number not available): BaseThreadInitThunk
0x770C9D42 (File and line number not available): RtlInitializeExceptionChain
0x770C9D15 (File and line number not available): RtlInitializeExceptionChain
9C 33 2D 6B    74 2A 2D 6B    C8 11 BE 04    00 00 00 00     .3-kt*-k ........
00 00 00 00    70 14 BB 6C    70 14 BB 6C    00 00 00 00     ....p..l p..l....
00 00 00 00    68 14 BB 6C    68 14 BB 6C    00 00 00 00     ....h..l h..l....
00 00 00 00    6C 14 BB 6C    6C 14 BB 6C    20 12 BE 04     ....l..l l..l....
00 00 00 00    CD 00 CD CD    00 00 00 00    01 CD CD CD     ........ ........
68 14 BB 6C    78 33 2D 6B    00 00 00 00    00 00 00 00     h..lx3-k ........
00 00 00 00    01 02 00 00    06 00 00 00    00 00 00 00     ........ ........
00 00 00 00    00 00 00 00    88 11 BE 04    5C 10 BE 04     ........ ....\...
00 00 00 00    20 CD CD CD                                   ........ ........

We can note the following information from this output:

  • The block allocation number output by Visual C++ leak detection and by VLD do not necessarily match.
  • The memory block address and size information of Visual C++ and VLD match. This confirms that this VLD information is about the same memory block as that reported by Visual C++. This is useful when the program has multiple memory leaks. The programmer can then match each of the Visual C++ memory leak to the corresponding VLD memory leak information.
  • VLD provides a lot of information: the entire call stack trace with function call names, source code filenames and line numbers. It also prints out a lot more data from the memory block.

By looking at the sourecode filename and the line number in it, the programmer should be able to get solid leads to the memory leak and hopefully be able to fix it. 🙂

Visual C++: Iterator Checks and Slow STL Code

Visual C++ turns on a lot of checking on STL iterators when compiled in Debug mode. This is very helpful since any mistake with an iterator leads immediately to an exception with a helpful exception message. This can catch latent bugs much much earlier while programming.

However, this huge amount of security is sometimes not tolerable by everyone. For certain applications the debug mode with all the iterator checking turned on can be extremely slow, to the point of being useless. I faced a similar problem and so had to investigate to find the reason for the slow behaviour. I discovered that there are 2 mutually exclusive checking mechanisms in the STL of Visual C++: checked iterators and iterator debugging.

Checked Iterators

Checked iterators is controlled by the preprocessor definition _SECURE_SCL. SCL is Microsoft jargon for Standard C++ Library. So, this is a feature by Microsoft to provide some amount of minimal security on the usage of STL iterators. The overhead of _SECURE_SCL is so low that by default it is ON for both Release and Debug modes. So, _SECURE_SCL is rarely the cause of your program being slow. It should be left at its default options.

Iterator Debugging

Iterator debugging is a whole another beast. It involves a lot more intensive checking on the validity of iterators. It does this both when iterators are dereferenced and when containers change internally. This was implemented by Dinkumware, who are the creators of the STL implementation that Visual C++ ships with.

By default, iterator debugging is turned ON for Debug mode and OFF for Release mode. Typically it is not slow for Debug mode, but if the C++ code has a lot of loops over STL containers and uses iterators heavily, then it can make everything very slow. How slow can it get? This is the difference I saw in one of my programs compiled in Debug mode:

Iterator Debugging ON: 51.83 sec
Iterator Debugging OFF: 0.27 sec

Yes, iterator debugging was a jaw-dropping 192 times slower! Not just that, at ~52 seconds of execution, this program was unusable for my purpose!

Iterator debugging is controlled by the preprocessor definition _HAS_ITERATOR_DEBUGGING. To turn off iterator debugging, add _HAS_ITERATOR_DEBUGGING=0 to the Preprocessor Definitions in C++ → Preprocessor section of the project properties.


  • STL Iterator Debugging and Secure SCL video on Channel 9 by Stephan T. Lavavej. A must watch video for anyone using STL on Visual C++. Stephan explains both Secure SCL and Iterator Debugging and how they are implemented internally in the library. Also explained is when and which of these options to turn ON or OFF.

Visual C++: Keyboard Shortcuts

Every programmer has his favorite keyboard shortcuts. Here are mine for Visual C++, from most used to least used, with some comments:

  • Jump to definition: F12
  • Jump to declaration: Ctrl + F12
  • Jump back (from any earlier jump): Ctrl + –
    • The above 3 keyboard shortcuts are my key tools to peek into and understand any C++ code.
  • Compile currently open .cpp file: Ctrl + F7
    • Every C++ programmer knows how frustratingly slow C++ compilers are! It is faster to first compile the currently modified file and proceed with a full solution build only if this succeeds. I typically keep compiling the current file while incrementally modifying a file and do a full build only much later when that part is completely coded.
  • Build solution: F7
  • Execute with debugging support: F5
  • Execute without debugging support: Ctrl + F5
  • Add or remove breakpoint on current line: F9
  • Find in entire solution and list in Find Results window: Ctrl + Shift + F
    • The normal find (Ctrl + F and F3) only jumps to one result and the user can jump around from there. I find the listing of all occurrences in a separate window much more useful. I can see all the files where it is used and also see one line of usage in them. This is very useful to understand and refactor code.
  • Full Screen: Alt + Shift + Enter
    • Visual Studio non-editor windows take too much space and combined with the Windows taskbar, they are all huge distractions while coding and debugging. So, I always work in full screen mode and switch back to normal size only to fix compile errors. But, the above default keyboard shortcut is hard to enter without causing side-effects, since it has Enter in it. So, I map this action to Ctrl + M, Ctrl + M instead. That is, keeping Ctrl pressed and press M twice. This is the keyboard shortcut for full screen in Eclipse. I find it easier to type and remember: M → Maximize 🙂
  • Delete line: Shift + Del
    • Useful while deleting many lines of code, which happens almost all the time.
  • Add or remove bookmark: Ctrl + K, Ctrl + K
    • Easy to remember: bookmark ends with a K 🙂 I find it very useful to leave a breadcrumb trail of bookmarks on lines where I need to modify or check code.
  • Jump to next bookmark: Crtl + K, Ctrl  + N
    • To follow the breadcrumb trail of bookmarks.

LNK4098 Linker Warning in Visual C++


C++ code when compiled can produce the linker warning LNK4098 at the final linking stage. This warning is of the form:

warning LNK4098: defaultlib 'LIBCMTD' conflicts with use of other libs; use /NODEFAULTLIB:library

What does this mean?

It means that  more than one kind of C run-time library has been used in the project! This is the cause of the conflict. The different types of C run-time libraries can be seen here.

How to fix it?

One source of conflict is different source files being compiled with different options. Examine the Runtime Library properties of the each of the source files in the solution. Open Project > Properties and this option can be found at C/C++ > Code Generation > Runtime Library. There might be some files which differ in the Runtime Library they are using. For example, Foo.cpp might be compiled with Multi-threaded DLL (/MD) and Joe.cpp might be compiled with Multi-threaded (/MT). To fix this warning, change the Runtime Library settings so that they are uniform across all the files of the solution.
Example: I typically notice these warnings when there are external Build Rules being used in the solution. For example, CUDA files (.cu) are typically compiled with a different Build Rule that invokes the CUDA compiler (nvcc.exe). The Runtime Library option within this Build Rule might not be matching the Runtime Library option of the solution, thus resulting in this warning.

Another possibility is the external libraries being linked with the project. Examine the library files being explicitly linked with the project and ensure they are compiled with the same run-time library options as that of the project.

If the above options fail or are not feasible, use the /NODEFAULTLIB option set to ignore the specific library that is causing this warning. That is, LIBCMTD in this case. To do this, go to Project > Properties > Linker > Input > Ignore Specific Default Libraries and add the filename of the offending library. For example, add LIBCMTD.lib in this case. This generates a compile option /NODEFAULTLIB:LIBCMTD.lib during compile time that excludes this library during linking.