S'identifier / Créer un compte
  • Actualités
  • Dossiers
  • Tests
  • Commentaires
  • INpactiens
Publicité

Flash Info : Fêtons la TVA à 2,1 % : abonnez-vous dès 17 € par an !

Windows 8 : Jupiter fera-t-il le grand ménage technologique ?

Il faut encore que les développeurs suivent

La présentation de Windows 8 il y a quelques semaines a laissé plus de questions qu’elle n’a donné de réponses. Il faut dire que Microsoft s’est concentré essentiellement sur une partie de la nouvelle interface, très inspirée de Metro, et clairement pensée pour les tablettes. Mais il reste de très nombreuses interrogations sur les fondations techniques du futur système et ce que les développeurs vont réellement utiliser pour leurs applications. Mary-Jo Foley de ZDnet propose un résumé qui rassemble des pistes obtenues par des développeurs.

win8 windows 8

Jupiter, le nouveau socle de développement

Les développeurs en question sont Michael Brown, Jose Fajardo et Jack Ukleja. Ils ont chacun suivi les versions alpha de Windows 8 qui se sont échappées de chez Microsoft en creusant dans le système à la recherche de références. Et des références, il y en a : Jupiter et DirectUI sont deux sujets qui gravitent l’un autour de l’autre et qui semblent concentrer le nouveau modèle de développement propre au prochain Windows.

Ce n’est pas la première fois que nous abordons Jupiter dans nos colonnes, mais les débats autour du développement HTML5/JavaScript ont éclipsé momentanément ce nom de code. Le temps passant, il apparaît de plus en plus que Jupiter est le nom de code d’un nouveau framework de développement contenant tout ce qui est nécessaire à la création d’une application « moderne » sur le nouveau système. Ce framework reposerait sur Redhawk dont nous avons déjà parlé et dont le vrai nom pourrait être tout simplement « Windows Runtime ».

Michael Brown estime que Jupiter deviendrait le nouvel hôte des applications .NET, mais avec certains bénéfices. Par exemple, votre application deviendrait capable d’utiliser du code natif en tant qu’assembly .NET. Mais Jupiter serait également l’occasion de faire un grand ménage dans les API Win32. Une partie serait alors intégrée dans Jupiter et réécrite pour l’occasion, tandis qu’une autre resterait à sa place actuelle pour des raisons de compatibilité, mais nous y reviendrons ensuite.

DirectUI, pour réunir Silverlight et WPF ?

D’après les développeurs, on trouve aux côtés de Jupiter une API nommée DirectUI, bien que le statut exact de ce composant soit encore flou. Comme son nom l’indique, il s’agit ici de tout ce qui touche à l’interface. Jupiter semble posséder une approche de type XAML pour la description des interfaces et DirectUI serait une API liée. Dans sa forme actuelle, les développeurs décrivent DirectUI comme un cousin de Silverlight et WPF (Windows Presentation Foundation) dont il reprend de très nombreux éléments. D’après eux, les développeurs familiers de l’une de ces deux technologies se retrouveraient immédiatement en terrain connu.

Mais DirectUI n’est pas un nom nouveau et existe dans Windows depuis longtemps. L’évolution serait bien présente, mais ce pourrait n’être qu’un composant réservé à Windows et qui n’intervient pas nécessairement dans le cadre des développements tiers.

La perspective du grand ménage

Il est difficile de définir ce qu’est exactement Jupiter, mais il semble que Microsoft tente d’en faire une terre promise. L’éditeur sait qu’il existe un no man’s land entre le code natif de l’univers Win32 et l’environnement .NET. Jupiter serait à la jonction et permettrait notamment de pouvoir faire exécuter une partie d’une application .NET en tant que code natif. Cela permettrait également de régler la question de l’intégration de l’API XNA dans l’ensemble.

L’aspect terre promise se retrouve également dans la « fusion » apparente de Silverlight et Windows Presentation Foundation pour ne garder qu’un tronc commun. Microsoft chercherait également à réduire les écarts séparant justement Silverlight, WPF, XNA et Direct3D pour que l’ensemble puisse être « mixé » facilement. Tout porte à croire que toutes les principales technologies se rassemblent en un lieu unique et que Microsoft en profite pour faire le ménage pour ne garder qu’un socle propre et commun. D’ailleurs, les fameuses applications immersives qui utilisent HTML5 et JavaScript pourraient finalement ne faire qu’appeler Jupiter, le HTML5 étant un autre langage de structuration des données, comme XAML.

RedHawk, ou Windows Runtime, est décrit comme le chainon manquant entre le code .NET et Jupiter. Il s’agit pour rappel d’une refactorisation de très nombreuses API, celles justement sur lesquelles Jupiter devrait venir s’appuyer. Brown parle ainsi des deux faces de la même pièce.

Si Microsoft devait finalement chercher à simplifier le socle technologique servant de référence aux développeurs, ce ne serait bien entendu pas par hasard. Il ne faut pas perdre de vue qu’une boutique d’application arrive avec Windows 8, et qu’un modèle concis et clair de développement devra être fourni. La conférence BUILD à la mi-septembre devrait être l’occasion pour l’éditeur de dire de quoi il retourne à ce sujet.

Hyper-V 3.0 et le potentiel de la virtualisation

Enfin, revenons sur le sujet de la compatibilité avec les anciennes API Win32. On ne connaît clairement pas leur rôle exact, en dehors du fait que tout le monde sait pertinemment qu’elles tomberont un jour dans l’oubli. Une partie d’entre elles semblent réécrites pour RedHawk, mais le destin de l’autre partie reste inconnu. Et si la virtualisation jouait ici un rôle prépondérant ?

On sait maintenant que l’hyperviseur Hyper-V sera présent en version 3.0 dans Windows 8. En dehors des améliorations telles que le support d’espaces disques allant jusqu’à 16 To ou la prise en charge de plus de quatre cœurs d’exécution, Hyper-V pourrait jouer un rôle « salvateur » en réglant la question du maintien de la compatibilité avec les plus anciennes des API Win32, tout en orientant les développeurs vers le nouveau socle : tous les appels vers la zone « héritage » (legacy) serait redirigés vers des API virtualisées.

En conclusion, Windows 8 pourrait être l’occasion attendue de longue date de faire un grand ménage dans les API et technologies gravitant autour de Windows. La réponse devrait intervenir dans moins de trois mois maintenant et pourrait réserver des surprises, aussi bien positives que négatives.
 

PS : remerciements à Charon pour l'ensemble de ses explications.
Vincent Hermann

Rédacteur/journaliste spécialisé dans le logiciel et en particulier les systèmes d'exploitation. Ne se déplace jamais sans son épée.

Publiée le 21/06/2011 à 16:53

Soutenez l'indépendance de Next INpact en devenant Premium

  • Tout le contenu de Next INpact sans pub
  • Et bien plus encore...

Il y a 206 commentaires

Avatar de jb INpactien
jb Le mardi 21 juin 2011 à 16:57:38
Inscrit le samedi 13 mai 06 - 3716 commentaires
:like:
Avatar de Vincent_H Equipe
Vincent_H Le mardi 21 juin 2011 à 16:59:38
Inscrit le jeudi 30 janvier 03 - 15419 commentaires


Je l'aurais parié
Avatar de djorgri INpactien
djorgri Le mardi 21 juin 2011 à 17:15:43
Inscrit le vendredi 14 mai 10 - 22 commentaires
Oula y a pas beaucoup de commentaires !
Trop technique ?
J'avoue, je n'ai pas tout compris, ce chaînon manquant servirait à unifier les technologies en place ? c 'est bien ça ?
Avatar de metaphore54 INpactien
metaphore54 Le mardi 21 juin 2011 à 17:17:14
Inscrit le mercredi 29 avril 09 - 6487 commentaires
Oula y a pas beaucoup de commentaires !
Trop technique ?
J'avoue, je n'ai pas tout compris
, ce chaînon manquant servirait à unifier les technologies en place ? c 'est bien ça ?


+1
Avatar de sepas INpactien
sepas Le mardi 21 juin 2011 à 17:18:26
Inscrit le jeudi 20 août 09 - 2165 commentaires
Oula y a pas beaucoup de commentaires !
Trop technique ?
J'avoue, je n'ai pas tout compris, ce chaînon manquant servirait à unifier les technologies en place ? c 'est bien ça ?


pffff t'es même pas un vrai geek alors

Il y a 206 commentaires

;