Ich gehöre nicht zu den Leuten, die Microsoft pauschal kritisch sehen. Im Gegenteil. Ich arbeite gerne mit Windows, ich nutze viele Microsoft-Produkte regelmässig, und ich habe grossen Respekt vor dem, was das Unternehmen in den letzten Jahren im Bereich Entwickler-Tools auf die Beine gestellt hat. Visual Studio Code, GitHub, TypeScript, .NET als Open Source, das alles sind Projekte, die unsere Branche geprägt haben. Eines der für mich persönlich wichtigsten Werkzeuge aus diesem Umfeld ist das Windows Subsystem for Linux, kurz WSL.
Ich nutze WSL 2 schon eine ganze Weile, sowohl beruflich bei Compresso als auch privat. In dieser Zeit hat sich das System vom interessanten Experiment zum festen Bestandteil meines Workflows entwickelt. Ich möchte in diesem Artikel deshalb nicht so tun, als wäre WSL für mich etwas Neues. Stattdessen will ich erklären, warum es technisch so spannend gebaut ist, wie es im Alltag funktioniert und wo sein wirklicher Mehrwert liegt.
Vom Übersetzer zur virtuellen Maschine
Die erste Version von WSL war ein technisch ambitioniertes Projekt. Microsoft hatte eine Übersetzungsschicht gebaut, die Linux-System-Calls in Echtzeit auf Windows-System-Calls übersetzte. Im Prinzip lief eine Linux-Distribution direkt auf dem Windows-Kernel, ohne echten Linux-Kernel und ohne Virtualisierung im Grunde das Gegenstück von Wine in Linux. Das war elegant, hatte aber Grenzen. Die Dateisystem-Performance war ein Dauerthema, viele Tools liefen schlicht nicht oder nicht korrekt, und Docker-Container waren auf diesem Weg nicht möglich.
Mit WSL 2 hat Microsoft den Ansatz neu gedacht. Statt einer Übersetzungsschicht bekommst du einen echten Linux-Kernel, den Microsoft selber pflegt und auf GitHub veröffentlicht. Dieser Kernel läuft in einer leichtgewichtigen virtuellen Maschine, gestartet über Hyper-V. Auf den ersten Blick klingt das nach mehr Komplexität, in der Praxis ist es deutlich runder. Performance, Kompatibilität und Tooling-Unterstützung sind seit der zweiten Version auf einem ganz anderen Level.
Hyper-V ist kein VirtualBox
Hier wird es technisch wirklich spannend, und ich finde das einen der faszinierendsten Aspekte der ganzen Konstruktion. Wenn du Virtualisierung von VirtualBox oder VMware Workstation kennst, hast du ein bestimmtes Modell im Kopf. Du installierst eine Anwendung auf deinem Betriebssystem, startest darüber eine VM, und diese VM läuft als Prozess innerhalb deines Hostsystems. Das nennt sich Type-2-Hypervisor oder hosted Hypervisor.
Hyper-V funktioniert anders. Hyper-V ist ein Type-1-Hypervisor, also ein Bare-Metal-Hypervisor wie Xen oder ESXi. Sobald Hyper-V aktiv ist, und das passiert unter anderem beim Einrichten von WSL 2, schiebt sich der Hypervisor zwischen Hardware und Betriebssystem. Dein Windows, das du siehst und benutzt, läuft danach selbst als virtuelle Maschine. Microsoft nennt diese spezielle VM "Root Partition" oder "Parent Partition". Sie ist hochprivilegiert und hat direkten Zugriff auf die Hardware, aber technisch gesehen ist sie eine VM.
Linux läuft dann nicht innerhalb dieser Windows-VM, sondern als zweite VM in einer sogenannten Child Partition, parallel zu Windows auf demselben Hypervisor-Layer. Dein Linux ist also nicht eine Anwendung in Windows, dein Linux ist eine eigenständige VM, die neben Windows läuft. Beide kommunizieren über den Virtual Machine Bus von Hyper-V miteinander.
Das ist architektonisch elegant. Weil Linux nicht durch Windows hindurchgehen muss, sondern direkt mit dem Hypervisor spricht, bekommt es nahezu nativen Zugriff auf CPU, Speicher und Geräte. Das erklärt auch die ausgezeichnete Performance, die WSL 2 im Vergleich zu klassischen VM-Lösungen liefert. Wenn du dir das Bild einmal verinnerlicht hast, dass dein Windows und dein Linux gleichberechtigt nebeneinander auf dem Hypervisor sitzen, verstehst du auch, weshalb sich das System so flott anfühlt.
Das Setup im Alltag
Heute ist die Installation in wenigen Minuten erledigt. In einer PowerShell genügt der Befehl wsl --install, und Windows kümmert sich um den Rest. Hyper-V wird aktiviert, die Virtual Machine Platform wird eingerichtet, der Linux-Kernel wird heruntergeladen, und nach einem Reboot landet eine Ubuntu-Installation auf dem System. Du kannst auch andere Distributionen wählen, Debian, openSUSE und Fedora-Derivate sind verfügbar, ich bleibe persönlich meistens bei Ubuntu, weil die Erfahrung am rundesten ist und alle gängigen Tools sofort funktionieren.
Mein typisches Setup besteht aus PHP, Node.js, Composer, Git und Docker, also der klassischen Web-Entwickler-Toolchain. Auf WSL 2 installierst du diese Tools genauso, wie du es auf einem nativen Linux tun würdest. apt update, apt install, fertig. Docker Desktop hat einen WSL-2-Backend-Modus, in dem die Container nicht mehr in einer separaten VM laufen, sondern direkt in deiner WSL-2-Umgebung. Dadurch ist Docker auf Windows endlich genauso schnell, wie man es von Linux kennt.
Mein Editor ist Visual Studio Code. Die Remote-WSL-Extension ist für mich eines der besten Stücke Tooling überhaupt. Du startest VS Code unter Windows, öffnest einen Ordner aus deiner WSL-Distribution, und VS Code installiert automatisch einen kleinen Server in deiner Linux-Umgebung. Der Editor selber läuft auf der Windows-Seite, aber alle Aktionen, Dateioperationen, Terminals, Debugging, finden in der Linux-VM statt. Extensions kannst du gezielt für die Linux-Umgebung installieren, sodass beispielsweise PHP-Tools oder Linter sauber gegen das passende Binary in WSL laufen. Im Alltag merkst du den Unterschied zu einem rein nativen Linux-Setup nicht.
Ein praktischer Tipp aus der Erfahrung: Lege deine Projekte komplett in der Linux-Welt ab, am besten unter ~/projects oder einem ähnlichen Pfad. Greift Linux auf Windows-Dateien unter /mnt/c/ zu, ist das spürbar langsamer als der Zugriff auf das eigene Filesystem. Umgekehrt funktioniert der Zugriff von Windows auf WSL über den UNC-Pfad \\wsl$ zwar problemlos, ist aber für intensive Build-Prozesse ebenfalls nicht ideal. Wer das von Anfang an beachtet, hat keine Performance-Diskussionen mehr.
Beide Welten gleichzeitig
Der eigentliche Mehrwert von WSL 2 liegt für mich genau in diesem Punkt: Du musst dich nicht mehr zwischen zwei Welten entscheiden. Auf einer Windows-Maschine hast du Adobe Illustrator, InDesign, Photoshop, das ganze Microsoft Office, Affinity, Figma Desktop, Snagit und alles andere, was die produktive Arbeit ausmacht. Vieles davon gibt es für Linux schlicht nicht oder nur als unbefriedigenden Ersatz. Mit WSL 2 hast du diese Anwendungen weiterhin zur Verfügung, mit nativer Performance und voller Funktionalität. Gleichzeitig hast du eine vollwertige Linux-Umgebung mit echtem Kernel, in der dein Webprojekt zuhause ist.
Das ist ein Workflow, der vor WSL schlicht nicht möglich war. Du arbeitest am Vormittag an einem Kundenmockup in Illustrator, exportierst Assets, und im selben Atemzug bindest du sie in dein WordPress-Theme ein, das in Docker auf WSL läuft. Du musst nicht zwischen Maschinen oder Betriebssystemen wechseln, du musst kein Asset hin und her schieben, beides ist gleichzeitig zur Hand. Für mich als Entwickler ist das die eigentliche Killer-Funktion. Die alte Frage "Mac, Linux oder Windows" verliert damit einen guten Teil ihrer Schärfe.
Auch grafische Linux-Anwendungen funktionieren übrigens. Microsoft hat mit WSLg eine Wayland-Implementierung gebaut, die Linux-GUI-Programme direkt im Windows-Fenstermanager anzeigt. Du kannst also problemlos GIMP, Inkscape oder einen Linux-spezifischen Datenbankclient starten, und das Fenster öffnet sich neben deinen Windows-Anwendungen. Im Hintergrund läuft das alles über die Hypervisor-Grenze, im Vordergrund merkst du davon nichts.
Mein Fazit
WSL 2 ist für mich kein Notbehelf und kein Kompromiss, sondern ein eigenständiges Werkzeug, das genau die Lücke füllt, die früher offen war. Wer ohnehin gerne mit Windows arbeitet und gleichzeitig die Linux-Toolchain für seine Entwicklungsarbeit braucht, bekommt mit WSL 2 die meiner Meinung nach beste Lösung, die es derzeit für dieses Szenario gibt. Performance, Tooling-Integration und Stabilität haben in den letzten Jahren ein Niveau erreicht, das den Wechsel zwischen Linux- und Windows-Welt fast unsichtbar macht.
Was mich dabei besonders beeindruckt, ist der Aufwand, den Microsoft betreibt. Ein eigener Linux-Kernel auf GitHub, eine echte Type-1-Virtualisierung als Unterbau, eine Editor-Integration die wirklich rund funktioniert, und WSLg als grafische Erweiterung. Das ist eine Menge Engineering, und das Ergebnis spürt man im Alltag jeden Tag. Wenn ich jemandem heute eine Empfehlung gebe, der unter Windows produktiv Web-Entwicklung machen will, ist die Antwort einfach: Aktiviere WSL 2, installiere VS Code mit der Remote-Extension, und du hast ein Setup, das in nichts hinter einem nativen Linux zurücksteht.
