Microsoft hat am 22. April 2016 die Architektur des Windows Subsystem for Linux erklärt. Die Windows-Komponente führt native Linux-ELF64-Binaries aus und richtet sich damit auch an Entwickler, die ihre Werkzeuge unter Windows und Linux kombinieren möchten.
WSL besteht laut Microsoft aus einem Sitzungsdienst, Pico-Providern und Pico-Prozessen. Diese Komponenten bilden keine herkömmliche virtuelle Maschine. Stattdessen werden Linux-Systemaufrufe in einer Kompatibilitätsschicht auf dem Windows-NT-Kernel verarbeitet.
Pico-Prozesse verbinden Linux und Windows
Der LXSS-Manager verwaltet die Lebensdauer einer Linux-Instanz und startet Linux-Binaries über Bash. Die Treiber lxss.sys und lxcore.sys nehmen Systemaufrufe entgegen. Wo eine direkte Entsprechung fehlt, übernimmt die WSL-Schicht die nötige Logik selbst. Als Beispiel nennt Microsoft fork(), das im Windows-Kernel nicht als dokumentierter Aufruf mit identischer Bedeutung vorhanden ist.
Die Entwicklerseite erläutert außerdem, dass Pico-Prozesse aus Project Drawbridge stammen. Sie laden unveränderte Linux-Programme in einen Prozessraum und leiten deren Aufrufe an die gekoppelten Kernelkomponenten weiter. Damit unterscheidet sich WSL vom Ansatz früherer POSIX- und SUA-Subsysteme, die Anwendungen häufig neu kompilieren mussten.
VolFs und DriveFs für unterschiedliche Aufgaben
Für Linux-Dateien verwendet WSL VolFs. Das Dateisystem unterstützt unter anderem Linux-Berechtigungen, symbolische Links, case-sensitive Dateinamen und typische Verzeichnisse wie /etc, /bin und /usr. Der Zugriff auf diese Dateien aus normalen Windows-Anwendungen war in der ersten WSL-Version nicht vorgesehen.
DriveFs bindet dagegen die festen Windows-Laufwerke unter /mnt/c oder /mnt/d ein. Diese Ebene dient der Zusammenarbeit mit Windows-Programmen und erlaubt es, Dateien etwa mit Editoren zu bearbeiten und sie gleichzeitig mit Open-Source-Werkzeugen in Bash zu verarbeiten. Ein ähnlicher Plattformbezug für Entwickler zeigt sich bereits beim älteren Unity Cloud Build, das Windows, OS X und Linux in einem Build-Workflow verband.