CODEWITHSUNDEEP
windowsapiwinapiwindows-runtimedesktop-bridge
Sam
Sam

Reputation: 1692

Why is it said that WinRT replaces the Windows API

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?

Upvotes: 15

Views: 11248

Answers (2)

kayleeFrye_onDeck
kayleeFrye_onDeck

Reputation: 6958

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):

  1. WinRT is leveraged by UWP apps
  2. Win32 apps can be converted into UWP apps using the Desktop Bridge
  3. Windows 10 S requires all apps to go through the Windows Store

enter image description here

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:

enter image description here

Upvotes: 10

Ross Ridge
Ross Ridge

Reputation: 39551

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.

Upvotes: 9

Related Questions