第219回
Longhornへの期待と懸念
〜WinFXアプリはWindows XPで動かない?



バイオノートX505

 12日発表のバイオノートX505をはじめ、モバイルPCにも新製品発表が続くこの時期。この年末はX505、先に発表されていたLaVie Jを含め、一時は絶滅するかとも思われたシングルスピンドルの製品に新製品が相次ぐ模様だ。Pentium M/Centrino登場時に行なった連続インタビューのように、少し“ゆるめ”の対談記事を年末商戦本格化までには掲載する予定だ。

 と忙しいハズのこの時期に、米国に約2週間、出かけていた。前半は先日開催されたMicrosoftのソフトウェア開発者向け会議「Professional Developers Conference 2003」(PDC 2003)、後半は半年ぶりの休暇、ということでしばらく連載もお休みしていたことをお詫びしたい。

 このところ、今ひとつ勤労意欲が沸いてこないこともあったのだが、たまの休暇は仕事への意欲を呼び起こしてくれるようだ。Intel製品のコードネームとして採用された地名が並ぶオレゴン北西部を移動していると、ことあるごとに仕事の目で米国の田舎を観察してしまう。

●ユーザーフロントエンドはまだまだこれから、だがしかし……

Longhornのデスクトップ

 さてPDC 2003では、ようやく次世代Windows、Longhornの開発者向けバージョンが配布された。このバージョンはユーザーインターフェイス、シェルの機能、ビジュアルデザイン、標準装備の便利機能などを評価するものではない。一部には実装されている(Windows XPに対する)追加機能もあるが、いずれにしろ最終仕様ではない。

 では開発者向けバージョンが持つ意味とは何か? と言えば、それはLonghorn向けアプリケーションが、実際に動作する環境を提供することにある。つまりソフトウェアがOSの機能を呼び出すAPIレベルで、一通り動作するものが提供されたということだ。

 MicrosoftはPDC 2003における質疑応答の場で、このあとしばらく開発者からのフィードバックを受け、4カ月後に各APIの振る舞いについて“固定”させると話した。APIそのもののおおまかな仕様は、今回発表されたWinFX(と下位互換のためのWin32)で決まったため、Longhornアプリケーションの開発は一応、可能にはなった。しかし、細かい振る舞いや機能に関しては4カ月後を見なければわからない、とも言える。

 これまでにあったLonghornのビルドは、いずれもWinFXをすべては実装していなかったそうで、プログラムコードを書いても実際には動作しなかった。Longhornの各種デモで、Microsoftが「これはあくまでもLonghornで実装予定の機能をデモする目的で作ったもの」と強調していた理由だ。

 今回はそれが実装されたわけだが、それでもまだOS単体でLonghornの機能を“見る”ことはできない。シェルやその他機能が、WinFXの機能をフルには利用していないからだ。たとえばPDC 2003の基調講演で見せられた、スクロールバーにマウスカーソルを合わせると、そのページのプレビューが半透明に表示される、という機能。これは機能デモで、WinFXを使えば簡単に実現できるものだが、開発者向けバージョンのシェルや付属アプリケーションではまだ使われていない。

 よってLonghornがどんな使い勝手になるのか? といったエンドユーザー的視点で、Longhornを見ることはできない。それが可能になるのは、来年の中頃に予定されているβ版を待つ必要がある。Windows XPのときも、開発者向けバージョンからβ版において、ビジュアル要素の大きな変化があった。エンドユーザーから直接見える部分が決まるのだ。今回のリリースの画面ショットを見て一喜一憂する必要はない。

 とは言うものの、APIがほぼ決まったことで見えてきた部分も多い。

●すべてのアプリケーションで

 ここでLonghornのWinFXについて詳細に紹介することはしない。が、簡単に説明しておくと、従来、OSの機能を構成していたサブシステムの機能を直接呼び出す関数としてAPIが定義されていた(Win32)のに対して、Windowsの機能をさらに仮想化しクラスライブラリで包んでいるのがWinFXだ。

 良い例えがあるといいのだが、ピタリと当てはまる例が思い浮かばない。部品をひとつひとつ組み合わせ、ディスクリートで組み上げるのがWin32。WinFXはアセンブルパーツやIC、LSIを用いてよりシンプルに組み上げる手法。とでも言おうか。

 WinFXを用いると、セキュリティや各種機能との連携、ビジュアル効果などについて、システム側が面倒を見てくれる。特にセキュリティに関しては、WinFXを用いることでより仮想化の度合いが進み、アプリケーションのプログラムミスによってセキュリティホールが発生する可能性が下がるだろう。

 個人的にはせっかくWinFXを採用するならば、Win32そのものを仮想化してしまい、WinFXの上に載せる(パフォーマンスは落ち、互換性も100%は取れないだろうが、セキュアにはなるはずだ)方が良いと思うが、MicrosoftはWin32を従来通りWindowsサブシステムを直接呼び出す関数型のAPIとして残すとのこと。

 つまりWin32を呼び出している限り、一部の機能を除いて従来と変わらない動作となる(一部とは、たとえば96dpi前提で描画を行なっているアプリケーションを、拡大縮小機能で正しくLonghornの可変dpiスクリーンに表示するといったこと)。

 では、なぜWinFXが必要になったのか。様々な理由があるが、ひとつにはPCがサポートするデバイスやネットワークの種類が増え、アプリケーション開発が複雑になり、Windowsとして統一的な解決策を提供できなくなってきた、というのが、最大の理由ではないかと思う。

 たとえばDOSの時代は、グラフィック機能にアクセスする統一的なアプローチは存在しなかったし、マウスを用いたユーザーインターフェイスにも共通の枠組みは無かった。統一しようという動きはあったものの、成功したとは言い難い。

 これがWindowsになると、グラフィック機能にアクセスするAPIが定義され(現在のGDI)、すべてのアプリケーションが同じようにグラフィック機能を利用可能になる。その後、Windowsはユーザーインターフェイス部分の強化も進められ、緩やかながらもユーザーインターフェイスが統一されるようになった。

 上位のAPIが使われるようになると、そのシステムの上で動作するプログラムは、自ずと統合されていく。たとえばMicrosoftはWebサービスとWindowsソフトウェアを統合するため、.NETフレームワークを開発の枠組みとして用意している。しかし、これはあくまでも開発の枠組みであって、その枠組みで作ったアプリケーション内の閉じた話になる。これがWinFXになれば、すべてのアプリケーションがWebサービスとWindowsソフトウェアの統合された枠組みの中で動作するようになる。

 この“すべてのアプリケーション”という部分が重要だ。多くのユーザーが望む機能は、プログラムレベルで実装しようと思えば、たいていのことは実現できてしまう。しかしひとつのプログラムが実現しても、そのプログラムでの出来事に過ぎない。これがOfficeなどの複数アプリケーションの集合体ならば、もう少しマシだろうし、汎用開発フレームワークにまでなってしまえば、ある程度の広がりも期待はできる。

 ただ、本当に変化を起こすためには、OSそのものが変わらなければならない。そのためにWinFXが必要なのだ。

●たとえばこう変化する

 Longhornは、ほとんどの機能に変化がもたらされるため、何かひとつだけを取り出して例にするのは難しい。その中でモバイルユーザー向けに例を挙げるとすれば、WinFSの持つ複製機能がある。

 WinFSは現在のファイルシステムであるNTFSにSQLデータベースを組み合わせた、より高機能なストレージの仕組みである。WinFSを用いることで、たとえば現在は電子メールや住所録なども、システムで統一された管理が可能になる。

 WinFSにはいくつか標準のデータスキーマがあり、その中には住所録を管理するためのコンタクト(連絡先)スキーマがある。またスキーマはユーザー定義も可能で、コンタクトスキーマなどの標準スキーマの上に被せて、電子メール、住所録、スケジュールなどを統一的に扱うスキーマを定義することもできる。

 従って、これらの情報を扱うアプリケーションが、WinFSを用いて情報を保存するようにプログラムすれば、WinFSの機能を用いて全文検索、(複数PC間でデータベースを複製・共有し)同期といったが利用可能になる。

 現在、Webページやネットワーク共有しているファイルを、Windowsの同期機能を用いてモバイルPCに複製し、活用しているユーザーもいると思うが、WinFSになれば同様にアプリケーションデータも簡単に同期可能になるわけだ。WinFSの同期マネージャは、プラグイン経由で様々なデバイス(PDAや携帯電話)との連携もサポートする。

 また標準スキーマで扱うデータは、システム内で一意のデータとして扱うことができるため、複数のアプリケーションで住所録を共有することも可能になる。電子メールのアドレス帳、PIMソフトの住所録、ハガキ印刷ソフトの住所録が、同じデータベースを使うようになれば、情報の管理はずっと楽になる。

 つまり、これまでアプリケーションが、個々に勝手にプログラムしていた機能が、Longhornで標準サポートされることで、より使いやすくなると言える。アプリケーション開発者にとっても、直接実装しなければならない機能が減ることになり、開発効率が向上することになる。

●とはいえ懸念材料はある

 Windowsサブシステムの機能が仮想化され、より上位のレイヤからWindowsの機能を利用するようになるということは、言い換えればプログラマの自由度が、WinFXの持つ機能によって制限されることを意味する。これまで好き勝手にプログラムしていたことも、WinFXの元では(不可能ではないにしろ)難しくなる。

 だからWinFXはアプリケーションの機能を制限しないためにも、非常に規模の大きなものにならざるを得ない。WinFXでサポートされない機能を、WinFXの上に実装するのは大変な作業になる。そんなときには、より小回りの利くWin32でチョイチョイとプログラムした方が楽ということもあるだろう。

 Microsoftはひとつのアプリケーションで、Win32とWinFXを混在利用することは可能だと話している。Win32とWin32用のクラスライブラリを使ってプログラムすることに慣れたユーザーが、どこまで積極的にWinFXを使ってくれるか、というのはひとつの懸念材料だ。

 WinFXを用いて開発をしてしまうと、Windows XP以前のWindowsでは動かないプログラムが出来上がることになる。しかしWin32で書けば、Windows XPでもLonghornでも動くプログラムにすることができる。さて、どのような選択が開発者にとって良いものになるだろう? Windowsのアップグレード率は、決して高いものではない。世界中のWindowsがLonghornになるには、かなりの時間が必要だろう。

 もしかすると、ほとんどの部分をWin32ベースで開発し、いくつかの部分について限定的にWinFXを使う(Windows XP/2000をサポートするため、Win32版も用意)アプリケーション、あるいは全くWinFXを使わない製品といったものがほとんどになるかもしれない。

 Microsoftにしてみれば、Windows XPでは実現し得なかったような新しいアプリケーションがLonghornベースで開発されれば、従来型アプリケーションはWin32のままでもいいと考えているのかも知れない。

 ただ、それでも現行OSとLonghornの橋渡しを行なう、何らかの解決策は必要ではないだろうか。たとえばかつてWin16環境下で、限定的ながらWin32の動作を可能にしたWin32sといったソリューションだ。Windows XP+.NETフレームワークの環境で、Indigoベースのアプリケーションを動かしたり、WinFSをストレージとして設計されたアプリケーションをWindows XPで動かすための互換レイヤが無ければ、ソフトウェア開発者はLonghornアプリケーションを思い切って開発できないだろう。

 これらに対してどのような解答をMicrosoftが用意するのかは、今のところわかっていない。

□関連記事
【11月5日】Microsoft Professional Developers Conference 2003レポートリンク集
http://pc.watch.impress.co.jp/docs/2003/link/pdc03.htm

バックナンバー

(2003年11月13日)

[Text by 本田雅一]


【PC Watchホームページ】


PC Watch編集部 pc-watch-info@impress.co.jp 個別にご回答することはいたしかねます。

Copyright (c) 2003 Impress Corporation All rights reserved.