Windowsでの大きな不満だった長いアップデート時間
Windows 10Xでは解決される!?

　年内登場が予定されている2画面タブレット向けの「Windows 10X」では、なぜかシステムアップデートが90秒以内で完了するらしい。にわかには信じられない話だが、スマートフォンなどのアップデートもOSが利用できない時間は数分程度。よく考えると、特段スゴいことではない。逆に言えば、なぜWindowsのアップデートにはあんなに時間がかかるのか？ のほうが謎といえる。

　そういえば、最近国内でも、Chromebookの宣伝（かつて米国で放送したCMをベースにしたもの）をテレビでやっていて、自動アップデートできると主張しているようだ。それに火をつけられたのか、Windows 10Xの解説ビデオでは、90秒以下でアップデートできるとアピールしていた。

●Microsoft 365 Developer Day
https://developer.microsoft.com/en-us/microsoft-365/virtual-events

　Windowsの機能アップデートに長い時間がかかるのは、そのたびにWindowsを「再インストール」しているからである。新しいWindowsのイメージを作り、今のWindowsをごっそり消して、新しいWindowsを起動ディスクに書き込む。その後、書き込まれたWindowsは、ハードウェアを調べてデバイスドライバーを組み込むなどハードウェアに自分自身を適合させていく。このときにWindows自体を止めて、長時間「Windowsを構成しています」という画面を出し続ける。

　では、なぜ再インストールなのかというと、これまでのWindowsのメジャーバージョンアップが、すべてそうだったからだ。ユーザーファイルの保存やライセンスのアップグレードはあったが、Windows自体は、一回バッサリと消してしまって、新しいWindowsをシステムとして書き込む、これがWindowsの標準的な手順となる。とはいえ、メジャーアップデートが3年に1回、5年に1回という周期なら、何も問題なかったのである。そもそも、アップグレードは無料ではなかったし、しないという選択肢もあったのだから。

　しかし、Windows 10で状況は大きくかわる。従来のメジャーアップグレードに相当する機能アップデートが年2回も発生し、そのたびに再インストールである。マイクロソフトも努力はしていて、最近のバージョンでは、ダウンロードやインストールイメージの作成は、Windowsが動いている間に実行し、PCが利用できない時間を短縮させている。

　しかし、再インストールされたWindowsは、ハードウェアをゼロから調べて、デバイスドライバーの組み込みなどをするため時間がかかる。しかも、CPU性能やストレージ性能が低いとか、メモリが少ないといった場合には、より時間がかかる。これがPCでの作業効率を大きく落としていた。

Windows 10Xは、90秒でアップデートでできる？

　ところが、マイクロソフトが公開したWindows 10Xのビデオによれば、Windows 10Xは、アップデートを90秒以内にするのだという。今までの経験からすると、どうしてもにわかには信じられない。昨日まで「大人を信じるな」と言っていた長髪とTシャツ姿の大学生が、急に髪を短くして背広にネクタイ姿になり「もう若くないのさ」と言うぐらいに違う（たとえが古い？）。

　たとえばAndroidでは、なぜアップデート時にOSが止まっている時間が短いのか？ もちろんOS自体が小さいということもあるが、起動中にどうしても差し替えられない部分（カーネルなど）だけはOSを止めて更新し、それ以外はあとからゆっくり差し替えたり、最低限必要な機能（アラームや着信など）は生かしつつ、バックグラウンドでOSを書き換えるという手法を導入しているからだ。つまり、OSや機能を停止する時間を最小にするための工夫を入れてある。Chromebookもやはりアップデート時間は短いが、おそらく同様の仕組みを使っているのだと思われる。

　Windowsも自身を構成するソフトウェアモジュールについては、可能なものは起動中に差し替えることができるようにしているようだ。実際、品質アップデートで再起動を要求させる回数は減り、たとえば、.NET Frameworkなど最低限の場合に限られてきた。また、昨秋のアップデートは、機能追加は小規模ながら、毎回の品質アップデートでモジュールを差し替えていき、最後に再起動することで機能を有効化するという手法が使われた。

　しかし、これだけではまだ不十分な部分がある。1つには、起動しているWin32アプリケーションは中断や再開が実質不可能であり、これらが動作していると、原理的にはWindows側もモジュールを差し替えられない場合が出てくるからだ。

シェルを差し替えるとともに仮想環境を使う

　そこでWidnows 10Xは、2つの方法を使う。1つはWin32アプリケーションを「Win32コンテナー」の中で動作させる。もう1つは、Explorerから新しいシェルに置き換えることだ。

　Win32コンテナーは、WSL2と同じ「軽量ユーティリティ仮想マシン」環境であり、起動時のシステム負荷が小さい仮想マシン環境だ。マイクロソフトは、Windows 10X用に新規開発したとしている。

　このあたりについては別途解説したいが、ここで言いたいのは、Win32アプリケーションをすべてコンテナー内で動作させることで、ホスト側のWindows 10Xは、Win32アプリケーションの細かなリソース管理までする必要がなく、またコンテナー全体を停止させることで、すべてのWin32アプリを「休止」状態にできる点だ。

　起動中のWin32アプリのリソース管理などは、仮想マシン内のゲストOS（Windows 10X）が行ない、ホスト側のWindows 10Xはなにも関与する必要がない。この結果、Win32アプリが起動している状態でも、ホスト側のWindowsはモジュールを差し替えることが可能になると考えられる。

　イメージ的には、Windows 10のHyper-Vで作った仮想マシン環境でWindows 10を動かして使っているのと同じだ。仮想マシン環境を保存して停止させている間なら、ホスト側のWindowsのアップデートができ、アップデート後に仮想マシン環境を起動すれば、中のアプリケーションは何事もなかったかのように動き出す。

　また、Windows 10XではWindows NT以来ずっとデスクトップを管理し、ユーザーインターフェースの前面にあったExplorerを簡易なシェルに置き換えた。そもそもExplorerは、exeプログラムで、さまざまな外部プログラムやサードパーティプログラムと連携する巨大なソフトウェアである。これをやめることで、Windowsのモジュール差し替えはかなりラクになるはずだ。

　おそらくはこのような形で、ホスト側のWindows 10Xは起動中に自身を構成するモジュールを差し替えていき、どうしても起動中では変更することができない機能だけを、最短の再起動時間で差し替えるようにするのだと思われる。1980年代から続く、再インストールによるメジャーアップデートはここでようやく終わりを告げるが、この方法でアップデートが高速化できるのはWindows 10Xだけのようだ。