9 points par GN⁺ 2025-12-02 | 3 commentaires | Partager sur WhatsApp
  • L’architecture des sous-systèmes de Windows NT a historiquement reposé sur une couche de conversion des appels API pour exécuter des programmes d’autres systèmes d’exploitation
  • WSL1 s’inscrivait dans cette continuité : en tant que couche de traduction légère, il convertissait les appels Linux en appels du noyau Windows
  • WSL2 a basculé vers une VM Linux complète basée sur Hyper-V pour résoudre les problèmes de performance, et exécute un noyau Linux réel
  • WSL2 propose une intégration plus poussée que les VM classiques grâce à la gestion dynamique de la mémoire, le montage des lecteurs Windows et l’intégration GUI via WSLg
  • Malgré des limites (gestion des fichiers peu pratique, dépendance aux images disque), la souplesse de tirer parti des forces et des faiblesses de WSL1 et WSL2 selon le cas d’usage reste essentielle

Le concept de sous-système dans Windows NT

  • Le sous-système (subsystem) de Windows NT désigne un jeu d’API et une couche de conversion d’appels pour exécuter des programmes d’autres systèmes d’exploitation
    • NT proposait autrefois des sous-systèmes comme OS/2 subsystem (OS2SS.EXE), POSIX subsystem (PSXSS.EXE), etc.
    • CSRSS.EXE est une couche de conversion de l’API Win32, dont certaines fonctions ont été déplacées en mode noyau (WIN32K.SYS)
  • Le sous-système POSIX était une implémentation minimale pour certification gouvernementale, puis a été remplacé par Interix-based Windows Services for Unix

WSL1 : couche Linux basée sur la traduction

  • WSL1 (Windows Subsystem for Linux) est une couche de traduction légère qui convertit les appels système Linux en appels Windows
    • À l’exécution, le processus bash utilise seulement quelques Mo de mémoire et apparaît comme un processus normal dans le Gestionnaire des tâches
    • La racine du système de fichiers existe comme une structure de fichiers individuelle sur NTFS, avec très peu de surcharge de stockage
  • Limites
    • Dégradation des performances I/O : coût de conversion lié aux différences entre les API de fichier Linux et Win32
    • Serveur X externe requis pour exécuter une GUI (par ex. X410)
    • Raw sockets non pris en charge, ce qui empêche l’exécution de traceroute, nmap, tcpdump, etc.

WSL2 : VM Linux basée sur Hyper-V

  • Face aux besoins des utilisateurs, Microsoft a introduit une VM Linux complète fonctionnant sur Hyper-V
    • La racine du système de fichiers est gérée via un fichier VHDX unique
    • La conversion WSL1↔WSL2 est possible avec la commande wsl --set-version "Ubuntu" 2
  • Caractéristiques de performance
    • Le démarrage initial est plus lent, mais il exécute un noyau Linux natif
    • L’utilisation mémoire est dynamique et peut monter jusqu’à la moitié de la mémoire physique maximale
    • Dans le test stress, l’usage mémoire augmente avec la charge puis se réduit automatiquement
    • Lorsque nécessaire, la VM peut être arrêtée avec la commande wsl --shutdown

Intégration et limites de WSL2

  • WSL2 renforce l’intégration avec Windows par rapport à une VM traditionnelle
    • Montage automatique des lecteurs Windows, accès aux lecteurs Linux via le chemin \\wsl$\\, exécution d’apps GUI via WSLg
    • Les applications GUI sont diffusées via le Remote Desktop Protocol, avec un réglage spécifique requis pour le DPI et la mise à l’échelle du texte
  • Problèmes de gestion des fichiers
    • Les données de travail Linux sont stockées dans l’image ext4.vhdx, avec des risques de portabilité et de récupération
    • L’exécution de wsl --unregister Distro supprime immédiatement toutes les données
    • Utiliser les lecteurs Windows (/mnt/c) entraîne des baisses de performance dues à la surcharge NTFS + VM
  • Protocoles de système de fichiers
    • WSL1 utilise drvfs, WSL2 utilise le protocole 9p de Plan9
    • Des cas de bugs résiduels liés à drvfs sont mentionnés pendant les conversions
  • Alternative
    • Il est recommandé de créer une image VHDX séparée et de la monter avec wsl --mount --vhd pour isoler les données de travail
    • La configuration automatique n’est pas possible dans .wslconfig, il faut la piloter via des scripts

Conclusion

  • La conception modulaire de Windows NT et son ABI noyau stable préservent la compatibilité avec d’anciens pilotes
  • WSL1 a l’avantage d’une faible consommation mémoire, tandis que WSL2 apporte une compatibilité et des performances supérieures avec un noyau Linux réel
  • WSL2 est une architecture qui minimise les inconvénients d’une VM tout en renforçant l’intégration avec l’OS hôte
  • Selon la définition classique, il s’apparente à une VM, mais il mérite d’être considéré comme un « sous-système » grâce à son intégration légère

3 commentaires

 
crawler 2025-12-02

Waouh, il y a aussi le développeur Sseuk.

 
GN⁺ 2025-12-02
Avis Hacker News
  • WSL2 fonctionne sur un sous-ensemble de Hyper-V et est, fondamentalement, une VM au-dessus de l’hyperviseur
    Mais il diffère d’une VM Hyper-V classique. Par exemple, les distributions Linux de WSL2 peuvent utiliser l’accélération GPU même dans des environnements X ou Wayland grâce au partitionnement GPU (c’est-à-dire le passthrough PCI/GPU) et à une implémentation spéciale de DirectX
    Ce genre de fonctionnalité est aussi possible sur un Hyper-V classique via des bricolages avec PowerShell, mais officiellement, ce n’est pris en charge que sur Windows Server

    • Je pensais que le passthrough GPU fonctionnait aussi sur Windows 11 standard, mais je n’ai pas vérifié en détail. Cela reste une fonctionnalité assez impressionnante
    • Au final, c’est juste une VM classique, mais l’automatisation est appréciable
      En revanche, dire que « X ou Wayland s’occupent du rendu » est trompeur. En réalité, c’est l’application elle-même qui utilise le GPU, et X/Wayland ne gèrent essentiellement que la composition des fenêtres une fois le rendu terminé
      Il y a aussi des opérations plus complexes comme la conversion des couleurs, mais la charge de calcul reste faible
    • WSL2 et le noyau WinNT ne tournent-ils pas tous les deux à peu près au même niveau au-dessus de Hyper-V ? Bien sûr, le noyau NT a davantage de droits d’accès au matériel
    • C’est amusant d’imaginer devoir acheter et installer une licence Windows Server juste pour exécuter Linux
    • L’intégration graphique de WSL2 m’a plus déçu que je ne l’espérais. L’ancienne configuration avec serveur X était meilleure. Mais X ne prend pas en charge les API modernes, donc les développeurs s’en désintéressent peu à peu. J’espère que cela s’améliorera à mesure que le support de WSL2 progressera
  • WSL1 reposait sur les pico process, une technologie dérivée de la recherche Drawbridge
    Voir les ressources The Linux Kernel Hidden Inside Windows 10 et WSL Pico Process Overview
    La même technologie Drawbridge a aussi été utilisée pour exécuter SQL Server sur Linux
    L’article d’Ars Technica l’explique en détail

  • Je comprends pourquoi ils sont passés à WSL2, mais c’est dommage d’avoir complètement arrêté le développement de WSL1
    Notre environnement de CI est majoritairement basé sur Linux, mais certaines toolchains ne fonctionnent pas bien sous Wine, comme MSVC
    Nous avions donc besoin d’un environnement capable d’exécuter correctement des builds Linux depuis Windows. WSL1 le permettait, mais WSL2 ne partage ni les espaces de noms de processus ni les descripteurs de fichiers, ce qui oblige à recourir à diverses solutions de contournement
    Les performances d’E/S se sont améliorées, mais le partage de fichiers est lent, donc peu adapté à un usage réel

    • Sous WSL2, l’accès aux fichiers Windows reste possible via /mnt/c
    • Une autre piste consiste à combiner clang-cl et xwin à la place de MSVC.
      J’ai déjà compilé des modules d’extension C pour Python de cette manière
  • WSL2 est une VM très étroitement intégrée à l’environnement Windows
    Je l’utilise tous les jours pour le développement parce que la politique de l’entreprise m’impose Windows, et dans la plupart des cas l’expérience est assez confortable

    • Je travaille actuellement dans une VM fournie par l’entreprise, et les performances deviennent de plus en plus pénibles. J’envisage de passer à WSL2.
      En revanche, comme nous sommes sur une base RHEL8, le fait que seules les distributions de type Debian soient prises en charge est gênant. Je me demande aussi où en est aujourd’hui le support des applications graphiques
    • On parle d’« intégration étroite », mais en pratique, dans ps ou top, on ne voit que les processus de la VM.
      On peut obtenir quelque chose de similaire avec docker run -it ubuntu, donc je me demande quelle est la vraie différence.
      Personnellement, cet espace de travail séparé m’a beaucoup dérangé
  • WSL2 est au fond une VM légère. Le concept est proche de Firecracker, avec pour objectif un démarrage rapide et une faible consommation mémoire
    Mais dès qu’on lance plusieurs conteneurs Docker, les besoins en mémoire augmentent. Il faut au moins 20 Go pour être vraiment à l’aise

    • Heureusement, les ordinateurs portables avec 32 Go de RAM ne sont plus aussi chers qu’avant
    • Le démarrage de WSL2 est extrêmement rapide, 1 à 2 secondes. Je me demande comment c’est implémenté. Je comprends qu’ils sautent l’écran du BIOS, mais il semble aussi y avoir d’autres optimisations
  • Personnellement, je trouve WSL1 bien plus utile. La plupart des outils CLI comme les toolchains C++ et .NET, ainsi que ssh/scp, fonctionnent très bien
    À l’inverse, WSL2 ne me sert quasiment à rien. Quand j’ai besoin d’une VM Linux, j’utilise VMware
    VMware offre beaucoup plus de fonctionnalités, comme les arbres de snapshots, l’accélération 3D, la connexion de périphériques USB, la configuration réseau virtuelle, ainsi qu’une interface graphique pratique

  • Le disque de la VM interne à WSL est accessible via le chemin \\wsl$
    Si un ancien logiciel ne prend pas en charge les chemins UNC, on peut contourner le problème en les associant à une lettre de lecteur

  • Il y a un problème où le fichier VHDX continue de grossir. Il faut le compacter manuellement

    • Activer le VHD sparse peut aider. Ce n’est pas parfait, mais le service systemd-trim peut résoudre une partie du problème
      Voir aussi GitHub WSL #12103
      Et si cela ne suffit pas, on peut utiliser cette méthode d’optimisation manuelle
    • Il existe bien une fonction de réduction automatique, mais elle peut parfois causer d’autres problèmes
  • À noter que WSL contourne par défaut les règles du pare-feu Windows. On peut se demander pourquoi Microsoft l’a conçu ainsi

    • Vraiment ? J’ai toujours eu des problèmes avec les connexions ssh depuis WSL
  • Je me demande s’il serait possible de monter une vraie partition ext4 afin de réduire la perte de performances liée à la simulation d’un périphérique bloc basée sur un fichier image

 
tangokorea 2026-04-23

Alors que j’utilise de plus en plus souvent WSL2 et que j’en viens peu à peu à moins utiliser Linux directement, je me demande si ce n’est pas aussi une forme d’EEE.
EEE - adopter, étendre et éliminer (Embrace, Extend, and Extinguish)