Après des mois de suspense, Microsoft a enfin levé le voile sur le degré de compatibilité de Windows dans sa version ARM, une question qui laissait nombre d'observateurs dubitatifs. Et la réponse est pour le moins surprenante…

Microsoft a provoqué un petit séisme lorsqu'elle a annoncé que Windows 8 serait proposé dans une version compatible avec les processeurs ARM. A vrai dire ça n'est pas la première fois que Windows sort du pré carré de l'assembleur x86 : Windows NT a été proposé entre autres sur plateformes Alpha, MIPS, PowerPC, et déjà en son temps sur ARM, et Windows CE sur MIPS et ARM. Toutefois c'est la première fois que la version "standard" de Windows s'aventure en dehors des sentiers battus du x86.

L'annonce a soulevé nombre de questions, à plus forte raison lorsque Microsoft a annoncé par la suite que la version ARM de Windows disposerait également, comme sur x86, du mode "classique" en plus de Metro, avec les bonnes vieilles fenêtres telles qu'on les connaît encore actuellement.

Voilà qui a donné naissance aux plus folles spéculations : comment Microsoft comptait-elle accomplir un pareil tour de force? S'il était parfaitement concevable que des applications soient distribuées en "fat binary" (contenant les codes compilés tant pour x86 que pour ARM, comme ce fut le cas un temps sur Mac lors du passage des processeurs 68k au PowerPC, puis du PowerPC au x86), du moins dans leur version pour Metro, l'architecture ARM laissait beaucoup moins de latitudes pour faire tourner les applications Windows en mode "classique" dans des contraintes matérielles autrement plus limitées.

Langages et tours de Babel

Reprenons ici quelques bases : un logiciel est un code binaire qui s'appuie sur deux langages, celui du processeur (l'assembleur), et celui du système d'exploitation (les Application Programming Interface, ou API, qui permettent à une application de faire appel aux fonctions de bas niveau gérées par l'OS). Chaque famille de processeur dispose de son propre assembleur (qu'on appelle également langage machine). Pour éviter de ré-écrire chaque application pour chaque assembleur, la majorité des logiciels est écrite dans un langage intermédiaire (la plupart du temps le C ou l'un de ses dérivés), qui est converti en assembleur pour une famille de processeur donnée grâce à un compilateur. Ainsi, pour peu qu'un système d'exploitation soit disponible sur plusieurs familles de processeurs, il suffit de compiler le même code pour chaque assembleur, produisant autant d'applications dédiées qui fonctionneront indifféremment sur chaque plateforme sans plus de travail. Les applications "fat binary" (ou encore "universal binary") contiennent plusieurs codes binaires pour plusieurs processeurs, seul celui concernant la plateforme sur laquelle l'application est lancée sera exécuté.

Cependant il existe différents remèdes aux incompatibilités de plateformes :

- lorsqu'on souhaite faire tourner un logiciel qui a été compilé pour un processeur incompatible avec celui de la machine sur laquelle on veut le faire tourner : un émulateur va permettre son exécution en lisant son code binaire et en l'adaptant à la volée à la machine cible (au prix d'un ralentissement qui exige que la machine hôte soit plus puissante que la source émulée pour une exécution en temps réel). Il s'agit là d'une reconstitution plus ou moins fidèle du matériel qui va exécuter jusqu'à l'OS lui-même, en plus de l'application, dans un environnement logiciel.

- lorsqu'on souhaite faire tourner un logiciel qui a été compilé pour un processeur compatible, mais qui fait appel aux API d'un système d'exploitation différent : un adaptateur (ou wrapper) va brancher les appels aux API d'un OS vers l'autre sans nécessiter la présence de l'OS auquel l'application se destine. Autre possibilité, la virtualisation permet d'exécuter concomitamment l'OS auquel l'application se destine par dessus l'OS hôte, rendant ainsi possible l'exécution d'une application dont l'assembleur est compatible avec celui du processeur.

Apple a utilisé un panaché de ces techniques pour conserver une compatibilité à travers les âges : l'émulation 68k sur PowerPC (d'abord de manière logicielle, puis directement au sein du processeur PowerPC), l'émulation PowerPC sur x86 (avec Rosetta), la virtualisation (avec Classic), et l'adaptation avec Carbon sur OS X.

Pas de choix pour Microsoft

Toutes ces solutions sont cependant assez gourmandes en ressources matérielles, et donc impensables sur des machines dont la RAM, la puissance du processeur, et l'autonomie sont restreintes, ce qui est le cas des tablettes. Pour qu'une application Windows fonctionne aussi bien sur x86 que sur ARM, Microsoft n'a donc d'autre choix que d'en passer par une recompilation, et le procédé des fat binaries. Et c'est précisément ce qu'elle propose avec Windows Runtime (WinRT), qui offre des API unifiées de Metro pour x86 aussi bien qu'ARM, permettant de programmer en C++, C#, VB.NET, et JavaScript.

Mais le problème de Windows 8 est plus structurel encore qu'une simple question d'API et d'assembleur. Si Microsoft a fini par proposer Windows sur ARM, c'est pour rester compétitive face à ces nouvelles plateformes mobile, iPad en tête. Les processeurs x86 s'étant avérés incapables jusqu'ici de concurrencer les processeurs ARM tant en termes d'autonomie que de tarif, pour que des machines équipées de Windows puissent répondre aux tablettes avec les mêmes arguments il a donc fallu en passer par ce changement de processeur. Mais les contraintes matérielles ne s'arrêtent pas là, puisque pour offrir la même autonomie et les mêmes tarifs, il faut un équipement en RAM similaire, et une gestion drastique de la consommation. Sachant que l'iPad n'est doté que de 512 petits mega-octets, comment donc faire tenir Windows et diverses applications dans si peu de mémoire? Et comment faire en sorte que sa gestion des tâches ne vienne à bout soit du processeur autrement moins puissant qu'un x86, soit de la batterie, voire des deux ? Impensable, tout bonnement.

Download this video to view it in your favorite media player:
High quality MP4 | Lower quality MP4

La réponse est arrivée il y a peu : Windows On ARM (WOA) est en réalité une plateforme différente de Windows 8.

Si WOA comprendra aussi bien Metro que Windows "classic", du moins en apparence, que Windows 8 sur x86, le mode classique sera en fait bien plus limité que sur x86. Microsoft a indiqué que WOA serait livré avec Office 15, comprenant Word, Excel, PowerPoint, et OneNote, ainsi qu'Internet Explorer 10… et c'est tout. Il sera impossible à l'utilisateur d'installer une autre application pour Windows classique sur une machine dotée d'un processeur ARM. A l'image de sa version Metro, il ne sera pas non plus possible d'installer un plugin pour Internet Explorer en mode classique. Ironie du sort, alors que Flash a été abandonné sur Android, et que Linux n'y aura plus droit que dans Chrome, si Windows On ARM devait prendre le pas sur la version x86, il n'y aurait guère plus que sur Mac que le plugin d'Adobe pourrait encore trouver refuge !


C'est là que subitement les choses s'éclaircissent. Le mode classique de Windows n'est pas un portage de sa contrepartie sur x86, pas plus que pour la suite Office. Il ne s'agit pas non plus d'émulation, mais de simulation : on reproduit le comportement apparent sans pour autant reprendre les rouages internes.

Ainsi, au lieu de proposer une version adaptée à l'interface Metro de sa suite bureautique, Microsoft a fait le choix de bâtir tout un décor en trompe-l'œil pour proposer un Office qui fonctionne de manière similaire sur plateforme ARM, sans ouvrir Windows classique à d'autres logiciels. Ce qui lui évite précisément d'avoir à gérer les problèmes cités plus haut. Il reste à voir quelles seront les limitations effectives, et il y en aura. Microsoft indique qu'Office 15 tiendra compte d'une interaction tactile, et sera pleinement compatible avec les fichiers Office, à défaut d'en reprendre toutes les fonctionnalités. Cependant le mode classique sera probablement plus exploitable avec un clavier et une souris — deux périphériques que toutes les tablettes compatibles WOA seront tenues de prendre en compte — eu égard à la taille des éléments d'interface qui se destinent plus à un curseur qu'à la pointe du doigt.

Certains s'étonnent d'ailleurs de voir la suite bureautique livrée en standard avec WOA, sachant qu'Office a toujours été une poule aux œufs d'or pour Microsoft, plus encore que Windows. Pour l'heure cependant rien ne dit que la suite sera pour autant gratuite, et on ignore encore le plan de bataille de Microsoft. Avec les rumeurs de l'arrivée d'Office sur iPad (lire La « vérité » sur Microsoft Office pour iPad éclatera « dans quelques semaines »), il se pourrait bien que Microsoft joue la carte du "tout sauf Android"…


Pour peu que les PC sur ARM rencontrent un certain succès, les développeurs qui voudront s'adresser au plus grand nombre devront favoriser l'interface Metro — et les conditions de Microsoft pour la distribution de leurs logiciels sur son magasin en ligne. Il restera toujours possible de proposer des applications pour Windows classique tel qu'on l'a toujours fait sur x86, mais il reste à voir si cette plateforme restera dominante à l'avenir. Tim Cook pour sa part semble convaincu que le PC tel qu'on l'a toujours connu représentera demain une minorité du marché, au profit des nouvelles plateformes mobiles telles que l'iPad.

Avec WOA, Microsoft tient une chance de pouvoir jouer sa carte sur ce nouveau marché, mais son choix de maintenir Windows classique coûte que coûte laisse quelque peu songeur. Même sur x86, c'est Metro qui sera l'interface par défaut, le mode classique étant relégué au second plan. Alors qu'Apple, malgré un dialogue entre OS X et iOS, semble déterminée à proposer des choses résolument différentes sur ses deux plateformes, Microsoft se targue de tourner le dos au compromis. Mais à vrai dire, la présence de cet ersatz sur ARM ne fait qu'office de cache-misère. Microsoft s'est accroché à sa philosophie "Windows Everywhere" autant qu'elle aura pu, pour ne plus le faire qu'en apparence histoire de ne pas se renier. Une pirouette d'autant plus inutile qu'elle n'inclut pas la compatibilité de la logithèque historique de Windows, fer de lance sur lequel Microsoft a toujours appuyé son hégémonie.

Il reste à voir quelle sera la stratégie la plus payante entre ces deux approches différentes, mais quitte à faire un pari risqué, Microsoft aurait peut-être eu meilleur compte à l'assumer jusqu'au bout. Windows 8 "consumer preview" (notez la litote pour "beta") sera disponible, dans sa version x86, dès le 29 février.