プログラマから見たWindows 10 #1 ~プラットフォームの全体像

開発の橋本孔明です。

5月に米国で開催されたマイクロソフトの技術カンファレンス「BUILD」に続き、日本でも「de:code 2015」が開催されました。今回これに参加し、Windows 10に関するセッションを受講してきましたので、そこで得られたトピックをご紹介します。

Windows アプリケーション開発者の視点から、Windows 10の全体像や、大きく変化するアプリケーション開発上での注意点などをまとめていきたいと思います。

Windows 10で復活したスタートメニュー

Windows 10で復活したスタートメニュー

1回目は、BUILDおよびde:codeで示された、Windows 10プラットフォームの全体像を見てみます。

* 本記事は、de:codeのセッション、「Windows 10 Insider Preview Build 10130」および「Visual Studio 2015 RC」を元に執筆しました。筆者の個人的見解および解釈が含まれていることをご了承ください。

いよいよコアが一本化されるWindowsと「Universal Windows Platform」

90年代後半から2000年代初頭にかけ、Windowsは「9x」と呼ばれる16ビット コア システムと、Windows NT系の32ビット コア システムが併存していました。Windows XP世代でこれらの統合が実現しましたが(32ビット版と64ビット版があるものの違いは僅か)、Microsoftではそれ以外のプラットフォームとしてゲーム機である「Xbox」、モバイル端末向けの「Windows CE」、その後継であるスマートフォンOSとしての「Windows Phone」などを抱えていました。

Windows 10世代においては、MSがずっと追い求めてきた「すべてのWindowsエディションのシステム コアの統合」がついに実現することになりました。PC・スマートフォン・タブレット・Xbox One・IoTデバイスなどのすべてにおいて、同じコアを持った「Windows 10」ファミリーのOSが提供されます。マイクロソフトでは「One Windows」や「Windows OneCore」と銘打っています。

ではOSを共有することでどのようなメリットがあるのでしょうか。

デバイス ドライバの統一

デバイス ドライバの開発インターフェースが全デバイスで共通になることで、CPUターゲット(x86、x64、ARM)さえ合わせればどの環境でも動作するデバイス ドライバを書けるようになります。

Windows用のデバイス ドライバというのは、大半の周辺機器において最初に開発されるものですから、AndroidやiOSではデバイス ドライバがなく使用できなかった機器も、Windows 10を搭載したスマートフォンやタブレット、ひいてはIoTデバイスのような環境であっても、使用できる可能性が高まります。

管理方法の統一

システムの管理方式が統一されるため、企業内で使用するスマートフォン・タブレット端末といったデバイスがWindows 10に統一されていれば、すべて同じセキュリティ ポリシーやアカウント体系を適用できるようになります。これはセキュリティ面からも大きなメリットとなるでしょう。Windows Phoneが企業向けに有力と目されている理由のひとつです。

アプリケーションの互換性は…

アプリケーションの互換性という点においてですが、同じOSといっても動作するデバイスごとにCPUなどの環境が大きく異なるため、従来からあるWin32ネイティブ アプリケーションがどの環境でも動作するというわけにはいきません。また、そのような問題を解決する方策として、中間言語方式を採用した.NET Frameworkというプラットフォームもありますが、Windows 10においては従来の.NET Frameworkは原則としてデスクトップPC(およびIntel CPU搭載タブレット)向けのエディションのみをサポートするとされています。

では、どのプラットフォームでも動作するアプリは…というと、これを実現するのが「Universal Windows Platform」(UWPという略称もよく使用されます)です。UWPアプリとして開発したアプリのみが、すべてのWindows 10ファミリーで動作するものとされています。

Windows 10は最後のメジャーバージョン。収益モデル転換へ

現在、マイクロソフトではWindows 10を「最後のメジャー バージョン」と定義しています。これまでOSの大規模な機能強化というと、OS自体のメジャー バージョンアップによって実現されるのが定番でしたが、今後はOSの機能強化もWindows Updateを通じて無償で行われていくことになります。

こまめなアップデートに加え、Windows 8から8.1へのアップデートと似たような状況も発生するでしょう。8から8.1のアップデートは、OS内部バージョンが6.2から6.3に変更されるなど、内部的にはかなり大規模な変更となっていました(ちなみに、Windows Vistaは6.0、Windows 7は6.1でした。Windows 10は最初のTechnical Preview版までは6.4でしたが、次から10.0になっています)。

これは、マイクロソフトの収益モデルが「OSの販売」から「Office 365」や「Windows Azure」への課金といったサブスクリプション中心へと変わりつつあることを示しています。「Windows as a Service」という標語もその流れを示したものといえるでしょう。Windows 10そのものへも、Windows 7/8/8.1からは無償でアップグレードができることになっています(ただし、OEMメーカーがアップグレードへ対応するためのサポート コストを低減するといった理由から、この無償アップグレードは1年間限定とされました)。

なお、Windows 10を利用する企業ユーザーなどで「勝手に機能が変わっていくのは困る」というケースも充分考えられることから、セキュリティ アップデートなどの緊急的なものに限って適用するという選択肢も提供されます。

また、定期的に大きなアップデートが行われるため、現在実施している「Windows Insider Program」が継続され、Insider Programに登録しているユーザーを対象にしたアップデート要素の先行テストも行われるとのことです。

UWPの技術的内面

1回目の最後は、開発者から見たWindowsという観点で、UWPそのものの技術的側面を少し見てみます。

UWPアプリがウィンドウモードで複数動作している様子

UWPアプリがウィンドウモードで複数動作している様子

UWPはストアアプリの進化形

UWPは、Windows 8で導入された「Windows ストア アプリ」用のプラットフォーム(WinRT)を拡張したような形態です。ストア アプリと同様にC++/CXやC#、VB.NETなどの言語と、XAMLベースのユーザー インターフェース定義(あるいはDirectXによる画面直接描画や、HTML+CSSによるUI定義)を組み合わせて開発を行うことができます。

UWPアプリケーションはWindows ストア経由で配布され、インストール状況やアプリが参照・使用可能なデータ領域も完全に管理されたものとなります。このあたりはWindows 8/8.1用のストア アプリと同様です。

また、ストア アプリはかなり制限のきついプラットフォームでしたが、UWPでは各所の制限が緩和されたり、より低レベルな要素にアクセスできるAPIを追加するといった拡張も行われています。詳しくは今後の記事に載せたいと思いますが、従来のアプリケーションや、ゆくゆくは他社プラットフォームのアプリまで取り込めるよう、意欲的なAPI提供が行われるようです。

ストアからは各機種のネイティブコードのバイナリで配信

前述のように、UWPアプリが動作する環境はx86・x64・ARMといった複数のCPUタイプが考えられます。これらにすべて対応するためには、ストアに登録する際にすべてのバイナリ形式を提出(アプリ パッケージの作成プロセスの中で自動的に行えます)するか、中間言語形式(C#など)で提出することになります(ここまでは従来のストア アプリと同様)。

中間言語の場合は「.NET Native」テクノロジにより、ストア側で配布先ターゲットに合わせたネイティブ コードへのコンパイルを自動的に行ってから配布されるとのことです。つまり、最終的にユーザー環境にインストールするアプリは、対象のCPUアーキテクチャに合わせたネイティブ コードのバイナリ(ランタイム ライブラリは不使用)がひとつだけ入ったものとなります。ランタイムが不要となることで従来のようなランタイム バージョンの相違を気にする必要がなくなるほか、「巨大なランタイム」「JITの動作」といったオーバーヘッドが不要になり、特にスマートフォン向けのアプリ配信では大きな効果が期待できます。

デバイスの種類毎に拡張SDKを用意

ただし、いくらすべてのデバイス上で動作するといっても、例えばスマートフォンのセンサー類やIoTデバイスのGPIOなど、特定のデバイスでないと利用することができない機能群というものが存在します。UWPでは、そういった要素を「コントラクト」というAPIやクラスの集合体として定義し、デバイス ファミリごとに使用できるコントラクトを集めた「拡張SDK」が用意されています。開発時には使用する拡張SDKへの参照を明示的に追加する必要があります。

実行中のコードから特定のコントラクトの有無をチェックすることもできますので、デバイスの機能対応状況に合わせたアプリケーションが開発しやすくなっています。

タグ , , | 2020/06/16 更新 |