Core OS : le plan de Microsoft pour migrer les développeurs de Win32 vers les Windows Apps

Core OS : le plan de Microsoft pour migrer les développeurs de Win32 vers les Windows Apps

De l'autoroute au sentier de montagne

35

Core OS : le plan de Microsoft pour migrer les développeurs de Win32 vers les Windows Apps

Après les caractéristiques et ambitions principales de Core OS, nous plongeons plus dans les détails techniques de Win32, ses évolutions et ce qui attend les développeurs. Contrairement aux tentatives passées de Microsoft dans ce domaine, la nouvelle approche est nettement plus « douce ». La migration avance, mais il reste encore des obstacles.

Nous avons dans nos précédents articles expliqué comment Core OS allait représenter un nouveau chapitre de l’histoire de Windows, en apportant une solution souple aux problématiques actuelles. Microsoft a en effet longtemps été coincée entre de vieilles interfaces de programmation, très utilisées mais peu sécurisées, et de nouvelles, beaucoup plus sûres mais également plus limitées.

Presque dix années d’errances, ponctuées par des échecs retentissants comme Windows RT, auront infléchi le plan initial vers un projet beaucoup plus intégré où, normalement, les développeurs devraient s’y retrouver.

Notre dossier sur Core OS :

Le problème posé par Win32

Qu’appelle-t-on d’abord Win32 ? C’est un ensemble d’interfaces de programmation, exposant aux développeurs un socle normalisé de fonctions exploitables. Pour afficher une fenêtre par exemple, pas question de réécrire le code d’une fonction considérée comme triviale.

Comme indiqué dans notre précédent article, Win32 est apparu d’abord avec Windows NT en 1993, pour suivre l’évolution technique vers le 32 bits. Les anciennes API ont été rassemblées dans le groupe Win16. Les utilisateurs connaissent probablement les trois bibliothèques principales de Win32 : Kernel32.dll, User32.dll et GDI32.dll. Chacune expose des fonctions essentielles.

  • Kernel32 : fonctions de base du noyau, pour des appels directs à l’API du noyau NT (Native API).
  • GDI32 : fonctions graphiques de base (dessins, polices de caractères, rastérisation...)
  • User32 : fonctions de l’interface graphique (shell, dialogues et menus)

On y trouve également le réseau (ws2_32), la manipulation du registre (advapi32), les dialogues classiques (comctl32) ou encore la gestion COM (ole32).

Avec le temps, le nombre de fonctions Win32 a été décuplé. Cette augmentation était à la croisée des demandes des développeurs et du sens que voulait donner Microsoft à l’évolution de Windows. Il fallait également pouvoir interagir avec un nombre croissant de produits.

Mais Win32 a été construit dans les années 90, avec les techniques et inquiétudes d’alors. Il n’était pas tant question de sécurité que de fournir au plus vite ce qui était demandé. En outre, Microsoft voulait donner rapidement accès à des API de composants qui, s'ils étaient liés à Windows, restaient indépendants : Internet Explorer, DirectX, Office, etc. Ce sont les fameuses API COM.

Le modèle retenu étendait largement Win32, exposant tous les composants importants en COM. Il devait établir un environnement dans lequel les logiciels pourraient s’ébattre gaiement. Ce fut certes le cas – et ça l’est toujours en partie – mais il y eut un prix à payer : les malwares. Même si le problème a commencé surtout avec Windows 95, il n’a fait que prendre de l’ampleur, jusqu’à la « crise » sous Windows XP, aboutissant à un Service Pack 2 (qui intégrait pour la première fois un pare-feu) et retardant Vista.

La situation était d’autant plus sérieuse que les comptes créés sous Windows étaient par défaut en droits administrateur, sans aucun verrouillage avant d’entreprendre des actions importantes, comme installer un programme. On se souvient de Sasser, si répandu qu’il suffisait de laisser connectée à Internet une machine Windows XP non mise à jour pour qu’elle soit infectée en quelques minutes, grâce à une faille de sécurité.

Il fallait donc réformer en profondeur l’architecture du système.

Vista et Windows 7 : MinWin et la recherche d’un dénominateur commun

On s’en souvient, Vista eut la désagréable mission d’introduire de lourds changements. Système de transition par excellence, il n’avait clairement pas reçu tout le travail de finition nécessaire avant sa commercialisation, surtout à cause de la réinitialisation complète du projet Longhorn. Son Service Pack 1 avait largement amélioré la situation.

Si beaucoup se rappelleront sa lourdeur et le déluge de fenêtres agaçantes de confirmation des actions (UAC, User Account Control), il était un mal nécessaire. D’abord parce que Windows ne créait plus par défaut des comptes administrateur, mais également parce sous le capot, un gros travail de tri avait commencé.

Microsoft avait en effet décidé de faire du ménage, voulant rassembler tous les composants essentiels de son système d’exploitation. Le résultat s’appelait MinWin et contenait alors l’immense majorité des composants communs de Windows (couvrant toutes les éditions de Vista et les moutures de Windows destinées à l'embarqué). L’objectif était déjà posé : démêler et documenter consciencieusement les dépendances de la base technique.

Le nom MinWin fut surtout popularisé (du moins chez les passionnés) par Windows 7, car le tri avait continué. MinWin prit alors sa dimension de « Windows minimal » (il faisait tourner correctement les programmes), Microsoft dégraissant petit à petit sa liste de composants pour ne garder que l’essentiel. Ces composants étaient accompagnés d’un chiffre correspondant à une couche, selon qu’ils était plus ou moins proches du noyau.

Mais il y avait d’un côté l’architecture du système, et de l’autre les API fournies aux développeurs. Comment mieux contrôler les accès et limiter les risques ?

Windows RT, la réponse radicale et erronée au problème

Windows RT était une variante de Windows 8 dans laquelle il était impossible d’installer autre chose que des applications provenant du Store. Impossible par exemple d’installer Firefox en allant récupérer le fichier depuis le site de Mozilla.

Ce fut le premier essai, radical, de pousser les développeurs à se servir d’autre chose que de Win32. Pouvait-on cependant parler réellement de mise à l’écart de Win32 ? Non, car les composants impliqués sont trop profondément imbriqués dans Windows pour pouvoir imaginer un ménage total.

Même si l’accent était largement mis sur Metro (renommé plus tard Modern UI) et les nouvelles API de ce qui constituerait plus tard UWP (Universal Windows Platform), on retombait bien sur des DLL Win32 dans les fondations. Tout simplement parce qu’en l’espèce, elles sont inévitables.

Les développeurs n’avaient alors le droit qu’à un sous-ensemble de Win32 appelé MinCore et un lot d'API COM, comprenant surtout de nouvelles appelées « API WinRT » et certaines anciennes API COM. Dans la vision de Microsoft, cette méthode permettait de limiter grandement les risques en orientant les développeurs vers des interfaces considérées comme « safe ».

Ce mouvement était motivé par une volonté spécifique : séparer les bibliothèques système de bas niveau de celles de plus haut niveau. MinCore fut enrichi avec la version 8.1 de Windows et a posé les bases de ce que l’on appelle aujourd’hui « OneCore », et qui concerne surtout les Windows récents (nous y reviendrons).

Windows RT fut un échec aussi fracassant que la méthode de transition adoptée par Microsoft. La raison en était simple : les API proposées en remplacement n’étaient pas assez nombreuses (ni vraiment au point). L’écart était même colossal, bloquant les développeurs dans leurs choix et ne laissant de la place qu’aux applications bureautiques n’ayant pas besoin de fonctions bas niveau. Impossible pour des éditeurs de jeux ou de logiciels type Photoshop de basculer sur ce modèle. L'arrivée de Windows 8.1 améliorera la situation, sans combler le fossé pour autant.

Sans de nombreuses applications, la plateforme ne pouvait pas rencontrer le succès, les utilisateurs étant vite frustrés du manque de possibilités. Ce d’autant qu’un produit vendu sous l’appellation « Windows RT » renvoyait quand même à Windows, traditionnellement associé au principe de rétrocompatibilité.

Windows 10 S, le Desktop Bridge et l’approche plus progressive

Microsoft a refait depuis un essai avec la version S de Windows 10 (devenue le mode S, optionnel), elle aussi limitée au Store, mais avec une nuance majeure : les développeurs peuvent maintenant publier dans la boutique des logiciels totalement Win32, via le Desktop Bridge (anciennement Centennial). Les binaires sont préparés par les serveurs et envoyés sous une forme encapsulée permettant de profiter de certains avantages, comme la désinstallation propre.

Plus en détail, au-delà de la seule conversion au format APPX, les développeurs ont le choix de migrer ou non tout ou partie du code vers des API plus récentes, dont le nombre a largement augmenté avec les années.

Cette nouvelle approche, beaucoup plus discrète, est foncièrement différente. Elle a permis à de nombreux éditeurs de publier dans le Store des applications aussi connues qu’iTunes, témoignant d’une confiance plus importante des entreprises.

Pourquoi ce changement ? Parce qu’il permet justement de faire atterrir en douceur les applications dans la boutique. La conversion initiale ne réclame pratiquement aucun changement (à moins que le code ne soit très ancien). Les développeurs peuvent ensuite modifier le projet pour lui faire adopter des capacités inhérentes aux applications « modernes » (appelées Windows Apps) : distribution à tous les appareils Windows 10, mises à jour automatiques, prise en charge du centre d’action, des notifications et des vignettes dynamiques, ajout de la monétisation, etc.

Pour Microsoft, le plus gros argument est sans conteste la possibilité de distribuer une même application à tous les appareils compatibles. Mais ce doux rêve est dans la pratique complexe, et il aura fallu du temps pour que la vision se concrétise, via une approche de la migration beaucoup plus progressive. C’est là qu’interviennent OneCore et Core OS.

OneCore, OneCoreUAP et les socles d’API

Dans quel état est aujourd’hui Win32 ? La réponse n’est pas simple, expliquant les transitions décrites plus tôt.

Les développeurs souhaitant aujourd’hui publier une application sur Windows ont plusieurs possibilités. S’ils ne visent que les PC classiques, ils peuvent rester sur les technologies établies de longue date. Cependant, Microsoft s’avance vers un modèle plus uniformisé, et à terme standardisé (en matière de développement).

Comme dit précédemment, les API Win32 se répartissent en plusieurs catégories. Il y a d’abord toutes celles que l’on est sûr de trouver sur n’importe quelle édition de Windows 10. Elles sont rassemblées dans OneCore, qui établit un socle fonctionnel minimal commun à toutes les dernières versions du système, comme expliqué précédemment.

Mais alors, cela ne signifie-t-il pas qu’une même application peut fonctionner partout de la même manière ? Non, car en fonction de l’appareil visé, le shell n’est pas le même. Nous avons abordé ce point dans un précédent article, soulignant le problème posé par des éléments aussi simples que le centre de notifications, dont l’ergonomie changeait par exemple entre Windows 10 classique et Mobile. Parmi les shells, on trouve Desktop, Mobile, Xbox et Windows 10.

Un développeur visant OneCore aura donc l’assurance que son programme se chargera correctement, tant que les questions de shell n’entrent pas en ligne de compte. Une même fonction n’aura en effet pas la même interprétation visuelle selon l’appareil qui l’exécute. Par exemple, CreateDialog aura un impact dans le shell Desktop, mais pas sur Xbox. C’est l’intérêt de OneCore : s’assurer que le cœur d’un programme est capable de tourner sur l’ensemble des derniers Windows.

Et si l’on souhaite aller plus loin ? Pour s'assurer que l'application sera totalement fonctionnelle, le développeur n'a qu'une solution : se restreindre aux API Win32 compatibles UWP, regroupées dans une bibliothèque appelée « WindowApp.lib ». Il aura alors la certitude que le fonctionnement sera le même sur toutes les versions de Windows 10, quel que soit le shell. WindowsApp.lib est donc un sous-ensemble de OneCore.

En parallèle, Microsoft a rendu la plupart des API COM WinRT/Modern/UWP accessibles depuis des applications classiques. Il y a donc un continuum entre les apps Win32 classiques, celles qui n’utilisent que OneCore, et les app UWP. En clair, plus on veut augmenter le niveau de compatibilité avec les versions Windows 10, plus le champ d'API Win32 est restreint.

Avec le temps, Microsoft espère que toutes les applications seront migré petit à petit vers UWP et seront toutes des Windows Apps. Les conditions sont maintenant réunies puisque les plus grosses absences ont été comblées entre temps, permettant – en théorie – à presque tous les types de programmes de fonctionner, y compris ceux ayant des besoins en accélération graphique ou en accès au matériel.

Contrairement aux premières tentatives avec Windows RT, il n’y a même plus besoin de langages tels que C# ou XAML. Plus besoin du Store non plus dans l’absolu : une Windows App peut être téléchargée et installée depuis un site web.

UWP est pourtant bien une promesse de plateforme universelle. Alors que manque-t-il ? Concrètement, il faudrait que toutes les variantes de Windows 10 soient équipées des mêmes capacités, exploitables à travers un ensemble unique et standardisé d’API, tout en coupant les risques liés à l’utilisation des API Win32 de bas niveau. C’est ce que doit réaliser Core OS.

Core OS vu sous l’angle du développement

Dans nos précédents articles, nous nous sommes intéressés à la manière dont Core OS allait probablement se présenter aux utilisateurs, les défis qu’il devait relever, ses caractéristiques et ambitions principales.

Le Surface Duo, prévu pour la fin d’année prochaine, devrait être le premier produit grand public à être équipé de Windows 10X, basé sur Core OS. Comment les développeurs doivent-ils aborder ce changement à venir ?

La réponse variera en fonction de l’appareil visé. Un système basé sur Core OS acceptera toujours les Windows Apps, mais pas forcément celles visant les anciennes API Win32. Pour ces dernières, et sur les appareils où ce choix sera pertinent, le sous-système Win32 sera virtualisé dans un conteneur. En clair, un système Core OS peut dans l’absolu faire fonctionner tous les logiciels actuels. Tous les « anciens » continueront à tourner, sans modification, via une couche dédiée, mais séparée du socle système, comme un simple module. À la manière, finalement, du sous-système Linux présent dans Windows 10.

Selon nos informations, Core OS offrirait des avantages très concrets. D’abord un sous-système Win32 pleinement fonctionnel et assurant une rétrocompatibilité en théorie totale avec le parc logiciel actuel. Ensuite, plus aucun risque que le système s’encrasse avec le temps. Puisque Core OS peut embarquer un sous-système Win32 virtualisé, chaque conteneur reçoit sa propre copie des éléments dont il a besoin, dont la base de registre et les bibliothèques essentielles comme Kernel32.dll, User32.dll, Shell32.dll et Advapi32.dll.

Tout aussi important, les logiciels Win32 bénéficieront du PLM (Product Lifecycle Management) et des permissions de Windows 10, c’est-à-dire tout ce qui touche à la gestion d’une application par le système. Exemple simple : les Windows Apps intégrées (comme Courrier, Photos, etc.) sont automatiquement gelées quand elles sont détectées comme inactives. Les notifications continuent d’arriver mais elles ne consomment plus de CPU et ne gardent qu’une empreinte mémoire minimale (quelques Mo).

Le sous-système Win32 s’appuie en effet sur Windows 10, en réorientant les appels. Microsoft prévoit donc de faire d’une pierre deux coups : couper les derniers liens trop forts avec la base du système et plier les anciennes applications aux règles de sécurité plus modernes. Exemple, les réglages centralisés liés à la géolocalisation, l’accès à la webcam, au micro et ainsi de suite.

Le système doit encore être peaufiné

Des avantages conséquents, sans aucun inconvénient ? Il y en a pour l’instant, mais ils sont a priori temporaires. Toujours selon nos informations, les performances seraient ainsi dégradées en fonction des cas, particulièrement quand le GPU est sollicité, car DirectX doit transférer le résultat via un canal RDP, entrainant une latence importante. Le but est cependant à terme d’obtenir des performances natives ou presque.

Les développeurs pourraient alors se pencher tranquillement sur une migration de leur code, d’abord en s’assurant si besoin de la compatibilité avec OneCore, puis progressivement vers WindowsApp.lib. Lorsque le Surface Duo sortira avec Windows 10X, il ne s’agira alors que d’un « simple » shell supplémentaire avec lequel il faudra vérifier les éventuels soucis ergonomiques, mais pas le code. Car les Windows Apps auront l’assurance de pouvoir fonctionner avec l’ensemble des appareils Core OS, tandis que le sous-système Win32 ne sera présent que là où il sera pertinent. Comprendre : sur les ordinateurs fixes et portables.

Sur la question du « desktop », justement, les avis semblent divisés. Certains estiment que la virtualisation des anciennes API Win32 serait « proche », d’autres que Core OS serait avant tout dévolu à de nouveaux produits pour l’instant et que Microsoft compterait laisser tranquille le Windows 10 classique pour l’instant.

Commentaires (35)


Bravo pour l’article de qualité 👍


Très bon décryptage. Merci l’équipe


Excellent article. À voir l’influence de xcloud et de la future xbox pour les jeux video, après il ne faut pas oublier HoloLens avec la mixed reality… On verra ça dans quelques années, ça serait intéressant de voir l’evolution des nouveautés/changement dans windows 10, si ça commence a diminuer ?


<img data-src=" />


Hololens2 Surface hub2 et la Duo sont tous sur une base core OS avec des shells spécifiques. Et la nouvelle XBox aussi.

D’ailleurs, microsoft propose/proposera (certaines parties sont déja dispo depuis un moment je crois ) DX9/10/11 over dx12, qui permet en partie à la xbox de n’avoir qu’un driver DX12 mais de faire tourner les jeux ( et appel DX9 ) en compatibilité sans soucis. La même mécanique sur pc permettra au vendeur gpu de n’avoir à fournir qu’un driver DX12 ( et donc enlever une grosse couche de code historique au drivers )


Intéressant, j’avais raté les précédentes parties.

Il aurait été intéressant de parler des frameworks, Sous les vieux visual studio tu pouvais soit appeler directement l’API WIN32, ou passer par le framework VisualStudio du coup ton appli nécessitait l’installation du VisualC++ runtime pour s’exécuter correctement.

On aurait pu parler de .net qui a été également une tentative maladroide de remplacement de Win32 (sauf que ça allait avec de nouveaux langages moins performant c#, vb.net…)



Bref ces frameworks qui étaient censés être une abstraction des appels à l’OS étaient finalement totalement inutile.


Merci pour cet article, intéressante évolution de windows, à voir si l’essai se transforme !


Si chaque appli est dans un conteneur Win32, alors la machine va devoir être une bête de guerre, non ?


Pas de changement du nom prévu ? Parce que bon CoreOS c’est déjà pris et appartient à RedHat/IBM…


Merci, très bon article.



(même s’il mentionne COM, ce qui va sans doute raviver des cauchemars parmi vos lecteurs cette nuit <img data-src=" />)


Vous êtes sur que le pare feu de Windows XP est apparu avec le SP 2 ?

De même il existe depuis la version d’origine, mais a été bien plus plus en avant avec le SP2.








Aloyse57 a écrit :



Si chaque appli est dans un conteneur Win32, alors la machine va devoir être une bête de guerre, non ?





Logiquement les grosses applis tournent déjà toute en 64, les petites sont en générale légère et entre temps les pc seront encore plus puissant. Pour le “lol” tente de réinstaller un gros programme de l’époque genre photoshop 7 ( pas cs, le 7 ) et tu va halluciner, ça ce lance aussi vite qu’un bloc note. Avec un pc de l’époque t’en avais au moins pour 50 secondes.

&nbsp;





ThomasBrz a écrit :



Excellent article. À voir l’influence de xcloud et de la future xbox pour les jeux video, après il ne faut pas oublier HoloLens avec la mixed reality… On verra ça dans quelques années, ça serait intéressant de voir l’evolution des nouveautés/changement dans windows 10, si ça commence a diminuer ?





La prochaine Xbox sera entièrement rétrocompatible et certains ont même évoqués des mise à jours d’anciens jeux.. M’enfin ça rese un peu “daubé” par rapport au pc avec la possibilité de créer des mods. Je suis même pas sur que GTA6 sera aussi beau tout à fond que GTA5 avec tous les mods et textures / shader pack. Reste l’inconnu avec le framerate, tout dépendra des techno car c’est des jeux de MALADE.



C’est un peu ça le danger du cloud, ne plus être maitre de sa propre machine qui n’est plus qu’une vulgaire console de jeu à distance. Après c’est pas encore au point et tout juste utilisable pour jouer en solo et cantonné à certain type de jeux. Hololens je doute que ça fonctionne&nbsp; un jour, il vaut mieux un casque virtuel avec une caméra.



Article très intéressant ! Merci <img data-src=" />


pas forcément, c’est des travaux basé sur drawbridge, le surcoût mémoire est faible ( et le temp de démarrages des applications est augmenté dut au démarrage de l’os host si il n’est pas encore chargé ) Mais en utilisant une techno similaires, ils font tourner SQL serveur sous linux, donc niveau perf d’utilisation c’est plutôt correct j’imagine


Pas de changement du nom prévu ?



ils devraient !!!

(m’enfin…….) <img data-src=" />


Le problème de faire tourner dans des conteneurs, c’est que Windows y perd son ADN: la possibilité (via COM) de faire marcher des applis dans les applis, de faire des appels plutôt performants entre applis, de partager les composants…

&nbsp;

Plusieurs applis ont besoin de COM par exemple pour leurs propres extensions (filtres et autres).



Comme ce que l’on combat/contourne depuis des années avec l’exécution de l’environnement x64 à côté de x86 mais sans passerelle entre les deux (ceux qui gèrent des postes en entreprise avec des logiciels 32 et 64 mais une seule suite office possible comprennent), mais cette fois-ci pour chaque appli.


J’ai vraiment bien aimer les articles. Bravo a l’auteur =)


Extrait:&nbsp; L’article donne la réponse&nbsp; =)



“&nbsp;Des avantages conséquents, sans aucun inconvénient&nbsp;? Il y en a pour

l’instant, mais ils sont a priori temporaires. Toujours selon nos

informations, les performances seraient ainsi dégradées en fonction des

cas, particulièrement quand le GPU est sollicité, car DirectX doit

transférer le résultat via un canal RDP, entrainant une latence

importante. Le but est cependant à terme d’obtenir des performances

natives ou presque. “


Merci pour le décryptage 👍


Je paie donc je suis !





Si beaucoup se rappelleront sa lourdeur et le déluge de fenêtres agaçantes de confirmation des actions (UAC, User Account Control), il était un mal nécessaire.





Je crois qu’il y avait aussi, d’une certaine manière, un besoin de sensibiliser les utilisateurs à la sécurité, ça ne pouvais plus qu’être du ressort de l’éditeur de SE. Même si MS s’y est mal pris, finalement.


Il ne s’agit pas tant de mettre win32 au rebut que de pousser le store Microsoft. C’est ça la vraie finalité derrière, et nombre de développeurs de refuser cette tentative d’imposer le store comme étape imposée pour fournir des logiciels sur un système Microsoft.


Alors qu’ils ont accepté sur android et ios…


En quoi Microsoft tente d’imposer le store ?

Les développeurs ont le choix et c’est ça l’important.


Est-ce qu’ils avaient le choix sur ios et plus tard android ?


C’est plus l’illusion du choix, sans “Store” pas de visibilité sans compter que l’utilisateur se sentira toujours plus en sécurité en installant via le store.&nbsp; Vue la façon qu’il faut utiliser pour installer un apk (“sources inconnues”)








PercevalIO a écrit :



Il ne s’agit pas tant de mettre win32 au rebut que de pousser le store Microsoft.



Il serait bien de lire l’article avant de commenter n’importe quoi : Core OS n’est pas lié au store contrairement aux tentatives précédentes (Metro, WIndows RT, Windows 10S) où les nouvelles API étaient liées au store.









xillibit a écrit :



Est-ce qu’ils avaient le choix sur ios et plus tard android ?







À l’origine apple poussait la webapp. Pendant près un an il n’y a pas de store, ce sont les développeurs qui ont poussé pour avoir des applications “natives” et c’est apple qui leur a proposé de le faire via un store.



Quel style dans l’écriture ! Bravo pour le fond et la forme.


A noter que la séparation du Shell du reste du système a déjà commencé il y a plusieurs version de cela avec l’apparition de nouveaux process :

ShellExperienceHost.exe

StartMenuExperienceHost.exe

ShellExperienceSwitcher.exe

SearchUI.exe



Microsoft communique dessus maintenant mais ce travail a commencé il y a bien longtemps s’est juste passé inaperçue&nbsp;


Win32 est une sorte de cancer, Microsoft a mis Win32 dans une VM sur 10X et cela sera aussi le cas bientôt partout. Il ne va pas disparaître mais n’évoluera plus enfin il n’évolue déjà plus en fait. Nous le voyons clairement dans le domaine dans lequel je bosse même nos applications console utilise UWP et plus Win32 car les APIS dont nous avons besoin ne sont pas et ne seront jamais dans Win32.


Techniquement c’est joli. Utiliser la technologie des conteneurs afin de proposer un os modulaire, je trouve cela puissant. Mais microsoft ne va t il pas à contre courant du marché ?&nbsp;



Le marché n’est il pas entrain de pousser linux+le navigateur&nbsp; web (chromium ainsi que ses dérivés) comme os universel ?

Le marché ne pousse t il pas les éditeurs à migrer leurs produits vers du full web avec une offre type saas sauf cas très spécifique ?

Le marché ne pousse t il pas vers des produits “os indépend” on le voit avec les promesses des solutions cloud gaming qui promette de pouvoir jour à son jeux préféré sur n’importe quelle plateforme/device.



Tout ceci me laisse croire que&nbsp; dans quelques années je pourrais complètement me passer de windows voire même que savoir sur quel os tourne mes devices me sera complètement égal tant que cet os me permet d’executer toutes mes applications et respecte ma vie privée.&nbsp;

&nbsp;

&nbsp;




C’est bien la vie privée la pierre d’achoppement de cette avenir…


Tu peux oublier le dernier point xD




Le marché n’est il pas entrain de pousser linux…. comme os universel ?



heu….<img data-src=" />








Girthham a écrit :



Techniquement c’est joli. Utiliser la technologie des conteneurs afin de proposer un os modulaire, je trouve cela puissant. Mais microsoft ne va t il pas à contre courant du marché ? 



Le marché n’est il pas entrain de pousser linux+le navigateur  web (chromium ainsi que ses dérivés) comme os universel ?

Le marché ne pousse t il pas les éditeurs à migrer leurs produits vers du full web avec une offre type saas sauf cas très spécifique ?

Le marché ne pousse t il pas vers des produits “os indépend” on le voit avec les promesses des solutions cloud gaming qui promette de pouvoir jour à son jeux préféré sur n’importe quelle plateforme/device.



Tout ceci me laisse croire que  dans quelques années je pourrais complètement me passer de windows voire même que savoir sur quel os tourne mes devices me sera complètement égal tant que cet os me permet d’executer toutes mes applications et respecte ma vie privée.



C’est l’inverse : ce sont les éditeurs qui poussent le marché dans cette direction, car un abo sur plusieurs années est nettement plus rentable qu’une licence à paiement unique.

Pour les usagers, c’est plus d’inconvénients qu’autre chose (surtout quand on a des machines hors réseau)…



Fermer