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

Windows Phone 8 : le début de l'unification des technologies chez Microsoft

Depuis le temps qu'on en parle

Microsoft possède sur son vaste campus de Redmond une unité spécifique baptisée Microsoft Research, ou MSR. De nombreuses technologies et des produits comme le Kinect viennent de projets qui ont été travaillés au MSR. Coté logiciel, des noms de code tels que Menlo et Redhawk ont déjà trouvé écho dans nos colonnes. Avec l’arrivée de Windows 8 et surtout de Windows Phone 8, les applications concrètes semblent être sur le point d’envahir l’écosystème maison.

wp8 apollo

Menlo, la base de Windows Phone 8

Menlo, tout d’abord, est la base de Windows Phone 8. Pour comprendre Menlo, il faut revenir à Vista et au travail commencé par Microsoft. Les développeurs avaient en effet débuté un travail de factorisation destiné à classer les composants de Windows. Avec la version 7 du système, ce travail a abouti sous la forme de MinWin, autrement dit la base minimale nécessaire pour fonctionner : le noyau, quelques pilotes et les fichiers nécessaires à l’exécution de logiciels. Aucune interface graphique n’était de la partie.

 

Menlo a un objectif connexe : celui d’être un système complet, mais minimal. Il est donc basé sur MinWin, mais fournit des éléments d’interface ainsi, entre autres, qu’un CLR (Common Language Runtime). Microsoft travaillait en effet sur WIndows Phone 7 depuis un moment à l’aide d’un noyau CE et du Compact Framework .NET. L’éditeur était cependant frustré du manque d’alignement et de compatibilité avec le noyau NT et le vrai CLR. Menlo est l'aboutissement d’un projet de remplacement de la base du système mobile. Un remplacement confirmé par Microsoft puisque l’on sait que Windows Phone 8 a la même base que celle de Windows 8, à peu de choses près.

 

Menlo est un pas important pour Microsoft, puisque son système mobile est désormais aligné avec celui pour les PC. Important à plus d’un titre en fait : comme il s’agissait de porter une base NT vers l’architecture ARM, les résultats ont bénéficié autant à WIndows Phone 8 qu’à Windows RT, la variante de Windows 8 pour les tablettes ARM. Dans la foulée, les développeurs ont porté leur compilateur JIT (Just-in Time) vers ARM pour le CLR, puis le CLR lui-même et enfin Silverlight.

La prévalence de .NET et de WinRT

Une fois que plusieurs plateformes partagent le même système d’exploitation, l’unification des technologies de développement n’est guère loin. Là encore, l’annonce de Windows Phone 8 a montré que les mêmes technologies (quasiment) seraient utilisées que dans Windows 8. Jusqu’au remplacement d’ailleurs de XNA pour les jeux vidéo par le code natif couplé à DirectX.

 

Les environnements .NET et WinRT ont ceci de commun que les applications conçues pour ces environnements peuvent théoriquement fonctionner partout de la même manière. Mais il se pourrait que la distribution des applications sur le Marketplace ou le Windows Store dispose d’améliorations tout droit sorties là encore du MSR.

Des technologies proches de la phase de production

Microsoft travaille en effet depuis des années sur plusieurs projets aux conséquences potentielles importantes. On pourrait par exemple citer Redhawk, dont la mission est de compiler un code MDIL (pour Machine Dependant Intermediate Language), lui-même issu d’un code managé. Le MDIL est beaucoup plus proche du langage machine et affiche de bien meilleures performances. Cela reste à confirmer, mais le MDIL a de très fortes chances d’être utilisé au sein de Windows Phone 8.

 

On pourrait également citer les travaux menés sur un même compilateur C++/C#, et donc destiné aussi bien au code natif qu’au code managé. Les objectifs sont très nombreux, mais on citera notamment l’exploitation des dernières possibilités offertes par les processeurs Intel, AMD et ARM, la création d’un nouveau type de fichier objet supportant le linking rapide (il s'agit en fait du MDIL) ou encore l’utilisation du parallélisme et de la vectorisation automatiques issues du compilateur créé pour Windows 8.

 

Plus récemment encore, des informations (obtenues grâce à la fuite du SDK de Windows Phone 8) laissent présager que Microsoft pourrait se livrer à des optimisations sur la compilation du code côté serveur. Ces opérations interviendraient après la publication du code par le développeur tiers, lors de la soumission de son application au Marketplace de Windows Phone 8.

 

Ces projets et informations restent en suspens tant que Microsoft ne les confirme pas. Cela étant, la plupart de ces données sont liées d’une manière ou d’un autre à Windows 8 et Windows Phone 8. Les prochains mois devraient être riches en informations, surtout si l’on considère que la conférence BUILD, dédiée aux développeurs, est prévue pour le 30 octobre.



PS : merci à Charon

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 28/07/2012 à 08:30

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 127 commentaires

Avatar de metaphore54 INpactien
metaphore54 Le dimanche 29 juillet 2012 à 15:53:11
Inscrit le mercredi 29 avril 09 - 6473 commentaires


Le souci c'est pas "ils doivent innover", le souci c'est que c'est que Microsoft utilise sa position dominante sur windows pour casser le business model de Valve qui fait d'eux un des leader de la vente dématerialisée PC, et se poser comme "outil installé par défaut dans windows".

Ils vont étouffer valve sans avoir besoin de faire un service meilleur. Juste le fait qu'ils soient installé par défaut sous Windows ... ils se sont déjà fait condamner pour ça ... je vois difficilement comment ils vont éviter de se faire condamner ...


Tant mieux si MS est condamné, pour ça le but, n'est pas d'empêcher les concurrents de vendre, mais je ne crois pas qu'être installé par défaut peut faire mourir les concurrents qui ont de l'avance dans un domaine. Si steam se sent lésé qu'il porte plainte pour obtenir satisfaction.

De toute façon steam mourra à terme, car on va vers le tout store chez les 3 gros, pour moi même si steam obtient satisfaction, ce ne sera que reculer pour mieux sauter.

De toute façon le problème ne se posera pas que pour MS, car les 3 y vont tête baissée.
Avatar de raoudoudou INpactien
raoudoudou Le dimanche 29 juillet 2012 à 15:56:49
Inscrit le jeudi 27 février 03 - 3529 commentaires


Si, c'est possible. OCaml est plus performant que C sur certains problèmes.
En plus, dire que du code C ne peux pas être plus rapide que du C ne tient pas debout, et ne tient pas non plus compte de ce que fait effectivement le code.


Nan mais là, les programmes sont censés faire la même chose. Alors si en ajoutant une traduction supplémentaire AVANT de compiler (pour C et Vala) du C ça en devient plus performant, y a comme un paradoxe.

Perso, si je traduis de l'allemand vers l'espagnol avant d'en faire du français, ça va pas être mieux que de le faire directement de l'allemand au français (exemple foireux, mais bon, c'est l'idée)

C'est pour ça que je dis que le bench est douteux. On n'a pas les lignes de commande utilisées pour chaque version du programme, ni même l'architecture d'exécution. Pour moi, on est typiquement dans le cas du mec qui a une idée en tête et qui fabrique (littéralement) un bench pour appuyer ses préjugés.
Avatar de HarmattanBlow INpactien
HarmattanBlow Le dimanche 29 juillet 2012 à 16:55:42
Inscrit le jeudi 21 juin 07 - 3981 commentaires
Mais bon tu es en train de globalement dire le contraire des développeurs midori sur les performances.. Je ne peux pas en dire plus de toute façon...

En même temps s'ils annoncent vraiment des applis deux fois plus rapides cela signifie que leurs applis passent aujourd'hui la moitié du temps dans les fonctions systèmes, ce qui serait peu commun (<- euphémisme sarcastique). Je n'ai donc aucun scrupule à débiner de telles annonces et mes propres affirmations sont, elles, argumentées, contrairement aux leurs. De toute façon Midori est fait pour accroître la sécurité et la parallélisation, pas pour accélérer les perfs par coeur.

Mais tu oublies le principal Windows utilise intensivement la mémoire partagée tandis que Midori la bannit.

Alors le coup du message-passing qui serait X fois plus rapide que le verrouillage, sans vouloir te vexer, je rigole. Plus simple et plus sécurisé, oui. Mais question performances les microkernels n'ont jamais été réputés pour leurs perfs et sont d'ailleurs régulièrement contraints de violer ce principe d'isolation de la mémoire pour justement obtenir des perfs décentes. Plus généralement le message-passing n'est pas fondamentalement plus lent que le verrouillage, simplement c'est souvent ce qu'on observe en pratique, ce qui n'est pas très grave puisque son intérêt est dans la robustesse et, parfois, la simplicité de conception. C'est un avantage pour le manycore mais un inconvénient pour les performances par coeur.

Du coup sur un pc manycore sous Windows avec l'augmentation des verrous, les performances finiraient par être complètement plombées. Ce qui ne serait pas le cas sur Midori.

A nouveau, c'est plutôt faux. Avant tu avais N threads qui, chacun leur tour, effectuaient la tâche X. Maintenant tu auras N threads qui enverront tous ensemble la tâche X à un unique thread "agent" qui les traitera l'une après l'autre.
Premier constat : si tes threads doivent attendre le résultat de la tâche X, rien n'a changé, il y a toujours contention.
Second constat : même si tes threads n'attendent pas le résultat, tu n'as un gain que si le nouvel agent s'exécute sur un coeur jusqu'à présent inutilisé, sans quoi tu as toujours contention. Autrement dit, dans ce cas-ci tu as simplement parallélisé davantage, ce qui n'a d'intérêt que si certains coeurs ne sont pas exploités mais qui, sinon, est contre-productif.
Troisième constat : contrairement au verrouillage qui a un coût fixe, le coût de l'envoi d'un message dépend de la taille des données envoyées. C'est rapidement pénalisant.

Il n'y aurait d'ailleurs même pas de gestion de threads au niveau du nouveau langage car l'os gèrerait le parallélisme lui même.

Désolé mais cette phrase ne veut rien dire. Les threads ne disparaîtront pas, ou alors pour être remplacés par des processus légers (mais je n'ai rien lu de tel), et l'OS ne va certainement pas paralléliser à la place du programmeur car ce dernier sait bien mieux le faire que n'importe quel algorithme.

Le code managé induit peut être quelques baisses de performances mais il permet d'avoir un os réellement mieux conçu qui au final pourra exploiter de bien meilleur façon le matériel et obtenir des performances supérieures à Windows.

Je n'ai jamais contesté ceci. Un noyau Singularity offrirait davantage de possibilités de parallélisation, avec à la clé des performances accrues si ton algorithme peut être massivement parallélisé, en dépit de performances par coeur vraisemblablement plus faibles. Ça ne conviendrait pas à toutes les applications, certaines pouvant s'en trouver pénalisé, mais ça irait indubitablement dans le bon sens.

J'insiste : je ne suis pas en train de critiquer l'idée de Singularity, qui est bonne, je démonte simplement les affirmations fallacieuses selon lesquelles demain le code managé sera demain aussi rapide que le code natif ou que les applis vont soudain voir leurs performances multipliées par deux à l'installation du nouveau système alors qu'au contraire elles seront plutôt réduites (en attendant la lente évolution qui suivra). Ces innovations sont bonnes mais elles n'en sont pas pour autant des miracles, sauf au département marketing bien sûr.

En matière de sécurité et de fiabilité c'est le jour et la nuit par rapport à Windows.

Là aussi, je suis entièrement d'accord. Même si, en tant que développeur, j'en ai ma claque des environnements sandboxés qui m'empêchent d'implémenter les fonctionnalités voulues par mes utilisateurs qui, ensuite, se tournent vers moi pour se plaindre.

Autre point que tu as l'air d'omettre, Windows reste un os très gros et très lourd. Midori est vraiment tout petit en comparaison.

Le noyau est plus petit. L'OS, c'est autre chose. Si l'OS est plus petit, c'est qu'il a moins de fonctionnalités, pas de miracle. A un détail près, que tu abordes ci-dessous.

C'est incomparable. Il ne traîne pas derrière lui plus de 2GO de code. Même si tu comparais à MinWin(Windows core) il resterait beaucoup plus petit. Rien que le fait de ne plus dépendre de tout un tas de code legacy ça change pas mal les choses. Les ressources mémoires utilisées sont de même bien plus faibles.

Voici un très bon argument. Incontestablement cela profitera aux performances globales. Le prix, en revanche, serait drastique : la table rase de l'intégralité de l'écosystème existant. Je doute que MS fasse cela pour un OS desktop ou mobile.
Avatar de HarmattanBlow INpactien
HarmattanBlow Le dimanche 29 juillet 2012 à 17:17:31
Inscrit le jeudi 21 juin 07 - 3981 commentaires
Parce qu'après tous ces posts fleuves j'y ai bien droit, voici deux trolls...

* Je fais toute confiance à MS pour conserver intact le business model de Steam et ne pas tenter de rafler ce marché. Le fait que le Windows store possède un monopole d'installation des applis métros n'est en aucun cas une abus de position dominante qui fera que le long terme de MS le seul magasin en ligne d'applications pour Windows. MS is not evil (pas comme Apple) : eux, ils travaillent pour le bien de l'humanité.

* J'applaudis l'unification menée par MS. J'espère d'ailleurs que Mr Bricolage annoncera bientôt la disparition des marteaux auxquels nous substituerons avantageusement des marteaux-clé-de-douze-buldozer-pelleteuse-marteau-piqueur-visseuse-scie-à-disque-tournevis-lime-à-ongle. Et j'espère qu'ils prendront en compte notre sécurité en restreignant l'usage de cet outils aux seuls matériaux vendus par Mr Bricolage, afin d'être surs que je ne planterai pas mon clou dans un contreplaqué contrefait plein de produits chimiques nocifs.

Je suis très heureux que MS veille ainsi à ma sécurité par pure charité, la com de 30% n'étant d'ailleurs là, j'en suis sûr, que pour couvrir leurs frais.

PS : Si j'étais Valve j'engaerais plutôt des avocats au lieu de développer un client Linux. Il faut savoir réaliser qu'on vient de se prendre une balle en pleine tête et que tout ce qu'il reste à faire c'est un procès pour pratiques anti-concurrentielles afin de récupérer un ou deux bouts de son crâne.

Edité par HarmattanBlow le dimanche 29 juillet 2012 à 17:21
Avatar de arno53 INpactien
arno53 Le dimanche 29 juillet 2012 à 17:20:22
Inscrit le lundi 21 juillet 08 - 1797 commentaires


Le souci c'est pas "ils doivent innover", le souci c'est que c'est que Microsoft utilise sa position dominante sur windows pour casser le business model de Valve qui fait d'eux un des leader de la vente dématerialisée PC, et se poser comme "outil installé par défaut dans windows".

Ils vont étouffer valve sans avoir besoin de faire un service meilleur. Juste le fait qu'ils soient installé par défaut sous Windows ... ils se sont déjà fait condamner pour ça ... je vois difficilement comment ils vont éviter de se faire condamner ...


Bah a la rigueur sur la partie WinRT Desktop Ms va peut etre faire comme pour Android c'est a dire un option dans les paramètre pour pouvoir installé un programme d'une source inconnu ... Ca pourrait leur éviter un procès tout en maintenant l'os sure pour la madame Michu qui n'ira pas voir cette option ... Et le petit Kevin (en esperant qu'il ne soit pas c*n ) n'installera que les jeux provenant de steam qui est quand même fiable ... Le c*n par contre installera les jeux issu du p2p ...

Mais y'a aussi la question : "est ce que les editeurs de jeu continueront a soutenir steam/origin ... avec l'avenement du store qui touchera via 1 executable win8, winRT et la xbox 8 ?"

Edité par arno53 le dimanche 29 juillet 2012 à 17:21
Avatar de arno53 INpactien
arno53 Le dimanche 29 juillet 2012 à 17:27:29
Inscrit le lundi 21 juillet 08 - 1797 commentaires



Le noyau est plus petit. L'OS, c'est autre chose. Si l'OS est plus petit, c'est qu'il a moins de fonctionnalités, pas de miracle. A un détail près, que tu abordes ci-dessous.

C'est incomparable. Il ne traîne pas derrière lui plus de 2GO de code. Même si tu comparais à MinWin(Windows core) il resterait beaucoup plus petit. Rien que le fait de ne plus dépendre de tout un tas de code legacy ça change pas mal les choses. Les ressources mémoires utilisées sont de même bien plus faibles.

Voici un très bon argument. Incontestablement cela profitera aux performances globales. Le prix, en revanche, serait drastique : la table rase de l'intégralité de l'écosystème existant. Je doute que MS fasse cela pour un OS desktop ou mobile.


Ms l'a bien fait entre Windows mobile et Windows Phone et est en train de le faire avec Windows RT sur ARM mais bon a mon avis il feront pendant peut etre 10 ans des OS de transition incluant Midori + Windows legacy ou bien la virtualisation ou le projet Drawbridge prendront le relais pour gérer le windows legacy
Avatar de raoudoudou INpactien
raoudoudou Le dimanche 29 juillet 2012 à 17:35:30
Inscrit le jeudi 27 février 03 - 3529 commentaires

Ms l'a bien fait entre Windows mobile et Windows Phone et est en train de le faire avec Windows RT sur ARM mais bon a mon avis il feront pendant peut etre 10 ans des OS de transition incluant Midori + Windows legacy ou bien la virtualisation ou le projet Drawbridge prendront le relais pour gérer le windows legacy


Je vois plus de la virtualisation, vu que ça fonctionne depuis longtemps, et très bien

Edité par raoudoudou le dimanche 29 juillet 2012 à 17:35
Avatar de charon.G INpactien
charon.G Le dimanche 29 juillet 2012 à 17:38:45
Inscrit le vendredi 29 avril 05 - 7344 commentaires
Flemme de tout répondre je precise juste sur ce point car tu n'as pas saisi ce que je racontais:
Désolé mais cette phrase ne veut rien dire. Les threads ne disparaîtront pas, ou alors pour être remplacés par des processus légers (mais je n'ai rien lu de tel), et l'OS ne va certainement pas paralléliser à la place du programmeur car ce dernier sait bien mieux le faire que n'importe quel algorithme.

Il y aura toujours des threads(les SIP) mais ca disparait au niveau du langage. Ce n'est plus le développeur de l'applications qui exploite le parallelisme mais c'est géré totalement par l'OS. Je te garantis que c'est vrai. Que tu n'y crois pas c'est autre chose. Après bien sur, ça ne résume pas à un problème de mémoire partagée mais comme je te l'ai dis on ne sait pas 10% du truc....

Pour le reste je retranscris ce que je sais ce sont pas des annonces commerciales puisque que ce n'est même pas censé se savoir...
Avatar de charon.G INpactien
charon.G Le dimanche 29 juillet 2012 à 17:41:27
Inscrit le vendredi 29 avril 05 - 7344 commentaires
Voici un très bon argument. Incontestablement cela profitera aux performances globales. Le prix, en revanche, serait drastique : la table rase de l'intégralité de l'écosystème existant. Je doute que MS fasse cela pour un OS desktop ou mobile.

Microsoft peut le faire sur Windows RT vu qu'il n'autorise pas le Win32. Pour le desktop l'ancien code restera présent longtemps comme le dos sur les Windows actuels(mais le dos n'est pas inclu dans le coeur de Windows la ce sera pareil).
Avatar de charon.G INpactien
charon.G Le dimanche 29 juillet 2012 à 17:47:09
Inscrit le vendredi 29 avril 05 - 7344 commentaires

Microsoft peut le faire sur Windows RT vu qu'il n'autorise pas le Win32. Pour le desktop l'ancien code restera présent longtemps comme le dos sur les Windows actuels(mais le dos n'est pas inclu dans le coeur de Windows la ce sera pareil).

De plus tu oublies que Midori vise un domaine bien plus large que le pc et la tablette. Il était considéré par Shapiro comme une sorte d'os embarqué. Ce qu'on voit sous Windows 8 n'est qu'un prélude, Microsoft espère le mettre sur n'importe quoi en particulier la domotique les voitures etc. Il n'y a pas besoin de Win32 pour ça. Le fait que Midori puisse marcher sur n'importe quelle architecture sans recompilation des applications c'est un point important.
;