●ただWinFXを乗せただけ?

　昨日のレポートで、WinFSのデータベースエンジンが動いてないと書いてしまったが、これは筆者の間違い。実際には、音楽用ファイルの格納場所として、データベースを使ったファイルシステムが動作している。慌てていたので、見落としてしまっていた。読者の方々にお詫びするとともに、ここで記事を訂正させていただきたい。

　このデータベースファイルシステムだが、エクスプローラーで見ると通常のフォルダのように見える。しかし、フォルダのプロパティを見ると、フォルダとはあきらかに違っている。

　昨日のレポートで報告したとおり、Longhornは標準のAPIとしてWinFXを採用する。APIとしてのWinFXは、現在の.NET Frameworkの延長上にある。WinFXをオブジェクトとして見ると、.NETの「System」クラスに属するものとして実装されている。

Longhorn Architechture(再掲)

　PDCで公開されたLonghorn Architechtureの図を参照していただくとわかるが、Longhornは、簡単にいうと、Windows XPと同じ構造のOSの上にWinFXが載ったものとなっている。

　そのため、この図を見る限りカーネルやサブシステムがWindows XPと非常に似たもの(あるいは同じ物)のように見える。

　ではWinFXは、従来のXPのバージョンアップ版の上に乗っているだけなのだろうか? PDCの展示会場にあるMicrosoftブースで、いろいろと話を聞いてみた。

　その話をまとめると、Longhornは単純にWinFXが乗ったものではないようだ。WinFXで呼び出された機能を単純に既存のWin32コールで実現してしまうと、まず効率が悪く、スピードが出ない。それで、WinFX側もある程度下位のモジュールを呼び出すことになる。となると問題は、Win32経由での同等の機能呼び出しである。

　同じようなモジュールが同時に1つのデバイスやリソースなどにアクセスすれば、競合が起こる。WinFXを単純にWin32に変換してやれば問題は起きないが、それでは本来、標準となるべきWinFXアプリケーションの効率が犠牲になってしまい、ひいては、WinFXの普及にも影響する。

　また、WinFXは、Win32 APIに対しても、WinFXでアクセスしたのと同様にファイルを見せなければならないので、Win32 APIからのファイルアクセスは、最終的にWinFS側で処理する必要がある。

　しかも、Win32 API側でも従来と同等な性能を確保する必要がある。非常に単純な解決方法として、Win32 APIを逆にWinFXに変換して処理してやる方法があるが、それではWin32 APIの実行効率が悪くなってしまう。

　考えられる解法としては、機能モジュールがWin32もWinFXも同時に処理するという方法だが、となると、Longhornでは、現在のWindowsの中にあるWin32 APIに関わるモジュールをすべて書き換えることになってしまう。

　WinFSは、NTFSやそこに置かれたデータベースファイルなどをSTOREという、ユーザーに見える仮想的なファイル格納場所(ドライブや共有フォルダのようなもの)として扱う。Win32経由でのアクセスであっても、このSTOREを扱うことができる。

WinFSは、Win32からのアクセスをサポートする。WinFSが持つデータベースを使ったStoreであっても、Win32からは、普通のファイルのようにアクセスできる。しかし、ファイルではない、コンタクト(アドレス帳に相当するデータ)や電子メールにはアクセスできない	WinFSでは、StoreをUNC形式でアクセスでき、ネットワークフォルダ内にある自分自身を開けば、標準で作られるStoreにアクセスできる(写真左上のウィンドウ)。さらに、CドライブのNTFS上に作られたDefaultStore内(写真右下のウィンドウ)には、Music Storeに格納したファイルが入っていることがわかる	WinFSは、ファイルに対する変更に対してイベントハンドラを呼び出すように設定できる。アンチウィルスソフトをイベントハンドラとして登録すれば、ファイルが変更される前に内容をチェックできるようになる

Storeの1つであるMusicフォルダ(Music Store)と、筆者がCドライブ上に作ったフォルダのプロパティの比較。データベースファイルが実体となるMusic Storeは、フォルダとは違ったプロパティ表示となる	Win32にしか対応していないソフトウェアで、Music Storeの中をアクセスしたところ。WinFSのサポートにより、ファイルのようにアクセスが可能となる

　前述の図をみると、現在のWindows XPなどに存在するモジュールが書かれており、WinFXの下には「昔のWindows」が隠れているようにも見える。部分的にはそうなのだろうが、Longhornで新たに書き換えられ、実際にはWinFXスタイルのAPIだけしか残っていない部分もかなりあるはずだ。

　Indigoもかなり複雑な構造となっている。たとえばIndigoは、Webサービスのためにトランザクション機能を提供している。Webサービスでは、HTTPとSOAPを使った通信も利用できるが、その中で確実なトランザクション処理を行なわせることは困難である。

　このため、Webサービスでトランザクションを使用するオプションが指定されている場合、クライアントプログラムとは別にマネージャーを動かし、これが、サーバー側のリソースマネージャーと通信するようになる。

　クライアントが発行するコミットやロールバックの要求は、このマネージャを経由してやりとりされ、サーバー側のデータベースエンジンをリソースマネージャが直接コントロールしてしまう。このため、クライアント側のプログラムには、コミットやロールバックの処理ルーチンがあるのに、サーバー側のルーチンにはそれを処理するコードがまったくないといった一見奇妙なプログラムとなってしまう。

　もしかしたら、このあたりの問題をMicrosoftも認識しているため、リリース時期を明言できないのかもしれない。ある意味、対象が広範囲になるため、Windows 2000では間に合わず、Windows XPで実現したWin95系カーネルとNTカーネルの統合より複雑な問題ともいえる。

　PDCで配布されたβ版だが、これは、多くの部分が単純にWin32の上にWinFXが乗っている可能性は高い。つまり、論理的にはWinFXだが、インプリメンテーションはまだ最終版と違っていると思われる。キーノートスピーチで、Allchin副社長が「クラッシュもない」と自慢したが、こういうインプリメンテーションであれば、下の部分はWindows XPと同じ。安定しているはずである。

□PDC 2003のホームページ(英文)
http://msdn.microsoft.com/events/pdc/
□関連記事
【10月29日】【PDC】Longhornの詳細が明らかに
http://pc.watch.impress.co.jp/docs/2003/1029/pdc01.htm
【10月29日】【海外】ついにベールを脱いだ次世代Windows「Longhorn」
http://pc.watch.impress.co.jp/docs/2003/1029/kaigai039.htm

(2003年10月30日)

[Reported by 塩田紳二]