マイクロソフトがWindows 10 on Armを初めてリリースした際、エミュレーションでは32ビットx86アプリしか実行できませんでした。マイクロソフトは、顧客が実行したいWindowsアプリケーションの大部分、特に開発者がArm向けに再コンパイルする可能性が低い古いアプリが32ビット版であることがテレメトリで示されていると報告しました。しかし、これはすべてのWindowsアプリケーションを網羅しているわけではありません。
多くのゲームは64ビットですが、Microsoftは初期デバイスではゲームが「ターゲット顧客外」であると述べています。Adobe Photoshop、Illustrator、InDesign、Dreamweaverの32ビット版も利用可能ですが、これらは古いリリース（Creative Cloud 2018）のものであり、新しい機能が欠けています。
参照: Microsoft 365: チートシート (無料 PDF) (TechRepublic)
CorelDRAWには32ビット版も残っていますが、AIを活用した新機能は64ビット版でのみ動作します。多くのインストーラーは、32ビット版ソフトウェアであっても64ビット版に対応しています。
これを支援するため、Windows on Armに64ビットエミュレーションが導入されます。まだInsiderビルドの段階ですが、テスト結果は良好です。
64ビット対応ツール
マイクロソフトは、より多くの開発者がアプリケーションをネイティブ Arm バージョンとして再コンパイルすることを期待していた可能性があります。なぜなら、アプリケーションがそもそも 64 ビットになった理由はパフォーマンス上の理由であることが多く、エミュレーションで実行するのは理想的ではないからです。
つまり、開発者が必要とする言語とフレームワークのサポートを得ることを意味し、これも段階的なプロセスです。
Chromium、Chromium Embedded Framework、Electron は、2019 年後半から Windows on Arm で利用可能になっており、ネイティブ Chromium ビルドは 2020 年初頭に登場します。.NET 5 では ARM64 サポートが導入されましたが、WPF と WinForms のサポートはごく最近、.NET 6 の最初のプレビューで導入されました。完全な .NET 6 は 2021 年 11 月までリリースされず、.NET 5 で WPF ARM64 サポートが実現するまでにどのくらいの時間がかかるかについての議論はまだ続いています。
Microsoft による jClarity の買収は、Windows 10 向けに OpenJDK を Arm に移植する作業を引き受けたことを意味します。Python と Rust のネイティブ ビルドは存在します。IIS はまだ利用できません。また、Go の公式ネイティブ ビルドがないため、Git for Windows が遅れています。ただし、Wireguard VPN アプリを有効にするために特別に用意された、Arm 上の Windows 向けの Go 言語の非公式初期 ARM64 ビルドは既に存在します。OpenCL および OpenGL 互換パックは当初、Adobe が GPU アクセラレーションに大きく依存するネイティブ Photoshop を Arm 上の Windows 10 に導入できるようにするために開発されました。他の OpenCL および OpenGL アプリをサポートするプレビュー バージョンもありますが、OpenCL 1.2 以前と OpenGL 3.3 以前に限られます。
しかし、開発者たちが自分たちのアプリをAppleのM1 Armデバイス向けにネイティブ化するのに素早く取り組んでいる一方で、Windowsでは進捗が遅く、Microsoft自身のアプリでさえ遅い。OfficeとEdgeはネイティブで実行され、MinecraftのWindows 10（Bedrock）バージョンもネイティブで実行されるが、オリジナルのJavaバージョンは実行されない（OpenGLのかなり新しいバージョンが必要）。Visual Studio Codeはつい最近Armでサポートされたばかりで、Power Toysはまだ多くの依存関係によってブロックされており、Visual StudioのネイティブArmバージョンを提供する計画は現在ない。Microsoftは、開発者がArm PC上で開発作業を行うのではなく、より強力なx86システムからクロスコンパイルすることを期待しているが、Clangの開発者たちはArm上のWindows用のネイティブコンパイラを作成しており、これはエミュレーションよりも2倍速くビルドを実行する。
Adobeは12月にWindowsとM1 Mac向けのLightroomのARM版をリリースしました。また、PhotoshopのネイティブARM64版もベータ版として提供されています。最新リリースでは、スポット修復ブラシやコンテンツに応じた塗りつぶしと移動といった主要ツールが追加されています。しかし、Creative Cloudデスクトップアプリは2つのバージョンを同時に実行できず、ベータ版にはバージョン5.3以降（64ビットアプリケーションのみインストール可能）が必要なため、古い32ビット版Adobeアプリケーションをエミュレーションで同時に実行することはできません。デザイナーは通常、ワークフローで複数のCreative Cloudアプリケーションを使用します。
最新の x64 版 Photoshop のスタンドアロンインストーラーもシステム要件によりインストールに失敗しますが、ネイティブ Photoshop ベータ版と並行して、いくつかの Adobe アプリ（Photoshop を含む）の Creative Cloud 2019 Windows 版 64 ビット版をインストールすることができ、新しい 64 ビットエミュレーションでも問題なく動作しました。多くの場合、最も難しいのは 64 ビット版の入手です。スマートインストーラーは 32 ビット版を自動的にインストールすることが多いため、64 ビット版を探して直接インストールする必要があるかもしれません。
64ビットエミュレーションの現状
WindowsがArm上のソフトウェアでx86アプリケーションをエミュレートする方法は、x64 PC上でハードウェア命令エミュレーションを用いてx86アプリケーションをエミュレートする方法、つまり「Windows on Windows」抽象化レイヤーに基づいています。このシステムは依然としてARM64上のWoW64と呼ばれています（実際には、それぞれXTAJIT.DLLとWOWARMW.DLLを使用してx86アプリケーションとARM32アプリケーションの両方をエミュレートします。これは、ストアなどの多くのWindowsアプリケーションがArm上で依然として32ビットであるためです）。しかし、X64エミュレーションは実際にはWoWを使用していません。
バイナリを Arm アーキテクチャに変換するためのコア テクノロジは WoW に似ており、Microsoft が x86 エミュレーションで学んだ内容に基づいていますが、細部を見てみると、これは互換性に対する新しいアプローチです。
当時 Microsoft が私たちに伝えたように、x64 サポートを追加するにはより多くの作業が必要になり、時間がかかり、現在も進行中です。
x64 エミュレーションの最初の Insider バージョンは 2020 年末にリリースされました。当時、Windows カーネル チームの主席グループ プログラム マネージャーである Hari Pulapaka 氏は、64 ビット エミュレーションの最終バージョンでは、64 ビット アプリで利用できるアドレス空間の拡大と、64 ビット コードがレジストリを使用する方法により、32 ビットと同等かそれ以上の速度でアプリが実行されるはずだと示唆していました。
「一般的に、x86とx64のエミュレートされたアプリは、アドレス空間の広さを除けば、パフォーマンスは同等になるはずです。エミュレーションはまだ初期段階であるため、x64向けの最適化がすべて追加されているわけではありません。今後数ヶ月かけて実装される予定です」とPulapaka氏は述べています。
同様に、x86エミュレーションも改善が続いています。現在Insiderビルドで提供されているTurboTaxやQuickenといった.NETアプリケーションの一部操作を高速化する新たな最適化が実装されています。Surface Pro XやGalaxy Book Sなどの第3世代Windows on Armデバイスでは、これらの特定の命令を従来の2倍の速度でエミュレートできます。
初代Surface Pro Xでテストしたx64アプリケーションは、概ね正常に動作しましたが、一部のアプリケーションは起動直後にクラッシュしたり、単に閉じてしまったりしました（中には最初はクラッシュしたものの、その後は問題なく動作したアプリケーションもありました）。最高のパフォーマンスを得るには、アプリケーションを2回実行してください。1回目はコードをArmで実行できるように変換し、2回目はキャッシュから実行します（キャッシュ中にWindowsによってさらに最適化が行われ、パフォーマンスがさらに向上します）。
新しいインサイダー ビルドでは、より多くの ARM64 システム DLL が追加され、互換性が向上し、より多くのアプリが正常に実行できるようになります。また、以前はエミュレーションでは実行できなかったアプリが動作することがすでに確認されています。
参照:サービスとしてのソフトウェア (SaaS): チートシート (無料 PDF) (TechRepublic)
Signal、Slack、Bluestacks、Power BI Desktop、GIMP、Photoshop、Xboxアプリの64ビット版はすべてインストールされ、問題なく動作しました。Uraniumフレームワークを必要とするアプリはインストールと実行が可能ですが、動作が遅いのが難点です。AutodeskのSketchbookは、要求の厳しい描画ツールでも優れたパフォーマンスを発揮しましたが、クラッシュしやすいという問題がありました。Affinity Photoでも同様の問題が発生しましたが、予期せず終了すること以外は問題なく動作しました。
他の64ビットアプリケーションでは、さらに多くの問題が発生しました。CorelDRAWとPHOTO-PAINTはインストールして起動しましたが、すぐに閉じてしまいました。Camtasiaは管理者権限でインストールしましたが、録画しようとしたときにクラッシュしました。これらの問題は、アプリケーションに必要なDLLが含まれた新しいInsiderビルドがリリースされれば、すぐに修正される可能性が高いでしょう。Dropbox同期クライアントのように、Dropboxが提供していないネイティブドライバーを必要とするアプリケーションもあり、エミュレーションでは全く動作しません。
Photoshop、GIMP、Power BI Desktop の 32 ビットおよび 64 ビット エミュレーションのパフォーマンスをさまざまなタスクで比較しました (ただし、ソフトウェアの同じバージョンが常に見つかるとは限りませんでした)。一般的な編集タスクでは、エミュレーションで実行されている Photoshop の 32 ビット バージョンは、非常に近いパフォーマンスを示したネイティブ 64 ビット バージョンおよびエミュレートされた 64 ビット バージョンよりもわずかに速いことがよくありました。両方ともベータ版であり、完全に最適化されていないため、予想外ではありませんが、違いは通常、エフェクトが確定するまでに 2 秒かかるか 3 秒かかるかという程度で、多くの一般的な編集タスクは両方のバージョンで瞬時に完了しました。ネイティブ バージョンは、パノラマ写真の結合などの複雑な一連のタスクで明らかに有利で、エミュレーションでは 32 ビット バージョンの 2 倍以上、64 ビット バージョンの 4 倍の速度でした。
同様に、単純な写真編集は、より複雑なスクリプト アクションを実行するまでは、GIMP の 32 ビット バージョンの方が 64 ビット バージョンよりも若干高速でしたが、64 ビット エミュレーションでは 2 ～ 4 倍高速になりました。
Power BI Desktop は、32ビットエミュレーションで実行した場合、レポートの読み込みと Excel からのデータのインポートがわずかに高速化しました。ただし、Windows の最新インサイダービルドでは、64ビットエミュレーションのパフォーマンスが大幅に向上しました。Microsoft は、Arm 上での 64 ビットエミュレーションの拡張と最適化に力を入れていることは明らかです。
サーバーサイドアーム
マイクロソフトは、Windows for Armラップトップをリリースするずっと前から、Windows ServerをArm対応にする計画を発表していました。Armは、ストレージ、インデックス作成、検索といったAzure社内インフラの運用に利用されており、低消費電力、低コストのハードウェアとコンピューティング効率が特に重要となります。サーバーマザーボードサプライヤーによるプロジェクトの延期や中止によって遅延が生じている可能性はありますが、マイクロソフトはAmpere Altra、富士通、Marvell ThunderX2などのArmシリコン上でAzure向けにWindows Serverをテストしており、Marvellは2019年にArmポートフォリオが「社内の実稼働レベルのサーバー」に使用されていると発表していました。
2020 Arm DevSummit で、Windows カーネル チームのテクニカル フェローである Arun Kishan 氏は、Microsoft は VM ホスティング サービスに ARM64 上の Windows Server を使用することを検討しており、Windows Server の実行を含むサーバーの SystemReady 認定について Arm と連携しており、「Microsoft Azure での展開を可能にすることに一歩近づく」と述べました。
本格的な Windows Server on Arm が間もなく登場するというわけではありませんが、64 ビット エミュレーションは、実行したい Arm サーバー ワークロードの顧客にとって非常に重要であり、Microsoft が Windows クライアントにそれを追加するもう 1 つの理由となる可能性があります。
Azure の Arm サーバーは、Arm 上の Windows 10 をターゲットとする開発者にとって、Azure Pipelines などのツールを使用して CI/CD (継続的インテグレーション/継続的デプロイメント) システムを構築する機能という、欠けている重要な部分を補います。これにより、バグ修正や新しいコードを簡単にテストして展開できるようになります。
エクイニクスでWorks On ARMエコシステム・プロジェクトを運営するエド・ヴィエルメッティ氏は、開発者はテストのためにArmデバイス上で直接作業できる必要があると述べています。Works On Armは、Go、Node.js、そして複数のPythonライブラリを含むArmインフラストラクチャを活用したオープンソース・プロジェクトを提供し、開発者がArm上でコードを動作させ、データセンターで実行できるように支援しています。
「ネイティブビルドとネイティブテストができるようになったら、すぐにでも始めるべきです。実際の環境でテストすることで、テスト環境の忠実度が大幅に向上します。そして、開発者にターゲットアーキテクチャを日常的に使用するよう説得できれば、彼らは頑固さとフラストレーションから、あらゆる問題を解決してくれるでしょう」とヴィエルメッティ氏は述べた。
ヴィエルメッティ氏によると、複数のオープンソースプロジェクトがWindowsへのコード移植に関心を示しているものの、デスクトップWindowsだけでなくWindows Serverでも実行したいと考えているとのことだ。しかし、Armではまだそれが実現できていない。また、大規模なテストを行うにはクラウド上にArm VMが必要だ。これがNode.jsや、それに依存するGitHub Desktopなどのツールの妨げになっている。
「オペレーティング システムや言語、あるいは何らかの複雑な動作ライブラリを開発している場合、配布用にソフトウェアを一度ビルドするだけでなく、時間の経過とともに進化し変化するのに合わせて継続的にビルドできる十分なインフラストラクチャを用意することが非常に重要です」と Vielmetti 氏は述べています。
「大規模なコードの問題は、たった一人の開発者が自分のマシンでコンパイルして公開するコードを書くということではありません。大勢の開発者がさまざまなプラットフォームで貢献し、テストは大部分が自動化されているという点です。」
そして、その自動テストには、この場合は Arm VM を使用したクラウド インフラストラクチャが必要です。
「クラウドインフラの可用性は変革をもたらします。デスクトップハードウェアが処理できる速度よりも速い変更速度を持つプロジェクトをサポートできるようになるからです」とヴィエルメッティ氏は説明した。「コンピューティングリソースへのフルアクセスがなければ、大規模プロジェクトが何らかのリリースサイクルを維持することはほぼ不可能でしょう。複雑なシステムを開発する場合、新バージョンをどれだけ早くリリースし、スモークテストを実施できるかが大きな違いを生みます。このエコシステムがなければ、Windows開発者は『ビルド、テスト、試用』という好循環を維持するのが難しくなります。」
Azure Pipelines が最終的に Arm VM に対応すれば、多くの開発者が Windows on Arm にコードを持ち込むための障壁がなくなることを期待しています。その間、エミュレーションは着実に改善され、より幅広い（完全ではないにせよ）ソフトウェアをサポートできるようになりました。
