Windows Info 第213回

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

Windows32コンテナーにWin32アプリを閉じ込める
Windows 10X

　Windows 10XのWin32コンテナーは、こうしたWin32アプリを動作させる「環境」である。すべてのWin32アプリケーションは、この中で実行される。マイクロソフトによれば、このとき、バッテリ消費と性能をバランスさせるようにWin32コンテナーを動かすという。

　コンテナー内でWin32アプリを動作せることで、コンテナーでまとめて、資源割り当てを制御できる。Win32アプリは、いくらジャイアンとはいえ、Windowsが提供する資源以上には資源を利用できない。つまり、「コンテナー」という箱の中にWin32アプリを閉じ込め、適当にリソースを割り当てておき、あとはコンテナーの中でWin32アプリ同士で配分させればいいのである。箱の中にジャイアンを複数入れて置き、ジャイアン同士で戦わせて外には影響させないようにできるわけだ。

　Win32コンテナーは、Desktop Bridgeアプリ同様にファイルシステムとレジストリを仮想化する。これにより、物理的なファイルシステムはWin32アプリからの汚染を心配しないですむ。

　なお、Desktop Bridgeアプリは、Windows 10Xでは、MSIXコンテナーで動作することになっているが、このMSIXコンテナーもWin32コンテナー内にある。というか、そもそもWin32コンテナーは、Desktop Bridge用のコンテナーを改良したものと考えられる。

　というのは、Win32コンテナーには、“CentennialContainer”という名前がついているからだ。Centinelとは、Desktop Bridgeの開発プロジェクト名「Project Centennial」と一致する。そもそも、この名前は、Classic Windows Application（CWP）という当時のWin32アプリの名前（UWPと対比させるためにこのような名称が使われた）の頭文字「C」で選ばれた名前である。同様にAndroid Bridgeは、Androidの「A」を取って、Project Astriaと呼ばれた。

　CentennialContainerの名称は、Windows10Xエミュレーターのデバイスポータルに接続したときにプロセス情報として表示される。

Windows 10Xエミュレーターを起動し、デバイスポータルに接続する。ページタイトルの「Running processes」の下にHostとCentennialContainerの2つの切り替えリストボックスがある。Win32アプリのメモ帳は、CentennialContainerの中で動作している。これがWin32コンテナーだと思われる

　デバイスポータルは、Windowsマシンが、開発時に動作中の情報をHTTPサーバーとして提供するもの。Win32アプリ（メモ帳）を起動すると、Windows10Xのプロセスではなく、CentennialContainer内のプロセスとしてメモ帳が表示される。

　また、Windows10XのComposable Shellから起動したFileExplorerでは、ローカルファイルとして、ユーザーフォルダー（ドキュメントやピクチャーなど）しかアクセスできない。なお、このFileExplorerはUWPアプリケーションだ。

Windows 10X標準付属のFile ExplorerはUWPアプリで、ここからはユーザーフォルダー以下しか見ることができない

　しかし、メモ帳からファイルオープンダイアローグを開くと、ちゃんと、Windowsフォルダーなどが見えている。これは、Win32コンテナーがWindows環境をWin32アプリに提供しているからだ。

メモ帳のファイルオープンダイアログからは、ちゃんと「C:\Windows\System32」フォルダーなどにアクセスできている

　簡単に言えば、Win32コンテナーは、その中で書き込んだファイルやレジストリが別に残る「Windows Sandbox」のようなものだ。逆にWindows Sandboxは、Windows 10X開発の過程で生まれてきたもので、先行してテストするためにユーザーに提供されているのかもしれない。

　マイクロソフトは、Windows内での作業やエラーなどを「テレメトリー」という機能を使って収集・分析をしているという。Windows Sandboxを提供することでユーザーがさまざまなWin32アプリケーションをSandbox内で動作させ、その挙動やエラーなどを調べ、Windows 10X開発に利用しているという推測もできる。

Windows 10Xの構造はどうなっているか

　以下の図に、Windows 10Xの構造を示す。Windows 10Xは、ホストOSとなるWindows Core OS（WCOSと略されることもある）と、ゲストOSとしてWindows 10が動作するWin32コンテナー、そしてNativeコンテナーから構成される。

Windows 10Xの構成図。ホストOSとなるWindows（Windows Core OS）の上にNativeコンテナー（UWPの実行環境）とWin32コンテナーがある。なお、Win32コンテナー内のアプリケーションは、UWPアプリケーションであるRDPクライアントを経て画面を表示している。ユーザーフォルダーだけは、Native／Win32コンテナーからはアクセスが可能で、Win32コンテナーからは、Windows 10同等のファイルシステムは見えるものの、書き込みが仮想化される

　コンテナー内からは、ホストWindows（Windows Core OS）側へのアクセスは制限されている。UWPはもともと、OS側とはAPIを通してのみつながるだけで、ファイルアクセスなども禁止されているが、Win32アプリは、Win32コンテナーの中になるため、ホストWindows側へのアクセスができない。そしてWin32アプリやMSIXアプリは、UWPアプリケーションであるRDPクライアントを使って、自身のウィンドウを表示する。RDPは、リモートデスクトップのためのプロトコルで、現在でもWindows 10でHyper-Vを使う場合に仮想マシン側の画面を表示するために使われている。

　ハードウェアアクセスに関しては、従来どおりにデバイスドライバー経由となるが、重要なのは、Win32アプリの場合、Win32コンテナー側のWindowsでは仮想化されたデバイスのアクセスとなり、コンテナーからのリクエストをホストWindows側が処理するという点である。これは、現在のWindows Sandboxとほぼ同じ構造だ。

　Win32コンテナーからのファイルアクセスは、ユーザーフォルダーを除いてすべて仮想HDDに対する処理となる。おそらくホスト側で仮想ディスクファイル（VHDXファイル）として扱っているのではないかと思われる。また、同様にレジストリへの書き込みもファイルにリダイレクトされ、ホスト側のレジストリと合成されてWin32アプリに提示されるはずだ。これで、Win32アプリは好き勝手な場所にファイルを書けるが、実際のファイルシステムには書き込まれない。また、レジストリへの書き込みも別ファイルにリダイレクトされ、ホストWindows側のレジストリを汚染しない。

　Win32コンテナーにWin32アプリを閉じ込め、ホスト側をアクセスさせないことは、システムの健全性を保つためにも必要だろう。昨年のWindows 10 Ver.1909あたりから、電源を止めない「Connected Modern Standby」を実装するマシンが増えてきたが、Modern Standbyがムダに電力を使ってしまう原因は、ルールに従っていないデバイスドライバーとWin32アプリに原因があるという。

　筆者も、対応デバイスを購入してみたが、満充電にして持ち出して、さて使おうとするともう20％も30％もバッテリが減っていることがある。Modern Standbyのスリープ中にデバイスに集中してアクセスが起きたり、あるいは起動していたアプリが活発に動作してしまって電力を使っていることが少なくない。

　こうした問題を解決するには、デバイスドライバーなどには手を付けさせず、スリープ中は制御できるかたちでアプリを実行させるしかない。UWPはお行儀がいいので、そのままとして、やはり問題になるのがWin32アプリケーションだ。

　そこでWin32コンテナーごとにスリープ中のCPU時間の割り当てを減少させて、実行時間を短くしてやればいいわけだ。ホストWindows側からみると、Win32コンテナーは、単一のプロセスでしかなく、CPU時間を割り当てたときしか動かない。また、Win32アプリへのCPU時間の割り当ては、コンテナー内のゲストOSであるWindowsが行ってくれるため、ホスト側では何も気にする必要がない。

　Windows 10Xエミュレターを使うと、UWPの起動は比較的軽快なのに対して、Win32アプリのメモ帳の起動には時間がかかる。おそらく、仮想環境のセットアップや仮想マシンの負荷などがかかるからだ。

アプリの互換性を保ちつつ、新しくなったWindows 10X
では、これでタブレット市場での劣勢を挽回できるか？

　Windows 10Xは、タブレット市場に対するMicrosoftの再チャレンジだ。今回は、これまでのPCタブレットで問題だったバッテリ問題を解決し、従来のWin32アプリケーションとの互換性も保った。また、こうして1年も前から開発を発表し、エコシステムの準備もしている。

　しかし、先行するiPadやAndroidのタブレットのシェアは高く、タブレット市場で一定の存在感を示すには、大きな労力が必要だろう。IDCの調査によれば、2019年タブレット市場では、アップル、サムスン、ファーウェイの上位3社の合計で約6割のシェアを占めている。サムスンやファーウェイはWindowsベースのタブレットも出荷しているが、大半はAndroidベースであり、アップルはもちろんiPadだ。

　そして、dual-screenデバイスに賛同して年内の出荷を目指すのは、ASUS、デル、HP、レノボ、そしてマイクロソフト。つまり、どの会社も現在のタブレット市場では「その他」に甘んじているメーカーばかりである。かろうじてレノボがIDCの調査では5位には入っているものの、シェアは5.9%とかなり低く、かつ大半がAndroidベースとされている。そんなわけでdual-screenのPCタブレットは、これから市場奪還を目指して立ち上がるわけだが、はたして、どこまでやれるのか？ 今年後半の見所は、このタブレット市場であろう。