Le GM de la division Windows Embedded a fait un tas d’annonces à l’ESC Boston:

  • Windows Server 2008 R2 intègre le lineup Windows Embedded Server: c’est la ligne de produits Servers “classique” de chez Microsoft avec bien entendu une licence (et donc des conditions d’acquisition) spécifique à l’embedded
  • Windows 7 Pro & Ultimate for Embedded Systems intègrent le lineup Windows Embedded Enterprise: c’est la ligne de produits “desktop” classique de chez Microsoft, avec bien entendu une licence (et donc des conditions d’acquisition) spécifique à l’embedded
  • Le programme pour hobbyistes “Spark Your Imagination” devient “EmbeddedSpark” et on annonce un concours avec à la clef plus de $20000 de lots: l’Embedded Spark Challenge 2010. On en reparlera plus tard.
  • et la RTM de Windows Embedded CE 6.0 R3, qui inclut Silverlight for Windows Embedded.

 

Si on regarde de plus prêt cette nouvelle release de Windows Embedded CE 6.0 on voit qu’il y a en fait un paquet de nouvelles choses: notamment, des Office Viewers, pour les documents office, un nouveau navigateur qu’il est plus beau et qu’il marche mieux, mais aussi et surtout, un truc qui s’appelle Silverlight for Windows Embedded:

Pour être précis, c’est le moteur de rendu de Silverlight avec des spécificités très “embedded”: on l’a sorti de la sandbox du browser, et on ne va pas utiliser les technologies .NET, mais du code natif pour développer le code “fonctionnel”. C’est assez gros comme différence, pour être souligné. On garde en revanche tout ce qui est développement avec Expression Blend, XAML, etc. Sauf que.. on a plus l’overhead induit par le code managé, et les limites de la sandbox. Bien ou pas bien? à vous de me dire. Moi j’achète le concept à 200%. Pourquoi? Parce que pour les développeurs embedded, c’est tous les avantages de Silverlight sans les inconvénients:

  • Dans l’embedded, chaque MIPS compte. Le code managé, même si c’est très bien pour plein de raisons (productivité, unification de la plateforme de développement, etc…) mais quand on veut être battery-efficient, ça marche moins bien que le code natif. Moins de layers = moins de cycles CPU et d’accès mémoire donc des applications plus réactives et moins consommatrices de batterie.
  • La vaste majorité des développeurs embedded sont encore des développeurs C++. Donc finalement, ils vont retrouver les outils qu’ils connaissent.
  • On développe avec un outil de designer, des interfaces riches: passer au natif n’altère pas la possibilité de faire des choses visuellement impressionnantes, je vous renvoie vers ce post sur le blog de Mike Hall pour en avoir la preuve en images.

je posterai plus de concret dans un futur assez proche puisque j’animerai une session sur le sujet au TechEd à Berlin