Windows Subsystem for Linux

Pour les articles homonymes, voir WSL.

Cet article ne s'appuie pas, ou pas assez, sur des sources secondaires ou tertiaires (août 2023).

Pour améliorer la vérifiabilité de l'article ainsi que son intérêt encyclopédique, il est nécessaire, quand des sources primaires sont citées, de les associer à des analyses faites par des sources secondaires.

Windows Subsystem for Linux

Bash s'exécutant sous Windows 10

Informations

Créateur	Microsoft
Première version	2 août 2016
Dernière version	WSL 2 2.1.5[1]
Système d'exploitation	Windows 10 et Windows 11
Type	Microsoft Windows component (d) Environmental subsystem (en)
Licence	Microsoft CLUF (d), licence publique générale GNU version 2 et licence propriétaire
Site web	https://docs.microsoft.com/fr-fr/windows/wsl/

modifier - modifier le code - voir Wikidata (aide)

Windows Subsystem for Linux (WSL) est une couche de compatibilité permettant d'exécuter des exécutables binaires Linux (au format ELF) de manière native sur Windows 10, Windows 11 et Windows Server 2019^[2].

La version WSL 2 est sortie en mai 2019^[3],[4]. Cette nouvelle version introduit d'importants changements, notamment la présence d'un véritable noyau Linux^[5] via un sous-ensemble de fonctionnalités Hyper-V. Depuis juin 2019, WSL 2 est disponible pour les clients Windows 10 via le programme Windows Insider, y compris l'édition Famille^[6]. En juin 2020, il est accessible à tous les utilisateurs généraux Windows^[7]. Les appels graphiques et les lectures de fichiers Linux deviennent très rapides, mais l'accès aux fichiers Windows est en revanche ralenti.

La première version de WSL fournit une interface noyau compatible Linux développée par Microsoft, qui ne contient aucun code source du noyau Linux^[8]. Cette interface permet d'exécuter un espace utilisateur GNU comme celui d'Ubuntu^{[9],[10],[11],[12]}, openSUSE^[13], SUSE Linux Enterprise Server^{[14],[15],[16]}, Debian^[17] ou Kali Linux^[18]. Un tel espace utilisateur peut contenir un shell Bash avec des outils en ligne de commande GNU / Linux natifs (sed, awk, etc.), des interpréteurs de langage de programmation (Ruby, Python, etc.) et même des applications graphiques (utilisant un serveur X11 côté hôte)^[19].

L'architecture a été repensée dans WSL 2^[3], avec un noyau Linux s'exécutant dans une machine virtuelle légère.

Lors de son introduction avec la mise à jour anniversaire (1607) le 2 août 2016, seule une image Ubuntu était disponible. La mise à jour Fall Creators (1709), publiée le 17 octobre 2017, a déplacé le processus d'installation des distributions Linux vers le Windows Store et a introduit les images SUSE^[16].

WSL est disponible uniquement dans les versions 64 bits de Windows 10 à partir de la version 1607. Il est également disponible sous Windows Server 2019.

Le 6 mai 2019^[3], Microsoft a lancé WSL 2^[3], qui propose un tout nouveau backend basé sur une machine virtuelle (basée sur un sous-ensemble de fonctionnalités Hyper-V) au lieu de la couche de compatibilité antérieure.

La première tentative de Microsoft pour atteindre une compatibilité de type Unix sur Windows a commencé avec le sous-système Microsoft POSIX, remplacé par Windows Services for UNIX, qui a finalement été rendu obsolète à la sortie de Windows 8.1. La technologie à l'origine de WSL est issue du projet non publié Astoria, qui permettait à certaines applications Android de s'exécuter sur Windows 10 Mobile^[20]. Il a d'abord été mis à disposition dans Windows 10 Insider Preview build 14316^[21].

Alors que les projets précédents de Microsoft et de Cygwin s’étaient concentrés sur la création de leurs propres environnements de type Unix basés sur le standard POSIX, WSL vise la compatibilité native avec Linux. Au lieu d'encapsuler les fonctionnalités non natives dans les appels système Win32, la conception initiale de WSL (WSL 1) exploitait l'exécutif du noyau NT pour servir les programmes Linux en tant que processus minimaux isolés et uniques (appelés "pico processus") liés au mode noyau "pico providers" en tant que gestionnaires d'appels système et d'exceptions dédiés, distincts de ceux d'un processus NT classique, en choisissant de réutiliser les implémentations NT existantes dans la mesure du possible^[22].

Bien que WSL (dans cette conception initiale) soit beaucoup plus rapide et sans doute beaucoup plus populaire que les autres solutions permettant d'utiliser Linux sur Windows, les ingénieurs du noyau Windows ont eu du mal à augmenter les performances de WSL et la compatibilité des appels systèmes en essayant de remodeler le noyau NT existant pour qu'il reconnaisse et fonctionne correctement sur l'API de Linux . Lors d'une conférence Microsoft Ignite en 2018, les ingénieurs Microsoft ont donné un aperçu d'une nouvelle technologie "légère" de machine virtuelle Hyper-V pour la conteneurisation dans laquelle un noyau virtualisé pouvait utiliser directement les primitives NT sur l'hôte. En 2019, Microsoft a repensé l'architecture de WSL 2, utilisant cette technologie VM légère hébergeant des images de noyau Linux réelles (personnalisées), revendiquant ainsi une compatibilité complète^[5].

Microsoft présente WSL comme un outil pour les développeurs - en particulier les développeurs Web et ceux qui travaillent sur ou avec des projets open source^[19]. WSL utilise moins de ressources qu'une machine virtuelle classique (avant WSL, une machine virtuelle était le moyen le plus direct pour exécuter un logiciel Linux dans un environnement Windows), tout en permettant aux utilisateurs d'utiliser des applications Windows et des outils Linux sur le même ensemble de fichiers.

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^[23].

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^[24]. 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^[25]. wsl.exe remplace lxrun.exe qui est obsolète à partir de Windows 10 1803^[26].

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)^[27] et certaines parties du matériel, telles que le réseau afin de garantir l’interopérabilité^[28]. 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^[19].

WSL 1 ne peut pas exécuter tous les logiciels Linux, tels que les fichiers binaires 32 bits^[29],[30], 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)^[31]. 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^[32],[33].

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^[19].

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^{[34],[35],[36]}. 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^[5].

La version 2^[37] introduit des modifications dans l'architecture. Microsoft a opté pour la virtualisation via un sous-ensemble optimisé de fonctionnalités Hyper-V^[38], 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^[39],[40]. 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)^[41]. Microsoft a annoncé multiplier par 20 les performances de lecture / écriture par rapport à WSL 1^[42].

WSL 2 nécessite Windows 10 version 1903 ou une version ultérieure pour les systèmes basés sur x86, ou Windows 10 version 2004 ou une version ultérieure pour les systèmes basés sur ARM^[43]. 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^[44] 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^[45], tel que PHP 8 qui ne sera pas proposé pour Windows par Microsoft, favorisant ainsi l'usage de WSL 2 pour PHP sous Windows.

• 
  Firefox pour Linux s'exécutant sur WSL
• 
  Gestionnaire de paquets Synaptic s'exécutant sur WSL

• (en) Cet article est partiellement ou en totalité issu de l’article de Wikipédia en anglais intitulé « Windows Subsystem for Linux » (voir la liste des auteurs).

• Blog sur le sous-système Windows pour Linux
• WSL sur Microsoft Docs
• Windows Subsystem for Linux sur GitHub
• Blog des outils de ligne de commande Windows pour les développeurs
• Brown, « Fun with the Windows Subsystem for Linux », Windows Developer Blog, Microsoft, 22 juillet 2016

• Portail de l’informatique
• Portail de Microsoft
• Portail GNU/Linux