14

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?

Richard Chambers
  • 16,643
  • 4
  • 81
  • 106
Sam
  • 1,301
  • 1
  • 17
  • 26
  • 4
    Microsoft is aiming for a "universal" application platform that works uniformly across all devices, such as phones, desktops, laptops, and notebooks. The legacy Win32 API has been such an integral part of Windows development throughout its history, it's been nearly impossible to replace it entirely. The desire, good, bad, right, or wrong, is to position WinRT to point developers in the direction of what are called Windows Universal Apps. – David W Jul 07 '15 at 16:06
  • Microsoft tried the same thing when they introduced .NET, and look how (not) well that turned out. – Remy Lebeau Jul 07 '15 at 17:11
  • 6
    It's just the "next trendy thing", wait long enough and it will go away again. – Jonathan Potter Jul 07 '15 at 21:39
  • 2
    Hi Sam, things have changed for this question in the last year. Please check my new answer in case it impacts you or your team. – kayleeFrye_onDeck Jul 13 '17 at 21:56

2 Answers2

9

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.

Ross Ridge
  • 38,414
  • 7
  • 81
  • 112
  • Thank you for your reply. Actually the .NET Framework seems to be build upon Win32 (or at least parts of it) as you can see if you look inside the Frameworks implementation. The applications I mentioned use for example lots of sub windows. And Visual Studio requires to do a lot of things which are not allowed with WinRT. How would you debug an application if access to it is forbidden by other applications (sandboxing)? – Sam Jul 07 '15 at 20:51
  • 1
    Sure, .NET uses Win32 but that doesn't mean it wasn't meant to replace Win32. Win32 itself is built on the native NT API. Just like how no one uses the native NT API, Microsoft expected that .NET would replace Win32 and no one would use the Win32 API anymore. I'm not sure what you mean by "sub windows", but WinRT (now) supports multiple windows. Not all of Visual Studio can be implemented using the WinRT API, at least as it now stands, but much of it can. The API isn't fixed in its current state. – Ross Ridge Jul 07 '15 at 22:39
  • 1
    Also WinRT itself uses the Win32 API similar to how .NET does. It's not a replacement API in that sense either. – Ross Ridge Jul 07 '15 at 22:41
  • When was it ever claimed that the .NET Framework was supposed to replace the Win32 API though? That makes zero sense at all because the entirety of .NET Framework is implemented upon Win32. – user3700562 Nov 11 '21 at 12:48
9

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

kayleeFrye_onDeck
  • 6,648
  • 5
  • 69
  • 80
  • 6
    "All apps required to go through the store". The sun has not yet risen on a day where I would find that something positive. Back in the day of the first PDAs with Windows CE you could program your own devices without any outside involvement. That is a feature. I have computers to compute - my way. And I do not need some company to loop into my development cycles. My device - my code. No one else needs to be in the loop. – BitTickler Oct 11 '18 at 19:04
  • I'm not going to even try to defend their design :) – kayleeFrye_onDeck Oct 15 '18 at 18:55
  • that kinda defends it though: " why you want to use WinRT over Win32" – j riv Jul 01 '19 at 18:16
  • Where is windows 10 S now huh? actually never heard of until now – Shahrooz Jun 13 '23 at 19:14
  • 1
    @Shahrooz right? So much time wasted. – kayleeFrye_onDeck Jun 29 '23 at 00:58