Microsofts gescheiterte / fehlende GUI-Strategie für Windows

Heute noch ein Thema, welches sich mit der gescheiterten GUI-Strategie von Windows über die letzten Jahrzehnte befasst – wobei ich konstatiere, dass Redmond da nichts in Bezug auf GUI-Strategie hat. Ein Insider hat vor einiger Zeit aus dem Nähkästchen geplaudert. Ich habe zudem ein wenig aus eigenem Erleben beigetragen. Hier ein kleiner Abriss.

Inneneinsichten: Microsofts Windows GUI-Strategie

Getriggert wurde der Artikel hier durch den Blog-Beitrag Microsoft Hasn't Had a Coherent GUI Strategy Since Petzold von Ex Microsoft Mitarbeiter Jeffry Snover. Snover ist heute im Ruhestand, stieß aber 1999 als Bereichsarchitekt zu Microsoft und war im Geschäftsbereich "Management and Services" tätig. Dort war er für die technische Ausrichtung der Managementtechnologien und -produkte von Microsoft verantwortlich.

Petzold mit klarer Vision und Strategie

Snover skizziert in seinem Blog-Beitrag die Irrungen und Wirrungen der Microsoft Windows GUI über die letzten Jahrzehnte. Er startet mit Charles Petzold, der 1988 sein Werk "Programming Windows" veröffentlicht hat. Hier einige Zitate:

• [Am Anfang war] Die Win16-API in C. Und trotz ihres Umfangs stellte sie etwas Bemerkenswertes dar: eine einzige, schlüssige und maßgebliche Antwort auf die Frage, wie man eine Windows-Anwendung schreibt. In der Branche nennen wir das eine „Strategie".
• Das darauf folgende Win32 war umfangreicher, aber immer noch kohärent. Nachrichten-Loops; Fensterprozeduren; GDI. Das mentale Modell war ein bisschen schräg, aber es war ein einziges mentales Modell.

Snover fasst es so zusammen: "Petzold erklärte es [Die Windows GUI-Programmierung]. Es war das Fundament von Windows. Einfach, Leistungsstark, man lernte es, man nutzte es. Man war erfolgreich. Klarheit ist dein Freund! Ein Betriebssystem, eine API, eine Sprache, ein Buch." Und noch ein Insight aus den frühen Windows-Tagen liefert Snover: Es gab kein Komitee, das über Alternativen für Managed Code debattierte. Es gab nur Win32 und Petzold, und es funktionierte.

Der Absturz im Chaos

Dann skizziert Snover, wie die "Bürokratie" und ein krudes Management bei Microsoft den Ansatz von Petzold gekillt haben. neowin.net, über deren Artikel hier ich auf den Beitrag von Snover gestoßen bin, fasst es etwas zusammen.

In den 1990er Jahren versuchte Microsoft dann, die Einschränkungen von Win32 mit MFC, COM, OLE und ActiveX zu umgehen. War zwar kein GUI, aber die Komponentenarchitekturen durchdrangen laut Snover jeden Winkel der Windows-Entwicklung mit steigender Komplexität. Der von Snover als Clusterfu*k (deutsch: riesen Schlamassel) bezeichnete "Abstieg" begann. Der Insider schreibt von "Objekt-orientiertem Fiebertraum" von 1992–2000.

Im Jahr 2003 präsentierte Microsoft Windows Longhorn, mit Avalon (später bekannt als WPF) als GUI-Technologie. Avalon baute auf dem GPU-beschleunigten, vektorbasierten UI-Subsystem XAML auf.

Im August 2004 gab es von Microsoft die neueste interne Vorgabe, für alle neuen Entwicklungen C++ zu verwenden. Windows Presentation Foundation (WPF) sollte zwar mit Windows Vista ausgeliefert werden, doch die Shell selbst sollte es nicht nutzen. Es gab dann Zoff zwischen dem .NET-Team und dem Windows-Entwicklerteam, und das Verhältnis sollte sich nicht mehr erholen.

WPF wurde zwar Ende 2006 intern fertig und hätte Potential gehabt, so Snover. Stattdessen kam der feuchte Traum von Silverlight als Technologie auf, der von 2007 an bis 2010 seine Urstände feierte. Am Ende des Tages starb Silverlight als Technologie (und Flash-Killer), während WPF zwar blieb, aber verwaiste.

Danach kam die Universal Windows Platform (UWP) heraus, die seinerzeit schon bei ihrer Einführung zum Scheitern verurteilt war. HTML 5 war ist nun der Standard, nur hat man dem Silverlight-Team das nicht mitgeteilt. Hier im Blog hatte ich 2015 Silverlight am Ende? Edge unterstützt es nicht! und Update KB4481252 für Silverlight (15.1.2019) letztmalig was zu dieser "Krankheit" geschrieben.

Aber Microsoft wäre nicht Microsoft, wenn sich die Konfusion nicht noch toppen ließ. 2012 kam es zu Windows 8.x Metro-Entwicklung, was Snover als "Metro-Panik und der Krieg der Teams" bezeichnet. Apple hatte 200 Millionen iPhones verkauft und das iPad grub den PCs das Wasser ab. Microsoft kam schwungvoll mit Windows 8 und Metro, um "den Markt zu übernehmen" und fiel bekanntlich auf die Nase.

Snover berichte, dass sich intern zwei Teams (.NET und Windows-Entwicklung) bekriegten. Spannend die Insides von Snover. Windows 8.x hatte eine touch-orientierte Laufzeitumgebung namens WinRT, die bewusst nicht auf .NET aufbaute. Er erinnert an die oben erwähnte Verbitterung des Windows-Teams. WinRT war eine native C++-Laufzeitumgebung, ein klarer Bruch mit WPF, WinForms und einem Jahrzehnt Entwicklerinvestitionen in .NET, so Snover.

Das Windows-Team entwickelte WinRT. Das .NET-Team warb weiterhin für WPF. Verschiedene Gebäude, verschiedene Vice Presidents, verschiedene Roadmaps , schreibt Snover (erinnert mich an meinen letzten Arbeitgeber bis 1993).

Windows 10 brachte 2015 dann die Universal Windows Platform (UWP) mit dem Versprechen: Einmal Anwendungen als App schreiben, und auf PC, Smartphone, Xbox und HoloLens ausführen. Problem: Windows Phone ist tot, Office, Visual Studio und die Windows-Shell nutzten UWP nicht. So 2021 gab es das Projekt Reunion / WinUI 3 mit dem Versuch, das Ganze irgendwie noch hinter einen Zaun zu kriegen. Project Reunion sei eine organisatorische Notlösung, die als technische Lösung getarnt war, schreibt Snover.

Snover fasst das Schlamassel bei Windows mit der Aussage eines Entwicklers aus dem Jahr 2024 zusammen: "Ich habe die ständigen Veränderungen bei Microsoft verfolgt: UAP, UWP, C++/CX, ersetzt durch C++/WinRT ohne Tool-Unterstützung, XAML Islands, XAML Direct, Project Reunion, der Neustart von WinAppSDK, der chaotische Wechsel zwischen WinUI 2.0 und 3.0 …" Und zieht das Fazit: Vierzehn Jahre. Vierzehn Kurswechsel.

Mein eigener Blick auf das Ganze

So als schlichteres Gemüt mit Null Ahnung, aber viel Meinung, habe ich das Ganze eher aus der Ferne beobachtet. Ich habe gestaunt, wie die "Fachkollegen" mit Begriffen wie Avalon, Metro, WPF etc. um sich warfen und das scheinbar nicht nur verstanden, sondern auch zitiersicher beherrscht. So als schlichtes Gemüt habe ich auf der Basta 2005 oder 2006 letztmalig so etwas "Ok, Du hast verstanden, wo die Genialität von WPF und XAML liegt, ist die Zukunft"-Gefühl aufblitzen sehen, mich dann aber aber aus der Entwicklung verabschiedet.

Meine Microsoft-Insights passierten früher und viel schnöder, denn ich war "Outsider", der von draußen auf den Zirkus blickte. Als ich 1993 als Schreiberling in die Selbständigkeit startete, gab es Windows 2.x und bald 3.x. Und dort gab es – aus meiner Sicht – den Versuch, dass Aussehen der Windows-Fenster, der Menüs und der GUI so zu vereinheitlichen, dass ein Anwender die gleiche Handhabung zwischen unterschiedlichen Anwendungen wiedererkennen konnte.

Dann kam 1995, und Microsoft brachte Windows 95 auf den Markt. Bei Microsoft Press USA erschien "Programming the Windows 95 user interface" von Nancy Cluts. Zu dieser Zeit gab es von Microsoft Press Deutschland einen Anruf, der in meinem Büro auflief: "Born, wir wollen den Cluts-Titel auf Deutsch übersetzen, übernehmen sie das?".  Die Übersetzung des Buches war für mich ein Augenöffner – da gab es ganz klare Vorgaben, was auf der Benutzeroberfläche von Windows für Elemente verwendet werden, wie diese auszusehen und anzuwenden wären und wie Menüs etc. zu gestalten seien.

Meine Erinnerung an dieses Buch: "Wow, da haben die bei Microsoft den Stein der Weisen gefunden, wenn die das durchhalten, rollen die den Markt gnadenlos auf". Dazu muss ich sagen, dass ich in dieser Zeit auch ein Buchmanuskript eines Autorenkollegen zu IBMs OS/2 (OS-Halbe) als Herausgeber betreute. Ich rief den Kollegen mitten in der Lektüre des Manuskripts an und fragte "was hast Du dir da zusammen geschrieben?", und der meinte nur "das ist O-Ton IBM, bei OS/2 ist das so".

Schwank am Rande, ist inzwischen "verjährt": Kurz nach der Übersetzung des Nancy Cluts-Titels kam den nächste Anruf aus München: "Born, wir wollen den neuen Petzold übersetzen, sind Sie dabei? Aber Sie sind Projektverantwortlicher, in sechs Wochen ist das Manuskript von 1.000 something Seiten fertig übersetzt bei uns." Ich habe mir einen halben Tag Bedenkzeit erbeten, zwei Anrufe getätigt und hatte ein Team von "drei Musketiere" zusammen, von denen jeder 300+ Seiten übersetzen sollte (gab da noch kein Deepl oder ChaptGPT, und Microsoft hat noch richtige Bücher gemacht).

Wurde mein Waterloo, denn am Ende des Tages habe ich den Petzold alleine übersetzen müssen – teilweise rund um die Uhr. Ja, ich habe die die 1.000+ Seiten abgerissen und die Termine gehalten. Der Petzold lag in deutscher Übersetzung zum Wunschtermin in den Buchhandlungen. Aber die Übersetzung war nicht wirklich richtig gut – mit mehr Zeit hätte ich die mir zugedachten 300 Seiten durchpflügen und in deutschem Kontext "ausliefern" können. So musste ich das englische Manuskript durchhecheln im Kopf übersetzen und den deutschen Text tippen, bis die Finger wund waren. Da bleibt dir keine Zeit für tiefergehende Überlegungen, was man besser machen kann. Ist so in etwa der Kontext, unter dem ich die Entwicklung von 1993 bis heute bei Windows verfolgt habe.

Es hätte mit Microsoft genial werden können. Die hatten gut vorgelegt, und 1998 gab es sogar ein Buch von mir zur Registrierung von Windows 1998 direkt in Englisch geschrieben und bei Microsoft Press USA erschienen. Teile wurden später in das offizielle "Microsoft Windows 98 Ressource-Kit" übernommen. Mein Registry-Titel zu Windows 98 muss palettenweise zu den Windows-Entwickler gekarrt worden sein, erzählte mir der US-Lektor seinerzeit. Es hätte steil gehen können. Hätte, hätte Fahrradkette …

Und damit kommen wir wieder mit Snover und dessen Insides weiter oben zusammen. So 2000 erlebte ich mit Microsoft Press USA mein Waterloo, als ich was zu Windows Script Host verfassen sollte. Es war die Zeit, als eine US-Kartell-Untersuchung eigentlich zur Zerschlagung Microsoft hätte führen sollen. Hintergrund war der Vorwurf, dass Microsoft seine Monopolstellung ausnutzt, um den internen Windows- und Office-Entwicklern einen Insider-Vorsprung bei der Produktentwicklung zu verschaffen und externe Entwickler auszubremsen.

Das führte zur berühmten "Chinese Wall", die intern bei Microsoft organisatorisch zwischen Geschäftsbereichen und Teams eingezogen wurde. Ich hatte in dieser Zeit alle 6 Wochen einen anderen Lektor als Ansprechpartner bei Microsoft Press USA, und die Projekte scheiterten (über 1.000 Seiten englisches Manuskript in den Sand gesetzt). Natürlich ging es auch bei den Windows Entwicklern ebenfalls drunter und drüber, was möglicherweise später auf die Longhorn-Entwicklung durchschlug.

Das 9/11-Ereignis 2001 und die Paranoia der US-Homeland-Security gab dann für mich den Ausschlag, alle Verbindungen meinerseits mit Microsoft Press USA zu kappen. Seit dieser Zeit habe ich als sehr weit außenstehender die Windows-Entwicklung für deutsche Verlage und Microsoft Press Deutschland begleitet. Windows 2000, Windows Millennium, Windows XP waren von der Benutzeroberfläche das, was ich aus dem Titel von Nancy Cluts kannte und schätzen gelernt hatte. Selbst Windows Vista (2007) und Windows 7 (2009) bauten auf dieser Welt auf.

Die Älteren unter den Blog-Lesern erinnerten sich aber noch an Windows Longhorn, Steve Ballmer und die Versprechen zu einem genialen neuen Windows-Betriebssystem, was dann nicht kam, und nach einem großen Reset als Windows Vista 2007 auf den Markt geworfen wurde. Zwei Jahre später schob Microsoft 2009 Windows 7 nach, was (neben Windows XP) in meinen Augen einen "nicht tot zu kriegen"-Status hatte.

Und dann kamen 2012 Window 8 und Metro, die Kacheloberfläche, die Metro-Apps und die Zeit, wo ich "angeleint auf dem Bürostuhl in meinem Büro arbeiten musste". Angeleint, um nicht der Versuchung zu erlegen, vor Verzweiflung aus dem Fenster zu springen, wenn ich mal wieder eine Windows 8-Beta-Version für irgend ein Buch auf dem Tisch bekam. Bei meinem Büro im 1. Stock wäre das mit etlichen Brüchen ausgegangen.

Ok, ist jetzt spitz formuliert, aber ich bin fast verrückt geworden. Unabhängig von der Kachelbedienung und der Touch-Oberfläche in Windows 8, die erkennbar für Desktop-Rechner nicht funktionierten konnte, erkannte ich noch etwas anderes: Microsoft hatte Jahrzehnte an GUI-Entwicklung über Bord geworden. Die Apps waren von der Bedienoberfläche das reinste Chaos. Jeder Entwickler schnitzte sein eigenes Zeug.

Ich habe adhoc keinen meiner damaligen Blog-Beiträge gefunden, wo ich über den Verlust einer klaren Bedien-Vision für Metro-Apps geklagt habe. Ich erinnere mich aber, dass da der Gedanke war, dass Microsoft "auf den Bauch fällt", weil Anwender sich mit den Metro-Apps nicht mehr zurecht finden. Jeder App-Entwickler bastelte sich seine eigene Bedienoberfläche zurecht. Nur native Windows-Anwendungen hatten noch das Look-and-Feel von früher – aber die sollten ja nach dem Willen Microsofts verschwinden. Apps, Apps, Apps, gekauft im Windows Store, war das Credo.

Zu dieser Zeit ist auch meine Begeisterung für Windows gekippt und es ist auch die Zeit, wo ich langsam aus dem Schreiben von Windows-Büchern ausgestiegen bin (weil der Kollaps absehbar war). Die Blog-Beiträge Neues zu Windows 8 (2012), Windows 8.1: (nicht nur) Entwickler sind angepisst (2013) und Windows 10 Apps: Können PWAs es reißen? (2018) lassen die damalige "Stimmung" durchblitzen. Ich habe damals schon vor gewarnt, was uns heute auf dem Füße fällt: Cloud-Fokussierung, gesperrte Online-Konten, Software as a Service als Bananaware, die beim Kunden reift und öfters mal umgestoßen wird. Tja, wie es bis heute weiter gegangen ist, weiß vermutlich jeder Leser selbst am besten.

Aus heutiger Sicht würde ich sagen, Microsoft hat "keine Erzählung mehr, die die Kundenerwartungen trifft". Ein WordStar, ein Multicalc, die später in Word, WordPerfect oder Lotos 1-2-3 mündeten, brachten den Leuten einen Vorteil. Das waren Killer-Anwendungen, die ihren Weg auch ohne großes Marketing machten. Bis so Windows XP, max. Windows 7 sehe ich noch irgendwie, dass Microsoft sein Windows unter der Haube als Betriebssystem weiter entwickelte. Aber bereits damals war schon zu viel "Eye Candy" im Vordergrund. Und das Wissen der Anwender zur Bedienung wurde ab Windows 8 mit jeder Version über den Haufen geworfen. Das konnte nicht gut gehen.

Wenn ich sehe, wie wenig das Startmenü von Windows 11 heute noch verwendet wird – und wie das früher unter Windows 2000 bis Windows 7 war, lässt sich die Fehlentwicklung erkennen Heute erklären mir die Leute, dass sie die Suche verwenden oder Verknüpfungen ablegen. Mache ich übrigens bei Windows 10 auch so – nur bei Linux Mint arbeite ich noch mit dem Startmenü. Stattdessen meint Microsoft nun mit Gimmicks wie AI den Benutzer abholen zu müssen und wirft Funktionen mit Windows auf den Markt, nach denen niemand gefragt hat. Eine absolute Fehlentwicklung in meinen Augen.

Ist aber nur meine "Außensicht", ohne die Insides von Snover. Spannend fand ich, die Inneneinsichten von Snover mit dem abzugleichen, was ich als Außenstehender so erlebt habe. Und da fiel beispielsweise die Geschichte mit der "Chinese Wall" mit zig Umorganisationen Microsofts ein. Dass wir deutschen Autoren und Übersetzer damals von der Nomenklaturgruppe in Redmond gefragt wurden, wie bestimmte GUI-Elemente oder Begriffe im deutschen Office oder Windows heißen sollten, ist eine Fußnote. Diese Welt gibt es nicht mehr – und die Nomenklaturgruppe ist längst aufgelöst.