Windows 8 : au cœur de l'OS controversé de Microsoft

Un modèle COM revisité

Il est nécessaire avant de continuer d’expliquer le concept d’ABI, à ne pas confondre avec les API qui sont un ensemble de routines dans une bibliothèque (DLL). L’ABI (Application Binary Interface) est une sorte de standard pour que les programmes et le système d’exploitation puissent communiquer ensemble. Elle intègre les types de base comme les entiers, les entiers longs, les chaines, etc. mais aussi la façon dont sont passés les arguments d’une fonction, de même pour les appels systèmes.

winrt winrt

Microsoft a introduit en 1993 la technologie COM (Component Object Model), dérivée d’OLE (Object Linking and Embedding), dans Windows. Le but était créer un standard d’interface binaire pour les composants logiciels. Les objets ainsi créés pouvaient être utilisés par plusieurs langages ainsi que par plusieurs processus ou mêmes machines. La technologie COM utilisait le langage IDL qui décrit toutes les interfaces des objets avec leurs différentes méthodes.  Cet IDL était compilé en .TBL, des métadonnées utilisées par COM pour accéder aux différents objets. Ces métadonnées décrivaient complètement l’ABI des objets COM.

Puis, en 2002, Microsoft lance la première version du Framework .NET. Contrairement au Java, il pouvait cibler plusieurs langages via les métadonnées CLI (Common Language Infrastructure). Ces dernières décrivent intégralement le code et certains mécanismes, comme la réflexion, les utilisent. Microsoft a longtemps misé sur .NET mais il y a un problème : aucune programmation native n’est possible. Un développeur C++ ne peut ainsi pas utiliser les API  .NET mises à disposition.

C’est ici que la situation sous Windows 8, avec l’arrivée du Windows Runtime, ou plus simplement WinRT. Ce Runtime est en réalité un modèle COM revisité : un framework natif qui crée en interne des objets COM+ et qui n’utilise plus le TBL mais les mêmes métadonnées CLI que dans .NET.

winrt

L’ensemble des API de Windows Runtime repose dans le dossier C:\Windows\System32\WinMetadata qui contient, comme son nom l’indique, toutes les métadonnées.

winrt winrt

WinRT est accessible depuis de nombreux langages, y compris le C++ et le JavaScript.

Quand une application WinRT veut créer un objet, elle utilise le mécanisme de projection. Ainsi, une application C++ va créer un objet COM en interne puis, à partir des métadonnées, un wrapper pour pouvoir communiquer avec cet objet. La projection se fait de la même manière qu’avec un programme en .NET ou un programme en JavaScript. Les API WinRT sont elle-même de type safe et les objets WinRT sont libérés automatiquement quand ils ne sont plus utilisés. Aucun pointeur n’est donc communiqué pour interagir avec le système, rendant plus complexes plusieurs types d’exploitations de failles de sécurité, notamment l’escalade de privilèges.

winrt

Il faudra également prendre en compte certaines spécificités. Par exemple, pour le C++, il est nécessaire d’utiliser un langage d’extension pour accéder aux API WinRT : le C++/CX. Pour un développement multiplateforme, il faut cependant préciser que le code peut rester en C++ classique. Le C++/CX n’est utilisé que pour l’accès aux API WinRT qui sont de toute façon spécifiques.

En JavaScript, WinRT utilise le moteur Chakra d’Internet Explorer (9 et 10), le navigateur permettant depuis longtemps la création d’objets COM. Le système de projection en JavaScript avec Windows Runtime est donc naturel. Il est par ailleurs extensible et devrait ainsi autoriser des langages supplémentaires dans l’avenir. De plus, un développeur peut très facilement mélanger les langages dans son application WinRT grâce aux métadonnées qui rendent compatible un objet avec l’ensemble (une sorte de P/Invoke plus moderne). On peut par exemple très bien créer une application avec un moteur écrit en C++ ou C# et utiliser une interface web en JS/HTML5.

Il est intéressant de noter que dans un programme natif classique, n’importe quelle routine de n’importe quel DLL du système peut être utilisée. D’après Microsoft, cela représenterait plus de 100 000 API potentielles environ. Dans WinRT, l’API LoadLibrary classique pour charger une DLL n’est cependant pas disponible. Les seuls API utilisables sont celles du dossier de l’application ou celles exposées dans les métadonnées WinRT. On peut imaginer facilement que l’évolution du framework devrait être facilitée afin de garantir la compatibilité. Le code est en outre totalement découplé de l’interface.

winrt

Microsoft assure en effet une compatibilité totale des applications WinRT dans les futurs Windows.

Si des méthodes ne sont pas modifiables, de nouvelles seront ajoutées. En cas de nouvelle technologie, de nouvelles classes seront ajoutées. La situation est différente du .NET qui, en évoluant, utilise le mécanisme de côte-à-côte (side-by-side) en conservant toutes les versions majeures du framework sur le disque dur. Ce n’est pas le cas de WinRT : il existera une seule version pour tous les Windows. 

winrt

Une application WinRT peut stocker les données de différentes manières. À chaque application est associé un dossier dans le compte utilisateur. On trouvera ainsi des dossiers temporaires, des dossiers locaux et un dossier roaming. Les données de ce dernier seront synchronisées entre différentes machines par le cloud.

Enfin, WinRT donne accès à un jeu d’API de haut niveau pour stocker les paramètres. L’implémentation interne actuelle utilise la base de registre, mais il n’existe pas d’API WinRT donnant accès à la totalité de la base, contrairement aux applications Desktop (Win32). La base de registre stocke les données dans des fichiers .dat nommés « ruches ». Dans WinRT cependant, les préférences de chaque application ont leur propre ruche, stockée dans le dossier interne de l’application. WinRT Microsoft règle ainsi la principale critique faite la base de registre.

Sécurité et WinRot

Toutes les applications Modern UI sont sandboxées : elles fonctionnent dans des espaces mémoire isolés et dans un App Container qui ne possède que des droits restreints. Par comparaison, on trouvait dans Vista un niveau d’intégrité bas utilisé dans le mode protégé d’Internet Explorer 7 (puis dans les versions 8 et 9). Ce mode interdisait l’écriture dans d’autres dossiers mais autorisait la lecture. Le mode App Container est beaucoup plus restrictif puisqu’il interdit toutes les opérations de lecture et écriture hors du dossier de l’application. Les mécanismes IPC sont aussi bloqués et il est même interdit par défaut de faire des échanges réseau en local entre deux applications WinRT ou vers une application Win32. Il est probable que Microsoft ne souhaite pas d’applications hybrides Win32/WinRT, ce qui expliquerait cette interdiction.

Contrairement aux autres systèmes d’installation des applications sur les anciens Windows, l’opération se fait ici uniquement depuis le Windows Store. L’installation comme la désinstallation se font en un ou deux clics et s’exécutent très rapidement.

winrt

Ces applications sont en faites paquets APPX contenant les différents fichiers nécessaires. Un manifeste XML est également présent pour décrire toutes les dépendances ainsi que les capacités, qui sont les droits d’accès de l’application. On trouve ainsi l’accès aux dossiers musiques, photo, vidéo, documents, la webcam, la localisation, le niveau d’accès sur le réseau. À la désinstallation, tous les fichiers utilisateurs sont supprimés. Le dossier lui-même est supprimé quand plus aucun utilisateur ne s’en sert.

Le fonctionnement particulier des applications WinRT a en outre été conçu pour se débarrasser au passage d’un souci de longue date. Windows est en effet frappé depuis longtemps par un phénomène qu’on appelle le WinRot, littéralement « pourrissement de Windows ». Au fur et à mesure du temps, la machine de l’utilisateur ralentit à cause des installations et désinstallations des applications qui laissent différents fichiers sur le système. Ce qui finit par obliger l’utilisateur à réinstaller Windows en dernier recours. Si le phénomène a ralenti avec Vista qui a imposé les comptes utilisateurs à tout le monde, le problème s’est déplacé vers les comptes eux-mêmes et n’était donc pas totalement réglé.

L’environnement WinRT interdisant aux applications  d’écrire en dehors de leur dossier, il garantit le nettoyage complet lors de la désinstallation. De plus, une telle application ne peut pas utiliser de DLL partagées ou modifier le système. Grâce à la sandbox, la propagation des virus devrait devenir théoriquement impossible. Dans le cas de malwares qui auraient réussi à passer la validation du Windows Store, une simple désinstallation de l’application WinRT devrait suffire à supprimer toutes traces.

La situation est très différente des applications classiques Win32 : elles peuvent écrire n’importe où. Les désinstalleurs tels que MSI se contentent donc de supprimer les fichiers listés dans un log. Mais une application crée dynamiquement des fichiers à l’exécution et ils ne sont la plupart du temps pas effacés. De plus les préférences des applications étant aussi stockées par application, les ruches principales de la base de registre ne grossissent plus inutilement. Il suffit désormais de supprimer la ruche de l’application Modern UI pour supprimer toutes traces.

Il est fort probable que le phénomène WinRot disparaisse complètement sur la version RT de Windows 8, puisque seules des applications WinRT peuvent être installées. Pour la version standard de Windows 8, l’environnement Bureau est toujours présent et le problème devrait perdurer en partie. 

par Vincent Hermann et Jérôme Bosch Publiée le 27/11/2012 à 14:36