一段时间以来，微软一直试图将全栈开发人员吸引到Windows。直接在Windows上运行Linux二进制代码的Windows Subsystem for Linux（WSL）可以说开了个好头，颇受欢迎。350万活跃的开发人员在使用WSL，它因每六个月更新一次的Windows 10而得到改进，比如能够同时安装和使用多个Linux发行版，能够从Windows编辑Linux文件而不损坏文件。但这还不足以提供全面兼容性。
因此针对6月份Windows Insiders将可以使用的下一个版本，微软正转向在Windows中运行正宗的Linux 4.19内核以支持Linux二进制代码。
WSL 2承诺对文件IO性能进行亟需的改进，另外增添对Docker的原生支持，以简化Linux容器的使用。但它也可以在Windows上实现全面的Linux兼容性，因此成为Windows所能实现的重大转变。
Windows开发者平台的企业副总裁Kevin Gallo对IT外媒The New Stack说：“WSL是许多Web开发人员在Windows中用时颇多的组件。现在我们拥有了纯粹的Linux内核，因此你获得的兼容性高得多。”
Gallo说：“文件性能向来是开发人员抱怨的一大问题，我们在解决这个问题。我们正在对Windows上的Linux容器（LCOW）进行重大改进，性能和兼容性均有明显提升。你不需要虚拟机就能运行Linux版本的Docker，因而可以减少占用的内存，提高执行速度，并缩短启动时间。LCOW过去有点笨拙，但一旦我们得到原生的Docker支持，它运行起来就变得很顺畅。作为开发人员，你可以尽可能接近生产环境，在WSL上运行Docker，并直接在上面进行调试。”
WSL 2是如何工作的？
Windows容器和虚拟化的首席项目经理Taylor Brown向The New Stack解释道：“从体验和用户的角度来看，顾名思义，WSL 2只是更好的WSL，”但它的工作方式截然不同。
“WSL将Linux系统调用转换成相应的Windows API，而WSL 2运行非常轻量级的Hyper-V VM（与我们用于Hyper-V隔离容器的是同一种类型），它有正宗的Linux内核，因此不必进行系统调用转换。它解决了许多顶级功能请求（文件系统性能和ABI兼容性），并使我们踏上一条便于以后解决更多请求的架构路径。”
WSL 2有赖于微软为了使Windows上的Linux容器（常常名为LCOW）在Azure上顺畅运行而做的工作。“轻量级Hyper-V VM、9P文件系统桥甚至内核都是从我们与Azure中的LCOW一起使用的内核中大量借用过来的。9P是一种为Plan 9分布式操作系统开发的协议，用于为WSL桥接Windows文件系统和Linux文件系统。
如果你与WSL一起使用多个Linux发行版，每个发行版将在各自的虚拟机中运行。Brown说：“然而，这些虚拟机使用虚拟分配的内存，启动不到一秒，而停止的速度更快，因此体验和开销是WSL级的（或甚至更好）。”
性能将优于WSL，对文件而言更是如此。“Linux的IO模式与Windows完全不同，NTFS是针对Windows优化的；NTFS在大文件IO方面非常出色，因此适合数据库，而ETX4适合较小的IO。在WSL 2中，Linux文件系统现在只是直接在虚拟pmem设备上使用EXT4，因此我们在Linux端获得Linux原生文件系统性能，在Windows端获得Windows原生文件系统性能（集两者之众长）。通过9P桥，我们可以将两者连接起来，获得出色的集成体验。”
使用WSL 2
尽管有这些变化，对于使用和bash及其他Linux工具的开发人员来说，体验与今天的WSL一样。Brown证实：“开发人员喜欢从WSL获得的功能（比如共享文件/文件夹）通过使用9P协议的文件系统桥得到全面维护，因此WSL 2可以看到你的所有Windows文件和文件夹，你也可以从Windows看到Linux挂载的对象。”
计划任务（cron job）和持久性守护进程的工作方式将与目前的WSL一样，但网络套接字会有一些变化，这方面仍处于开发之中。“由于我们使用虚拟机，现在WSL 2中有NIC（网卡）。我们使用NAT网络模式，以便NIC由主机全面管理和协调，但它确实有自己的IP地址。我们现正在致力于自动映射套接字，以便体验与WSL一样；但我们认为，就预览版而言，目前的体验在情理之中，给了我们非常宝贵的反馈意见。”
WSL 2使Windows全面兼容Linux，至少在内核ABI层是这样，不过微软将目光投向开发者社区，搞清楚WSL中应包含哪些内核模块。Brown解释道：“在WSL中用不了的iSCSI目标（target）在WSL 2中用得了，但需要添加适当的模块。”
WSL 2最初通过Insider体验计划适用于Windows 10，因此开发人员可以尝试一下，就内核模块等功能方面给予反馈。Brown特别指出，准备推出正式版之前，除了网络套接字的自动映射外，9P性能方面还有一些工作要做。
计划是及时将WSL 2引入到Windows Server，这两种操作系统上的Linux内核将像其他Windows组件一样自动更新和维护。由于Hyper-V的嵌套虚拟化技术，你能够在Azure上的虚拟机中使用WSL 2；虽然WSL 2本身基于为Azure所做的LCOW工作，但无法被Azure平台使用。
Visual Studio Code和WSL 2
Docker等工具将能够增强WSL 2。Brown说：“今天，Docker Desktop创建并管理自己的Linux虚拟机；由于这种体验，它们将能够直接使用WSL 2，以提升性能和可靠性。”
借助面向WSL和Docker容器的Visual Studio Code，原生Docker支持还将简化远程调试。新的远程开发扩展包（RDEP）将在Visual Studio Code可以连接的目标环境中运行一套开发服务，那些服务负责安装在远程环境而不是在本地Windows环境中运行的工作区扩展，因此它们可以检测什么语言和运行时环境可以使用，在IDE中提供适当的代码完成和代码检查（linting）。
Gallo解释道：“Visual Studio Code远程调试让你可以直接连接到现有容器，而今天Windows上的Visual Studio Code可以在Windows中针对node.js来运行，但不是针对WSL来运行。如果你在Linux环境中启动Visual Studio Code，它将调试Linux环境；在启动虚拟机之前，它现在直接连接到启动它的环境。”Visual Studio Code命令和扩展直接在启动它的Linux发行版中运行，因此开发人员不必担心路径问题，你在WSL和已挂载的对象中都可以编辑文件。
这是Visual Studio Code用户一直要求的功能；Visual Studio Code存储库中评论第三多的问题是支持在WSL中从bash启动IDE，它与目前版本的WSL和WSL 2兼容。
Windows桌面上的Linux
微软最初想把Linux二进制支持功能引入到Windows时，WSL 2依赖的容器支持功能还没有出现，因此团队不得不先将Linux系统调用支持添加到面向WSL的Windows内核。Brown特别指出，这种方法始终存在一些缺点。
“我们在系统调用转换方法方面遇到的问题之一是，要始终关注Linux内核来创建新的转换机制；更具体地说，一些系统调用很难搞对，将来会出现不可能搞对的系统调用。由于我们现在直接运行Linux内核，这种架构不用担心这个问题，但我们运用了当初为Hyper-V隔离容器采取的大量创新后才真正实现了这个概念。”
如果WSL 2的新方法提供了微软承诺的全面兼容性和显著的性能改进，它将使Windows成为对任何开发人员而言极具吸引力的平台，无论他们在何种平台上从事开发。
实际上，Gallo认为WSL 2将为开发人员提供比在Mac上更好的Docker支持，因为他们不需要考虑亲自运行Linux虚拟机。他表示，WSL 2有望使Windows成为开发人员为需要构建的任何云工作负载而积极采用的操作系统，而不仅仅是针对Windows平台编程时所使用的操作系统。
“除了新终端中的所有改进以及在新的Edge浏览器中开发基于Chromium的网站从而支持前端企业开发外，我们认为相比其他任何环境，端到端体验对于开发人员来说将是最高效的环境。”
