次期Windowsとしての基本仕様を公開したWindows8だが、今回配布されたものは、β版以前のマイルストーン3と呼ばれるもの。おおまかな内容は決まったが、細かい部分はまだ詰められていないし、今後、機能追加や削除もありえる。今後のおおまなかなスケジュールとしては、
| 2012/01 | β版 |
|---|---|
| βテスト期間 | |
| 2012/04 | RC1 |
| RC版のフィードバック期間 | |
| 2012/07 | RTMおよび正式発表 |
| 製造段階 | |
| 2012/10 | 最初の出荷(プレインストールマシンか) |
となると予想される。おそらく、Windows 7のときとほとんど同じスケジュールで進むと思われるが、不測の事態などにより、遅れる可能性もある。開発を担当するシノフスキー氏は、Windows 7をほぼスケジュール通り開発しており、今回も大きな問題はないと考えられる。
さて、このWindows 8だが、さまざまな新しい機能、新しいユーザーインターフェースなどがあるが、その本質、つまりマイクロソフトは、Windows 8で何をしようとしているのだろうか?
ソフトウェア製品である以上、機能を追加したり、ユーザーインタフェースを向上させるというのは、バージョンアップに際しての当たり前の作業である。そういう意味では、電源完全オフからの高速起動や、電源オフをやめてスタンバイとする「Connected Stand-By」といった機能は、単なる機能向上の1つでしかない。また、タッチによるタブレット対応なども、世間の動向に追従するバージョンアップでしかない。
では、Windows 8の最大のポイントはどこなのか? 筆者は、新しく作られたWindows Runtime(WinRT)なのではないかと考えている。
|
WinRTは、Metro Styleのアプリケーションに対して、粒度の大きなAPIを提供する。しかし、Windowsの機能すべてを提供するわけではない |
WinRTは、Metro StyleのためのAPIセットであり、従来のUnmanaged Code(CやC++を使って作られる機械語コード)、Managed Code(C#やVisual BASICで開発するCLRで動作するコード)および、HTML+CSS+JavaScriptとの3つの言語環境に対して、同じオブジェクトを提供する。
|
WinRTは、Unmanaged(従来の機械語コード)、Managedコード(CLRのコード)とHTML+JavaScript環境(WinJSと呼ばれる)に対して同一のオブジェクトを提供することで、APIとしての役目を果たす。しかし、WinRT自体は、従来のWindowsのカーネルやWin32サブシステムを利用している |
Managedコードにだけついて言えば、これは、.NET Frameworkの再構築である。Windowsは、本来からのWin32 APIを持っていたが、さまざまな拡張の末、特定のマシンで何があって、何がないのかなどをアプリケーションが起動前に調べない限り、どうなっているのかわからないような状態になっていたこと、特定のアプリケーションと結びついたAPIセット(たとえば、メディア再生の機能は、Windows Media Playerに含まれる)があり、全体の見通しを悪くしていた。これに対して、APIに含まれるものの範囲を確定させたのが.NET Frameworkだ。しかし、.NET Frameworkは、Win32 APIを整理はしたが、APIの「粒度」として同じであり、たとえば、Webカメラで画像をキャプチャする(いわゆる静止画を撮影する)ためには、デバイスを扱うAPIを使って、画像を入手するという手順を記述しなければならない。このため、デジカメのように撮影前にプレビューを表示するなどという処理も自前で用意しなけばならず、カメラアプリケーション自体をユーザーが作る必要があった。
これに対して、WinRTが提供するのは「Media Capture」と呼ばれるAPIで、静止画だけでなく動画(もちろん音声も)のキャプチャ機能や、撮影前のプレビュー表示、撮影後のクリッピングなどの補助機能までを含む。
こうした粒度の大きなAPIは、最近のiOSやAndroidなどでは普通に提供されており、ある意味、現在では、普通のことになっている。たとえば、Androidの場合、カーネルにLinuxを使っているが、Linuxとしての機能はカーネルと基本ライブラリの一部のみを使い、アプリケーションはJavaで記述するために、いわゆるAPIとしてはJavaのオブジェクトが提供される。
ところが、Windowsは、これまで、こうした粒度の大きなAPIはほとんど提供しておらず、このあたりは、サードパーティやオープンソースプロジェクトが補完していた格好になる。しかし、世界中で使われ、さまざまなハードウェアを対象とするWindowsでは、すべての場合をカバーするのは困難だった。
つまり、WinRTは、粒度の高いAPIセットを「公式」なAPIとして提供することにあり、これによって、.NET Frameworkなどを補完して、「モダン」なオペレーティングシステムに生まれ変わらせるという役目があるのだと推測される。
1つには、iPadやAndroid タブレットなどに対抗するために、開発者向けの環境を整えたいという部分もあると思われる。そうでなくても、現在の多くの開発者にとって、.NET FrameworkやWin32は、必要十分ではあっても、「使いやすい」ものでもなければ、「簡単」なものでもない。さらにいえば、アプリケーション配布と課金の仕組みがないために、簡易なアプリケーションを販売したり、配布する方法もない。セキュアな配布方法は、ウィルスなど日常的にユーザーが危険にさらされている現在では、オペレーティングシステムが用意すべき必須の機能といえるだろう。マイクロソフトは、これを「Store」で行おうとしている。
こうした方向性があるものの、今回のBuildでは、アプリケーション実行環境としてのWindowsに対しての明確な方向性を示す発言がなかった。開発者にしてみれば、.NET FramworkやWin32を使い続けていいのか? WinRTに早期に対応すべきなのかという問題がある。WinRTは、たしかに便利だが、現時点では、Windows 8でしか動かない。だから、WinRTの勉強はできても、対応をどうすればいいか判断しかねる状態だ。
おそらく、Microsoft自身にもまだ、迷いがあるのかもしれない。Vistaの開発中、PDCでは、当時開発を担当していたオルチン副社長は、.NET FrameworkはWinFXとして次世代の標準APIとなるとぶち上げたものの、結局、.NET Frameworkは、次世代の標準APIになってはいない。
今回、WinRTの扱いが控えめなのも、こうした背景があるからかもしれないが、オペレーティングシステムの開発元としては、もう少し明確なメッセージを出すべきと考えられる。このまま明確なメッセージがないと、かえって開発者に混乱を引き起こす可能性さえある。おそらくβ版あたりで、もう少し明確な態度が示されるのてはないか。
