Als der Hedgefonds TCI jüngst seinen Microsoft-Anteil drastisch zusammenstrich, klang das erst einmal nach einer dieser Meldungen, die im Strom der Finanznachrichten untergehen. Doch diesmal lohnt der zweite Blick. TCI-Gründer Chris Hohn gehörte jahrelang zu den großen Profiteuren des Microsoft-Booms, fast 400 Prozent Kursgewinn seit 2017 sprechen eine deutliche Sprache. Wenn ausgerechnet so ein Investor kalte Füße bekommt, geht es nicht um schwache Quartalszahlen. Dann steht die ökonomische Grundlage der Softwareindustrie zur Debatte.

Die Sprengkraft der KI-Revolution liegt nicht darin, dass sie eine bestimmte Software ersetzt. Sondern darin, dass sie das Geschäftsmodell dahinter pulverisiert. Willkommen in der SaaSpocalypse.

Das Geschäftsmodell hinter der Lizenzmaschine

Zwei Jahrzehnte lang funktionierte Unternehmenssoftware nach einem stabilen Prinzip. Jede Aufgabe bekam ihre eigene Anwendung: Texte in Word, Tabellen in Excel, Kundendaten in Salesforce, Bildbearbeitung in Photoshop. Unternehmen zahlen Lizenzen pro Nutzer, pro Arbeitsplatz, pro Monat. Je tiefer die Software in die Arbeitsabläufe einsickerte, desto verlässlicher sprudelten Umsatz und Margen. Der Wert lag dabei nie nur im Programmcode, sondern in einer schlichten Tatsache: Menschen mussten ihre Arbeit innerhalb dieser Anwendungen erledigen.

Genau diese Logik bröckelt nun. KI-Assistenten verändern nicht bloß einzelne Funktionen, sondern die Schnittstelle zur Arbeit selbst. Wer heute Copilot, Gemini oder ChatGPT nutzt, klickt sich nicht mehr durch klassische Menüs. Stattdessen formuliert der Nutzer Ziele: „Fasse die wichtigsten Punkte aus diesen Mails zusammen.“ „Bau eine Präsentation aus den Quartalszahlen.“ Die Arbeit wandert Schritt für Schritt vom Menschen zur Maschine. Und je besser diese Systeme werden, desto unwichtiger wird die Anwendung im Hintergrund.

Microsoft sägt am eigenen Ast

Das zeigt sich ausgerechnet bei Microsoft selbst. Seinen Copilot präsentiert der Konzern längst nicht mehr als Zusatzfunktion für Word oder Excel. Das Ziel ist ein Assistent, der quer über alle Anwendungen arbeitet. Der Nutzer redet mit dem Agenten – nicht mehr mit dem Programm. Wird die KI zur Bedienoberfläche der Wissensarbeit, verliert die klassische Anwendung ihre Rolle als zentraler Zugangspunkt. Sie wird zur Infrastruktur.

Aus Nutzersicht klingt das verlockend. Für die Softwareindustrie ist es eine Bedrohung. Denn Software-as-a-Service-Modelle leben davon, dass jeder Mitarbeiter Zugang zu einzelnen Anwendungen braucht. KI-Agenten lösen diese Kopplung auf. Warum Hunderte Vollzugänge bezahlen, wenn ein paar Agenten einen Großteil der Arbeit erledigen?

Die Börse handelt bereits die nächste Ära

Die Nervosität an den Börsen kommt nicht von ungefähr. Microsoft, Salesforce, Adobe und Oracle verdienen weiterhin Milliarden. Aber die Zweifel wachsen, ob die fetten Margen der SaaS-Ära dauerhaft Bestand haben. Bemerkenswert dabei: Die Disruption entsteht innerhalb der Plattformen selbst. Microsoft demonstriert mit Copilot genau die Entwicklung, die das klassische Softwaremodell untergräbt. Der Konzern treibt die Entkopplung von Nutzer und Anwendung selbst voran.

Börsen handeln spekulative Erwartungen, keine Gegenwart. Für Investoren genügt die Aussicht auf sinkende Preissetzungsmacht, um Bewertungen neu zu sortieren. Die Machtfrage lautet deshalb nicht mehr, wer die beste Software baut. Sondern wer künftig die Bedienoberfläche der Arbeit kontrolliert.

Das erklärt, warum TCIs Teilverkauf mehr ist als ein gewöhnliches Börsensignal. Der Fonds stößt Microsoft-Aktien nicht ab, weil Office schwächelt oder Azure plötzlich Verluste schreibt. TCI reagiert auf eine tiefere Unsicherheit: KI löst eben nicht einfach Programme ab. Sie ersetzt die ökonomische Logik, auf der die Softwareindustrie aufgebaut wurde. Und genau deshalb droht die SaaSpocalypse.

Bei diesem Kommentar handelt es sich um das Editorial der iX 6/2026, die am 22. Mai erscheint.

(fo)

Neben viel KI und Virtualisierung gab es auf dem Red Hat Summit auch Neuigkeiten im Bereich der Linux-Distribution: Fedora Hummingbird Linux – auch HummingbirdOS genannt – ist da. Hierbei handelt es sich um eine vollständig Container-basierte Distribution. Gleich mehrere bereits bekannte Projekte vereinen sich hier: Zum einen natürlich Software aus dem Fedora-Universum, aber auch rpm-ostree, das von Fedora CoreOS und auch Silverblue bekannt ist.

Statt über einen traditionellen Paketmanager kommen Software-Aktualisierungen über sogenannte Transaktionen in das System. Das ist vergleichbar mit einem Git-Commit mit zwei Zuständen: dem aktuellen und dem nächsten. HummingbirdOS greift ebenfalls auf das bootc-Projekt zurück. Dabei geht es um sogenannte „bootfähige“ Container, die mit einem Linux-Kernel und systemd ausgestattet sind. Sie können als normale Container laufen oder über bootc wie ein klassisches Linux starten.

Die letzte Zutat für das neue Fedora Linux ist das Hummingbird-Projekt. Es stellt minimalistische und gehärtete Container bereit. Letzteres bedeutet, dass es idealerweise keine bekannten ungepatchten Sicherheitslücken bezüglich der installierten Software gibt. Ziel ist, dass jeder Container nur eine Funktion hat.

HummingbirdOS ausprobieren

Fedora Hummingbird Linux ist noch in einem frühen Stadium. Interessierte können sich aber schon ein Abbild aus der Container-Registry der Hummingbird-Community herunterladen. Ferner kann man das System auch als virtuelle Maschine betreiben. Dazu muss man das Container-Abbild per bootc-image-builder umwandeln. Das Resultat ist entweder eine virtuelle Festplatte oder Installations-CD. Erstere bindet der Anwender entweder in den Hypervisor oder Cloud-Account ein. Danach startet HummingbirdOS analog zu den anderen virtuellen Maschinen. Die Installations-CD benutzt das bekannte Werkzeug Anaconda.

Bei den von Red Hat angedachten Anwendungsfällen schließt sich der Bogen zurück zur KI. HummingbirdOS soll laut Ankündigung als Plattform für KI-Agenten dienen. Designbedingt bietet es aktuelle Software mit minimaler Angriffsfläche. Unterstützung für Nutzer ist über den „Cooperative Community Support“ geplant. Hier können zahlende Red-Hat-Kunden auch Hilfe für bestimmte Projekte außerhalb des Enterprise-Umfeldes bekommen.

(fo)

Die vierte Vorschauversion der kommenden .NET-Version 11.0 ist erschienen und steht zum Download bereit. Parallel dazu hat Microsoft auch die Version 11811.120 von Visual Studio 2026 Insiders veröffentlicht, die zum Entwickeln von .NET-11.0-Anwendungen benötigt wird. Alternativ ist eine Arbeit mit Visual Studio Code und dem im SDK mitgelieferten Kommandozeilencompiler möglich.

Viel Neues für den Prozessstart

Die Klasse System.Diagnostics.Process zur Verwaltung von Betriebssystemprozessen gibt es seit Version 1.0 des klassischen .NET Framework aus dem Jahr 2002. Prozesse startet man seitdem, indem man eine neue Instanz der Klasse erzeugt. Seit .NET Framework 2.0 (Jahr 2005) gibt es alternativ die statische Methode Process.Start(). 21 Jahre später ergänzt Microsoft nun weitere alternative statische Methoden zum Prozessstart: Process.Run() und Process.RunAsync() sowie Process.RunAndCaptureText() und Process.RunAndCaptureTextAsync(). Das letztgenannte Pärchen liefert ein ProcessTextOutput-Objekt, mit dem man direkt auf Standardausgabe (ProcessTextOutput), Standardfehlerausgabe (StandardError) und Rückgabewert (ExitStatus.ExitCode) zugreifen kann, mit deutlich weniger Programmcode als dies bei der alten Start()-Methode notwendig ist, siehe Listing.

Ein Abbruch des Kindprozesses ist über ein Cancellation-Token möglich. Anders als bei der Start()-Methode kehren alle neuen Methoden mit „Run“ im Namen erst zum Aufrufer zurück, wenn der Kindprozess beendet ist. Entwicklerinnen und Entwickler können dabei allerdings keine Ausgaben des Prozesses verarbeiten, während er läuft.

CancellationTokenSource cts = new CancellationTokenSource();
 
 ProcessTextOutput result = await Process.RunAndCaptureTextAsync(
     "robocopy.exe", [@"t:\Daten", @"t:\Daten_Backup", "/MIR", "/IS"], cts.Token);
 
 CUI.Print("Neuer Prozess mit ID #" + result.ProcessId + " ist beendet!");
 
 CUI.Line("StandardOutput");
 CUI.Print(result.StandardOutput);
 CUI.Line("StandardError");
 CUI.PrintError(result.StandardError);
 CUI.Line("ExitStatus");
 CUI.Print("Canceled? " + result.ExitStatus.Canceled);
 if (result.ExitStatus.HasValue && !result.ExitStatus.IsEmpty) PrintStatus(result.ExitStatus.ExitCode);

Listing 1: Einsatz der neuen Methode Process.RunAndCaptureTextAsync()

Eine weitere hinzugefügte Methode zum Prozessstart ist Process.StartAndForget() zum Start eines Prozesses, ohne auf den erfolgreichen Start zu warten und ohne direkte Interaktionsmöglichkeiten mit dem neuen Prozess. Man kann lediglich über die zurückgelieferte Prozess-ID den neuen Prozess von außen überwachen, hat aber keinen Zugriff auf den Rückgabewert des Prozesses.

int processId = Process.StartAndForget(
    "robocopy.exe", [@"t:\Daten", @"t:\Daten_Backup", "/MIR", "/IS"]);
 
CUI.Print("Neuer Prozess mit ID #" + processId + " ist gestartet!");
 
var p = Process.GetProcessById(processId);
while(!p.HasExited)
{
 CUI.BusyIndicator();
 Thread.Sleep(500);
}
 
CUI.Line("Neuer Prozess mit ID #" + processId + " ist beendet!");
// PrintStatus(p.ExitCode); // System.InvalidOperationException: 'Process was not started by this object, so requested information cannot be determined.'

Listing 2: Einsatz der neuen Methode Process.StartAndForget()

In der Klasse ProcessStartInfo, die bei Process.Start() verwendet wird, gibt es auch zwei neue Boolean-Optionen: Neu sind zum einen ProcessStartInfo.StartDetached zum Start eines unabhängigen Prozesses mit eigener Konsole, der weiterlebt, auch wenn der startende Prozess beendet wird. Mit ProcessStartInfo.KillOnParentExit erreicht man zum anderen, dass der Kindprozess endet, wenn der startende Prozess endet. Wenn man beide Optionen in Kombination einsetzt, erhält man eine separate Konsole, die aber endet, wenn der startende Prozess endet. Während ProcessStartInfo.StartDetached auf allen Plattformen läuft, meldet ProcessStartInfo.KillOnParentExit aktuell, dass es nur auf Windows funktioniert, denn im Quellcode bei Microsoft steht:

[SupportedOSPlatform("windows")]
public bool KillOnParentExit { get; set; }

In einem Blogeintrag findet man schon den Hinweis darauf, dass Implementierungen für Android und Linux in Arbeit sind.

Für mit Process.Start() gestartete Prozesse gibt es auch die neuen Methoden ReadAllText() und ReadAllTextAsync(), mit denen man von einem beendeten Prozess gleichzeitig die Standardausgabe und die Fehlerausgabe erhalten kann:

process.WaitForExit();
(string output, string error) = process.ReadAllText();

Im Gegensatz zu dem bisherigen Ansatz

string output = process.StandardOutput.ReadToEnd();
string error = process.StandardError.ReadToEnd();

besteht bei den neuen Methoden nicht die Gefahr eines Deadlocks.

(De)-Komprimierung mit Span

In .NET 11.0 Preview 1 hatte Microsoft die Zstandard-Komprimierung ergänzt. Die Klassen ZstandardEncoder und ZstandardDecoder bieten dabei genauso wie die bereits in .NET Core 2.1 eingeführten Klassen BrotliEncoder und BrotliDecoder die Möglichkeit, beim Komprimieren und Dekomprimieren mit den Typen Span und ReadOnlySpan zu arbeiten, ohne die aufwendige Speicherallokation bei Streams. Nun liefert Microsoft diese Option auch für die älteren Klassen ZLibEncoder, DeflateEncoder und GZipEncoder sowie die zugehörigen Decoder, siehe Listing.

CUI.H1($"Komprimiere Datei {BIGFILEPATH} via Span");
 
ReadOnlySpan sourceSpan = File.ReadAllBytes(BIGFILEPATH);
Console.WriteLine("Länge=" + sourceSpan.Length);
long maxCompressedLength = ZLibEncoder.GetMaxCompressedLength(sourceSpan.Length);
Span compressedSpan = new byte[maxCompressedLength];
 
// ZLibEncoder, DeflateEncoder, GZipEncoder, ZstandardEncoder oder BrotliEncoder
using ZLibEncoder encoder = new();
OperationStatus status = encoder.Compress(
    sourceSpan, compressedSpan, out int bytesConsumed, out int bytesWritten,
    isFinalBlock: true);
 
PrintStatus(compressedSpan, status);
 
CUI.H1($"Dekomprimieren aus Span");
 
// ZLibDecoder, DeflateDecoder, GZipDecoder, ZstandardDecoder oder BrotliDecoder
using ZLibDecoder decoder = new();
byte[] decompressedSpan = new byte[sourceSpan.Length];
OperationStatus decompressStatus = decoder.Decompress(
  compressedSpan,
  decompressedSpan,
  out int compressedBytesConsumed,
  out int decompressedBytesWritten);
 
PrintStatus(decompressedSpan, decompressStatus);

Listing 3: Komprimierung und Dekomprimierung mit Span

Parsen von Hex-Werten

Die Fließkommazahltypklassen Half, Single und Double können in den Methoden Parse() und TryParse() auch Zeichenketten mit Hexadezimalzahlen auswerten. Dazu müssen Entwicklerinnen und Entwickler aber die Option NumberStyles.HexFloat angeben:

static void TestDouble(double d, string doubleAsString )
{
 string hex = d.ToString("X");
 Console.WriteLine(hex); 
 double d1a = double.Parse(hex, NumberStyles.HexFloat);
 Console.WriteLine(d1a); 
 CUI.Success(d1a == d); // True
 double.TryParse(hex, NumberStyles.HexFloat, null, out double d1b);
 Console.WriteLine(d1b); 
 CUI.Success(d1b == d); // True
}

Prüfung auf Gültigkeit bei UTF8 und UTF16

Die Klassen System.Text.Unicode.Utf8 und System.Text.Unicode.Utf16 bieten nun zwei neue Methoden: IsValid() und IndexOfInvalidSubsequence(). Damit lässt sich nun leichter die Gültigkeit einer Unicode-Zeichenkette prüfen und zumindest die erste fehlerhafte Stelle ermitteln:

ReadOnlySpan chars1 = "Gültiger Text: \uD83D\uDC4D";
Console.WriteLine(chars1);
bool check1 = Utf16.IsValid(chars1); // True
Console.WriteLine(check1);
if (check1) CUI.Success("OK");
else CUI.Warning("Fehler bei Zeichen: " + Utf16.IndexOfInvalidSubsequence(chars1));
 
ReadOnlySpan chars2 = "Ungültiger Text: \uD83D";
Console.WriteLine(chars2);
bool check2 = Utf16.IsValid(chars2); // False
if (check2) CUI.Success("OK");
else CUI.Warning("Fehler bei Zeichen: " + Utf16.IndexOfInvalidSubsequence(chars2));

Utf8JsonWriter mit abweichenden Einstellungen wiederverwenden

Bei dem im modernen .NET mitgelieferten JSON-Serialisierer, dem NuGet-Paket System.Text.Json, das auch im klassischen .NET Framework funktioniert, bietet die schon vorher bestehende Methode Reset() in der Klasse Utf8JsonWriter nun eine Überladung, in der man via JsonWriterOptions abweichende Einstellungen festlegen kann. Entwicklerinnen und Entwickler können damit Utf8JsonWriter-Instanzen mit abweichenden Einstellungen wiederverwenden:

using var stream1 = new MemoryStream();
using var writer = new Utf8JsonWriter(stream1, new JsonWriterOptions
  {
    Indented = true
  });
…
using var stream2 = new MemoryStream();
writer.Reset(stream2, new JsonWriterOptions
   {
    Indented = false
   });

Im Source Generator innerhalb von System.Text.Json behebt Microsoft einige Schwächen.