Core OS : le plan de Microsoft pour migrer les développeurs de Win32 vers les Windows Apps

Après les caractéristiques et ambitions principales de Core OS, nous plongeons plus dans les détails techniques de Win32, ses évolutions et ce qui attend les développeurs. Contrairement aux tentatives passées de Microsoft dans ce domaine, la nouvelle approche est nettement plus « douce ». La migration avance, mais il reste encore des obstacles.

Nous avons dans nos précédents articles expliqué comment Core OS allait représenter un nouveau chapitre de l’histoire de Windows, en apportant une solution souple aux problématiques actuelles. Microsoft a en effet longtemps été coincée entre de vieilles interfaces de programmation, très utilisées mais peu sécurisées, et de nouvelles, beaucoup plus sûres mais également plus limitées.

Presque dix années d’errances, ponctuées par des échecs retentissants comme Windows RT, auront infléchi le plan initial vers un projet beaucoup plus intégré où, normalement, les développeurs devraient s’y retrouver.

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 problème posé par Win32

Qu’appelle-t-on d’abord Win32 ? C’est un ensemble d’interfaces de programmation, exposant aux développeurs un socle normalisé de fonctions exploitables. Pour afficher une fenêtre par exemple, pas question de réécrire le code d’une fonction considérée comme triviale.

Comme indiqué dans notre précédent article, Win32 est apparu d’abord avec Windows NT en 1993, pour suivre l’évolution technique vers le 32 bits. Les anciennes API ont été rassemblées dans le groupe Win16. Les utilisateurs connaissent probablement les trois bibliothèques principales de Win32 : Kernel32.dll, User32.dll et GDI32.dll. Chacune expose des fonctions essentielles.

• Kernel32 : fonctions de base du noyau, pour des appels directs à l’API du noyau NT (Native API).
• GDI32 : fonctions graphiques de base (dessins, polices de caractères, rastérisation...)
• User32 : fonctions de l’interface graphique (shell, dialogues et menus)

On y trouve également le réseau (ws2_32), la manipulation du registre (advapi32), les dialogues classiques (comctl32) ou encore la gestion COM (ole32).

Avec le temps, le nombre de fonctions Win32 a été décuplé. Cette augmentation était à la croisée des demandes des développeurs et du sens que voulait donner Microsoft à l’évolution de Windows. Il fallait également pouvoir interagir avec un nombre croissant de produits.

Mais Win32 a été construit dans les années 90, avec les techniques et inquiétudes d’alors. Il n’était pas tant question de sécurité que de fournir au plus vite ce qui était demandé. En outre, Microsoft voulait donner rapidement accès à des API de composants qui, s'ils étaient liés à Windows, restaient indépendants : Internet Explorer, DirectX, Office, etc. Ce sont les fameuses API COM.

Le modèle retenu étendait largement Win32, exposant tous les composants importants en COM. Il devait établir un environnement dans lequel les logiciels pourraient s’ébattre gaiement. Ce fut certes le cas – et ça l’est toujours en partie – mais il y eut un prix à payer : les malwares. Même si le problème a commencé surtout avec Windows 95, il n’a fait que prendre de l’ampleur, jusqu’à la « crise » sous Windows XP, aboutissant à un Service Pack 2 (qui intégrait pour la première fois un pare-feu) et retardant Vista.

La situation était d’autant plus sérieuse que les comptes créés sous Windows étaient par défaut en droits administrateur, sans aucun verrouillage avant d’entreprendre des actions importantes, comme installer un programme. On se souvient de Sasser, si répandu qu’il suffisait de laisser connectée à Internet une machine Windows XP non mise à jour pour qu’elle soit infectée en quelques minutes, grâce à une faille de sécurité.

Il fallait donc réformer en profondeur l’architecture du système.

Vista et Windows 7 : MinWin et la recherche d’un dénominateur commun

On s’en souvient, Vista eut la désagréable mission d’introduire de lourds changements. Système de transition par excellence, il n’avait clairement pas reçu tout le travail de finition nécessaire avant sa commercialisation, surtout à cause de la réinitialisation complète du projet Longhorn. Son Service Pack 1 avait largement amélioré la situation.

Si beaucoup se rappelleront sa lourdeur et le déluge de fenêtres agaçantes de confirmation des actions (UAC, User Account Control), il était un mal nécessaire. D’abord parce que Windows ne créait plus par défaut des comptes administrateur, mais également parce sous le capot, un gros travail de tri avait commencé.

Microsoft avait en effet décidé de faire du ménage, voulant rassembler tous les composants essentiels de son système d’exploitation. Le résultat s’appelait MinWin et contenait alors l’immense majorité des composants communs de Windows (couvrant toutes les éditions de Vista et les moutures de Windows destinées à l'embarqué). L’objectif était déjà posé : démêler et documenter consciencieusement les dépendances de la base technique.

Le nom MinWin fut surtout popularisé (du moins chez les passionnés) par Windows 7, car le tri avait continué. MinWin prit alors sa dimension de « Windows minimal » (il faisait tourner correctement les programmes), Microsoft dégraissant petit à petit sa liste de composants pour ne garder que l’essentiel. Ces composants étaient accompagnés d’un chiffre correspondant à une couche, selon qu’ils était plus ou moins proches du noyau.

Mais il y avait d’un côté l’architecture du système, et de l’autre les API fournies aux développeurs. Comment mieux contrôler les accès et limiter les risques ?

Windows RT, la réponse radicale et erronée au problème

Windows RT était une variante de Windows 8 dans laquelle il était impossible d’installer autre chose que des applications provenant du Store. Impossible par exemple d’installer Firefox en allant récupérer le fichier depuis le site de Mozilla.

Ce fut le premier essai, radical, de pousser les développeurs à se servir d’autre chose que de Win32. Pouvait-on cependant parler réellement de mise à l’écart de Win32 ? Non, car les composants impliqués sont trop profondément imbriqués dans Windows pour pouvoir imaginer un ménage total.

Même si l’accent était largement mis sur Metro (renommé plus tard Modern UI) et les nouvelles API de ce qui constituerait plus tard UWP (Universal Windows Platform), on retombait bien sur des DLL Win32 dans les fondations. Tout simplement parce qu’en l’espèce, elles sont inévitables.

Les développeurs n’avaient alors le droit qu’à un sous-ensemble de Win32 appelé MinCore et un lot d'API COM, comprenant surtout de nouvelles appelées « API WinRT » et certaines anciennes API COM. Dans la vision de Microsoft, cette méthode permettait de limiter grandement les risques en orientant les développeurs vers des interfaces considérées comme « safe ».

Ce mouvement était motivé par une volonté spécifique : séparer les bibliothèques système de bas niveau de celles de plus haut niveau. MinCore fut enrichi avec la version 8.1 de Windows et a posé les bases de ce que l’on appelle aujourd’hui « OneCore », et qui concerne surtout les Windows récents (nous y reviendrons).

Windows RT fut un échec aussi fracassant que la méthode de transition adoptée par Microsoft. La raison en était simple : les API proposées en remplacement n’étaient pas assez nombreuses (ni vraiment au point). L’écart était même colossal, bloquant les développeurs dans leurs choix et ne laissant de la place qu’aux applications bureautiques n’ayant pas besoin de fonctions bas niveau. Impossible pour des éditeurs de jeux ou de logiciels type Photoshop de basculer sur ce modèle. L'arrivée de Windows 8.1 améliorera la situation, sans combler le fossé pour autant.

Sans de nombreuses applications, la plateforme ne pouvait pas rencontrer le succès, les utilisateurs étant vite frustrés du manque de possibilités. Ce d’autant qu’un produit vendu sous l’appellation « Windows RT » renvoyait quand même à Windows, traditionnellement associé au principe de rétrocompatibilité.

Windows 10 S, le Desktop Bridge et l’approche plus progressive

Microsoft a refait depuis un essai avec la version S de Windows 10 (devenue le mode S, optionnel), elle aussi limitée au Store, mais avec une nuance majeure : les développeurs peuvent maintenant publier dans la boutique des logiciels totalement Win32, via le Desktop Bridge (anciennement Centennial). Les binaires sont préparés par les serveurs et envoyés sous une forme encapsulée permettant de profiter de certains avantages, comme la désinstallation propre.

Plus en détail, au-delà de la seule conversion au format APPX, les développeurs ont le choix de migrer ou non tout ou partie du code vers des API plus récentes, dont le nombre a largement augmenté avec les années.

Cette nouvelle approche, beaucoup plus discrète, est foncièrement différente. Elle a permis à de nombreux éditeurs de publier dans le Store des applications aussi connues qu’iTunes, témoignant d’une confiance plus importante des entreprises.

Pourquoi ce changement ? Parce qu’il permet justement de faire atterrir en douceur les applications dans la boutique. La conversion initiale ne réclame pratiquement aucun changement (à moins que le code ne soit très ancien). Les développeurs peuvent ensuite modifier le projet pour lui faire adopter des capacités inhérentes aux applications « modernes » (appelées Windows Apps) : distribution à tous les appareils Windows 10, mises à jour automatiques, prise en charge du centre d’action, des notifications et des vignettes dynamiques, ajout de la monétisation, etc.

Pour Microsoft, le plus gros argument est sans conteste la possibilité de distribuer une même application à tous les appareils compatibles. Mais ce doux rêve est dans la pratique complexe, et il aura fallu du temps pour que la vision se concrétise, via une approche de la migration beaucoup plus progressive. C’est là qu’interviennent OneCore et Core OS.

OneCore, OneCoreUAP et les socles d’API

Dans quel état est aujourd’hui Win32 ? La réponse n’est pas simple, expliquant les transitions décrites plus tôt.

Les développeurs souhaitant aujourd’hui publier une application sur Windows ont plusieurs possibilités. S’ils ne visent que les PC classiques, ils peuvent rester sur les technologies établies de longue date. Cependant, Microsoft s’avance vers un modèle plus uniformisé, et à terme standardisé (en matière de développement).

Comme dit précédemment, les API Win32 se répartissent en plusieurs catégories. Il y a d’abord toutes celles que l’on est sûr de trouver sur n’importe quelle édition de Windows 10. Elles sont rassemblées dans OneCore, qui établit un socle fonctionnel minimal commun à toutes les dernières versions du système, comme expliqué précédemment.

Mais alors, cela ne signifie-t-il pas qu’une même application peut fonctionner partout de la même manière ? Non, car en fonction de l’appareil visé, le shell n’est pas le même. Nous avons abordé ce point dans un précédent article, soulignant le problème posé par des éléments aussi simples que le centre de notifications, dont l’ergonomie changeait par exemple entre Windows 10 classique et Mobile. Parmi les shells, on trouve Desktop, Mobile, Xbox et Windows 10.

Un développeur visant OneCore aura donc l’assurance que son programme se chargera correctement, tant que les questions de shell n’entrent pas en ligne de compte. Une même fonction n’aura en effet pas la même interprétation visuelle selon l’appareil qui l’exécute. Par exemple, CreateDialog aura un impact dans le shell Desktop, mais pas sur Xbox. C’est l’intérêt de OneCore : s’assurer que le cœur d’un programme est capable de tourner sur l’ensemble des derniers Windows.

Et si l’on souhaite aller plus loin ? Pour s'assurer que l'application sera totalement fonctionnelle, le développeur n'a qu'une solution : se restreindre aux API Win32 compatibles UWP, regroupées dans une bibliothèque appelée « WindowApp.lib ». Il aura alors la certitude que le fonctionnement sera le même sur toutes les versions de Windows 10, quel que soit le shell. WindowsApp.lib est donc un sous-ensemble de OneCore.

En parallèle, Microsoft a rendu la plupart des API COM WinRT/Modern/UWP accessibles depuis des applications classiques. Il y a donc un continuum entre les apps Win32 classiques, celles qui n’utilisent que OneCore, et les app UWP. En clair, plus on veut augmenter le niveau de compatibilité avec les versions Windows 10, plus le champ d'API Win32 est restreint.

Avec le temps, Microsoft espère que toutes les applications seront migré petit à petit vers UWP et seront toutes des Windows Apps. Les conditions sont maintenant réunies puisque les plus grosses absences ont été comblées entre temps, permettant – en théorie – à presque tous les types de programmes de fonctionner, y compris ceux ayant des besoins en accélération graphique ou en accès au matériel.

Contrairement aux premières tentatives avec Windows RT, il n’y a même plus besoin de langages tels que C# ou XAML. Plus besoin du Store non plus dans l’absolu : une Windows App peut être téléchargée et installée depuis un site web.

UWP est pourtant bien une promesse de plateforme universelle. Alors que manque-t-il ? Concrètement, il faudrait que toutes les variantes de Windows 10 soient équipées des mêmes capacités, exploitables à travers un ensemble unique et standardisé d’API, tout en coupant les risques liés à l’utilisation des API Win32 de bas niveau. C’est ce que doit réaliser Core OS.

Core OS vu sous l’angle du développement

Dans nos précédents articles, nous nous sommes intéressés à la manière dont Core OS allait probablement se présenter aux utilisateurs, les défis qu’il devait relever, ses caractéristiques et ambitions principales.

Le Surface Duo, prévu pour la fin d’année prochaine, devrait être le premier produit grand public à être équipé de Windows 10X, basé sur Core OS. Comment les développeurs doivent-ils aborder ce changement à venir ?

La réponse variera en fonction de l’appareil visé. Un système basé sur Core OS acceptera toujours les Windows Apps, mais pas forcément celles visant les anciennes API Win32. Pour ces dernières, et sur les appareils où ce choix sera pertinent, le sous-système Win32 sera virtualisé dans un conteneur. En clair, un système Core OS peut dans l’absolu faire fonctionner tous les logiciels actuels. Tous les « anciens » continueront à tourner, sans modification, via une couche dédiée, mais séparée du socle système, comme un simple module. À la manière, finalement, du sous-système Linux présent dans Windows 10.

Selon nos informations, Core OS offrirait des avantages très concrets. D’abord un sous-système Win32 pleinement fonctionnel et assurant une rétrocompatibilité en théorie totale avec le parc logiciel actuel. Ensuite, plus aucun risque que le système s’encrasse avec le temps. Puisque Core OS peut embarquer un sous-système Win32 virtualisé, chaque conteneur reçoit sa propre copie des éléments dont il a besoin, dont la base de registre et les bibliothèques essentielles comme Kernel32.dll, User32.dll, Shell32.dll et Advapi32.dll.

Tout aussi important, les logiciels Win32 bénéficieront du PLM (Product Lifecycle Management) et des permissions de Windows 10, c’est-à-dire tout ce qui touche à la gestion d’une application par le système. Exemple simple : les Windows Apps intégrées (comme Courrier, Photos, etc.) sont automatiquement gelées quand elles sont détectées comme inactives. Les notifications continuent d’arriver mais elles ne consomment plus de CPU et ne gardent qu’une empreinte mémoire minimale (quelques Mo).

Le sous-système Win32 s’appuie en effet sur Windows 10, en réorientant les appels. Microsoft prévoit donc de faire d’une pierre deux coups : couper les derniers liens trop forts avec la base du système et plier les anciennes applications aux règles de sécurité plus modernes. Exemple, les réglages centralisés liés à la géolocalisation, l’accès à la webcam, au micro et ainsi de suite.

Le système doit encore être peaufiné

Des avantages conséquents, sans aucun inconvénient ? Il y en a pour l’instant, mais ils sont a priori temporaires. Toujours selon nos informations, les performances seraient ainsi dégradées en fonction des cas, particulièrement quand le GPU est sollicité, car DirectX doit transférer le résultat via un canal RDP, entrainant une latence importante. Le but est cependant à terme d’obtenir des performances natives ou presque.

Les développeurs pourraient alors se pencher tranquillement sur une migration de leur code, d’abord en s’assurant si besoin de la compatibilité avec OneCore, puis progressivement vers WindowsApp.lib. Lorsque le Surface Duo sortira avec Windows 10X, il ne s’agira alors que d’un « simple » shell supplémentaire avec lequel il faudra vérifier les éventuels soucis ergonomiques, mais pas le code. Car les Windows Apps auront l’assurance de pouvoir fonctionner avec l’ensemble des appareils Core OS, tandis que le sous-système Win32 ne sera présent que là où il sera pertinent. Comprendre : sur les ordinateurs fixes et portables.

Sur la question du « desktop », justement, les avis semblent divisés. Certains estiment que la virtualisation des anciennes API Win32 serait « proche », d’autres que Core OS serait avant tout dévolu à de nouveaux produits pour l’instant et que Microsoft compterait laisser tranquille le Windows 10 classique pour l’instant.