Everything about WSL 1 you want to know
關於 WSL 1 入門，你應該知道這些
如有錯誤，歡迎指出
參考：
概述
通過 WSL 2 來認識 WSL 1
什麼是 WSL 2？
WSL 2 是適用於 Linux 的 Windows 子系統體系結構的一個新版本，它支援適用於 Linux 的 Windows 子系統在 Windows 上運行 ELF64 Linux 二進位文件。 它的主要目標是提高文件系統性能，以及添加完全的系統調用兼容性。
這一新的體系結構改變了這些 Linux 二進位文件與Windows 和電腦硬體進行交互的方式，但仍然提供與 WSL 1（當前廣泛可用的版本）中相同的用戶體驗。
單個 Linux 分發版可以在 WSL 1 或 WSL 2 體系結構中運行。 每個分發版可隨時升級或降級，並且你可以並行運行 WSL 1 和 WSL 2 分發版。 WSL 2 使用全新的體系結構，該體系結構受益於運行真正的 Linux 內核。
比較 WSL 1 和 WSL 2
WSL 2 使用最新、最強大的虛擬化技術在輕量級實用工具虛擬機 (VM) 中運行 Linux 內核。 但是，WSL 2 不是傳統的 VM 體驗。
比較功能
| 功能 | WSL 1 | WSL 2 |
|---|---|---|
| Windows 和 Linux 之間的集成 | ✅ | ✅ |
| 啟動時間短 | ✅ | ✅ |
| 佔用的資源量少 | ✅ | ✅ |
| 可以與當前版本的 VMware 和 VirtualBox 一起運行 | ✅ | ✅ |
| 託管 VM | ❌ | ✅ |
| 完整的 Linux 內核 | ❌ | ✅ |
| 完全的系統調用兼容性 | ❌ | ✅ |
| 跨 OS 文件系統的性能 | ✅ | ❌ |
從上述比較表中可以看出，除了跨作業系統文件系統的性能外，WSL 2 體系結構在多個方面都比 WSL 1 更具優勢。
WSL 2 中的新增功能
完整的 Linux 內核
WSL 2 中的 Linux 內核是 Microsoft 根據最新的穩定版分支（基於 kernel.org 上提供的源程式碼）構建的。此內核已專門針對 WSL 2 進行了調整，針對大小和性能進行了優化，以便在 Windows 上提供良好的 Linux 體驗。 內核將由 Windows 更新提供服務，這意味著你將獲得最新的安全修補程式和內核改進功能，而無需自行管理它。
提升了文件 IO 性能
如果使用 WSL 2，文件密集型操作（如 git 克隆、npm 安裝、apt 更新、apt 升級等）的速度都明顯更快。
完全的系統調用兼容性
Linux 二進位文件使用系統調用來執行訪問文件、請求記憶體、創建進程等功能。 雖然 WSL 1 使用的是由 WSL 團隊構建的轉換層，但 WSL 2 包括了自己的 Linux 內核，具有完全的系統調用兼容性。 優點包括：
- 可以在 WSL 內部運行的一組全新應用，例如 Docker 等。
- 對 Linux 內核的任何更新都立即可供使用。 （無需等待 WSL 團隊實現更新並添加更改）。
在啟動時使用的記憶體量更少
WSL 2 在實際 Linux 內核上使用輕量級實用工具 VM，記憶體佔用量很小。 該實用工具將在啟動時分配虛擬地址支援的記憶體。 它已經過配置，在啟動時使用的記憶體佔比小於 WSL 1 所需的記憶體佔比。
WSL 1 會被棄用嗎？
我們目前沒有計劃棄用 WSL 1。 你可以並行運行 WSL 1 和 WSL 2 發行版，還可以隨時升級和降級任何發行版。
WSL 2 與 VMware
WSL 2 使用 Hyper-V 體系結構來實現其虛擬化。
衝突與兼容
ref1
VMware Workstation 15.5.5 Pro 發行說明 在「新增功能」中指出：
支援 Windows 10 主機 VBS： 現在，VMware Workstation 15.5.5 可在啟用了 Hyper-V 功能（例如：基於虛擬化的安全性）的 Windows 主機上運行。
ref2
VMware Workstation Pro 產品文檔 在「在啟用了 Hyper-V 的主機上運行 Workstation」中指出：
傳統的 Workstation Pro 實施依賴於對 x86 微處理器特定硬體功能的直接訪問。
這些功能（通常稱為 Intel VT 或 AMD-V）也由支援 Hyper-V 的最新版本的 Windows 使用，所以無法在啟用了 Hyper-V 功能的 Windows 主機上運行傳統 Workstation Pro。
在其子項「主機 VBS 模式與 Windows 版本的兼容性」中，說到：
在啟用了 Hyper-V 的具有適當功能的 Windows 10（或更高版本）主機上啟動 Workstation Pro 時，將自動啟用主機 VBS 模式。
如果禁用 Hyper-V， Workstation Pro 將以其傳統模式運行。如果啟用 Hyper-V，但 WHP 功能版本不夠新或未安裝， Workstation Pro 將無法啟動。
另外，與在傳統模式下運行的 Workstation Pro 虛擬機相比，在主機 VBS 模式下運行的虛擬機存在一些功能限制。（參見子項「主機 VBS 模式的限制」）
ref3
在VMware Workstation 15.5 Now Supports Host Hyper-V Mode中，有關於 Hyper-V 與 VMM 的更詳細的說明。如：
- 解釋了為何舊版本的 Workstation 無法在啟用了 Hyper-V 功能的 Windows 10 主機上運行：
How does VMware Workstation work before version 15.5.5?
VMware Workstation traditionally has used a Virtual Machine Monitor (VMM) which operates in privileged mode requiring direct access to the CPU as well as access to the CPU』s built in virtualization support (Intel』s VT-x and AMD』s AMD-V). When a Windows host enables Virtualization Based Security (「VBS「) features, Windows adds a hypervisor layer based on Hyper-V between the hardware and Windows. Any attempt to run VMware』s traditional VMM fails because being inside Hyper-V the VMM no longer has access to the hardware』s virtualization support.
- 如何處理了這個兼容性問題：
Introducing User Level Monitor
To fix this Hyper-V/Host VBS compatibility issue, VMware』s platform team re-architected VMware』s Hypervisor to use Microsoft』s Windows Hypervisor Platform (WHP) APIs. This means changing our VMM to run at user level instead of in privileged mode, as well modifying it to use the WHP APIs to manage the execution of a guest instead of using the underlying hardware directly.
另外，也說到：
If you don』t use Hyper-V at all, VMware Workstation is smart enough to detect this and the VMM will be used.
這正好呼應了上面「主機 VBS 模式與 Windows 版本的兼容性」中的內容。
ref4
在 WSL 2 FAQ 中，問題 我是否能夠運行 WSL 2 和其他第三方虛擬化工具 的回答，也提到了關於這一兼容問題的解決：
我們一直在開發解決方案以支援 Hyper-V 的第三方集成。 例如，我們向第三方虛擬化提供商公開了一組稱為虛擬機監控程式平台的 API，可以用來使其軟體與 Hyper-V 兼容。 這使得應用程式可以將 Hyper-V 體系結構用於其模擬。
小結
總而言之，15.5.5 之後，在使用了 WSL 2、Docker for Windows 的同時，仍可以使用 Workstation。但在虛擬機性能上，會有些損耗；另外，也無法再使用嵌套的虛擬化（已知問題）。
所以我選擇使用：
WSL 1 + Workstation 15.5.2
VMware 官方只提供每個主版本的最新版本的下載，所以要想下載 15.5.2，只能另尋門路了。
WSL 1 的使用
開啟功能支援
- 打開「控制面板」
- 打開「程式和功能」
- 在窗口左側，打開「啟用或關閉 Windows 功能」
- 選中「適用於 Linux 的 Windows 子系統」
- 點擊「確認」
文件系統
概述
WSL 必須將各種 Linux 文件系統操作翻譯成 NT 內核操作，為此，WSL 仿照 Linux 下的 VFS，設計了一個 VFS 組件。下圖展示了它的架構：
VFS 定義了多個文件系統插件：用於展示硬碟中文件的 VolFs 和 DrvFs，記憶體中的文件系統 TmpFs，以及偽文件系統，如 ProcFs，SysFs，和 CgroupFs。
VolFs 被設計用來提供對 Linux 文件系統特性的完全支援；DrvFs 被設計用來與 Windows 交互。
如今通過執行
mount命令，將會發現 VolFs 已經消失了，取而代之的是 WslFs。至於 WslFs 是什麼，網上並沒有搜到太多有價值的資料。
文件許可權
參見
Linux 文件的許可權資訊作為額外的元數據，在默認的掛載中是不被支援的。這也就意味著，如 Chmod/Chown 這樣的命令實際上不會起到任何作用。對於沒有元數據的文件，WSL 根據 Windows 下文件的「屬性-安全」資訊來推測該文件在 WSL 中的許可權。
為此，WSL 團隊針對 DrvFs 引入了掛載選項 metadata，以對文件和目錄提供 Linux 元數據支援。這將在 Windows NT 文件上添加擴展屬性，並對其進行解釋，以提供 Linux 文件系統許可權。
啟用了元數據後，新創建的文件將帶有默認的元數據，並且同一文件在 Windows 和 Linux 下的許可權也將不再保持同步，但注意，同一文件在 WSL 下的訪問許可權不能多於其在 Windows 下具有的訪問許可權。
另外，可以通過掛載選項來設定初始許可權，這些選項有：
- 指定文件的用戶 ID 的
uid - 指定文件的組 ID 的
gid - 用於設置許可權掩碼的：
- 應用於所有文件的
umask - 只應用於目錄的
dmask - 只應用於文件的
fmask
- 應用於所有文件的
實例如：
sudo mount -t drvfs C: /mnt/c -o metadata,uid=1000,gid=1000,umask=22,fmask=111
關於許可權掩碼，需要知道，文件的默認許可權為 666，目錄的默認許可權為 777，而後與掩碼進行計算，才最終得到真正的默認許可權（或者說」初始許可權「更準確）。
掛載移動存儲
參見 File System Improvements to the Windows Subsystem for Linux
WSL 只會在啟動時自動掛載固定的 NTFS 驅動器；同時，也允許用戶手動掛載系統中存在的任意驅動器。
這意味著，對於可在 Windows 中訪問到的任何存儲，包括 removable USB sticks or CDs, and any network location等，都同樣可在 WSL 訪問到。
以掛載可移動驅動器 D: 為例，執行如下命令以掛載：
sudo mkdir /mnt/d
sudo mount -t drvfs D: /mnt/d
執行如下命令卸載：
sudo umount /mnt/d
不過要注意的是，對於 FAT 格式的可移動介質，DrvFs 表現為不支援硬鏈接和符號鏈接，同時對大小寫不敏感。
高級操作
命令行參考
運行 Linux 命令
-
不帶參數
啟動默認發行版，使用默認的 shell
-
--distribution, -d <Distro>運行指定的發行版
-
--user, -u <UserName>以指定用戶的身份運行
-
--exec, -e <CommandLine>執行指定的命令，但不使用默認的 Linux shell
我不知道這到底意味著什麼。
在執行
wsl -e printenv後，我看到SHELL被設置為printenv； -
--按原樣傳遞剩餘的命令行
管理 WSL
-
--set-default, -s <Distro> -
--unregister <Distro> -
--list, -l-
--all -
--running -
--quiet, -q只顯示分發名稱。
-
--verbose, -v
-
-
--export <Distro> <FileName>將該分發版導出為 tar 文件。
-
--import <Distro> <InstallLocation> <FileName>從 tar 文件中導入分發版，Distro 用於命名該分發版，InstallLocation 指定了安裝位置。
-
--version <versionNumber>指定用於新分發的版本（WSL 1 or 2）。
-
-
--set-default-version <versionNumber>更改新分發的默認安裝版本。
-
--set-version <Distro> <versionNumber>更改指定分發的版本。
-
--shudown終止所有分發。
-
--terminate, -t <Distro>終止指定分發。
忘記了密碼
- 使用命令
wsl [-d distribution] -u root進入分發版根目錄； - 使用
passwd <WSLUsername>重置密碼。
取消註冊和重新安裝
使用 wsl --unregister <Distro> 註銷一個分發版後，與該分發關聯的所有數據、設置和軟體都將永久丟失。也就是說，wsl -l 不會再列出該分發，硬碟中也不再有該分發相關的文件。
但注意，通過 Microsoft Store 安裝的分發在註銷後，仍可在 Win 應用列表中看到，這時右擊圖標，卸載即可。若要重新安裝以獲取原始副本，那麼左擊該圖標即可，或者運行 bash 或 wsl 命令。
移動（導出和導入）
WSL 默認將發行版存儲在系統盤，且無法在資源管理器中直接訪問到其文件。對於默認的安裝，在啟動了一個分發後，可以在命令行中執行explorer.exe .以在資源管理器中訪問其文件，或直接在資源管理器地址欄中輸入\\wsl$，即可看到該分發。
可以結合使用 wsl.exe 的 --export 和 --import 選項來移動一個分發，而後便可在資源管理器中對其進行直接訪問，即便該分發沒有在運行中。
-
導出默認分發
wsl --export <DefaultDistro> \path\to\defaultDistro.tar -
（可選）註銷默認分發
wsl --unregister <DefaultDistro> -
導入分發
wsl --import <DistroName> <FSLocation> \path\to\defaultDistro.tar -
（可選）設置新位置的分發為默認分發
wsl -e <DistroName>
不過，這樣會使的該分發的默認用戶變為 root，對此，可使用 wslconf 該配置默認用戶。
在 WSL文檔 中，給出了「更改分發默認用戶」的方法：
<DistributionName> config --default-user <Username>但這僅適用於從 Store 獲取到的分發，對於自行導入的分發無效。
啟動配置
通過 wslconf 配置每個發行版
每個發行版在啟動時會檢測 /etc/wsl.conf 是否存在，如果存在且格式正確，則讀取其內容。
wsl.conf 遵守 .ini 約定（除了注釋，使用#，而非;），支援的節（section）有：automount、network、interop、user。
一個例子：
[automount]
options = "metadata,umask=22,fmask=11"
[user]
default = "w" # Set default user
使用 wslconfig 進行全局配置
該配置文件位於用於根目錄下，一般為C:\Users\<yourUserName>\.wslconfig。
這個配置文件主要是和 WSL 2 有關的，有效節為wsl2。
