Connexion
Abonnez-vous

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

Épreuve de funambulisme

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

Le 06 avril 2018 à 10h22

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.

Commentaires (30)

Vous devez être abonné pour pouvoir commenter.

Abonnez-vous
votre avatar







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. 


votre avatar







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.

 

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



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

 


votre avatar

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 …


votre avatar

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

votre avatar

Oui.

votre avatar

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

votre avatar

Windows fonctionnait sur Itanium et MIPS R4000.

En quoi ça sera le premier ?

votre avatar

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.

votre avatar







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. 





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.


votre avatar







Zulgrib a écrit :



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







Mais pas X64. 



Zulgrib a écrit :



Windows fonctionnait sur Itanium et MIPS R4000.

En quoi ça sera le premier ? 







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



 



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. 


votre avatar







Leum a écrit :



Mais pas X64. 



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



 

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





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


votre avatar

Mouais.



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

votre avatar

ils n ‘ont rien appris de windows RT ?



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

votre avatar

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:

votre avatar

Oui mais vous c’est particulier :p

votre avatar

> 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.

votre avatar







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


votre avatar







Vincent_H a écrit :



Oui mais vous c’est particulier :p







<img data-src=" />


votre avatar

Ouais,

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

votre avatar

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

votre avatar

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

votre avatar

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

votre avatar

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

votre avatar

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

votre avatar



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

votre avatar

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.

votre avatar

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

votre avatar

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.

votre avatar

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

votre avatar

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.

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

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

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

  • Un vieux souci de plateforme logicielle

Fermer