使って理解しよう！Windows Server 8の姿 第4回

SP1のタイミングでARM版Windows Serverも登場か

「Windows Server 2012」は名称もエディションも大きな変更なし？

　次期Windows、コード名「Windows 8」の正式名称が決まった。クライアントが「Windows 8」で、サーバーが「Windows Server 2012」という、あまり面白みのない名前である。筆者は、正式発表の少し前に（マイクロソフトMVPとしての機密保持契約下で）正式名が知らされたとき、「そ、それが機密ですか？」と心の中で突っ込んだものだ。

　クライアントWindowsは格好良さとか目新しさなどを重視する。2000は新規性を示し、XPやVistaは格好良さを重視した。7も数字が持つイメージを重視したのだろう。マイクロソフトのいう「7番目のWindows」という数え方は少々無理がある。文字通りにとらえないほうがよい（コラム）。

　8という数字は、漢字圏では縁起のよい数字とされる。日本では「末広がり」だし、中国では「発財（金持ちになる）」の「発」が「八」と同じ読みだとして好まれる。北京オリンピックの開会式は2008年8月8日午後8時8分だったくらいだ。

　一方、サーバーの場合は安定性を重視するため奇抜な名前や新しすぎる名前は好まれない。そのためWindows 2000 Server以来、Windows Server 2003、2008、2008 R2と、単に年号を並べただけになっている。特に面白いのはWindows Server 2008 R2である。内部的には大きな変化があり、クライアントOSはWindows VistaからWindows 7に変わったのに、サーバーは「R2」が付いただけである。そして、多くの人はWindows Server 2008 R2のことを単に「Windows Server 2008」と呼ぶ。

Windowsのエディション

　Windows 8のエディションは、家庭向けの「Windows 8」、企業向けの「Windows 8 Pro」、そしてソフトウェアアシュアランス（SA）契約特典として提供される「Windows 8 Enterprise」の3つに集約された（図1）。また、ARM版WindowsはWindows RTとして別エディションとなった。

図1　Windows 8のエディション

　参考のため、Windows 7のエディションを示すので比較してほしい（図2）。Windows RTがActive Directoryに参加できないのは残念だが、それでもローカルポリシーは使えるはずなので、企業用タブレットとして他社にない大きな優位点になるはずだ。

図2　Windows 7のエディション

　筆者はまだ詳細情報を入手していないが「Windows To Go」はWindows 8 Enterpriseにのみ含まれるという話を聞いた。Windows To Goは、Windows 8システムを収めたUSBメモリから起動する機能で、OSを丸ごと持ち歩けるメリットがある。個人でも使いたい人はいるはずだ。これが単にライセンスの問題だけならよいのだが、機能そのものがEnterpriseにしか含まれないとするとちょっと残念である。

■関連サイト

• Windows開発チームのブログ「Blogging Windows」の記事「Announcing the Windows 8 Editions」（機能比較表に「Windows To Go」がない）

　一方、Windows Server 2012のエディションは発表されていないが、こちらは大きな変更はなく、以下のようになると思われる。

• Windows Server 2012 Standard
• Windows Server 2012 Enterprise
• Windows Server 2012 Datacenter

　現在と同様、Standardは機能縮小版、EnterpriseとDatacenterは基本機能が同じで、ホットメモリ追加（OS動作中に物理メモリを追加）など特殊なハードウェアサポートの有無と、ライセンス形態の違いとなるだろう。

　そのほか、Web Serverは廉価版として維持されるはずだ。HPC（High Performance Computing）も、「Computing Cluster」という特殊な機能をStandardに含める必然性はないし、Enterpriseのような高価な構成にするのは不適切なので、独立したエディションになると思われる。なお、従来Windows Storage Serverの上位版のみに含まれていたiSCSIターゲット機能は、現在Windows Server 2008 R2用ソフトがマイクロソフトのWebサイトから無償ダウンロードして利用できるうえ、Windows Server 8 ベータ版では標準機能となっている。しかし、CALなどの条件が異なるため、OEM向けのWindows Storage Server提供は維持されるだろう。

　現在公開されているベータ版は1種類で「Datacenter Edition」と表記されている。そのため実際の製品、特にStandardには含まれない機能があることに注意してほしい。

コラム：「7番目のWindows」とは？

　マイクロソフトのオフィシャルブログWindows Vista Team Blog「Why 7？」では、Windows 7が7番目のWindowsである理由を以下のように説明している。

1. Windows 1.0
2. Windows 2.0
3. Windows 3.0/Windows NT
4. Windows 95/98/98SE/Me
5. Windows 2000/XP
6. Windows Vista
7. Windows 7

　この数え方は、異なる2系列を1つにまとめたせいで混乱している（案の定、多くの批判的なコメントが付いている）。Windows NTの最初のバージョンはWindows 3.1との互換性を強調するためにWindows NT 3.1となったが、完全な別製品である。またWindows NT 4.0がカウントされていない。Windows 95の開発コード名や内部バージョンはWindows 4.0だが、これはWindows NT 4.0とはまったくの別物である。Windows 2000とXPは内部バージョンが5.0と5.1の差なのでまとめられたが、Windows VistaとWindows 7の内部バージョンはそれぞれ6.0と6.1である。

　マイクロソフトからは「バージョン番号の大小は、変更の大小とは無関係」と説明されているが、だったらバージョン番号に何の意味があるというのだろう。

Windows Server RT？

　サーバー管理者として少々気になるのがARM版のWindows Server、つまり「Windows Server RT（筆者命名）」だ。

　ARMプロセッサーは性能は低いものの低消費電力であり、実装密度を上げることができる。一般にサーバーには単体での性能を向上させる「スケールアップ」よりも、多数のサーバーを並列動作させる「スケールアウト」を重視する。リレーショナルデータベースなど、スケールアウトが難しい場合もあるが、WebサーバーやDNSサーバーなどはスケールアウトが有効である。ARMプロセッサーは、インテルx64よりもスケールアウトに有利である。

　もともとWindows NT系列のOSは、複数のCPUへの移植を前提に開発されてきた。過去にはDEC（現HP） Alpha、MIPS R4000、IBM PowerPC用のWindows Serverが存在したし、開発途中で放棄されたものもあるという。

　しかし、後述するようにいくつかの例外はあるものの、原則として実行できるのはネイティブアプリケーションだけなので、Alphaプロセッサー用の実行ファイルは、インテルx86プロセッサーでは動作しない（図3）。

図3　異なるアーキテクチャの実行ファイルを起動

Windows NT 4.0(x86)上でAlpha用Windows NT 3.5のセットアッププログラムをすると、CPUが異なるというエラーメッセージが表示

Windows Vista上でAlpha用Windows NT 3.5のセットアッププログラムを実行。こちらは、あたかもファイルが壊れているかのように表示される

　そのため、Windows RTでは従来のWindowsアプリケーションがいっさい動作しない。そこでWindows RTにはMicrosoft Officeがバンドルされ、リモートデスクトップクライアントが付属する。

　既存のプログラムが起動すらできないのは、かなり厳しい制約のように思えるだろう。だが、クライアント用途と異なり、サーバーではあまり大きな影響はないと筆者は考えている。

　まず、サーバーとクライアント間はネットワークを介して通信するだけだから、プロトコルさえ合致していれば、互換性の問題は発生しない。

　次に、.NETベースのアプリケーションはネイティブコードではなく共有言語ランタイム（CLR）用の仮想環境で動作するため、CPU命令に（原理的には）依存しない（図4）。一部アプリケーションはネイティブコードを呼び出したり、特定のCPU上での動作を強制したりしているが、マイクロソフトの開発ガイドラインに従って開発されたプログラムであれば、ARMプロセッサで動作させるのはそれほど難しくないはずだ。

図4　.NETアプリケーションの実行の流れ

　ARMプロセッサーベースのサーバーは2012年に登場し、2013年から普及すると予測されている。OSの製品サイクルからすると、Windows Server 2012の次は2016年頃と思われるので、そのタイミングでARM対応するのは少し遅すぎる。おそらく2013年にはWindows Server 2012のService Pack 1（SP1）が出るだろうから、その頃にARM対応が行なわれるのではないだろうか。Windows Server 2003のx64版はWindows Server 2003 SP1をベースにしたが、似たような展開になるのではないかと予想する。

非ネイティブアプリケーションの実行

　現行のWindowsでは、OSが本来ターゲットにするアーキテクチャ以外のアプリケーション（非ネイティブアプリケーション）が実行されるケースが3種類ある。1つ目は16ビットDOS/Windowsアプリケーション、2つ目はx64版Windows上のx86アプリケーション、そして3つ目はItanium版Windows上のx86アプリケーションである。

　x64プロセッサーはx86プロセッサーを64ビット化したものだが、32ビット命令と互換性を持つ（ハードウェアエミュレーション）。そのため、32ビットアプリケーションであっても高速に動作する。

　一方、初期のItaniumはハードウェアによるx86エミュレーション機能を搭載していたが、ハードウェアアーキテクチャの制約によりきわめて低速であった。そのため、のちにソフトウェアエミュレーションに変更された。Windowsは当初からソフトウェアエミュレーションでx86アプリケーションを動作させることができた（実はハードウェアエミュレーションよりも高速だそうだ）。

　また、x64以外のWindowsは、16ビットDOS/Windowsアプリケーションを実行できる。このとき、インテルとAMD x86プロセッサーの場合はCPUが持つ「仮想8086モード」を使い、それ以外のCPUの場合はソフトウェアエミュレーションを行なう。

　x64プロセッサーには仮想8086モードが存在しないため、16ビットDOSアプリケーションは動作しない。他のCPUと同様、ソフトウェアエミュレーションを行なうことは技術的に可能だったはずだが、そうはなっていないのだ。

　異なるCPUの機能をソフトウェアで実装した場合、高速に動作させるのは難しいように思える。しかし、OSのシステムコールはネイティブCPU動作に切り替えてから実行するため、実際の速度は意外に低下しない。この切り替えの仕組みを「サンク（Thunk）」と呼ぶ（図5）。サンクにより、ファイル入出力や画面描画など、OSの機能はネイティブアプリケーションと同じ速度で動作する。もちろん、アプリケーション内の処理が多ければ多いほど、エミュレーションによる速度は低下する。

図5　サンクの利用

　以上3つの例外を除き、一般のアプリケーションは、CPUが異なると実行できない（図5）。そこで、Alphaプロセッサーを製造販売していたDEC（現HP）は、「FX!32」というシステムを開発し、x86プロセッサ用アプリケーションをAlphaプロセッサー上で実行する仕組みを実現した。

「Digital FX!32： Combining Emulation and Binary Translation（Digital Technical Journal Vol. 9 No.1 1997）」

　FX!32はソフトウェアエミュレーションとバイナリ変換を併用するため、利便性と性能の両方を実現している。まず、初回実行時はエミュレーションを使うためすぐに起動する。エミュレーションなので、実行速度は遅いがエミュレーション結果はファイルに保存されるため、2回目からは変換済み命令を高速に実行できる。また、前述の「サンク」の仕組みも使うため、OS内部ルーチンについては最初から高速に実行できる。

　FX!32のようなソフトウェアがARM用に登場すれば、さらに利用範囲が広がるはずだが誰か開発しないのだろうか。

■関連サイト

• 「Windows Server "8" ベータ版」
• Windows 8 Consumer Preview