Windows is almost entirely coded in C. The Windows C API is one of the most depended upon API with the largest codebase and the longest documentation in existence.
After Longhorn's failure, they started to focus on COM to be the future of Windows APIs, leading to UWP.
And if masochists can implement COM in C, they need to be quite pain resistant for the UWP update.
In the meantime, the new C runtime was rewritten in C++, using extern "C" entry points.
Windows drivers can be written in C++ since Windows 8, and since then they have been migrating the code to be compilable as the C subset from C++ as well.
The low level API have been fixed for a very very long time. It doesn't really need to change, opening a file is not different now than a decade ago. It gets no love and no popularity, but it runs the world.
Most development is done in higher languages nowadays, typically C#, java or python and all these languages rely on the Windows API to run. They are abstractions of C.
P.S. Drivers could already be written in C++ since Windows XP. There were a lot of constraints though because of running in the kernel.
MFC was the way to write real Windows applications until .NET came around.
Visual Basic was mostly used by not so skilled developers, creating applications that IT department had to take care of, sometimes rewriting them into MFC ones.
Delphi and C++ Builder were the only solid alternatives outside Microsoft world, but thanks to the way they drove prices upwards and the identity crisis from Borland, most developers went away to Microsoft products, as the platform is always a safer better for development tools.
As I mentioned, since Windows Vista all new API are COM, and UWP, which is the future of the platform is COM as well.
UWP is what .NET was supposed to be initially, COM+ Runtime, just that UWP uses .NET metadata instead of COM type libraries and allows for real instances, not only interfaces.
COM is a first class type in .NET given its original design, many of the .NET APIs are COM objects underneath, including the whole CLR native APIs.
Drivers written in C++ on XP only by adventurous coders with their own compilers or hacks somehow, as Visual C++ only supports kernel mode since Windows 8.
> It doesn't really need to change, opening a file is not different now than a decade ago
Actually it has changed.
OpenFile() has been deprecated and replaced by CreateFile(), which was superseded by CreateFile2().
And on Windows 10, CreateFileFromApp() and CreateFile2FromApp() should be used instead, otherwise the application won't run from the store.
And if you want to use any of the goodies from Windows 8 onwards, they are only available as UWP APIs.
So?
If you dislike the app store monopolies, it's stupid to herd your users into the store. Tell your users that your app is too sophisticated to run in dummy mode. Bonus: Sell to all the Win7 holdouts.
If you love app stores (monopoly rents be damned), you rank the store ecosystems and then never write a Windows version.
So regardless of Win32 or UWP, everything will eventually be sandboxed.
Windows 7 is the new XP.
OpenFile() could be considered deprecated but the official documentation doesn't mark it as deprecated.
You missed the point that these API have been stable for decades and software will continue to work without any change.
"OpenFile() has been deprecated and replaced by CreateFile(), which was superseded by CreateFile2()."
I never said CreateFile() was deprecated. Superseded is not the same thing.
> OpenFile() could be considered deprecated but the official documentation doesn't mark it as deprecated.
"Note This function has limited capabilities and is not recommended. For new application development, use the CreateFile function."
Looks pretty much an euphemism for deprecated.
> You missed the point that these API have been stable for decades and software will continue to work without any change.
Not when Windows puts a container around what they can see.
Win7 is a focal point of some importance: It's where developers who don't want to be pushed into app store indentured servitude join up with the Windows compatible systems, Wine and ReactOS.
Everything before Win7 is not a focal point because it's too old. Everything after Win7 is not a focal point because nobody can handle the update threadmill. By elimination, it's Win7.
Win7 is not the new XP; it's the future of stability-oriented Windows compatible computing.