Windows 11ではARM版も改良が進んだ

　Windows 11にはARM版もある。Windows 10のとき最初は騒がれたが、そのあとARMの人以外で実際に使っている様子を実は見たことがない。とはいえ仕事なので、Surface Pro Xを購入した。このマシンにもWindows Insider ProgramのBeta Channelでプレビュー版がやってきた。ARM版のWindows 11は強化されており、Windows 10のときにはプレビュー版でしか提供されていなかったx64コードのバイナリ変換機能が搭載されている。今回は、このあたりを含めて、ARM版Windows 11の状況について解説しておこう。

ARMプロセッサについてあらためて整理

　話が少しややこしいので、最初にちょっと用語を整理させていただく。まずはARMプロセッサについてである。インテルやAMDのCPUは、「世代」と「マイクロアーキテクチャ」名で区別されるが、ARMプロセッサでは、アーキテクチャにバージョン番号がついている。とはいえ、番号が整理されたのは、ARMv7から。PC関連ではこれ以降のアーキテクチャだけ考えればいい。なお、かつてインテルがDECから“譲り受け”て、うまく行かずに売り払ったXscaleはARMv5世代である。Androidも最初はこの世代をサポートしていたが、現在では、ARMv7以降のみが対象となっている。

　簡単に言えば、ARMv7が32bitアーキテクチャで、ARMv8が64bitアーキテクチャである。現在では、ARMv9というアーキテクチャもあるが、これはARMv8-Aを強化したものと考えればよく、少なくともWindows 10、Windows 11のレベルでは両者の違いは問題にならない。

　なお、ARMv8にはARMv7の命令セットや実行環境が含まれていて、これをAArch32と呼んでいる。

　この32bit命令セットをA32命令セットと言う。なお、ARMv7の時代には、AArch32やA32命令セットという呼び方はなく、ARMアーキテクチャなどと呼ばれていた。ARMv8で64bit環境が出てきたとき、ARMv7とは異なるA64命令セットを導入し、レジスタなどを追加してAArch64として定義した。この際にARMv7までの32bit実行環境をAArch32と呼ぶことにした。このため、ARMv7のオリジナルの定義は、AArch32とは呼ばれていなかったのだが、話が面倒になるので、ARMv7に対してもAArch32やA32といった呼び方を使う。

　ARMv8は、AArch32/A32とAArch64/A64の両方に対応している。これは、AMDやインテルのCPUが32bitモードと64bitモードの両方を持っているのと同じである。ここで明確にしたいのは、A32とA64という異なる命令セットを持っている点である。一般に1つのCPUが異なる命令セットを持っている場合、プログラムはどちらかの命令セットを使って作ることになる。プログラムの途中でモードを切り替えることは、ハードウェアとして不可能ではないが、モードの切り替えは特権命令であったり、実行環境の設定などが必要なことが多く、1つのプログラムの中で勝手にモードを切り替えるようなことはOSが許さないのが普通である。なので、一般にアプリケーションはどれか1つの命令セットだけで作られる。

　OSはAPIを呼び出す手順などの基本的なルールを決めている。これをABI（Application Binary Interface）という。ハードウェア上、プログラムはさまざまな構造を持つことができるが、アプリケーションプログラムは、OSの提供するAPIを使わないと、ファイルも読めなければ、画面に何かを表示することもできない。

　ABIには、API呼び出し時のルール（Calling Conventionと呼ばれる）やデータやプログラムをメモリに置くときの境界合わせ（アライメントという）やAPI呼び出し時のスタックの使い方などが定められている。たとえば、高速化のためにレジスタを使って引数を渡すときにどのレジスタに置くか、スタックには何を入れておくかといったルールが定めれている。そのほか、一部の汎用レジスタに固有の役割を持たせる、保存しておく必要があるレジスタなど、さまざまなルールがある。

　ただし、このABIに関しては、CやC++などの高級言語でアプリケーションを記述する場合には、コンパイラが処理してくれるため、開発者があまり心配する必要はない。しかし、アセンブラでプログラムを記述する場合、開発者はABIに準拠してプログラムを書かねばならない。

　ARM版Windows 10用にMicrosoftが定義したABIは、ARM64 ABIと呼ばれている。これはWindows固有のABIである。ARMプロセッサでは、Linuxなども動作するし、AndroidやChromebookなどもARMプロセッサを使う。しかし、ABIはMicrosoftのARM64 ABIとは異なっている。ただし、ARM64 ABIはARM社が定義したABIをベースに作られた。

　これに対して、従来のAMDやインテルCPU用に定義したABIもある。これらは、x86 ABIやx64 ABIと呼ばれている。ARM64 ABIは、同じ64bit用のx64 ABIとCalling Conventionやアライメントのアルゴリズム、スタック利用方法で異なる部分がある。多くの場合ABIは、それぞれのCPUに最適化して作るため、アーキテクチャが異なれば違うものになるのが普通である。

Windowsとコードタイプ

　一般にアプリケーションプログラムは、このABIに準拠して、特定のCPUのアーキテクチャの命令セットを使って作られる。ここではこれを「コードタイプ」と呼ぶことにする。Windowsのコードタイプには、以下の表のようなものがある。

　64bit版Windowsは、x86コードとx64コードの実行が可能だ。これに対してARM版Windows 10は、従来のx86コードを「バイナリ変換」により、A64命令セットに変換して実行することが可能だが、もちろんARM64コードの実行もできる。

　Microsoftのドキュメントによれば、ARM版Windows 10は、ARM64で作られているという。しかし、x86／x64コードは、ARM64とは違うABIを持つ。ということは、アライメントやCalling Convention、スタックの使い方が違っていることになる。x86／x64コードをバイナリ変換でA64命令セットのプログラムに変換できたとしても、ABIまでは変換できない。どういうアルゴリズムやコードでABI対応させているかが不明だからだ。これを変換するのには、プログラムの「意味」を知る必要がある。

　しかし、変換されたx86／x64コードは、APIを呼び出した瞬間には、スタックやアライメントなどがx86／x64 ABIに準拠した状態になっているはずなので、これを機械的にARM64に変換することは可能だ。ソフトウェアでは、こうした変換をする小さなプログラムを「スタブ」と呼ぶことがある。おそらく、ARM版WindowsではAPIに入る前にスタブが置かれ、ここでARM64 ABIに準拠させたうえでAPI呼び出しをしていたと考えられる。なお、WindowsのAPIは、DLLの中にあるため、API呼び出しはDLLの呼び出しと同じである。

　ARM版Windows 10では、フックやエクスプローラー拡張で、アプリケーションが組み込むx86コードのコンポーネント（DLL）をロードできない。これらは、API呼び出しではないためにスタブを挿入することができず、Windows側のモジュールはARM64 ABIに準拠し、バイナリ変換されたx86コードは、x86 ABIに準拠しているため、正しく動かないためだ。ARM版Windows 10で、ATOKや一部のエクスプローラー拡張などがうまく動かなかったのは、これが原因だ。

　さらに、ARM版Windows 10ではx86に限定したとはいえ、サードパーティの対応があまり進んでいない。その理由の1つは、ARM64版を作りにくいタイプのアプリケーションがあるからだ。それは、コードの一部にx86／x64のアセンブラを使って記述されたアプリケーションだ。これは完全にx86／x64の命令なので、A64命令で書き直す必要がある。しかし、CPUのアーキテクチャが違うために簡単な作業ではない。

Windows 11のARM64ECによって

DLLの一部がx64コードのままでよくなった

　こうした問題に対して、Microsoftは、Windows 11でARM64EC（Emulation Compatible）というABIを追加定義した。ARM版Windows 11用のアプリケーションは、このARM64ECを使って開発することが可能になり、このときDLLの一部をx64コードのままにして、バイナリ変換で実行させることが可能になる。

　ARM版Windows 10で定義されたARM64 ABIでアプリケーションを開発すると、DLL呼び出しもARM64 ABIに従う必要があり、ARM64用として開発する必要があった。しかし、x64のアセンブラで記述されたコードが含まれるような場合、プログラムをAArch64/A64命令セットに書き換える必要があり、単純な再コンパイルでは対応できなかった。

　これまで、こうしたアセンブラ記述が問題で、ARM64版を開発できないアプリケーションがあったとしたら、ARM64ECを使うことでアセンブラ部分を書き換えることなく、ARM版Windows 11で動作可能になる。なお、ARM64ECでアプリケーションを開発するからといっても、必ずしもx86／x64コードを含む必要はない。

　このARM64EC ABIは、簡単に言えば、x64 ABIと同じになるように再定義されたAArch64/A64命令セット用のABIだ。つまり、Calling Conventionやアライメント、スタックの構造はx64と同じになり、スタブが不要になる。ただし、そのためには、プログラムはARM64EC ABIに対応したコンパイラで作成する必要がある（Visual Studioが対応）。

　Windows 11は、このARM64ECで作られているのか、とも思ったが、どうもそうではないようだ。タスクマネージャーの詳細タブでは、プログラムのアーキテクチャを表示できる。

　ここに「ARM64」と「ARM64(x64互換）」の2つが表示される。おそらく「ARM64(x64互換）」と表示されるのがARM64ECで作られたプログラムだと考えられる。しかし、Windows関連のプロセスはほとんどがARM64で、「ARM64(x64互換）」のプロセスは1つしかなかった。また、Windows PowerShellは、ARM64ECのようである。

　Powershellからは、ユーザーが開発したものを含め、x64のDLLを呼び出すことができる。Powershell用として提供されているモジュール（PowerShellにはパッケージマネージャーやリポジトリがあり、そこからモジュールをダウンロードして組み込める）の中には、ARM64対応されていないものもありそうだ。

　最初からARM64ECを採用して、ABIをx64互換としておいてくれたなら、フックやシェル拡張のモジュールもバイナリコンパイルしたものが利用できたのにと思うが、MicrosoftもWindows 10をARM対応させ、ARM64 ABIを定義するときに検討くらいはおそらくしただろう。しかし、採用しなかったのは、オーバーヘッドなどのなんらかの理由があったと考えられる。

　ARM版Windowsにおける日本国内での最大の関心事は、ATOKが使えるようになるかどうかだろう。とはいえ、世界を見渡してもサードパーティ製のIMEが使われている言語は少ない。主にATOKのためだけにARM版Windowsを改良するとは思えないので、ありえるとしたら、MicrosoftがARM64/ARM64EC対応を支援するぐらいしかないだろう。とはいえ、国内でも入手できる機種は限られていて、市場が小さすぎる。ジャストシステム側にATOKをARM64対応させる気があるかどうかが一番のポイントとなりそうだ。