このページの本文へ

Windows Info 第441回

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

2024年07月21日 10時00分更新

文● 塩田紳二 編集● ASCII

  • この記事をはてなブックマークに追加
  • 本文印刷

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までを簡単にまとめたのが、以下の表となる。

WindowsとUNIX

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に切り替わったことになる。

カテゴリートップへ

この連載の記事

注目ニュース

ASCII倶楽部

プレミアムPC試用レポート

ピックアップ

ASCII.jp RSS2.0 配信中

ASCII.jpメール デジタルMac/iPodマガジン