更新时间：2023-09-25 16:34
WSL是Windows Subsystem for Linux的简称，它是Windows的一项功能，可用于在Windows计算机上运行Linux环境，而无需单独的虚拟机或双引导。WSL旨在为希望同时使用Windows和Linux的开发人员提供无缝高效的体验。该功能集成了Windows和Linux，与传统的虚拟机相比，同时启动两个操作系统时，所需的资源（CPU、内存、存储）更少。WSL必须在Windows 10版本2004及更高版本（内部版本19041及更高版本）或Windows 11才能使用。
2016年8月，微软在Windows 10上推出WSL,使用的是现在称为“WSL1”的体系结构。WSL1作为一个转换层运行，在Windows内核上使用一个Linux内核接口。可将WSL1视为一个兼容层，用于模拟在Windows环境中运行Linux二进制文件的系统调用。2019年5月，微软发布了WSL2。WSL2引入了对WSL体系结构的重要更改，包括在一部分Hyper-V功能中使用真正的Linux内核。WSL2现在是在Windows上安装Linux分发版时使用的默认体系结构。
WSL提供了一个微软开发的Linux兼容内核接口（不包含Linux代码），来自Ubuntu的用户模式二进制文件在其上运行。
该子系统不能运行所有Linux软件，例如那些图形用户界面，以及那些需要未实现的Linux内核服务的软件。不过，这可以用在外部X服务器上运行的图形X Window系统缓解。
此子系统起源于命运多的Astoria项目，其目的是允许Android应用运行在Windows 10 Mobile上。此功能组件从Windows 10 Insider Preview build 14316开始可用。
在设计之初，微软就允许类似于win32这种子系统运行于windows NT内核之上，它可以为上层应用提供编程接口，同时避免应用去实现内核里的一些调用细节。NT内核的设计在最开始就可以支持POSIX，OS/2和win32子系统。
早先的子系统是用户态模块的实现，它封装了NT系统的系统调用为应用程序提供编程接口。所有的应用程序都是PE/COFF（一些为子系统封装NT系统调用的库和服务）可执行的。当一个用户态的程序启动的时候，启动器就会基于可执行的头部去引用适当的子系统来满足应用程序的依赖。
后来版本的子系统替换掉了POSIX层，由用户态组件提供了Subsystem for Unix-based Applications (SUA)，满足：
1.进程和信号管理
2.终端管理
3.系统服务请求和进程间通信
SUA的主要目的是为了鼓励应用程序移植到Windows上能尽量少的重写。这已经通过实现POSIX用户态API达到了。考虑到这些组件是用户态实现，很难跟内核态的系统调用（比如fork()）在语义上和效率上完全相对应。因为这种模式需要程序重新编译，它需要持续的功能移植，维护也是负担。
随着时间的演变，这些早先的子系统都退出历史舞台了。但是因为WIndows NT内核的架构允许新的子系统环境，我们就基于这领域的原始积累进行扩展，发展Windows Subsystem for Linux。
Windows Subsystem for Linux
WSL是一些组件的集合，允许原生的Linux ELF64二进制文件跑在Windows上。它同时包括了用户态和内核态组件，主要包含以下部分：
1.用户态会话管理服务处理Linux实例的生命周期
2.PICO provider drivers (lxss.sys, lxcore.sys)“翻译”系统调用，以模拟Linux内核
3.Pico进程管理原生的用户态Linux（比如/bin/bash)
奇迹就发生于用户态的Linux二进制文件和Windows内核组件之间。通过将未经修改的Linux二进制文件放置于Pico进程中，我们把Linux系统调用直接导入Windows内核中。lxss.sys,lxcore.sys驱动将Linux系统调用翻译为NT APIs，来模拟Linux内核。
作为Project Drawbridge的一部分，Windows内核引入了Pico进程和Pico驱动的概念。Pico进程和驱动提供了Windows Subsystem for Linux的基础。可执行的ELF二进制文件被加载到Pico进程的地址空间，并在系统调用的Linux兼容层上执行。
WSL基于Windows NT内核虚拟了Linux内核接口，这允许它执行未经修改的Linux ELF64二进制文件。一类内核接口是系统调用。系统调用是内核为用户态程序提供的一种服务。Linux内核和Windows NT内核都为用户态程序提供了几百个系统调用，但是他们有不同的语义，并且一般来说并不直接兼容。比如Linux提供fork, open和kill，Windows NT提供相兼容NtCreateProcess, NtOpenFile和 NtTerminateProcess。
Windows Subsystem for Linux 包含内核态驱动（lxss.sys和 lxcore.sys），以协调Linux系统调用的请求与Windows NT内核。驱动不包含Linux内核代码，但是是一个全新实现的Linux兼容的内核接口。在原生的Linux上，用户态程序请求一个系统调用，系统调用请求由Linux内核处理。在WSL，当一个系统调用由同一个可执行文件请求时，Windows NT内核把请求发送给lxcore.sys。当可能时，lxcore.sys将Linux系统调用翻译成等价的Windows NT的调用，由它来完成繁重的工作。当没有可能的等价转换时，Windows内核态驱动需要直接处理请求。
比如说，Linux中的fork()系统调用没有直接的等价的windows版本。当一个fork系统调用由Windows Subsystem for Linux产生时，lxcore.sys需要做一些复制进程的准备工作，然后调用Windows NT内核APIs来产生一个进程来正确实现fork操作，完成为新进程复制额外的数据。
WSL支持的文件系统需要满足两个目标。
1. 提供一个完全支持Linux文件系统的环境
2. 能够与Windows上的设备和文件互通
Windows Subsystem for Linuxt提供与真实Linux内核类似的虚拟文件系统。在用户的系统上，我们提供了两个文件系统：VolFs 和 DriveFs。
VolFs提供了完整的Linux文件系统特性的支持，包括：
1. Linux权限管理，访问权限可以通过如chmod和chroot来改变
2. 文件的符号链接
3. 文件名可以包含一些Windows上不合法的符号
4. 大小写敏感
包含Linux系统的目录，应用程序文件（/etc, /bin, /usr等）和用户Linux家目录都使用的是VolFs。
与Windows应用和文件的互用在VolFs里并不支持。
DriveFs是为了和windows互用的文件系统。它需要所有的文件名是合法的windows文件名，使用Windows安全策略，并不完整地支持所有的Linux文件系统特性。文件名是大小写敏感的，用户不允许创建仅仅是大小写不同的两个文件。
所有的Windows磁盘使用DriveFs被挂在到/mnt/，/mnt/d等等下面。用户从这里可以访问所有Window下的文件。这允许用户用他们喜欢的Windows编辑器比如Visual StudioCode来编辑文件的同时，通过Bash里的一些开源工具来修改文件。