Summary
A personal account of the chaos in Windows native development ecosystem, tracing the evolution from Win32 to WinUI 3 and explaining why developers turn to Electron instead.
The Evolution of Windows Programming
The UI framework evolution alone tells the story:
- Win32: The C API - still highly relevant today
- MFC: C++ wrapper with classes and templates
- .NET: C# with automatic memory management
- Windows Forms: Wrapper around Win32 windowing APIs
- WPF (2006): XAML + GPU-rendered controls
- WinRT (2012): Cross-device attempt
- UWP (2015): Sandbox restrictions, still not full power
- WinUI 3 (2021): Finally exposes all features to all Windows apps
"I am here to report that the scene is a complete mess. I totally understand why nobody writes native Windows applications these days, and instead people turn to Electron."
The Built Utility: Display Blackout
Simple requirements that exposed the complexity:
- Enumerating displays and bounds
- Placing borderless, titlebar-less windows
- Global keyboard shortcuts
- Startup functionality
- Persistent settings
- System tray icon with menu
The Three Development Paths
- C++: Full control, maximum complexity
- C#/XAML framework-dependent: Smaller distribution, but potential runtime issues
- C#/XAML self-contained: Largest distribution, but massive file sizes
Core Insight: Each abstraction attempt (WinForms → WPF → WinRT → UWP → WinUI 3) was supposed to be "the new foundation" but got replaced within years, leaving developers with a tangle of legacy APIs.
Why This Matters
This is a cautionary tale of platform fragmentation. While Apple (Cocoa → Cocoa Touch) and Linux (glibc → ...) maintained relative stability, Windows has repeatedly abandoned its development frameworks, creating a fragmented ecosystem where "latest and greatest" means navigating a minefield of deprecated technologies.