Windows Info 第441回

WSL以前から40年以上続く、Windows（Microsoft）とUNIXとの関わり

80年代、Microsoft製のUNIXが存在していた
POSIXサブシステムは2012年までサポートが続いた

　現在のWindows 11では、Windows Subsystem for Linux（WSL）が動作するため、（それ自体はUNIXではないものの）UNIXからのアプリケーションを簡単に動作させることができる。

　かつてMicrosoftは、x86版UNIXのライセンスを持っており、XENIXと呼ばれる製品を販売していた。また、Windows NTに「POSIXサブシステム」、のちに「Windows Service for UNIX（SFU）」と呼ばれる機能があった。そういうわけで、WindowsとUNIXは切れない“縁”があったのだ。

　Windows NTのPOSIXサブシステムやその搭載理由などに関しては、過去記事（「Windows Subsystem for Linuxの中身を詳しく見る」）に記載したが、簡単に言えば、非推奨で廃止機能とされたものの、Windows 8まではPOSIXサブシステムは生きていた。

　またWindows Serverでも、2012まではPOSIXサブシステム（当時は「Windows Subsystem for UNIX-based Applications」、SUAと呼ばれていた）が動作したが、廃止が通告された。Windows 10のWSLはLinuxではあるが、SUA的なものとして導入された。しかし、あくまでもLinuxである。

　というわけで、Windows NTからWSLまでを簡単にまとめたのが、以下の表となる。

UNIX/POSIXアプリケーションをWindowsで動かすための
プロジェクトとしてCygwinなどが存在する

　POSIXサブシステムが廃止になったのは、2000年にPOSIX要件（米政府に納入されるコンピュータに関する義務）が廃止になり、POSIXアプリケーションを動作させる必要がなくなったからだが、結果的には2012年までサポートは続いた。Windows Server 2012の廃止通告では、SUAの代用として、CygwinとMinGW-w64、MinGWが推奨された。

　これらは簡単に言えば、UNIXやPOSIX準拠のアプリケーションをWindowsで動かすためのオープンソースソフトウェアプロジェクトだ。1994年に出荷されたWindows NT 3.5にはPOSIXサブシステムがあり、gccなども含まれていて、POSIX準拠のアプリケーションを動かすことができた。

　しかし当時の主力クライアントOSは、Windows 3.1などの非NT系Windowsで、大多数を占めるWindowsでは、UNIX/POSIXアプリケーションは利用できなかった。また、Windows NTのSFUでは、たとえばNFS（Network File System、UNIXで標準的に使われていたネットワークファイル共有システム）サーバーにUNIXマシンを接続するには、クライアント用ライセンス（Client Access License、CAL）を購入する必要があり、自由に使えるものとは言いがたかった。

　Cygwinは、Windows 95などの非NT系Windowsでも、UNIX/POSIXプログラムを動作させることができた。Win32実行バイナリを出力できるgcc（旧GNU C Compiler、現GNU Compiler Collection）や、UNIX APIを解釈するDLLを開発し、UNIX/POSIXプログラムをほぼそのままコンパイルできるようにした。Cygwinプロジェクトが開始された1995年は、Windows 95が登場し、クライアントマシンでも32bitアプリケーションを実行できるようになった年である。

　そもそも、当時のUNIXでは、ソースコードレベルでの互換であり、POSIXではシェルや標準ツールなども標準化したため、これらの実行ファイルもSUAに含まれていた。

　Cygwinは、Windows上でPOSIXアプリケーションを開発、実行するための環境として作られた。Windows NTの上で動作するgccなどのコンパイラやシェルを含んでおり、アプリケーション開発ができた。現在でもプロジェクトは継続している。現在では、CygwinはUNIX/LinuxのアプリケーションをWindows上で動かす仕組みになっている。gcc自体は、Cygwinとは異なるプロジェクトだが、Cygwinが開発される過程でgccはWindowsの実行バイナリを出力できるようになった。

　MinGW（Minimalist GNU for Windows）は、Cygwinから分岐（フォーク）したプロジェクトで、基本的な開発ツールと実行環境を提供する。Cygwinと異なり、開発されるプログラムを重視し、完全なPOSIX互換にはこだわらなかった。このため、一部のソフトウェアは書き換えが必要になる。

　このMinGWに、UNIX系の標準ツール実行プログラムを提供したのが、MSYS（Minimal SYStem）と呼ばれるプロジェクトだ。のちにMSYSはMinGWと1つのパッケージで配布されるようになる。MinGW自体は、UNIXソースコードからWindows用バイナリを出力させるためのヘッダ定義やDLLなどからなり、コンパイラなどは、別プロジェクトであるgccを使う。MSYSもCygwinと同じくUNIXアプリケーションを動作させることを目的としているが、ソフトウェア開発関係のプログラムに限定されていた。

　しかし、MinGWはWindowsの64bit実行バイナリ出力をサポートしなかった。理由は不明だが、Linux/UNIXでは、LP64モデル（long変数とポインタが64bit）を採用したのに対して、Windowsでは、ポインタのみ64bitであとは32bitのまま据え置き（LLP64などと表記することがある）と語長が異なったこと。Windowsが64bit化しても、32bitバイナリの実行が可能で、すぐに64bitバイナリが必要ではなかったことなどが背景にある。

　2007年にMinGWから分岐（フォーク）して開発が始まったのがMinGW-w64である。名称としては、MinGWのWindows 64bit版という意味だ。ただし、MinGW-w64は、64bit X64実行バイナリファイルだけでなく、32bit X86実行バイナリファイルを出力するためにも利用できる。MinGW-w64自体は、ヘッダや必要なDLLなどから構成される。

　また、このMinGW-w64に対応して、各種のUNIXプログラムを提供する「実行環境」が2013年に開始されたMSYS2である。MSYS2は、MSYSとは独立したプロジェクトとして開始され、CygwinでWindowsに移植されたUNIXプログラムを対象とする。Cygwinへの依存を最低限として、MSYS2用としてコンパイルされたバイナリを使う。MSYS2はパッケージマネージャにより、アプリケーションの配布とインストールがされる実行環境をWindows上に提供する。

　現状では、Win32側にUNIX/Linux系のオープンソース・ソフトウェアを比較的簡単に移植するには、MinGW-w64とMSYS2を使うのが標準的だ。

　Linuxは、1991年にVer.0.01として配布が始まったが、OSとして認知され始めたのは、1990年代の後半で、現在Linuxディストリビューションと呼ばれる配布形式と、安定したカーネルが登場してからだ。1990年台の前半は、UNIXが業界の覇権争いもあって、混乱した時期でもある。

　また、PCでも動作するBSD系のUNIXをベースしたオープンソース・プロジェクトも開始されている。しかし、1990年代の前半、PC上のBSD系OSは、AT&TとBSDとのソースコード訴訟に巻き込まれる。

　その間、Linuxは順調に開発が進み、UNIXの揉め事に引っかからないUNIXの“後継者”として認知される。結果的にUNIXはハードウェアベンダー固有のバージョンに分かれたままとなり、現在のようにLinuxが広く普及することになる。もっとも、Linuxもディストリビューションが多数登場し、デスクトップ環境やパッケージ形式などを統一できず、クライアントマシンとしての普及は進まなかった。

　現状、LinuxベースやUNIXに起源を持つオープンソース系のプログラムは、大きく以下の方法を使いWindows上で動作させることができる。

MinGW-w64+MSYS2
WSL
直接移植

　ただし、どれもWindowsで動作するが、コンパイル条件などが異なるため、同じソースコードであっても、出力されるバイナリが異なる。

　たとえば、バージョン管理ツールのgitは、公式としてgit for Windowsが配布されている。これは、MinGW-w64を使ってWindows上（Win32側）で動作させている（過去には、MinGW+MSYSも使われていて、インストール時に選択が可能だった）。また、MSYS2を同時にインストールすることで、bashを動かすことができ、シェルを含めて、Linuxと同じ環境で利用でき、Linux用のパイプラインをほぼそのまま利用できる。

　WSLでは直接gitを使うことも可能だ。gitは元々はLinux用に作られた。こちらもシェルはbashである。WSLとWin32側でファイルシステムを相互にアクセスできるため、WSL上のgitを使っても、Win32側で開発しているソフトウェアのバージョン管理はできる。

　これに対して、現在のVisual Studioには、Gitエクスペリエンスと呼ばれる機能が含まれている。gitの機能をVisual Studio（2019以上だが、2019にはgit機能に制限あり）内で利用することが可能になっている。gitコマンドの直接移植ではなく、内部的にgit for Windowsを呼び出しているわけでもない。おそらくはgitのソースコードから同等の機能をVisual Studio内に移植したものと考えられる。これも、互換性がありgit for Windowsと併用できる。

★

　Microsoftは、早い段階でUNIXに関わったが、早々に自社製品とすることを放棄。結果的にUNIX業界の覇権争いには巻き込まれなかった（裏では関わっていたようではあるが）。OS/2という寄り道はあったものの、Windowsは順調に開発が進んだ。Windowsでは、TCP/IPの実装をBSDのものをベースとするなど、利用できるものは、ちゃっかり利用している。

　Windows NT系では、ずっとUNIX系アプリケーションが動作する環境が存在し、結果的に、これがWindows 10のWSLでLinuxに切り替わったことになる。