Arm64X PE ファイル

Arm64X は、従来の Arm64 コードと Arm64EC コードの両方を一緒に含めることができる新しい種類のバイナリです。 このデュアル互換性により、Arm64X は、Arm デバイス上の Windows 上の従来の Arm64 プロセスと Arm64EC プロセスの両方に適しています。 これは、両方の ABI が使用するミドルウェアまたはプラグインに特に適しています。

Windows 11 SDK で導入された Arm64X バイナリは、Arm 上の Windows 11 と Arm 上の Windows 10 の両方で動作するポータブル実行可能ファイル (PE) の一種です。 Arm64X バイナリをビルドするには、「 Arm64X バイナリのビルド」を参照してください。

Arm64X バイナリのしくみ

基本的に、Arm64X バイナリには、個別の x64/Arm64EC バイナリと Arm64 バイナリ内にあるすべてのコンテンツが含まれていますが、ディスク上の 1 つのより効率的なファイルにマージされます。 ビルドされた Arm64X バイナリには、コード、エントリ ポイント、およびその他の要素の 2 つのセットがあり、ディスク上の領域を節約するための冗長な部分は不要です。

アプリケーションが Arm64X バイナリを読み込むとき、オペレーティング システムは変換を適用して、プロセスのアーキテクチャに応じて適切なセクションを公開します。 古い 3D 画像のような Arm64X バイナリを考えることができます。赤と青の両方の画像は、3D メガネのペアで赤または青のレンズを通して見ることができます。 x64 アプリでは DLL が x64 DLL であるかのように見えますが、Arm64 アプリでは Arm64 DLL と同じ DLL が表示されます。

透過的なオペレーティング システム変換により、x64 アプリケーションと Arm64 アプリケーションの両方が、他のアーキテクチャのコードも含まれていることを知らずに、同じ Arm64X バイナリを読み込むことができます。 そのため、Arm64Xバイナリは周囲の「色」をまとうことから「カメレオン」という愛称で呼ばれています。

既定では、Arm64X バイナリは Arm64 バイナリのように見えます。 この既定の設定では、Arm64X 形式を認識しない、または変換の適用方法を知らない Arm で Windows 10 を実行しているシステムが Arm64X バイナリを Arm64 プロセスに正常に読み込むことができます。

オペレーティング システムで Arm64X バイナリはどのように使用されますか?

Arm 上の Windows 11 では、Arm64 で x64 アプリケーションを実行する機能が導入されました。 ただし、 フォルダーを含む SysWoW64とは異なり、純粋な x64 オペレーティング システム バイナリの別のフォルダーはありません。 Arm 上の Windows 11 では、x64 アプリケーションと Arm64 アプリケーションの両方でバイナリを読み込み、 System32のバイナリを使用して API を呼び出すことができます。 開発者は、アプリが Arm64X バイナリとして読み込む必要がある可能性がある System32 でバイナリを再コンパイルするため、この柔軟性が可能です。

x64 アプリケーションと Arm64 アプリケーションの両方で、 System32内のバイナリを読み込んで操作できます。x86 用の SysWoW64 など、すべてのシステム バイナリを個別にコピーする必要はありません。

ミドルウェアまたはプラグインで使用する Arm64X

Arm64X バイナリのコア機能は、ディスク上の 1 つのファイルが x64/Arm64EC プロセスと Arm64 プロセスの両方をサポートできるようにすることです。 ほとんどのアプリ開発者は、両方ではなく Arm64EC または Arm64 としてアプリケーションを構築することに重点を置いているため、Arm64X は必要ない可能性があります。

ただし、 ミドルウェア または プラグイン の開発者は、そのようなコードが x64 または Arm64 プロセスに読み込まれる可能性があるため、Arm64X を考慮する必要があります。

Arm64X を使用せずに x64 プロセスと Arm64 プロセスの両方をサポートできますが、オペレーティング システムで特定の 64 ビット プロセスへのバイナリの正しいアーキテクチャの読み込みを処理する方が簡単な場合があります。

Arm 上の Windows 11 で両方のアーキテクチャをサポートする 3 つの概念的な方法は次のとおりです。

• 個別のバイナリ: 現在の標準的なプラクティスでは、複数のアーキテクチャをサポートするときに個別のバイナリが使用されるため、個別の x64 バイナリと Arm64 バイナリをビルドして出荷する方がソリューションに適している場合があります。 既存のメカニズムを使用して、関連するアーキテクチャ プロセスに正しいバイナリが確実に読み込まれるようにすることができます。

• Arm64X バイナリ: すべての x64/Arm64EC コードと Arm64 コードを 1 つのバイナリに含む Arm64X バイナリをビルドできます。

• Arm64X 純粋フォワーダー: Arm64X の柔軟性が必要だが、すべてのアプリ コードを Arm64X バイナリに入れないようにしたい場合は、純粋フォワーダー アプローチを使用できます。 コードのない小さな Arm64X バイナリは、ローダーを DLL の正しいアーキテクチャにリダイレクトします。

Arm64X を必要とする状況の例

状況によっては、x64 アプリと Arm64 アプリの両方をサポートするために Arm64X バイナリを使用する必要があります。 このような状況は次のとおりです。

• x64 アプリと Arm64 アプリの両方が呼び出す 64 ビット COM サーバー
• x64 または Arm64 アプリに読み込むプラグイン
• x64 または Arm64 プロセスに挿入される 1 つのバイナリ

いずれの場合も、Arm64X バイナリまたは Arm64X 純粋フォワーダーを使用して、1 つのバイナリで両方のアーキテクチャをサポートできます。

Arm64X バイナリのビルドの詳細については、 Arm64X バイナリのビルドに関するページを参照してください。