News | 2003年10月30日 01:59 AM 更新 |
Windows+αの機能をクラスライブラリで覆う
PDCで配布されている資料や技術セッションでのコメントによると、WinFXとはいわばクラスライブラリの固まりのようなものだ(関連記事)。従来のWin32 APIは単純な関数呼び出しの形式を取っていたが、WinFXはすべてのWindows機能、そしてLonghornからの追加機能を「クラス」として定義し直している。
前日のレポートにあったように、WinFXはOSとしての基盤部分(Fundamentals)の上にプレゼンテーション(Avalon)、ストレージ(WinFS)、コミュニケーション(Indigo)のクラスが載っている。Longhornネイティブのアプリケーションは、これらのクラスを呼び出すことでOSの機能を利用することができる。ちょうどNeXTStep、現在のMac OS Xに近い実装と言えるかもしれない。
従来のWin32で呼び出していた各種サブシステム、たとえばGDI、DirectXやNTFS、DFS、ネットワークスタック、ウィンドウ管理などのシステムAPIは、ほぼFundamentalsで割り当てられたクラスに含まれる(ウィンドウ管理、GDI、オーディオ、DirectXはAvalon、上位のストレージサービスはWinFS、ネットワーク機能の一部はIndigoに含まれる)。
WinFXのFundamentalsはクラスとして再定義され、よりセキュアで信頼性の高いものになっているが、その下にあるのは従来のWin32と同様のモジュールだと考えられる。
またAvalon、WinFS、Indigoなども、その下のレイヤーにはWin32と同等の機能モジュールが存在するはずだ。そうでなければ、従来のWin32モデルに合わせて作られたドライバやサービスモジュールなどとの互換性を取ることが難しくなるからだ。これら三つのパートはAPIというよりは開発フレームワークそのものであり、複雑に多くの機能が絡み合うWindowsの機能を目的ごとに分かりやすく包み、OSの機能を仮想化する。
実際に開発の現場がどのように変化するかは、開発者自身で開発者向け情報にアクセスするのがいいだろうが、われわれエンドユーザーにはどのような影響があるのだろうか。
“可能性がある”と“できる”は違う
端的に言えば、今までも可能だったことが、きちんとできるようになり、実際に使えるようになる、ということかもしれない。これまでにもWindowsには実装されているが、実際には使われていない機能はたくさんあった。例えば今はほとんど使われていないブリーフケースという機能がある。ブリーフケースはユーザーインタフェースが使いにくかったから廃止された、とMicrosoftは説明していたが、もうひとつ、対応するアプリケーションが「皆無だった」という理由もあったと思われる。
ブリーフケースはファイル単位での同期を行う機能として知られている。しかし、Windows 95でブリーフケースAPIと呼ばれるAPIが定義され、そのAPIに対応したプラグインを追加することでレコード単位の同期などにも対応できる構造になっていた。現在のOfficeが対応しているかどうかは不明だが、Office 95のAccessはデータベースをブリーフケース経由でレプリケートし、レコード単位での同期が行える。だが、この機能を利用したアプリケーションを、筆者はほとんど見たことがない。
もう少し身近なところだと、グラフィックスのアルファブレンディングによる半透明表示がある。アルファブレンディングはかなり前からWindowsでサポートされ、グラフィックアクセラレータにもハードウェアで実装されている。しかし、Windows 2000以降のメニュー表示エフェクトで使われている以外、実装例をあまり見ることはない(最近、Outlook 2003が着信メッセージのお知らせに利用している)。
Windowsアプリケーションは、画面エフェクトが素っ気なくつまらない、といった意見をかつてはよく聞いたものだが、WindowsでもMacOS Xのような半透明表示を利用した画面効果は十分に実行できるし、実際にそれをハードウェアで支援する機能まで何年も前から存在しているのに、それが使われていないだけなのだ。
これはDirectXにも言える。DirectXは元々ゲーム用に作られただけあり、リッチなユーザーインタフェースを実現するのに役立つ数多くの機能がある。グラフィックチップベンダーも、高度なDirectXの機能を実装するため、膨大なトランジスタを持つGPUを開発している。ところが、ゲーム以外のアプリケーションはGDI/GDI+が存在することもあって、DirectXを活用することはほとんどない。現在のDirectXはさまざまなメディア再生をサポートするなど、決してゲーム専用のAPIではないのだが、現実にDirectXを使った一般アプリケーションは皆無に近いのである。
結局、APIと機能が存在し、実装する“可能性”を提供することと、より積極的に“できる”ことは違う。WinFXを用いると使い方次第で、WinFX自身がさまざまな機能を利用する。もちろん、プログラマーがLonghornの新機能を積極的に利用する方が、より高度な“ユーザー体験”をもたらすかもしれないが、従来通りの使い方をしていても、フレームワーク側の機能が失われることはない。
例えばAvalonでは、ほとんど苦労することなくオーディオやビデオをアプリケーションに統合できるし、従来よりも凝った画面効果もパラメータ一つで実現できる。Indigoを用いればリアルタイムコミュニケーション機能をアプリケーションに統合し、ネットワークを通じた情報共有機能を簡単に実装できてしまう。
もちろん、WinFXのような巨大なクラスを扱うことは、それなりに大変なことではあるが、いちいちローレベルのAPI呼び出しを繰り返しながら機能を実装するよりは、ずっと簡単で手間は少ない。Win32で画面上のコントロールを透明度を変化させ、浮き上がらせながらアニメーションさせるといった画面効果をプログラムする人はよほどの物好きだと思うが、Avalonならば忍耐強くプログラムすることなく同じことができるのだ。
先ほどDirectXがゲーム以外のアプリケーションでは、必要でない限りほとんど使われないと述べた。だが、AvalonはDirectXもGDI/GDI+も統合したフレームワークで、最終的にはすべての描画がDirect3Dに変換、処理されるため、開発者はDirectXを意識せずにGPUの機能を利用できる。MicrosoftはAvalonのデモプログラムとして、ウィンドウの拡大縮小表示や、各種コントロールの回転表示、トランスペアレント処理、ウィンドウのラスタアニメーションなどを見せていたが、いずれもサンプルコードを見せてもらうと実にシンプルなものだった。
システムの整合性向上にも効果期待
もうひとつ期待したいのは、システムの整合性が向上することである。たとえば今年5月のWinHECで、Longhornではカラーマッチングが大きく改善されると書いた。Longhornでは、その中で扱われるカラー情報すべてが、色に関する履歴、プロファイルを持つからである。
しかし、これまでもカラーマッチングシステムは実装されており、すべてのアプリケーションがカラーマッチング対応していれば、色に関してそれほどケアする必要はない。簡単なユーティリティはともかくとして、画像を扱うソフトウェアだけでも全部が対応していれば、かなり状況は変化するだろう。ところが実際にはイメージビューアはもちろん、フォトレタッチソフトの中にもカラーマッチングに対応していない製品は多数あり、正しくない色で見たり、編集したり、といったことが起こってしまう。
しかしカラーマッチングの機能はWinFXではフレームワークの中に入っているため、普通に作ればカラーマッチングを意識せずに色が合うアプリケーションになってくれる。カラーマッチングは、利用するプログラムすべてが対応していなければ効果が薄いため、この差は非常に大きい。
これはセキュリティに関しても同じだろう。セキュリティを考慮して設計されたフレームワークをアプリケーションが使えば、少なくともアプリケーションのバグでセキュリティ問題が起きることはなくなる。もちろん、WinFX自身が重大なバグ、仕様的な問題を抱えていれば話は別だが、よりシステムに近いAPIを利用するよりはずっと安全性が高くなる。インターネットが爆発する以前に設計されたWin32では、対策を施すにしても限度があるが、より仮想化の度合いを高めたWinFXのクラスならばセキュリティレベルを上げることも可能なハズだ。
現在は絵に描いたモチでしかないLonghornだが、その可能性に賭けたいと考える開発者は少なくないだろう。それは過去最大規模と思われるPDCで、熱心に技術トラックを聞き入っている多くの開発者たちの表情にも現れていた。
[本田雅一, ITmedia]
Copyright © ITmedia, Inc. All Rights Reserved.