Windows Threshold, un système unique pour tous les appareils

Windows Threshold, un système unique pour tous les appareils

Vous attendiez la confirmation ? La voici

Avatar de l'auteur
Vincent Hermann

Publié dans

Logiciel

23/07/2014 4 minutes
65

Windows Threshold, un système unique pour tous les appareils

Depuis plusieurs mois, les rumeurs s’accumulent autour de Windows Threshold, nom de code de la prochaine vague du système d’exploitation. Alors que la firme unifie peu à peu ses technologies, on pouvait se demander si le futur produit irait un cran plus loin, en jouant le rôle de socle commun pour tous les supports. La réponse a été donné par le PDG Satya Nadella : ce sera bien le cas.

windows 8

Des signes qui pointaient tous dans la même direction 

Le faisceau des derniers mouvements de Microsoft dans le secteur du développement logiciel ne laissait plus guère de doutes. La firme a commencé par réunir les comptes développeurs pour Windows et Windows Phone, peu de temps avant d’officialiser les applications universelles pour les deux systèmes, dans leurs versions 8.1 respectives. Récemment, l’éditeur a également rassemblé ses ressources de développement au sein d’un même site.

 

Hier, nous nous attardions sur une offre d’emploi indiquant très clairement que Microsoft travaillait sur un framework graphique unique pour l’ensemble des plateformes : ordinateurs, tablettes, smartphones et Xbox. En clair, une infrastructure pour uniformiser les interfaces avec le même socle technologique, quel que soit l’appareil utilisé. Nous évoquions alors les rumeurs concernant Windows Threshold, selon lesquelles la version destinée aux ordinateurs embarquerait un nouveau bureau, sans doute largement remanié et modernisé.

Nadella confirme le système unique pour tous les écrans 

Dans sa présentation des nouveaux résultats trimestriels, Satya Nadella, le PDG de Microsoft, a cependant officialisé un point important : la firme va « rationaliser la prochaine version de Windows en passant de trois systèmes d’exploitation à un unique système ». Doit-on comprendre alors qu’il n’existera plus qu’un seul Windows pour tous les appareils ? Nadella répond là encore : « Cela signifie un système d’exploitation pour tous les tailles d’écran ».

 

Cela veut-il vraiment dire que nous aurons le même Windows partout ? Pas tout à fait. Comme l’indique Nadella, cela signifie surtout que Microsoft disposera d’une « seule équipe avec une architecture commune ». C’est donc bien le socle technologique qui sera le même partout, ce qui est une direction prise par Microsoft depuis l’arrivée de Vista et les premiers grands travaux sur la base du système. Des travaux qui avaient accouché quelques années plus tard de MinWin dans Windows 7, c’est-à-dire le plus petit dénominateur commun capable de fonctionner seul, sans interface, sans DLL, sans rien d’autre que le noyau et les composants essentiels.

Un rêve de développeur ? 

Comment cela va-t-il se traduire concrètement ? Une base technique ne veut pas dire une même interface. Même si les technologies sont identiques, même si le framework graphique est unique, l’ergonomie sera forcément différente selon l’appareil. Cependant, les éléments de contrôle risquent de fortement se ressembler. Mais surtout, une telle unification signifie des applications communes à tous les appareils.

 

Ce dernier point est capital, d’autant que Nadella a confirmé que les boutiques d’applications allaient elles aussi être rassemblées. Les développeurs pourront donc créer des applications qui pourront s’exécuter partout, l’appareil déterminant quelle interface doit être exploitée. En somme, des applications universelles qui pourront également fonctionner sur la Xbox, et probablement sur le bureau. Microsoft compte donc réaliser sa vision : vous utilisez des applications et des services, le matériel n’a plus guère d’importance et vous proposera toujours d’y accéder, sous une forme adaptée. Les données sont ainsi mises en avant, chaque ordinateur, tablette ou smartphone n’étant plus qu’une interface de consultation.

 

Si la théorie est agréable, la mise en pratique restera cruciale. Car Microsoft peut disposer de technologies avancées, performantes, fiables et ainsi de suite, rien ne peut remplacer la prise en main et l’ergonomie de l’ensemble. C’est la dure leçon imposée par Windows 8 qui, pour la première fois, n’était plus critiqué pour sa stabilité ou sa rapidité, mais pour son interface.

65

Écrit par Vincent Hermann

Tiens, en parlant de ça :

Sommaire de l'article

Introduction

Des signes qui pointaient tous dans la même direction 

Nadella confirme le système unique pour tous les écrans 

Un rêve de développeur ? 

Commentaires (65)


Uniformisation des paradigmes chez Micrososft pourquoi pas ?

Si toutes fois les spécificités des plateformes sont respectées <img data-src=" />



Déjà sortez un Windows 9 et stable <img data-src=" />








sniperdc a écrit :



Déjà sortez un Windows 9 et stable <img data-src=" />





Ça c’est acquis de toute façon depuis Windows vista <img data-src=" />



Faut aller encore un cran plus loin (mais ils le feront pas). Tu achètes ton jeu / logiciel sur une plateforme et tu l’as sur toutes.


C’est bien ça va être pratique pour développer des virus.

Et pour corriger les failles aussi du coup.








XMalek a écrit :



Faut aller encore un cran plus loin (mais ils le feront pas). Tu achètes ton jeu / logiciel sur une plateforme et tu l’as sur toutes.





C’est déjà fait avec Windows Phone 8.1 et Windows 8.1 <img data-src=" />

Et il a justement annoncé que ce serait une des choses qu’ils feront pour threshold <img data-src=" />









Khalev a écrit :



C’est bien ça va être pratique pour développer des virus.

Et pour corriger les failles aussi du coup.





bien vu …

d’ailleurs ça existe des virus sur console ?









DDReaper a écrit :



Ça c’est acquis de toute façon depuis Windows vista <img data-src=" />







Rien n’est acquis en informatique, même si win 7 et 8 sont stables, ça veut pas dire que les suivants le seront. <img data-src=" />



Ce qui était acquis c’est que MS allait de plus en plus unifier ses techno. Depuis l’interface de la xbox, en passant par WP, WinRT et le store MS, c’était quand même bien entamé.









DDReaper a écrit :



C’est déjà fait avec Windows Phone 8.1 et Windows 8.1 <img data-src=" />

Et il a justement annoncé que ce serait une des choses qu’ils feront pour threshold <img data-src=" />







je vois pas la xboite dedans <img data-src=" />









XMalek a écrit :



je vois pas la xboite dedans <img data-src=" />







non mais réfléchis, justement avec Threshold ils veulent inclure la xbox one dans les universal apps.

Du coup pour le moment on est à 2 plateforme sur 3 et ils veulent inclure la 3ème donc je trouve ca un peu fort de café de sortir un “ils ne le feront pas” <img data-src=" />









XMalek a écrit :



Faut aller encore un cran plus loin (mais ils le feront pas). Tu achètes ton jeu / logiciel sur une plateforme et tu l’as sur toutes.







Pas seulement, on veut ca aussi pour Office, bien sur avec le même compte MS hein, faudrait pas abuser du système (je parles pas d’O365), mais ce serait top d’avoir ces applications qui fonctionne partout :)









DDReaper a écrit :



non mais réfléchis, justement avec Threshold ils veulent inclure la xbox one dans les universal apps.

Du coup pour le moment on est à 2 plateforme sur 3 et ils veulent inclure la 3ème donc je trouve ca un peu fort de café de sortir un “ils ne le feront pas” <img data-src=" />







Je vais modérer mes propos : ça fait 5 ans que j’entend parler de ce projet (universalisation des apps) et que je ne vois toujours pas d’avancées réelles. Oui les sdks se sont grandement améliorés mais le partage des apps au vu de la politique des éditeurs actuels (faire repayer la plateforme une somme significative) me parait assez “fantaisiste”.







colonelc4 a écrit :



Pas seulement, on veut ca aussi pour Office, bien sur avec le même compte MS hein, faudrait pas abuser du système (je parles pas d’O365), mais ce serait top d’avoir ces applications qui fonctionne partout :)







Pour moi office en fait parti c’est un logiciel comme les autres.









DDReaper a écrit :



non mais réfléchis, justement avec Threshold ils veulent inclure la xbox one dans les universal apps.

Du coup pour le moment on est à 2 plateforme sur 3 et ils veulent inclure la 3ème donc je trouve ca un peu fort de café de sortir un “ils ne le feront pas” <img data-src=" />







Si la xboite1 arrive à faire tourner Office, et les applications du Store, ca va faire du mal aux HTPC…surtout s’ils décident d’ouvrir le robinet pour des applications type XBMC, VLC…etc.



Question: Est-ce que vous pensez que les équipements matériels (Xbox, smartphones, tablettes…) pourront être mis à jour logiciellement pour bénéficier de Threshold ou pensez-vous qu’il y aura encore un gap technologique l’empêchant (du style windows phone 7 / windows phone 8)?








monpci a écrit :



bien vu …

d’ailleurs ça existe des virus sur console ?







Je n’ai jamais vu de cas pour ma part. Ca doit être un peu comme pour le mobile à une époque : ça doit exister mais ça doit être rarissime.



Intéressantes les idées de Shuttleworth Nadella








XMalek a écrit :



Je vais modérer mes propos : ça fait 5 ans que j’entend parler de ce projet (universalisation des apps) et que je ne vois toujours pas d’avancées réelles. Oui les sdks se sont grandement améliorés mais le partage des apps au vu de la politique des éditeurs actuels (faire repayer la plateforme une somme significative) me parait assez “fantaisiste”.







Pour moi office en fait parti c’est un logiciel comme les autres.





Pourtant j’ai pu télécharger tweetium sur mon téléphone et NextGen reader sur ma tablette gratuitement parce que j’avais déjà payer leur alter ego sur tablette et téléphone respectivement donc ça va arriver :)



Si j’était Microsoft je sortirai aussi un Appstore alternatif sur Android avec la aussi les universal apps.









Alpha Centauri a écrit :



Question: Est-ce que vous pensez que les équipements matériels (Xbox, smartphones, tablettes…) pourront être mis à jour logiciellement pour bénéficier de Threshold ou pensez-vous qu’il y aura encore un gap technologique l’empêchant (du style windows phone 7 / windows phone 8)?





Le souhait de Microsoft c’est que le plus de monde possible passe à Threshold le plus rapidement possible, ca m’étonnerai très très fortement qu’il y est ce genre de restrictions. On entend plutôt parler de mise à jour gratuite pour les personnes sous windows 8.1 Update et les gens sous Windows 7 SP1 pour te dire.



ça voudrait dire qu’un code initialement prévu pour de l’x86 / x64 fonctionnera de la même manière sur un environnement ARM comme nos smartphones ? C’est possible de faire un truc aussi cool ? <img data-src=" />








DDReaper a écrit :



Ça c’est acquis de toute façon depuis Windows vista <img data-src=" />







Loul vista sans le sp1 etait pas vraiment stable, pas vraiment du tout…



Je le dis juste depuis la sortie de win 8. Quelle grosse merde d’avoir unifier l’interface pour des utilisation différentes…



‘fin bon on va ptet avoir un truc intelligent a la fin <img data-src=" />










Alpha Centauri a écrit :



Question: Est-ce que vous pensez que les équipements matériels (Xbox, smartphones, tablettes…) pourront être mis à jour logiciellement pour bénéficier de Threshold ou pensez-vous qu’il y aura encore un gap technologique l’empêchant (du style windows phone 7 / windows phone 8)?





Attends, je sors ma boule de cristal.









0zmaster0 a écrit :



ça voudrait dire qu’un code initialement prévu pour de l’x86 / x64 fonctionnera de la même manière sur un environnement ARM comme nos smartphones ? C’est possible de faire un truc aussi cool ? <img data-src=" />







malheureusement et je pense que c’est le problème il y a peu de chance que cela arrive.



Ca sera probablement une compil spéciale faite par visual studio qui sort des version x86 x64 et ARM



comme c’est le cas il me semble pour les applications universelles



Faudra migrer.



Ce qui fait peur c’est l’hégémonie grandissante de Visual studio pour les développements et même au delà de Windows.









0zmaster0 a écrit :



ça voudrait dire qu’un code initialement prévu pour de l’x86 / x64 fonctionnera de la même manière sur un environnement ARM comme nos smartphones ? C’est possible de faire un truc aussi cool ? <img data-src=" />





oui car “.net”

pour faire simple c’est un peu comme java du moment qu’il y a la machine virtuelle …

Apres si tu met de l’assembleur dedans : code non managé (je crois qu’il appellent ça comme ça) ben forcement ça marche plus









monpci a écrit :



oui car “.net”

pour faire simple c’est un peu comme java du moment qu’il y a la machine virtuelle …







Ouais mais ton code doit etre en .net pour que cela fonctionne. (Youhouuu y a pas que visual studio dans la vie)

et quand bien même si ca compile y a AUCUNE chance que ca marche sans rien faire…

edith :A moins que ton programme marche sans interface sans chemin et sans droits









DDReaper a écrit :



C’est déjà fait avec Windows Phone 8.1 et Windows 8.1 <img data-src=" />

Et il a justement annoncé que ce serait une des choses qu’ils feront pour threshold <img data-src=" />







C’est une “possibilité” offerte pour les développeurs, qui ne sont pas obligés de s’y conformer. S’ils souhaitent faire payer une licence différente par support, ils le peuvent.





Un rêve de développeur ?



Je pense que la plupart des développeurs à qui on a soumis ce paradigme dans le passé en ont d’amers souvenirs.

Quand on doit utiliser les mêmes sources pour diverses cibles hétérogènes, ça finit toujours en code spaghetti. Sans compter la taille des bibliothèques qu’il faut traîner pour faire tourner le tout et les tiers qu’il faut pour accéder aux bases de données par exemple (DB2/400 et SQLServer <img data-src=" />)

Je ne sais pas trop comment les outils de dév pour Threshold vont faire pour optimiser le code final suivant la plateforme visée ; je suis curieux de voir ça.








0zmaster0 a écrit :



ça voudrait dire qu’un code initialement prévu pour de l’x86 / x64 fonctionnera de la même manière sur un environnement ARM comme nos smartphones ? C’est possible de faire un truc aussi cool ? <img data-src=" />





Ca a rien de nouveau, .net le fait depuis longtemps, car comme java le code est executé sur une VM (CLR) il y a donc aucune manipulation à faire du coté du codeur…



Je pense que ce qu’ils vont unifié c’est tout le framework autour, notament le langage pour l’ui (degager Silverlight au profit du WPF, et bosser sur des composants responsive)…









Vincent_H a écrit :



C’est une “possibilité” offerte pour les développeurs, qui ne sont pas obligés de s’y conformer. S’ils souhaitent faire payer une licence différente par support, ils le peuvent.





C’est vrai mais ils ont l’air de s’y conformer pour le moment, en espérant que cela continue <img data-src=" />









XMalek a écrit :



Je vais modérer mes propos : ça fait 5 ans que j’entend parler de ce projet (universalisation des apps) et que je ne vois toujours pas d’avancées réelles. Oui les sdks se sont grandement améliorés mais le partage des apps au vu de la politique des éditeurs actuels (faire repayer la plateforme une somme significative) me parait assez “fantaisiste”.





Et pourtant, il y a certaines app qui en profitent déjà, même si ce n’est possible que depuis quelques semaines.

Dernier exemple en date par exemple, le client Tweetium, si tu as acheté la version Windows 8.1, tu as aussi la version WP 8.1 en même temps.









DDReaper a écrit :



C’est déjà fait avec Windows Phone 8.1 et Windows 8.1 <img data-src=" />

Et il a justement annoncé que ce serait une des choses qu’ils feront pour threshold <img data-src=" />





Malheureusement, ce n’est pas le cas pour toutes les applis… <img data-src=" />









0zmaster0 a écrit :



ça voudrait dire qu’un code initialement prévu pour de l’x86 / x64 fonctionnera de la même manière sur un environnement ARM comme nos smartphones ? C’est possible de faire un truc aussi cool ? <img data-src=" />





C’est déjà possible depuis longtemps d’adapter à la volée un code pour d’autres plateformes. Les moteurs 3d le font déjà depuis longtemps.

La principale difficulté est l’optimisation car que ça tourne sur les 2 archis, c’est pas très dur, que ça tourne bien, c’est plus difficile.











0zmaster0 a écrit :



ça voudrait dire qu’un code initialement prévu pour de l’x86 / x64 fonctionnera de la même manière sur un environnement ARM comme nos smartphones ? C’est possible de faire un truc aussi cool ? <img data-src=" />





Hum, si on parle du code… dans les grandes lignes, oui. En pratique, c’est comme pour Java, ça dépendra de ta qualité d’écriture pour être multiplate-forme.



Mais bon, en théorie, C et C++ tant que tu reste dans la norme ISO, c’est déjà en théorie indépendant de la plateforme. Cependant il y a plus de soucis de chemin et de droit d’accès…. et ça fini avec des tonnes de codes spécifiques aux plateforme. Qt vient par exemple avec pas mal d’outils qui simplifie grandement ces problèmes de plateformes.









DDReaper a écrit :



non mais réfléchis, justement avec Threshold ils veulent inclure la xbox one dans les universal apps.

Du coup pour le moment on est à 2 plateforme sur 3 et ils veulent inclure la 3ème donc je trouve ca un peu fort de café de sortir un “ils ne le feront pas” <img data-src=" />







Ils n’ont précisés que xbox donc on peut penser que même la Xbox 360 pourrait être dedans, je ne sais pas si le Xbox store 360 et One sont unis mais cela pourrait être pas mal.



C’est clairement la bonne approche : base technique commune pour simplifier la maintenance de l’OS et le développement pour les développeurs tiers, et interface spécifique pour chaque type d’appareil.



Du coup, il sera possible de développer une application unique avec une interface qui s’adapte en fonction de l’environnement dans lequel elle se trouve ? Ce serait pratique pour les appareils hybrides : j’ai mon application en version tactile sur ma tablette, je la mets sur un dock connectée à un écran plus grand et un clavier/souris, et l’environnement s’adapte aux nouveaux périphériques, l’application reste ouverte et modifie son interface.



En tout cas, ce usecase est un des objectifs de KDE. Avec Plasma 5, ils ont déjà l’environnement qui s’adapte automatiquement, et ils exposent une API pour informer les applications du mode le plus adapté. Et QtQuick pousse au découplage total entre l’interface et la logique, et le langage QML facilite la création d’interfaces qui s’adaptent.



Ce serait intéressant de voir si Microsoft vise la même chose, où s’ils veulent simplement pouvoir réutiliser des bouts de code tout en gardant des applications séparées.


Il parle ici de 3 systèmes qui convergent vers un unique mais moi j’en compte 4:

Windows Phone

Windows RT

L’OS de la One (du moins celui des 3 OS de la one gérant les applis)

Windows X86 X64.



A mois que je ne me fourvoie dans mes propos.


Windows Phone et RT vont fusionner, il ne le compte peut-être déjà que pour un.


Clairement il parle de “windows on arm”, windows pour x86 et windows sur xbox one.








Khalev a écrit :



C’est bien ça va être pratique pour développer des virus.

Et pour corriger les failles aussi du coup.





Ca c’est possible depuis un moment, le .Net et le C++ tournent sur toutes les plateformes, pas besoin d’interface graphique pour les virus.

L’unification concerne la partie graphique, le reste est assez bien géré à mon

avis.









Khalev a écrit :



C’est bien ça va être pratique pour développer des virus.

Et pour corriger les failles aussi du coup.





Non parce que l’unification ne concerne évidemment pas les applications Win32(présent uniquement sur le sku PC). Et les applications WinRT sont sandboxées.









Khalev a écrit :



C’est bien ça va être pratique pour développer des virus.

Et pour corriger les failles aussi du coup.





Les consoles / mobiles devices continueront leur fonctionnement via un sotre/market. Donc à part quelques app pas cool, les virus sont assez difficiles à faire entrer.



Ce qui je l’espère ne changera rien pour le PC, qui aura le store et les autres sources, comme actuellement.



Au final, l’idée c’est que tu développes un application style client mail (p. ex.), et ce dernier pourra s’installer sur ta One, sur ton Windows Phone, sur ton PC et sur ta Surface, tout ça en utilisation ton compte Live/Outlook.



Edit : Grilled par la technique de Charon.G <img data-src=" />









monpci a écrit :



bien vu …

d’ailleurs ça existe des virus sur console ?





Oui, mais ça s’appelle un “code sans signature valide” ou encore “jailbreak”… <img data-src=" />







caesar a écrit :



Ouais mais ton code doit etre en .net pour que cela fonctionne. (Youhouuu y a pas que visual studio dans la vie)





Visual Studio n’a rien d’indispensable pour cracher du .Net, c’est un outil (performant) mis à disposition mais il suffit juste qu’un compilateur balance du .NET au lieu du x86, après tout Mono et d’autres existent bien.







caesar a écrit :



et quand bien même si ca compile y a AUCUNE chance que ca marche sans rien faire…

edith :A moins que ton programme marche sans interface sans chemin et sans droits





Actuellement. C’est justement le but à atteindre : Arriver à inventer une API d’interface capable de s’adapter toute seule au format de l’écran. C’est un défi balèze, mais je rappelle que les sites Web existe, que le bandeau Office (s’adaptant à la place disponible) existe, et que même les interfaces Java ont tenté le coup il me semble. C’est pas encore suffisant mais ça montre un peu la voie à suivre.









DDReaper a écrit :



Le souhait de Microsoft c’est que le plus de monde possible passe à Threshold le plus rapidement possible, ca m’étonnerai très très fortement qu’il y est ce genre de restrictions. On entend plutôt parler de mise à jour gratuite pour les personnes sous windows 8.1 Update et les gens sous Windows 7 SP1 pour te dire.







Merci pour l’info, par contre ça veut dire que Microsoft a à peine commencé sa réorganisation. Wait & see :)



Trop impatient d’ouvrir mes feuilles Excel sur ma smartwatch. <img data-src=" />


C’est comme tout, ce n’est pas parce que tu peux que tu dois, c’est à ce moment qu’intervient le bon sens normalement.








127.0.0.1 a écrit :



Trop impatient d’ouvrir mes feuilles Excel sur ma smartwatch. <img data-src=" />





Il faudra une loupe je pense et pour modifier les formules/macros tu feras comment ?









darth21 a écrit :



C’est comme tout, ce n’est pas parce que tu peux que tu dois, c’est à ce moment qu’intervient le bon sens normalement.





J’ai des doutes quant à son bon sens.

Déjà rien que sur un smartphone c’est pénible (et pas que pour Excel, d’autres solutions existent).

C’est juste pour faire un commentaire négatif concernant Microsoft.









Khalev a écrit :



C’est bien ça va être pratique pour développer des virus.







WinRT et les applis universelles ne permettent pas de faire des virus, d’adware/toolbars, ni de malwares en général.



les applications sont obligatoirement sandboxées sur le systèmes type Windows RT, Windows Phone, et Xbox.



même s’il n’y avait pas de Windows Store et que le sideloading était autorisé comme sur Android, les applis tournent au sein de conteneurs limités et ne présentent pas de risque de sécurité.



c’est d’ailleurs pour cette raison qu’à partir de Windows 9, win32 (les applis desktop) ne seront plus supportées sur les versions de Windows destinées aux machines low cost, aussi bien sur ARM que x86, car les applis win32 ne peuvent pas être sandboxées par l’OS sans casser la compatibilité.









jinge a écrit :



Ca c’est possible depuis un moment, le .Net et le C++ tournent sur toutes les plateformes, pas besoin d’interface graphique pour les virus.

L’unification concerne la partie graphique, le reste est assez bien géré à mon

avis.







l’unification ne concerne pas que les APIs graphiques, elle concerne le runtime tout entier.



en gros c’est WinRT pour tout le monde, avec sandbox obligatoire. Contrairement à des applis .net Framework (qui tournent sur le desktop sans restriction), les applis WinRT ne pourront pas faire d’actions qui pourraient nuire à la sécurité de la machine ou des données utilisateur.





Nadella a confirmé que les boutiques d’applications allaient elles aussi être rassemblées. Les développeurs pourront donc créer des applications qui pourront s’exécuter partout,





Partout… même sur un ARM <img data-src=" />



Et la phrase est intéressante en tout cas, on y vient, ça parle de “boutique d’application” ce qui ne choque personne sur mobiles/tablettes (merci Apple), mais est radicalement nouveau sur PC W\( (sur Linux on a les "repo" depuis bien longtemps, c'est d'ailleurs la base technique de l'AppStore inventé par Apple).



Du reste c'est bien l'annonce de cela : "boutique d'application" sur PC aussi qui a mis en fureur Gabe Newell, et ne manquera pas d'inquiéter de même les fabricants de logiciels PC : désormais M\)
va leur taxer 30% sur PC aussi !..



Bon courage à l’idée de génie. <img data-src=" />








jmanici a écrit :



les applis win32 ne peuvent pas être sandboxées par l’OS sans casser la compatibilité.





Y’a peut etre moyen avec Drawbridge de mettre tout les programmes Win32 dans une même sandbox afin de garantir la sécurité du reste de l’OS (noyau, applis WinRT…). Ca sera sans doute le meilleur compromis entre compatibilité et sécurité.









Alpha Centauri a écrit :



Question: Est-ce que vous pensez que les équipements matériels (Xbox, smartphones, tablettes…) pourront être mis à jour logiciellement pour bénéficier de Threshold ou pensez-vous qu’il y aura encore un gap technologique l’empêchant (du style windows phone 7 / windows phone 8)?







le passage de Windows Phone 7 vers WP8 était difficile du fait du chargement de noyau. Passage de WindowsCE vers WindowsNT, donc nécessité de réécrire des drivers pour les SoC snapdragon 1ere génération, et nécessité de réécrire toutes les applis natives fournies par les OEM, et faire recertifier le tout par les opérateurs.

vu les faibles ventes de devices wp7, MS aurait eu du mal à forcer les OEMs et les opérateurs à faire ce boulot couteux qui ne leur aurait rien rapporté.



avec Threshold, on reste sur du noyau NT, donc rien n’a besoin d’être réécrit, et la certification par les opérateurs devrait rester simple.



compte tenu de la politique de support de MS, on peut penser que MS voudra supporter un maximum de devices aussi longtemps possible. Techniquement rien n’en empêchera MS, contrairement à Android, MS est capable de publier des MAJ système sans l’intervention des OEMs.









arno53 a écrit :



Y’a peut etre moyen avec Drawbridge de mettre tout les programmes Win32 dans une même sandbox afin de garantir la sécurité du reste de l’OS (noyau, applis WinRT…). Ca sera sans doute le meilleur compromis entre compatibilité et sécurité.









théoriquement oui, mais je reste sceptique quant à la compatibilité.



en tout cas à la build 2011 j’avais demandé si les applis win32 allaient être sandboxées dans une future version de Windows, et le gars m’avait répondu que les applis WinRT représentaient l’avenir de Windows, et que le but était d’éliminer les applis win32, pas de les sandboxer.



du coup je me demande si drawbridge n’est pas juste conçu pour les applis WinRT, et non win32. A terme quand il faudra faire tourner toutes les applis winRT créées avec des versions différentes du runtime et du sdk WinRT, une technologie type drawbridge pourrait rentrer en jeu pour éviter tout cassage de compatibilité.



mais faire tourner du win32 sur des environnements sandboxés? Ca semble trop beau (et trop compliqué) pour être vrai.









Bylon a écrit :



Partout… même sur un ARM <img data-src=" />



Et la phrase est intéressante en tout cas, on y vient, ça parle de “boutique d’application” ce qui ne choque personne sur mobiles/tablettes (merci Apple), mais est radicalement nouveau sur PC W\( (sur Linux on a les "repo" depuis bien longtemps, c'est d'ailleurs la base technique de l'AppStore inventé par Apple).



Du reste c'est bien l'annonce de cela : "boutique d'application" sur PC aussi qui a mis en fureur Gabe Newell, et ne manquera pas d'inquiéter de même les fabricants de logiciels PC : désormais M\)
va leur taxer 30% sur PC aussi !..



Bon courage à l’idée de génie. <img data-src=" />







Mais c’est déjà le cas mon chère depuis Windows 8 !

Il est possible de proposer une application x86 sur le Store. C’est juste que ce n’est pas courant.

Et surtout en faite ca te renvois sur le site du soft. Reste à voir si il y aura une vrai mise en place d’installation etc.









Bylon a écrit :



Partout… même sur un ARM <img data-src=" />



Et la phrase est intéressante en tout cas, on y vient, ça parle de “boutique d’application” ce qui ne choque personne sur mobiles/tablettes (merci Apple), mais est radicalement nouveau sur PC W\( (sur Linux on a les "repo" depuis bien longtemps, c'est d'ailleurs la base technique de l'AppStore inventé par Apple).



Du reste c'est bien l'annonce de cela : "boutique d'application" sur PC aussi qui a mis en fureur Gabe Newell, et ne manquera pas d'inquiéter de même les fabricants de logiciels PC : désormais M\)
va leur taxer 30% sur PC aussi !..



Bon courage à l’idée de génie. <img data-src=" />







la boutique d’application ne concerne pas les applis win32.



elles ne peuvent pas être sandboxées, donc les héberger au sein d’un store représente trop de risque, et puis il serait impossible d’interdire le sideloading.



au final ça n’aurait aucun intérêt, puisque sur le long terme les applis win32 sont appelées à disparaître de toutes façons. (elles vont évidemment survivre 1 ou 2 décennies sur les versions entreprise et serveur de Windows)



concernant Gave Newell, sa réaction est pleine de mauvaise foi, puisque Valve lui même fait déjà la même chose. Quant on achète un jeu sur dvd, on se retrouve obligé d’installer steam et se connecter sur internet. Il est donc mal placé pour critiquer le principe du Windows Store. Mais très bien placé pour déplorer la concurrence directe…



quant à la part de MS sur les revenus du store, au delà d’un certain montant c’est seulement 20%. Et même 0% si l’éditeur préfère passer par sa propre plateforme de paiement, chose que Apple interdit mais pas MS :)









k43l a écrit :



Mais c’est déjà le cas mon chère depuis Windows 8 !

Il est possible de proposer une application x86 sur le Store. C’est juste que ce n’est pas courant.

Et surtout en faite ca te renvois sur le site du soft. Reste à voir si il y aura une vrai mise en place d’installation etc.





Eh non … Toutes les application WinRT de Windows 8 sont x86 vu que Windows 8 n’est que sur x86 <img data-src=" /> et que c’est la version faisant tourner les apps WinRT la plus vendu (l’autre étant Windows RT qui n’est supporté que par Microsoft).



VLC RT, les applis de banques, de magazine, skype, les pdf reader, les jeux etc … Tout ca est disponible sur x86.



VLC n’est même disponible que sur x86 pour l’instant mais ca ne devrait pas trop tarder pour la version ARM.



Les pages du Store renvoyant vers le site de dev ne concerne que les apps Win32.










jmanici a écrit :



théoriquement oui, mais je reste sceptique quant à la compatibilité.



en tout cas à la build 2011 j’avais demandé si les applis win32 allaient être sandboxées dans une future version de Windows, et le gars m’avait répondu que les applis WinRT représentaient l’avenir de Windows, et que le but était d’éliminer les applis win32, pas de les sandboxer.



du coup je me demande si drawbridge n’est pas juste conçu pour les applis WinRT, et non win32. A terme quand il faudra faire tourner toutes les applis winRT créées avec des versions différentes du runtime et du sdk WinRT, une technologie type drawbridge pourrait rentrer en jeu pour éviter tout cassage de compatibilité.



mais faire tourner du win32 sur des environnements sandboxés? Ca semble trop beau (et trop compliqué) pour être vrai.





Tu n’es pas le seul a penser que WinRT est intimement lié a Drawbrige

Mais ils ont également réussi a faire tourner IIS, Excel et IE et leur travail tourne principalement autour de Win32, Windows 7, Silverlight & co



Pour en avoir un peu parler avec Charon, ca peut vraiment débloquer la situation de Microsoft en entreprise en leur assurant que leur vieille applis seront toujours compatible avec le dernier OS de MS et puis si Midori sort dans les 5 ans qui viennent ils leur faudra bien une solution pour les applis Win32 a moins qu’ils maintiennent 2 OS complétement différent l’un pour le grand public, l’autre pour les pro mais j’y crois pas trop …



Edit : Apres ca sera surement une feature des version pro et entreprise uniquement histoire de forcer les devs a passer à WinRT …









arno53 a écrit :



Tu n’es pas le seul a penser que WinRT est intimement lié a Drawbrige

Mais ils ont également réussi a faire tourner IIS, Excel et IE et leur travail tourne principalement autour de Win32, Windows 7, Silverlight & co



Pour en avoir un peu parler avec Charon, ca peut vraiment débloquer la situation de Microsoft en entreprise en leur assurant que leur vieille applis seront toujours compatible avec le dernier OS de MS et puis si Midori sort dans les 5 ans qui viennent ils leur faudra bien une solution pour les applis Win32 a moins qu’ils maintiennent 2 OS complétement différent l’un pour le grand public, l’autre pour les pro mais j’y crois pas trop …



Edit : Apres ca sera surement une feature des version pro et entreprise uniquement histoire de forcer les devs a passer à WinRT …







je ne doute pas que MS parvienne à supporter ses propres applis win32 sur drawbridge, vu que même actuellement, IE10/Metro est déjà sandboxé dans un appcontainer.



mais pour des applis tierces (surtout les applis métier créées sur mesure spécifiquement pour 1 entreprise), ça me semble impossible qu’ un système type drawbridge puisse supporter 99% de ces applications sans modification, vu que quasiment aucune de ces applis n’a été conçue pour tourner dans un environnement isolé. Chaque appli suffisamment complexe est susceptible de reposer sur plusieurs processus provenant d’une ou plusieur compagnies (ex: ton appli peut utiliser un composant oracle ou sql server, ou tout autre composant nécessitant des communication interprocess). Si drawbridge isole chacun d’entre eux plus rien ne marche. C’est juste un exemple pour dire que sandboxer correctement des applis non conçues pour est très complexe.



et même si au final on se retrouve seulement avec 10% de cassage de compatibilité, on se retrouverait face à un nouveau vista, et les pros prefereront rester sur la plateforme précédente moins secure, mais qui fonctionne sans broncher.









jmanici a écrit :



je ne doute pas que MS parvienne à supporter ses propres applis win32 sur drawbridge, vu que même actuellement, IE10/Metro est déjà sandboxé dans un appcontainer.



mais pour des applis tierces (surtout les applis métier créées sur mesure spécifiquement pour 1 entreprise), ça me semble impossible qu’ un système type drawbridge puisse supporter 99% de ces applications sans modification, vu que quasiment aucune de ces applis n’a été conçue pour tourner dans un environnement isolé. Chaque appli suffisamment complexe est susceptible de reposer sur plusieurs processus provenant d’une ou plusieur compagnies (ex: ton appli peut utiliser un composant oracle ou sql server, ou tout autre composant nécessitant des communication interprocess). Si drawbridge isole chacun d’entre eux plus rien ne marche. C’est juste un exemple pour dire que sandboxer correctement des applis non conçues pour est très complexe.



et même si au final on se retrouve seulement avec 10% de cassage de compatibilité, on se retrouverait face à un nouveau vista, et les pros prefereront rester sur la plateforme précédente moins secure, mais qui fonctionne sans broncher.





il ne feront peut être qu’une seule sandbox pour tout l’environnement win32, ce qui permettrait à plusieurs applis win32 de communiquer ensemble sans trop de problèmes… Enfin ce n’est que de la spéculation mais c’est soit drawbridge soit encore supporter Windows une 15aine d’année :-/









Rozgann a écrit :



En tout cas, ce usecase est un des objectifs de KDE. Avec Plasma 5, ils ont déjà l’environnement qui s’adapte automatiquement, et ils exposent une API pour informer les applications du mode le plus adapté. Et QtQuick pousse au découplage total entre l’interface et la logique, et le langage QML facilite la création d’interfaces qui s’adaptent.



Ce serait intéressant de voir si Microsoft vise la même chose, où s’ils veulent simplement pouvoir réutiliser des bouts de code tout en gardant des applications séparées.





+1, l’exemple des KDE avec les KDElibs et l’utilisation des possibilités de Qt5 m’est aussi venu directement à l’esprit, et c’est aussi selon mi la bonne approche.



Parce que pour l’instant on parle de 3 supports au max (PC, smart/tablette, console). Mais dans le futur on risque d’avoir plus de supports que ca (textile numérique peut-être, papier numérique, toutes les futures interfaces de contrôle qu’on va dev pour l’internet des objets, etc..)….









jmanici a écrit :



théoriquement oui, mais je reste sceptique quant à la compatibilité.



en tout cas à la build 2011 j’avais demandé si les applis win32 allaient être sandboxées dans une future version de Windows, et le gars m’avait répondu que les applis WinRT représentaient l’avenir de Windows, et que le but était d’éliminer les applis win32, pas de les sandboxer.



du coup je me demande si drawbridge n’est pas juste conçu pour les applis WinRT, et non win32. A terme quand il faudra faire tourner toutes les applis winRT créées avec des versions différentes du runtime et du sdk WinRT, une technologie type drawbridge pourrait rentrer en jeu pour éviter tout cassage de compatibilité.



mais faire tourner du win32 sur des environnements sandboxés? Ca semble trop beau (et trop compliqué) pour être vrai.





Win32 ne peux pas disparaître. Il perdura encore 20 ans ou trente ans il y a trop d’applications win32 sur le marché. Du coup Microsoft est obligé de les sandboxer tôt ou tard. T’imagine un midori où les applications win32 pourraient faire tous ce qu’elles veulent? Il y aurait comme un problème de conception.

Pour DrawBridge l’un des buts premiers est justement de sandboxer les applications Win32. L’autre but est de créer au niveau architecture une “library OS”. Toute la plateforme applicative serait contenu dans la library OS. Donc en effet ça pourrait aussi gérer WinRT



Pour la compatibilité je t’invite à en discuter avec qui tu sais qui a bossé sur cette techno…



DrawBridge est capable de rediriger les appels du système de fichier pour stocker les fichiers liées à une application dans une image séparée. Donc si une application va écrire en dehors de la sandbox le comportement de l’application ne sera pas cassée.

Le seul problème que je connais c’est qu’apparemment il ne contiendrait pas la totalité des DLL win32. Mais il est possible de déployer des extensions à drawbridge qui les intègrent ou inclure ces DLL dans l’application.



Je précise que drawbridge devrait bientôt sortir. Depuis Windows 8.1 tu trouveras ce DLL du core OS dans le dossier system32: ext-ms-win-ntos-pico-l1-1-0.dll

Tu peux l’analyser avec dependency walker il fait référence aux picoprocess de drawbridge. De plus d’après les précédents papiers Ils gèrent déjà Windows 7 , 8 et linux en library OS. Pour les systèmes hôtes ils gèrent wince,win7,win8,barrelfish et midori



Pour la sandbox win32 Drawbridge n’est pas la seule possibilité. Perso je pense qu’une virtualisation applicative à la AppV serait suffisante et plus légère.









Drepanocytose a écrit :



+1, l’exemple des KDE avec les KDElibs et l’utilisation des possibilités de Qt5 m’est aussi venu directement à l’esprit, et c’est aussi selon mi la bonne approche.



Parce que pour l’instant on parle de 3 supports au max (PC, smart/tablette, console). Mais dans le futur on risque d’avoir plus de supports que ca (textile numérique peut-être, papier numérique, toutes les futures interfaces de contrôle qu’on va dev pour l’internet des objets, etc..)….







Effectivement, KDE est probablement le projet qui a été le plus loin au niveau des partages des outils. Les mêmes libs et data engine pour différent “form factor”: pc, tablet, netbook, mediaplayer plus une tentative d’une interface pour téléphone mobile qui n’a pas aboutie due à la difficulté de remplacer l’OS d’un mobile, mais d’autres projets basés sur Qt ont aboutis dans ce domaine (meego harmattan, BB10, sailfish, ubuntu phone).



Ils n’ont pas fait l’erreur que tout les autres ont fait: faire converger les différentes UI au point qu’elles ne sont plus optimales pour leur form factor de prédilection.

Il les ont gardé spécifiques tout en réutilisant les composants et ils les ont rendu installable en parallèle avec la possibilité de basculer (pas encore mais presque automatiquement) de l’une à l’autre.










arno53 a écrit :



il ne feront peut être qu’une seule sandbox pour tout l’environnement win32, ce qui permettrait à plusieurs applis win32 de communiquer ensemble sans trop de problèmes… Enfin ce n’est que de la spéculation mais c’est soit drawbridge soit encore supporter Windows une 15aine d’année :-/





Oui c’est ce qui pourrait se passer. DrawBridge consomme beaucoup moins de mémoire qu’une VM classique mais un picoprocess bouffe beaucoup trop de ram. Si il y a un picoprocess par application ce sera trop lourd. Du coup c’est probable qu’un seul picoprocess soit utilisé pour l’ensemble des applications Win32.









charon.G a écrit :



Win32 ne peux pas disparaître. Il perdura encore 20 ans ou trente ans il y a trop d’applications win32 sur le marché. Du coup Microsoft est obligé de les sandboxer tôt ou tard. T’imagine un midori où les applications win32 pourraient faire tous ce qu’elles veulent? Il y aurait comme un problème de conception.

Pour DrawBridge l’un des buts premiers est justement de sandboxer les applications Win32. L’autre but est de créer au niveau architecture une “library OS”. Toute la plateforme applicative serait contenu dans la library OS. Donc en effet ça pourrait aussi gérer WinRT



Pour la compatibilité je t’invite à en discuter avec qui tu sais qui a bossé sur cette techno…



DrawBridge est capable de rediriger les appels du système de fichier pour stocker les fichiers liées à une application dans une image séparée. Donc si une application va écrire en dehors de la sandbox le comportement de l’application ne sera pas cassée.







oui façon virtualisation vista pour les processus 32bit qui écrivent dans program files.



mais il y a plein d’applis qui ont besoin que leurs données soient accessibles à d’autres applis. Et souvent ces données sont stockées dans des dossier genre c:\nomdelappli\data\



comment drawbridge pourrait isoler les applis win32 les une des autres sans casser cela?



il faudrait avoir la capacité de gérer des exceptions, et que MS produise des profils de compatibilité pour les applis populaires. Définissant ce qu’elles ont le droit de faire.

mais ca me semble compliqué, et puis MS ne pourra pas faire de tels profils pour 50 millions d’applis win32. Il faudrait que les utilisateurs les fassent eux même, et comme on l’a vu avec vista et l’UAC, les utilisateurs veulent que ca marche directement, sinon ils gueulent.







Le seul problème que je connais c’est qu’apparemment il ne contiendrait pas la totalité des DLL win32. Mais il est possible de déployer des extensions à drawbridge qui les intègrent ou inclure ces DLL dans l’application.



Je précise que drawbridge devrait bientôt sortir. Depuis Windows 8.1 tu trouveras ce DLL du core OS dans le dossier system32: ext-ms-win-ntos-pico-l1-1-0.dll

Tu peux l’analyser avec dependency walker il fait référence aux picoprocess de drawbridge. De plus d’après les précédents papiers Ils gèrent déjà Windows 7 , 8 et linux en library OS. Pour les systèmes hôtes ils gèrent wince,win7,win8,barrelfish et midori





je peux bien imaginer drawbridge comme couche de compatibilité, aussi bien pour win32 que winRT, mais pas comme couche de sécurité.



Pour la sandbox win32 Drawbridge n’est pas la seule possibilité. Perso je pense qu’une virtualisation applicative à la AppV serait suffisante et plus légère.





justement j’avais demandé à un gars haut placé dans l’équipe à l’origine de AppV si la technologie pouvait être adaptée pour fournir une sandbox de sécurité (actuellement c’est une sandbox de compatibilité, elle n’empêche pas les actions dangereuses).



la réponse a été un clair non. Il m’a dit que AppV ne pourrait pas remplir ce rôle et que rien n’etait prévu pour isoler les applis win32 les une des autres.









jmanici a écrit :



mais il y a plein d’applis qui ont besoin que leurs données soient accessibles à d’autres applis. Et souvent ces données sont stockées dans des dossier genre c:\nomdelappli\data\



comment drawbridge pourrait isoler les applis win32 les une des autres sans casser cela?





Pour ça pas de soucis. Suffit de généraliser la mécanique mise en place depuis un moment avec le dossier Roaming.









ndjpoye a écrit :



Pour ça pas de soucis. Suffit de généraliser la mécanique mise en place depuis un moment avec le dossier Roaming.







je comprends pas le rapport entre roaming et sandboxing



tu peux préciser?









jmanici a écrit :



oui façon virtualisation vista pour les processus 32bit qui écrivent dans program files.



mais il y a plein d’applis qui ont besoin que leurs données soient accessibles à d’autres applis. Et souvent ces données sont stockées dans des dossier genre c:\nomdelappli\data\



comment drawbridge pourrait isoler les applis win32 les une des autres sans casser cela?



il faudrait avoir la capacité de gérer des exceptions, et que MS produise des profils de compatibilité pour les applis populaires. Définissant ce qu’elles ont le droit de faire.

mais ca me semble compliqué, et puis MS ne pourra pas faire de tels profils pour 50 millions d’applis win32. Il faudrait que les utilisateurs les fassent eux même, et comme on l’a vu avec vista et l’UAC, les utilisateurs veulent que ca marche directement, sinon ils gueulent.





Comme je l’ai dis au dessus il y a de fortes chances que la sandbox sandboxe tout l’environnement Win32 par rapport au système hôte.donc les fichiers seraient accessibles aux différentes applications win32 dans une sorte d’image vhd.







jmanici a écrit :



je peux bien imaginer drawbridge comme couche de compatibilité, aussi bien pour win32 que winRT, mais pas comme couche de sécurité.





Relis les specs de DrawBridge, galen hunt le dit clairement. Après que tu penses que ça ne marche pas c’est autre chose. Mais drawbridge sandboxe bien les applis Win32. Drawbridge est plus ou moins une VM logicielle et bénéficie de plusieurs avantages communs avec la virtualisation classique. Je te le dis pose la question à qui tu sais il a bossé dessus.







jmanici a écrit :



justement j’avais demandé à un gars haut placé dans l’équipe à l’origine de AppV si la technologie pouvait être adaptée pour fournir une sandbox de sécurité (actuellement c’est une sandbox de compatibilité, elle n’empêche pas les actions dangereuses).



la réponse a été un clair non. Il m’a dit que AppV ne pourrait pas remplir ce rôle et que rien n’etait prévu pour isoler les applis win32 les une des autres.





Pour AppV OK, Après pour des mesures de confidentialité les équipes communiquent peu entre elles. je doute que la personne à qui tu as parlé ne connaisse réellement la stratégie finale.

Et drawbridge a été dévoilé en 2011(par moi), il n’était pas connu avant je doute donc fortement que l’employé auquel tu as parlé connaissait à l’époque cette techno.

Comme je te l’ai dit au dessus ils ne peuvent pas laisser à terme les applications win32 sans sandbox et compromettre la sécurité des PC. Supprimer la compatibilité Win32 sur les PC est bien sur inenvisageable.