Du 64 bits pour Windows 10 sur ARM ? Oui, mais seulement via ARM64

Du 64 bits pour Windows 10 sur ARM ? Oui, mais seulement via ARM64

Épreuve de funambulisme

Avatar de l'auteur
Vincent Hermann

Publié dans

Logiciel

06/04/2018 5 minutes
32

Du 64 bits pour Windows 10 sur ARM ? Oui, mais seulement via ARM64

Le mois prochain, lors de la conférence Build, Microsoft permettra enfin de compiler en ARM64 via le SDK Windows. Ce qui ne résout en rien l’un des plus gros problèmes du système.

Actuellement, les applications UWP sont systématiquement compilées pour trois plateformes : x86, x64 et ARM. La machine se connectant aux serveurs récupère la version adaptée. Dans le cas d'un PC classique, la mouture x64, x86 s'il n’est pas 64 bits. Pour un PC ARM, la version ARM. Logique.

Ce fonctionnement n’est valable que pour UWP. Les logiciels Win32, passés à la moulinette du Desktop App Converter, sont limités à l’architecture supportée lors de la compilation par l’éditeur. Dans une majorité de cas, les logiciels sont en x86 ou capables d’assurer aussi le x64. Plus rarement, ils ne sont disponibles qu’en x64, comme Photoshop Elements. Un PC ARM ne peut pour sa part émuler que le x86.

L'éternel rapport bénéfices/risques

Comme on peut le voir, les PC ARM sont limités au seul 32 bits pour les applications, qu’il s’agisse d’ARM ou x86. L’arrivée le mois prochain d’une révision du SDK Windows, confirmée par Microsoft à Engadget, va donc faire bouger les lignes en ajoutant la compilation ARM64. Bien qu’il s’agisse d’un véritable 64 bits, la situation risque de ne pas être bouleversée pour autant.

Pourquoi ? Parce qu’il n’y a que deux cas de figure possibles. Soit il s’agit d’une application UWP et ARM64 devient le quatrième point de sortie pour la compilation, simplifiant largement le travail du développeur. Soit il s’agit d’un logiciel Win32, et l’éditeur tiers doit tout recompiler lui-même.

Mais le jeu en vaut-il la chandelle ? Côté UWP, la procédure est largement simplifiée, le framework étant adapté. Encore faut-il que les applications soient suffisamment entretenues par leurs éditeurs pour bénéficier du nouveau traitement. Pour Win32, la situation est plus complexe : l’éditeur devra impérativement tout recompiler lui-même vers une architecture qu’il ne connaît peut-être absolument pas.

Va immanquablement se poser la question de l’investissement et du rapport bénéfices/risques, surtout pour les logiciels Win32. Or, les bénéfices découlent de la part de marché de Windows 10 pour ARM, limité à quelques machines disponibles depuis peu de temps. Difficile pour les éditeurs tiers d’y trouver pour l’instant un véritable intérêt au vu du public concerné.

PWA : opportunité ou « aveu d'échec » ?

La situation est d’autant plus complexe que Microsoft a confirmé récemment que la version 1803 de Windows 10, diffusée la semaine prochaine, officialisera le support des PWA (Progressive Web Apps) par le système. Des applications web qui seront référencées de la même manière que les autres dans le Windows Store. Twitter a déjà sauté sur l’occasion, jetant sa version UWP à la poubelle, au profit de sa mouture Light (mobile) encapsulée.

Les PWA sont une vraie occasion pour le géant de faciliter l’arrivée de nouvelles applications dans son Store. Elles ne sont pas adaptées aux lourds calculs ou aux jeux AAA, mais conviennent pour la plupart des besoins. Si les développeurs répondent présents, la situation de Windows 10 pour ARM en sera d’autant plus améliorée, puisque les PWA peuvent fonctionner partout. Au détriment d’une compilation ARM64 qui aura moins de sens, en dépit du potentiel gain de performances.

Par ailleurs, l’annonce de Microsoft ne répond qu’en toute petite partie au souci du 64 bits. Les logiciels x64 ne pourront pas davantage fonctionner, car Windows 10 ne peut pas émuler ce code. L’arrivée d’ARM64 n’y changera rien, et des logiciels uniquement 64 bits comme Photoshop Elements resteront interdits de séjour sur le système.

Un vieux souci de plateforme logicielle

Malgré un système désormais robuste alimenté par les retours et demandes des utilisateurs (la Spring Creators Update est un très bon cru), Microsoft a toujours un problème de plateforme logicielle l’obligeant à jouer les funambules avec les technologies de développement

Un problème très loin d’être nouveau et qui a déjà plombé Windows 10 Mobile. Les développeurs ont le choix entre un Win32 qu’ils connaissent très bien mais n’évoluant plus, un UWP plus moderne mais incomplet, ou encore des langages web pour des PWA depuis peu. Microsoft pousse autant que possible UWP, mais ces API réclament une cassure dans les habitudes, et de réfléchir à de nouvelles ergonomies. Un cap que beaucoup n’ont pas passé, ou seulement de manière partielle, comme pour « faire plaisir » à Microsoft (qui avait largement incité par le porte-monnaie).

Notez tout de même que l’arrivée du nouveau SDK ARM64 se fera durant la conférence Build, du 7 au 9 mai. Il est probable que Microsoft en dise davantage sur ses projets pour ARM, la société ayant promis de dévoiler l’avenir de son système d’exploitation à cette occasion.

Écrit par Vincent Hermann

Tiens, en parlant de ça :

Sommaire de l'article

Introduction

L'éternel rapport bénéfices/risques

PWA : opportunité ou « aveu d'échec » ?

Un vieux souci de plateforme logicielle

Le brief de ce matin n'est pas encore là

Partez acheter vos croissants
Et faites chauffer votre bouilloire,
Le brief arrive dans un instant,
Tout frais du matin, gardez espoir.

Fermer

Commentaires (32)


Mouais.



Nous, on a recompilé VLC/win32 pour ARM64, et ça marche bien.


ils n ‘ont rien appris de windows RT ?



je sais qu’ils veulent nous forcer à utiliser UWP mias quand même…


Non, mais a un moment donné, faut enlever les œillères hein. Même en MacOS ou en BSD/Linux, si t’as un binaire x86, pour tourner sur un CPU ARM64, faut le recompiler en ARM/ARM64 hein… :spamafote:


Oui mais vous c’est particulier :p


> Soit il s’agit d’un logiciel Win32, et l’éditeur tiers doit tout recompiler lui-même.



Les PC ARM font tourner les appli Win32, donc le “besoin” de tout recompiler n’est pas catastrophique.



Finalement ce ne sont que les appli Win32 passées à la moulinette du Desktop App Converter qui posent problème, mais si l’appartement d’origine Win32 est disponible, il n’y a plus vraiment de problème.








the_mei a écrit :



Non, mais a un moment donné, faut enlever les œillères hein. Même en MacOS ou en BSD/Linux, si t’as un binaire x86, pour tourner sur un CPU ARM64, faut le recompiler en ARM/ARM64 hein… :spamafote:





Vive les dépôt multilib ! :P









Vincent_H a écrit :



Oui mais vous c’est particulier :p







<img data-src=" />



Ouais,

mais tous les studios de développement n’ont pas votre talent à la base ;)


Ben si, les perfs, vu que tu passes par la couche d’émulation…


Pas grave pour&nbsp;Photoshop Elements vu la puissance du CPU, au pire quelqu’un compilera bien GIMP en ARM64&nbsp;<img data-src=" />


On va attendre que Apple s’y mette et la ça deviendra magnifique…


Win32 n’est pas loin d’être décommissionné&nbsp;


Magique même ils auront le même souci mais ça s’ra génial, brillant révolutionnaire




La situation est d’autant plus complexe que Microsoft a confirmé récemment que la version 1803 de Windows 10 officialisera le support des PWA.. Twitter a déjà sauté sur l’occasion, jetant sa version UWP à la poubelle, au profit de sa mouture Light (mobile) encapsulée.





UWP is the new WInRT


Techniquement, côté Apple, ils ont déjà une tonne d’application compilées vers ARM64 : toutes les applis de l’AppStore (sauf celle tellement vieille qu’elles sont encore compilée uniquement pour ARM).



Donc pas le même problème que l’environnement Windows qui n’a pas d’applications pour sa plateforme ARM, hors les apps UWP du store et les app Win32 “converties” ou émulées.


Question bête : c’est vraiment indispensable pour Windows d’aller sur la plate-forme ARM ?


Je vais donner mon grain de sel : ça fait plusieurs Applis que je réalise sous UWP et pour être honnête, j’ai beaucoup de mal à m’y faire. Je code en win32 principalement, depuis 25 ans (premiers programmes sous Win3.1) et les paradigmes sont tellement différents pour UWP que s’en est désagréable. Surtout que beaucoup de limitations sont dues à l’environnement “Mobile”, mais le Mobile Windows est mort. Alors pourquoi traîner ces limitations ? Viser le full desktop serait bien plus cohérent, maintenant.

Faire des Applis compatibles avec le Store et Windows 10 devrait être AMHA beaucoup plus naturel qu’il ne l’est aujourd’hui, du moins dans un environnement x86.

Et puis tant qu’on y est : le changement de technologie continu sur des périodes courtes (3 ans en moyenne), de design aussi, ça devient difficile à suivre.


Oui, il y a une tonne de device “ultra mobile” en préparation donc ils suivent logique


Et là Microsoft va jouer ses dernières cartes : ou les utilisateurs suivent ou ils migrent vers ChromeOS+Android, Mac+IOS, Linux. Et si je me fie au fiasco WindowsMobile, c’est pas gagné.

J’espère me tromper, mais si je fais de la prévision axé sur moi-même, moi qui suis un pur Windowsien, si le desktop Win32 disparait au profit d’une version ARM “As A Service” comme le patron de MS le souhaite, je dégage sous Linux. Et je pense que pas mal de monde fera pareil.

Ce qui m’intéresse dans Windows, c’est son intégration des périphériques très divers et sa logithèque monstrueuse. Si c’est pour repartir “from scratch”, je pense qu’il y a mieux qu’un Windows for ARM boiteux.








teddyalbina a écrit :



Magique même ils auront le même souci mais ça s’ra génial, brillant révolutionnaire





Apple ce sera leur troisième changement d’architecture, Microsoft c’est le premier. Et puis la base est déjà migrée depuis longtemps.&nbsp;









Mr.Nox a écrit :



On va attendre que Apple s’y mette et la ça deviendra magnifique…





Pour le PWA Apple a suivi le sens inverse si je ne m’abuse.

&nbsp;

&nbsp;À la sortie de l’iPhone, Apple voulait des “ web apps ” programmées en AJAX, les applications natives ont tout chamboulé.



&nbsp;L’iPhone n’avait peut-être pas assez de puissance à l’époque pour bien exploiter ces “ web apps “.

&nbsp;



Pour le grand publique oui et non ( ça reste le seul moyen de target 7/8/8.110, le jour ou les part de marché de ces 3 la deviennent insignifiantes, éventuellement.. )

par contre c’est sur qu’entre les pwa et la maturations des api uwp, ça avance :)



pour les “pro” y as de la marge, Visual studio est tjrs en wpf et 32 bits par exemple et c’est pas pret de changer …



Ils forcent rien du tout, tu peux compiler ton truc pour du ARM si le coeur t’en dis.


Oui.


La logithèque monstrueuse ne disparaît pas, il y a une belle couche d’émulation x86


Windows fonctionnait sur Itanium et MIPS R4000.

En quoi ça sera le premier ?


Non, Jobs estimait que les gens allait installer de la merde sur SON téléphone qu’il a créé et que c’est inacceptable.



“When it first came out in early 2007, there were no apps you could buy from outside developers, and Jobs initially resisted allowing them,” writes Isaacson. “He didn’t want outsiders to create applications for the iPhone that could mess it up, infect it with viruses, or pollute its integrity.”

Voir sa biographie.



Les ressources n’étaient pas un problème, les appareils Symbian alors avec moins de puissance brute faisaient du multi tâche avec logiciels tiers sans soucis.








Leum a écrit :



Apple ce sera leur troisième changement d’architecture, Microsoft c’est le premier. Et puis la base est déjà migrée depuis longtemps.&nbsp;





Ce n’est tout bonnement pas vrai et le problème actuel date de la période où Microsoft a abandonné l’entretien de la couche d’abstraction matérielle (HAL) windows pour tous les procs RISC de l’époque (MIPS, Power, Alpha…) pour privilégier uniquement X86 et instauré l’avènement de .net framework sans imaginer qu’un jour il faudrait faire rentrer tout ça dans une main et l’entretenir en 3 ou 4G.

Ceci dît Apple a repris from scratch à chaque fois alors que Microsoft tente de faire entrer un éléphant par un chas d’aiguille.









Zulgrib a écrit :



La logithèque monstrueuse ne disparaît pas, il y a une belle couche d’émulation x86







Mais pas X64.&nbsp;



Zulgrib a écrit :



Windows fonctionnait sur Itanium et MIPS R4000.

En quoi ça sera le premier ?&nbsp;







J’avais oublié ces deux là. Mais Windows X64 a beaucoup de choses qui n’existaient pas a l’époque.&nbsp;



&nbsp;



loulnux a écrit :



Ce n’est tout bonnement pas vrai et le problème actuel date de la période où Microsoft a abandonné l’entretien de la couche d’abstraction matérielle (HAL) windows pour tous les procs RISC de l’époque (MIPS, Power, Alpha…) pour privilégier uniquement X86 et instauré l’avènement de .net framework sans imaginer qu’un jour il faudrait faire rentrer tout ça dans une main et l’entretenir en 3 ou 4G.

Ceci dît Apple a repris from scratch à chaque fois alors que Microsoft tente de faire entrer un éléphant par un chas d’aiguille.





Pour la base migrée je parlais d’Apple. Le noyau Darwin et de nombreuses briques logicielles sont communes aux divers OS.&nbsp;









Leum a écrit :



Mais pas X64.&nbsp;



J’avais oublié ces deux là. Mais Windows X64 a beaucoup de choses qui n’existaient pas a l’époque.&nbsp;



&nbsp;

Pour la base migrée je parlais d’Apple. Le noyau Darwin et de nombreuses briques logicielles sont communes aux divers OS.&nbsp;





Tout ceci a sans doute un sens que mes pauvres capacités refusent à décoder.