次期Windowsの 『Threshold』のWinRT APIについて考えてみる。

次期Windowsの 『Threshold』のWinRT APIについて考えてみる。

Windows 8.1がリリースされたばかりだというのに、気が早いもので次期バージョンのウワサがささやかれているようです。コードネーム『Threshold』と呼ばれる次のWindowsは予定通りにいけば2015年の春にリリースされるそうです。

ま、いままでの例で行くとリリースされたWindowsの評判がイマイチな時ほど、次のWindowsのウワサが早くでてくる傾向があるので、Windows 8.1の動向も気になるところでもあります。

さて、今のところ分っている次期Windowsでのトピックは大きく以下の2つです。

  1. スタートメニューが戻ってくるかも。
  2. モダンスタイルのアプリがデスクトップアプリのようにウィンドウで使えるようになる。

Windows 8の登場以来、世間を騒がせているのはスタートメニューの廃止による一連の操作方法の変化なので(1)のスタートメニュー復活が気になる方も多いかもしれませんが、日曜プログラマの私としては(2)のモダンスタイルのアプリがウィンドウで使えるようになるという点は結構重要だと思うのです。

モダンスタイルのアプリとはメトロスタイルと呼ばれていたスタートスクリーンから実行するアプリケーションです。見た目や操作方法がかなり違うので、そっちに注目がいってしまいますが、実はAPIと呼ばれるプログラムの根本部分が異なっているのです。

APIについて話すと長くなりますが、一言で言えばプログラムがOSの機能を使うために用意されたモノです。例えばファイルを読み書きしたり、画面に何かを表示させたり、そういったことを実現するために必要なものです。

WindowsはWindows NT 3.1の時代からWin32 APIとよばれるAPIが搭載されていました。新しいWindowsが登場する度に新しい機能が使えるようになるので、Win32 APIはどんどん増えていきましたが、昔からあったAPIは基本的にはそのまま使えます。これがポイントです。

新しいWindowsでも古いアプリケーションが動くのは、そのアプリケーションが使っているAPIが新しいWindowsでも古いWindowsと同じように使えるからです。もちろん、様々な理由で必ずしも全てのAPIが新しいWindowsでも古いWindowsと全く同じように動作できないため、時々動作しないアプリケーションもありますが、簡単なアプリケーションであれば期待できるものです。

対応したアプリケーションがたくさんあるので、多くの人がWindowsを使っていて、逆に多くの人がWindowsを使っているから、対応アプリケーションもたくさん作られる。これがWindowsのエコシステムと呼ばれるものです。良い方向の循環ですね。

話を元に戻しましましょう。モダンスタイルとよばれるアプリは、Win32 APIとは異なるWindows Runtime(以下WinRT API)と呼ばれる新しいAPIが使われています。Windows RTでは、従来のデスクトップアプリケーションが使えないのは、Windows RTがWin32 APIをサポートしていない(使えない)からです。

Win32 APIはWindows NT 3.1からですが、登場から20年近くも経ったAPIです。それこそ開業以来つぎ足しつぎ足し使ってきた秘伝のたれのごとく、その時々で拡張されてきたため纏まりがつかなくなってしまいました。また、ハードウェアもソフトウェアもWin32 APIが設計された当時とは別世界になっていますから、そろそろ新しいAPIが必要になったとも言えます。

実は、Microsoftはこの20年間、APIについて何もしていなかったというわけではなく、10年ほど前から.Net Frameworkというjavaに近い発想の新しいAPIをWindowsに搭載したりしています。アプリケーションの動作環境に書かれていたりするので知っている方も多いと思います。

この.Net Frameworkの以下のような特長があります。

  1. 比較的簡単にバグの少ないプログラムを作れる。
  2. うまくいけばWindows以外のプラットホームでも動かせる?(javaのような感じ)

(2)に関しては10年経ってもWindows以外では使えるようになったとは聞かないのでうまくいかなかったということでしょう。プロジェクト自体は継続しているかもしれません。

そして、この新しいAPIでWin32 APIを置き換えるという壮大な計画を実行しようとしたのが、開発コードネームLonghornとよばれるWindowsで、後のWindows VistaとよばれるOSになるハズだったものです。なるハズだったというのは、この計画自体が失敗して一旦開発をリセットさせて、作り直したのがWindows Vistaだからです。

これが開発期間が長かった理由の一つです。結局.Net Frameworkは搭載されていますがWin32 APIを置き換えるには至らず、.Net Frameworkは内部でWin32 APIに変換されてWindowsに引き渡されるようなっています。現在もこのスタイルを引き継いでいて、APIの面ではWindows XP以前と大きく変わってはいません。

とはいえ、置き換えには至らなかったものの、.Net Frameworkが(1)のように、プログラムが作りやすく、バグが出にくいというメリットがあるため、徐々にこのAPIを使ったアプリケーションが増えてきてるのも事実です。

まだ、Win32 APIと.Net Frameworkという2つのAPIがある状況ですが、そこにを登場したのが新顔のWinRTです。WinRTの特長はざっくり言えば以下のような感じになります。

  1. 簡単に高機能でカッコイイアプリを作ることが出来る。
  2. うまくいけばパソコン以外でも動かせる。

.Net FrameworkはWin32 APIを置き換えることができるくらいの、かなり細かいこともできるAPIでしたが、WinRTどちらかというとWEBアプリのように高機能なアプリを簡単に作るのが目的のAPIのようです。また、移植性が高いので少なくとも近い将来、WindowsとWindows Phoneで共通に動くようになるハズです。

さて、話を戻して『Threshold』でした。Thresholdは、このWinRTで作られたモダンなアプリが、普通のデスクトップアプリケーションのように、ウィンドウ表示ができるようになります。そして、たぶんスマホ用のWindows(Windows Phone)とタブレット用のWindows(modern consumer[Windows RT相当])では、今のモダンアプリのように動作すると思われます。

つまり、まとめるとこんな感じになると思われます。

  1. 1つのアプリでパソコンからタブレット、スマホまでカバーできるようになる。
  2. WinRTのような高機能なAPIでデスクトップアプリケーションが作れるようになる。

WinRTは高機能でカッコイイアプリを作ることができますが、ハードウェアに依存することや速度を求められるものには向いていません。言ってみればカレーのルーのようなものです。野菜とお肉を入れれば美味しいカレーはできますが、大衆食堂ならいざしらず本格インドカレー屋さんレベルになると力不足というワケです。

ですから、デスクトップアプリケーションとして使えるようになっても、Win32 APIや.Net Frameworkを置き換えるようなことはないと思われます。とはいえ、いたずらにAPIをたくさん維持するのは作る側(Microsoft)も使う側(プログラマ)も大変なので、Win32 APIの動向は気になるところです。

ただ、Microsoftはこの手のことに一貫性があんまりないのは昔からでして、ついこないだも鳴り物入りで導入されたSilverrightというWEBアプリ用のフレームワークもトーンが低くなってしまいましたし、Vistaで導入されたガジェットもWindows 8で廃止になってしまいました。

余談ですが、ガジェットは、『Windows Vistaで最初サイドバーに固定』 → 『Windows 7でデスクトップアプリのように自由に配置』 → 『廃止』 という流れでした。『Windows 8でスクリーンに固定』 → 『次期Windowsでデスクトップアプリのように自由に配置』 → 『?』 と考えると穏やかではないですね。

そもそも、WinRTにはいくつか課題もあります。まず、特長である(1)に関しては、既にHTML5とJavaScriptが存在しています。こちらはブラウザ間での対応状況を整える必要があるとはいえ、Windowsに限らず、それこそブラウザさえサポートしていればプラットホームを選びません。

Windowsはパソコンでは圧倒的なシェアをもっていますが、スマホもタブレットも厳しい状況ですからエコシステムの力は頼れません。WinRTのモダンアプリがHTML5+JavaScriptにどう優位性を出せるかがポイントになります。

また、(2)に関しても、そこそこシェアのあるだろう古いOS(ここでいうとWindows 7など)では動かないというデメリットや、ソースコード(プログラムが記述されたモノ)やプログラマの知識などの資産を捨ててまで乗り換えるメリットがあるかが問われるわけです。

とくに後者に関してはWin32 APIから.Net Frameworkに完全移行できていない大きな理由の一つで(もう一つが動作速度)、そういった意味ではやや前途多難かもしれません。今後、じわじわと『Threshold』の情報がでてくると思いますが、APIが話題になることは少ないと思ったのでつらつらと書いてみました。

Microsoftの方も試行錯誤しているようですし、そもそもパソコンやタブレットなどのライフスタイル自体が『Threshold』の登場するころには大きく変わっているかもしれません。  そんな、未来を楽しみにしながら、Win32 API 消えないで欲しいなぁとささやかに祈ることにします。ずっとWin32 APIでプログラムを書いている日曜プログラマとしては。