Microsoft bereitet die schrittweise Open-Source-Freigabe von WinUI vor, dem UI-Framework von Windows 11

• Microsoft hat einen schrittweisen Plan für die Open-Source-Umstellung von WinUI, dem Benutzeroberflächen-Framework von Windows 11, angekündigt.
• WinUI kann nicht sofort vollständig veröffentlicht werden, da es eine komplexe Architektur und viele proprietäre Codeanteile hat; es ist notwendig, zwischen Teilen, die geteilt werden können, und solchen, die das nicht können, zu unterscheiden.
• Die Open-Source-Maßnahme soll in vier Phasen erfolgen
  • Phase 1: Erhöhung der Mirror-Frequenz: Nach der Veröffentlichung von WASDK 1.8 (Ende August) werden interne Commits künftig häufiger mit GitHub synchronisiert, um Transparenz und den Entwicklungsfortschritt zu teilen.
  • Phase 2: Lokale Builds für externe Entwickler: Externe Entwickler können den Code selbst clonen und lokal bauen; außerdem werden Dokumente zu Konfiguration und Abhängigkeiten bereitgestellt.
  • Phase 3: Externe Beiträge und Tests: Community-Mitwirkende können Pull Requests einreichen und lokal testen; gleichzeitig sollen interne Abhängigkeiten bereinigt und die Test-Infrastruktur offenlegt werden.
  • Phase 4: Umstellung auf GitHub-zentrierte Entwicklung: Letztlich wird GitHub zum Kern der zentralen Entwicklung, Issue-Verwaltung und Community-Kommunikation, und das interne Mirror-System wird schrittweise abgeschafft.
• Der Open-Source-Fahrplan von WinUI wird öffentlich auf dem GitHub-Projektboard geführt.
• Entwickler und Nutzer können WinUI durch Feedback, klar formulierte Issues und Abstimmen über bestehende Vorschläge voranbringen

[regentag]

Ich mag weder COM noch Webview ... ein halbwegs brauchbares GUI wäre schön.
Von allen Windows-UI-Lösungen, die ich bisher ausprobiert habe, hat mir Qt4 am meisten gefallen. Bei Qt5 ist das Ganze irgendwie schon deutlich anders geworden.

[regentag]

Ehrlich gesagt war MFC auch gar nicht so schlecht ... haha

[GN⁺]

Hacker News-Kommentare

• Ich mache mir Sorgen um die Zukunft der nativen UI-Technik von Windows. OS-Entwickler haben normalerweise durch ihre eigenen Produkte konsistente und gut funktionierende native Apps geschaffen. Bei Windows 11 ist es jedoch genau umgekehrt. Seit Windows 10 gab es zumindest eine halbwegs funktionierende Standard-Mail- und Kalender-App, doch im neuesten Windows-11-Update wurde diese entfernt und durch einen langsamen WebView-Wrapper ersetzt, der beim Starten mehrere Sekunden benötigt.

• Wenn man sich einen WinUI-Community-Call anschaut, scheint ein Großteil der Neueinstellungen keinerlei Windows-Erfahrung zu haben, und auch das Management kümmert sich anscheinend nicht darum, sodass die Grundlagen nicht wirklich sitzen. Selbst auf Fragen, die ein Windows-Entwickler eigentlich kennen müsste, gibt es keine Antwort – und man versteht nicht einmal, warum die Frage gestellt wurde. Genau deshalb breiten sich in Windows 11 WebView2-Instanzen überall aus.

• Bei den UI-Problemen von Windows 11 wirkt es, als würden neue Apps und Funktionen überbetont, während ältere Werkzeuge kaum modernisiert werden. Die Systemsteuerung etwa hat seit Windows 7 fast dieselbe Hülle. Geht man tiefer, findet man veraltete Tools wie in einem Meme, bei dem man Klammern an Homer Simpson klebt. Die Oberfläche wirkt nur oberflächlich neu; in der Praxis zeigen sich die Grenzen sehr schnell.

• Vielleicht wird MSO (Office) irgendwann vollständig mit Dart und WASM neu geschrieben. Man könnte in einem komplett vom nativen Toolkit unabhängigen Ansatz sämtliche Excel-Funktionen nachbilden und es als O365-Premium-Plan überall verfügbar machen. Vielleicht wird Windows dann wie ChromeOS, wo nur für Sperr- und Anmeldebildschirm noch eine einfache native UI nötig ist und der Rest leichtgewichtig bleibt.

• Wenn man den internen Machtkampf und die harte interne Politik bei Microsoft kennt, kann man nachvollziehen, warum solche Veränderungen passieren. Die Abteilungen ringen offenbar darum, wer oben steht.

• Bei Windows habe ich den Eindruck, dass mindestens zehn unterschiedliche UI-Frameworks wild durcheinandergeworfen wurden. Windows 11 fühlt sich wie ein Besuch im Naturkundemuseum an. Man trifft auf Apps wie MSC, die praktisch im Windows-2000-Stil stecken geblieben sind, und auf Metro-inspirierte, grobe, bunte Oberflächen. Der neue Win11-Look wirkt zwar überzeugend, ist in der Praxis aber wie Lippenstift auf einem Schwein. Das Rechtsklick-Kontextmenü ist ein klassisches Beispiel: Es sieht hübsch aus, doch die Funktionen fehlen, sodass man auf „Mehr anzeigen“ klicken muss, um im alten Stil mehr Funktionen zu sehen. Insgesamt ist es ein chaotischer Mix.

• In Aussagen wie „Ausrichtung an den Microsoft-Zielen“ oder „wir verteilen Ressourcen sorgfältig“ kann ich keine echte Aufrichtigkeit erkennen. Es wirkt wie die Strategie, das Framework auszulagern und zu hoffen, dass engagierte externe Entwickler sich um Wartung und Weiterentwicklung kümmern, während Ressourcen zurückgehalten werden.

• Der Ausdruck „leidenschaftliche Verlierer“ ist zu negativ. Auch wenn ich mit der kühlen Sichtung mitgehen kann, dass mir Win11-UI nicht interessiert oder diese Öffnung nur der Kostensenkung dienen soll, möchte ich denjenigen Respekt zollen, die das weitertragen.

• Ganz klar ist das die typische Großkonzern-Formel: „Keine garantierte Unterstützung, keine Updates außer Sicherheitslücken, benutzt es auf eigene Gefahr.“

• Spöttisch möchte man sagen: „Wann kommt Apache Windows?“ Ernst gemeint: Desktop-UI-Toolkits sind heute weder echter Wettbewerbsvorteil noch Eintrittsbarriere. Auf Windows gibt es mittlerweile 3 bis 4 offizielle UI-Stile. Sicherheit und Stabilität bleiben jedoch weiterhin entscheidend, damit Windows in Unternehmen, im Finanzbereich und in Behörden bestehen kann.

• Dass andere Unternehmen ihre UI-Frameworks offenlegen, kann ich nachvollziehen. Atlassian oder AWS sind solche Frameworks in Jira/AWS direkt nützlich, also für B2B-SaaS durchaus sinnvoll. Dieses Framework aber verstehe ich nicht: Warum sollte man es überhaupt einsetzen? Wer nicht explizit native Windows-Apps bauen will, sollte meiner Meinung nach bessere Optionen haben.

• Ich halte WinUI für gescheitert.

• In der Windows-Entwicklergemeinschaft interessiert sich kaum noch jemand für WinUI; übrig bleiben eher diejenigen, die bereits in WinRT/UWP investiert haben und nicht mehr herauskommen. Seit Windows 8 sind zu viele Brücken abgebrochen, dass die Community das Vertrauen verloren hat. Das wirkt so, als wolle Microsoft das Problem nicht selbst beheben, sondern auf die Community abwälzen.

• Wenn selbst Anbieter wie DevExpress oder Progress Telerik nicht in eigene WinUI-Controls investieren, ist das ein deutliches Zeichen, dass sie an der Zukunft von WinUI nicht glauben. Aus heutiger Sicht sind für Unternehmensanwendungen im Grunde nur WinForms und WPF realistische Alternativen. Ich habe in der Praxis keine App gesehen, die mit WinUI3 entwickelt wurde.

• Ehrlich gesagt: Wer würde heute noch ein Microsoft-UI-Framework ernsthaft nutzen? Auch vorhandene Frameworks werden typischerweise nie abgeschlossen und halbfertig fallen gelassen, bis man sich dem nächsten glänzenden Framework zuwendet. Am Ende werden sie alle vergessen. Dagegen sind Open-Source-Cross-Platform-Frameworks in Grundlagen, Funktionalität und Wartung meist deutlich vollständiger. WinUI wird am Ende wohl ein weiteres vergessliches UWP-Paria.

• Es ist schon schwer zu zählen, wie viele UI-Frameworks es für Windows überhaupt gibt; es ist schlicht chaotisch. Ich frage mich, was man sich eigentlich von der Open-Source-Strategie erwartet. Ist es nur ein Image-Schachzug „Wir sind offen“, oder bringt es Windows-Entwicklern, die auf Windows zielen, echte Vorteile?

• WinUI ist eine Weiterentwicklung von UWP, und UWP wiederum eine Evolution von WinRT. Die Intention von WinUI ist klar, und es ist eine langfristig gewachsene Technologie (derzeit Version 3). MAUI ist eher als Cross-Platform-Lösung denn als Konkurrenzprodukt zu sehen. Trotzdem ist langfristiges Vertrauen kaum zu bekommen, wenn nicht das gesamte OS, insbesondere die Verwaltungstools, wirklich mit WinUI neu aufgebaut werden.

• Die vielen genannten Abkürzungen am Anfang habe ich zuerst für Satire gehalten: WinUI, UWP, WinRT, XAML, Avalon, WPF, Project Reunion, Win2D, MFC, wxWidgets, Qt usw. Die Vielzahl an Versions- und Framework-Namen ist schon im Vorlesen verwirrend und lang.

• Vielleicht fokussiert Microsoft wie immer auf den nächsten Trend (jetzt KI), während es versucht, alte Technologien ruhig abzubauen. Wahrscheinlich reagiert nur eine kleine Minderheit mit offener Gegenwehr.

• Tatsächlich gibt es in Windows nur drei UI-Frameworks, wovon lediglich zwei wirklich leben. Die anderen sind im Grunde nur wiederholte Evolutionen von Win32/Native und WPF/Managed. WinUI3 ist dafür entstanden, diese Lücke zu schließen.

• Langfristig wird MFC meiner Meinung nach am ehesten überleben. Jetzt sind zwar keine Updates mehr geplant, aber es wird wohl noch locker 20 Jahre halten.

• Ich hätte mir gewünscht, dass Microsoft WPF kontinuierlich weiterentwickelt hätte. Ich habe es in vielen Projekten genutzt; trotz Lernkurve sind Data Binding, ViewModel und XAML bis heute angenehm. WPF braucht jedoch ein paar Verbesserungen, um wirklich rund zu sein. Ich habe Microsofts neue Frameworks sowie Open-Source-Lösungen wie Avalonia, Uno ausprobiert, aber entweder liefen die Samples nicht oder der Entwicklungsansatz passte nicht. Deshalb bin ich wieder zu vertrautem WPF zurückgekehrt. Die größte Verbesserungsidee für WPF wäre, das Data-Binding-System nicht per Reflection zur Laufzeit, sondern per Compile-time-Codegenerierung in .NET umzusetzen. Dadurch wären echte AOT-Builds möglich, die Leistung würde deutlich steigen, und man hätte zusätzliche Vorteile wie XAML-Typsicherheit und Cross-Platform-Unterstützung. Ich wollte das selbst als Open Source umsetzen, aber dafür fehlt mir die Zeit und es gibt zu viele andere Aufgaben.

• Der zweite Absatz trifft auf Avalonia zu: Avalonia unterstützt bereits AOT, Compile-Time-Datenbindung und Cross-Platform-Funktionen. Wenn ihr länger kein Update gesehen habt, schaut euch Avalonia compile-time data binding docs und das XamlX-Projekt an.

• Mit diesem Ansatz wäre auch Assembly Trimming möglich. Für eine eigenständige Bereitstellung braucht eine .NET-Library derzeit oft über 200 MB, mit diesem Weg ließe sich das deutlich reduzieren.

• Als ich WinUI3 vorher bewertet habe, war die Entwicklererfahrung zu schlecht. Um eine App zu debuggen, die ich deployen wollte, musste sie wirklich im System installiert werden. Dadurch landen viele unnötige Einträge im Startmenü und die Registry wird unordentlich. Sogar im Beispielcode ist die App beim Klick auf einen Button sofort abgestürzt. Für Windows-App-Entwicklung nutze ich nach wie vor Win32+WTL.

• Dass direktes Debuggen nur bei Installation möglich war, lag daran, dass ich mich für das „packaged“-Modell entschieden hatte. Für Funktionen und Berechtigungen ist genau das vorgesehen. Unter macOS ist es ähnlich: Paket-Apps müssen installiert werden; auch wenn sie nicht im Launchpad erscheinen, sind sie per Spotlight auffindbar.

• Wie viele schon gesagt haben, war Windows UI Framework lange unstrukturiert und wurde immer verworrener. Leider ist es in der Open-Source-Cross-Platform-Welt ähnlich. GTK war für eine Weile ein Desaster, Qt hat viele Features, aber das Lizenzmodell ist für professionelle Nutzung zu schwer. (Nach der Hoffnung aus der Nokia-Phase über MS CEO Elop bis hin zu späteren Besitzerwechseln bei Qt spielt sich diese Geschichte ähnlich ab.) In manchen Bereichen gibt es gute Lösungen wie Dear Imgui, insgesamt fehlt in nativen und Cross-Platform-UI-/Widget-Frameworks aber fast jede Alternative, die permissive Lizenz, natives Kompilieren, gute Widget-Struktur und Vulkan-3D-Rendering gleichzeitig bietet.

• Der häufige Vorwurf gegen Electron oder React Native ist „Web ist einfach schlecht“. Dabei wird oft übersehen, dass es bei Wunsch nach Plattform-Flexibilität kaum echte Alternativen gibt. Microsoft hätte in diesem Bereich wirklich ein relevantes Produkt schaffen können, aber der Versuch war zu lau, und deshalb ist nie wirklich ein gutes Ergebnis entstanden.

• Ich hätte es gerne, wenn Windows 11 wieder eine native vertikale Taskleiste bekäme. Dieses Feature existierte schon in Windows 98 und ist in 11 verschwunden. Es gibt zwar Drittanbieter-Tools wie Windhawk (erzwingt horizontale Taskbar) oder StartAllBack (stellt Windows-10-Code wieder her), aber beide sind nicht perfekt.

• Wenn ein UI-Framework open-source wird, wird die Taskleistenfunktion dadurch nicht besser. In diesem Bereich sind Beiträge nur möglich, wenn die Taskleiste selbst (also explorer.exe) offen ist.

• Zur Info: Eine vertikale Taskleiste war schon seit Windows 95 als Option vorhanden.

• Die Taskleistenfunktion gehört zu explorer.exe. Die aktuelle Open-Source-Ankündigung hat nichts mit explorer zu tun.

• Ich bezweifle, dass das Windows-Team wirklich native Desktop-UI mit WinUI baut.

• Windows-UI-Arbeit läuft heute über Win32, GDI und DirectDraw. Dank CsWin32 und modernem C# (ref returns) ist der Zugang gegenüber früher deutlich einfacher geworden. Früher musste man meist ein eigenes C++-Projekt aufsetzen; jetzt kann man in die native methods-Datei nur die benötigten Funktionen schreiben und der Codegenerator übernimmt den Rest. Win32 ist zwar deutlich low-leveler als andere Frameworks, aber genau deshalb ist es für Microsoft schwieriger, es zu entfernen oder umzubauen. Auf lange Sicht hat kaum eine API so lange durchgehalten. Auch die Web-Plattform kommt langfristig nicht annähernd dagegen an.

• Dennoch braucht man in vielen Bereichen weiterhin C++. Das liegt am Festhalten von Microsoft an COM. Windows Runtime Components hätten die Chance geboten, die .NET-Ökosystemqualität zu steigern, aber Microsoft hat sie verpasst. Shell-Erweiterungen, Kontextmenüerweiterungen usw. müssen in C++ umgesetzt werden; wenn man das in .NET machen will, landet man oft bei einem C++-Stub, das dann den .NET-Prozess aufruft.

• Für mich ist die Diskussion über High-Level-Frameworks weniger spannend als die über Low-Level-APIs. Der gesamte Windows-Render-Stack basiert meines Erachtens auf GDI/DirectX, und auch Win32 sitzt letztlich auf GDI. Wenn man den wirklich nah am Metal liegenden Windows-UI-Stack diskutieren will, sollte man mit DirectX anfangen.

• Aus Nutzersicht ist Win32 immer noch genug High-Level. Bis heute ist Win32 das einzige Toolkit, mit dem man Buttons, Scrollbars usw. sauber rendern kann.

• Ich wünsche mir, dass die Community ein wirklich gutes Framework für native Windows-Entwicklung bereitstellt. Die Realität ist jedoch, dass dafür keine ausreichend große Community vorhanden ist.

• In der früheren Windows-UI-Entwicklung hat mir am meisten gefehlt, dass es früher einfach war, Apps zu bauen, die sich so anfühlten, als wären sie direkt von Microsoft gemacht. Seit Einführung von Web-Technologien ist die Konsistenz der Windows-UI-Erfahrung stark zerstört. Es ist ein Problem, dass Microsoft alte Apps nicht aktualisiert hat, aber auch ein Problem, dass neue Tools keine den Style Guides entsprechende Bibliotheken liefern. Diese Entwicklung begann schon bei Vista, und bei MSDN wurden Beispiele wie „So nutzen Sie diese Funktion“ zunehmend knapper.