L’évolution de Windows Phone 7 est « connue » puisque l’on connaît les deux prochaines versions du système mobile, à savoir Tango et Apollo. Tango a toujours été considérée comme une version mineure tandis qu’Apollo est censé être Windows Phone 8. Pourtant, Tango pourrait finalement être plus important qu’il n’y paraît, de fortes rumeurs lui prêtant une prise en charge du code natif.
Selon plusieurs sources, un évènement récent en Inde consacré aux développeurs aurait été le théâtre de plusieurs révélations et confirmations. Ainsi, Tango devrait bien porter le nombre de langues supportées par Windows Phone à 120, contre 35 actuellement. Elle devrait également définir une liste de spécifications plus basses pour la production de smartphones à destination des pays où le budget est beaucoup plus serré. Bien que non abordée ici, une autre rumeur veut que Tango reconnaisse officiellement le form factor de type BlackBerry, à savoir un téléphone équipé d’un clavier physique et donc d’un écran de taille plus réduite.
Mais une information publiée par WP Sauce indiquait que le code natif pourrait faire sa grande entrée prochainement dans le développement pour Windows Phone. Il s’agirait d’une modification importante de la ligne de conduite face aux applications tierces. Tout développement Windows Phone doit en effet sur baser sur Silverlight et les langage C#, Visual Basic et F#. De fait, ces applications ne sont pas natives.
WP Sauce indiquait que le code natif passerait par le langage C++, mais il n’était pas possible de dire si cette prévision visait Tango ou Apollo, Microsoft ayant simplement parlé de « prochaine version » (Next release). Une information publiée via un tweet par le développeur Karthik Ragubathy qui était sur place. Un tweet qui a depuis étrangement disparu.
Cette question du code natif n’est pas importante dans la grande majorité des cas. Cependant, elle peut se poser quand le besoin de performances est beaucoup plus fort. Ce peut être le cas dans les jeux, bien que ces derniers utilisent l’environnement XNA. Le code natif pourrait en outre débloquer la situation sur des applications multimédias plus intenses, comme des lecteurs tirant parti de toutes les ressources matérielles disponibles.
Mais le point intéressant de cette information est peut-être que l’actualité initiale de WP Sauce a été retirée à la demande de Microsoft. Automatiquement, cela apporte du crédit aux informations fournies, sans pour autant prouver quoi que ce soit. Mais après tout, de très nombreux bruits de couloir ont circulé sur Tango et Apollo, notamment pour cette dernière le rapprochement avec Windows 8, sans que Microsoft n’intervienne.
Notez toutefois que le mois prochain se tiendra comme chaque année à Barcelone le Mobile World Congress. S’agissant d’un évènement particulièrement important pour la téléphonie en général, Microsoft pourrait en profiter pour faire quelques annonces importantes. Si la prise en charge du code natif devait être annoncée, la firme publierait à terme un équivalent pour son système du NDK (Native Development Kit) d’Android.
Selon plusieurs sources, un évènement récent en Inde consacré aux développeurs aurait été le théâtre de plusieurs révélations et confirmations. Ainsi, Tango devrait bien porter le nombre de langues supportées par Windows Phone à 120, contre 35 actuellement. Elle devrait également définir une liste de spécifications plus basses pour la production de smartphones à destination des pays où le budget est beaucoup plus serré. Bien que non abordée ici, une autre rumeur veut que Tango reconnaisse officiellement le form factor de type BlackBerry, à savoir un téléphone équipé d’un clavier physique et donc d’un écran de taille plus réduite.
Mais une information publiée par WP Sauce indiquait que le code natif pourrait faire sa grande entrée prochainement dans le développement pour Windows Phone. Il s’agirait d’une modification importante de la ligne de conduite face aux applications tierces. Tout développement Windows Phone doit en effet sur baser sur Silverlight et les langage C#, Visual Basic et F#. De fait, ces applications ne sont pas natives.
WP Sauce indiquait que le code natif passerait par le langage C++, mais il n’était pas possible de dire si cette prévision visait Tango ou Apollo, Microsoft ayant simplement parlé de « prochaine version » (Next release). Une information publiée via un tweet par le développeur Karthik Ragubathy qui était sur place. Un tweet qui a depuis étrangement disparu.
Cette question du code natif n’est pas importante dans la grande majorité des cas. Cependant, elle peut se poser quand le besoin de performances est beaucoup plus fort. Ce peut être le cas dans les jeux, bien que ces derniers utilisent l’environnement XNA. Le code natif pourrait en outre débloquer la situation sur des applications multimédias plus intenses, comme des lecteurs tirant parti de toutes les ressources matérielles disponibles.
Mais le point intéressant de cette information est peut-être que l’actualité initiale de WP Sauce a été retirée à la demande de Microsoft. Automatiquement, cela apporte du crédit aux informations fournies, sans pour autant prouver quoi que ce soit. Mais après tout, de très nombreux bruits de couloir ont circulé sur Tango et Apollo, notamment pour cette dernière le rapprochement avec Windows 8, sans que Microsoft n’intervienne.
Notez toutefois que le mois prochain se tiendra comme chaque année à Barcelone le Mobile World Congress. S’agissant d’un évènement particulièrement important pour la téléphonie en général, Microsoft pourrait en profiter pour faire quelques annonces importantes. Si la prise en charge du code natif devait être annoncée, la firme publierait à terme un équivalent pour son système du NDK (Native Development Kit) d’Android.
Source :
LiveSide
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.
Le 30 janvier 2012 à 09:35
(13 038
lectures)
Il y a 36 commentaires
et question environnements de dév, sait on si microsoft fera preuve d'ouverture ?
parce que pouvoir choisir un langage c'est agréable, mais ça l'est d'autant plus si on peut le faire avec son éditeur préféré.
J'espère en tout cas que les émulateurs fournis seront plus performants que les émulateurs android ^__^
parce que pouvoir choisir un langage c'est agréable, mais ça l'est d'autant plus si on peut le faire avec son éditeur préféré.
J'espère en tout cas que les émulateurs fournis seront plus performants que les émulateurs android ^__^
:'( j'arrive pas à user du bouton "erreur dans la news" ....
So, H.S. :
Dans le 2nd paragraphe :
Tout développement Windows Phone doit en effet sur baser Silverlight et le langage C#.
=> [en effet se baser sur Silverlkight] non ?
<3 PcINpact !
Edité par MrGeekArt le lundi 30 janvier 2012 à 10:02
So, H.S. :
Dans le 2nd paragraphe :
Tout développement Windows Phone doit en effet sur baser Silverlight et le langage C#.
=> [en effet se baser sur Silverlkight] non ?
<3 PcINpact !
Edité par MrGeekArt le lundi 30 janvier 2012 à 10:02
J'espère que cette annonce pourra s'allier d'une ouverture. L'idéal serait a minima l'ouverture pour l'environnement Qt de Nokia compte tenu de leur partenariat respectif. Ce qui permettrait de continuer la dynamique de ce dernier (Symbian > Meego > WP7 )
Petite precision tout de même (un peu inutile mais bon, ca va mieux en le disant): Techniquement, Winphone supporte tous les langages .NET, donc pas uniquement C# ;)
A part ca, l'arrivée du code natif signifierait surtout qu'on pourrait executer du code en full trust (puisque c'est bien de ca qu'il s'agit) Actuellement les applications Windows Phone s'executent avec un niveau de confiance bas, ce qui limite drastiquement ce qu'on a le droit de faire (Security Transparent) Et seul MS peut faire des assemblies Security critical.
Avant de proposer des API natives, il faudrait déjà qu'on puisse executer nous nos applications en Security Critical. Ce qui permet de faire du code unsafe en .NET par exemple (ie des choses qui ressemblent vraiment au natif, avec des perfs similaires, et des dangers equivalents. )
A part ca, l'arrivée du code natif signifierait surtout qu'on pourrait executer du code en full trust (puisque c'est bien de ca qu'il s'agit) Actuellement les applications Windows Phone s'executent avec un niveau de confiance bas, ce qui limite drastiquement ce qu'on a le droit de faire (Security Transparent) Et seul MS peut faire des assemblies Security critical.
Avant de proposer des API natives, il faudrait déjà qu'on puisse executer nous nos applications en Security Critical. Ce qui permet de faire du code unsafe en .NET par exemple (ie des choses qui ressemblent vraiment au natif, avec des perfs similaires, et des dangers equivalents. )
J'espère que cette annonce pourra s'allier d'une ouverture. L'idéal serait a minima l'ouverture pour l'environnement Qt de Nokia compte tenu de leur partenariat respectif. Ce qui permettrait de continuer la dynamique de ce dernier (Symbian > Meego > WP7 )
A mon avis, Qt permettra de développer sur Windows Phone 8 et pas avant. Ce n'est qu'une supposition, mais ça me semble la voie la plus logique vis à vis du planning de Microsoft pour la série des "8".
J'espère que cela ne fera pas comme apollo 13.
127.0.0.1
Le lundi 30 janvier 2012 à 10:19:56
#7
Inscrit
le mercredi 29 avril 09
-
12270
commentaires
A part ca, l'arrivée du code natif signifierait surtout qu'on pourrait executer du code en full trust (puisque c'est bien de ca qu'il s'agit)
J'espère bien que non. S'il faut sacrifier la sécurité (i.e. l'isolation) au profit de la performance, je préfère que Ms optimise son compilo JIT.
Microsoft a évoqué plusieurs fois l'unification de la plateforme sur Windows 8 et phone8(apollo).
Il est très probable que WinRT soit disponible sur apollo. WinRT permet le développement d'applications en C++ sandboxé.
Il est très probable que WinRT soit disponible sur apollo. WinRT permet le développement d'applications en C++ sandboxé.
Petite precision tout de même (un peu inutile mais bon, ca va mieux en le disant): Techniquement, Winphone supporte tous les langages .NET, donc pas uniquement C# ;)
A part ca, l'arrivée du code natif signifierait surtout qu'on pourrait executer du code en full trust (puisque c'est bien de ca qu'il s'agit) Actuellement les applications Windows Phone s'executent avec un niveau de confiance bas, ce qui limite drastiquement ce qu'on a le droit de faire (Security Transparent) Et seul MS peut faire des assemblies Security critical.
Avant de proposer des API natives, il faudrait déjà qu'on puisse executer nous nos applications en Security Critical. Ce qui permet de faire du code unsafe en .NET par exemple (ie des choses qui ressemblent vraiment au natif, avec des perfs similaires, et des dangers equivalents. )
A part ca, l'arrivée du code natif signifierait surtout qu'on pourrait executer du code en full trust (puisque c'est bien de ca qu'il s'agit) Actuellement les applications Windows Phone s'executent avec un niveau de confiance bas, ce qui limite drastiquement ce qu'on a le droit de faire (Security Transparent) Et seul MS peut faire des assemblies Security critical.
Avant de proposer des API natives, il faudrait déjà qu'on puisse executer nous nos applications en Security Critical. Ce qui permet de faire du code unsafe en .NET par exemple (ie des choses qui ressemblent vraiment au natif, avec des perfs similaires, et des dangers equivalents. )
Le natif n'est pas égal à win32 et au full trust. En effet je ne crois pas trop à une ouverture des api win32 natives internes.
Par Contre WinRT permet le développement d'applications en c++ sandboxé. Les api de WinRT ne sont pas natives mais type safe.
Il me semble qu'ils aient pu demander de retirer l'annonce pour éviter les faux espoirs également (des gens qui commencent à coder en vue de publier dès que c'est disponible par exemple).
Sinon j'espère qu'ils n'autoriseront jamais le full trust sur WP, histoire de ne pas risquer de nombreux virus trop "puissants"...
Par contre autoriser au coup par coup certains éditeurs à publier leur logiciel pourquoi pas (tomtom, etc...)
Sinon j'espère qu'ils n'autoriseront jamais le full trust sur WP, histoire de ne pas risquer de nombreux virus trop "puissants"...
Par contre autoriser au coup par coup certains éditeurs à publier leur logiciel pourquoi pas (tomtom, etc...)
Il n'est plus possible de commenter cette actualité
Vous devez être connecté ou vous inscrire en haut pour pouvoir participer aux commentaires.














