Windows Info 第82回

Windows Subsystem for LinuxからWindowsバイナリが起動可能に

　現在配布が行なわれているWindows Insider Program（WIP）のRS2 Insider Preview Build 14951以降（以下プレビュー版と略す）では、Windows Subsystem for Linux（WSL、Bash on Windows:BOWとも）の機能が拡張されており、bash側からWindowsデスクトップアプリケーション（Win32アプリケーション）の起動が可能になった。

　マイクロソフトのブログでは、この機能を「Windows Subsystem for Linux - interoperability with Win32 applications」と呼んでいる（以下、Win32相互運用性と略す）。

　このWin32相互運用性は、単純にWin32アプリケーションを起動するだけでなく、引数に指定された「ファイルパスの変換」と「標準入出力などリダイレクションの制御」も行なう。

　また、WSLを起動するinitプロセスの機能が拡張されており、起動時のWindows側のPATH環境変数をWSL側に持ち込むようだ。このため、特にWin32側のPATH設定などをしなくても、Win32アプリケーションを起動できるようになる。ただし、Linuxでは実行ファイルの拡張子の省略（Windowsではexe/com/batの拡張子は省略可能）がないため、実行ファイルは「cmd.exe」のようにファイル名を完全に指定する必要がある。

WindowsとLinux間のパスの変換

　Win32相互運用性では、Win32アプリ側が動作するのはWindows環境だが、起動するbashはWSL内となる。Windowsの環境では、パスにドライブ名などを含むパス表記（UNC、Universal Naming Convention）が使われる。これに対してWSL内では、Linuxのパス表記方法が使われている。

　WSLには2つのファイルシステムがあり、1つはLinuxのファイルシステム（ルートディレクトリ以下）であり、これはVolFS（Volume File System）と呼ばれている。もう1つは、WSL側からWindows側のファイルをアクセスするためのDrvFS（Drive File System）で、こちらは、VolFSの/mnt/以下にドライブ文字のディレクトリが作られ、たとえば「/mnt/c」が「C:\」に相当する。

　コマンドラインの引数は、プログラム自身が解釈し、必要に応じてファイル名をフルパスなどに変換している。このとき、使われる「カレントディレクトリ」（Windowsではカレントフォルダ）は、プログラムの起動時に環境情報として渡される。プログラムを起動するbash側では、引数のどれがファイルなのかは判断できず、単純に引数にある環境変数やシェル変数などを展開（変数を変数値で置き換える）するだけだ。

　このため、Win32相互運用性でも、引数自体にはまったく手をつけないが、環境情報である「カレントディレクトリ」だけは、パスをUNCに変換して、Windows側に手渡す。

　ただし、VolFS（WSLのルートディレクトリ以下、DrvFS以外の部分）内のパスがカレントディレクトリだった場合には、現在のWin32相互運用性では、Bash.exeの起動フォルダである「%windir%\system32」（一般的にはC:\Windows\System32）が使われる。

　VolFSは、Linux側のファイルシステムであるため、Windows側からのアクセスが制限されている。これは、WindowsとLinuxではファイルロックのポリシーが違い、安全なアクセスを実現するためのコストが小さくないからだ。このため、VolFS側にあるファイルは、Win32相互運用性ではアクセスすることができない。処理する場合には、Linux側でVolFSからDrvFS側にファイルをコピーするなどが必要になる。

　WSL側では引数を勝手には変換しないため、Win32プログラムの引数に直接Windowsのパスを記述することもできる。

WSL側でWin32アプリケーションを起動するとき、\はbashが解釈するエスケープ文字なので\\とするか、パスをシングルクオートで括る

　注意したいのは、UNCで使われる\（逆スラッシュ）は、bashのコマンドラインではエスケープ文字として解釈されるため、表記に注意が必要になることだ。具体的には「\」を「\\」としてエスケープ文字として解釈が行われてもいいようにするか、Windows側のパスをシングルクオートで括り、エスケープ文字の解釈を行わせないようにするかである。

notepad.exe 'c:\temp\test.txt'　引数をシングルクオートで囲む
notepad.exe c:\\temp\\test.txt　\を\\とする

　実は、Windows自体は、パスの区切り文字としてスラッシュ「/」も受け付けるため、必ずしも、逆スラッシュ（円マーク）で指定しなくてもよい。たとえば、前述の例では、

notepad.exe c:/temp/test.txt

と表記しても動作する。ただし、Windowsのコマンドラインプログラム（GUIを持たずコンソールで動作することを前提に作られたコマンドライン用実行プログラム）では、この表記がエラーになる。

　標準のオプション指定文字がスラッシュであるため、これをファイルパスとは解釈しないからだ。たとえば、「dir」コマンドは、ファイルパスは逆スラッシュ区切りでしか受け付けない。逆にGUIを使うWin32プログラムの大半はオプション指定を持たないため、スラッシュ区切りでもパスを解釈できるものが多い。ただし、GUIを使うプログラムの中にもオプション指定を受け付けるものがある。

　逆に、引数としてDrvFSのパスを直接表記してしまうとエラーになる。

notepad.exe /mnt/c/Temp/test.txt　エラー
cd /mnt/c/Temp　カレントディレクトリを使う
notepad.exe test.txt　エラーにならない

　エラーになるのは、引数などは変換されずにそのままWin32アプリケーションに渡されるからだ。Win32アプリケーションは、UNC形式のパスが前提であるため、DrvFS形式のパスを解釈できない。

標準入出力の変換

　Win32相互運用性のもう１つの機能が、WSLとWindows側の標準入出力の接続だ。Windowsでもbashでも、パイプ"|"でプログラム間の標準入出力を接続したり、">"や"<"で切り替えを行なうことができるが、Win32相互運用性では、WSLとWindowsの標準入出力を接続することができる。たとえば、bash上で

cmd.exe /c dir | grep "test"

として、WSLでWin32ソフトウェアであるcmd.exeを起動し、その出力をWSL側のLinuxソフトウェアであるgrepの標準入力と接続できる。

Win32相互運用性では、Win32とWSL間で標準入出力によるデータの受け渡しが可能

逆に

ls | find.exe '"test"'

として、Linuxのlsコマンドの出力をWin32側のFind.exeの入力と接続することも可能。ただし、Find.exeの引数はダブルクオートで括る必要があるが、Bashが解釈して評価した結果としてダブルクオートをはずしてしまうためシングルクオートでくくり、ダブルクオートが解釈されないようにする必要がある。

　リダイレクションは、bashが解釈して、WSL側で標準入出力を設定するため、リダイレクト先のファイルの指定には、WSL側のパス指定を使う必要がある。Win32アプリケーションでも、VolFS内へのファイルの書き込みが利用できる。

リダイレクションを使えばWin32アプリからLinux側のファイルシステム（VolFS）へのアクセスが可能になる

　だが、Windows側では、コマンドプロンプトウィンドウ内で

dir | bash -c "grep 'test'"

として、cmd.exe側の標準入出力をbash側へつなぐことはできないようだ。bash.exe自体には、標準入出力はあるものの、それをWSL側で起動される/bin/bashに接続することはできない。Win32相互運用性があるため、前述のようにWSLからcmd.exeを起動するなどしてWindows側でコマンドを動作させれば実質的には同等のことが可能となるため、基本的には問題になることはないだろう。

　次回は、このWin32相互運用性を実現している仕組みについて解説する。