Das große Microsoft GUI-Verwirrspiel

Wie eine Hinterhoffirma hat Microsoft über die Jahre unzählige Frameworks angefangen zu entwickeln, die sämtlich nach kürzester Zeit wieder aufgegeben, eingestellt und verworfen wurden. Fürchtet Microsoft die Konkurrenz der freien Entwickler? Viele Entwickler sagen heute: "Microsoft hat unser Vertrauen verspielt". Die Enttäuschung sitzt tief. Man hat den Eindruck, Microsoft möchte die Entwickler vergraulen.

Die Entwicklergemeinschaft macht inzwischen nur noch Witze über Microsoft: "Great News: All Bugs Will be Fixed In the Year 2041". Schlimmer als in einer Hinterhoffirma findet die Bug-Eliminierung in traumatisch langen Zeitabständen statt. Ist Microsoft in Wirklichkeit eine 1-Mann-Firma? Die Billionen- und  Milliarden-Einnahmen von Microsoft gingen wohl sämtlich in Epsteins Imperium unter.

Wer viel auf Github unterwegs ist, stellt fest: fast 70% oder mehr der veröffentlichten Source-Codes sind Commandline-Programme, wie in den Neunzigern mit Win95 und Win98 oder gar MSDos. Oder es sind erste Gehversuche im Programmieren, die für absolut niemand von Interesse sind. Projekte, die auf ernsthaften Entwicklersites wie Codeproject (das alte Codeproject, nicht die heutige untaugliche Kopie) oder meiner Site schon vom Konzept her nicht veröffentlicht wurden. Und für viele der verbleibenden Sourcecode-Projekte gibt es von Microsoft keine Bibliotheks-Unterstützung mehr, auf Microsoft-Seiten erhält der Nutzer nur noch: "Das Zielframework "xxxxx" wird nicht mehr unterstützt und erhält in Zukunft keine Sicherheitsupdates mehr. Weitere Informationen zur Supportrichtlinie finden Sie unter https://aka.ms/dotnet-core-support". Sicherheitswarnungen und ausnutzbare Sicherheitslücken tun ein übriges. Man fragt sich: Warum liegt dieser alte Schrott dann noch auf Github herum? Wenn dies doch niemand nutzen kann, weil die erforderlichen Bibliotheken nicht mehr existieren oder vor Sicherheitslücken nur so strotzen? Um Content vorzutäuschen, der in Wirklichkeit nicht vorhanden ist?

Die ständigen Änderungen und Umbenennungen haben viele Entwickler verwirrt und genervt. Natürlich ist die Unbeständigkeit Microsofts nur einer der Faktoren. Entwickler fragen: "Selbst Microsoft nutzt es (WinUI) nicht, wie soll die Community es dann verwenden?"  Ein Entwickler kommentierte: "Ich verwende WinRT seit Windows 8. Seitdem musste ich immer mit den Veränderungen von Microsoft mithalten: zuerst UAP, dann UWP, dann wurde C++/CX durch C++/WinRT ersetzt, das keine Werkzeugunterstützung hat, dann kamen XAML Islands, XAML Direct, und dann das angekündigte Project Reunion, die Neustarts von WinAppSDK, die verwirrende Umstellung zwischen WinUI 2.0 und 3.0, und die immer wieder wechselnden Aussagen über .NET Native..."

Microsoft verhindert gezielt Software-Re-use, indem man Entwickler zwingt, schon längst fertig entwickelte und leistungsoptimierte, als auch im Aussehen optimierte Dialoge etc wegen Compiler-Defiziten oder Framework-Änderungen immer wieder neu zu erstellen. Dies ist besonders ärgerlich, da sich an den eigentlichen Inhalten absolut nichts geändert hat, man immer noch mit ineffizienten steinalten vorgestrigen Lösungen (als nur ein Beispiel die jetzt ~30 jährige Katastrophe richedit und Bilder) arbeiten muss, die schon lange hätten überarbeitet und mit neuer Technik ersetzt werden müssen. Sisyphos Strafe einen Felsblock auf ewig einen Berg hinaufzuwälzen, der, fast am Gipfel, jedes Mal wieder ins Tal rollt, ist eine regelrecht barmherzige Bestrafung im Vergleich damit.

 Die Verwirrung der vielen nicht weiter verfolgten Gui-Alternativen schlägt sich jedenfalls auf Github deutlich nieder und viele Entwickler wenden sich mittlerweile anderen Alternativen zu.

Microsoft Foundation Classes (MFC)

Microsoft Foundation Classes oder MFC war eine Bibliothek, die einen objektorientierten Wrapper für die Win32-API bereitstellte. Es war eine GUI-Bibliothek die durch die Internet-Gemeinde eine erhebliche Entwicklung erfuhr. GUI-Anwendungen und  Verwalten der Ressourcen wurden durch diese Klassenbibliothek erheblich erweitert und vereinfacht und endlich auf C++-Niveau gehoben.

MFC wurde  1992 mit der Version 7 des C / C ++ - Compilers von Microsoft eingeführt. Microsoft setzte sich verspätet damit auf die Entwicklung von C ++  auf. Spätere Versionen von Visual Studio hatten erheblich verbesserte Versionen von MFC im Gepäck bis Visual Studio 2015. Dann verschwand diese 'Foundation' sang und klanglos in der Versenkung. Mit dieser Aufgabe der MFC wurde viele Arbeit vieler Menschen sang und klanglos in die Tonne gekippt (Bezeichnenderweise zu einer Zeit, als freie Entwickler MFC sehr attraktive Designs mit abgerundeten Ecken[*] und Farbverläufen etc. verpasst hatten, die Microsoft-Software als XP-Steinzeit-Software aussehen ließen und auch die heutigen Frameworks als kalter Kaffee in den Schatten stellen.).

Ursprünglich war die Bibliothek als Application Framework Extensions ( AFX) geplant. Die Marketingabteilung änderte allerdings den Namen in MFC, der Code aber blieb. Viele Header verwiesen immer noch auf "Afx" anstelle auf "Mfc", so etwa der vorkompilierte Standard-Header, der automatisch von Visual Studio generierte StdAfx-Header.

Dennoch war MFC mit 23 Jahren ('92-'15) Lebenszeit eines der am längsten unterstützten Frameworks. 

*) Windows 11 introduces a modern aesthetic with rounded corners that enhance its visual appeal and user experience. These rounded corners create a softer, more inviting interface, aligning with current design trends and improving overall aesthetics

ATL

 ATL ist eine mittlerweile ziemlich alte Bibliothek, die win32 api-Funktionen umschließt. Weder MFC noch ATL werden für neue Programme empfohlen. Windows Forms und  .NET-Framework, oder häufiger CLR/C++ genannt, folgte diesen Dinosauriern.

ATL war eine weitere Leichtbaubibliothek, die einfach Möglichkeiten zur Erstellung von COM-Komponenten auf eine Weise zur Verfügung stellte, die die Low-Level-Details des Aufbaus einer COM-Schnittstelle abstrahiert. Es machte COM einfacher zu verwenden.

Windows Forms

Windows Forms gibt es seit 2002 und das Erscheinungsbild ist dem  entsprechend. Man fühlt sich in Zeiten von Windows XP zurückversetzt. Winforms war gegenüber MFC ein Schritt zurück in die Computer-Steinzeit von Win-XP. Die digitale Steinzeit lacht aus jedem damit programmierten Programm den Nutzer an.

Zwar hätte  die Entwickler-Community auch Winforms schon längst eíne modernere Erscheinungsform geben können, die Erfahrung mit MFC hat dies jedoch bis heute verhindert. Freie Entwickler sehen nicht ein, dass sie ohne jede Bezahlung die Arbeit für eine $ 4 Billionen-Firma leisten sollen, die "sich nicht darum kümmert, Entwickler-Teams angemessen zu besetzen." und  "kostenlose Community-Fixes für ein Unternehmen im Wert von $ 4 Billionen (zu erstellen), das sich (noch) nicht (einmal) darum kümmert, die (Bugfix-)Teams angemessen zu besetzen."

Die Kurzlebigkeit der Microsoft-Frameworks erkennt man alleine schon daran, dass Microsoft selbst alte Winforms-SDKs nicht mehr anbietet (man muss alte Versionen mit Krücken wie netfx4sdk's zum Laufen überreden)

Auch kann man auf https://learn.microsoft.com/en-us/visualstudio/releases/2022/port-migrate-and-upgrade-visual-studio-projects#pre-msbuild-projects lesen:

"Pre-MSBuild .NET projects (that is, .NET projects created with versions of Visual Studio that predate MSBuild) are convertible only when you upgrade them with a version of Visual Studio up to Visual Studio version 17.12. The projects won't be convertible when using Visual Studio version 17.13 or later. Convert any such projects you might still need now with Visual Studio 17.12 and store the converted results. The other project formats will continue to be convertible, and earlier Visual Studio versions will continue to convert even pre-MSBuild project files going forward. However, it is still recommended to store the converted results, as in future versions of Visual Studio or future updates of previous releases of Visual Studio (including 2017 and 2019), additional restrictions of upgrade functionality might apply".

oder dies:

"Das Zielframework "net6.0-windows" wird nicht mehr unterstützt und erhält in Zukunft keine Sicherheitsupdates mehr. Weitere Informationen zur Supportrichtlinie finden Sie unter "https://aka.ms/dotnet-core-support"".

Warum Microsoft diesen alten Schrott auf Github anbietet ist ein Rätsel. Schließlich sind diese Projekte für absolut niemand mehr von Interesse oder nutzbar, wenn die dazugehörigen Libraries von Microsoft nicht mehr angeboten werden. Falls hier Fragen sind: Mit einem Kaufpreis von 7,5 Milliarden US-Dollar übernahm Microsoft im Jahr 2018 die Entwicklerplattform GitHub. Und falls Microsoft alle diese nicht mehr unterstützten Zips löscht, dürfte der Content auf Github nicht mehr weit von Null entfernt sein.

Silverlight

Wer erinnert sich noch an das Silverlight-Desaster? Einst als Flash-Killer beworben wurde Silverlight später sang- und klanglos eingestellt.

WPF

Die Windows Presentation Foundation betrat 2006 die Bühne und schien viel zu versprechen: Eine hardwarebeschleunigte Oberfläche, XAML, Datenbindung, Styles. Für manche Windows-Anwendungen könnte WPF auch heute noch aktuell sein, allerdings nur proprietär für Windows, die vielen anderen Systeme heute bleiben außen vor.

BYOD ist für Microsoft ein Fremdwort. Und WPF wird nicht mehr entwickelt. Auch hier also nur Sackgasse. Aber WPF läuft Cross Platform selbst auf Linux dank Avalonia XPF. Aber WPF wird nicht mehr entwickelt......

UWP

Sollte die App-Revolution auf Windows bringen – dümpelt als Nischenlösung vor sich hin.

Noch November '24 war auf der Visualstudio-Magazine-Seite zu lesen: "Microsoft is previewing UWP (Universal Windows Platform) support for .NET 9, providing a path for existing UWP developers to modernize their apps with the latest .NET and Native AOT. That's being done as the company urges devs to switch to Windows App SDK and WinUI 3 because UWP is no longer under active development." Siehe Win UI 3.

WinUI 3

Die Windows UI Library (WinUI) ist das native UI-Framework von Windows 10 und Windows 11. Wer mühsam gelernt hat, wie  WinUI und seine UI-Beschreibungssprache XAML verwendet wird, um moderne Windows-Desktopanwendungen mit .NET und C# zu erstellen, steht auf dem Abstellgleis.

Eine Zeitung schreibt: "Ein Projekt, das schon vor vielen Jahren "Open Source" gemacht wurde, kündigt nun plötzlich "echte Open-Source-Entwicklung" an? Was für ein Scherz spielt Microsoft hier?"

2024 konnte man dann auf Github lesen: ""WinUI 3 ist tot. Wann können wir die Bekanntgabe dafür  erwarten?" Der Thread fand inzwischen über 580 Kommentare und wurde zum Sammelbecken für die Unzufriedenheit der Community über die stagnierende Entwicklung von WinUI 3 (mittlerweile ist die Sperre wieder aufgehoben) . Im Thread kann man jetzt wieder solche Kommentare lesen: "kostenlose Community-Fixes für ein Unternehmen im Wert von $ 4 Billionen, das sich nicht darum kümmert, die Teams angemessen zu besetzen."   Ein Entwickler kommentierte: "Berühren Sie WinUI 3.0 nicht. Die aktuelle Erfahrung ist noch schrecklicher, sogar noch schlechter als die mit UWP, und UWP war schon nicht viel besser als WPF."

MAUI

Dann sollte .NET MAUI die Erlösung bringen. Endlich ein Framework für viele Plattformen.  Windows, Mac, Android, iOS sollte unterstützt werden. Aber der große Markt für Linux Fehlanzeige. Die Realität war ernüchternd.  MAUI wird halbherzig entwickelt, ist nach Jahren im Markt  immer noch mit Kinderkrankheiten behaftet. Probleme mit Deployment, Performance, kaum Dokumentation. MAUI war als der große Hoffnungsträger gestartet. Heute stellt sich heraus, dass er alles andere als ein Hoffnungsträger darstellt. Hier nur 2 Kommentare: "MAUI shipped as a horrifically buggy mess " ("MAUI wurde als schrecklich defektes Durcheinander ausgeliefert") und "I would not touch MAUI with a 10-meter pole.("Ich würde Maui nicht mit einer 10-m Stange anfassen")"

8 Bibliotheken in 32 Jahren

8 Bibliotheken in 32 Jahren ergibt eine Lebenszeit pro Bibliothek von 4 Jahren. Gar nicht erwähnt WTL,  Xamarin, WinJS, WinRT, UWP, VCL, OWL.... (Eigentlich sogar noch weniger Jahre, da MFC 1992 unausgereift war und erst in jahrelanger Entwicklung durch die Entwicklergemeinde nach 2000 zu einem brauchbaren Produkt wurde).  Man muss wohl niemand erklären, welch extrem kurze Zeitspanne 4 Jahre darstellen. In Wirklichkeit 3 Jahre, wenn man vom Jahr 2004 als dem Fertigstellungsjahr für MFC ausgeht. (Komplexe Programme benötigen weit mehr als 4 Jahre zu ihrer Entwicklung, man wird dann mitten in der Entwicklung von Microsoft überrascht: "Das Zielframework "xxxxx" wird nicht mehr unterstützt und erhält in Zukunft keine Sicherheitsupdates mehr. Weitere Informationen zur Supportrichtlinie finden Sie unter https://aka.ms/dotnet-core-support"). Ohne wirkliche Weiterentwicklung. Manche mittlerweile 32 Jahre alte MFC-Programme haben ein moderneres Erscheinungsbild als etwa Winforms-Programme. Hinzu kommt wie gesagt das Revival der Command-line Programme der Computer-Steinzeit. Ist das die Zukunft der Microsoft-Windows-Welt?

Gar nicht zu erwähnen die vielen Bugs im Microsoft Compiler bis heute. Und dass modernere Windows Versionen versuchen Entwickler zu gängeln und zu kontrollieren... (die vielen anderen Desaster gar nicht erwähnt: Merkwürdigkeiten der Desktopskalierung, nicht defragmentierbarer Partitionen, Systembackup-Fehlern aller Art, Probleme mit dem automatischen Scrollen, dass der Compiler selbst wenn man ihn auf einem anderen Laufwerk installiert hat, den größten Teil der Bibliotheken unbedingt auf c:  speichern will, dass Desktops bis heute in Win11 keine brauchbare Funktion aufweisen. Vielleicht erklärt mal jemand Microsoft, wie so etwas aussehen müsste etc.....)[*].

Die Entwickler sind stolz darauf ihr Geheimwissen auf Stackoverflow etc weiterzugeben, wie man trotz der vielen Bugs und defective by design-Problemen weiterkommt.

Gar nicht zu reden von den bis heute vollkommen unbrauchbaren Hilfedateien im Netz in nicht-englischen Sprachen. Sie strotzen nur so vor den Inhalt verfälschenden  Fehlern, die all die Propagandadarstellungen in der Presse und im Netz zu AI/KI Lügen strafen.

Defective by Design oder "fehlerhaft auf Grund des Entwurfs"  ist eine Kampagne der Free Software Foundation gegen das Digital Restrictions Management (DRM).  Der offizielle Begriff Digital Rights Management (engl. für ‚Digitale Rechteverwaltung‘) ist danach eine Irreführung der Verbraucher und insbesondere aber der Entwickler, da er suggeriert, die großen Firmen würden Rechte sichern, obwohl dies für Entwickler und die Verbraucher nur Einschränkungen bedeutet. In US-Art versucht man dies als abgehakt, als kalter Kaffee hinzustellen. Es ist nicht abgehakt, es geht mit anderen Mitteln und Methoden weiter..

Defective by Design geht viel weiter. Defective by Design gilt für viele Produkte des Silicon valley, insbesondere jedoch für Microsoft Produkte, angefangen beim Vorzeigeprodukt Compiler, der - obwohl explizit auf einem anderen Laufwerk installiert, unbedingt darauf besteht Bibliotheken gewaltigen Umfangs auf C: unterzubringen[**], der in größeren Projekten mit seiner starren Vorgabe, wie Projekte zu verwirklichen sind, mehr behindert als nützt (folgt man dem nicht, hagelt es  Bugs, weil alle diese durchaus vernünftigen und gangbaren Wege nicht ausgeführt sind), über gezielt verhindertes Software-Re-use, indem man Entwickler zwingt, schon längst fertig entwickelte und optimierte Dialoge etc wegen Compiler-Defiziten oder Framework-Änderungen immer wieder neu zu erstellen, über Microsoft Windows mit seinen virtuellen Desktops, über die vielen angefangenen und wieder verworfenen Bibliotheken, über die (absichtliche ? ) Irreführung und Behinderung von Software-Entwicklern, Ausschluss unbequemer, kritischer Benutzer etwa in Github, und über .. (man könnte fast den Eindruck gewinnen, dass größere Projekte absichtlich verhindert werden sollen, damit eigene Produkte nicht negativ dagegen abfallen. Man versucht sich immer wieder als Wahrer von Rechten zu verkaufen, wo es in Wirklichkeit nur um Behinderung und Aneignung der Werke freier Entwickler geht.). Überhaupt ist alles so wunderschön anachronistisch und verstaubt im Microsoft-Imperium. Wie gesagt, sind die Milliarden wohl alle in Epsteins Kassen gelandet, für Entwicklung war da kein Geld mehr übrig. Aber ich sag nicht mehr, denn jede einzelne meiner Aussagen wären für ein fähiges Management Millionen wert. Aber das Microsoft-Management schläft wohl so tief, dass auch in dieser Hinsicht keine Gefahr besteht. Entwickler wenden sich von Microsoft ab, weil die GUI-Entwicklung: einen "Mangel an Transparenz, Mangel an Fortschritt, Mangel an Verantwortlichkeit und Mangel an einer klaren Richtung" hat, wie ein Entwickler schreibt.

Defective by design waren über Jahrzehnte Intel Prozessoren der 86, 186, 286 Serien bis der Unmut der Verbraucher aber natürlich insbesondere der Software-Entwickler über die 'irren' Prozessoren (an der Reaktion meiner Leser kann ich sehen, dass heute vergessen ist, was an diesen Prozessoren so 'irre' war: der Adressraum spiegelte sich unendlich oft. Und damals programmierte man mangels Compiler noch viel in Assembler, was angeblich einige Programmierer ins Irrenhaus trieb. Jeder Versuch dies hier kurz zu erklären, muss scheitern. Wenn Sie dieses 'verrückte' Prinzip verstehen wollen, müssen Sie sich schon die Arbeit machen, tiefer einzusteigen. Der damalige Softwarepapst Tannenbaum beschrieb das Prinzip noch 1992 als "brain-dead", "brain-dead nature of the Intel CPUs", "man konnte auch "brain-damaged" dazu lesen.) unüberhörbar wurde (selbst das Mooresche Gesetz war in dieser Hinsicht eine reine Propagandalüge). Und es sind ganz klar die unverständigen  Firmenleitungen, die solche Fehlentwicklungen zu verantworten haben. Auch von dieser Seite sind also die heutigen Angriffe der Silicon valley Wortführer auf Demokratie und Gesellschaft überaus kritisch zu sehen.

Defective by Design wurde im Mai 2006 gegründet. Bei den Protesten verteilten Mitglieder der Free Software Foundation damals Flugblätter, die Microsoft-Produkte als „defective by design“ bezeichneten, da sie DRM enthielten.

Ganz zu schweigen vom AI/KI Hype und Schrott. Das Internet wird mit den heutigen absolut unbrauchbaren AI/KI-Inhalten geflutet. Als „AI Slop“ werden Texte, Bilder und Videos bezeichnet, die automatisch erzeugt wurden, absolut keinen Nutzen bieten und nur dazu dienen Pseudo-Content und damit  Klicks und Werbeeinnahmen zu erzeugen. Entwicklern wird eingetrichtert, dass sie sich an diesen unausgegorenen Inhalten beteiligen müssen, ob dies etwas zu ihrem Projekt beiträgt oder nicht. Das Internet verkommt zur AI/KI-Hölle: ein selbstverstärkender Kreislauf in dem KI von KI lernt. Internet-Nutzer  werden diesem Schwachsinn ausgesetzt und (bayrische) Politiker glauben den Mist und investieren Millionen an Steuergeldern in KI-Farmen (mit entsprechender Gewinnbeteiligung ?). Der von interessierten Kreisen künstlich hochgepushte AI-Hype wird sich relativ schnell totlaufen, wenn die Menschen bemerken, welcher Schwachsinn Ihnen da präsentiert wird.

Die heutigen Entwickler sind wohl so angepasst und Industrie-hörig, dass von ihnen keine Kritik mehr kommt. Im übrigen sorgen auch die derzeitigen Suchmaschinen dafür, dass kritische Kommentare nicht mehr aufscheinen. Orwells 1984 lässt grüßen. Sie finden diese Seite weder in Google, noch in bing, noch in duckduckgo (selbstverständlich lässt man kurz einmal die Zensur fallen, wenn zu viele nach dieser Site suchen.). Die totale faschistoide Kontrolle ist wenn nicht schon gegeben, dann nur noch einen Steinwurf entfernt.

Die Silicon-valley-Mafia macht sich offensichtlich lustig über die dummen Entwickler, die sich alles gefallen lassen und gleichzeitig auch noch ihre Götter anbeten (siehe Apple).

*) die vielen Fehler in Visual Studio Community 2026 gar nicht erwähnt, zwar könnte man auch solche Produkte wenigstens von den größten Fehlern bereinigt auf den Markt bringen (unliebsame Entwickler verhöhnt man mit Spezialversionen, in denen sämtliche Standard-Einstellungen gelöscht sind und die dann diese nachtragen müssen)...

**) natürlich weiß auch ich, warum der Compiler unbedingt auf c: will, aber ich habe natürlich meine Gründe ihn auf einem anderen Laufwerk zu installieren...