Windows Subsystem for Linux (WSL)が msdn Blog でどのように機能するかについて多くの情報を見つけました。 LinuxシステムコールをNTシステムコールにリアルタイムで変換することに基づいているので、変更されていないELFバイナリを実行することが可能です。
WSLはNTサブシステムであり、Microsoft POSIXサブシステム、Windows Services for UNIX(SFU)、およびUnixベースアプリケーション用サブシステム(SUA)/ Interixも同様です。
一方、Cygwinは、Win32サブシステムの上にあるアプリケーションです。
ブログには、SUA用にプログラムを再コンパイルする必要があると書かれています。 SUAは(私が理解しているように)SFUの後継であり、SFUはPOSIXサブシステムの後継です。したがって、必要なすべての再コンパイルされたバイナリも想定しています。
その場合、WSLの前身はCygwinとどのように異なりますか?
前述のシステム/プログラムと、それらが「内部で」どのように機能するかを比較したいと思っています。 (具体的には、WSLが後継とどのように異なるか)
PS:SUでの評判が2に制限されているため、今のところいくつかのリンクを削除する必要があります
Interix/SFU/SUAは軽量のサブシステムであり、serspace Win32レイヤーのみをUnixlibcのようなものに置き換えます。特定のタスク用の「サブシステムドライバー」(psxss)がありますが、それでもWindowsを使用します。 PE(.exe)実行可能ファイル、libcは引き続きNTカーネルシステムコールを使用し、Interixプロセスはほぼ完全にWin32またはネイティブプロセスのように見え、同じファイルシステムアクセスを持っています。
Cygwinは似ていますが、より単純です。それは完全にユーザースペースランタイムライブラリとして構築されています上 Win32の(時折NT呼び出しを伴う)。その結果、Cygwinアプリは、実際には非常に奇妙なlibcを使用するWin32アプリにすぎません。
比較すると、WSLはSUAよりもはるかに広範囲です。Lxssドライバーはユーザースペースライブラリ関数ではなくLinuxカーネルシステムコールを再実装し、変更されていないELFバイナリを実行できます(デフォルトのWSLシステムはストックUbuntuです)。 WSL環境はほとんどが自己完結型であり、実際には「ユーザーモードLinux」仮想マシンであり、ホストOSとの対話はほとんどありません。 WSLプロセスは共有プロセスツリーに表示されますが、/ bin/shを直接実行することはできません。WSLシステム全体をboot実行する必要があります。これは、bash.exe
によって実行されます。シーン。 (それについてのブログ投稿がありました。)
SUA/SFUとInterixに関しては、違いがあります。ウィキペディアはそれをかなりよくそして広範囲に説明しています: Microsoft POSIXサブシステム および Interix
Interixは、POSIXサブシステム上のBSD実装でした。 GNU DebianまたはNetBSD(これは実行されました)のような別の実装に置き換えることができます。SUA(2005)はPOSIXサブシステムを開いたので、NT呼び出しで拡張したり、混合Posixを実行したりすることもできます。/Win32アプリケーション。
残念ながら、マイクロソフトは適切な開発ツールをリリースしたことはなく、サポートを外部委託したことさえありませんでした。ユーザーが開発などで互いに助け合うことができるフォーラムがありました。サポート会社は、さまざまなバイナリパッケージをリポジトリに提供しました。最終的にMicrosoftは資金提供を停止し、サポート会社がフォーラムを閉鎖したときにInterixに関するほとんどすべての情報が消えました。
つまり、SUA Posixアプリケーションは非常に高速で、おそらくWindowsで実行できる最も効率的でした。しかし、NTおよびPosixシステムファイルへのハッキングを伴う開発は面倒でした。つまり、非常に楽しいものでした。