WSL

WSL ermöglicht es Entwicklern, unveränderte Linux-Befehlszeilentools, Dienstprogramme und Anwendungen direkt unter Windows auszuführen, ohne den Aufwand einer herkömmlichen virtuellen Maschine oder einer Dual-Boot-Konfiguration.

Jahrelang hatten Windows-Entwickler, die an Software für Linux arbeiteten, zwei Möglichkeiten: entweder eine vollständige virtuelle Maschine auszuführen - was die Verwaltung von Festplatten-Images, das Abwarten von Startsequenzen und den Verbrauch von RAM auf einem Gastbetriebssystem bedeutete - oder ein Dual-Boot-System zu nutzen, was einen Neustart jedes Mal erforderte, wenn ein Kontextwechsel zwischen den Ökosystemen notwendig war. WSL war Microsofts Antwort auf beide Probleme. Und es funktionierte so gut, dass es zur Standard-Entwicklungsumgebung für eine enorme Anzahl von Windows-basierten Entwicklern wurde.

WSL wurde erstmals auf der Microsoft BUILD 2016 vorgestellt und schließlich im Windows 10 Anniversary Update ausgeliefert. Die erste Version, WSL 1, nutzte eine Kompatibilitätsschicht, die Linux-Systemaufrufe übersetzte, sodass diese über einen benutzerdefinierten Treiber mit dem Windows-NT-Kernel kommunizieren und zusammenarbeiten konnten.

Dieser Ansatz stieß unweigerlich an seine Grenzen. Die Übersetzung von Systemaufrufen ist clever. Sie ist jedoch nicht vollständig.

WSL 2 hat die Architektur komplett verändert

Im Jahr 2019 veröffentlichte Microsoft WSL 2, das einen echten Linux-Kernel enthielt, der in einer virtuellen Maschine lief und erhebliche Verbesserungen bot, wie beispielsweise Leistungssteigerungen, GPU- und systemd-Unterstützung sowie die Möglichkeit, grafische Anwendungen auszuführen.

WSL 2 ist die aktuelle Standardversion bei der Installation einer Linux-Distribution und nutzt die neuesten und besten Virtualisierungstechnologien, um einen Linux-Kernel in einer schlanken, zweckgebundenen virtuellen Maschine auszuführen.

Dies ist die Architektur, die die meisten Entwickler, die sich heute mit WSL beschäftigen, tatsächlich nutzen. Der Begriff "virtuelle Maschine" verwirrt zunächst. Er klingt aufwendig. Ist er aber nicht. Microsoft behauptet, dass WSL weniger Ressourcen - CPU, Arbeitsspeicher und Speicherplatz - benötigt als eine vollständige virtuelle Maschine, während gleichzeitig die Verwendung von Windows- und Linux-Tools auf demselben Dateisatz möglich ist.

Der entscheidende Unterschied zu einem herkömmlichen Hypervisor: Man verwaltet diese VM nicht. Man weist ihr keinen Speicherplatz zu. Man bootet nicht in sie hinein. Man gibt "wsl" ein und befindet sich in weniger als zwei Sekunden in Ubuntu.

Was hat sich also geändert, als WSL Open Source wurde?

Das Tool selbst hat sich am 19. Mai 2025 nicht verändert. Was sich geändert hat, war die Beziehung zwischen Microsoft und jedem Entwickler, der es nutzt.

Microsoft stellte WSL erstmals auf der Build 2016 vor. Die allererste Frage, die jemals im WSL-GitHub-Bugtracker gestellt wurde, lautete: "Wird das Open Source sein?" Neun Jahre später lautete die Antwort "Ja", und dieses Ticket wurde schließlich geschlossen.

Auf der Microsoft Build 2025 stellte das Unternehmen die Befehlszeilentools von WSL (wsl.exe und wslg.exe), die Hintergrunddienste (wslservice.exe) sowie die Linux-seitigen Daemons, die zum Starten der Netzwerkverbindung, zum Starten anderer Daemons und zum Einrichten der Portweiterleitung verwendet werden, als Open Source zur Verfügung.

Die einzigen Komponenten, die nicht als Open Source veröffentlicht wurden, sind Lxcore.sys - der kernelseitige Treiber, der WSL 1 antreibt - sowie P9rdr.sys und p9np.dll, die für die Umleitung des Dateisystems unter \\wsl.localhost verwendet werden.

Diese Ausnahme ist von Bedeutung. Die Dateisystembrücke zwischen Windows und Linux - der Teil, der es Ihnen ermöglicht, Ihre Linux-Dateien über den Windows-Explorer zu öffnen - ist nach wie vor proprietär. Für die meisten Entwickler ist dies unsichtbar. Für alle, die in einer regulierten Umgebung jede Ebene prüfen müssen, ist dies jedoch nicht der Fall.

Die Architektur: Wie WSL 2 tatsächlich funktioniert

Die Hauptunterschiede zwischen WSL 1 und WSL 2 sind die Verwendung eines echten Linux-Kernels innerhalb einer verwalteten VM, die Unterstützung vollständiger Systemaufrufkompatibilität sowie die Leistung über die Betriebssysteme Linux und Windows hinweg.

Jede Linux-Distribution, die Sie installieren - Ubuntu, Debian, Fedora, Kali - läuft als containerisierte Umgebung innerhalb dieser verwalteten VM. WSL 2 führt Linux-Distributionen als isolierte Container innerhalb der verwalteten VM aus.

Die VM startet bei Bedarf, weist Speicher dynamisch zu und gibt diesen Speicher wieder frei, sobald Sie Ihren letzten Linux-Prozess schließen. Der Start dauert weniger als zwei Sekunden - keine Boot-Sequenz, keine Wartezeit. Speicher und CPU werden automatisch skaliert: Wenn Ihre Anwendung 1 GB benötigt, werden 1 GB genutzt und nach Abschluss wieder freigegeben.

Auch das Netzwerkmodell ist deutlich ausgereifter geworden. Mit WSL 2.0.0 wurden gespiegelte Netzwerke, DNS-Tunneling, Unterstützung für Session 0, Proxy-Unterstützung und Firewall-Integration eingeführt. Gespiegelte Netzwerke waren die Funktion, auf die Unternehmensentwickler seit Jahren gewartet hatten: Ihre WSL-Instanz nutzt nun dieselben Netzwerkschnittstellen und dieselbe IP-Adresse wie Windows, was bedeutet, dass Sie sich nicht mehr mit Portweiterleitung herumschlagen müssen, nur um von innerhalb von Linux mit "localhost" zu kommunizieren.

Wo es noch hakt

WSL 2 ist kein nativer Linux-Kernel. Bei den meisten Arbeitsabläufen hat sich diese Lücke fast vollständig geschlossen. An einigen Stellen macht es sich jedoch noch bemerkbar:

Wenn Sie WSL 2 unter Windows verwenden und Projektdateien unter /mnt/c/ statt im nativen WSL-2-Dateisystem unter ~/ speichern, werden alle dateiintensiven Tools - npm, pip, cargo und Maven - unter der E/A-Leistungseinbuße bei systemübergreifenden Dateizugriffen leiden. Dieser einzelne Stolperstein verursacht mehr Beschwerden über "WSL ist langsam" als jede tatsächliche architektonische Einschränkung. Die Lösung ist trivial: Speichern Sie Ihre Projektdateien unter ~/ statt unter /mnt/c/.

Wo WSL noch Defizite aufweist, sind Low-Level-Kernel-Aufgaben, ressourcenintensive Docker-Builds mit vielen kleinen Dateien und alles, was USB- oder GPU-Pass-Through im Produktionsmaßstab erfordert.

Der Treiber für die Dateisystemumleitung ist nach wie vor proprietär. Bestimmte Dateisystemfunktionen stützen sich auch Ende 2025 noch auf eine proprietäre Closed-Source-Bibliothek. Für Teams im Gesundheitswesen, im Fintech-Bereich oder in der öffentlichen Verwaltung mit strengen Open-Source-Prüfungsanforderungen stellt dies in Extremfällen nach wie vor ein Hindernis dar.

Der Schritt hin zu Open Source verändert den Kurs

Als sich das WSL-Ökosystem weiterentwickelte und Unterstützung für GPU-Beschleunigung, Linux-GUI-Anwendungen über wslg sowie systemd hinzukam, wurde klar, dass WSL vom Windows-Betriebssystem entkoppelt werden musste. Entwickler können nun auf GitHub auf den WSL-Quellcode zugreifen, ihn aus dem Quellcode kompilieren, Fehlerbehebungen und Funktionen beisteuern und an der laufenden Entwicklung mitwirken.

Dies ist mehr als nur symbolisch von Bedeutung. WSL hat die Art und Weise, wie Linux-Umgebungen unter Windows betrieben werden, tiefgreifend verändert. Indem Microsoft den Code nun auf GitHub zugänglich macht, zielt das Unternehmen darauf ab, funktionale Verbesserungen zu beschleunigen und die Zusammenarbeit mit großen Distributionen wie Ubuntu, Red Hat, SUSE und Debian auszuweiten.

Seit April 2026 hat sich WSL vollständig von einer experimentellen Funktion zum Industriestandard für plattformübergreifende Entwicklung entwickelt.

Dieser Kurs liegt nun in den Händen der Community und wird nicht mehr von Microsoft kontrolliert.

Stand: 11.07.2026