A few years ago I was in a meeting with developers and someone asked a simple question: “What’s the right framework for a new Windows desktop app?”
Dead silence. One person suggested WPF. Another said WinUI 3. A third asked if they should just use Electron. The meeting went sideways and we never did answer the question.
That silence is the story. And the story goes back thirty-plus years.
When a platform can’t answer “how should I build a UI?” in under ten seconds, it has failed its developers. Full stop.
The Last Time Windows Had a Clear Answer
In 1988, Charles Petzold published Programming Windows. 852 pages. Win16 API in C. And for all its bulk, it represented something remarkable: a single, coherent, authoritative answer to how you write a Windows application. In the business, we call that a ‘strategy’.
Win32 that followed was bigger but still coherent. Message loops. Window procedures. GDI. The mental model was a bit whacky, but it was one mental model. Petzold explained it. It was the F=MA of Windows. Simple. Powerful. You learned it. You used it. You were successful.
Clarity is your friend! One OS, one API, one language, one book. There was no committee debating managed-code alternatives. There was just Win32 and Petzold, and it worked. This was Physics not Chemistry (this works but only for this slice of the period table. And only under these pressures. And only within this temperature. And only if the Moon is in the 7th house of Jupiter).
What happened next is a masterclass in how a company with brilliant people and enormous resources can produce a thirty-year boof-a-rama by optimizing for the wrong things. AKA Brillant people doing stupid things.
The Object-Oriented Fever Dream (1992–2000)
Win32 had real limitations, so Microsoft did what Microsoft does: it shipped something new for the developer conference. Several somethings.
MFC (1992) wrapped Win32 in C++. If Win32 was inelegant, MFC was Win32 wearing a tuxedo made of other tuxedos. Then came OLE. COM. ActiveX. None of these were really GUI frameworks – they were component architectures – but they infected every corner of Windows development and introduced a level of cognitive complexity that makes Kierkegaard read like Hemingway.
I sat through a conference session in the late nineties trying to understand the difference between an OLE document, a COM object, and an ActiveX control. I looked at the presenter like they had a rat’s tail hanging out of his mouth for the entire hour.
Microsoft wasn’t selling a coherent story. It was selling technology primitives and telling developers to figure out the story themselves. That’s the Conference Keynote Cluster***k – Microsoft optimized for an executive impressing people with their keynote and not the success of the users or developers.
PDC 2003 and the Vision That Ate Itself
At PDC 2003, Microsoft unveiled Longhorn – genuinely one of the most compelling technical visions the company had ever put in front of developers. Three pillars: WinFS (a relational file system), Indigo (unified communications), and Avalon – later WPF – a GPU-accelerated, vector-based UI subsystem driven by a declarative XML language called XAML. Developers saw the Avalon demos and went nuts. It was the right vision.
It was also, in the words of Jim Allchin’s internal memo from January 2004, “a pig.”
By August 2004, Microsoft announced a complete development reset. Scrapped. Start over from the Server 2003 codebase. And after the reset, leadership issued a quiet directive: no f***ing managed code in Windows. All new code in C++. WPF would ship alongside Vista, but the shell itself would not use it.
The Windows team’s bitterness toward .NET never healed. From their perspective, gambling on a new managed-code framework had produced the most embarrassing failure in the company’s history. That bitterness created a thirteen-year institutional civil war between the Windows team and the .NET team that would ultimately orphan WPF, kill Silverlight, doom UWP, and give us the GUI ecosystem boof-a-rama we have today.
Silverlight: The Pattern Established (2007–2010)
WPF shipped in late 2006. It was remarkable – XAML, hardware-accelerated rendering, real data binding. If Microsoft had made it the definitive answer and invested relentlessly, the story might have ended differently. Instead, in 2007, they launched Silverlight: a stripped-down browser plugin to compete with Flash, cross-platform, elegant, and the foundation for Windows Phone. Around 2010 it looked like the rich client future.
Then at MIX 2010, a Microsoft executive said in a Q&A that Silverlight was not a cross-platform strategy – it was about Windows Phone. HTML5 was now policy. The Silverlight team was not told this was coming. Developers who had bet their LOB applications on Silverlight found out from a conference Q&A.
Silverlight wasn’t killed by technical failure. The technology was fine. It was killed by a business strategy decision, and developers were the last to know.
Remember that pattern. We’ll see it again.
The Metro Panic and the Two-Team War (2012)
Apple had sold 200 million iPhones. The iPad was eating into PC sales. Microsoft’s answer was Windows 8 and Metro – a touch-first runtime called WinRT that was deliberately not built on .NET. Remember the Windows team’s bitterness? Here it manifests. WinRT was a native C++ runtime. Clean break from WPF, WinForms, and a decade of developer investment in .NET.
There were actually two stories being told simultaneously inside Microsoft. The Windows team was building WinRT. The .NET team was still evangelizing WPF. Different buildings, different VPs, different road maps.
What developers heard at //Build 2012: the future is WinRT, and also HTML+JS is first-class, and also .NET still works, and also C++ is back, and also you should write Metro apps, and also your WPF code still runs fine. That is not a strategy. That is a Hunger Games stage where six teams are fighting for your attention.
Enterprise developers took one look at UWP’s sandboxing, its Store deployment requirement, and its missing Win32 APIs, and walked away. The framework designed to win them into the modern era had been optimized for a tablet app store that never materialized.
UWP and the WinUI Sprawl (2015–Present)
Windows 10 brought Universal Windows Platform – write once, run on PC, phone, Xbox, HoloLens. Compelling on paper. The problem: Windows Phone was dying, and Microsoft’s own flagship apps – Office, Visual Studio, the shell itself – weren’t using UWP. The message was clear even if no one said it out loud.
When UWP stalled, the official answer became it depends. Use UWP for new apps, keep WPF for existing ones, add modern APIs via XAML Islands, wait for WinUI 3, but also WinUI 2 exists for UWP specifically, and Project Reunion will fix everything, except we’re renaming it Windows App SDK and it still doesn’t fully replace UWP and…
Brilliant people doing stupid things. Technological Brownian motion.
Project Reunion / WinUI 3 represents genuine progress. But ask yourself why the problem existed at all. UWP’s controls were tied to the OS because the Windows team owned them. The .NET team didn’t. The developer tools team didn’t. Project Reunion was an organizational workaround dressed up as a technical solution.
One developer’s summary, written in 2024: “I’ve been following Microsoft’s constant changes: UAP, UWP, C++/CX replaced by C++/WinRT without tool support, XAML Islands, XAML Direct, Project Reunion, the restart of WinAppSDK, the chaotic switch between WinUI 2.0 and 3.0…” Fourteen years. Fourteen pivots. That person deserves a medal and an apology, in that order.
The Zoo Without a Zookeeper
Here is every GUI technology actually shipping on Windows today:
Microsoft native frameworks:
- Win32 (1985) – Still here. Still used. Petzold’s book still applies.
- MFC (1992) – C++ wrapper on Win32. Maintenance mode. Lives in enterprise and CAD.
- WinForms (2002) – .NET wrapper on Win32. “Available but discouraged.” Still fastest for data-entry forms.
- WPF (2006) – XAML, DirectX-rendered, open source. No new Microsoft investment.
- WinUI 3 / Windows App SDK (2021) – The “modern” answer. Uncertain roadmap.
- MAUI (2022) – Cross-platform successor to Xamarin.Forms. The .NET team’s current bet.
Microsoft web-hybrid:
- Blazor Hybrid – .NET Razor components in a native WebView.
- WebView2 – Embed Chromium in a Win32/WinForms/WPF app.
Third-party:
- Electron – Chromium + Node.js. VS Code, Slack, Discord. The most widely deployed desktop GUI technology on Windows right now – and Microsoft had nothing to do with it.
- Flutter (Google) – Dart, custom renderer, cross-platform.
- Tauri – Rust backend, lightweight Electron alternative.
- Qt – C++/Python/JavaScript. The serious cross-platform option.
- React Native for Windows – Microsoft-backed port of Facebook’s mobile framework.
- Avalonia – Open source WPF spiritual successor. Used by JetBrains, GitHub, Unity – developers who stopped waiting for Microsoft.
- Uno Platform – WinUI APIs on every platform. More committed to WinUI than Microsoft is.
- Delphi / RAD Studio – Still alive. Still fast. Still in vertical market software.
- Java Swing / JavaFX – Yes, still in production. The enterprise never forgets.
Seventeen approaches. Five programming languages. Three rendering philosophies. That is not a platform. I might not have a dictionary definition for the term boof-a-rama but I know one when I see it.
The Lesson
Every failed GUI initiative traces back to one of three causes: internal team politics (Windows vs. .NET), a developer conference announcement driving a premature platform bet (Metro, UWP), or a business strategy pivot that orphaned developers without warning (Silverlight). None of these are technical failures. The technology was often genuinely good – WPF was good, Silverlight was good, XAML is good. The organizational failure was the product.
You either have a Plausible Theory of Success that covers the full lifecycle – adoption, investment, maintenance, and migration – or you have a developer conference keynote.
One is a strategy. The other is a thirty-year boof-a-rama.
Charles Petzold wrote six editions of Programming Windows trying to keep up with each new thing Microsoft announced. He stopped after the sixth, which covered WinRT for Windows 8. That was 2012.
I don’t blame him.
You could argue that the root cause of all of this was the incredibly late realisation that we were in an X-Plat world, and the refusal to let go of the notion that Windows was at the heart of everything.
WPF was strangulated by that (despite x-plat MIL implementations hiding away in the shadows), Silverlight was ultimately canned because of that; the assorted Windows-specific successor technologies were born of that notion. A rear-guard defence for a business unit that was always likely to remain significant, but had to give up the Divine Right of Kings.
no, we abandon Silverlight because we had no real plan beyond take on Adobe Flash and figure out what happens next once we hit 95% ubiquity.
We alos starved WPF funding to make way for Silverlight. There are a lot of mistakes to be had, but the true moment Silverlight got ear marked for death was when we released “Out of Browser” capability. That’s when Steve Sinofsky acolytes descended upon on us.
It’s also around this time when the Windows team absorbed XAML and declared it was C++ or JS not C# as the way of Windows 8 and beyond. Then Steve Jobs posted the letter and that pretty much was the 1000th cut for activex.
This.
I actively opposed installing or using Silverlight because as far as I could see, it was Microsoft being jealous of Flash and wanting its own private label version. Except that it couldn’t eliminate Flash, so supporting Silverlight meant *two* proprietary in-browser application platforms instead of one. No thank you.
Technology wise, Silverlight was a lot more sane than the Flash extension itself. My biggest issue was the really limited cross-platform support and this is where MS always falls apart… even with MAUI, I think the lack of Linux targets really holds it back, just in developer mindshare. I know a lot of devs that really like Avalonia and Uno with C# cross platform, but MS blessed options just languish.
Pingback: 微软自Petzold以来一直没有一个统一的GUI战略。 - 偏执的码农
One thing you glossed over was the “elegance” of MFC (well, for some definition of “elegance”). I was an MFC guy in the 90s, and I took three different companies from 16-bit to 32-bit Windows apps during that time. Yeah, MFC was weird (it got nick-named the “Macro-based Foundation Classes”). It was a very thin wrapper around both Win16 and Win32. But it was enough of a wrapper and just enough abstraction to allow a 16-bit MFC app to run on 32-bit MFC with about a week’s work. At one company I worked for, we did a 6-week (start-to-shipment) release for our new 32-bit product. We took no marketing or customer bugs – just the ones we found during testing. It was *way* more stable and noticeably faster.
Pingback: Windows UI History | Fruity Dev Log
Loved MFC it influenced all my C++ work until I switched to C# fully about 10 years ago, still got the book in my library.
Microsoft is run by idiots. I mean it. They had a perfectly valid WinAPI-based UI, and they didn’t expand it; they didn’t bring new controls – nah, they changed it completely for different platforms and different systems and different languages. Nobody asked for it. I bet next Windows will bring another “revolutionary” UI concept designed by their “best of the best” designers on their Mac Books ;).
2026 nobody develops Windows apps anymore. All legacy apps are updated, nothing new is created except big apps. I haven’t seen a single new Windows app with interesting UI in years.
Way to fix it
0. Fire entire Windows UI and design team – we all know they are using macs anyways
1. Expand existing WinAPI UI, add new functions, new metrics
2. Introduce new, native cool components
3. Add visual styling to Visual Studio to allow interactive designing of forms WITHOUT XAML bullshit (look how Delphi did it)
4. Introduce support for wide array of graphic formats for controls (icons, JPG, WEBP, SVG, AVIF)
5. Introduce support for animations in mp4 formats for controls e.g. add animation icon to a button
6. Add dynamic skinning to forms with easy to create themes (and DPI support) and dynamic form creators in Visual Studio to create and design forms interactively for C++ and .NET apps (Delphi had it in 1998!)
Yep the MacBooks are an insult to die hard Windows developers and users. If I wanted a Mac I would buy one. Stop making Windows look like a Mac. Don’t hire a team that has Mac envy. You can do much better.
I worked with and for MS for 25+years. I started working for a Google partner 3 years ago and we all just use Mac Mini. “Don’t hire a team that has Mac envy. You can do much better”. mmmm I’d love to see it. I just can’t fault my Mac, the experience is first class. Also the Google teams don’t care if we use Mac’s or Chrome Books.
Apple has the same problem as MS with their GUI though. Constant, unnecessary, pointless changes that do nothing but frustrate the user. Fundamentally the problem with the team at MS isn’t that they have Mac envy but that they, like the MacOS team, want to change visible things that worked for the sake of changing them in order to feel like they’re making a mark or because they need to have something to show that they’re really working.
Meanwhile with MS the problem is that they make poorly designed changes to the GUI and screw things up under the hood too, while MacOS only screws up things under the hood every ten years or so (the abandonment of 32-bit app compatibility in Catalina a few years before introducing the ARM chips anyway, destroying backwards compatibility for huge numbers of users even on current apps at the time. I remember doing support and taking calls from parents with kids doing covid lockdown learning asking why Zoom didn’t work).
The introduction of Copilot AI programming is making their under-the-hood screw up rate accelerate exponentially as far as I can tell.
Windows conquered more marlket share than Mac because it was better, not worse. You usually do not copy a less successful competitor.
I think the Winforms wrapper for Win32 is pretty reasonable if you only want to target Windows with .Net … the problem is a lot of the “modern” incarnations try to do more, but are always held back in some ways for political reasons… even MAUI, there’s absolutely no reason they couldn’t target at least GTK for Linux… IMO this has an outsized effect on those holding out from even trying it, with many completely unaware that Avalonia and Uno even exist.
Yes. Just make the gdi rendering and themes to support different scales, and that’s it. There is no need to throw away all the theme engine for unthemable WinRT.
Speaking of Windows GUI frameworks, back in the day Borland created the Object Windows Library (OWL). Similar to MFC it was a wrapper around WinAPI, but better designed. It was abandoned by Borland when they switched to Delphi and C++ Builder with the VCL framework, but it was taken by the open-source community and still being updated and supported as the OWLNext project on SourceForge.
I used OWL before I ever worked with MFC, and thought it was the superior platform. I always thought MFC was a good first cut, but they never really got past that “first attempt” level. I really like MFC, and built a huge amount of code to expand and improve on it back in the day.
I remember, being used to MFC, encountering one of the Borland libraries and thinking “Hang on, this presents the list control as a proper container! Why doesn’t MFC do this?” Since MFC was a very thin wrapper around Win32, it had an object to wrap the list control, but to do anything with the entries meant calling methods on the control that used primitive types like int and char *. Whereas in the Borland model, the list control was a container and each entry in it was a C++ object you could manipulate directly.
Cool article, suddenly feeling a lot less like it’s my fault I never got the hang of UI programming.
Crying shame you felt the need to illustrate it with slopware, though.
have you actually seen the graphic you included with this post?
Yes. I thought about working to fix it but then I thought it aligned with the boof-a-rama I was describing (and I’m lazy) so I kept it.
This sounds reasonable.
Wow, that’s probably exactly how the mess you describe in your article happened.
At one point, MFC got an “upgrade” with the WTL. IMO they were solving the wrong problem with that one.
Sounds like how you end up with walled gardens.
And that graphic is full of AI slop, did you even look at it?
Nice look into the hairball. A piece that seems worthy of including is the rise and fall of the army of developers that was VB. A lot of them made it to C# WinForms but IMO MS never replaced the level of loyalty & new dev engagement that VB brought. It was the OG in vibe coding.
Yes, and plus, VBA embedding in third-party apps, office scripting with VBScript… Gates started with Basic and developed it all the way only for some haters of his legacy to declare it obsolete.
Related boof-a-rama (*) and perhaps even worse than what you’ve listed: one of the biggest reasons for Microsoft’s success was its unwavering commitment to backward compatibility. Not only would your older apps run on new Windows versions, but you could extend your older code by interoperating with newer code technologies. You could interoperate: Petzold-style code with COM/ActiveX with MFC with ATL with VB5/6 with C# with VB.NET with all kinds of database components/backends — all the way up to but NOT INCLUDING WinRT, which insisted that you throw away all your old code and start over – because WinRT was SO PERFECT that it couldn’t afford to be polluted by interoperating with older technologies. And this at a time when Apple and Google had already become massive competitive platform threats. I’ll never forget going to Redmond to join a small meeting where we brought this feedback to a couple of arrogant and clueless VPs whose responses were SO out to lunch that I’m sure they never made it back for dinner. I remember glancing at my watch and making sure to be looking at these VPs at the very top of the hour because I was certain that a little door would pop open on their foreheads and a little cuckoo would come out and chirp.
(*) I think I’m going to open a shopping mall and call it “Boof-A-Rama.”
Backward compatibility is truly an advantage. Imagine losing the only tech that worked because it was deprecated.
And not forget the replacement the web browser control with an incompatible WebView2.
Jeffrey, this is the most precise autopsy of the GUI boof-a-rama I’ve read, and the Petzold framing is exactly right. What Petzold represented wasn’t just a good book. It was a trust signal. One API, one answer, one commitment. Everything after it broke that commitment incrementally until Electron’s dominance became not a technical verdict but a trust verdict.
Your piece got me thinking about why the pattern repeated for thirty years despite being visible to everyone involved, and I ended up writing a response that explores the organizational psychology underneath the technical history you laid out. The Windows vs .NET civil war, the conference keynote as anxiety management device, the fourteen-pivot developer who deserves a medal and an apology: there are named mechanisms from organizational psychology that explain why brilliant people inside a brilliant company kept producing this outcome, and why good intentions at every level still generated thirty years of developer abandonment.
I’d be honored if you gave it a read: https://rlsutter.substack.com/p/seventeen-frameworks-and-no-strategy
The reason is simple: the genius left the company. So, entropy takes everything.
This is a great autopsy. The organizational failure framing is spot on. But I think there’s an economic layer underneath that explains why the org dysfunction was so hard to fix.
The Petzold era wasn’t just coherent because one team owned the answer. It was coherent because the dev platform was the upgrade engine. New Windows meant new developer capabilities, which meant apps that needed new hardware, which funded the next round of platform investment. Developers, users, OEMs, Microsoft: everyone’s incentives were aligned. The clarity you’re describing wasn’t just good strategy, it was a byproduct of a business model where coherence paid.
The fracture started when Microsoft tried to decouple the dev platform from that hardware upgrade cycle. Should new capabilities span older OS versions, or should they be tied to the latest release? That’s the question underneath the Windows vs .NET civil war, underneath Metro, underneath UWP. Every pivot you describe is really a different answer to that question, delivered by whichever team had political momentum that quarter.
Once you break the flywheel (new platform → new apps → new hardware → new platform), you lose the economic gravity that kept the strategy coherent. And then you get exactly what you describe: seventeen frameworks, conference keynotes as strategy, and developers left holding the bag.
Aaron’s comment about WinRT breaking backward compatibility is the perfect example. The one thing that did survive across eras was the interop contract. WinRT threw it away in pursuit of a tablet store that never materialized, and with it went the last thread connecting the new world to the old flywheel.
Some of this comes from launching new things to break other companies rather than because they are useful or a plan for the future.
This is completely true, I’ve been thinking it for a while, but much better researched (and presumably from more hands-on info).
If I were asked, I’d still think WinForms was the best. I see the benefit of what followed, but XAML is so ugly that I just can’t.
But to not even have an answer from Microsoft for what I should be using… in 2026… it’s an absolute embarrassment.
Pingback: Por qué la interfaz de Windows nunca ha sido consistente - Noticias de Hoy
Pingback: Por qué la interfaz de Windows nunca ha sido consistente - LaVozTV
Pingback: Un ingeniero clave de Microsoft explica por qué la interfaz de Windows es un desastre – Partnerlink
The article is really good, but the cross-platform frameworks and solutions can run on Windows, Mac, or Linux. so this is from the community not from Microsoft, right ?
But totally agree with you about the inconsistency which still exists in the Windows OS UI components itself
One thing I would like to point out is that.net as a whole is dead, they just haven’t announced it jet. C# is amazing but Microsoft hates it like no one in the world. Core team did a great job but they never managed to get out of the microslop branding
Pingback: Un ingeniero clave de Microsoft explica por qué la interfaz de Windows es un desastre - Portal Maya
I would add Richter’s Advanced Windows to Petzold as one of the foundational Win32 tomes. It carried me through a decade plus of development.
Are native GUI frameworks still relevant, though? I know that on the Mac side there’s still developers that are stubbornly one platform only.
But I look at most of the stuff that I use for work and fun, and 1. it’s cross platform and 2. It always tries to look consistent on all platforms, instead of trying to look and behave “native”, which means it uses it’s own GUI toolkit. Adobe apps have their own GUI, same on Mac and Win. Houdini and Blender, same. Cubase, same. This is a reversal of the 90s-2000s when apps were trying to “respect” the conventions of the OS.
With even dotnet being cross platform, why would somebody use a Windows-only GUI instead of Avalonia?
It’s even worse than this. Under the hood are several old UI dev frameworks Microsoft still uses in the OS. If you dig, you’ll still find WinJS and Knockout, and a proprietary pre-WPF framework called Direct User Interface.
Back in the Win8 days, I took one look at WinJS and Metro and said “no, thank you.” Silverlight on the phone and WPF on the desktop was at least usable. UWP in C# was an easy transition if you wanted to buy into the Store. If I do anything else on the platform, it will probably be Electron.
Pingback: Windows app development is broken and it’s affecting every program you use – FastPlayStream
Pingback: El avance de aplicaciones de Windows no funciona y está afectando a todos los programas que utilizas – DeUltimoMinuto
I like Windows Api and The UI Library is [C++ + Graphic Api + Multi Layout Style + Shader + Responsive + Animation + …]. And the best UI is browser such as Chrome. Hahaha
No one’s asking the real question: *why* build a Windows-only app? If you’re a developer, ask yourself that question. Are there good reasons to build an app that works only on Windows?
I build several apps, and while some of my users have PCs, others have a Mac, an iOS device, an Android device, maybe a Linux box. If I want all those users to run my app, the best solution is to build for the web.
For many developers, building a platform-specific app just doesn’t make sense. As a developer, I can’t write 4 or 5 different apps, one for each platform. That’s too much time and money and maintenance.
So instead, I just build for the web.
The web has grown more powerful and more capable. The web can do 99% of what most apps need. I build for the web, all my users can run my app no matter their OS or form factor.
Some people complain about overhead of Electron apps – fine, don’t ship Electron. You can package web apps for all the major app stores — including the Microsoft Store — without shipping any Electron runtime. Microsoft’s own PWABuilder can package your web app and ship to all the major apps stores.
The web is the universal runtime that Flash and Silverlight aimed to be.
I fully expect in the future, as the web’s capabilities continue to grow, there will be fewer and fewer reasons to write platform-specific apps.
Web is interpreted and absolutely not intended for general apps.
> I looked at the presenter like they had a rat’s tail
like HE had*
they is for multiple people
And you’d be wrong…
What I keep missing in all these discussions is wxWidgets (previously called wxWindows). It’s by far the best C++ Windows UI framework since it uses the native controls. It also has a very easy-to-use UI editor called wxFormBuilder.
In addition it’s cross-platform so you can compile your application for Windows, Mac OS X and Linux from the same codebase.
It targets Win32 but notice that amongst all this fuzz about frameworks Win32 always kept working on all versions of Windows, including Win11.
On Linux it was pain in the ass to maintain.
A lot of the pain from the UWP sandboxing mess was itself fallout from this kind of situation. Look at what happened to CreateFile. They didn’t want UWP apps to be able to open hardware devices and that sort of thing and didn’t want to do sandboxing for it in proc, because the “bridges” out of the sandbox themselves needed to use CreateFile. So they made CreateFile2, and said “devs, use that”. Because updating all of the code MS owns to call CreateFilePowerful would have been too expensive, they forced the rest of the code in the universe to call CreateFileWeakened. And in so doing broke compat with every piece of code that touched files ever written for the platform. For all the claims about it being easy to port code over to the Windows 8 world, having a single codebase that worked on Win7- and Win8+ was next to impossible due to this CreateFile difference alone.
Ironically, perhaps, and quite understated here — with many people choosing Electron these days — Microsoft has shown time and again that the best UI technology they have managed to produce since WinAPI (16-bit and 32-bit both), has been one they didn’t make themselves. This is, in my opinion, the “crux” — they’re their own worst enemy. They look at Apple and got it into their little heads (and let’s face it, heads of managers and everyone not actually writing and _reading_ code at Microsoft, are relatively “small”), that they too can be the sole primary provider of all Windows APIs, but that’s a responsibility they, as demonstrated with this and many other an article, just cannot fulfill anymore. They haven’t for ages. But they keep trying and they will keep shoving Avalons, Indigos, Project This and Project That, perpetually, and we’ll keep hating them for that, but Windows will keep chugging along.
Microsoft should indeed stop stirring the pot, and stick to things that don’t require them wooing developers directly. Leave the middleware to middlemen. And UI is middleware.
This will allow them to actually focus on WinAPI, which in my opinion as well, is the single best thing about Windows, among very few other things. It’s clunky but it’s a known quantity, and abstractions can be built on top of it to preserve sanity of today’s developers expecting automatic memory management, data binding etc. That’s what abstractions are _for_.
I do agree that a lot of technologies Microsoft came up with were very interesting. I own “the” COM book and the premise of COM — for its time at least — was very compelling. There were other things — now and then Microsoft gets smart people on board and _gets out of their way_, but I think that particular culture is dying there, as they try to assert more and more control looking at how “consistent” Apple seemingly is with their development development. But Apple too is losing the plot, albeit not exactly in the same category yet: https://news.ycombinator.com/item?id=47547009. But entropy is winning as usual, it’s just that Microsoft is hilariously, true to themselves-bad at offsetting it.
Yep.. MS all lost me as loyal employee when after initial fascination with Sinofsky who fixed W7 he continued on that crap called Windows 8 and WinRT an CX and keep inventing around inconsistent UI perspective while fundamental part of the OS that could be optimised further more stalled.
Dichotomy continues up to this day and with Windows 7 era of OS Development, Cpp getting C++11 and .NET being at 4.x they all had such solid foundations to create next gen but no… all folks back then were confused by HTML5 revolution and now we need to eat that nonsense called Electron, being abused by Redmond devs in the system and Office apps themselves..
But I agree, Apple has the same issue. They had Carbon that was combining C/C++ and ObjC coders under one umbrella and then Cocoa + Swift and constant changes without something that I still respect in MS much better -> backwards compatibility.
in 2026 it’s so funny to observe that actually Linux comes with so much better consistency all around APIs and platforms than both of these behemoths..
The reason Linux comes up with much better consistency is because it’s a bazaar and Torvalds or his fellow _kernel_ developers don’t disrupt or even tangle themselves up with e.g. Wayland or UI/UX, knowing their core competence isn’t there. They leave the UX/UI of the level Microsoft and Apple are trying to invent, to other developers, and everything ticks merrily along — in this case open source and open design and quorum- or conversation based design produces good results, also not being motivated by buzzwords and teams competing for budget and relevancy (read: the situation at a company like Microsoft).
Like I said earlier, I think the problem is that companies like Microsoft and Apple suffer from a star syndrome of sorts, full of themselves they’re utterly convinced another component is something they can well tackle. Turns out it’s only true half of the time, then the rust starts to set and externalities take apart their hubris, only for the cycle to begin again.
A wonderful post marred by a total garbage LLM generated illustration. Did you even look at it before posting? It’s as just embarrassing.
You forgot the WTL! I mean it was unofficial, but while we’re piling up technologies… I recently had to build a C/C++ Excel Add-in with a mixture of MFC, COM, and more and ended up using some WTL, and it was surprisingly good.
Pingback: Developer explains why Windows 11 keeps getting web apps instead of native apps - MaktabIT News
Pingback: Developer explains why Windows 11 keeps getting web apps instead of native apps - Peer Networks UK
Pingback: El desarrollador explica por qué Windows 11 sigue recibiendo aplicaciones web en lugar de aplicaciones nativas | Uco Digital
Everything so interesting, and agreeable.
But the “so nice” picture has text which is pure AI nonsense: just try re-reading it… I’ll bookmark it as a good example to avoid!
We were probably in the same place at the same time in the late 90s “Air Lifts” to Seattle.
I coded as Petzold instructed.
I never “got” MFC. Now, retired with tome, no problem.
I still prefer native. Steve and the assembly code was god in those days. Now, Dave and LLMs make the hard stuff easy
I recently finished up a BLE app in native code. All the examples were wrong, full of “wait for” and “try catch”. As soon as I removed that mess, it worked.
Another hipothesis: while Bill Gates was in charge, he was able to get the Microsoft developers to agree to one or two standards (Win32 native C API + MFC C++ wrapper). Because, for all his faults, he is (was?) a programmer and he understands the developers’ point of view.
When Steve Ballmer took over, this was no longer the case. He is (was?) a sales person and he didn’t understand how these strategies affect external application developers. Because he didn’t understand programming enough, he didn’t intervene (or delegate intervention) in political fights between internal Windows API developer factions, which then broke out and were done in public.
Pingback: Developer explains why Windows 11 keeps getting web apps instead of native apps – Alicloud.my.id
I’ve followed the whole path, from Petzold to WinUI3 and MAUI. OMG… 25 years! I’ve given up. Considering Electron. Considering Flutter and Dart. Fallen back to WinForms for now.
Pingback: Shop Talk: 2026-04-06 – Shop Talk with TriPASS