Microsoftは、Windows用のLinuxサブシステムをLinux用のWindowsサブシステム（WSL）と呼びます。 今日、同社はWSL実装の新しい技術詳細を公開しました。 前に、Windows 10（NT）のサブシステムモデルと、LXss.sysおよびLXCore.sysドライバーを介してWindowsカーネルレベルでWSLを実装する方法について説明しました。 元のWindowsカーネルモデルでは、上位レベルのコンポーネント（ntdll.dll-Win32など）が拡張カーネルインターフェイスによりシステムコールのセマンティクスを使用できるため、WSLのWindows環境での実装に問題はありません。
図 ディレクトリ内のファイルのリストを取得するためのサービスの実装の例。 カーネルモードLXss.sysドライバーは、これを可能にするntoskrnl！NtQueryDirectoryFile拡張カーネルインターフェイスを使用して、lsコマンドのセマンティクスを実装します。 ntdll.dllコンポーネントは、Windowsサブシステムに対して同じ操作を実行し、 ntoskrnl！NtQueryDirectoryFileに直接アクセスします（右側）。
興味深い機能は、新しいサブシステムにLinuxシステムコールを実装することです。この機能は、Linuxプログラムを実行する際の最も重要な操作であるためです。 システムサービスは、OSで基本的なアクションを実行し、引数を渡すカーネル関数の呼び出しです。 このようなアクションには、ファイル、プロセス、ネットワークなどの操作が含まれます。サービスを呼び出すには、 syscallというマイクロプロセッサ命令が使用されます 。これは、制御をカーネルモードに転送し、サービスコントロールマネージャを呼び出します。
Microsoftは、システムサービス呼び出し規則をApplication Binary Interface（ABI）として呼び出します。 ABI for WSLの機能は、Windowsで使用されるものと完全には一致しないことです。 以下は、同じ操作の場合にシステムサービスに引数を渡す場合の違いです-Linuxの getdents64サービスとWindowsのNtQueryDirectoryFile 。 Linuxサービスの引数の説明はこちらです。
図 LinuxとWindowsのABIの違い。
違いは、WindowsおよびLinuxで使用されるレジスタと、 raxレジスタで送信する必要があるシステムサービスの数の両方にあります。 この違いは上記の表に示されていますが、ABIの他のステップは同じですが、両方のサービスの引数がレジスタに配置され、 syscall呼び出しが行われます。 もう1つの違いは、LinuxおよびWindowsサービスによって返されるステータスです。 Windowsは特殊な負の定数NTSTATUSを使用しますが、Linuxは実行された操作のステータスに番号を付けるために異なるシステムを使用します。 WLSシステムサービスを呼び出した後、制御がWindowsシステムサービスマネージャーに転送され、対応するセマンティクスを実装するLXss.sys要求が変更されずに送信されます。
LXss.sysドライバーは、追加のセマンティクスを提供せずにWindowsシステムサービスを単に呼び出すことができます。 これは、両方のオペレーティングシステムで実装セマンティクスが同じサービスに適用されます。 たとえば、Linuxのsched_yield関数は、同じセマンティクスを持つZwYieldExecutionというWindowsサービスに対応しています。 この関数は、別のスレッドが使用するマイクロプロセッサーを転送するようカーネルに指示します。 WLSは追加のアクションを実行せず、単にZwYieldExecutionを呼び出します 。 他の場合、たとえば、チャネルの操作（パイプ）およびプロセスの分岐のための関数を実装する場合、LXss.sysは、Windowsカーネルを同期する基本的な関数およびプリミティブに基づいて、対応するセマンティクスを実装します。