Windows Subsystem for Linux

LXSS Manager Service est le service qui interagit avec le sous-système (via les pilotes lxss.sys​ et lxcore.sys​), qui gère la façon dont bash.exe​ (à ne pas confondre avec les shells fournis par les distributions Linux) lance les processus Linux, et qui gère également les appels système Linux et les verrous binaires lors de leur exécution[22].

Tous les processus Linux appelés par un utilisateur vont dans une "instance Linux" (généralement, le premier processus appelé est init). Une fois toutes les applications fermées, l'instance est fermée.

La commande wsl.exe permet de gérer, en ligne de commande, les distributions dans WSL. Cette commande peut répertorier les distributions disponibles, définir une distribution par défaut et désinstaller les distributions[23]. La commande peut également être utilisée pour exécuter directement des fichiers binaires Linux à partir de l'invite de commande Windows ou de Windows PowerShell[24]. wsl.exe remplace lxrun.exe qui est obsolète à partir de Windows 10 1803[25].

Exécuter la commande uname dans WSL à l'aide de PowerShell.

PS C:\temp> wsl uname --all
Linux WikiMachine 4.4.0-18362-Microsoft #1-Microsoft Mon Mar 18 12:02:00 PST 2019 x86_64 x86_64 x86_64 GNU/Linux

Exemple d'utilisation de la commande sudo partir de l'invite de commande.

C:\temp> wsl sudo apt-get update
[sudo] password for username:
Hit:1 https://archive.ubuntu.com/ubuntu xenial InRelease
Get:2 https://security.ubuntu.com/ubuntu xenial-security InRelease [94.5 kB]

La conception de WSL 1 ne comportait aucune émulation / virtualisation matérielle (contrairement à d’autres projets tels que coLinux) et utilisait directement le système de fichiers hôte (via VolFS​ et DrvFS​)[26] et certaines parties du matériel, telles que le réseau afin de garantir l’interopérabilité[27]. Les serveurs Web, par exemple, sont accessibles via les mêmes interfaces et adresses IP configurées sur l'hôte et partagent les mêmes restrictions pour l'utilisation des ports nécessitant des autorisations administratives ou déjà occupés par d’autres applications).

Pour des raisons de sécurité, l'accès à certains emplacements (tels que les dossiers système) est restreint, même lors de l'exécution en tant que root (avec sudo à partir du shell). Pour accéder à ce type d'emplacement protégé, il est nécessaire de lancer une instance WSL avec des privilèges élevés (en tant qu'administrateur) afin que "sudo" donne de vrais privilèges root et autorise un tel accès[18].

WSL 1 ne peut pas exécuter tous les logiciels Linux, tels que les fichiers binaires 32 bits[28] - [29], ou ceux nécessitant des services spécifiques du noyau Linux non implémentés dans WSL. En raison de l'absence de "vrai" noyau Linux dans WSL 1, les modules du noyau, tels que les pilotes de périphérique, ne peuvent pas être exécutés. WSL 2, quant à lui, utilise des instances de noyau Linux virtualisées.

Il est possible d’exécuter certaines applications graphiques (comme Mozilla Firefox) en installant un serveur X11 dans l’environnement Windows (hôte) (VcXsrv ou Xming par exemple)[30]. Cependant, l'audio ou l'accélération matérielle ne sont pas pris en charge (ce qui entraîne de mauvaises performances graphiques). La prise en charge d’OpenCL et de CUDA n’est pas non plus mise en œuvre actuellement, bien que celle-ci soit prévue pour les versions futures[31] - [32].

Microsoft a déclaré que WSL 1 était destiné principalement au développement d'applications et non pas à l'exécution d'environnement de bureau ou de serveurs de production. Pour ce type d'usage, Microsoft recommande l'utilisation de machines virtuelles (Hyper-V), Kubernetes et Azure[18].

Dans les tests de performance, les performances de WSL 1 sont souvent proches des distributions Linux natives Ubuntu, Debian, Clear Linux ou autres. Dans certains tests, les I/O sont un goulot d'étranglement pour WSL[33] - [34] - [35]. Selon Microsoft, les modifications apportées à WSL sont censées offrir une vitesse multipliée par vingt sur certaines opérations par rapport à celle de WSL 1[4].

La version 2[36] introduit des modifications dans l'architecture. Microsoft a opté pour la virtualisation via un sous-ensemble optimisé de fonctionnalités Hyper-V[37], afin d'exécuter le noyau fourni et les distributions sous-jacentes, offrant des performances plus proches d'un Linux natif. La compatibilité avec les versions antérieures étant annoncée, les développeurs n’ont donc pas besoin de changer quoi que ce soit dans leurs distributions publiées.

Dans WSL 2, il existe une nouvelle configuration globale. Il est toutefois toujours possible, comme avec WSL 1, d'utiliser un fichier INI nommé .wslconfig situé également dans le dossier personnel de l'utilisateur[38] - [39]. Il s'installe particulièrement facilement sous la version "2004" disponible depuis fin mai 2020.

L'installation de la distribution s'effectue sur un système de fichiers au format ext4 dans un disque virtuel. Le système de fichiers hôte est accessible de manière transparente via le protocole 9P (en)[40]. Microsoft a annoncé multiplier par 20 les performances de lecture / écriture par rapport à WSL 1[41].

WSL 2 nécessite Windows 10.0.18917 ou supérieur. Le build 19041.329 de mai 2020 permet une installation en quelques dizaines de secondes, ne nécessitant ensuite qu'un redémarrage. On est libre ensuite de décider (ou non) que WSL 2 sera le WSL par défaut.

Un développeur signale ses compilations sous Linux comme 13 fois plus rapides[42] sous cette nouvelle version, dont les performances permettent à tout programmeur C de réaliser des animations 3D fluides en OpenGL.

La sortie de WSL 2 coïncide avec l'annonce de Microsoft visant à arrêter le portage d'applications Linux vers Windows[43] tel que PHP 8 qui ne sera pas proposé pour Windows par Microsoft, favorisant ainsi l'usage de WSL 2 pour PHP sous Windows.