Les applications métier fonctionnent-elles sous Windows on Arm ? — La réalité de l'émulation x64 (Prism) et des DLL/COM natifs

« Le nouveau PC prévu pour le mois prochain sera un de ces Copilot+ PC — est-ce que notre système métier fonctionnera dessus ? » À mesure que l’adoption en entreprise des PC équipés de puces Snapdragon progresse, de plus en plus de sociétés de développement et de services informatiques se voient poser cette question. La documentation commerciale annonce que « les applications existantes fonctionnent aussi via l’émulation ». Mais votre propre application métier utilise P/Invoke vers une DLL native fournie par un éditeur tiers derrière son interface C#, génère des rapports via un composant COM, et, en plus de tout cela, dispose d’un pilote installé pour un matériel dédié. Honnêtement, « est-ce que ça fonctionne ? » n’est pas une question à laquelle on peut répondre sur-le-champ.

La réponse courte, d’entrée de jeu : « l’application elle-même fonctionnera généralement bien. Ce qui est dangereux, c’est tout ce qui gravite autour de l’application. » L’émulation de Windows 11 gère le code x86/x64 en mode utilisateur avec une précision assez impressionnante, mais il existe une zone clairement définie « hors de portée de l’émulation », constituée des pilotes, des extensions shell et du mélange d’architectures au sein d’un processus — et cette zone est justement celle où les applications métier ont toujours eu l’habitude de vivre.

Cet article détaille le fonctionnement de l’émulation de Windows on Arm et ses limites, la règle fondamentale selon laquelle x64 et Arm64 ne peuvent pas être mélangés au sein d’un processus, le problème de combinaison propre aux applications .NET, ainsi que les étapes pratiques pour vérifier « notre application fonctionnera-t-elle sur une machine Arm » — le tout étayé par des sources vérifiables sur Microsoft Learn.

1. La conclusion d’abord

• Une application purement managée (.NET), ou une application de bureau x86/x64 ordinaire, fonctionnera presque intégralement sous l’émulation de Windows 11 Arm. L’émulation est intégrée à l’OS — aucune modification de l’application ni composant supplémentaire n’est nécessaire.¹
• L’émulation ne prend en charge que le code en mode utilisateur. Les pilotes en mode noyau ne sont pas émulés et nécessitent impérativement des versions natives Arm64. Les pilotes UMDF et les pilotes d’imprimante doivent également correspondre à l’architecture de l’OS.²³
• Les extensions shell, les IME, les technologies d’assistance — tout ce qui constitue une « DLL chargée dans un autre processus » (Explorer et autres) — doivent également être recompilés pour Arm64, en accord avec le système. L’émulation ne peut pas les sauver.⁴
• x64 et Arm64 ne peuvent pas coexister dans un même processus. Un processus x64/Arm64EC ne peut charger que des binaires x64 et Arm64EC ; un processus Arm64 ne peut charger que des binaires Arm64. Un exécutable x64 ne peut pas appeler une DLL Arm64, et inversement non plus.⁵
• Les mécanismes permettant de contourner cette restriction au sein d’un seul fichier sont Arm64EC (code Arm64 natif pouvant coexister avec x64 dans le même processus) et Arm64X (un binaire permettant à Arm64 et Arm64EC de coexister dans un seul PE, chargeable dans l’un ou l’autre type de processus). Arm64X est exactement ce qu’il faut pour un serveur COM in-process ou un plugin appelé depuis les deux architectures.⁵⁶
• .NET prend officiellement en charge Arm64, et vous pouvez publier nativement avec le RID win-arm64. En revanche, exécutez une application AnyCPU sur un runtime .NET Arm64 et le processus s’exécute en Arm64, donc si elle utilise P/Invoke vers une DLL native disponible uniquement en x64, son chargement échoue — un problème de combinaison à connaître.⁷⁸⁵
• Outre le matériel physique (un Copilot+ PC, etc.), vous pouvez mettre en place un environnement de test avec une VM Windows 11 Arm64 sur Azure, ou l’ISO Windows 11 Arm64, utilisable sur Hyper-V sur une machine Arm ou sur un Mac Apple Silicon. Notez que vous ne pouvez pas créer de VM Arm64 sur Hyper-V exécuté sur une machine x64.⁹¹⁰

2. Qu’est-ce que Windows on Arm — Les PC Snapdragon et Prism

Windows on Arm désigne Windows fonctionnant sur un processeur Arm64. Depuis 2024, la plupart des « Copilot+ PC » — une nouvelle catégorie de machines Windows 11 équipées d’un NPU capable de plus de 40 000 milliards d’opérations par seconde (40+ TOPS) — ont adopté des puces Snapdragon X, série basée sur Arm, ce qui en fait un sujet que les développeurs ne peuvent plus ignorer.¹¹¹²

Ce qui sous-tend la compatibilité avec les applications existantes, c’est l’émulation intégrée à l’OS. Voici son fonctionnement, en bref.¹

• L’émulateur compile en JIT des blocs d’instructions x86/x64 vers des instructions Arm64, en mettant en cache le résultat traduit par module afin d’accélérer les lancements suivants.
• Windows 11 peut émuler à la fois x86 et x64. Windows 10 on Arm ne peut émuler que le x86, donc toute discussion sur les applications métier x64 suppose en pratique Windows 11.
• Windows 11 24H2 a introduit un nouvel émulateur, Prism, qui améliore les performances par rapport au précédent et réduit l’utilisation du CPU. Prism est optimisé pour les puces Qualcomm Snapdragon.
• Les applications 32 bits (x86) s’exécutent au-dessus de la même couche WOW64 que sous Windows x64, et bénéficient de la redirection du système de fichiers/registre. Les applications x64, en revanche, n’ont pas de couche WOW64 — car les binaires système sont compilés au format Arm64X décrit plus loin, les applications x64 peuvent accéder à l’ensemble de l’OS (système de fichiers et registre) sans redirection.¹

Les informations CPU visibles depuis une application s’exécutant sous émulation sont celles du « processeur virtuel émulé ». Pour des raisons de compatibilité, même GetNativeSystemInfo renvoie la valeur émulée ; si vous voulez détecter si l’hôte est réellement Arm64, utilisez IsWow64Process2 ou GetMachineTypeAttributes.¹³

Pour les applications qui rencontrent des problèmes sous émulation, Windows offre également un moyen de modifier les paramètres d’émulation (préréglages par défaut/sûr/strict/très strict, plus des options individuelles fines) en effectuant un clic droit sur l’exécutable, en allant dans Propriétés, puis dans l’onglet Compatibilité. Cela sacrifie une partie des performances au profit de la compatibilité, mais cela vaut la peine d’être gardé en mémoire comme échappatoire pour le cas « ça fonctionnait sur une ancienne version de Windows on Arm ».¹⁴

3. Ce qui fonctionne sous émulation, et ce qui ne fonctionne pas

La réponse à « est-ce que ça fonctionne ? » est déterminée non pas par l’application elle-même, mais par le type de dépendance en jeu. Voici un tableau de décision.

Traduits en termes d’application métier, les signaux d’alerte sont les suivants :

• Clients VPN, agents de gestion d’actifs, produits de sécurité — ce sont essentiellement des assemblages de pilotes en mode noyau. Il faut vérifier auprès de l’éditeur qu’une version compatible Arm64 existe.
• Protection par clé USB (dongle), matériel dédié (instruments de mesure, terminaux de paiement, etc.) — la disponibilité d’un pilote de périphérique Arm64 est le facteur décisif.
• Outils « ajoutant une fonctionnalité à Explorer » — les extensions shell sont chargées dans l’Explorer Arm64, donc elles ne fonctionneront tout simplement pas tant qu’elles restent en x64.
• Même si l’application elle-même ne relève pas de ces catégories, un cas où l’installeur embarque un pilote (comme une sortie PDF implémentée via un pilote d’imprimante virtuelle) se heurte au même problème.

4. Le mélange d’architectures au sein d’un processus est impossible — la réalité de P/Invoke et de COM

Depuis l’ère 32 bits, il existe une règle immuable : « un processus 64 bits ne peut pas charger une DLL 32 bits ».¹⁶ Windows on Arm applique une règle structurellement équivalente. La documentation officielle décrit la compatibilité de chargement comme suit.⁵

Deux mécanismes apparaissent ici, et ils sont la clé pour concevoir une préparation à Arm.

• Arm64EC (Emulation Compatible) est une ABI de code Arm64 natif qui suit la convention d’appel, l’utilisation de la pile et la disposition des données de x64, de sorte qu’il peut coexister au sein du même processus avec du code x64 s’exécutant sous émulation. Lorsqu’une application x64 s’exécute sous Windows 11 on Arm, la majeure partie du code OS chargé dans ce processus est déjà compilée en Arm64EC, s’exécutant à vitesse native sans que l’application ne le sache jamais. Cela permet une migration progressive — Arm64EC-iser d’abord son propre code, morceau par morceau, pour gagner en performance, tandis que les DLL dépendantes restent en x64.⁵
• Arm64X est un format binaire qui permet au code Arm64 traditionnel et au code Arm64EC de coexister dans un seul fichier PE. Selon que le processus qui le charge est x64 ou Arm64, il se comporte respectivement comme une DLL x64 ou une DLL Arm64, ce qui le rend particulièrement adapté à une DLL susceptible d’être appelée par des processus de l’une ou l’autre architecture. La documentation officielle cite comme situations nécessitant Arm64X « un serveur COM 64 bits appelé à la fois par des applications x64 et Arm64 », « un plugin chargé dans des applications x64 ou Arm64 » et « un binaire unique injecté dans des processus x64/Arm64 ».⁶

Rendons concret l’impact réel sur les applications métier.

Cas 1 : un exécutable x64 accompagné d’une DLL native x64 (P/Invoke). Si l’ensemble du processus est uniformément x64, il s’exécute entièrement dans l’émulation. Vous ne pouvez pas mélanger une DLL Arm64 sous prétexte de vouloir « accélérer seulement cette partie » (comme le montre le tableau ci-dessus, ce n’est tout simplement pas chargeable).

Cas 2 : un serveur COM in-process. Un serveur COM in-proc n’est qu’une DLL, donc le tableau ci-dessus s’applique directement. Un client x64 ne peut utiliser qu’une DLL COM x64 (ou Arm64EC/Arm64X), et dès que l’application devient native Arm64, la DLL COM x64 devient non chargeable. Si vous devez prendre en charge les deux, transformez la DLL en Arm64X, ou appliquez le schéma éprouvé depuis l’ère 32 bits/64 bits : la séparation COM/IPC hors processus (division en processus distincts reliés par communication inter-processus). Franchir une frontière d’architecture au niveau d’une frontière de processus a toujours été l’approche standard.¹⁶⁶

Cas 3 : vous hébergez un plugin, ou vous êtes vous-même un plugin. Les compléments Excel, les plugins pour progiciels métier, les middlewares d’impression, et toute autre forme où « votre DLL est chargée dans le processus de quelqu’un d’autre » doivent correspondre à l’architecture de l’autre partie. Inversement, si votre propre application héberge des plugins, il faut réfléchir au périmètre d’impact : rendre votre propre application native Arm64 anéantira tous les plugins tiers en x64.

Au fait, vous pouvez vérifier quelle architecture est réellement un binaire donné depuis une invite de commandes développeur.⁵

link /dump /headers MyLibrary.dll | findstr machine
# 8664 machine (x64)            -> x64
# 8664 machine (x64) (ARM64X)   -> inclut Arm64EC
# AA64 machine (ARM64)          -> Arm64
# AA64 machine (ARM64) (ARM64X) -> Arm64X

5. Le cas des applications .NET — le piège d’AnyCPU et la détection de l’architecture

.NET (la famille de runtime Core) prend officiellement en charge Windows Arm64, et Windows 11/10 Arm64 figure explicitement comme OS pris en charge pour .NET 8/9/10. La publication consiste simplement à spécifier win-arm64 comme RID.¹⁷⁷

<!-- csproj : publier pour Arm64 natif -->
<PropertyGroup>
  <TargetFramework>net8.0-windows</TargetFramework>
  <RuntimeIdentifiers>win-x64;win-arm64</RuntimeIdentifiers>
</PropertyGroup>

dotnet publish -r win-arm64 -c Release

Pour une application entièrement composée de code managé, cela représente pratiquement tout le travail nécessaire pour la rendre native Arm64. Le JIT se contente d’émettre du code Arm64, et aucune modification du code source n’est généralement nécessaire. Pour les applications .NET Framework, .NET Framework 4.8.1 a ajouté la prise en charge native Arm64 (pour les machines Arm64 sous Windows 11 — le runtime 4.8.1 ne prend pas en charge les applications natives Arm64 sur les machines Arm sous Windows 10). Une application Framework restée compilée en x64 est traitée comme s’exécutant sous émulation.¹⁸¹⁹

Le problème réside dans la combinaison qui survient lorsque vous utilisez P/Invoke vers une DLL native. Sur une machine Arm, l’hypothèse de longue date « c’est une application .NET, donc AnyCPU fonctionne partout » est mise en défaut.

• Exécutée sous un SDK/runtime .NET Arm64, l’application s’exécute par défaut en tant que processus Arm64.⁸
• Un processus Arm64 ne peut pas charger une DLL x64 (voir le tableau du chapitre 4). Autrement dit, votre propre code AnyCPU reste intact, mais le chargement de la DLL native x64 que vous appelez via DllImport échoue.⁵
• À l’inverse, une application publiée en win-x64 s’exécute intégralement en tant que processus x64 et fonctionne à l’intérieur de l’émulation (DLL native comprise). Cette configuration n’obtient pas les performances natives d’Arm64, mais offre la compatibilité la plus élevée.¹²

Ce qui ressemble à « ça fonctionne parfois, parfois non » est, le plus souvent, en réalité une incompatibilité entre l’architecture du processus et l’architecture de ses dépendances natives. Comme première étape de tri, il est très utile de disposer d’un code capable de signaler l’architecture réellement utilisée par le processus en cours d’exécution.

using System.Runtime.InteropServices;

// L'architecture propre du processus (X64 s'il s'exécute sous émulation x64)
Console.WriteLine($"Process: {RuntimeInformation.ProcessArchitecture}");

// L'architecture réelle sous-jacente de l'OS (Arm64 sur une machine Arm)
Console.WriteLine($"OS: {RuntimeInformation.OSArchitecture}");

Un point d’attention : OSArchitecture n’a commencé à renvoyer « l’architecture réelle sous-jacente de l’OS, émulation mise à nu » qu’à partir de .NET 7. Auparavant, elle renvoyait X64 même sous émulation, donc le code sur .NET 6 ou antérieur utilisant cette API pour détecter « s’agit-il d’une machine Arm ? » ne se comportera pas comme prévu.²⁰²¹

Voici un récapitulatif des points de contrôle spécifiques à .NET.

• Ressources natives dans les packages NuGet : un package ne contenant que runtimes/win-x64/native n’a rien sur quoi se rabattre lors d’une publication pour win-arm64. Vérifiez le contenu du package (ou son dépôt) pour la présence de ressources win-arm64. Le mécanisme RID existe précisément pour ce « routage vers des ressources spécifiques à la plateforme ».⁷
• Configuration du SDK sur la machine de développement : sur une machine Arm, la version Arm64 de .NET s’installe normalement dans C:\Program Files\dotnet\, tandis que le SDK x64 s’installe dans C:\Program Files\dotnet\x64\, et les deux peuvent coexister. Quelle version dotnet run exécute réellement dépend de la cible pointée par PATH ou DOTNET_ROOT, gardez-le à l’esprit lors des tests.¹⁷
• Comment interpréter l’exception : une incompatibilité d’architecture dans un assembly managé se manifeste sous forme de BadImageFormatException (la référence officielle elle-même mentionne explicitement « le chargement d’un composant ciblant une plateforme différente » comme condition déclenchante).²²

6. Une checklist de préparation à Arm pour votre propre application

En pratique, il est efficace de procéder en trois étapes.

Pour les étapes 2 et 3, vous disposez des options suivantes pour un environnement de test.

• Matériel physique : une machine à base de Snapdragon comme un Copilot+ PC. En avoir au moins une sous la main est l’option la plus fiable, y compris pour le dépannage.¹²
• VM Azure : dans le portail Azure, filtrer les images par Arm64 et créer une VM Windows 11 Arm64 (une taille recommandée comme D2ps_v5, basée sur Ampere Altra). L’avantage est de pouvoir commencer les tests sans posséder la moindre machine Arm.⁹
• VM locale : une ISO Windows 11 Arm64 est officiellement distribuée, et vous pouvez construire une VM sur Hyper-V sur une machine Arm ou sur un Mac Apple Silicon basé sur Arm. Notez que Hyper-V sur une machine x64 ne peut pas créer de VM Arm64.¹⁰

Vous pouvez consulter l’état de compatibilité des produits tiers sur le site de statut publié par Microsoft (Works on Windows on Arm), et pour les problèmes de compatibilité des applications métier (LOB), le programme App Assure offre une assistance sans coût supplémentaire pour les plans d’entreprise éligibles. Disposer d’un canal officiel avant d’être bloqué par un « ça ne fonctionne pas et on est dans une impasse » constitue également un argument utile pour expliquer la situation au service informatique.¹²¹⁵

7. Une réponse pragmatique pour l’instant — Choisir parmi trois options

Être prêt pour Arm ne signifie pas « tout basculer en natif, sans autre choix ». En réalité, pour de nombreuses applications métier, une approche progressive et situationnelle constitue la réponse pragmatique.

Si vous disposez d’une base de code C++ importante, il existe un terrain intermédiaire entre (a) et (c) : Arm64EC. C’est la voie officielle pour le cas où « on ne peut pas migrer d’un coup une énorme application x64 » — en laissant les DLL dépendantes en x64 telles quelles, tout en portant nativement uniquement son propre code, morceau par morceau.⁵²³

Côté outillage, il existe une version native Arm64 de Visual Studio, ainsi qu’un ensemble d’outils de compilation disponible sur matériel Arm capable de cibler à la fois Arm64, x64 et x86. Les builds CI peuvent également être produites par compilation croisée sur une machine de build x64 existante, ce qui facilite la mise en place d’une configuration où « seule l’exécution des tests » se fait sur du matériel Arm réel ou une VM.²⁴²³

8. Résumé

• Windows 11 Arm peut exécuter les applications x86/x64 via l’émulation intégrée à l’OS, et les performances se sont encore améliorées avec Prism depuis 24H2. L’émulation x64 est une fonctionnalité de Windows 11 — Windows 10 on Arm ne gère que le x86.
• Le domaine de compétence de l’émulation se limite au mode utilisateur. Les pilotes en mode noyau/UMDF/imprimante, ainsi que les « DLL chargées dans un autre processus » comme les extensions shell, les IME et les technologies d’assistance, nécessitent impérativement des versions natives Arm64. Le fonctionnement ou non d’une application métier dépend moins de l’application elle-même que de ces dépendances périphériques.
• x64 et Arm64 ne peuvent pas coexister au sein d’un processus. Un processus x64/Arm64EC peut charger x64 plus Arm64EC ; un processus Arm64 ne peut charger que Arm64. Les serveurs COM in-process comme les plugins suivent cette même règle — Arm64X est la réponse standard pour un support double, et COM/IPC hors processus est la réponse standard pour franchir une frontière de processus.
• .NET peut publier nativement avec win-arm64, mais une application AnyCPU s’exécutant sur le runtime Arm64 s’exécute en tant que processus Arm64, elle échouera donc si elle utilise P/Invoke vers une DLL native disponible uniquement en x64. Faites le tri avec RuntimeInformation.ProcessArchitecture / OSArchitecture (ce dernier à partir de .NET 7).
• La procédure de vérification est un flux en trois étapes : « inventorier les dépendances -> tester tel quel sous émulation sur matériel réel -> passer en natif Arm64 si nécessaire ». Un environnement de test peut être mis en place via une VM Azure Arm64 ou l’ISO Arm64, et les entreprises peuvent également s’appuyer sur le support d’App Assure.
• Pour l’instant, la réponse pragmatique est un dosage selon la situation : « si ça fonctionne sous émulation, laisser tel quel », « vérifier auprès des éditeurs de pilotes/DLL leur état de support », et « passer en natif Arm64 si les exigences l’imposent (le C++ peut aussi emprunter la voie de migration progressive Arm64EC) ».

Articles liés

• Appeler une DLL native depuis C# : wrapper C++/CLI vs P/Invoke
• Appeler l’API Win32 en toute sécurité depuis C# — Guide pratique de P/Invoke (DllImport / LibraryImport / CsWin32)
• Comment appeler une DLL Native AOT C# depuis C/C++
• Distribution en fichier unique des applications Windows — Binaires uniques et limites des dépendances OS
• Exemple concret de pont COM : appeler une DLL 64 bits depuis une application 32 bits

Domaines de conseil associés

Komura Software LLC prend en charge l’étude de la compatibilité d’une application métier existante avec Windows on Arm, la conception de migrations d’architecture pour des applications impliquant des DLL natives ou une interopérabilité COM, ainsi que l’analyse de la cause racine de bugs ne survenant que sur des machines Arm.

• Développement d’applications Windows
• Conseil technique et revue de conception
• Investigation de bugs et analyse de cause racine
• Contact

Références

</content>

Articles associés

Articles récents partageant les mêmes étiquettes, pour approfondir des sujets proches.

Sujets associés

Ces pages replacent le sujet dans un contexte plus large de services et de décisions.

Services liés à ce sujet

Cet article est directement lié aux services suivants.

Questions fréquentes

Questions souvent posées lors d’une consultation sur le sujet de cet article.

Une application métier x64 ordinaire fonctionne-t-elle sous Windows on Arm ?

Dans la plupart des cas, oui. Windows 11 on Arm intègre une émulation qui exécute les applications x86/x64 sans modification, et depuis Windows 11 24H2, un nouvel émulateur nommé Prism a encore amélioré les performances. Cependant, l'émulation ne prend en charge que le code en mode utilisateur : les pilotes en mode noyau, ainsi que les extensions shell/IME et autres composants chargés dans d'autres processus comme Explorer, nécessitent impérativement des versions natives Arm64. Il vaut mieux voir cela moins comme une question sur l'application elle-même que comme une question sur ce qui gravite autour d'elle.

Un exécutable x64 peut-il appeler une DLL Arm64 ?

Non. Il est impossible de mélanger des binaires x64 et Arm64 au sein d'un même processus : un processus x64 (ou Arm64EC) ne peut charger que des binaires x64 et Arm64EC, et un processus Arm64 ne peut charger que des binaires Arm64. Le sens inverse — un exécutable Arm64 appelant une DLL x64 — est tout aussi impossible. Si vous avez absolument besoin d'une seule DLL compatible avec les deux, vos options sont Arm64X, un format qui permet au code Arm64 et Arm64EC de coexister dans un seul fichier, ou la séparation en processus distincts communiquant par IPC.

Que faut-il pour rendre une application .NET compatible Arm64 ?

.NET 6 et versions ultérieures prennent officiellement en charge Windows Arm64, et il suffit de publier avec le RID (identifiant de runtime) win-arm64 pour produire un exécutable natif Arm64. Pour une application entièrement en code managé, c'est pratiquement tout le travail — mais si vous utilisez P/Invoke vers une DLL native, ou un package NuGet qui embarque des ressources natives, vous devez vérifier qu'une version Arm64 existe pour chacun d'eux. Pour les applications .NET Framework, la version 4.8.1 prend en charge l'exécution native Arm64 sous Windows 11.

Quel type de logiciel ne fonctionne pas sous Windows on Arm ?

Les logiciels incluant des pilotes en mode noyau arrivent en tête de liste. Les pilotes ne sont pas émulés, donc les clients VPN, les produits de sécurité, les périphériques virtuels et les protections par clé USB (dongle) ne fonctionneront pas sans pilote Arm64. Viennent ensuite les extensions shell, les IME et les technologies d'assistance qui chargent des DLL dans des processus côté OS, les applications interdisant la génération de code dynamique, ainsi que les jeux dépendant d'anciennes versions d'OpenGL ou de pilotes anti-triche. Pour les périphériques, tout dépend également de l'existence ou non d'un pilote Arm64.

Profil de l’auteur

Page de présentation de l’auteur de l’article.

Go Komura

Représentant de KomuraSoft LLC

Spécialisé dans le développement de logiciels Windows, le conseil technique et l’analyse de pannes, notamment pour les systèmes existants et les incidents difficiles à reproduire.