Windows Info 第213回

アプリ互換性を維持しつつ生まれ変わったWindows 10Xでタブレット市場を挽回できるか

　前回は「Windows 10Xはなぜかアップデートが90秒で終わるらしい」として、Windows 10Xのアップデートが90秒で終わることを紹介し、その理由として、Windows 10XではWin32アプリを「Win32コンテナー」の中で動作させることを紹介したが、今回はそのWindows 10XのWin32コンテナー（CentennialContainer）について解説して、一連のWindows 10Xの紹介の締めくくりとしたい。

Windows 10Xエミュレーターイメージに唯一インストールされているWin32アプリである「メモ帳」を起動し、ファイルオープンダイアログを開くと、Windowsフォルダーなど普通のWindows環境がそこにある。しかし、これはWin32コンテナーによって作り出された仮想的な環境だ

Win32アプリはジャイアンのような存在？

　簡単に言えば、Win32アプリは「ジャイアン」のような存在である。

　たとえば、Win32アプリはシステムの「資源」消費に関して、何も気にしない。もちろん資源利用を最小限にするように開発することもできるが、強制はされないので使いたいだけ使うことになる。まさに「お前のものもオレのもの」である。

　このため、バッテリ駆動のモバイルPCで使えば、電池をバカ食いし、システムがスリープに入ることを阻止するようなアプリケーションさえも、作ること自体は可能だ。もちろん開発者が、ユーザーのPCのバッテリを使い切ってやろうとか、他のアプリに資源なんか渡すもんかと考えているわけではないだろうが、自分のアプリケーションが最大性能を発揮できるように開発すること自体は普通である。

　もちろんOSとは、こうした「お行儀の悪い」アプリケーションをちゃんと躾けるというのも仕事の1つではある。しかし、Windows VistaまでのWindowsにおいて、マイクロソフトがメインに考えていたのはデスクトップPCであり、アプリケーションがバッテリをバカ食いすることなんかほとんど意識していなかった。

　また、Win32アプリは、許されればどこにでもファイルを作ることができるし、ファイルも読み放題である。過去にはCOMコンポーネントを置くためにSystem32フォルダーにファイルを置くアプリケーションさえも結構あった。さらにレジストリにもアクセスし放題で、自身の設定を書き込んで保存していた。

　これはそもそもマイクロソフトが推奨したことなので、アプリを責めることはできないが、アンインストールされても、再インストールに備え、レジストリをそのままにしておくことも普通だった。一部のアプリケーションは、バージョンアップにアンインストール、インストールという手順を使うからだ。そしてレジストリファイルが肥大化していく。

　レジストリは、Windowsの動作に不可欠だし、APIを介してアプリに情報を提供するためにレジストリ構造をメモリに保持する。このため、レジストリが肥大すると、メモリを圧迫することになる。年単位でPCを使うと、速度が遅くなったように感じる原因の1つとして、レジストリが肥大化したことによるシステムリソースの圧迫がある。

　また、一部のアプリケーションは、ユーザーの要望にすばやく応えるために、システムの起動時に自身の一部や全部を起動させたり、通知領域に常駐したり、常に起動するサービスをインストールするなどの処理をしている。もちろん、特定のアプリの利用に関して言えば、反応がよくなるなどのメリットはあるが、そのために起動時間が延びたり、あるいは使わないときにでもメモリやストレージ容量、CPU時間などシステムリソースを消費してしまう。これもシステム全体の性能を落とす理由の1つだ。

　最近のアプリでいえば、Chromeはメモリに残り、バックグラウンドでウェブサイトからの通知を調べるなどの処理をしている。設定で変更は可能だが、これを知らないと、ずっとChromeが起動したままになる。

　また、やることもないのに、ムダにCPU時間を消費してしまうこともある。

　タスクマネージャーのCPUの負荷グラフは、簡単に言えばアプリケーションやWindowsが処理に使った時間とアイドル時間の比率を示す。アイドル時間とは、CPUがプロセスに対して割り当てた実行時間のうち、処理を終えて戻ってきた残り時間を指す。忙しいプログラムは割り当てられたCPU時間を使い切って、Windowsに制御を奪われて戻ってくる。イベントやI/Oの応答を待っているなどの場合には、割り当てたCPU時間を使わずに戻る。この残り時間が「アイドル時間」であり、1秒などの一定時間内で使われた時間とアイドル時間の比率がCPUの負荷として表示されているわけだ。

　しかし、一部の情報に関しては、イベントで待ち受けることができず、プログラムが一定時間ごとに状態を確認しなければならないものがある。過去にはこうした情報が多く、大抵のプログラムは、ループを回して状態を調べていた。たとえば、特定のディレクトリにファイルが書き込まれたかどうかなどは、一定時間ごとに調べるしか方法がなかった。俗に「ビジーウェイト」などと呼ばれる手法だが、Windowsのバージョンが上がるとともに、さまざまな情報の変化をイベントとして通知できるようになって、ビジーウェイトを使わずにすむようになってきた。しかし、過去に作られたプログラムのバイナリにはまだビジーウェイトが残ったままのものがある。こうしたプログラムは何も仕事をしていないのにCPU時間を消費してしまう。

古い作法のアプリが大量に残るWindowsの世界
アプリ自体を新しくしようとする試みもあったが……

　そしてWindowsの世界には、現在でも過去に作られたアプリケーションのバイナリがそのまま流通している。もちろん、ちゃんとしたソフトウェアメーカーが作り、バージョンアップを重ねてきたようなアプリケーションは、正しい作法を身につけている可能性はあるが、現実には多数派ではない。

　数年前のマイクロソフトは、Win32アプリを躾けることよりも、「出木杉君」を作ることを選んだ時期もあった。それがWindows 8のストアアプリ（モダンアプリ）であり、その後継となるUWPである。しかし、UWPは欲を出し過ぎた。UWPとして開発したソフトウェアがWindows 10 Mobileだけでなく、AndroidやiOSでも動作できるようになるといった風にアピールしたが、そのために使えるAPIは、どんなOSの上でも実現可能なものに限定され、Windowsの能力を最大限に引き出すようになっていなかった。そのほかにも、いろいろと制約が多すぎて、開発者の食指を動かすことはできなかった。

　そこでマイクロソフトが用意したのはWin32アプリをパッケージ化してUWPと連携しやすくした「Desktop Bridge」（Project Centinel）である。Desktop Bridgeでは、Win32アプリをほぼそのままパッケージ化し、Microsoftストアで配布できる形式にする。また、ファイルやレジストリアクセスを「仮想化」し、物理的なファイルシステムやレジストリファイルから分離した。

　これにより、Desktop Bridgeアプリをアンインストールすると、書き込んだプライベートファイル（一時ファイルなど）やレジストリ項目を綺麗さっぱり消すことができ、システムに影響を残さない。しかし、実行時にリソースを使いたいだけ使い、常に動作できる“ジャイアン”的な部分は変わらない。その後、Desktp Bridgeでは、MSIXパッケージャーを使うことになり、現在では、MSIXパッケージと呼ばれている。Windows 10Xでは、これがMSIXコンテナーと呼ばれる。マイクロソフトによれば、MSIXコンテナーは既存技術とのことなので、仕組み的には現在のMSIXパッケージそのものだと想像できる。