「WSL」カテゴリーアーカイブ

Announcing Windows 10 Insider Preview Build 14366 & Mobile Build 14364

Hello Windows Insiders! WOW, what a week. You all were on fire last week with the all of the feedback for the double dose of PC + Mobile. I also appreciated you sharing your career/business goals w…

情報源: Announcing Windows 10 Insider Preview Build 14366 & Mobile Build 14364

だんだんアニバーサリーのリリースが近づいてきているためか、今回は安定性向上と言った感じですね。

Bash on Ubuntu On Windowsの実行環境でGit for Windowsのbash.exeを使いたいときの注意点

バッチファイルやJenkinsからGit for Windowsのbash.exeを起動したい事が有ると思いますが、Bash on Ubuntu On Windowsが動作する環境だとsystem32\bash.exeが起動されてしまい不具合がでているような状況もあるようです。

単純に環境変数PATHの参照順の話なのですが、バッチファイルやJenkinsのスクリプト記述で以下のようにすれば回避できます。

方法1 bash.exeを全てフルパスで記述する。

すべてフルパスでbash.exeを記述してしまえば間違えようがありません。

方法2 バッチファイル(スクリプト)内で環境変数PATHを設定し直す。

ようはsystem32\bash.exeより先にGit for Windowsのbash.exeが呼び出されれば良いので、バッチファイルの先頭に以下をのようにPATHの設定を追加します。

まとめ

めんどくさいですが、以上の方法で改善できます。最初からPATHの参照順を変えてしまうのは、それはそれでBash on Ubuntu On Windowsの使い勝手が悪くなってしまうので、個人的にはおすすめしません。

Tmux support arrives for Bash on Ubuntu on Windows 

情報源: Tmux support arrives for Bash on Ubuntu on Windows | Windows Command Line Tools For Developers

build 14361のUbuntu on Windowsで XTerm Control Sequencesがサポートされたので、みんな大好きtmuxがサポートされました。apt-getでインストールすれば動作するようです。

追記:

IPのアップデート後apt-get upgradeしてしまったらupgradeであれこれエラーが出て、tmuxのインストールも出来なかったので、みなさんご注意を。。。とほほー。

エラーは出るものの、インストールは出来ていて、ちゃんと動きました。

SnapCrab_SHINANO 上の Win10IP  - 仮想マシン接続_2016-6-9_7-37-50_No-00

Huge improvements to Bash on Ubuntu on Windows in Build 14361 

情報源: Huge improvements to Bash on Ubuntu on Windows in Build 14361 | Windows Command Line Tools For Developers

今回のBuild 14361ではBash on Ubuntu on Windowsで大幅な改良がされています。SysCallの対応も追加されています。

詳細は以下のリリースノートで確認してください。

https://msdn.microsoft.com/en-us/commandline/wsl/release_notes

Pico Process Overview 

情報源: Pico Process Overview | Windows Subsystem for Linux

謎過ぎなWindows Subsystem for Linux(WSL)で使用されているPicoプロセスの解説です。

基板技術となったDeawbridgeの簡単な解説、前提となるMinimal Processの説明、それを受けてのPico Processの解説となっています。

そもそもMinimal Processって何だよって感じですが、これはユーザーのアドレス空間だけを示しているもので、本当にプロセスのガワだけといったものの事のようです。Pico ProcessはPico Providerと呼ばれるこのMinimal Processを管理するためのカーネルモードドライバに紐付けられたMinimal Processの事を指すようです。

また、Windows Kernelに対しては、やはりForkの改善が行われているほか、Pico Processのために4KBずつメモリ管理出来る様にしたり、WSL起動時はNTFS上で大文字小文字の区別が生きるように改造が行われたとマジカ!と言う内容が行われているようです。

という事で、速報的にかいつまんで書いてみました。正式な翻訳が欲しいです。


Windows Subsystem for Linux Overview

情報源: Windows Subsystem for Linux Overview

Windows Subsystem for Linuxのソフトウェアアーキテクチャに関するペーパーと解説のビデオが出てきました。

LXSS-diagram-1024x472

記事本文にもありますが、今回のWSLは従来のOS/2サブシステムやSFUのInterixのサブシステムとは全く作り方が違います。従来はNTDLL.DLLという門に守られていたWindowsのカーネルモードの壁に新しい通用口を作った感じです。

bash.exeはユーザーモードで動いているLX Session ManagerにCOM(!)で接続し、一方Ubuntuのユーザーモードは一つの大きな分離プロセスとしてユーザーモードで動作し、外側へのインターフェイスとしてinitというタスクを持っています。LX Session Managerとinitとの間はカーネルモードで動作するLXCore/LXSSを通して接続されています。そして、分離プロセスとして動作しているLinuxのインスタンスの中で動作するbashやvimなどは、Linuxのインスタンスの中のピコプロセスとしてinitにより起動されます。

このピコプロセス管理し、カーネルとして振る舞うこともLXCore/LXSSの仕事になり、Linuxのバイナリが必要とするLinuxシステムコールをWindowsのシステムコールに翻訳をします。Windowsから見るとこのlxcodre.sysとlxss.sysはデバイスドライバとして動作しています。

ファイルシステムとしてはUnixファイルシステムを再現し、Windowsアプリケーションやそのファイルとは相互互換性のないVolFsと、Linuxサブシステム上からWindowsのファイルシステムを使用するためのDriveFs(/mnt/cのやつですね)が作られたようです。

ということで、自分が理解した内容をつらつら書いてきましたが、正確な内容については情報源のところの元の記事とビデオとで参照・確認してください。

いやぁ、やはりというか思った以上にというかELFバイナリをそのまま動かすって大変ですね。やっぱすごいことしてた。UWPと分離プロセスとかWindowsコンテナのような様々な要素技術が十分そろった今だからこういうことができるようになったという感じですね。Drawbridgeの成果物としてこういうものも出てくるとは思ってもみなかったです。

あと、MSKKには是非ちゃんと翻訳してほしい。


とりあえずの答え合わせ - BASH Running in Ubuntu on Windowsについて

情報源: BASH Running in Ubuntu on Windows 現状わかってきたことをまとめてみ…

情報源: BASH Running in Ubuntu on Windowsについて

本日配布が始まったWindows 10 Insider Preview Build 14316よりLinux Subsystemが使用できるようになりました。とりあえず先週の想定が合っていたかの答え合わせをしたいと思います。今後の情報によりまた内容が変わる可能性は沢山ありますw

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

  • GUIの無いLinuxアプリケーションの実行。
    • OK.
  • ELF形式のバイナリファイルを直接実行できる。
    • OK.
  • ELF形式のバイナリを開発できる。
    • OK, 開発環境のインストールが必要(apt-get install build-essential)
  • Aptによるアプリケーション管理。
    • OK.
  • Windows側ファイルシステムのマウント。
    • OK, ただしWindowsファイルシステム側でln -sが動かないなど制限もある。
  • Windows側から見るとLinux(Ubuntu)のファイルシステムは通常のディレクトリ/ファイルに見える。
    • OK.

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

  • Ubuntu側のシェルからのWindowsアプリケーションの起動、またその逆。
    • OK.
  • Ubuntu側LinuxアプリケーションとWindowsアプリケーションとのパイプ、共有メモリ等による連携。SocketやHTTPなら可能だろうけど。
    • OK.また、UWPと同様な形でWindowsアプリ側とプロセスの分離をしていると思われる。
  • X Window Systemに依存するアプリケーションの動作。これはServerだけでなくClientも動作できないと考えられる。

  • コンソールアプリケーションでもフレームバッファに直接アクセスするなどするアプリケーションの動作。
    • 今のところ不明。
  • 上二つはWindowsの制約からWindowsサブシステム以外グラフィックシステムにアクセスできない制約による。
    • 今のところ不明
  • Linuxサーバーとしての運用。(これは出来ないというよりやら無い方が良いレベルになるかも)
    • 今のところ不明

情報が増えてきたらまたアップデートします。


BASH Running in Ubuntu on Windowsについて

情報源: 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-3_s
図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の新版出版とかも期待したいところです。

Running Bash on Ubuntu on Windows!

P488 Running Bash on Ubuntu on Windows? Really? Yes, REALLY! In this video we’ll outline why and how we’re enabling Windows 10 to run native Linux apps and tools directly on Windows! Watch to learn more an

情報源: Running Bash on Ubuntu on Windows! | Build 2016 | Channel 9

Channnel 9のビデオです。キーノートよりも詳細な情報が語られているのと、実際にbashで操作していくデモを見ることができます。