
De Windows à Midori : un abîme technique
Comme nous le disions récemment, Midori semble être un projet hérité de Singularity, un système d’exploitation écrit exclusivement en code managé, et faisant fi de toutes les bases posées jusqu’à présent : un système neuf, avec des bases neuves. Singularity n’a jamais pour autant eu vocation à être un produit commercial. Son code source et son SDK peuvent être téléchargés librement, et Microsoft le décrit depuis longtemps comme de la recherche pure.
Par contre, Midori serait d’un tout autre acabit. Il représenterait le futur des systèmes d’exploitation de Microsoft, tout en n’étant nativement pas compatible avec la plateforme Windows telle que nous la connaissons. Le lien avec Vista ? WinFX justement, et son environnement de développement en code managé. Ici, on se trouve devant plusieurs voies intéressantes.
Windows 7 continue le marquage amorcé par Vista
Premièrement, il semble que Microsoft soit en train de travailler sur une version native de tout ou partie de WinFX, en particulier sur tout ce qui concerne les services web. Comprendre : une version de l’environnement qui ne serait pas en code managé. Les motivations semblent assez floues à ce jour, mais on peut au moins avancer une théorie sur le terrain des performances : le code managé étant légèrement moins rapide que le code natif, l’éditeur pourrait vouloir viser un retour vers les performances maximales dans Windows 7. À l’heure actuelle, cette plateforme porterait le nom de code « Sapphire ».

L'environnement .NET, clé de voute du futur
Si l’on considère le système d’exploitation comme un oignon, l’environnement .NET est de haut niveau, tout comme Java : ce sont les dernières couches de l’oignon. Ils ont nécessairement besoin des couches inférieures pour être maintenus et pouvoir fonctionner. Au centre de Windows, on trouve le noyau (environ 3,4 Mo pour celui de Vista), autour duquel gravitent les pilotes (espace noyau) et quelques couches basses. Au-dessus, on trouve le fameux UMDF, qui permet le développement et le fonctionnement de pilotes qui n’ont pas besoin d’accéder au noyau (les périphériques USB par exemple). On trouve ensuite les sous-systèmes tels que Win32 et Posix, et enfin, l’environnement .NET.
Win32 contenant un ensemble d’API (Application Programming Interface) permettant d’appeler les pilotes, les applications .NET sont obligées d’y faire appel pour lancer par exemple un évènement sonore. Les appels de l’application .NET sont regroupés et encapsulés par la BCL (Base Class Library) qui joue le rôle de central d’appels. En clair : un logiciel .NET a besoin de jouer un son, il faut donc communiquer avec le pilote de la carte son. L’appel est transporté par la BCL jusqu’à l’API de gestion du son, qui se situe dans Win32, qui peut alors à son tour communiquer avec le pilote qui est dans l’espace UMDF. Une solution lourde, dont Microsoft veut se débarrasser.

La direction prise actuellement consiste à faire contourner complètement Win32 par l’environnement .NET. La BCL devient alors elle-même un sous-système qui peut communiquer directement avec UMDF et donc avec les pilotes. Pratiquement tous les projets de Microsoft concernant les systèmes d’exploitation pointent dans une seule direction : l’écartement et la mise au rebut du sous-système Win32. Ce qui est donc en conséquence étrange si l’on compare cet objectif aux rumeurs concernant Sapphire.
Ces informations, si elles commencent à s’assembler dans un ordre logique et à recouper divers projets de la firme, n’en restent pas moins à ce jour conditionnelles. Elles répondent toutes cependant à une volonté affichée depuis des années par Microsoft, qui n’a jamais caché son désir de faire de l’environnement .NET la base de ses développements dans le futur.