Jeffrey Snover has a knack for saying what others at Microsoft only whisper. The inventor of PowerShell, a Technical Fellow emeritus who spent decades shaping how Windows administrators interact with machines, has now turned his attention to something that’s been broken for a very long time: Microsoft’s approach to graphical user interface development.
His verdict is blunt. Microsoft hasn’t had a coherent GUI strategy since Charles Petzold’s Programming Windows was the bible of desktop development. That book, first published in 1988 and updated through the late 1990s, taught a generation of programmers how to write Windows applications using the Win32 API. Since then? A trail of abandoned frameworks, false starts, and developer whiplash that has left the Windows desktop in a state of strategic incoherence unmatched by any of its competitors.
In a blog post published on his personal site, Snover lays out the case with the kind of directness you’d expect from someone who once had to fight internal Microsoft politics just to get a command-line shell shipped. His argument isn’t merely nostalgic. It’s structural. The problem, as he frames it, is that Microsoft has repeatedly introduced GUI frameworks, attracted developers to them, and then walked away — sometimes quietly, sometimes with a loud pivot to whatever the next internal team’s pet project happened to be.
The litany is familiar to anyone who’s built Windows applications professionally. Win32. MFC. Windows Forms. WPF. Silverlight. UWP. WinUI 2. WinUI 3. MAUI. Each one promised to be the definitive way to build graphical applications on Windows. Each one eventually lost momentum, executive sponsorship, or both.
That’s not evolution. That’s churn.
The Petzold Standard and What Came After
To understand why Snover’s critique resonates so deeply with veteran Windows developers, you have to understand what the Petzold era actually represented. Charles Petzold’s books didn’t just teach the Win32 API. They embodied a time when Microsoft had a single, clear answer to the question: “How do I build a Windows application?” You learned the message loop, you learned GDI, you learned about window procedures and device contexts, and you were off. The platform was hard but it was unified. There was one path.
Windows Forms, introduced with .NET in 2002, was the first attempt at modernization. It was simpler. It was productive. Developers loved it. Microsoft then introduced Windows Presentation Foundation (WPF) in 2006, a far more ambitious framework based on XAML, vector graphics, and data binding. WPF was technically impressive but significantly more complex, and it never fully supplanted Windows Forms in practice. Many shops stuck with WinForms. Many still do.
Then came Silverlight, Microsoft’s answer to Adobe Flash for rich internet applications. Silverlight was killed. Then came UWP — the Universal Windows Platform — which was supposed to unify app development across Windows 10, Xbox, HoloLens, and phones. The phones died. UWP adoption was anemic among third-party developers, hampered by sandboxing restrictions and a distribution model that required the Microsoft Store.
WinUI was supposed to extract the good parts of UWP’s UI layer and make them available to traditional desktop apps. WinUI 3, bundled into the Windows App SDK, has been in various stages of “ready” for years now. And .NET MAUI — the successor to Xamarin.Forms — was pitched as a cross-platform framework for building apps on Windows, macOS, iOS, and Android from a single codebase. Its reception has been rocky, plagued by bugs, missing features, and a general sense among developers that it was shipped before it was finished.
Snover’s point isn’t that any one of these frameworks was bad in isolation. Some were quite good. His point is that the pattern of introduction-and-abandonment has destroyed trust. A developer who bet on Silverlight in 2009 got burned. A developer who bet heavily on UWP in 2015 got burned. The rational response, increasingly, has been to not bet on Microsoft’s GUI frameworks at all — to use Electron, or web technologies, or cross-platform toolkits like Qt, or simply to build everything as a web app and sidestep the question entirely.
And that’s exactly what has happened. Look at the most prominent applications on Windows today. Teams was built on Electron before being rewritten with WebView2. Visual Studio Code is Electron. Slack, Discord, Spotify — all use web-based rendering engines wrapped in desktop shells. Microsoft’s own flagship products increasingly avoid Microsoft’s own GUI frameworks. The irony is thick.
The contrast with Apple is instructive, if painful for Microsoft partisans. Apple has had its own framework transitions — from Carbon to Cocoa, from AppKit to SwiftUI — but the trajectory has been far more coherent. SwiftUI, introduced in 2019, builds on decades of investment in the Cocoa model and is clearly positioned as the future. Apple deprecated the old approaches but gave developers long runways and clear migration paths. Crucially, Apple’s frameworks are what Apple itself uses to build its own apps. The signal is unmistakable: this is the way forward, and we’re walking it too.
Microsoft has never managed to send that signal with the same clarity. The Windows shell itself is a patchwork of Win32 controls, XAML islands, and web views. The Settings app uses one framework; the Control Panel underneath it uses another. File Explorer has been partially modernized multiple times without ever being fully rewritten. The result feels like an archaeological dig — layers upon layers, each one reflecting a different era’s strategic priorities, none of them fully realized.
Snover’s blog post has generated significant discussion among developers and industry observers. On X (formerly Twitter), reactions have ranged from weary agreement to pointed frustration. Several prominent developers noted that the post articulates something they’ve felt for years but rarely seen stated so plainly by someone of Snover’s stature within the Microsoft orbit.
The timing of Snover’s critique is notable. Microsoft is pouring enormous resources into AI — Copilot is being embedded into everything from Windows to Office to Azure. The company’s stock price and strategic narrative are dominated by its partnership with OpenAI and the race to monetize large language models. In that context, traditional GUI development can feel like an afterthought. But applications still need interfaces. Users still need to interact with software through windows, buttons, text fields, and menus. The GUI isn’t going away just because the backend is getting smarter.
If anything, AI makes the GUI question more urgent, not less. Copilot-powered applications need rich, responsive interfaces. The agents and assistants that Microsoft envisions need front ends that can handle complex interactions — displaying code, rendering documents, managing multi-step workflows. Building those interfaces well requires a modern, well-supported, coherent UI framework. What does Microsoft recommend for that today? The answer depends on which team you ask, which documentation page you land on, and whether you’re building for Windows only or multiple platforms.
That ambiguity is the problem.
Some inside Microsoft would argue that WinUI 3 and the Windows App SDK represent the current answer, and that the framework is maturing. Others would point to .NET MAUI for cross-platform scenarios, or Blazor Hybrid for developers who want to use web technologies inside a native shell. The issue isn’t a lack of options. It’s the opposite — there are too many options, none of them clearly dominant, and developers have learned the hard way that today’s recommended framework may be tomorrow’s afterthought.
The web, meanwhile, keeps winning by default. Not because web technologies are inherently superior for desktop applications — they often aren’t — but because they’re stable, widely understood, and platform-independent. A developer who builds a web app today can be reasonably confident that browsers will continue to support it for years. That kind of confidence is something Microsoft’s desktop GUI frameworks haven’t been able to offer in over two decades.
Snover doesn’t claim to have all the answers. But his diagnosis is precise and, for many who’ve lived through the framework wars, long overdue from someone of his standing. Microsoft needs to pick a direction, commit to it publicly and organizationally, use it in its own flagship products, and stick with it for at least a decade. Not five years. Not until the next reorg. A decade.
Whether Microsoft’s current leadership — focused as it is on cloud and AI — has the appetite for that kind of long-term commitment to desktop GUI tooling is the open question. The history suggests they don’t. But as Snover’s post makes clear, the cost of continued incoherence isn’t zero. It’s measured in lost developers, lost applications, and a platform that increasingly feels like it belongs to everyone except the company that makes it.
WebProNews is an iEntry Publication