Windows Info 第293回

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

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

ARM版Windows 11でタスクマネージャーを起動するとさまざまなコードタイプのプログラムが動いていることがわかる。ここで「ARM64(x64互換)」となっているのがARM64ECで作られたプログラムだと思われる。よく見るとMicrosoft.Photos.exeが「ARM」になっている

　ここに「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対応させる気があるかどうかが一番のポイントとなりそうだ。