The official way to create user interfaces for the Windows operating system changed quite a lot of times during the last years. Microsoft created and (partially or fully) abadoned a lot of APIs which where intended to replace the respective previous ones. They changed names and ways how it’s supposed to be done a few times, and left a lof of developers confused. Here is a small historical overview.
↫ Nikolaus Gebhardt
If you’re ever wondering how we ended up at a situation where, on the desktop and in Explorer, context menus have their own context menus, well, this is why.
Can’t believe he did not even mention WTL !
And this article is so old you can’t post a comment. ♂️
(was supposed to be a facepalm emoji, not a male sign or whatever)
If you look at it closely, there are actually two different APIs (or approaches).
Win32 (or rather Windows), which is based on GDI.dll and USER.dll which is the original interface. It has raster (bitmap) primitives and composition is Window based.
And XAML, which is used in originally Silverlight, and WPF, and evolved over time to be the new default. It has vector primitives, and composition is done more or less at the whole view level.
And yes, there are a lot of wrappers on these. As @Nico57 mentioned, for example the Windows Template Library (WTL) was an attempt to modernize the C++ API. Anyone who has used MFC or ATL (also missing) can say how much of cruft they had from pre-C++11 legacy syntaxes.
Win32 has been around since 1985!? No, in fact it was first supported by Windows NT which most assuredly did not exist in 1985.
Correct – the original API circa Windows 3.1 had the original Win AAPI, (retrofitted to be called Win16), and used 16bit data structures, pointers etc. it is “mostly” compatible with Win32, but you needed to care about code segments and calling across memory spaces because the 16bit memory model was horrible, There was also Win32s, which was a “mostly” Win32 compatible version of the API that ran on 16bit OS.
There are 5 products here, with various Microsofty rebrandhings along the way:
Win32, MFC, WinForms (.NET wrapper, basically) – same thing, different years, different branding
Silverlight – idiocy, but parts of it live on in various other projects (osnews had a really good history on this one a few years ago – it’s not really related to anything else on this list)
Xamarin, MAUI – just an open source implementation of .NET stack (it’s harder to separate the 2 these days)
WinJS – This is just Microsoft’s version of a PWA packager – Apple, Microsoft and Google all have versions of PWA, all seem to want it to die for various reasons (Apple keeps it around just enough to pretend it’s a viable alternative to the App Store). There is very little incentive for anyone to build a truly cross platform application system – in fact, the incentives are for lock-in. Any business 101 text book will tell you that, or just he history of computing companies for the last 50 years.
WPF, WinRT (confusing naming), UWP, WinUI, WinUI 3 – these all the same thing, just with different versions/iterations over the years:
That’s to say – there are really only 2 actual MS UI toolkit lines. Win32, and WPF. Everything else is either iteration or superfluous.
The reason so many Windows apps look so different is for entirely different reasons, most of which you want.
1) Windows is an “open” general computing platform (in the sense that anyone can write and run programs for it – it ain’t iOS)
2) Developers will often use 3rd party GUI toolkits for various reasons (usually, because it’s easier, or some similar perceived benefit).
3) App makers want their apps to look like their apps, not like Windows apps, and they are constantly innovating to try and make their apps more useful for their own users.
The goal of application look and feel consistency is foolish. You don’t really want that, you just think you do. Freedom and diversity is better.
That said – we should be using truly open platforms – the state of Linux desktop has never been better. Time to dump Windows, IMHO.
I think it is more than that.
There is the Win32 API which is the native Windows GUI tech on which everything is really based. Originally, you called that in C directly. MFC ( Microsoft Foundation Classes ) was a C++ wrapper over that. Windows Forms was a .NET managed library that was Win32 under the hood. From the point of view of a developer, these are 3 totally incompatible UI frameworks. However, they are conceptually all very similar as ultimately they are, as you say, just layers put on top of Win32. Again though, from an application code perspective, they are very different. If I, as a developer, know how to create Windows Forms applications, I have no idea at all how to create an MFC application and certainly not a C native Win 32 application. However, I do understand the concept of a “Form” and a “MessageBox” and most of the controls and the kinds of properties they have make sense to me. They all “look” the same as they really are all just Win32 at the end of the day ( totally Windows native ). You can lump WTL / ATL in here too.
Next we have another “mostly conceptually compatible” but totally different implementation universe that started with WPF ( Windows Presentation Foundation ). Starting with WPF, the API completely diverged from Win32 and was not even thematically similar. In particular, a more declarative UI style using XAML ( eXtensible Application Mark-up Language ) was introduced. XAML, MVVM ( Model View View Model ), binding, and other WPF concepts are a universe apart from any of the Win32 stuff above. Way under the hood it is still running on Win32 ( Windows only for sure ) but it looks and feels nothing like it to a developer. WPF apps do not necessarily look like all other Win32 apps even at the presentation level.
XAML becomes the common thread that unifies the all Microsoft attempts at UI since WPF. So, in that way, we have two generations: the Win32 era and XAML.
Silverlight is also XAML and not nearly as distinct as you imply unless you concede that all the XAML frameworks are totally different.
That said, the XAML used by MAUI ( first created by Xamarin ) is incompatible with WPF and certainly MAUI itself is a totally different framework at the code level.
The replacement for WPF was meant to be UWP ( Universal Windows Platform ). UWP was more than just the GUI as it was an attempt to create a fully sandboxed environment that was distinct from Win32 ( to the programmer at least ) and also “portable”. This is what Windows Phone apps and XBox applications were meant to be written in alongside Windows apps. UWP and WindowsRT ( Windows Runtime ) are basically synonymous ( just to add to the naming disaster ). We all know what the introduction of this GUI framework brought as it was used to create the “Modern” apps and look that shipped with Windows 8. While the GUI was still XAML based, I think even the least technical people can agree, this was not at all just a continuation of WPF as everything about it was a break from the past. The backlash against Windows in general that resulted was significant. WinJS was just a way to create UWP / WinRT apps with Javascript.
It is not wrong to say that UWP as a paradigm failed however the GUI API is essentially still state-of-the-art on Windows. If you create a GUI application using WinUI ( or even a Windows application using MAUI ), you are using basically the exact same API that was introduced with UWP. All the sandboxing and non-GUI stuff is gone now but the UI part is very, very similar ( including the XAML ). You can create cross-platform applications using the API via the Uno Platform ( non-Microsoft Open Source ). A modern WinUI app is almost the same code as a UWP app would have been ( it is much closer than Win32 and MFC for example ).
What we call WinUI now has had many names. I would say that it is mostly responsible for the perception that Microsoft keeps changing horses as they naming is a disaster. However, the actual API and approach has not changed much in
So, if we work backwords, I would create the following list of GUI APIs from Microsoft ( on Windows ):
1. WinUI ( it has evolved a bit since the introduction of UWP in Windows 8 ( 2012 ) but it is essentially the same – XAML based )
2. WPF ( a big departure from earlier frameworks – introduced XAML – appeared with .NET 3 in Windows Vista )
3. Windows Forms ( .NET wrapper for Win32 introduced way back in 2002 – did not replace Win32 outside .NET )
4. MFC ( C++ wrapper around Win32 ) – not really a replacement for Win32 – more just an OOP toolkit for C++ users
5. Win32 ( the original C based API – still there today if you want to target it )
On the “cross-platform” side ( working backwards:
1. MAUI ( just a renaming and Microsoft in-sourcing of the Xamarin Forms API that they bought along with Xamarin )
2. UWP ( mostly envisioned as their “mobile” toolkit back in 2010. It failed as their mobile strategy failed but lives on in WinUI – now targeting only Windows – and Uno Platform, which is Open Source )
3. Silverlight ( really only targeting web but I think it was seen as the cross-platform strategy of the day – a competitor to Flash really and it went the same way Flash did – crushed by “web” technologies )
On the “web” side of things, the story is actually fractured in some ways as there are competing frameworks. Then again, it is an oasis of stability compared to Javascript. Working backwards:
1. Blazor ( a component based .NET framework leveraging WASM )
2. Razor Pages ( a simplification of the ASP.NET story in .NET 5+ — a bit of a modern PHP really in some ways )
3. ASP.NET MVC ( first started back in the .NET Framework days – 2009 – and refreshed with the introduction of .NET Core in 2014 )
All the above are still current and kind of alternatives to each other. Before that there was…
4. Silverlight ( see above – there is still Project Silver if you really, really loved Silverlight )
5, ASP.NET ( the original – now called Web Forms – the web version of Windows Forms introduced with .NET in 2002 )
6. Active Server Pages – a Microsoft version of essentially exactly the same idea as PHP
All-in-all, other than the totally dysfunctional naming and branding, there has not been that much churn on Windows and not even that bad in on the web ( considering how chaotic web dev is in general ).
On the cross-platform side, it is more a story of failure to launch than anything. They have not really backed many horses. They are arguably not there yet. I think that Avalonia and Uno ( both Open Source cross-platform GUI toolkits ) are more popular than Microsoft’s own offerings for cross-platform. Uno is essentially 100% compatible with the WinUI API. Avalonia is extremely similar to WPF but not API compatible. In fact, Avalonia offers a commercial service to “port” WPF applications to Avalonia.
The entire stack in Silverlight was alien to Windows, and distinct from basically everything else. The only thing it had in common was the it has a declarative GUI system based on XAML, but even that was only surface level. That thing was a blob monster, even my proprietary Operating System standards.
I guess it depends on the way you look at it. Silverlight on the web had to rely on a version of the .NET runtime as a web plugin. In that way, it was a unique mess and a “blob monster” as you say.
However, from the stand-point of an application developer, Silverlight and “modern” WinUI ( which is a tweak of the UWP GUI API ) are pretty similar. Microsoft even offered something called the “Silverlight to UWP bridge” that would mechanically convert Silverlight apps to UWP. Going from UWP to WinUI is even easier ( largely a namespace change ).
Here is how Microsoft described porting from Silverlight to UWP at the time:
“Since you used Extensible Application Markup Language (XAML) in your Windows Phone Silverlight app, it’s likely that XAML will be your choice for your Windows 10 version because most of your knowledge and experience will transfer, as will much of your source code and the software patterns you use. Even your UI markup and design can port over readily. You will find the managed APIs, the XAML markup, the UI framework, and the tooling all reassuringly familiar”
https://learn.microsoft.com/en-us/windows/uwp/porting/wpsl-to-uwp-root
The UWP API was an “improved” version of the Silverlight API. Not compatible but very similar and via the “Silverlight bridge” potentially largely machine translatable from one framework to the other.
The article above mentions “Silverlight Phone” but this was not really anything different than Silverlight on the web. It just added a few phone specific APIs and was just a last ditch effort to reposition Silverlight. It became UWP which became just WinUI after both Windows Phone and the Windows 8 store failed. The following article talks about the plans to use Silverlight as the application framework for Windows Phone ( before that even happened ):
https://www.crn.com/news/applications-os/222900433/sources-silverlight-the-platform-for-windows-phone-apps
To put his article another way, here is the timeline of Windows only GUI APIs:
Win32 ( C language API ) – 1985 – present ( mature )
— MFC ( Win32 in C++ ) – 1992 – present ( mature )
— WinForms ( Win32 in .NET ) – 2002 – present ( available but discouraged )
WPF – 2006 – present ( Open Source now but no new MS investment )
WinUI / XAML ( current – effectively the same API since 2012 as WinRT, UWP, and WinUI 2 – Open Source as UNO )
That is a pretty short list when you look at it that way.
He also mentioned: MAUI ( was Xamarin Forms) – 2014 – present ( actively developed )
MAUI is a cross-platform framework. When it runs on Windows, it targets WinUI. So, it does not really deserve to be on the list above. It is a complement, not a competitor.
Similarly, he mentioned Silverlight. Silverlight is and was indeed a total dead-end, as was its inspiration–Flash. The API heavily inspired what is now WinUI though so not totally abandoned in that sense. More importantly, it is an API for building web applications which is an entirely different list that he did not get into.
That short amount of iteration highlights another thing that Thom misses in all this. The Windows GUI toolkits just don’t do that much for you, as a developer. It’s not like the macos UI toolkit, which has a widget for like everything, where Apple has been adding high level features (with properly considered security implications) for actual decades. Windows just isn’t that robust, at last not at that level. And they’ve largely thrown in the towel. There’s not even a dedicated Windows team, and hasn’t been for years.
Fair
can you explain more about this?