Insider's Eye WinFXのインパクト ――　新たな .NET Frameworkの姿　―― Greg DeMichillie 2004/01/07 Copyright (C) 2003, Redmond Communications Inc. and Mediaselect Inc.

---

本記事は、（株）メディアセレクトが発行する月刊誌「Directions on Microsoft日本語版」2003年12月15日号p.34の「WinFXのインパクト―新たな .NET Frameworkの姿」を、許可を得て転載したものです。同誌に関する詳しい情報は本記事の最後に掲載しています。

　MicrosoftはWindowsの次期バージョン（開発コード名：Longhorn）の発表に合わせて、新APIセットのWinFXを発表した。WinFXは.NET Frameworkをベースとしており、老朽化したWin32 APIの後継となるように設計されている。

　Windowsの次期バージョンであるLonghornは、WinFXという新APIセットを提供する。WinFXは .NET Frameworkをベースに構築されており、1993年発売のWindows NT 3.1以来使われている老朽化したWin32 APIの後継として設計されている。従って、開発者は主に .NET Frameworkおよびマネージ・コードを介してLonghornの新機能（新グラフィックス・エンジンやWebサービス・システムなど）にアクセスする。WinFXの登場により、Windowsは開発者からすると、いっそうシンプルかつ有意義なものに変わるかもしれないが、WinFXへの移行を支援するツールはすぐには登場しない可能性がある。

Win32を置き換える意味

　Win32は何度も拡張されているが、本質的にはWindows NTとともに導入されたAPIセットと同じである。それどころか、1985年にWindowsとともに導入されたAPIセットとほぼ同じだ。もっともMicrosoftが32ビット版Windowsに移行し、それに伴いAPIを拡張するまではWin32と呼ばれていなかった。MicrosoftはWinFXによって、着実に悪化しつつある次のような各種の問題を軽減しようと考えている。

●「ツール・ギャップ」問題
　Win32自体の変化はほとんどなかったといえるが、周囲の環境は劇的に変化した。アプリケーション開発用のAPIの提供をVisual Basicなどのツールに依存している多くの開発者にとって、Win32は直接関係ない。このため、しばしば「ツール・ギャップ」が発生した。MicrosoftがOSにAPIを追加しても、多くの開発者、特にVisual Basicなどの開発ツールに大きく依存する社内IT開発者は、普段使用する開発ツールにそれらが組み込まれるまで新APIを利用できない。MicrosoftはISVと社内IT開発者の両方が直接使用できるOS APIを作ることで、新機能の開発と、開発者に実際に使用されるまでの期間を短縮しようとしている。

●困難なプログラミングの習得
　Win32 APIはCプログラミング言語をベースとしているため、意味のある方法で整理するのが難しい（唯一の例外は、恐らくアルファベット順のソートだろう）。このためWin32の学習は新人プログラマにとって敷居が高いものになり、APIの増加とともに事態は悪化する一方だった。Windows 1.0が提供した比較的少数のAPIセットは開発者にとって管理可能なものだったかもしれないが、一説によればWindowsはいまや1万5000個以上のAPIを提供している。この数字は端的にいってあまりにも膨大で扱いにくい。また、1個のリストで効率的に管理することはできない。.NET FrameworkはAPIを論理的な名前空間という階層グループに整理するので、開発者は特定のWinFX APIを見つけやすくなる（この構成については次の図「WinFXの名前空間によるAPIの整理」を参照）。

WinFXの名前空間によるAPIの整理

WinFXは、 .NET Frameworkと同様に、APIを名前空間という階層的グループに基づいて整理する。本図にいくつかの例を示す。トップは「System」名前空間で、ここにはMicrosoftがシステムの一部として定義したすべてのAPIが含まれている。ほかのベンダも独自のトップレベルの名前空間を導入できる。 　「System」名前空間には複数の子（サブ）名前空間が含まれている。本例では、Longhornの新ファイル・システムおよびストレージ・エンジンであるWinFS用のAPIを定義する「System.Storage」と、Webサービス構築用の新コミュニケーション・レイヤであるIndigo（開発コード名：インディゴ）を定義する「System.MessageBus」の2つを示した。 　これらの各名前空間は特定の機能を提供するほかの名前空間やクラスを含むことができる。例えば「System.Storage.Contact」には、WinFS内に格納された個人のコンタクト情報を表わす「Person」というクラスが含まれている。

●間違いやすいプロセス
　C言語によるプログラミングは間違いやすいプロセスである。開発者はメモリの割り当てや解放など、プログラムのほぼすべての側面を管理しなければならないからだ。Microsoftは、.NET Frameworkおよびマネージ・コードへの移行によって、メモリ管理などを常に気にしなければならないという仕事から開発者を解放し、彼らの生産性を高めるのと同時に間違いを減らしたいと考えている。さらに使い慣れたすべてのOS機能を引き続き利用できるようにする狙いがある。

.NET Frameworkが開発舞台の中央に

　Microsoftは、開発サイクルの後半でWindows Server 2003を.NET Frameworkが統合される最初のWindowsバージョンであると売り込み始めた。.NET FrameworkはOSと同時に出荷され、OSとともにインストールされるので、ユーザーや開発者はマネージ・コード・アプリケーションを実行する際に別途インストールする必要がない。Windows 2000やWindows XPの場合はユーザーによるインストールが必要だった。しかしOSの機能性の面では、Windows Server 2003上で稼働する.NET FrameworkはWindows 2000 Server上で稼働するFrameworkと劇的に違うわけではない。

　LonghornとWinFXでは、.NET FrameworkとWindowsの関係が変化する。基本的なOS機能（例えばAvalonグラフィックスおよびユーザー・インターフェイス・サブシステムやWinFSファイル・システム）は少なくとも部分的にマネージ・コードとして実装される。そして、.NET FrameworkはC#やVB.NETなどのプログラミング言語とともに、開発者がそれらのOS機能にアクセスする際の基本的手段となる。開発者は従来どおりCやC++などの言語によるネイティブ・コードを書いてこれらの機能にアクセスできるが、そのコードはネイティブ・コード・アプリケーションとマネージ・コードAPIの翻訳を行う「Interop」レイヤを通過し、それによってオーバーヘッドが増える。

　Microsoftは、.NET Frameworkをすでに使用している開発者にとって、WinFXへの移行は簡単になるとしている。例えば新グラフィックスAPIのAvalonは、.NET FrameworkのWindows Forms APIに可能な限り似せた設計だ。同様に、.NET Frameworkの一部である基本クラス・ライブラリも、WinFXへの移行でほとんど変更されない予定だ。

社内IT開発者向けからの脱却

　.NET Framework（特にASP.NET）は、ISVよりも社内IT開発者の間で人気がある。これは .NET Frameworkがまだ広く普及していないからだが、乗り換えに値する説得力のある理由をISVがまだ見つけられないからでもある。商用ソフトウェア開発者はすでにWin32専門家のチームを抱えており、Win32の習熟曲線は障害ではなかった。また、マネージ・コードの生産性のメリットも、Win32 APIを直接使用した場合のパフォーマンス改善には、しばしば及ばない。

　MicrosoftはWinFXにより、この習慣を変えようと考えている。ネイティブ・コードよりもマネージ・コードを介した方が、開発者がより多くのOS機能により、快適にアクセスできるようになるとしている。

　しかし1つの大きな障害は、既存OSとの下位互換性の欠如だ。WinFXはLonghornでしか利用できない。大手ISVには、旧バージョンのWindowsの大規模なインストール・ベースを持つユーザーがいるため、Windowsユーザー全体のごく一部としか互換性のないメジャー・アプリケーションの開発に着手するとは思えない。これらのISVは、WinFXを無視するか、Longhorn用と旧バージョンのWindows用という2つの異なるコード・ベースを維持するという選択を迫られる。

開発ツールに残る課題

　WinFXは「ツール・ギャップ」をなくすように設計されている。その結果、Win32 APIは社内IT開発者にとってある程度不要なものとなる。だが、残される課題もある。Visual Basicでは、ユーザー・インターフェイスをグラフィカルに作成したり、データベース・クエリーを構築したり、アプリケーションのデバッグを行うことで、開発者に簡易なAPI以上のものを提供している。

　Microsoftは、Longhornに対応した将来のVisual Studio .NET（VS.NET）のリリース（開発コード名：Orcas）ではWinFX APIを搭載するとしている。

　 しかし、最近のProfessional Developers Conference（PDC：Microsoft主催の開発者向けの会議）における発表では、Microsoftの開発者用ツール部門はSQL Server「Yukon（開発コード名：ユーコン）」とそれに対応するVS.NETの「Whidbey（開発コード名：ウィッドビィ）」を可能な限り早くリリースすることに専念していた。YukonとWhidbeyにこれほど多くの力が注がれているとすると、Microsoftの開発者用ツール部門は、Longhornやその機能を利用する上で開発者が必要とするツールに集中する時間を割くのは、簡単なことではないだろう。

参考資料

• Longhornの概要については、「Directions on Microsoft日本語版」2003年12月15日号の「Longhorn 評価版に見るリリースまでの道のり」を参照。

• Longhorn Developer Centerでは、WinFXのサンプル・コードと情報が参照できる。
  http://www.microsoft.com/japan/msdn/longhorn/default.aspx

	関連記事
		Insider's Eye 次期クライアントOS「Longhorn」本格始動へ（Windows Server Insider）
		Insider's Eye 革新的なOSを目指して開発が進むLonghorn（Windows Server Insider）
		Insider's Eye Longhornの機能と構造―　PDC 2003レポート No.1 ―（Windows Server Insider）
		Insider's Eye Longhornの機能と構造―　PDC 2003レポート No.2 ―（Windows Server Insider）
		Insider's Eye Longhornの機能と構造―　PDC 2003レポート No.3 ―（Windows Server Insider）
		特集 .NET開発者のためのPDC 2003レポート（Insider .NET）

Directions on Microsoft日本語版 本記事は、（株）メディアセレクトが発行するマイクロソフト技術戦略情報誌「Directions on Microsoft日本語版」から、同社の許可を得て内容を転載したものです。『Directions on Microsoft 日本語版』は、同社のWebサイトより定期購読の申し込みができます。

　

「Insider's Eye」

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）