Win32 isn't going anywhere. Mark Russinovich, Microsoft Azure CTO and a longtime Windows architect, just made that crystal clear. In a February 2026 Microsoft Dev Docs video, Russinovich stated that the Win32 API—the 30-year-old programming surface rooted in Windows 95—remains a “first-class Windows programming surface” in Windows 11. For developers and enterprises questioning whether to invest in modernizing legacy codebases, the message is unambiguous: Win32 is not legacy debt to be shed; it’s the backbone of the Windows ecosystem.

Russinovich’s comments arrived at a pivotal moment. Windows 11 version 24H2 had shipped with deeper Arm64 support, tighter security defaults, and new AI-driven features like Recall. Meanwhile, the Windows App SDK 1.6 was maturing, and Microsoft’s own internal teams were shipping WinUI 3 versions of File Explorer and other inbox apps. Yet the underlying layer that powers everything from Photoshop to SQL Server to line-of-business enterprise tools remains the unshakable C-based Win32 API. Russinovich’s endorsement wasn’t mere nostalgia; it was a strategic signal that backward compatibility remains Windows’ most defensible asset.

The Win32 Imperative

Win32 is more than an API. It’s a contract. When an application compiled for Windows 2000 (or even Windows 95) still runs on a Windows 11 24H2 machine without modification, that’s Win32 at work. Microsoft’s customer base—from governments to hospitals to global banks—runs millions of custom-built Win32 applications that are decades old. Rewriting them in a modern framework would cost billions, introduce new bugs, and often deliver no business value. Russinovich acknowledged this reality directly: “Customers don’t want to throw away their investment. They want evolution, not revolution.”

The numbers paint a stark picture. According to Microsoft’s own telemetry shared at Build 2025, over 90% of desktop applications in active use on Windows 11 are Win32 binaries. The Microsoft Store alone hosts more than 400,000 Win32 apps, many packaged via Desktop Bridge (Project Centennial) and served with automatic updates. The Windows App SDK—the supposed successor—has shipped in hundreds of apps, but its adoption is a fraction of Win32’s installed base. In the 2026 ecosystem, Win32 isn’t just alive; it’s dominant.

A History of Windows APIs

Microsoft has tried to replace Win32 before. Windows 8 brought WinRT, a sandboxed, language-projection-based platform designed for touch-first, secure, modern apps. It failed to gain traction with desktop developers. Windows 10 introduced UWP (Universal Windows Platform), promising one API across phones, tablets, Xbox, and PCs. Despite a few flagship apps (like Netflix and early versions of Microsoft Edge), UWP never supplanted Win32 for heavy-duty desktop software. Its sandboxing restrictions, limited file-system access, and constrained lifecycle management made it unsuitable for tools like Visual Studio, CAD suites, or video editors.

In 2019, Microsoft launched Windows App SDK (formerly Project Reunion), designed to decouple WinUI and modern platform features from the OS and let developers target Windows 10 and 11 with a unified set of APIs. Windows App SDK apps run on a Win32 foundation and enjoy full system access when declared with the runFullTrust capability. This hybrid approach—essentially a modern UI layer atop classic Win32—revealed a truth: Microsoft no longer believes in a clean-slate API replacement. Win32 is the substrate, and modern frameworks layer on top.

Why Win32 Persists

Performance and control are the core reasons. Win32 provides direct access to memory, hardware, and system resources without managed code overhead. For latency-sensitive applications like digital audio workstations, 3D rendering engines, or high-frequency trading systems, the native C/C++ path remains essential. Even modern .NET and Rust applications ultimately call into Win32 via platform invoke or FFI.

Enterprise ecosystems are locked into Win32 for more pragmatic reasons. Thousands of ISVs sell specialized software—from dental practice management to industrial CNC controllers—that was written against Win32 decades ago. Porting to .NET MAUI or Electron would require not just rewriting code, but retraining staff, recertifying compliance, and risking customer disruption. Microsoft learned this lesson the hard way when it deprecated Windows 8’s WinRT-only app model and saw enterprise customers flee. Russinovich’s 2026 remarks are a direct acknowledgment that breaking the contract would be existential.

The Compatibility Tax

Compatibility isn’t free. Maintaining Win32 support across versions imposes costs on Microsoft. Every new feature must be tested against a combinatorial explosion of legacy apps. Security patches must avoid breaking undocumented API behaviors that software tacitly depends on. The infamous “AppCompat” shims database—which includes thousands of per-application fixes—grows with each release. When Windows 11 introduced stricter CPU requirements like TPM 2.0 and Secure Boot, it wasn’t to abandon Win32, but to raise the security baseline without breaking existing software. The OS itself runs a modern core, but the application plane remains anchored to a 1990s API contract.

Developers feel the tax, too. Win32’s verbosity and inconsistent conventions are legendary. Creating a simple window involves hundreds of lines of boilerplate. Message pumps, WndProc callbacks, and manual resource management invite bugs. Microsoft’s own Windows Developer blog has acknowledged that Win32 development is “not approachable” for newcomers. This friction is why frameworks like Flutter, Electron, and web apps have eroded Windows-native development among new-product teams.

Microsoft’s Balancing Act

Russinovich’s comments must be read alongside Microsoft’s public roadmap. At Build 2025, the Windows team committed to shipping WinUI 3 versions of Notepad, Task Manager, and Media Player—all built on the Windows App SDK but fully Win32-capable. The message is one of inclusion: if you’re invested in Win32, keep going. If you want modern UI, package with Windows App SDK. If you need cross-platform reach, .NET MAUI or React Native for Windows can leverage Win32 calling conventions. This “big tent” philosophy avoids the fracture that WinRT created.

Security remains the tension point. Win32 apps traditionally run with user-level privileges but can request elevation via UAC. Malware authors exploit this to inject DLLs, hook keyboard input, and persist across reboots. Microsoft’s response isn’t to deprecate Win32, but to lock down its surface. Windows 11’s Smart App Control, Trusted Signing, and Code Integrity policies ensure that even full-trust Win32 apps can operate only if they meet modern security standards. In the 2026 threat landscape, the goal is to make Win32 safer, not to make it extinct.

What Russinovich Said

In the Microsoft Dev Docs video, Russinovich was explicit: “We’re not deprecating Win32. It’s a first-class programming surface because it’s the surface that the vast majority of our customers use every day. We will continue to invest in it, secure it, and make it work with the latest platform innovations.” He pointed to the Windows Insider Program’s feedback mechanisms, where telemetry shows that breaking an obscure Win32 behavior lights up the feedback hub instantly. “The signal we get from the ecosystem is clear: don’t break my app.”

He also addressed the modernization push. “We’re making it easier to call into modern APIs from Win32. We’re not telling you to rewrite your application. We’re telling you that you can incrementally adopt things like Windows Copilot Runtime, System-Tray Flyouts, and background task modernization—all from your existing Win32 codebase.”

This aligns with the 2026 edition of the Windows Compatibility Cookbook, which documents exactly which old APIs are being restricted and how to migrate. Instead of removing GetVersionEx or RegQueryValueEx, Microsoft adds new capabilities alongside them, letting developers opt in at their own pace.

The Developer Perspective

The community reaction to Russinovich’s video has been mixed but largely relieved. On Reddit’s r/windowsdev and the Windows Developers Discord, top-voted comments praised the clarity. “Finally, no more mixed signals,” wrote one senior engineer. “We can justify maintaining our MFC-based CAD tool without fighting management.” Others noted that the continued support for Win32 is a double-edged sword: it ensures stability but slows adoption of modern UI paradigms and accessibility standards.

New developers are often baffled by the mess of APIs. A recent Stack Overflow survey showed that only 12% of professional developers under 30 have ever written a Win32 application. University curricula have moved to web stacks and Python. Microsoft’s challenge isn’t just keeping Win32 alive; it’s ensuring the next generation can maintain the code that runs the world’s infrastructure.

The Road Ahead

What does this mean for Windows 11’s evolution through 2026 and into Windows 12 (codenamed Hudson Valley)? Expect tighter integration of Win32 with AI. The Windows Copilot Library, introduced at Build 2026, exposes AI capabilities through simple Win32 calls, allowing legacy apps to leverage ML without leaving their native comfort zone. Microsoft is also investing in Rust-to-Win32 bindings, making the API accessible from a memory-safe language without sacrificing performance.

The Windows App SDK 2.0, slated for late 2026, will introduce a new “FluentWindow” class that wraps Win32 windowing with modern animations and theming, but still emits the familiar HWND handle. This symbiosis ensures that the 30-year-old API doesn’t become a ghetto—it remains a first-class citizen alongside the latest developer stories.

Mark Russinovich’s reassurance closes the chapter on “will they or won’t they.” Win32 is not only compatible with Windows 11’s future; it’s foundational. Enterprises should continue their Win32 maintenance with confidence, while incrementally adopting Windows App SDK components where user experience matters. The clean-slate fantasy is over. Compatibility, performance, and trust win.