Personally I would like to see proper C++11 support instead of playing around with C++/CX and while they are at it, either provide a native compiler for .NET or improve NGEN's optimizer for C++ performance level.
Given that Microsoft had .NET native compilers for Singularity and Windows Phone 8 .NET apps are compiled to native code, it isn't as if they don't have the tooling already available.
Many cross-platform libraries are written in C. Microsoft's terrible support for C causes those projects a significant amount of pain. If the upstream library developers don't have time/interest to restrict their dialect to avoid various C features and to test regularly with Microsoft compilers, they either (a) drop support for Windows, or (b) only support Windows via non-Microsoft compilers. Neither of these options are very appealing for users of those libraries on Windows.
The Windows kernel is C++. From what I've seen (shared source), it's mainly C-style C++ though. I didn't see a single template or a class in my travels.
it's in C. as it was explained to me once, the compiler team asked the kernel team if they would be fine fixing C support at C89 and the kernel team said "sure". being the largest and most important consumer of the compiler (at the time, possibly still today) that was that.
the kernel team is also pretty slow to adapt new C compilers and you can see this by watching the lag in compiler versions released in the driver development kit vs those released with visual studio.
What? Since when was the last time C++ ever produced external symbols readable by anyone else?
If mangling/decoration of symbols was standardized, and how to structure vtables, and how to handle exceptions, and etc. etc. etc. - then I can say "C is officially deprecated". Until then - C is still the lingua franca for native development.
Write in C++ all you want, but expose "C" interface - you would be accessible much easier from anywhere else.
Sometimes it's harded than that. For example in Windows XP, if you have __declspec(thread) variable then it won't work if it's in DLL (this has been fixed since Vista).
Not really a compiler, but more like linker/loader problem. If the __declspec(thread) is in the main .exe it works.
Things like this affect for example ANGLE (WebGL) when compiling for XP, as such one would have to resort to TlsAlloc/TlsFree.
It's just an example, where an OSS might've used the gcc/clang primitive for thread-safe var, and later someone does it for Visual Studio, only to understand later that it won't work when in DLL for XP.
Now I know XP is no longer supported, but a lot of OSS projects still target it. (and probably lots of others).
Then again, it's not such biggie, for example Elmindreda, the GLFW developer was really kind to re-implement the feature once I reported the problem.
Personally I would like to see proper C++11 support instead of playing around with C++/CX and while they are at it, either provide a native compiler for .NET or improve NGEN's optimizer for C++ performance level.
Given that Microsoft had .NET native compilers for Singularity and Windows Phone 8 .NET apps are compiled to native code, it isn't as if they don't have the tooling already available.