Microsoftの開発者向けイベント「Build 2013」で見えたWindows 8.1。「DirectX 11.2」とUI面の改良がポイントに

Windows 8.1 Previewのスタート画面

　Microsoftは2013年6月26日から29日（いずれも現地時間）にかけて，米国サンフランシスコで開発者向けイベント「Build 2013」を開催し，次期Windowsである「Windows 8.1」に関する詳細を公開した。また，それに合わせて26日には，開発者向け事前公開版に当たる「Windows 8.1 Preview」も公開している。2013年内のリリースに向けた準備が，加速し始めたわけだ。

Build 2013が開催されたサンフランシスコのThe Moscone Center（左）と，基調講演に登壇したSteve Ballmer氏（Chief Executive Officer，Microsoft）

　実のところ，MicrosoftはBuild 2013開催以前から，小規模なイベントや開発者向けのblogなどで，ユーザーインタフェース（以下，UI）の変更などについての情報を小出しにしており，「スタートボタンの復活」といった話題はすでに周知されていた。

　しかし，Build 2013の講演や開発者向けセッションを通して詳細な情報を見ていくと，「見た目」の変更はWindows 8.1で導入される改良点の，ごく一部でしかないことが分かってくる。重要な改良はむしろOS内部に集中しており，Windows 8で積み残した課題の解決に加えて，Windows 8のリリース後に，ソフトウェア開発者から受けたフィードバックが多数反映されたものになるようだ。Microsoftは本来，こうした地道な改良を続けるのが得意な企業であり，その真価が発揮されるのがWindows 8.1となりそうである。

　本稿ではWindows 8.1で導入される多数の改良点から，4Gamer読者の関心も高そうなDirectXとUIについてレポートしよう。

DirectX 11.2で導入される新機能

メモリやCPUへの負荷を軽減する機能が目立つ

Windows 8世代の画面描画の仕組みを示したスライド。Windowsストアアプリの場合、UIの表示にはXAML（後述）という仕組みを経由して，最終的にDirectXを含めたWindows 8のグラフィックサブシステムが描画する。一方でゲームグラフィックスは，DirectXを直接利用することも可能だ

　Windows 8.1ではOS内部の改良やAPIの追加によって，動作速度や処理の効率が改善される部分が多い。DirectXの改良もその1つだ。現在のWindowsはゲームだけに止まらず，画面全体の最終的な描画もDirectXで行っているので，DirectXの改良もまた，ゲームだけでなくOS全体の動作速度を改善する重要な要素となっている。

　既報のとおり，Windows 8.1ではDirectXのバージョンが上がり，DirectX 11.2となる。
　そもそもDirectX 11はWindows 7で初めて採用され，Windows 8でDirectX 11.1にアップデートされていた。基本的な機能はDirectX 11で確立されているのだが，3DグラフィックスAPI群の「Direct3D」，2DグラフィックスAPIの「Direct2D」，テキスト表示に使うAPI「DirectWrite」などに，いくつかの機能強化が加えられる形で，DirectX 11.1やDirectX 11.2へと改良が続けられてきたわけだ。ちなみにDirectX 11.2は，Windows 8.1だけでなく，Xbox Oneでも利用可能になる。

　とくにゲームと関わりの深いDirect3Dには，DirectX 11.2で以下の5機能が追加された。それぞれの改良点について説明しよう。

• Hardware overlay support（ハードウェアによる画面の合成表示）
• HLSL shader linking（HLSLシェーダリンク）
• Mappable default buffers（割り当て可能になったデフォルトバッファ）
• Low-latency presentation API（低遅延プレゼンテーションAPI）
• Tiled resources（タイル化されたリソース）

Hardware overlay support

　「Hardware overlay support」とは，複数画面の合成をハードウェアで行うものだ。たとえば，「XAML」(ザムル)で描画するUI画面とDirect3Dによる3Dグラフィックス描画を組み合わせるような場合に，ハードウェアによる合成が利用できるようになるという。
　XAMLとは，XMLをベースにした表示記述言語のこと。プログラミング言語にC＋＋などを使えば，直接DirectXでUIを作ることも可能だが（※一般的なPCゲームはそうしている），Windowsストアアプリでは，画面の表示にXAMLを使うことが推奨されている。
　XAMLとDirectXの画面を合成することは，既存のWindowsストアアプリでも行われている。たとえば，Windows 8にプリインストールされている「地図」アプリでは，地図の部分がDirectXによる描画で，画面の上下に表示されるアプリケーション別のメニュー部分はXAMLにより描画されているのだ。

Windowsストアアプリでの，XAMLとDirectXによる混在表示の例。左は「地図」（Bing Map）アプリで，右はお絵かきアプリ「FreshPaint」。赤い部分がDirectXで，青い部分はXAMLにより描画される

DirectX側とXAML側の画面合成に制限がなくなり，DirectX側もXAMLのコンポーネントのように扱えるようになった。複数の画面を合成することもできる

　しかしWindows 8では，DirectX側とXAML側が同じサイズで互いに重なるようにしか配置できず，そのうえDirectX側が必ず上側になる，といった制約があった。Hardware Overlay Supportは，こうしたXAMLの画面とDirectXの画面を合成するときの制限を緩和して自由度を上げるとともに，処理速度を向上させるものだ。

　ゲームを例に，Hardware overlay supportを使った表示を考えてみると，まずDirect3Dで描画する3Dグラフィックス画面の解像度は，フレームレートを稼ぐために，ディスプレイの表示解像度（以下，ネイティブ解像度）より小さく描画する。一方で，得点や状態表示といったUI画面は，ネイティブ解像度で描画するとしよう。
　そこでHardware overlay supportを利用すると，3Dグラフィックス画面のサイズをネイティブ解像度へと拡大したうえでUI画面と合成し，1枚のゲーム画面を作り出せる。このときにUI画面は複数用意でき，しかもUI画面と3Dグラフィックス画面のZオーダー（奥行き方向の位置）は，任意の順序で指定できる。このように，XAMLで描かれたUIと，DirectXで描かれたゲーム画面を合成する処理を利用しやすくしたのが，Hardware overlay supportというわけだ。

レースゲームを例にして，Hardware overlay supportの概念を説明するスライド。UI画面と解像度の異なる3Dグラフィックス画面を，UI側に解像度を合うように拡大したうえで，合成する処理をハードウェア側で行える

概念説明スライドの一部を拡大したもの。左下の黒い画面はXAMLによるUI画面で，順位やラップタイムが表示されている。左上は3Dグラフィックスによるゲーム画面だが，UI画面より解像度が小さい。Hardware overlay supportを使うと，ゲーム画面をUI画面サイズに拡大したうえで，UI画面側を上にして表示できる

HLSL shader linking

　「HLSL shader linking」は，HLSL（High Level Shader Language）で書かれたシェーダプログラムによる「Dynamic Link Library」（DLL）とでも言うべきものだ。
　Windowsのシステムフォルダや，アプリケーションのインストールフォルダに「○○○.dll」という名称のファイルがあるのを見たことがあるだろう。このDLLというファイルの中身はプログラムであり，ほかのプログラムから，DLL内のプログラムを呼び出して使えるようになっている。DLLをうまく使えば，開発者は一度作ったプログラムをまた作る手間が省けるわけだ。

　HLSL shader linkingもこれと似たような動作をする。HLSLであらかじめ作成しておいた「ライブラリ」コードを，アプリケーション実行のときにシェーダプログラム本体と動的に組み合わせて，実行する機能を提供する。ゲームで使うメインのシェーダプログラムと，汎用的に使えるシェーダプログラムを独立して管理・運用できるので，ライブラリの整備や拡張などは楽になるはずだ。

　また，GeForce用シェーダやRadeon用シェーダといった具合に，ハードウェアの種類ごとにシェーダプログラムを切り替えたい場合にも，HLSL shader linkingは役立つ。GPU別に最適化した部分をライブラリ化することで，シェーダプログラム本体をGPU別に用意する必要がなくなるので，GPU性能を引き出すシェーダプログラムを用意するのが多少楽になるというわけである。

Mappable default buffers

　「Mappable default buffers」は，GPUで汎用演算を行う「Compute Shader」（演算シェーダ）のように，GPU処理とCPU処理を組み合わせたプログラムを効率化するための機能である。

　これまでは，Windows内部でCPUからGPU上で動くシェーダプログラムへとデータを受け渡すときには，メインメモリ上の中間バッファ（Staging buffers）にあるデータを、GPU側がアクセスできるデフォルトバッファ（Default buffers）というメモリ領域にコピーする必要があった。GPUからCPUにデータを送る場合も，その逆の手順が必要だ。しかし，このやり方ではメモリが余分に必要となるし，メモリの読み書きが増えてパフォーマンスも低下する。

　それがDirectX 11.2では，データの置かれた中間バッファのメモリアドレスを，デフォルトバッファとして割り当てることが可能になった。これによって，コピーを行わなくても中間バッファにあるデータを直接シェーダプログラムへ引き渡せるようになり，コピー処理に要していた時間とメモリが削減され，処理が高速になるというわけだ。

Compute Shaderを使うとき，これまではデータをいったん中間バッファに置き，それをデフォルトバッファにコピーしていた（スライド上側）。DirectX 11.2では，デフォルトバッファを任意のアドレスに指定可能となり，コピーの必要がなくなった。

Low-latency presentation API

　「Low-latency presentation API」は，ユーザーの操作に対する素早い反応が必要な表示，たとえばタッチ操作するゲームの表示を高速化するための仕組みだ。
　Windowsの画面表示は，ユーザーからの入力，たとえばタッチやマウス操作，キーボードのタイプなどに反応して行われることが多い。そしてDirectXを表示に使うアプリケーションは，内部のスレッドで「入力の検出」「検出を受けた処理」「画面描画」といったサイクルを，繰り返すように実行している。

　ところがDirectXでは，描画を行うスレッドの実行に条件があり，スレッドの実行制御をDirectX側に委ねなくてはならない。なぜなら先にも触れたように，今ではWindowsの描画すべてが，最終的にDirectXで処理されているからだ。かつてのようにDirectXを使うゲームひとつだけが，全画面を占有して動作していた頃とは状況が違う。そのため，多数のアプリケーションからの描画をDirectXが公平に行うために，個々の描画スレッドが一定時間内に実行される比率は適当な範囲に抑えられている。
　しかし，描画スレッドの実行比率が抑えられていると，入力の検出間隔が長くなってフレームレートも下がってしまう可能性がある。一般的なWindowsアプリケーションならそれでも困らないが，アプリケーションによっては（※とくにゲームは），ユーザーの入力にすばやく反応しなくてはならない。一定のフレームレートと入力検出のサイクルを保証して，入力から表示までの遅延を極力小さくするために導入されたのが，Low-latency presentation APIである。

　Low-latency presentation APIでは，あらかじめ1秒間に更新する画面数（フレームレート）を決めておき，フレームレートが変わらないように入力検出と描画のサイクルを実行できる仕組みを提供する。これを利用することで，ユーザーの操作が画面描画に反映されるまでのレイテンシ（遅延）をより短くでき，快適な操作を実現できる。
　下に示した画像は，Low-latency presentation APIのデモ動画^※1から切り出したスクリーンショットだが，Low-latency presentation API無効の左画像と，有効状態にある右画像で，マウスポインタとその動きを追いかける赤丸の距離や，レイテンシ時間が異なるのが分かるだろう。数字を見ると，API無効状態で46ms程度ある遅延が，API有効状態では16ms程度まで縮まっている。タッチ操作のゲームに利用すると，効果を発揮しそうな機能だ。

※1 開発者向け情報ページ「Channel 9」の記事にある動画の38分20秒あたりから。

Low-latency presentation APIのデモ動画の画像。左はWindows 8を想定したAPI無効状態で，右がWindows 8.1でのAPI有効状態。マウスポインタを画面上で素早く動かして，それに追従する赤丸の動きや遅延時間を表示している。右の方が遅延が少ない

Tiled resources

　「Tiled resources」とは，小さな領域を表す「タイル」を複数組み合わせて，ひとつの大きなテクスチャデータ（リソース）を生成する機能である。
　ゲームを例に挙げると，空や平原といった広い領域を表現するときに表示品質を高める手段の1つに，高解像度の大きなテクスチャデータを使うという手段がある。しかし大きなテクスチャデータは，メモリを多く使用してしまう。Tiled resourcesはこうしたテクスチャデータによるメモリ圧迫の解決手段として導入されるものだ。

Tiled resourcesの概念図。左がメインメモリ上に配置された，タイル化されたテクスチャで，それをOSのメモリ管理機能が適切に配置し直して（Hardware page table），1つの巨大テクスチャとしてGPU側（Texture filter unit）に渡す

　たとえば，空（そら）のテクスチャの場合，ほとんど同じような部分が少なくない。そこでTiled resourcesでは，まず巨大なテクスチャを複数のタイルに分割し，同じ内容で代替できる部分は1つのテクスチャタイルにまとめて，使用されるタイルと，どのタイルを使ったのかの情報だけをメモリに記録する。
　しかし，GPUは仕様上，1つのテクスチャデータは連続したデータになっていなければ，正しく扱えない。そこでTiled resourcesはWindowsの仮想メモリ管理機能を利用して，メモリ内のタイルを連続したテクスチャデータに見えるように配置しなおして，連続したデータであるかのようにGPUに渡すというわけだ。これにより，テクスチャデータによるメモリ使用量を減らせるし，高品質なテクスチャデータを，ゲーム内で使いやすくなるというわけだ。

DirectX 11.2の新機能は

GPUの世代によっては使えないこともある

　ここまでで説明したDirectX 11.2の新機能は，Windows 8.1をインストールしたどんなPCでも使えるというわけではない。搭載GPUが対応する機能によって，利用できる/できないといった違いが生じ，その違いは「フィーチャーレベル」（FL）という概念で表されている。

　DirectXは，10.0や10.1，11.0や11.1といった具合に，メジャーバージョン（10や11）以外にも細かい違い（.0や.1）が存在する。そのため，GPUがどのバージョンやどの機能に対応するかを把握するのは，昔からアプリケーションにとってやっかいな問題だった。
　それを，DirectX 11でフィーチャーレベルにまとめることで，分かりやすく管理できるように改善された（関連記事）。たとえば「FL9_1」は，Windows Vista世代のDirectX 9.x世代のGPUが対応していた仕様を示す定義で，現在のWindowsにおけるグラフィックス機能の最低基準となっている。同じように，「FL10_0」はDirectX 10.0対応，「FL11_1」ならDirectX 11.1対応というわけだ。ただ理由は不明ながら，今回，「FL11_2」という定義は導入されなかったようである。

　ともあれ，下の画像は，DirectX 11.2の新機能が必要とするフィーチャーレベルを示したスライドだ。これを見ると，HLSL shader linkingやLow-latency presentation APIは基本的にソフトウェア側の改良で実現できるので，FL9_1以上なら利用可能になっている。つまり，今時のGPUやPCなら，ほとんど問題なく使用できると言えよう。
　その一方，Mappable default buffersやTiled resourcesは，FL9_1とFL10_0には非対応で，FL11_0でも「Check for Support」，つまり「使えるかどうかチェックしてから使ってね」とされている。具体的にどのGPUなら使える/使えないとは明言されなかったが，「現在発売されているGPUで使えるものもある」との説明もあったので，Windows 8.1用のWDDM 1.3対応のディスプレイドライバを使ったDirectX 11世代のGPUなら，これらの機能を使える可能性があるようだ。

DirectX 11.2の新機能が必要とするフィーチャーレベル。緑は使用可能。黄色は条件付きで可能。赤は非対応を示している

Windows 8.1で導入された

そのほかのグラフィックス機能

　DirectX 11.2での新機能以外にも，Windows 8.1ではグラフィックスに関する改良がいくつか加えられている。全部がゲームにも通用するわけではないが，簡単に紹介しておこう。

　1つは，マルチコアCPUでの描画効率を向上させる改良だ。Windows 8では，1つのUIスレッド内でXAML側とDirectX側の描画を行う必要があったのだが，DirectX 11.2では，DirectX側の描画やユーザー入力の処理を，UIスレッドとは別のスレッドで処理可能となった。DirectXで描画するゲームグラフィックスと，XAMLで描画するUI部分を分けておけば，この機能をうまく利用することで描画効率を大きく改善させる可能性がありそうだ。

XAMLとDirect3Dの描画を組み合わせる場合，UIスレッドとDirect3D側の描画を別スレッドで行えるようになった（スライド右）。

　2Dグラフィックスに関する改良で，いかにも今風の仕様だと感じたのが，「カラーフォント」への対応だ。カラーフォントと聞いて，「フォントには今までだって色を付けられただろう？」と思うかもしれないが，それとは違う。
　これまでWindowsのフォントは，フォントデータに色情報という概念がなかったので，単色しか扱えなかった。たとえば「林」という字で，右と左の「木」で色を変える，などということはできなかった。ワープロソフトや画像編集ソフトでそれができるのは，フォントを画像データに置き換えているからだ。

　しかしWindows 8.1からは，フォントデータはその形だけでなく色情報を含むことが可能になった。これにより，携帯電話のようなカラフルな絵文字フォントが使えるようになった。それに合わせて，絵文字のフォントデータである「Segoe UI Emoji」フォントが，Windows 8.1には付属する。
　「たかが絵文字対応程度で，OSを修正する必要があるのか？」と思う人もいるだろう。しかし，絵文字は今や世界的な標準文字コードである「Unicode」にも取り入れられているし，AndroidやiOSでも利用できるなど，タブレットやスマートフォンには必須の機能となっている。Windows 8.1をタブレット分野に普及させるためには，避けて通れない機能なのだ。

　ただし，カラーフォントを表示させるためには，アプリケーション側でカラーフォントに対応する必要があり，たとえばWindows 8.1付属の「メール」アプリケーションは，絵文字の表示と入力に対応するよう改良されている。残念だが，既存のアプリケーションでそのまま絵文字フォントが使える，というわけにはいかないようだ。

絵文字の表示に対応したWindows 8.1付属の「メール」。今まではアプリケーション側で絵文字表示を独自に作り込む必要があったが，Windows 8.1以降はカラーフォントに対応すればいいだけで，楽になりそうだ

　複雑な2DグラフィックスをGPUに処理させるときに役立つ，「Geometry realization object」という機能も加わった。
　Windows 8では2Dグラフィックスも実際にはDirect3Dの機能を使って表示するので，GPUの持つ3Dグラフィックス機能を利用することにより，2Dグラフィックスも高速に処理できる。こうしたGPUによる2Dグラフィックス処理を「2Dジオメトリレンダリング」と呼ぶ。
　画像編集ソフトを例に挙げると，ユーザーの操作に応じて画像を回転させたり変形させたりといった処理に2Dジオメトリレンダリングを使うことで，画像の拡大縮小や回転，変形の表示が高速化できるわけだ。

Windows 8での，画像の回転や変形処理の描画手順。1フレームごとにこれだけの処理が必要だった

　しかしWindows 8までは，こうした表示を実現するためには，1フレーム分の描画のたびに，「CPU側で画像をジオメトリ（≒ポリゴン）に分割するテッセレーション処理を行ったのち，GPUに拡大縮小の比率や回転角といったパラメータを与えて画像を変形させ，さらにテクスチャ貼り付けやアンチエイリアシングを行う」といった処理が必要だった。
　これがWindows 8.1になると，元データ（つまりジオメトリ）が変形しない画像の表示なら，CPUは1度だけGeometry realization objectを作ればいいだけになった。あとの処理はGPUが行うため，CPUの負担が軽くなる。画像編集ソフトのGPU活用は，ますます進みそうだ。

同じ処理をWindows 8.1のGeometry realization objectを使った場合。左はCPU側の処理で，基本的に1度で済む。右はGPU側の処理で，こちらは1フレームごとに実行する

Windows 8で導入されたUIの動作を

細かく指定できるようになったWindows 8.1

タスクバーに戻ってきたスタートボタン（左下）。ただし，押してもWindows 7までのようなメニューが表示されるわけではなく，スタート画面が表示されるだけ

UIの設定を細かく指定できるNavigationタブ

　Windows 8.1内部の込み入った話が続いたので，目に見えるUI側の改良点についても簡単に触れておこう。なお，デスクトップのタスクバーにスタートボタンが復活した話は，冒頭でも触れたので省略する。

　Windows 8.1のUIに関して重要な変更点は，タスクバーのプロパティに追加された「Navigation」タブに集中している。

　まず，Navigationタブでの設定により，スタート画面の背景に，デスクトップ画面の壁紙と同じ画像ファイルを表示できるようになった。Windows 8の場合，スタート画面の背景は，OS側が用意したシンプルな画像から選べるだけだったので，スタート画面の印象は，かなり変わることになるだろう。
　さらに，デスクトップとスタート画面で同じ画像を設定しておくと，デスクトップ側でスタートボタンを押したときに，デスクトップの上に半透明のスタート画面が表示されているように見えるようになった。これにより，スタート画面とデスクトップを行き来しても，違和感を感じにくくなっている。

　また，Navigationタブでの設定には，OS起動直後に，スタート画面ではなくデスクトップ画面を表示させる項目や，マウスポインタが画面の4隅に入ったときの動作（チャームバーの表示やタスク切り替え一覧表示）をオン/オフしたり，スタート画面を表示させるディスプレイを固定したりする設定もある。
　これらはいずれもWindows 8では設定できなかったか，レジストリを手作業で編集しないと設定できなかった要素なので，Windows 8.1の使い勝手は，その分向上することになると思われる。

Windows 8.1では，スタート画面の背景画像に，デスクトップの壁紙と同じ画像を選べるようになっていて，一見すると，デスクトップの上に半透明のスタート画面が表示されているような印象になる

チャームバーから表示する「PC設定」では，画面左端からのエッジ動作でのタスク切り替え動作や，マウス操作によるチャームバー表示の動作に関する設定を変更できる

　Navigationタブにある設定で面白いのは，スタート画面にタイルを並べるのではなく，「すべてのアプリ」画面（Apps view）を表示させるという設定があることだ。Apps viewは，表示するアプリケーションの並びを，名前順やインストール日時順，利用頻度順，カテゴリ順（※旧スタートメニューのフォルダに相当）の4種類で並べ替えが可能で，Windows 7までのスタート画面にあった，「すべてのプログラム」表示に比較的近い表示にもできるようになった。
　Apps viewとタスクバーのスタートボタンを組み合わせれば，「スタート画面にはどうしても慣れない」という人でも，あまり違和感なくWindows 8.1を使えるようになりそうだ。

Apps viewをカテゴリ順表示にした状態。従来型スタートメニューの表示に比較的近いので，スタート画面を使う気になれない人は，これを使うといいかもしれない

今後のWindowsは，

AndroidやiOS並みの短期間で更新される？

　さて最後に，Windows 8.1そのものというより，今後のWindowsのリリースサイクルについても触れておきたい。とはいえ，これから記すことはMicrosoftが正式に表明したものではなく，Build 2013を通じて筆者が感じたことであることをお断りしておく。

　これまでのWindowsは，Windows 7やVistaようなメジャーアップデートの場合，3年ほどの利用期間を想定して開発されてきた。そして，まとまった数のバグ修正や若干の機能追加は，「Service Pack」によって提供されるという仕組みになっていた。

　しかし，今やWindowsにとって最大の脅威であるiOSやAndroidは，1年に1回程度のメジャーアップデートを提供することで，機能や性能を急速に伸ばしてきている。Windowsは，iOSやAndroidと異なり，PCメーカー向けのOEM提供がビジネスの中心なので，膨大な種類のPCで検証する手間がかかる。なので，3年に一度というペースのメジャーアップデートは，ある意味で仕方ないところもあるのだが，iOSやAndroidがどんどんと進化していくこのご時世に「メジャーアップデートまで3年お待ちください」では，やはり厳しい。とくに，タブレットの分野では，Microsoftは王者ではなく挑戦者である。挑戦者がそんなにのんびりしていたら，いつまで経っても追いつけまい。

　そういう状況にあって，短いサイクルでアップデートを繰り返す競合OSに対抗するために登場したのが，Windows 8.1である。Windows 8の市場における評価が低かったせいもあるとはいえ，前バージョンが登場してから，わずか1年後に改良版が登場するというのは，Windowsの歴史では珍しいことだ。昔話になるが，Windows NT最初のバージョンである「Windows NT 3.1」が1993年に登場してから，「Windows NT 4.0」が1996年に登場するまでの間に，「1年に1バージョン」ペースで改良版が投入された時期以来と言えよう。

　Microsoftは競合OSに追いつき追い越すために，今後もこうした短いサイクルでの新バージョン投入を続けようとしているのでないだろうか。今後も同社が，短期間でのOSリリースを続けられるかどうかは未知数であるものの，こうしたアップデートサイクルが軌道に乗れば，Windowsも急速に機能を成長させることが可能となるかもしれない。そしてその鍵を握るのは，動作検証にかかる時間だと筆者は考えている。

　PCの歴史を振り返れば，想定していなかったハードウェアのわずかな違いが，OSのクラッシュやハングアップを引き起こした例は珍しくない。それは「リファレンスとなるハードウェア」が存在しなかったうえ，OS自体の複雑化もあって，開発や検証に時間がかかるようになったことは，その原因の1つである。
　Microsoftは「Windows Phone 8」を投入するのに当たって，同一のプロセッサや関連パーツを使う「シャシー戦略」を採用した。またPCでも，初の自社製タブレットPCである「Surface」シリーズを投入している。これらはいずれも，リファレンスとなるハードウェアを用意したともいえるわけで，Windowsのリリース速度を上げるための準備は，ハードウェア面でも整ったといえるかもしれない。

Windows 8.1 Preview情報ページ