WindowsVistaで最も重要な変更点とは？
「Windows Vistaで何かが変わったか？」。これについては、マイクロソフト自身の話やさまざまな記事などでいろいろと言われている。しかし筆者は、Vistaでの最も大きな変更は“内部的なもの”。すなわち“.NET Framework 3.0”が標準で組み込まれた点にあると考えている。
話はWindows XPの発表時にさかのぼる。この時点でマイクロソフトは、次世代のWindowsに.NET Frameworkを全面的に採用するつもりでいたようだ。しかし、実際には.NET Frameworkへの移行は、非常にゆっくりとしたものになった。市販アプリケーションでもごく一部しか採用されていないが現状だ。
こうした動きから、Longhornでは.NET Framework(当時はWinFXと呼ばれていた)とWin32 APIを同時にサポートする方向となった。当時はコードネームに使われた地名の地図上の位置から「“Whisler”(Windows XPのコードネーム)から、直接“Blackcomb”(次世代OSのコードネーム)に行かずに、“Longhorn”経由」と言われたものである。
しかし、Longhornの開発は一度危機的な状況に陥った。2005年8月には、計画の仕切り直しが行われ、現在のVistaの方向性ができたと伝えられている。Win32 APIとWinFXをともに効率的に動作させるというのが無理だったのか、それ以外が原因なのかはわからないが、この時点で、Longhron開発の方向性は大きく変化したのである。
WinFSを取りやめ、アプリなどの開発に専念
まずは“WDF”(Windows Data Foundation)と呼ばれていたWinFSの取りやめである。また、この時点で、Vistaの新機能は、Win32 API側からも利用できるようになった。
開発期間などから、内部的な変更を限定し、上物である付属アプリケーションやWindows Explorerなどの開発に専念できるようにしたのではないかと思われる。
また、“SideBar”などは、コンセプトが変化した。“XAML”(Extensible Application Markup Language)を使って、アプリケーションをGadgetとしても使えるようにするという方向から、Gadgetは“HTML＋JavaScriptで作る簡易アプリケーション”になった。Vistaの2D描画性能は、同じハードウェアでXPを動かしたときよりもかなり落ちているようだ。
このようにして、WinFXは.NET Framework 3.0と名前を変え、現在では、XP上でも動作させることができる追加モジュールになっている。
この.NET Frameworkを使うことで、Windows用のプログラムの作り方が大きく変化する。XAMLを使えば、回転するオブジェクトの表面に動画を貼りつけることなどが可能になる。また、プログラム上は、従来のリストボックスやボタンを扱っているのと同じだが、見た目をまったく変えることが可能だ。たとえば、動画を表示しているパネルが3次元空間で回転するようなリストボックスを作っても、アプリケーションのロジックは、従来通りでかまわない。
.NET Frameworkへ移行する意味
では、なぜ.NET Frameworkへ移行する必要があるのだろうか？ それは、セキュリティと、64bit OSへの移行のためだ。
.NET Frameworkでは、“MSIL”(Microsoft Intermediate Language)と呼ばれる中間コードでプログラムバイナリーを作成し、これを“CLR”(Common Language Runtime)で実行する。このため、実行段階で、コードの挙動を制限することが可能となり、不審なプログラムの実行を止めることが可能だ。なお、CLRでは、実行前に、IA32などのバイナリーコードへ変換されるため、オーバーヘッドはあるものの、動きだしてしまえば、実行効率はそう悪くない。
この中間コードを使う構造は、マイクロソフトが1996年に買収したColusa Softwareが持っていた“OmniVM”の技術を使うものだ。
当時、マイクロソフトは、COM+と呼ばれる、現在の.NET Frameworkのようなものを開発していた(Windows 2000用にリリースされたCOM+とは別物である)。また、セキュリティー上の問題についても、この時点で強く認識していたと考えられる。CLRのような構造だけが、悪意のあるソフトウェアに対する唯一の解答である。ただし、そのためには、セキュリティ的に弱いWin32APIを廃止しなければならない。このため、当時は、XPの次のOSで、完全移行を目指したのであろう。COM+については、1997年頃のMicrosoft System Jarnalなどの記事があるが、計画上は、Windows NT 5.0(Windows 2000)に搭載する予定だった。
また、CLRが中間コードを実行する構造になっているため、アプリケーション自体には、32bitモードも64bitモードも関係ない。IA32の機械語コードを直接使うWin32 APIでは、64bit環境では、ポインターが64bitとなるために変更が必要となる。このため、現在の64bit環境（Windows XPやWindows Vistaの64bit版）では、64bitコード、32bitコードを相互に呼び出すことができない。システムコールと自身が提供するコードのみなら、問題はないが、例えば、Internet Explorerのプラグインのように、他人の作ったDLLコードと連携するような場合、32bitと64bitのコードは連携できない(このため、64bit版XPでは、32bit、64bitの2つのInternet Explorerが付属する)。
こうした問題は、.NET Frameworkでは発生しない。配布されるコードは、MSILで記述されているからだ。
おそらく、マイクロソフトは、メモリー空間などの問題から、64bit環境への移行を早くしたいと考えているのだと思われる。インテルにAMDと同じ64bitモードを採用させたのには、マイクロソフトが大きく絡んでいるといわれている。マイクロソフトとしては、2種類の64bitモードの存在は、Windowsの64bitへの移行の邪魔になると判断したのだろう。
Vistaの次に来るもの
マイクロソフトは、Windows Vistaの次にリリースするOSとして『Longhorn Server』を計画している。これは、サーバー系OSで『Windows Server 2003』の後継にあたるものだ。
このLonghorn Serverは、WCF(Windows Communication Foundation)のサーバー側を完成させるという大きな使命がある。WCFが扱うウェブサービスは、.NET Frameworkの基本でもある。.NET Framework 3.0は、このLonghron Serverとともに完成することになる。
さらに次の段階としては、マイクロソフト製品の.NET Frameworkへの移行が開始されることになるだろう。
マイクロソフト自身は、現在では、自身が.NETへの移行を完了しない限り、サードパーティの.NET対応が進むとは考えていないようである。実際、Windowsのときも、マイクロソフトがWindowsベースのアプリケーションを投入してもまだ、DOSバージョンでビジネスを続けていたサードパーティは少なくなかった。
しかし、このタイミングで、大手サードパーティとマイクロソフトのアプリケーションの地位が逆転した。例えば、『Lotus 123』や『一太郎』などである。これを考えると、マイクロソフトが.NETへの本格移行を開始すれば、おそらく他社も短期間のうちに追従する可能性は高い。
もっとも、Windows 95のような急速な変化は期待できない。マイクロソフトもWindows 98のような現在市場に残っているシステムに関しては、自然減にまかせ、積極的にVistaへの移行を促すような“無駄な”努力はしないようだ。しかし、これには、時間が必要だ。
ビル・ゲイツは、2008年に引退を予定しているが、それは、Vistaで方向転換がようやく完了したからだろう。世間が.NET Frameworkへ完全移行するには、さらに5～10年という月日が必要で、さすがのビル・ゲイツもそこまではつきあえないと考えたからではなかろうか。
