Vous n'avez pas encore de notification

Page d'accueil

Options d'affichage

Abonné

Actualités

Abonné

Des thèmes sont disponibles :

Thème de baseThème de baseThème sombreThème sombreThème yinyang clairThème yinyang clairThème yinyang sombreThème yinyang sombreThème orange mécanique clairThème orange mécanique clairThème orange mécanique sombreThème orange mécanique sombreThème rose clairThème rose clairThème rose sombreThème rose sombre

Vous n'êtes pas encore INpactien ?

Inscrivez-vous !
Windows 10 on ARM : l'émulation des applications x64 dès novembre

Cette étape était attendue, car il n'existait pour le moment que deux possibilités pour les développeurs et les utilisateurs : du code ARM natif (32/64 bits) ou émulé seulement en 32 bits.

On sait depuis quelques temps qu'un travail est en cours sur l'émulation 64 bits, Microsoft le confirme aujourd'hui et précise que de premiers tests seront proposés à travers le programme Insider dès le mois prochain.

L'éditeur précise avoir optimisé Visual Studio Code pour Windows 10 on ARM (WoA) et que son application Teams sera bientôt proposé dans une version ARM64 native pour cette déclinaison de son système d'exploitation. 

7 commentaires
Avatar de Trit’ Abonné
Avatar de Trit’Trit’- 01/10/20 à 08:16:24

J’ai du mal à comprendre pourquoi il est si difficile d’émuler (et de virtualiser) des programmes x86 en 64 bits, alors que ça ne pose aucun problème (en comparaison, s’entend) pour du x86 32 bits.
Rien que sur VirtualBox, pour pouvoir lancer un OS invité en 64 bits, il faut avoir des instructions CPU spéciales activées (mon Core 2 Duo P7540 ne les a pas, alors que c’est un CPU 64 bits, comme tous les CPU x86 depuis 2003, si on fait exception des Atom), alors que ce n’est pas nécessaire pour un OS invité 32 bits (sauf que maintenant, à part Windows, il ne reste plus que des OS anciens ou de vieilles versions des actuels pouvant encore être installés en 32 bits). Franchement, je pige pas…

Avatar de brice.wernet Abonné
Avatar de brice.wernetbrice.wernet- 01/10/20 à 09:04:30

Trit’ a écrit :

J’ai du mal à comprendre pourquoi il est si difficile d’émuler (et de virtualiser) des programmes x86 en 64 bits, alors que ça ne pose aucun problème (en comparaison, s’entend) pour du x86 32 bits.

Attention, il y a un monde entre émuler un programme et émuler une machine. Notamment, émuler un programme Windows nécessite d'émuler les instructions et l'accès mémoire. Les appels au système ou à une DLL sont si possible effectués avec l'équivalent natif (la DLL di Windows 10 ARM) (enfin j'expère).

Emuler une machine x64 implique d'émuler tout: un UEFI, un processeur x64 complet avec les règles de protection mémoire, les possibilités d'accès au bus PCI, et la totalité du code exécuté.
Bref, rien à voir.

C'est un peu comme comparer de traduire des messages twitter aujourd'hui et traduire shakespeare dans son édition originale.

Avatar de Trit’ Abonné
Avatar de Trit’Trit’- 01/10/20 à 09:36:41

brice.wernet a écrit :

Emuler une machine x64 implique d'émuler tout: un UEFI, un processeur x64 complet avec les règles de protection mémoire, les possibilités d'accès au bus PCI, et la totalité du code exécuté. Bref, rien à voir.

L’UEFI n’a rien à voir là-dedans : on peut très bien avoir un OS x86 en 64 bits sur une machine avec BIOS classique (c’est ce qui fut d’ailleurs la norme entre 2003 et fin 2012, avec l’imposition de l’UEFI sur les PC avec Windows 8 préinstallé). Pour le CPU, je veux bien croire que les règles de protection mémoire aient changé entre l’ère du x86-32 et le x86-64 forcément plus évolué, car beaucoup plus récent (le premier x86 32 bits était le 386 DX, quand le premier x86 64 bits grand public était l’Athlon64, avec 30 ans d’écart entre les deux).

Avatar de 127.0.0.1 INpactien
Avatar de 127.0.0.1127.0.0.1- 01/10/20 à 10:09:20

Mais... aura-t-on un jour des applis ARM natives s'il y a un émulateur x64. Quel intérêt pour les devs de faire une appli ARM-only si une appli x64 tourne partout ?

C'est un peu comme la disparition de l'api win32. Tant que c'est supporté par la plateforme, pourquoi les devs switcheraient sur une autre api...

Édité par 127.0.0.1 le 01/10/2020 à 10:09
Avatar de Leum Abonné
Avatar de LeumLeum- 01/10/20 à 10:26:03
Trit’

Je pense que c'est plus une question de traduction d'appels / d'API différents.

Microsoft a fais le 32 bits au lieu du 64 en priorité tandis qu'Apple a banis le 32bit de Mac OS Catalina et n'émule que le 64bits avec Rosetta 2 sous Big Sur donc il doit bien y avoir des différences problématiques à maintenir les 2.

Avatar de Leum Abonné
Avatar de LeumLeum- 01/10/20 à 10:27:12
127.0.0.1

Les performances.

Sur Mac Mini DTK, les différences de performances d'Handbrake en émulé et en natif (après compilation) sont plus qu’impressionnantes.

Avatar de renaud07 INpactien
Avatar de renaud07renaud07- 01/10/20 à 14:23:51

Trit’ a écrit :

Rien que sur VirtualBox, pour pouvoir lancer un OS invité en 64 bits, il faut avoir des instructions CPU spéciales activées (mon Core 2 Duo P7540 ne les a pas, alors que c’est un CPU 64 bits, comme tous les CPU x86 depuis 2003, si on fait exception des Atom), alors que ce n’est pas nécessaire pour un OS invité 32 bits (sauf que maintenant, à part Windows, il ne reste plus que des OS anciens ou de vieilles versions des actuels pouvant encore être installés en 32 bits). Franchement, je pige pas…

Il est tout à fait possible de faire tourner un OS 64 bits sans les instructions de virtualisation (VT-x) c'est juste que ça faisait plus de boulot, donc les dev de virtualbox (et d'autres comme vmware) n'ont pas implémenté la fonction.

Par contre ça marche très bien avec QEMU par exemple. Mais les perfs sont pas ouf, ça rame beaucoup puisque ça revient à faire de l'émulation, comme ARM sur x86 par ex.

https://superuser.com/questions/430060/is-there-any-way-to-run-64bit-virtual-machine-on-64bit-processor-without-hardwar

Édité par renaud07 le 01/10/2020 à 14:28
Il n'est plus possible de commenter cette actualité.