Stopbyte

What is the difference between WinRT, UWP (Universal Windows Platform) and WPF?

Hi there,

I am a WPF programmer for couple years now, I have enough experience on it, but after I installed Visual Studio 2015, I started having some kind of confusion, First there are windows forms projects (the usual thing), WPF projects (the thing I do best), then there are two new project types:

WinRT and UWP (Universal Windows Platform).

Can you please explain me the difference between all of those frameworks, WPF, WinRT and UWP.

thanks in advance

10 Likes

Here is how “I see it”:

UWP (Universal Windows platform), Metro and WinRT are all results of Microsoft’s latest changes, Microsoft made so many changes to its app frameworks in a very short period and I believe that’s the reason behind that confusion, you and many other developers have.

Here is the little Confusing story behind those frameworks:

  • Metro Apps
    For Windows 8, Microsoft had plans to move everything to Tablet and mobile, and start getting rid of PC, for that they invented that thing named Metro Apps. As you may have noticed, Metro apps, appeared once, and then after less than a year, they disappeared.

  • WinRT
    As expected Microsoft Was wrong “PC still Alive” so they had to make an urgent release after the big fat failure of Windows 8, for that they released the Windows 8.1, and they pushed all the ideas they had into that release (majority of the ideas were at beta and not complete as WinRT), WinRT was the main framework distributed under Windows 8.1 for the first time, WinRT was tended to replace Metro Apps and mainly to replace the Old Windows API “Win32”.

  • UWP
    Universal Windows Platform Apps, was finally released under Windows 10, and you can consider it as a successor of the WinRT, it’s the same technology, but just different Version with a few features, main feature UWP has is that all UWP Apps can run in PC, Tablet, And Phone with almost the same binaries. it’s still fresh technology but it’s worth learning for near future.

  • As for WPF
    is the Old framework that was invented to make Rich UI Desktop Applications For PC.

  • Windows Forms
    A Dead Technology, it’s only under maintenance now, no updates will be released anymore for that.
    You might notice that all those Technologies WinRT, UWP and WPF have similar syntax, Objects, Controls…etc, but don’t let that fool you WinRT, UWP are not Based on WPF at all, though they both have .XAML files.

11 Likes

I don’t think that someone can actually explain it better than @jms did already, but the only thing i would like to highlight here is concerning Windows Forms .NET Technology.

i really don’t think it’s “Dead” yet or will be anytime soon, especially that Microsoft has just made it (.NET entirely) Open source, and It was released only less than a decade ago. For sure WPF and similar technologies are taking almost all the attention that Windows Forms got but is still under heavy development. and i don’t think it will die any time soon.

2 Likes

You are very much right, and i believe programmers usually confuse those technologies WinRT, UWP, and WPF because they all use XAML files…while they are entirely different frameworks…though should admit that being familiar with WPF will make it absolutely easy to move to WinRT & UWP

@jms there are a couple problems with this answer:

  • Metro style apps was just what modern apps were called during the Win8 public preview period. They were officially named Windows Store apps before release, but were still the same thing, and 8.1 didn’t make any fundamental changes, just additions. Universal apps in Win10 are still more or less the same thing technically, but follow different UI patterns.
  • WinRT was introduced in Win8.0, 8.1 just expanded the API surface as did 10
2 Likes

This is a bit confusing because in Windows 8.x, “Windows Runtime” was actually used to refer to a few different things:

  1. A new pattern (and supporting code/OS components) for defining and consuming Windows APIs, meant to largely supersede “Win32” (i.e., flat C-style) and classic COM for new APIs in most scenarios. This was/is really about language interop: allowing the Windows team (and potentially others) to create components in C++ that expose APIs that don’t depend on GC or a runtime like the CLR, but still feel relatively natural to use from C# or JavaScript without needing manually written wrappers.

  2. The set of Windows APIs that follow the above pattern.

  3. A new platform/environment for building and running a new type of Windows app, which are meant to have some of the characteristics of mobile and web apps in terms of causing fewer potential problems with system security, reliability, performance, battery life, etc. This is what evolved into UWP with Windows 10. In the Windows 8 days, these apps were called “Metro style apps” during most of 8.0’s public preview period, and officially dubbed “Windows Store apps” just before RTM. The platform/environment for these apps … officially didn’t really have a name (other than “platform for Metro style apps”). Unofficially, people (including at Microsoft) sometimes referred to it as “Metro” (a whole can of worms in itself) or … “WinRT”.

So what’s the relationship between WinRT “proper” (definitions 1 and 2), and unofficial WinRT definition (3) aka UWP aka the formerly-nameless “platform for Metro style apps”? Well, since WinRT and the new app platform were both introduced in Windows 8, most of the WinRT APIs at that time were specific to the new platform. The app platform (and Store policy) at the time was also much more restrictive about which legacy Win32 APIs were allowed for use in apps - for the most part this was less about any technical limitation and more about the team hoping to use the new apps as an excuse to clean up the bloated Win32 API surface.

But technically, WinRT is meant to be the common pattern for new Windows APIs in general, whether used in UWAs or not, and “UWA vs. classic app” and “WinRT vs. Win32” are mostly independent; over time, they’ve gradually enabled more WinRT APIs for use outside UWAs and also relaxed their policies on using a lot of legacy Win32 APIs in apps (and also continued to introduce new flat C-style APIs for certain use cases).

So to summarize, it’s not technically accurate to say that “UWP replaced WinRT”, though understandable since this stuff is pretty confusing. UWP replaced the nameless app platform (3); essentially it’s just an updated version that’s been ported to other device types and integrated with the classic desktop UI. WinRT, in its proper definition (1), continues to be the basis for new Windows APIs for use in UWAs and even outside them.

As for WPF, it was a UI framework that originated at a time when Microsoft was trying to aggressively move all its platforms to managed code (i.e., CLR and .net). It’s mostly written in managed code and only exposes .net APIs. The Windows and Office teams ended up changing course away from managed code, and the WinRT XAML framework can be seen as a do-over of WPF that removes the CLR dependency, so that Windows/Office can use it, while still trying to expose a natural-feeling API for C# developers.

5 Likes

I do agree to a certain point, according to Microsoft Documentations you are right on that, UWP is a more evolved version of Windows Runtime with a bit more additions to it.

2 Likes

I don’t agree at all, Windows Forms is going to be deprecated for sure in the near future, as it doesn’t really align with the current Microsoft Trend, Technologies like WPF, UWP are something that should be considered.

1 Like

I guess WinRT & UWP are identical but WPF is rather a whole different platform, the only common thing between these frameworks is they all use XAML file formats, for UI design.

2 Likes

@yay honestly agree with @jms 's post, he explains that WinRT and UWP are actually the same framework just a different version, we can look at WinRT as an ancestor of UWP, but UWP allows for far more reach for your Apps, Tablet, Mobile, PC and XBox…etc

2 Likes

@afree, sounds to me like you’ve blurred together “Windows Forms” and “.NET”.

.NET will stay alive, with or without Microsoft. Specific example: another programmer and I shipped a substantial app for iOS and Android using .NET APIs via Xamarin. As .NET programmers, this has been fantastic. We did our first Android prototype in Java several years back, when we did not have confidence in Xamarin’s maturity. A year later, we translated it to C#, and have developed solely in C# since then. No need to maintain two code bases, one in Java, one in Objective C.

WPF was developed to work with .NET. WPF+.NET is very much alive, despite Microsoft’s efforts to push developers to UWP. I’m still skeptical that UWP is as productive an environment to develop in. But I haven’t switched to Visual Studio 2017; its possible that UWP development is finally mature.

WinForms. I have developed in WinForms for over a decade, and am still enhancing a major internal-use WinForms app (over 600 source files). I agree that WinForms is dead - in the sense that it has no future; I would not start a new project in it. On the other hand, it is still fully usable today, especially for enterprise customers. One annoyance: its development was frozen before Microsoft’s gesture APIs. Have to access gestures via low-level bindings. (Start from the Touch/MSGestures sample project in Microsoft SDK for Windows 7.)

1 Like