In almost every text about the new WinRT API I came to statements like "WinRT is the new API for Windows and replaces the old Win32 API". Since WinRT aims the development Windows Store apps, this statement to me does not seem to hold true.
There are lots of applications I just can not imagine to be done with WinRT (e.g. Microsoft Office, Adobe Products, 3D Designer Programs and even Visual Studio). These applications still need the functionality of the Windows API (aka Win32).
So why is it so often said, that the WinRT API replaces the Windows API?
In the context of the Windows 8 operating system (OS), the Windows Runtime Library (WinRT) is the default application programming interface (API) used by the OS. It does not replace the Win32 API that has been running underneath all Windows applications, but rather augments it.
WinRT can be described as an API at the same level as Win32. The only difference with Win32 is that WinRT is exposed to all application developers.
WinRT allows developers to create safe "sandboxed" touchscreen applications available from the Microsoft Store. WinRT apps support both the x86 and ARM architectures and multiple programming languages, including C/C++, C#, Visual Basic and JavaScript. WinRT was augmented by the Universal Windows Platform (see UWP).
The Windows API (application programming interface) allows user-written programs to interact with Windows, for example to display things on screen and get input from mouse and keyboard. All Windows programs except console programs must interact with the Windows API regardless of the language.
I'm not sure if it's often said that the Windows Runtime (WinRT) API replaces the Win32 API. It's not something Microsoft is saying. In many ways WinRT tries to learn from the failure of the .NET Framework to replace the Win32 API. That includes Microsoft not trying to push WinRT as a replacement, but merely a new way of doing things.
There isn't actually much of a reason why the applications you mentioned couldn't be be implemented using the WinRT API. The new API includes a lot of the functionality of the old. You can write WinRT applications in C++ and the resulting applications are native executables, not managed ones. It's even possible to use a subset of the Win32 APIs.
While Adobe has little to gain by porting its applications to WinRT, expect Microsoft to do so. They rewrote most of Visual Studio to use the .NET framework. If anything the WinRT API makes it practical to implement much more of it the new environment.
This has kind of changed, recently due to a couple reasons, but here's the rundown of why you want to use WinRT over Win32 in current Windows application development (circa 2017):
Ergo, using WinRT will invoke less time spent converting projects and code for the new Windows 10 S Store-only application paradigm.
In regards to WinRT vs. Win32API vs. .NET, both .NET and WinRT are partially built with Win32; IIRC, they use subsets of it. At least that's what was communicated back in 2012 from ArsTechnica in Peter Bright's article, "Turning to the past to power Windows’ future: An in-depth look at WinRT". That's where this stack chart comes from, or at least it was used there:
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With