Why is the Visual Studio runtime library source code stored in two directories?
The CRT sits at the bottom of the Visual C++ libraries stack: the rest of the libraries depend on it and practically all native modules depend on it as well. It contains two kinds of stuff: (1) the C Standard Library and various extensions, and (2) runtime functionality required for things like process startup and exception handling. Because the CRT sits at the bottom of the stack, it is the logical place to start the process of stabilizing the libraries.
From The Great C Runtime (CRT) Refactoring by James McNellis:
(1) We ship most of the sources for the CRT with Visual Studio; you can find them in the Visual Studio installation directory under VC\crt\src.
(2) In Visual Studio 2013 there are 6,830 #if, #ifdef, #ifndef, #elif, and #else directives in the sources that we ship with the product; in the Visual Studio "14" CTP there are 1,656. These numbers do not include directives in headers and they do include the STL source files which are largely untouched by this refactoring effort, so this isn't a perfect measurement, but it's indicative of the amount of cleanup that's been done.
The include directory has all of the public headers. These are headers that you can include in your code, like <stdio.h> and <type_traits>, plus implementation headers required by those headers.
The crt\src directory contains the CRT sources, including most of the .asm, .c, and .cpp files used to build the CRT. This directory also has a copy of many of the CRT headers, and in some cases these headers are different from what are in the include directory. This is purely an artifact of how the CRT was built.
When debugging into inline code defined in the CRT headers, the debugger should always pick the right header. If both directories contain the same copy of a header, then the debugger will just pick one and since the headers are the same it doesn't matter which one it picks. If the headers are different, then which header the debugger picks depends on the object into which the inline function was compiled. If the object is part of the CRT, you'll step into the header from crt\src; if the object is from one of your source files, you'll step into the header from include. Basically, the debugger should always be able to find the correct copy of the header.
We've greatly simplified this in the Visual Studio "14" CTP. There are no longer any public headers in the crt\src directory, and the headers that are shipped in the include directory are the same ones that were used to build the CRT.