- Bis Ende der 1980er Jahre war die Entwicklung von Windows-Apps mit einem einzigen, auf der Win16/Win32 API basierenden Modell klar definiert, danach wiederholten sich über Jahrzehnte inkonsistente Plattformwechsel
- Der Zusammenbruch der Windows-GUI-Strategie geht nicht auf das Scheitern einzelner Technologien zurück, sondern auf drei organisatorische Ursachen: Politik zwischen Teams, eine von Entwicklerkonferenzen geprägte Ankündigungskultur und strategische Kurswechsel ohne Vorwarnung
- 1988 gab Charles Petzolds Programming Windows mit Win32 als einheitlicher API und einheitlichem Mentalmodell eine klare Antwort auf die Frage, „wie baut man Windows-Apps“, doch in den folgenden 30 Jahren gelang es Microsoft nicht, diese Klarheit wiederherzustellen
- Von MFC, OLE, COM, ActiveX, WPF, Silverlight, WinRT, UWP, WinUI 3 bis MAUI setzte sich über Jahrzehnte eine ungeordnete Vielfalt an GUI-Frameworks fort; bei jeder gescheiterten Initiative war nicht ein technischer Mangel, sondern vor allem organisatorisches Versagen bei Entscheidungen die Hauptursache
- Derzeit werden unter Windows tatsächlich mehr als 17 GUI-Technologien eingesetzt, und die am weitesten verbreitete Desktop-GUI-Technologie, Electron, wurde nicht von Microsoft, sondern extern entwickelt
- Die Kerndiagnose „Wenn eine Plattform die Frage ‚Wie soll ich UI bauen?‘ nicht in 10 Sekunden beantworten kann, hat diese Plattform ihre Entwickler im Stich gelassen“ trifft auch im Jahr 2026 unverändert auf Microsoft zu
Microsoft nach dem Verlust einer kohärenten GUI-Strategie
- Seit mehr als 30 Jahren hält die Verwirrung um die Windows-GUI-Strategie an, und auf die Frage „Welches Framework sollte man für eine neue Windows-Desktop-App verwenden?“ gibt es keine klare Antwort
- 1988 existierte mit der Win16/Win32 API ein einziges Modell, mit dem Entwickler Apps auf einheitliche Weise schreiben konnten
- In den folgenden Jahrzehnten war Microsoft wegen interner Politik, vorführungsorientierter Entscheidungsfindung und Veränderungen der Geschäftsstrategie nicht in der Lage, eine konsistente Plattform aufrechtzuerhalten
- Das Ergebnis ist, dass von Win32 bis MAUI 17 GUI-Technologien nebeneinander existieren und Entwickler auf einer Plattform ohne Strategie mit Verwirrung kämpfen
- Nicht technisches Scheitern, sondern organisatorisches Scheitern ist die eigentliche Ursache
Die Petzold-Ära: die letzte wirklich klare Phase
- 1988 war Charles Petzolds Programming Windows (852 Seiten) die eine maßgebliche Antwort darauf, wie man mit der Win16 API in C arbeitet, und genau das war die Strategie der Windows-Entwicklung
- Auch Win32 wurde größer, behielt aber mit Message Loop, Window Procedure und GDI ein einziges Mentalmodell bei; Petzold erklärte es, und Entwickler konnten es lernen und sofort nutzen
- „Ein OS, eine API, eine Sprache, ein Buch“ — diese Klarheit war ein Vertrauenssignal der Plattform
Der objektorientierte Boom (1992–2000): der Beginn der Komplexität
- 1992 kapselte MFC Win32 in C++, doch danach traten OLE, COM und ActiveX auf, und statt GUI-Frameworks begannen Komponentenarchitekturen, die gesamte Windows-Entwicklung zu durchdringen
- Microsoft bot statt einer konsistenten Story nur technologische Primitiven an, die Entwickler selbst zusammensetzen mussten; der Grund war eine keynote-zentrierte Konferenzkultur, in der die Wirkung auf Führungskräfte wichtiger war als der Erfolg der Entwickler
PDC 2003 Longhorn: eine Vision, die sich selbst verschlang
- Das auf der PDC 2003 vorgestellte Longhorn war eine überzeugende Vision mit drei Säulen: WinFS (relationales Dateisystem), Indigo (einheitliche Kommunikation), Avalon (GPU-beschleunigte XAML-basierte UI)
- Im Januar 2004 bezeichnete ein internes Memo von Jim Allchin dies als „Schwein (a pig)“, und im August desselben Jahres wurde ein vollständiger Entwicklungs-Reset angekündigt — zurück auf den Codebestand von Server 2003
- Nach dem Reset gab die Führung die Vorgabe aus: „kein Managed Code in Windows, aller neuer Code in C++“; WPF wurde zwar zusammen mit Vista veröffentlicht, aber die Shell selbst verwendete kein WPF
- Diese Entscheidung löste zwischen dem Windows-Team und dem .NET-Team einen 13 Jahre dauernden internen Bürgerkrieg aus, der letztlich zur Verwaisung von WPF, zur Aufgabe von Silverlight und zum Scheitern von UWP führte
Silverlight: Etablierung eines Musters, das sich wiederholen sollte (2007–2010)
- WPF wurde Ende 2006 veröffentlicht, doch 2007 erschien Silverlight als Browser-Plugin gegen Flash, wodurch sich die Entwicklungsinvestitionen verteilten
- Auf der MIX-Konferenz 2010 sagte ein Microsoft-Manager während einer Q&A-Session, „Silverlight ist keine Cross-Platform-Strategie, sondern eine Windows-Phone-Strategie“ — das Silverlight-Team war darüber nicht im Voraus informiert worden, und auch Entwickler, die LOB-Apps in Silverlight investiert hatten, erfuhren es erstmals über die Q&A auf der Konferenz
- Das Ende von Silverlight war nicht Folge technischen Scheiterns, sondern eines Wechsels der Geschäftsstrategie; in dieser Phase etablierte sich die Struktur, dass Entwickler immer als Letzte informiert werden
Metro und der Krieg der zwei Teams (2012)
- Als Reaktion auf 200 Millionen verkaufte iPhones von Apple und die Verdrängung des PCs durch das iPad wurden Windows 8 und Metro veröffentlicht, doch WinRT wurde bewusst nicht als .NET-basierte, sondern als native C++-Runtime entworfen — ein direktes Ergebnis der Abneigung des Windows-Teams gegen .NET
- Auf der //Build 2012 empfingen Entwickler gleichzeitig widersprüchliche Botschaften: „Die Zukunft ist WinRT, HTML+JS ist First-Class, .NET funktioniert weiterhin, C++ ist zurück, Metro-Apps kann man auch schreiben, WPF-Code läuft weiterhin“
- Enterprise-Entwickler prüften Sandboxing, Store-Distributionsanforderungen und fehlende Win32-APIs bei UWP und wanderten sofort ab — „der Tablet-App-Store wurde am Ende nie Realität“
Das Chaos um UWP und WinUI (2015–heute)
- Die UWP (Universal Windows Platform) von Windows 10 war die Vision „einmal schreiben, überall ausführen“ für PC, Phone, Xbox und HoloLens, doch mit dem Niedergang von Windows Phone und der Tatsache, dass selbst Microsofts wichtigste Apps (Office, Visual Studio, die Shell) UWP nicht nutzten, wurde das Signal eindeutig
- Die offizielle Antwort verkam zu „it depends“ — UWP, Beibehaltung von WPF, XAML Islands, Warten auf WinUI 3, Koexistenz von WinUI 2, Veröffentlichung von Project Reunion und Umbenennung in Windows App SDK verstärkten die Verwirrung weiter
- Project Reunion / WinUI 3 ist zwar ein technischer Fortschritt, doch seine bloße Existenz ist selbst das Produkt eines organisatorischen Problems, bei dem UWP-Controls an das OS gebunden waren und weder das .NET-Team noch das Entwicklerwerkzeug-Team darüber verfügen konnten
- Rückblick eines Entwicklers aus dem Jahr 2024: „UAP, UWP, Ersatz von C++/CX durch C++/WinRT (ohne Tooling-Support), XAML Islands, XAML Direct, Neustart mit Project Reunion, Neustart mit WinAppSDK, der verwirrende Übergang zwischen WinUI 2.0 und 3.0… 14 Jahre, 14 Pivots“
Ein Zoo ohne Pfleger: die aktuelle Liste der GUI-Technologien unter Windows
Microsoft-native Frameworks:
- Win32 (1985) — weiterhin in Nutzung, Petzolds Buch ist immer noch gültig
- MFC (1992) — im Wartungsmodus, weiterhin in Enterprise- und CAD-Bereichen vorhanden
- WinForms (2002) — „nutzbar, aber nicht empfohlen“, für Dateneingabeformulare immer noch am schnellsten
- WPF (2006) — XAML, DirectX-Rendering, Open Source, keine neuen Investitionen von Microsoft
- WinUI 3 / Windows App SDK (2021) — die offizielle „moderne“ Antwort, Roadmap unklar
- MAUI (2022) — plattformübergreifender Nachfolger von Xamarin.Forms, die aktuelle Wette des .NET-Teams
Microsoft-Web-Hybride:
- Blazor Hybrid — .NET-Razor-Komponenten in nativer WebView
- WebView2 — eingebettetes Chromium in Win32-/WinForms-/WPF-Apps
Drittanbieter:
- Electron — Chromium + Node.js, eingesetzt von VS Code, Slack und Discord, derzeit die am weitesten verbreitete Desktop-GUI-Technologie unter Windows, aber ohne Bezug zu Microsoft
- Flutter (Google), Tauri (Rust-basiert), Qt (C++/Python/JS), React Native for Windows (von Microsoft gefördert, aber auf Facebook-Technologie basierend)
- Avalonia — der Open-Source-geistige Nachfolger von WPF, übernommen von Entwicklern wie JetBrains, GitHub und Unity, die nicht auf Microsoft gewartet haben
- Uno Platform — stärker WinUI verpflichtet als Microsoft selbst
- Delphi/RAD Studio, Java Swing/JavaFX — in vertikalen Märkten und im Enterprise-Bereich weiterhin am Leben
→ 17 Ansätze, 5 Programmiersprachen, 3 Rendering-Philosophien — keine „Plattform“
Kerndiagnose
- Alle gescheiterten GUI-Initiativen lassen sich auf eine von drei Ursachen zurückführen: Politik zwischen Teams (Windows vs. .NET), frühe Plattformwetten getrieben von Konferenzankündigungen (Metro, UWP), strategische Geschäftswechsel ohne Vorabinformation der Entwickler (Silverlight)
- Die Technologien selbst waren oft hervorragend — WPF hervorragend, Silverlight hervorragend, XAML hervorragend — organisatorisches Scheitern wurde zum Produktversagen
- Ohne eine Plausible Theory of Success, die den gesamten Lebenszyklus von „Adoption–Investition–Wartung–Migration“ abdeckt, ist das keine Strategie, sondern nur eine Konferenz-Keynote
- Charles Petzold überarbeitete Programming Windows bis zur 6. Auflage, um mit den von Microsoft vorgestellten Neuerungen Schritt zu halten, stellte das Schreiben aber nach der 6. Auflage über WinRT (Windows 8) ein
2 Kommentare
Am Ende also doch wieder Win32?!!
Hacker-News-Kommentare
Das grundlegende Problem ist, dass Microsoft versucht, GUI-Konsistenz nur auf der Framework-Ebene zu lösen
WinForms, WPF, UWP, WinUI und so weiter — ständig werden neue Frameworks herausgebracht und am Ende wieder fallen gelassen
Apple betrachtet dagegen das Designsystem selbst als Produkt und macht die Frameworks unsichtbar, während Microsoft jedes Mal den umgekehrten Weg geht
Magst du auch Beispiele von Apple nennen?
Heutzutage imitiert WPF immerhin WinUI-Skins, also bemüht sich Microsoft zumindest
Selbst im aktuellen .NET-Stack ist es weiterhin einer der offiziellen Wege
WinForms ist immer noch attraktiv
Dank WebView2 ist die Entwicklung hybrider Apps einfacher geworden, und man könnte auch vollständig aufs Web setzen, aber das Gefühl von nativem Chrome ist angenehmer
Da alle Kunden Windows verwenden, gibt es keinen Grund, dagegen anzukämpfen
In letzter Zeit baue ich mit .NET10 + WinForms + WebView2 einen AI-Assistenten
Ich möchte mir gar nicht vorstellen, die UI für den Gesprächsverlauf in reinem WinForms immer wieder anzupassen
Ich stimme der Aussage „WPF war gut“ nicht zu
Auf normaler Hardware der späten 2000er waren WPF-Apps langsam
Zum Beispiel verlangte Logos Bible Software trotz einer simplen Textanwendung Grafikleistung, wodurch ältere Laptops ins Stocken gerieten
Später stellte sich heraus, dass Logos 4 auf WPF basierte, und auch im Forenbeitrag gab es viele ähnliche Beschwerden
Am Ende habe ich den Großteil des Codes in Direct3D/Direct2D neu umgesetzt
Die WPF-Architektur selbst war das Problem
Als Gründe wurden unscharfer Text und Performance-Probleme genannt
Zugehörige Beiträge: edandersen.com / Reddit
Dazu passend: Ars Technica
Am Ende wiederholt sich die Performance-Debatte in jeder Ära
Auch Apple erlebt beim Übergang von AppKit/UIKit zu SwiftUI ähnliche Probleme
Als ChatGPT erstmals durch die Decke ging, war es eine geniale Idee, dass Bing eine webbasiert zugängliche Version integriert hat
Microsoft hat aber Details wie Kontextkomprimierung nicht umgesetzt, sodass Gespräche schnell blockiert wurden
OpenAI, Perplexity und andere haben das dagegen gut implementiert, und inzwischen ist es zum Standard geworden
Hätte Microsoft es damals richtig gemacht, hätte es Google womöglich verdrängen können
Am Ende lag das Problem an der mangelnden Ausgereiftheit von UI/UX, und ich denke, das hängt mit der fehlenden Konsistenz der Unternehmenskultur zusammen
Es war frustrierend, dass Apple das Bündeln von UI-Bibliotheken verhindert, aber dadurch blieb eben auch die UI-Konsistenz erhalten
Die meisten Nutzer interessiert das nicht
Jemand kopiert wohl immer wieder eine Geschichte über ein Abendessen mit Microsoft-Führungskräften hinein, und der Kern davon lautet: Microsoft geht voll auf Enterprise
Tatsächlich springen aber wegen der sinkenden Qualität von Windows und Azure selbst Unternehmen ab
Auch unsere Firma hat durch Azure-SLA-Probleme Schaden erlitten und keinerlei Entschädigung erhalten
Deshalb reduzieren wir unsere Abhängigkeit von Active Directory und Windows
Letztlich gibt es keinen Enterprise-Markt ohne Nutzer
Seit Win32 hat Microsoft nie länger als zwei Jahre eine Richtung konsequent verfolgt
WinRT war in Ordnung, aber mit Nadella kam der Schwenk auf Azure, und die Windows-Plattform wurde aufgegeben
Beim Wandel von Windows zu Office zu Azure ist die Identität verschwommen
Office gibt es sowohl im Web als auch auf dem Desktop, dazu kommen Hardware und Store
Satya Nadellas Vision wird nicht klar vermittelt
Der Store war miserabel und im Grunde nur ein Projekt für interne Beförderungen
Dass Microsoft ständig neue GUI-Frameworks herausbringt, ist das Problem, aber Win32-Apps lassen sich immer noch schreiben
Microsoft hat sich schon lange in Richtung Web orientiert und auch zu Entwicklungen wie AJAX, Flexbox und Grid beigetragen
Ich entwickle hauptsächlich plattformübergreifende Systeme auf Basis von Web, Java und Python
Es gibt keinen besonderen Grund, eine reine Windows-GUI zu bauen
Web-Apps sind flexibler und besser zugänglich
Das Web läuft überall, und mit PWABuilder ist sogar die Veröffentlichung in App Stores möglich
Ich arbeite an diesem Projekt mit, und man kann schnelle, schlanke Apps ohne Electron bauen
Die Dokumentation zu Active Desktop zeigt, wie experimentell das damals war
Das Web ist nur ein Behelf, wirklich gute Erfahrungen kommen von nativen Apps
Um 2007 bin ich von Delphi zu WPF gewechselt, aber 2010 habe ich Windows komplett verlassen
Die interne Politik bei Microsoft und das ständige Einstellen von Technologien waren einfach zu extrem
Da Rails gerade aufkam, war der Wechsel leicht
Vielleicht ist das Stockholm-Syndrom, aber da auch Visual Studio weiterhin auf WPF basiert, mache ich mir keine Sorgen
In gewisser Weise war das ein früher Vorgeschmack auf die Probleme des heutigen Big Tech
Steven Sinofsky hat kürzlich wieder etwas zum gleichen Thema geschrieben
x.com-Link
Er war zur WinRT-Zeit in DevDiv, aber das Windows-Team verstand die Bedürfnisse von Entwicklern nicht
Es gab sogar einen Python/WinRT-Prototyp, der aber mit der Begründung verworfen wurde, „Entwickler wollen nur JS“
Der Metro-Stil wurde so stark erzwungen, dass in Visual Studio alle Menüs in Großbuchstaben geändert wurden
Windows RT kappte außerdem die Kompatibilität, weshalb es kaum Apps gab, und scheiterte am Ende
Einige von Sinofskys technischen Behauptungen sind sogar falsch (.NET 3.0 war in Vista enthalten)
xcancel.com unterstützt diese Funktion bislang nicht
Die Antwort ist offensichtlich — Qt
Kein Scherz: Wenn man nicht Electron verwendet, ist Qt die echte Alternative
Für Qt ist das Kerngeschäft, daher wird die Richtung nicht ständig geändert