I saw an article today about some of the changes being discussed by Microsoft in regards to future Windows application development and their plans for Windows over the long term. It’s an interesting article — mostly focusing on the history of the Win32 API, what the future of that might be under Windows 10 S, and speculating about some of the reasons why it is that there are still so many Win32 apps lo these many years later. I do suggest you read it since it really does a great job I think about explaining why that matters in general, the significance of the announcement made by MSFT last week, and the general context surrounding the discussion in the first place.
The tl;dr version though is that Windows 10 S (like the Chromebook but with Windows) doesn’t let you run any app that interfaces directly with Win32 without going through UWP. Only those apps that can get loaded via the windows store (ergo, UWP) can land on the 10 S. Eventually.
This is a big deal… because, let’s face it, as the article points out, most everything uses Win32 . You know how you can tell that this is a fact? If you use Windows 10, you’ve probably noticed that there are some applications with the regular-old interface you’ve been seeing for the past decade — and then there are a few really-slick looking ones with a more modern-looking interface. You’ve noticed that, right? Like the built-in “news” or “mail” apps that look and behave a little different? The ones that say “Trusted Windows Store App” on them? If you haven’t noticed, pay attention as you use Windows 10 and you’ll notice: a few apps look just a little different in terms of button layout, window framing — even position and style of the title bar sometimes. That’s UWP. The regular old clunky stuff? Win32.
What’s interesting to me about this article is that I don’t quite think the author of the article really understands why developers use Win32 in the first place… which is unfortunate, because this is exactly what makes the impact of Windows 10 S to the app ecosystem (should it be broadly adopted) so significant. The article attributes the ubiquity of Win32 in part to “developer laziness” — I guess something along the lines that developers are all old school folks who aren’t interested in learning how UWP works. Which, (while I thought this article was generally well informed and astute and no offense intended) kinda makes it clear that the author isn’t now – or probably wasn’t ever – a serious Windows developer. Because, laziness isn’t the reason. It’s not even close. UWP is wicked easy compared to Win32 … no really. Go try it. It is. Compare for example creating a hello world under UWP compared to doing that same thing under win32. The “lazy choice” is clearly the UWP option that Visual Studio aggressively pushes into your face. The Win32 option you have to look for, change defaults to select, and results in something pretty ugly.
So why do people use Win32? The reason why IMHO is versatility. Here’s what I mean. UWP is pretty powerful, right? It lets you do most things you might want to do for most apps. So that’s great. But there are things Windows can do — and that are implemented in the Win32 API — that UWP won’t let you touch. Which makes sense because UWP is designed to encompass the subset of functionality that is portable between devices. Win32 gives you it all. So if for whatever reason your app needs to know detailed information on the memory status of the machine, you can do that. Change the power management wake status of a specific device? Don’t mind if I do. You can do pretty much everything the OS can do.
And unless you can be sure — before you write any code — that you won’t need some service that UWP doesn’t offer (either now or down the line), Win32 is always the better choice from a versatility standpoint. And who knows every function call an application might make before it’s written? Not even the most detailed designing process lays that out nowadays. Literally none. If a product manager is able to tell you every service some new application will use (down to the function call) — before developers write code…. and they also promise not to change their mind ever… then UWP could be a good choice. Although at that point, it’s arguable how much the developers are even needed (for debugging or production support maybe.)
In all seriousness, an analogy to this would be that your family has two cars: a Ferrari and an old beater. The Ferrari is in otherwise good condition but has so little gas in the tank that the empty fuel light is on (assuming Ferraris have a fuel light) — the beater has a full tank. You need to drive to the store but it’s a holiday so you don’t know if the gas station on the way is open or not. It probably is… But do you risk it? The Ferrari is a much better ride: more fun to drive, all around a preferable experience in every possible way. But the gas thing could be a big deal. It’s the difference between a quick and easy trip vs. a huge hassle that could take hours and may or may not get you to the end state successfully. And because you don’t know ahead of time whether the station is open or not, it’s pretty risky – and the consequences pretty dire – should things go south.
But here’s the real clincher… by writing for Windows in the first place, you’ve already limited portability. What are you trying to be portable with? Nobody cares about Windows phone… XBox developers have their own black magic anyway. So what’s the value of UWP? Because UWP is prettier? So you can put your app in the App store? That’s far from compelling when the alternative is so much more flexibility and potentially the difference between solving the problem your app tries to solve vs. not.