Bonjour,
je n'ai pas de machine windows (et encore moins d'ARM), cependant je me permets de spécifier ce qu'on entend par 32/64 bits et x86/Arm. Je préfère qu'on soit sûr d'utiliser les mêmes termes.
Il s'agit des spécifications du jeu d'instruction qu'exécute le processeur. Le jeu d'instruction définit quelle séquence binaire correspond à quelle instruction et quelles sont les opérations élémentaires (additions et autres opérations mathématiques, lecture/écriture dans un registre du processeur, contrôle du flot d'exécution … ) que réalisent le processeur. Le jeu d'instruction le plus courant pour les ordinateurs de bureau, stations de travail et autres est x86. Pour les processeurs de portable ou de systèmes embarqués, on rencontre plus souvent le jeu d'instruction ARM. Il existe plein d’autres jeux d’instructions (MIPS c'est celui par ex. de la Playstation 2, RISC-V, etc …).
Le processeur implémente sous forme de circuits ces opérations. Ces opérations doivent définir une (ou quelques) taille fixe pour les entrées manipulées, puisque les données sont stockées dans des cases mémoires au sein du processeur appelées registres. Pendant des années, le coût de la mémoire étant limitée, nous utilisions des registres avec 32 bits. Ces contraintes matérielles ont été un peu relaxées, et la plupart des systèmes d'exploitation et logiciels ont décidé de s'adapter aux architectures 64 bit. Bien qu’il soit peu probable que cela devienne la norme, il existe déjà des jeux d'instructions et des machines (serveurs/stations de travail) fonctionnant avec 128 bits.
Le jeu x86 a été conçu pour des processeurs en 32 bit, puis a été adapté en un jeu d'instruction x64, permettant d'exécuter à la fois des programmes en 64 bits et en 32 bits.
Lors de la compilation des programmes, c'est-à-dire lorsqu'un logiciel passe d'un code source (texte intelligible pour un humain) à un logiciel binaire (intelligible pour un processeur), l'architecture de la machine qui va exécuter le programme doit être spécifiée. Les logiciels peuvent être adaptés pour différentes architectures « cibles », mais cette adaptation est souvent complexe et longue pour le programmeur. On utilise parfois un interpréteur/simulateur qui exécute le programme dans un jeu d'instruction, et traduit au cours de l'exécution les instructions d'un binaire en le jeu d'instruction de la machine hôte.
Application à notre problème :
La surface X pro possède un processeur avec le jeu d'instruction ARM64. Le système d'exploitation Windows de la machine a été adapté pour cette architecture. Les programmes qui tournent « nativement » sont ceux écrits en ARM(32 bits) ou en ARM64(aussi dénoté AArch64). Il peut exécuter
via émulation des programmes écrits en x32, mais n'exécute pas les programmes en x64. La plupart des programmes pour Windows étant écrit pour x64, il faut le temps que les développeurs adaptent leur logiciel (si ça les intéressent) pour ARM64.
De ce que je peux lire ici sur
https://docs.microsoft.com/en-us/windows/uwp/porting/apps-on-arm-troubleshooting-x86#shell-extensions, je comprends que ce n’est pas tant l'Input Method Editor qui poserait problème, que les librairies sur lesquelles il repose.
Je regarde le code rapidement sur gitlab afin de comprendre un peu mieux le fonctionnement du pilote bépo. Même si ce problème ne me concerne pas directement, il me rend curieux 😃
Edit : formatage du texte. En espérant avoir pu t’éclairer sur la différence 32/64 bits et x86/arm. Je ne pense pas avoir tout expliqué, mais tu est peut-être déjà familier avec ces notions d’ architecture des ordinateurs.