WSL unter Windows on Arm: Was funktioniert und der Haken mit x86-Linux

WSL2 funktioniert gut unter Windows on Arm – wsl --install läuft auf einem Snapdragon-X-Laptop sofort, und für native Linux-Entwicklung fühlt es sich nicht anders an als auf einem Intel- oder AMD-Rechner. Aber es gibt eine architekturbedingte Einschränkung, die Entwickler überraschen kann, und es lohnt sich, sie zu verstehen, bevor man einen Workflow auf einen Arm-Laptop überträgt.

Die Architektur: WSL2 liefert Arm64-Linux

WSL2 ist ein echter Linux-Kernel, der in einer leichten (Hyper-V-basierten) VM läuft. Virtualisierung erfolgt nur innerhalb derselben Architektur, daher erhält man unter Windows on Arm einen Arm64 (aarch64)-Linux-Kernel und Arm64-Distributionen – wsl --install zieht automatisch Arm64-Ubuntu. Dies folgt derselben Architekturregel, die auch für Hyper-V und Mac-VMs gilt.

Verwenden Sie WSL2, nicht WSL1 auf Arm – die Syscall-Übersetzungsschicht von WSL1 ist veraltet; WSL2 liefert den echten Kernel und Container.

Der Haken: x86/x64-Linux-Binärdateien laufen nicht

Dies ist die Einschränkung, die überrascht, und der wesentliche Unterschied zu einem normalen x86-PC:

Eine Arm64-WSL-Distribution führt nur Arm64-Linux-Binärdateien aus. Sie führt x86/x64-Linux-Binärdateien nicht transparent aus – es gibt keinen integrierten architekturübergreifenden Emulator. Eine x86_64-Linux-ELF-Binärdatei schlägt fehl mit cannot execute binary file: Exec format error. Die üblichen Ausweichmöglichkeiten (qemu-user-static, box64) gelten heute als defekt oder unzuverlässig innerhalb von Arm-WSL. Behandeln Sie daher „x86-Linux-Binärdatei auf Arm-WSL ausführen“ als nicht zuverlässig unterstützt.

Verwechseln Sie das nicht mit Prism. Prism emuliert x86-Windows-Apps und funktioniert immer auf Arm. WSL ist die Linux-Seite – und dort arbeitet man nativ auf Arm64 ohne x86-Notlösung. Ein Leser, der weiß, dass „Windows-Apps emuliert laufen“, wird fälschlicherweise annehmen, dass Linux-Binärdateien das auch tun. Tun sie nicht.

Was läuft großartig (nativ)

Für native Arm64-Linux-Entwicklung ist WSL auf Arm exzellent. Verifiziert funktionierend: Node.js, Python, .NET 8, PHP, MySQL/Postgres in Containern, VS Code (mit der WSL-Erweiterung), Ollama. Distributionen mit soliden Arm64-Images: Ubuntu, Debian, Fedora, Kali, openSUSE, AlmaLinux.

Eine Einschränkung: Einige Distributionseinträge im Microsoft Store haben kein echtes Arm64-Image, daher kann es Versuch und Irrtum erfordern, funktionierende für Arm zu finden.

Docker und Multi-Arch-Builds

Docker Desktop hat volle Arm64-Unterstützung, wobei einige raue Kanten auf Snapdragon gemeldet wurden. Der Schmerzpunkt ist derselbe x86-Haken in Containerform: Das Ziehen und Ausführen von linux/amd64-Images erfordert QEMU-Emulation, die langsam ist. Wenn Ihr Team-CI oder Ihre Images amd64 voraussetzen, rechnen Sie mit Reibung – erstellen Sie Multi-Arch-Images und bevorzugen Sie arm64-Basisimages. Dies führt direkt zu CI/CD auf Arm.

GUI-Apps (WSLg)

WSLg (Linux-GUI-Apps unter Windows) funktioniert auf Arm, jedoch ohne GPU-Hardwarebeschleunigung – es wird per Software gerendert, und die App selbst benötigt einen Arm64-Build. Gut für Tools; nicht für GPU-intensive Linux-Apps.

Das Fazit

Für native Arm64-Linux-Arbeit – die meiste moderne Web-/Backend-/DevOps-Entwicklung – ist WSL auf einem Snapdragon-Laptop eine erstklassige Erfahrung. Die eine Sache, die Sie vor einem Wechsel überprüfen sollten: Liefern einige Ihrer Tools nur x86/x64-Linux-Binärdateien ohne Arm64-Build? Wenn ja, laufen diese nicht – genauso wie Sie eine Windows-App auf Abhängigkeiten prüfen würden, bevor Sie sie portieren. Für alles mit einem Arm64-Build sind Sie gut aufgestellt.