When developing games for Windows, WinRT, eventually Windows Phone 8, many of us prefer C++ as platform because of the performance, the code base and existing engines.

To that end, DirectX tends to be the norm. However, interacting with DX can be difficult, and it certainly doesn't provide a common ground for game development.

To that end, Microsoft created a wonderful library: XNA. Unfortunatelly, this library works only for the managed world. I do reckon the benefits of XNA, but I'd like to have them for native development.

Therefore, I propose a library akin to XNA, but for C++, with the following requirements.

1.- The library should contain classes that allow us to work with graphics, audio and input, and should be built atop of DirectX 11.
2.- The library should follow the conventions of the C++ standard library.
3.- The library should make use of as many C++ 11 features as possible, as well as the C++ standard library.
4.- Optionally, the library could rely on the already released C++ AMP library.
5.- The library should cover 2D and 3D gameplay, by creating the necessary classes for managing basic shapes, meshes, sprites, textures, maps, etc.
6.- Perhaps network connectivity could rely on recently released Casablanca library.

Would such a wish be possible?

There are a number of .h and .inc files that are referenced by source files in the CRT source but which are not included in the CRT source code, specifically:
ksamd64.inc
strchr_sse.inc
strrchr_sse.inc
strstr_sse.inc
coresyslibs.h
ehassert.h
ehhooks.h
ehstate.h
internal_safecrt.h
ksarm.h
kxarm.h
nowin.h
pch.h
rtti.h
trnsctrl.h
undname.h
vcver.h
vcwininternls.h
xmm_func.h

Some of them are referenced by name in MSDN articles, e.g. http://msdn.microsoft.com/en-us/library/ff770587%28v=vs.110%29.aspx references rtti.h by name.
It would be nice to have these header files so that when reading the CRT source code one doesn't bump into things that are defined or declared in .h files that you cant then go and read.
It would also be nice if the Visual Studio guys and the MSDN docs guys could make sure that if a MSDN documentation page references a specific header file, that header file is actually included with the product so we can use it. (or alternatively if its something we are not supposed to use, it should not be documented on MSDN)

It would also be nice to see more CRT source code released, especially for the structured exception handling logic and floating point support (or if there are valid reasons why it cant be released, those reasons should be given so people know why it cant be released and stop asking about it)

1) Put "Start without debugging" into the Right click menu for a particular project.

This is just smoother than "Right click a project, select "Set as Startup Project", Use Control+F5 or Debug | Start Without Debugging", and then go back to the project that you want to debug and Right click to "Set as Startup Project", and then do F5 to debug.

The current behavior is clumsy when you have two projects that interact such that you need to run one without debugging first, and the other with debugging second..

This was also suggested in 2006:
https://connect.microsoft.com/VisualStudio/feedback/details/111466/right-click-start-without-debugging#tabs

2) Make "Start without debugging" and "Start debugging" consistent for console programs at termination.
"Start without debugging" keeps the console program visible after the program stops.
"Start debugging" closes the program without letting you see what happened.

I don't think there is a good reason for this divergent behaviour. It is annoying to put a break point at the end of the program to be debugged each time, and I suggest that Visual Studio always stops after a console program has terminated to show the result.

I suppose you could make it optional in the project properties too.

It is good to add a C++(and other languages') interpreter for rapid development. An interpreter is very convenient and saves quite some time. The most important use of the interpreter is conceptual scripting. Users may transform basic concepts into scripts through line-editing, using an interactive command-line interpreter, before improving their idea into real and complete programs. It is also useful for new learners to use interactive interpreters for learning languages, in this way they can test and figure out if something works correctly, because interpreters can produce immediate results in an interactive session. Moreover, it helps programmers who uses interpreted languages(Python, Ruby, Perl., ect) to more quickly get used to .NET compiled languages. Finally, some C++ programmers rather chose other IDEs (like Ch) but not Visual Studio for programming in C++ solely because Ch has an interpreter.

Here is a common use case to debug data change. Make it an item in context menu in Watch.

1. drag-and-drop a structure member on a Watch window.
2. Insert & in front of it to take its address
3. drag-and-drop the address value into Watch window again , because there's no way to easily copy just the address of the variable or member
4. Copy the address of the variable or member
5. Go to Breakpoints window
6. Choose "New"->"New Data Breakpoint"
7. Paste the copied address of the variable or member.

That's quite a bunch of clicks thousands of C++ developers have to do every day. Hopefully it's trivial to add to VS IDE