情報源: BASH Running in Ubuntu on Windows

現状わかってきたことをまとめてみます。

出来ること出来ないこと。Ubuntu on Windowsの用途。

BASH Running in Ubuntu on Windowsで出来ること。

• GUIの無いLinuxアプリケーションの実行。
• ELF形式のバイナリファイルを直接実行できる。
• ELF形式のバイナリを開発できる。
• Aptによるアプリケーション管理。
• Windows側ファイルシステムのマウント。
• Windows側から見るとLinux(Ubuntu)のファイルシステムは通常のディレクトリ/ファイルに見える。

BASH Running in Ubuntu on Windowsで出来ないこと。(そう考えることが出来るもの)

• Ubuntu側のシェルからのWindowsアプリケーションの起動、またその逆。
• Ubuntu側LinuxアプリケーションとWindowsアプリケーションとのパイプ、共有メモリ等による連携。SocketやHTTPなら可能だろうけど。
• X Window Systemに依存するアプリケーションの動作。これはServerだけでなくClientも動作できないと考えられる。
• コンソールアプリケーションでもフレームバッファに直接アクセスするなどするアプリケーションの動作。
• 上二つはWindowsの制約からWindowsサブシステム以外グラフィックシステムにアクセスできない制約による。
• Linuxサーバーとしての運用。(これは出来ないというよりやら無い方が良いレベルになるかも)

(実際にUbuntu On Windowsを使えるようになりましたので、こちらで上予測を答え合わせしています。(2016/04/07))

以上のことから考えられる用途。

• Linuxのコンソールアプリケーションの開発。特にVisual C++ for Linux Development Extension使用時にローカルだけで完結できる。
• clangやGo言語等のクロス開発環境のビルド、デバッグ。
• RubyやPHP等のスクリプト言語の開発とデバッグ用途。

そもそもWindowsを開発者モードに設定しないと使用できないので、開発者向けの利便性向上というのが目的ですし、そういう用途でしか実質使えないでしょう。

Ubuntu on Windowsの作られかたから、シェル内でそれぞれのアプリケーションと共存が出来ないので現状のCygwinやmsys2、GOWのような使い方も出来なさそうです。同じような作られ方をしているService For Unix(SFU)がシェル内でそれぞれのアプリケーションを普通に実行できたのは、SFUの実行ファイルがWindowsと同じ形式だったので、ローダーが対応できたからです。

Ubuntu on Windowsの仕組み

図2-1

上の図がMSから出てきました。Windows Subsystem for Linuxというものが作られ、それがLinuxカーネルの代わりとして動作し、その上でUbuntuのユーザーランドが動作する仕組みです。

ただ、この図2-1を見たときに非常に私は違和感を感じます。なんでサブシステムがカーネル側になってるんだってところです。本来Windowsサブシステムはユーザーモードで動作しているはずです。WindowsのOSとしてのソフトウェア構成に詳しい方で有れば同様の違和感をお持ちになるかと思います。ただの図の書き方かもしれませんが違和感がありますね。

そこはともかく、Windows Subsystem for LinuxがWindowsのカーネルがもつシステムコールをLinuxカーネルのシステムコールに変換しているわけです。この変換の仕組みはWindowsサブシステムとWindowsカーネルの間でも基本的に同じです。そう、Windowsアプリケーションといえども直接Windowsカーネルが持つシステムコールを直接使用しているわけでは無いのです。

Windowsサブシステム(環境サブシステム)

現在のWindows 10はWindows NTをルーツに持ち、Windows 3.1やWindows 95をそのルーツとしていません。それらとは全く違うOSです。そしてWindowsがサブシステムという仕組みを持つに至ったのは、Windows NT開発時のマイクロソフト社(MS)の置かれたビジネス的な状況が影響しています。Windows NT開発時MSは自社ブランドの製品であるMS-DOS, Windows, Lanmanagerと他にIBMと共同でi286以上の16bit/32bit CPUを対象としたプリエンプティブマルチタスクOSだったOS/2をエンタープライズ用途向けに開発していました。このOS/2のメジャーアップデートに向けて、MSはGUIとして当時人気の出てきたWindowsベースのGUIを載せようと考えていましたが、IBMは自分たちの戦略があり、メインフレームからPCまで統一されたGUIを提供しようとしていました。またMSはIBMの戦略を知ってOS/2とは別にWindowsのGUIを持ったエンタープライズ向けのOSを開発を始めました。これがWindows NTとなります。結局Windows NTの開発を知ったIBMが激怒したこともあり、両者は仲違いしてMSはOS/2の開発から身を引いてWindows NTの開発に専念します。

しかしながら、OS/2はMSのブランドでIBM PC以外にも移植され販売されていましたし、企業ユーザーを中心に既にそれなりの数のOS/2アプリケーションをユーザーが抱えていました。また、非常に有力なエンタープライズの顧客として米国政府がありましたが、政府調達基準としてOSとしてPOSIXへの対応が求められていました。MSとしてはビジネスとして新OSを順調に立ち上げるためにはそうした顧客への対応が必要でした。

こうしたビジネス的要求があり、Windows NTはOSとして複数のOSのAPI(システムコール)に対応する必要が産まれてしまいました。その要求に応えるために生まれたのがWindowsサブシステムの仕組みです。複数のOS APIに対応するため本来のWindows NTのシステムコールとユーザーアプリケーションに提供するシステムコールとを分離し、後者はユーザーモードで動かす二階建ての構造とすることで、Windows NTの中でWin32アプリケーションや、OS/2のアプリケーションが動作する事を実現しました。この二階建ての構造はメインのWin32 APIとしてぼくらが知っているWindowsサブシステムも例外では無いのです。つまり、初めからWindowsは複数のOSのシステムコールをエミュレーションする仕組みを持っていたのです。

図2-2 インサイドMicrosoft Windows 第4版 上 第2章から引用

上の図2-2がWindowsのソフトウェア構成になります。WindowsはLinuxのモノリシックカーネルと違いマイクロカーネルアーキテクチャなので、カーネル機能は複数のモジュールから構成され、システムサービスディスパッチャと言う仕組みを通してユーザーモードで動作するアプリケーションとやりとりをします。一方ユーザーモード側でシステムサービスディスパッチャのスタブとして動作するがNTDLL.DLLとなり、原則的に各OS機能をユーザーアプリケーションに提供するサブシステムもこのNTDLL.DLLの上で動作します。(このあたりの詳細を知りたい方はぜひインサイドMicrosoft Windowsをお読みください)

さて、ここまでの説明で再び図2-1を確認しましょう。Windows Subsystem for Linuxの位置がおかしいとは思いませんか？本来サブシステムはユーザーモードで動作するはずですよね。めんどくさいのでLinuxユーザー側にわかりやすい図にしたって言う理由もありそうですが、本当にこの図2-1が正しいなら、何か今までに無いすごいことが起きているのでは無いかって言う感じもしています。実際のところはどうなんでしょう。

まとめ

動くものが手元にも無いし、MSからちゃんとした説明も無い以上、何を書こうが憶測以上では無いのですが、WindowsのOSとしての構成としてあまりVista以降大きな変更がなくてつまらないなと感じていたところ、ここに来て何かやっているかもという事でわくわくしている次第。IotやMobileとのカーネル共通化もあってあれこれやっているはずなので、ぜひ夏のアニバーサリー以降にこの件含めて詳細なペーパーがMSから出てくることや、Inside Windowsの新版出版とかも期待したいところです。

[amazonjs asin=”B00KWZNAYG” locale=”JP” tmpl=”Small” title=”インサイドWindows　第6版　上”]

[amazonjs asin=”4822294714″ locale=”JP” tmpl=”Small” title=”インサイドWindows 第6版 下”]