Nach Jahrzehnten will Microsoft endlich nachrüsten – doch das geht gewaltig schief: Nutzer bekommen kaputte Software und schwere Vorwürfe werden gegen den Konzern erhoben. Er hat den Paketmanager geklaut, dazu den Entwickler mit falschen Versprechungen zur kostenlosen Zusammenarbeit gelockt. Alles was du zu WinGet aka NuGet wissen solltest, im folgenden Beitrag!
Jahrzehnte lang waren Paketmanager eine Domäne der GNU/Linux-Distributionen: Dort bekam man Software spielend leicht aus offiziellen Quellen. Ein Grund, warum es Viren & co dort schwer haben. Windows-Nutzer konnten ihre Software lediglich über ausführbare Exe-Dateien von Hand beziehen, die sie (hoffentlich von der richtigen) Webseite herunterluden. Oft fallen sie auf Fälschungen herein, bis heute. Über 20 Jahre sollte es dauern, bis Microsoft dieses Konzept ebenfalls einführt: Seit 2020 ist WinGet der offizielle Paketmanager von Windows. Zumindest, wenn er funktioniert. Selbst das ist keineswegs selbstverständlich, wie Microsoft eindrucksvoll bewiesen hat.
Microsoft schrottet WinGet – repariert es selbst!
Entscheidend für die Verbreitung von WinGet ist Microsofts Entscheidung, den Paketmanager automatisch in Windows zu installieren (ab Windows 11 23H2). Das war bereits in der Vergangenheit Teil einer erfolgreichen Strategie, um einen sehr hohen Marktanteil bei Anwendersoftware wie z.B. dem Internet Explorer zu erreichen. Allerdings schafft es der Konzern nicht, eine aktuelle Version auszuliefern. Auf einem frisch installierten Windows 11 in der aktuellen 23H2 Version (Dezember 2023) war selbst nach dem Einspielen der Updates immer noch V1.2 vorhanden. Das ist ungünstig, wenn der Konzern die Download-Server für die älteren Versionen abschaltet.1
Besonders peinlich: WinGet gibt nicht mal einen Fehler aus, der über das Problem informiert – sondern färbt lediglich die Konsole blau. Eben so unprofessionell ist Microsofts Umgang damit. Seit mindestens dem 10.12.2023 ist dem Konzern das Problem durch Bugtickets bekannt. Das Unternehmen hätte längst eine aktualisierte Version über Windows Update nachreichen können – im besten Falle einige Zeit vor Abschaltung der CDN-Server. Mehr als 4 Monate später, ist ein frisch installiertes Windows 11 23H2 mit allen Updates immer noch genau so kaputt:
Microsoft scheint es nicht für nötig zu halten, den Nutzern funktionierende Software zu liefern – offensichtlich kann man sich derartiges Chaos als Marktführer bequem leisten. Trotz Vorinstallation müssen Windows-Nutzer daher Microsofts Fehler selbst ausbügeln, um die Software nutzen zu können: Erst nachdem das Paket von der GitHub-Seite heruntergeladen und mit Add-AppxPackage händisch installiert wurde, kann der vermeintlich integrierte Paketmanager endlich ohne verwirrende Farbsprache genutzt werden.2 Funktionell ist das sehr schade. Unzählige GNU/Linux-Distributionen schaffen es seit Jahrzehnten, dem Nutzer einen funktionierenden Paketmanager mitzuliefern. Microsoft macht ihn selbst kaputt und ist offensichtlich überfordert, das selbst verschuldete Problem in den Griff zu kriegen.
Über 5700 Pakete
Hat man diesen Workaround angewendet, kann der Paketmanager auf der Kommandozeile mit dem Befehl winget verwendet werden. Eine offizielle Web-Übersicht aller Pakete fehlt, wie man es von den Paketsystemen vieler GNU/Linux-Distributionen her kennt, etwa Debian.3 Wer außerhalb der Microsoft-Dokumentation recherchiert, findet zumindest inoffizielle Oberflächen wie beispielsweise wininstall.4 Sie stammt von einem Unternehmen aus Wien, Österreich.5 Es bietet Beratungsleistungen im Software-Bereich an.6 Mit ihrem Dienst kann man eine eigene Paketquelle für WinGet betreiben. Die Software ist quelloffen, allerdings werden Sicherheitsupdates satte 6 Monate verzögert veröffentlicht.7
Demnach existieren derzeit über 5.700 Pakete. Verglichen mit den großen GNU/Linux-Distributionen ist das ziemlich bescheiden: Alleine in Debian 12 Bookworm sind fast doppelt so viele (über 11.000) neu hinzugekommen, sodass dort insgesamt 64.000 Pakete zur Verfügung stehen – über 11x mehr.8 Während WinGet also noch vergleichsweise klein ist, kann winstall mit „Packs“ punkten. Das soll eine Kategorisierung nach z.B. Entwicklung, Unterhaltung und weiteren Kriterien darstellen – oder schlicht zeigen, welche Software man verwendet. Allerdings sind immer wieder Füllinhalte in Titel/Untertitel zu sehen, wie z.B. qqqq.
Außerdem ist die Funktion generell kaputt: Ich habe mehrere Packs versucht aufzurufen und erhalte auf jedem folgende Fehlermeldung. Alternativ zu Firefox wurde auch Chromium getestet. Während der Erstellung zu diesem Beitrag sind zig Wochen vergangen: Zum ersten Mal bemerkte ich das Problem Ende Februar. Nun haben wir Mitte April und die Packs können immer noch nicht geladen werden – Schade, da die Idee grundsätzlich nützlich klingt und eine vergleichbare Funktion bei APT & co. oft fehlt.
So funktioniert WinGet in der Praxis
Interessant ist, dass Microsofts Store als Quelle ebenfalls verfügbar ist. Beim ersten Ausführen wird daher die Bestätigung deren Nutzungsbedingungen verlangt. Neue Pakete installiert man mit winget install <id>, wobei <id> einem eindeutigen Paketpfad entspricht. Dieser setzt sich meist aus Organisation/Hersteller/Entwickler und Name der Software zusammen, ähnlich wie Namensräume in .NET. Beim Texteditor Visual Studio Code wird dies beispielsweise deutlich: Dessen ID lautet Microsoft.VisualStudioCode. Das mag vereinzelt Klarheit schaffen, bringt teilweise jedoch gar nichts. Bei ShareX beispielsweise ist beides identisch: ShareX.ShareX.
In jedem Falle hat man dadurch mehr Tipparbeit. Pakete für Visual Studio Code werden in GNU/Linux-Distributionen deutlich kürzer als vscode oder gar nur code benannt. Bei NuGet muss daher öfter nach der korrekten ID gesucht werden. Immerhin funktioniert das auch auf der Kommandozeile mit winget search – oder eben über die inoffiziellen Weboberflächen. Wer WinGet nicht als Administrator ausführt, bekommt anschließend das von Windows bekannte Popup-Fenster der Benutzerkontensteuerung zu sehen.
Wie man am Beispiel von ShareX sehen kann, lädt WinGet die Installationsdateien direkt vom Anbieter der Software – in diesem Falle die Releases im GitHub-Repository. Damit unterscheidet es sich von den Paketsystemen der großen GNU/Linux-Distributionen, welche die Software paketieren und über eigene Server verteilen. Da die Pakete zudem ohnehin nicht von Microsoft selbst gepflegt werden, sondern durch die Community, ist WinGet somit eher mit dem Arch User Repository (AUR) vergleichbar.
Zentrales Aktualisieren
Einer der großen Vorteile von systemweiten Paketsystemen ist die Möglichkeit, sämtliche oder zumindest den Großteil der Anwendungen darüber aktuell halten zu können. Die manuelle Installation unter Windows führt traditionell zu einem Wildwuchs: Manche Programme wie z.B. Mozilla Firefox oder auch viele Chromium-Browser bringen eine Software mit, welche regelmäßig nach Aktualisierungen sucht und diese installiert. Andere prüfen dies zumindest und weisen den Nutzer darauf hin, Updates selbst einzuspielen. Dieser hat durch das händische Installieren hier bereits mehr Arbeit. Zudem kümmern sich manche Programme gar nicht darum.
WinGet hat sich bei GNU/Linux inspiriert. Folgender Befehl zeigt eine Liste aller veralteten Pakete:
winget upgradeDie Liste stellt übersichtlich dar, welche Version wir aktuell auf dem lokalen System installiert haben, dazu die aktuellste verfügbare sowie aus welcher Quelle diese stammt. Das finde ich eine gelungene Darstellung, bei der WinGet erstmals einen Mehrwert gegenüber anderen GNU/Linux-Paketmanagern aufzeigt.
Der Befehl spielt jedoch noch keine Aktualisierungen ein, sondern zeigt diese lediglich an. Zum Installieren kann entweder als Parameter die Id des Programms übergeben werden. Oder man spielt sämtliche Updates mit winget upgrade --all ein.
Weitere nützliche Befehle
Wie anfangs erwähnt, kann man die Pakete durchsuchen (vergleichbar mit apt-cache search <name>) und sich damit in einigen Fällen den Weg zum den Web-Oberflächen sparen. Dies ist der von MS offiziell unterstützte Weg, um Pakete zu finden:
Wer Windows neu installieren möchte/muss, oder aus anderen Gründen die Pakete auf einem anderen System haben möchte, kann diese in eine JSON-Datei exportieren und mit winget import auf dem neuen System importieren.
winget export -o winget-pakete.jsonSpannend ist, dass hierbei eine ganze Reihe an Anwendungen auftauchen, die ich nie installiert habe. Auf einem frisch aufgesetzten Windows 11 zeigt winget list satte 70(!) Pakete an, von denen ich lediglich zwei ausdrücklich installiert habe. Viele davon besitzen keine Quellenangabe. Es scheint, als ob Microsoft WinGet zur Integration von eigener Software ebenfalls verwendet – darunter u.a. Taschenrechner und MS Teams.
Alles nur geklaut? Die dunkle Seite von WinGet
Microsofts Idee ist keineswegs neu: In der Community haben verschiedene Projekte bereits vor Jahren versucht, einen Paketmanager ähnlich zum GNU/Linux-Ökosystem auch für Windows zu etablieren. Ninite war einer der Ersten. Es folgten 2011 Chocolatey, Scoop, AppGet und weitere kleinere. Sie alle hatten den Nachteil, dass der Nutzer sie händisch installieren musste, während GNU/Linux-Distributionen mit ihrer Paketverwaltung ausgeliefert werden. Das wollte Microsoft wohl ändern und hat dabei AppGet zerstört.9
Sein Entwickler Keivan Beigi berichtete, er wurde 2019 von Microsoft kontaktiert. Bei mehreren Treffen hat der Konzern ihm die Übernahme seines Paketmanagers in Aussicht gestellt – inklusive Anstellung bei Microsoft, in deren Rahmen er Vollzeit an der Weiterentwicklung von AppGet arbeiten könne. Der Einstellungsprozess würde längere Zeit dauern, habe ihn das Unternehmen vertröstet. Beigi wunderte sich daher wohl nicht darüber, 6 Monate nichts von Microsoft zu hören. Doch dann kam plötzlich eine E-Mail: Darin entschuldigt sich der Mitarbeiter, ihm doch keine Stelle anbieten zu können. Außerdem werde man am Vormittag des Folgetages die erste Vorschauversion von WinGet veröffentlichen – Microsofts offiziellem Paketmanager.
Keivan Beigi war schockiert: WinGet besaß große Ähnlichkeit zu AppGet, manch einer würde es als Kopie bezeichnen. In den zahlreichen Gesprächen mit Microsoft wurde auch über technische Fragen diskutiert – unter anderem, wie AppGet für alle Windows-Nutzer skaliert und in die Infrastruktur des Konzerns integriert werden kann. Rückwirkend drängt sich der starke Verdacht auf, dass Microsofts Jobangebot nur ein Vorwand war, damit Beigi dabei hilft, seine eigene Software zu kopieren. Als Dank bekam er nicht nur keine gut bezahlte Stelle. Microsoft erwähnte AppGet nicht einmal, obwohl zumindest große Teile des Konzepts übernommen wurden. Diesen Teil ärgerte den Entwickler am Meisten. Nachdem der Konzern seine Arbeit entführt hat, wie er selbst sagte, sei das Projekt obsolet – er habe keine Chance gegen einen Klon von Microsoft und stellt AppGet daher ein.
Dieses Verhalten wurde in der Community stark kritisiert. Derart stark, dass Microsoft-Mitarbeiter Andrew Clinick sich einige Zeit später zu einer Erklärung veranlasst sah. In einem Blogbeitrag bestätigter Andrew Clinick die Treffen und Gespräche mit Keivan Beigi, seine Rückmeldungen seien in WinGet eingeflossen.10 Microsoft gibt auch zu, eine Reihe an Funktionen von AppGet übernommen zu haben. Man sehe ein, dass Keivan Beigi nicht für seine Arbeit gewürdigt wurde und bedauere die Entfremdung von der Community. Verschwiegen wird allerdings die von Microsoft in Aussicht gestellte Übernahme zusammen mit dem Jobangebot.11
Fazit: Mit dunklen Methoden aus den 90ern will Microsoft nachziehen
Diese Frage kann man sich zumindest in einzelnen Bereichen stellen. Insbesondere wenn man einen Blick in die letzten Jahre wirft, ist ein Trend erkennbar: Windows-Nutzer müssen Jahre oder teils Jahrzehnte auf Funktionen verzichten, die unter GNU/Linux längst zum Standard gehören. Microsoft scheint nach langem Winterschlaf etwas dagegen tun zu wollen, dass unter Entwicklern beispielsweise fast genau so viele Nutzer ein auf Linux basiertes Betriebssystem nutzen.12
Zwar ist die Softwareauswahl vergleichsweise klein und auch die Umsetzung an einigen Stellen recht holprig. Insgesamt scheint der Konzern jedoch erkannt zu haben, dass Windows mit der ehemaligen Boykott-Einstellung zu quelloffener Software eher verliert als gewinnt. Insbesondere, wenn es nicht mal annähernd gleichwertige Werkzeuge anbieten kann, wie die Konkurrenz. Mit WinGet hat Windows seinen Mischling aus APT & AUR bekommen, die relativ gut funktioniert, wenn man Microsofts Mängel selbst beseitigt.
Wie Microsoft jedoch den Entwickler eines freien Paketmanagers aus der Community offensichtlich ausgenutzt hat, um dessen Konzepte zu übernehmen und eine Übernahme in Aussicht stellt, die Monate später mit einem Satz ohne Angabe von Gründen zurückgezogen wird, lässt an der angeblichen Liebe des Konzerns zu quelloffener Software stark zweifeln. Derartige Methoden erinnern an das Microsoft aus den 90ern und 00er Jahren unter Steve Ballmer, als jeder schmutzige Trick recht war, um freier Software zu schaden. Der einzige Unterschied: Heute entschuldigt sich der Konzern für einen Teil seiner Fehler. Selbst wenn man dies als glaubwürdig ansieht, nützt das dem Geschädigten nichts – AppGet wurde entführt und zerstört, wie es Keivan Beigi selbst formulierte. Die versprochene Zukunft bei Microsoft war ein Bluff.
Quellen
- https://github.com/microsoft/winget-cli/discussions/3964#discussioncomment-7816401 ↩︎
- https://github.com/microsoft/winget-cli/discussions/3964#discussioncomment-7995988 ↩︎
- https://packages.debian.org/search?keywords=apache2 ↩︎
- https://winstall.app/ ↩︎
- https://winget.pro/ ↩︎
- https://omaha-consulting.com/ ↩︎
- https://github.com/omaha-consulting/winget.pro ↩︎
- https://u-labs.de/portal/debian-12-bookworm-ist-da-das-ist-neu-raspberry-pi-os/ ↩︎
- https://www.thurrott.com/windows/windows-10/235783/appget-creator-says-microsoft-stole-his-product ↩︎
- https://devblogs.microsoft.com/commandline/winget-install-learning/ ↩︎
- https://www.neowin.net/news/microsoft-gives-appget-creator-credit-for-windows-package-manager/ ↩︎
- https://survey.stackoverflow.co/2022/#section-most-popular-technologies-operating-system ↩︎