Microsoft rêve depuis longtemps d'un système Windows unifié qui serait capable d'offrir les mêmes capacités à tous les appareils pris en charge. L'objectif est en partie accompli avec Windows 10, mais Core OS ira plus loin. La route a été bien longue et les problèmes qu'il devra résoudre sont connus de longue date.
En dépit des efforts de Microsoft, Windows est finalement ramené au couple que tout le monde connait : le client et le serveur. Pour le grand public, la question se résume à Windows 10 en édition Familiale ou Professionnelle.
Il existe pourtant de nombreux rejetons. Bien qu’il ait (quasiment) cessé d’exister, Windows 10 Mobile a eu sa part de visibilité. On trouve Windows 10 également dans l’actuelle Xbox, dans le casque HoloLens ou encore le Surface Hub. Plus récemment, on a pu le voir également sur la Surface Pro X, pourtant équipée d’un SoC ARM. Toutes ces éditions ont une base technique identique (ou presque), mais de nombreuses spécificités.
Microsoft vise depuis longtemps un Saint Graal très personnel : le même système d’exploitation pour tous les cas de figure. L’éditeur y arrive progressivement avec Core OS. Tout ne va pourtant pas changer du jour au lendemain.
Notre dossier sur Core OS :
- Microsoft face au défi d'unification de Windows
- Core OS : caractéristiques et ambitions du « futur » système unifié de Microsoft
- Core OS : le plan de Microsoft pour migrer les développeurs de Win32 vers les Windows Apps
Le chemin erratique vers l'unification
Pour comprendre la route qui mène à Core OS, il faut revenir en arrière. Et même pas mal en arrière.
La première grande étape fut accomplie pendant la douloureuse genèse de Vista. Après un Windows XP installé depuis plusieurs années, Microsoft avait de grandes ambitions, particulièrement sur le terrain de l’ergonomie et de l’interface. On sait ce qu’il advint : une réinitialisation complète du projet, qui aboutit au bout de cinq longues années à Vista.
À l’époque, le système fut surtout remarqué par sa consommation de ressources. Mal ficelé dans sa version d’origine, Vista avait besoin de plus de mémoire pour fonctionner et sollicitait nettement plus souvent le disque dur. Il était le premier Windows à activer par défaut l’indexation des contenus et, à ce titre, passait de longs moments à fouiller dans les métadonnées pour construire son index. La situation s’était nettement améliorée avec le premier Service Pack, mais le système a gardé une réputation très médiocre.
Windows 7, quand il est arrivé trois ans plus tard, a pris des airs de sauveur. Certes Microsoft avait écouté les utilisateurs sur de nombreux points, mais il n’existait plus une énorme différence entre un Vista SP2 et un Windows 7 d’origine. En outre, l’énorme succès du nouveau venu masquait une réalité technique : un gros travail de découpage avait commencé dans Vista, que Windows 7 ne faisait que continuer.
Ce découpage partait d’une volonté de rationaliser la base technique de Windows, de regrouper les composants dans des briques logiques qui simplifieraient plus tard la réorganisation du système, en fonction des plans prévus par Microsoft (et qui ont changé depuis). L’objectif restait quand même, dans l’absolu, d’obtenir plus tard une base modulaire. Pourquoi ? Parce que l’éditeur entrevoyait déjà un sérieux problème à l’horizon : pouvoir fournir facilement un Windows à chaque catégorie de produits sans avoir à tout refaire à chaque fois.
Le travail a continué à travers Windows 8 et a en partie abouti dans Windows 10. Microsoft dispose ainsi aujourd’hui de OneCore, le socle technique de Windows qui peut être adapté à des besoins ou du matériel spécifique. Pour que Windows 10 puisse fonctionner sur ARM par exemple, il fallait que ce socle soit compilé pour cette architecture.
Mais un système d’exploitation est beaucoup plus qu’un socle technique et les contraintes vont plus loin qu’une compatibilité avec un architecture matérielle. Windows 10 n’y est-il pourtant pas arrivé ? Ne le trouve-t-on pas sur de nombreuses catégories de produits, y compris dans HoloLens et la Xbox ? Oui… et non. C’est en fait un joli petit bazar dont Microsoft veut justement se débarrasser pour faire place nette.
Mais pas de tabula rasa ici. Deux contraintes particulières s’imposent, qui aboutissent au résultat que l’on connait aujourd’hui : une arrivée très progressive.
Dette technique : ce satané Win32
La dette technique, dans le cas de Windows, retombe sur les anciennes technologies dont l’éditeur n’a pas réussi à se débarrasser. Et s’il en est une que Microsoft traine comme un boulet, c’est bien Win32.
Ce sous-système est arrivé en 1993 dans Windows NT et a été mis au contact du grand public deux ans plus tard dans Windows 95. Initialement, peu d’applications en tiraient parti, ce qui n’était pas un problème : le sous-système Win16 était encore là, nativement ou via une couche de compatibilité. Windows après Windows, Win32 a grandi, jusqu’à constituer aujourd’hui l’écrasante majorité des applications et jeux existant sur la plateforme.
Le sous-système rassemble tout ce dont un logiciel a besoin pour fonctionner, de l’outil technique pointu aux applications grand public, en passant par les antivirus, pare-feux et autres. Mais il était également utilisé par Microsoft pour toutes les fonctions de base de Windows : interface graphique, boites de dialogue, services, Shell, réseau et ainsi de suite. Tout le monde ou presque connait les principales bibliothèques dynamiques impliquées : kernel32.dll, user32.dll, gdi32.dll, etc.
Mais même si le sous-système s’est enrichi avec le temps, il héritait d’anciennes techniques, d’une ancienne architecture et d’une ancienne vision de l’avenir. Microsoft voulait donc proposer quelque chose de neuf, qui s’affranchirait des anciennes barrières, proposerait un modèle de développement plus clair, de meilleures performances, une sécurité inhérente et permettrait, à terme, de se débarrasser de Win32.
On se souvient des premiers essais dans ce domaine : Windows 8. La tentative était accompagnée d’une première boutique. Seulement voilà, la sauce n’a pas pris tout de suite. Principal grief : une parité loin d’être respectée avec Win32. Ces applications « Metro » (renommé plus tard en Modern UI) ne pouvaient tout simplement pas en faire autant que leurs anciennes cousines éloignées.
Windows Phone 8.1 et Windows 8.1
En outre, les choix ergonomiques de Microsoft dans Windows 8 ont largement contribué à l’échec qui s’en est suivi. Steven Sinofsky, en charge du projet, rêvait déjà d’un Windows commun à tous les appareils. Peu de subtilité dans la méthode adoptée : tout serait tactile. Le système avait été largement influencé par Windows Phone 7 sorti deux ans plus tard. Grands aplats de couleurs pleines, accent mis sur la police, zones d’actions larges : il fallait que tout soit pilotable au doigt. On connait la suite : une levée massive de boucliers.
Même si Microsoft a nettement infléchi cette direction avec Windows 10, cette patte caractéristique est restée scotchée à Metro/Modern UI pendant longtemps. Même quand le concept a évolué pour devenir Universal Windows Platform (UWP), on gardait cette orientation. Depuis, les changements se sont accumulés et l’éditeur n’a de cesse de jeter des ponts vers Win32 pour faciliter la transition.
Car Win32 est bel et bien un boulet. Microsoft veut s’en débarrasser depuis longtemps, mais est dans l’incapacité de le faire. En tout cas de manière radicale. Aujourd’hui, UWP contient une bonne partie de ce que sait faire Win32, mais l’inertie est pesante et Microsoft ne propose pas encore assez d’attraits. Le grand idéal « Codez une fois, exécutez partout » a encore du mal à se concrétiser. L’idée n’a cependant jamais été abandonnée chez l’éditeur.
L'agilité face aux form factors
Microsoft a un autre problème : l’agilité face aux différentes catégories de produits. L’éditeur avait beau dire que Windows 10 s’exécutait partout – ordinateurs, tablettes, téléphones, console, casque de réalité mixte, Surface Hub… – la réalité était loin d’être aussi simple. Il n’était ainsi pas possible de prendre simplement une application sur un appareil et de la transplanter sur un autre. Pas sans une grosse adaptation ergonomique au minimum. On a d’ailleurs pu le voir avec Modern UI puis UWP, de nombreux développeurs ne savaient pas vraiment comment bâtir leurs interfaces, créant un ensemble très disparate.
D’ailleurs, l’éditeur de Redmond ne donnait pas le bon exemple. Des éléments communs comme le menu Démarrer ou le centre d’Action n’étaient pas présentés et utilisés de la même façon sur un appareil ou un autre. N’en déplaise à ses rêves d’universalité, il était obligatoire de réfléchir soigneusement, pour chaque plateforme, à la manière dont le contenu allait s’afficher.
En outre, le changement était survenu brutalement, et une question revenait souvent : pourquoi changer les habitudes s’il faut tout réapprendre, pour un bénéfice incertain ? Windows 10 Mobile a depuis disparu, ne laissant essentiellement que l’argument ordinateurs/tablettes… où Win32 fonctionne aussi. Reste le développement des jeux sur Xbox, reposant en bonne partie sur des technologies de Windows 10 et facilitant leur arrivée sur PC.
Il fallait donc une solution pour désenclaver tout ce petit monde et créer un courant porteur uniforme à travers toutes les catégories de produits visées. Car Microsoft n'en démord pas. Plutôt qu'une approche façon Apple avec des systèmes d'exploitation spécifiques et un nombre croissant de briques communes, l'éditeur de Redmond veut un système d'exploitation complet commun. Sa réponse : Core OS, que nous aborderons dans la seconde partie de notre dossier.
