[malkia]

But Visual Studio is not C. It's C#, and even it's C++ parts would be somewhat com-ish, dot-ish. I'm sure Microsoft is well prepared for 32-bit -> 64-bit transition. My guess is that there are probably massive amounts of plugins (not done by them) that are not prepared, especially ones that have to use native code. So Microsoft can't say No there. Just guessing, I dont' know for sure.

[eropple]

Visual Studio is more C++ than you're giving it credit for, it's largely old C++, and making assumptions about how forward-looking that C++ is is probably pretty questionable.

Also, yes, plugins are a large concern.

[prewett]

> making assumptions about how forward-looking that C++ is is probably pretty questionable.

Especially since Visual Studio didn't even compile C++ correctly until fairly recently. Variables declared with `for (int i = 0; ...)` would remain in scope after the loop, the same as if it had been declared outside the loop. I don't know when they fixed that, but I think I ran into this problem as recently as 2010. Meanwhile, GCC and everyone else had been doing it correctly for years.

[Negitivefrags]

The last version of the compiler with that problem was VC6 which came out in 1998. This version was superceded in 2002.

I wouldn’t say 16 years ago was recent. If you really ran into this in 2010 it would have either been using an old toolset or the compiler flag that lets you enable the old behaviour for compatibility if you need it.

[kilon]

Nope, C++ is the undisputed king of coding and I have no love for C++. Not only Windows is mostly written in C++ (and I would not be surprised if they use some C and Assembly as well) but even external projects like Unity (a popular game engine) that suppose to be used only as C# libraries they are just C++ projects. As long as Windows is by far the most popular OS on desktop and Android on mobile devices C++ remains the most essential, well supported, mature although infinitely ugly Programming Language.Because the OS remains still in the center of software development.

[flohofwoe]

I doubt that there's a lot of C++ code in Windows, at least in the lower level system libraries. It should be mostly C (and that's a good thing). The same for Linux/Android and the BSD parts of OSX/iOS.

[pjmlp]

There is plenty of it, specially since Windows 8, which was when C++ code was officially supported on the DDK.

Since they decided they are done with C, Microsoft has been cleaning up Windows code to make their code compliant with the C subset of C++.

Since Windows Longhorn failure, with Vista COM got the main API role for the components that were originally designed to be written in .NET.

Which lead to the design of UWP as improved COM, using the ideas they originally had for Ext-VOS, but decided to create .NET instead.

https://www.reddit.com/r/cpp/comments/4oruo1/windows_10_code...

[flohofwoe]

Ah alright, thanks for the clarification. Nothing in those direction changes convinces me that Windows will improve over WinXP and Win7 though ;)

I really wish the Visual Studio team would give C a bit more love. Getting at least full C99 support in is most likely less work than any random C++17 feature.

[pjmlp]

Their are done with C, there is no more love to give beyond what ANSI C++ requires.

ANSI C++14 requires C99 library, while ANSI C++17 upgraded it to C11.

Microsoft has contributed to improve clang on Windows for those that still want to keep on using C, but then good luck accessing COM and .NET APIs from C, it is possible but I wouldn't do it for fun.

Even the new C runtime library is actually written in C++.

[flohofwoe]

It would be fine with me if I could simply compile any valid C99 or even C11 code with Visual Studio C++ compiler, but C99 support is only half-assed, and C11 support probably will never happen.

D3D11's C API works fine (that's the only Windows API I care about apart from the usual Win32 windowing stuff), but already D3D12 let that rot and is only usable from C with workarounds (doesn't matter though since D3D12 is fairly niche).

All in all it's a shame though because the newer C features are much more sane and useful than anything in C++14 or C++17.