Le 12/01/2017 à 16h 39

Je ne parle pas non plus des minidumps quand une appli crashe ou si tu as un bsod. Ces minidump servent aux éditeurs d’applications et de drivers à corriger les bugs. Ca existait bien avant Windows 10 mais c’est un point important.
Je sais que microsoft récupère aussi tout un tas de données sur l’usage de ton Windows,des infos comme ta résolution etc. Ces informations leur servent à savoir ce qu’ils doivent corriger dans les futures versions de windows 10.

Le 12/01/2017 à 16h 28

Parce que tu crois que c’est simple de proposer une interface qui affiche en raw les données réseaux. 99% des gens capteraient rien. Sans compter qu’il y a pas mal de données envoyées qui peuvent être analysées uniquement par des experts. Le peu de gens qui regarderaient se mettraient à râler. Apparemment Microsoft envoie en effet certaines informations confidentielles comme les pass edge ou l’historique (en partie pour la synchronisation entre appareil). Je pense qu’il envoie aussi les hardware id et les noms de composants pour les drivers. Il y a certains features qui captent la saisie du clavier pour améliorer la complétion. Au final tu montrerais ces données sans explications les gens prendraient peur(c’est d’ailleurs ce qui se passe).
Mais au final c’est le principe des statistiques. Les données sont anonymisées dans la masse d’information.

Le 12/01/2017 à 16h 00

Il y a tout un mythe sur la nsa key. Tout est expliqué en détail sur ce lien:
http://www.uzine.net/article1891.html

Pour résumer rapidement advapi32 contient les crypto api. Ce sont les api win32 de l’époque pour chiffrer et déchiffrer.
En fait en 1999 il y avait une loi aux états unis qui contrôlait l’utilisation du chiffrement. Les CSP(modules de chiffrements) devaient tous être certifiés par l’état américain. La clé nsa key servait pour l’examen technique de la NSA. Mais elle ne permet pas de tout déchiffrer comme on a pu raconté à l’époque….
D’ailleurs un peu plus tard cette loi a été abrogée ils ont retiré cette clé.


Crypto API est soumis à la réglementation américaine sur les exportations de cryptosystèmes [17]. Un aspect de cette réglementation oblige Microsoft à prendre les mesures adéquates afin d’assurer que son Crypto API chargera uniquement les CSPs admis pas la réglementation américaine sur l’exportation des cryptosystèmes. Cela est fait par une signature numérique de tous les CSPs. Avant qu’un CSP ne soit utilisé, CryptoAPI vérifie que ce CSP possède bien une signature numérique. La part de responsabilité pour Microsoft, en tant que vendeur du CryptoAPI, est de signer les CSPs. Quand un vendeur veut distribuer un nouveau CSP, il doit le soumettre à Microsoft pour signature et s’assurer que [’son produit’] respectera un des deux cas suivants :

• Le CSP ne sera commercialisé qu’en Amérique du Nord et par conséquent il n’est pas soumis au Bureau américain du contrôle des exportations. Dans ce cas, Microsoft donne immédiatement une signature numérique au CSP.
  


• Le CSP pourra être exporté et a reçu l’approbation du Bureau américain. Dans ce cas, Microsoft suit l’approbation émise et signe le CSP.
  
  
  
  « Il s’agit simplement d’un nom malencontreux. La NSA supervise les examens techniques de toutes les exportations américaines concernant la cryptographie. Les clés en question sont les seules qui nous permettent de garantir la [’mise en’] conformité avec l’examen technique de la NSA. Pour cette raison, elles furent connues à l’intérieur de la société Microsoft comme “les clés NSA”, et cela a été utilisé comme un nom de variable pour l’une des clés. Toutefois, Microsoft conserve ces clés [these keys] et ne les partage avec personne, y compris avec la NSA. »
  

Le 05/01/2017 à 10h 14

La maj gratuite n’existe plus et n’a jamais supporté une migration de XP. De plus beaucoup de chinois ont un budget modeste et ne peuvent pas forcément prendre un PC plus récent compatible.

http://www.ginjfo.com/actualites/logiciels/windows-10/windows-10-chine-aime-wind…

Le 05/01/2017 à 09h 55

C’est normal ce chiffre élevé, vu qu’il y a encore quelques années 9 licences sur 10 en chine de xp étaient piratées. XP est beaucoup plus simple à cracker que 10.
Pour le problème de sécurité il est déjà là. Les plus gros botnets sont composés de pc zombis chinois…

Le 30/12/2016 à 13h 43

Tu sais il n’y a pas du tout de cloisonnement en espace utilisateur sur Linux. Une application Linux peut pourrir si elle veut tout l’espace utilisateur comme Win32. De plus si une application Linux crée dynamiquement des fichiers, ils resteront aussi sur le disque dur après désinstallation sauf si c’est géré spécifiquement par le deb ou le rpm(comme avec win32 en fait).
Ensuite sur Windows tu as un niveau de sécurité supérieur. Une application admin ne peut pas avoir accès aux fichiers systèmes depuis Vista. C’est un niveau supplémentaire qui est attribué uniquement à Windows update.
Sur linux une application root peut tout à fait dégommer l’os.
Enfin bref je l’ai déjà expliqué des tas de fois mais il suffit de posséder des droits utilisateurs pour foutre la grouille et même installer des malwares que ce soit sur windows ou Linux.
La différence entre Windows et Linux est juste que les devs linux restent plus respectueux des guidelines que les devs windows et que les éditeurs de malwares s’intéressent plus à Windows qu’à Linux. Depuis un moment les malwares sur Windows n’ont plus besoin de droits admins.

Le vrai cloisonnement dont je parlais c’est la sandbox UWP.
Je précise que je développe à la fois sur Linux et Windows. Je vois beaucoup d’a priori sur le sujet qui sont totalement faux…

Le 30/12/2016 à 08h 36

Guinnness a écrit :

D’un autre coté si MS se mettait à imposer une discipline stricte dans ces domaines ça gueulerait instantanément vu la quantité de softs mal foutus qui ne fonctionneraient plus, et bien sur tout le monde accuserait l’OS


Ils ont justement justement appliqué cette idée avec UWP. Tout ce que tu décris a été corrigé dans UWP. Sauf que c’est l’os qui impose des règles strictes. Comme tu l’as expliqué jamais les devs ne bougeront pour Win32. On attend depuis déjà 20 ans.
Par contre un os full uwp prendra du temps mais c’est déjà plus viable qu’attendre que les développeurs win32 se bougent les fesses. Cocoa sur OSX ils ont pris 10 ans pour que la plateforme prenne. Un os full UWP serait surement bien plus fiable que le Windows actuel.

Mais bon désormais la plateforme win32 ne devrait plus évoluer. Au final les développeurs seront obligés de passer sur UWP pour gérer les nouveautés. Je pense en particulier aux applications holographiques. Sans compter les nouveaux devices qui sortiront sans win32.

Le 27/12/2016 à 18h 59

Tu as déjà pas mal de choses intégrées au compte Microsoft avec Windows 10. Je pense qu’effectivement , ça va encore s’accentuer.
Le travail sur l’unification entre les devices va continuer. Je ne sais pas si tu as vu cette news d’ailleurs:
http://www.windowscentral.com/microsoft-home-hub

Le 27/12/2016 à 18h 45

C’est ce que j’entendais par os de base gratuit. Pour les limitations si c’est trop contraignant ce n’est pas bon non plus. Les gens utiliseront des versions précédentes de Windows. Surtout que les concurrents ne proposent pas des upgrades bridés de ce genre….
Nadella voit surtout Windows comme un appel pour pouvoir vendre d’autres services payants. Cette stratégie passe obligatoirement par un windows gratuit non bridé.

Le 27/12/2016 à 18h 06

Le problème de l’abonnement complet c’est que se passerait t’il si des utilisateurs arrêtent de payer. Logiquement plein de pc n’auraient plus de mises à jour et une fragmentation s’installerait. Microsoft avec les mises à jour auto de Windows 10 veut éviter à tout pris ce problème.
Je vois quelque chose de plus crédible. Un système d’abonnement d’os modulaire(il y a d’ailleurs déjà eu des brevets par le passé) où l’utilisateur peut opter pour des modules gratuits ou payants. On peut imaginer que l’os de base reste gratuit mais pas forcément le reste. De cette manière les pc resteraient à jour.

Le 22/12/2016 à 10h 59

Il y a pas mal de régies de publicités qui ne sont pas encore prêtes. Mais c’est en train de bouger rapidement.

Le 25/11/2016 à 15h 57

Oui en effet ma phrase laissait à désirer " />
fatigue^^

Le 25/11/2016 à 15h 22

Elles ne fonctionnent pas avec EMET. C’est juste qu’il est inutile pour ces applications.

Le 25/11/2016 à 15h 15

En fait EMET fournit des algorithmes améliorés de DEP/ASLR. Ce sont toutes des technologies qui luttent contre les buffer overflow. A moins que tu es spécifiquement intégré du code unsafe. Les applications .NET ne sont pas concernées. Tu n’as pas de buffer overflow possible en .NET.

Le 24/11/2016 à 12h 27

Ce n’est pas aussi facile qu’une simple recompilation. Pour que le module soit chargé en espace utilisateur il faut que ce soit géré spécifiquement. Par exemple je crois qu’il existe des api spécifiques pour faire tourner certains systèmes de fichiers en espace utilisateur sur Linux.

Sur Windows tu as UMDF(User-Mode Driver Framework). Ils ont essayé de le relier au maximum avec KMDF(Kernel-Mode Driver Framework) . Mais pour les raisons que j’explique après il ne vise pas l’ensemble des classes de matériels disponibles.
Les systèmes actuels ne proposent pas de mettre l’ensemble des drivers en espace utilisateur pour des raisons de performances. Les contextes switch gérés par le processeur sont la cause principale. La plupart des micro noyaux ont des techniques particulières pour pallier à ce problème.

Le 23/11/2016 à 17h 08

arno53 a écrit :

Ça fait plaisir de revoir ce genre de fils de discussion, on se croirait sur PCI en 2008 xD

Et +1 pour Singularity/Midori pour avoir pas mal lu les différents blogs des développeurs de ces projets, ce n’est clairement pas à cause des performances ou de la sécurité que le projet n’a pas pu aller jusqu’à une phase commerciale mais bien à cause de la compatibilité avec l’écosystème existant…

Après sachant que l’UWP devait être compatible avec Midori on peut toujours espérer que Midori ressorte d’une façon ou d’une autre à travers Windows 10 dans quelques années..


+1000, j’expliquais déjà à l’époque que si le projet n’aboutissait pas ce serait pour des raisons de compatibilité avec l’écosystème existant. Ce n’est pas le premier projet qui devait remplacer Windows. Au final ils ont toujours choisi d’intégrer les changements dans Windows.

Le lien que j’ai posté plus haut https://robjsoftware.org/2016/10/20/the-future-is-further-than-you-think/) l’explique très bien. Plusieurs technos de Midori devraient être integrées au fil du temps dans Windows 10.

Le 23/11/2016 à 15h 01

Oui Depuis Vista tu as aussi plusieurs drivers en espace utilisateur ou le duo driver kernel et driver user(pile graphique et audio par exemple). Mais ça ne concerne pas l’ensemble des drivers.

Le 23/11/2016 à 12h 28

En fait sur Midori ou Singularity il n’y a plus une séparation administrateur où tout(enfin quasiment tout sur Windows) est permis et le côté userland avec moins de droits mais où en réalité on peut toujours faire pas mal de choses….

Je sais que ces deux os utilisent un système de permission avancé pour chaque SIP. A chaque installation toutes les dépendances sont complètement vérifiées. Mais je ne pourrais pas te détailler plus le fonctionnement j’ai zappé cette partie. Mais je sais que dans les sources de singularity on trouve un pdf qui en parle en détails.

Sur Midori chaque SIP(Software Isolated Process) est isolé et sandboxé. La mémoire de ce processus est scellée au runtime. C’est pour cette raison que mêmes les dll ont leurs propres SIP. Sur Midori et Singularity les performances des processus sont proches de celles d’un thread. Sur windows plusieurs mécanismes IPC existants modifient la mémoire du processus. Sur Singularity et Midori il n’y a pas d’api de code exportable ou de partage mémoire au sein d’un processus. (A noter que UWP s’en inspire sur certains aspects, même si bien sur, il ne va pas aussi loin) Tous les données échangées sont spécifiés et structurées dans un langage formel spec#. Tout passe par des canaux de communication et une sorte de tas partagé. En gros il n’y a pas de pointeurs à aucun moment que ce soit entre le système et les SIP ou les sip eux mêmes. Les SIP sont en code safe et totalement isolées entre eux. le micro noyau aussi. Donc tu ne peux pas avoir de failles d’escalades de privilèges. Au pire tu peux avoir un bug, mais une exception serait jetée ,ca ne produirait pas un crash comme avec une application C++. l’intégrité mémoire d’un SIP reste intacte même avec un crash(langage safe) . Le module en question pourrait être redémarré de façon isolée. Il ne peut pas y avoir de faille de sécurité vu que les buffers overflow n’existent pas avec les langage safe.

Pour la qualité du codage qui diminuerait suite à la résilience du système, Sur Midori ils ont repris tout le système de drivers. Je sais que le code nécessaire pour écrire un driver a été largement réduit. Il y a aussi un autre aspect du fait des caractéristiques techniques de Midori les outils de vérifications statiques du code écrits par le MSR sont beaucoup plus efficaces sur ce système. Si un tel système sortait je pense qu’au contraire la qualité n’aurait rien à voir avec ce qu’on connait.

Le 23/11/2016 à 11h 14

J’ai oublié aussi de dire que Midori s’inspire aussi largement du projet singularity. Tu trouveras tout un tas de papiers sur le site du MSR.

Le 23/11/2016 à 11h 08

Merci pour ta réponse détaillée ;)

Pour le 1 tu as le blog de joeduffy qui est l’ancien chef de projet de Midori. Il a écrit pas mal d’articles sur le sujet. A noter qu’il aime bien rust et est derrière les cppguidelines.
http://joeduffyblog.com/
Je te conseille aussi le twitter de felixhttps://twitter.com/h0x0d, il a trouvé vraiment pas mal de trucs sur le sujet.
Des brevets sont aussi disponibles sur freepatentonline qui explique certains fonctionnements de Midori en détail. Je n’ai pas les liens directement de mémoire mais ils se retrouvent.
Pour le 2, plusieurs concepts de checked c sont communs avec les cpp guidelines:
https://www.microsoft.com/en-us/research/project/checked-c/
Je pense que Microsoft compte proposer ces changements dans la norme c++ a terme.

Ensuite je l’avais déjà dit, Midori a été abandonné il y a un an. En réalité il était trop éloigné techniquement de Windows. Si Microsoft avait sorti un nouvel os, même avec une compatibilité Win32 il aurait crée une réelle rupture. C’est pour cette raison que Windows 10 est mis à jour graduellement de façon contrôlée. Apparemment il existe une team au sein de Windows qui travaille sur une intégration de plusieurs concepts de Midori au sein de Windows 10. Il y a des chances pour qu’ils aient choisi un langage du type de checked C. Il a l’avantage d ‘être compatible avec C++ et de permettre une mise à jour incrémentielle du code de Windows sur le temps. Rob Jellinghaus un ancien de midori en parle sur son blog.
https://robjsoftware.org/2016/10/

D’après une de mes connaissances qui bossent chez Microsoft mais je crois que l’information a été aussi confirmé sur une ancienne offre d’emploi. Cette équipe travaillerait en priorité sur edge. J’imagine qu’ils vont faire la même chose que servo.

Le 23/11/2016 à 09h 13

Les programmes de certifications de drivers n’ont jamais assuré le zero bug(c’est aussi idiot que le choix 6 plus haut) . Sauf que sur un noyau classique un simple bug c’est le crash assuré.

Pour les performances j’ai déjà expliqué plusieurs fois que le projet midori basé sur un micro noyau safe était un système hautes performances plus rapide que Windows. tous les papiers et sources disponibles en parlaient. Vu que l’isolation des SIP(processus isolés) ne se faisaient pas par le processeur(ring 0/3) mais par le langage les appels systèmes obtenaient des performances élevés équivalentes à l’appel de simples routines.

Ensuite le langage M# fonctionnait comme rust de plusieurs façons. Une bonne partie des vérifications se faisaient à la compilation grâce au compilateur bartok. Bartok effectuait tout un tas de vérifications dès la compilation. Il optimisait aussi grandement l’usage du “many core”.

Je l’explique déjà depuis des années mais certains qui se reconnaîtront sont vraiment de mauvaise foi. Dernièrement Mozilla a présente son projet Quantum et plus particulièrement servo. Certains libristes qui ont craché sur Midori pendant des années en utilisant l’argument faussé de la performance ont salué l’effort. Tout les benchs de servo annoncent des performances très élevés sur ce navigateur. Il est écrit en rust un langage safe et effectuait le même genre d’optimisations que midori. Ou sont passés les personnes qui critiquaient les performances des langages safe quand quantum a été annoncé? Comme je l’avais dit il était idiot de comparer à C# ou java et avec des optimisations on peut arriver à de très bons résultats. Au final quantum est beaucoup plus rapide que firefox avec seulement une partie du code en rust. Si les préjugés sur les performances du code safe avaient été fondés on aurait observé une nette baisse de performance mais ce n’est pas du tout le cas. C’est même le contraire….


Niveau sécurité, avoir le matériel drivé par le côté user n’est pas non plus sans conséquence.

Explique moi ça. parce que bon tu préfères peut être la situation actuelle où les drivers obtiennent les pleins privilèges sur la machine.

Le 22/11/2016 à 17h 55

Super le gros troll……
Windows NT est le noyau utilisé dans tous les windows récents et c’est loin d’être une daube. Son seul défaut : Les drivers tournent en kernel mode ce qui plombe tout. Linux a le même problème. Mais la tu ne vas pas dire que c’est une daube…..

Pour les Micro noyaux(les vrais) les drivers n’ont surtout pas les mêmes droits que le noyau. En terme de qualité tu te taperais beaucoup moins de bsod ou kernel panic(85% des crash ce sont les drivers).
Au niveau sécurité sur un système comme midori par exemple le driver est aussi sandboxé et a les mêmes droits qu’une application classique.

Le 22/11/2016 à 17h 32

Sauf que le système dans sa globalité ce n’est pas possible. Il y a trop de lignes de code en jeu. Par contre au niveau des micro noyau eux même c’est possible. Ils peuvent formaliser le code et prouver que le code est sans faille.
H4rvester a cité un exemple mais il y a aussi safe os http://www.driverscloud.com/fr/actualite/498-1/safeos-un-os-entierement-safe)

Le code de l’hyperviseur d’Hyper-V se situe aussi dans ce cas. Tout a été prouvé mathématiquement.

Le 22/11/2016 à 16h 29

Je dois être le seul qui ne trolle pas sur cette news mais bon " />
Après vu ce qu’annonce kaspersky il ne faut pas s’étonner de prendre le retour de baton, il fallait oser… " />

Le 22/11/2016 à 15h 32

Pour qu’un os soit fortement sécurisé(j’irai pas jusqu’à inviolable) il faut respecter plusieurs critères:
1)MicroNoyau sinon n’importe quel driver fait tout plomber
2)Le système doit être écrit en code safe sinon les failles d’élevation de privilèges sont toujours possibles

1. toutes les applications doivent être sandboxés. On peut même faire tourner des applications en C++ à condition que les points 2 et 3 soient respectés.
   


2. signer numériquement toutes les applications et créer une chaîne de trust
   


3. on peut imaginer un module antivirus intégré dont l’intégrité sera assuré par les points précédents.
   
   Apparemment le noyau de kaspersky OS est écrit en C++ donc le point 2 n’est pas respecté:
   http://eugenekasperskyru.files.wordpress.com/2012/10/1111.gif

Le 20/11/2016 à 10h 39

Arno53 s’est trompé. Le noyau NT ne tourne pas en espace utilisateur dans DrawBridge. Seule la partie applicative est virtualisé dans un pico process. Il comprend le sous système win32 et tous les dll utilisées par l’application déjà en user mode. Le noyau ici c’est Linux (le système hôte).
DrawBridge au départ a été conçu pour faire tourner Windows sur d’autres systèmes qui n’ont rien à voir comme barrelfish et Midori. Mais comme je l’avais expliqué à l’époque sur ce site il avait été aussi porté sur Linux. DrawBridge est aussi capable de virtualiser des “librairies os” Linux.
DrawBridge est le projet du MSR à l’origine des conteneurs Windows.(Drawbridge=Conteneur) Personne ici ne viendrait dire que les performances de MySQL ou Postgres sont mauvaises sur docker. La on est exactement dans la même situation.

Le 04/11/2016 à 14h 24

Le problème c’est que chaque mois Microsoft met à jour l’ensemble du système. Des dll de base sont systématiquement mis à jour. Y compris le noyau.

Le 04/11/2016 à 14h 10

Tout dépend des dll modifiés,certains sont utilisés par l’ensemble des applications du système. Tu es donc obligé de redémarrer certaines fois.

D’autres systèmes remplacent directement le fichier mais l’instance mémoire de l’ancienne version reste chargée. Donc si tous les processus qui l’utilisent n’ont pas été fermées, tu ne redémarres pas mais en réalité l’os n’est pas complètement à jour.

Midori avait une méthode bien particulière. Tous les SIP(process isolé) étaient isolés totalement au runtime. La notion de dll n’existait pas vraiment car en réalité sur ce système chaque dll était un SIP séparé en soi.
Si tu mets à jour un SIP tu peux facilement l’arrêter le mettre à jour puis le redémarrer. C’est possible car le SIP est totalement isolé en mémoire.
Sur Windows et Linux les dll/so sont chargées dans la mémoire du processus ce qui n’est pas le cas sur Midori où le dll a son propre sip.

Le 04/11/2016 à 11h 03

Peut être je ne sais plus si l’option était par défaut ou pas.

Le 04/11/2016 à 10h 55

Si tu as activé la bonne option oui :
http://www.hostingpics.net/viewer.php?id=996249misesajour.png

Le 03/11/2016 à 11h 02

Je n’y crois pas trop les gains sont trop importants, notamment au niveau sécurité. Par contre je suis d’accord que ça prendra beaucoup de temps. A mon avis c’est surtout plus simple à faire évoluer de façon incrémentielle que de partir sur un reset complet qui créerait une totale rupture et tous les problèmes qui vont avec.

Microsoft a adopté la même stratégie incrémentielle avec Midori pour intégrer les changements dans Windows 10.

Le 03/11/2016 à 10h 36

Uther a écrit :

D’abord Quantum n’introduit que de petites partie de Servo dans Gecko qui restera encore pour un moment très majoritairement codé en C++.


Oui pour le moment mais ils comptent tout réécrire en rust à terme. Par contre même au stade actuel Mozilla a annoncé de meilleurs performances avec quantum. Si rust avait soit disant été plus lent on n’aurait pas constaté ces hausses de performances.

EDIT: Voir mon commentaire plus haut le post que tu cites était ironique.

Le 03/11/2016 à 10h 03

Je le sais bien mais mon post était ironique ;)

Microsoft a travaillé sur un os écrit complètement en code safe. Le langage M# utilisait aussi plusieurs concepts de rust. Il y avait aussi énormément d’optimisations pour le many core et le parallélisme massif. Sans compter les autres optimisations avec les sip permis par l’architecture de ce système. A l’époque plusieurs personnes ont refusé de croire qu’il était plus rapide que Windows car écrit dans un langage safe, donc plus lent. Pourtant tous les documents et témoignages allaient dans ce sens.

Actuellement Microsoft essaye de faire évoluer le C++ de la même façon
https://github.com/isocpp/CppCoreGuidelines
Plusieurs de ces concepts sont repris dans checked c:
https://www.microsoft.com/en-us/research/project/checked-c/
Je pense que ms va essayer de le proposer sur une future norme de C++ …

Sinon rust effectue bien du bound checking au runtime dans certains cas d’après ce lien:
http://stackoverflow.com/questions/28389371/why-does-rust-check-array-bounds-at-…

Mais les pertes de perfs restent minimes.

Le 03/11/2016 à 09h 04

Sans surprise si Microsoft ne propose rien d’équivalent d’ici là ce sera mon prochain navigateur. Un navigateur dans un langage safe mon rêve :)

Par contre c’est bizarre ils n’ont pas perdu 50% de performances. Nous aurait t’on menti? " />
Le bound checking c’est au moins çà…

Le 27/10/2016 à 18h 52

Après oui vous avez raison nadella ne s’est pas investi plus dans WM10. Mais c’est justement car il pense que c’était mort. Ca ne servait à rien de perdre encore de l’argent dans le marketing et les nouveaux modèles.
L’avenir nous dira si c’était la bonne solution ;)

Le 27/10/2016 à 18h 17

Tu m’as mal compris je voulais dire que Microsoft n’allait pas supprimer complètement toute la branche hardware.

Désolé de te le dire mais lors de gros rachats ce genre de choses arrive très souvent. Tu ne peux pas assimiler une boite comme nokia sans supprimer un minimum d’effectifs.
Surtout que la branche mobile était déficitaire. Pour les features phone ce n’était pas du tout leur domaine d’activité.
C’est justement pour cette raison que ballmer n’aurait jamais du racheter nokia. C’est facile il se barre et les autres ramassent la merde….

Le 27/10/2016 à 17h 49

Nadella ne s’est pas débarrassé de nokia mais de lumia différence subtile. Il y aura toujours une branche hardware. Nokia a déjà couté assez cher , il ne va pas en plus s’en débarrasser. ce qui est fait est fait.
Tu voulais peut être que nadella continue sur le court terme à miser sur une stratégie perdue d’avance? Nadella je pense voit beaucoup loin.

Pour les bugs il en a dans tous Windows 10. Ils ont changé beaucoup de code en peu de temps(les gens le savent pas mais beaucoup plus que vista à l’époque) . C’est juste que le niveau des grosses mises à jour s’est accéléré et ils ne sont pas tout a fait au point. Avec une relance tous les 3 ans ils arrivaient à mieux gérer.
On m’a raconté aussi qu’ils ont du casser du code pour préparer de gros changements à venir.

Le 27/10/2016 à 16h 26

WP7.5 était peut être meilleur mais la part de marché était ridicule. D’ailleurs elle n’a jamais dépassé 10%. Même si Microsoft avait tenté de corriger tous les problèmes sur WM10, il ne faut pas se leurrer ils ne seraient jamais arriver à rien au final.

Ensuite la faute n’incombe pas totalement à nadella. Une bonne partie de la stratégie et du travail sur Windows 10 avait été initié par ballmer. Il est idiot de penser que le développement a démarré quand nadella est devenu PDG. Je sais aussi que le rachat de nokia par Microsoft initié par ballmer a coûté cher à la boite. Ca ne faisait pas l’unanimité. Mais bon c’est trop tard il faut faire avec…

Et bon si Microsoft a raté le coche du mobile je pense que c’est surtout ballmer le fautif. Il l’a dit lui même. Le ratage avec Vista a retardé les projets pour le mobile. Quand ballmer s’y est enfin intéressé c’était déjà trop tard….

Le 27/10/2016 à 14h 41

La première rupture(wp7 à wp8) était provoqué par un changement de noyau. La deuxième(wp8 à win10) était un changement de la plateforme WinRT.

A priori on est dans aucun des deux cas mais effectivement il y a des raisons d’être méfiant. Je ne sais pas ce qu’il en est des autres téléphones mais je lui ai dis la même chose que toi. Il m’a répondu que mon 950 serait supporté.

Ensuite le but de Microsoft c’est d’en vendre au plus grand monde.Je doute très fortement qu’ils le vendent à ce prix(plus de 1000 euros) . Microsoft n’est pas en position de force sur le marché. il aura plutôt intérêt à sortir différentes gammes à différents prix.

Le 27/10/2016 à 13h 27

Ler van keeg a écrit :

C’est sur que le R&D a un prix. Mais ça reste des produits devant lesquels on bave sans pouvoir se les offrir.


Cela n’a pas empêché que l’iphone se répande en 2007 ;)

Le 27/10/2016 à 11h 49

On ne connait pas encore la cible mais j’ai quand même du mal à croire que Microsoft va se priver du marché grand public.
Hier j’ai lu une interview de nadella qui expliquait que l’une des plus grandes erreurs de MS était d’avoir vu le PC comme le coeur de tous leurs projets.Je pense qu’il a donné une tendance..

http://news.softpedia.com/news/microsoft-we-were-wrong-to-consider-the-pc-the-co…

Le 27/10/2016 à 11h 43

Ce n’est pas une évolution justement ça devrait trancher ,du moins ce que j’ai compris. Après on verra bien ce n’est pas gagné en tous cas. Mais ils ne peuvent pas faire plus bas.

Le 27/10/2016 à 11h 29

J’en ai discuté avec un de mes contacts chez Microsoft. Je lui ai clairement demandé si windows phone est mort.
Il m’a expliqué qu’ils ont décidé d’arrêter de miser sur la génération de téléphone actuelle. Ils ont perdu cette bataille , cela ne servait à rien de persister.
Ils sont en train de bosser sur une toute nouvelle génération de téléphone tant au niveau software que hardware.
D’après ce qu’il a vu il est extrêmement enthousiaste, je ne répéterai pas le qualitatif qu’il a utilisé pour avoir 10 pages de trolls derrière mais d’après lui ça envoie du lourd…
Comme d’habitude ils n’annoncent rien avant que tout soit prêt. D’ici là le nombre d’applications win10 aura encore augmenté.

Le 26/10/2016 à 18h 17

Le surface dial je me souviens l’avoir vu dans une vieille vidéo du MSR


L’ensemble parait plus inspiré que ce qui a été fait jusqu’à présent et ressemble davantage à de vieux essais de Microsoft Research il y a bien longtemps.

Pour les changements d’interface de ce creator update, je me suis dit la même chose que vincent

Le 19/10/2016 à 11h 47

Quand je vois que certains râlent car le fond de l’explorateur a légèrement changé entre 7 et 10, je sens qu’il va bientôt y avoir des suicides sur ce site " />

Microsoft travaille sur une version de l’explorateur en UWP pour PC. Vu qu’il y a plus de ¹⁵⁄₂₀ ans d’habitudes derrière, même si ils en prennent compte c’est une certitude que ça va gueuler….

Le 17/10/2016 à 10h 24

Tolor a écrit :

Ce qui ne fonctionne pas, et ne pourra jamais fonctionner, c’est de plaire à tout le monde. Le changement, ou même l’absence de changement, fera toujours des malheureux.
Ici, c’est la simplification de l’interface de base qui ne plait pas à certains “power users”


Je me souviens d’une vieille actu basée sur les données télémétriques de Windows Vista(et oui ça existe depuis beaucoup plus longtemps que 10 ) . Les chiffres montraient que très peu de personnes changeaient de fond d’écran. Ca m’avait surpris à l’époque mais c’est une réalité.

Je pense que tous les options disponibles actuellement dans le nouveau panneau de configuration 10 cible 99% des utilisateurs. Il en reste encore certaines qui ne sont pas disponibles car certaines technologies vont être remplacées. Je pense aux options de thème par exemple(wait and see…)

Microsoft cherche effectivement a simplifier l’interface pour le plus grand monde. Après bien sur il ne pourra jamais abandonner les power users mais j’imagine que ce n’est pas la priorité actuelle.

Pour l’unification, le flat design qui ne plait pas à beaucoup ici est juste la partie émergée de l’iceberg. Rien n’empêcherait de changer le style graphique par la suite. Surtout que les technos xaml permettent un peu près n’importe quoi. Et surtout elles permettent un développement et des évolutions beaucoup plus rapides qu’avec la gdi.

Le 07/10/2016 à 11h 58

Sinon Windows 8 n’était pas une réussite d’homogénéite. Tu jonglais avec deux interfaces différentes qui n’avaient rien à avoir. Tandis que Windows 10 intègre une interface unique qui s’adapte à l’appareil.
De plus au niveau applicatif les applications WinRT sur Windows 8 n’étaient pas universelles. Tu avais des versions différentes des applications selon l’appareil. Au niveau de la plateforme il n’y avait pas non plus un socle commun d’api. Seul le “core OS” était commun entre les appareils sur Windows 8

Le 07/10/2016 à 11h 42

Sur Windows 8 sinofsky a voulu imposer une interface pour tablette sur des PC. Là où windows 10 garde un socle commun mais avec des interfaces qui s’adaptent au type d’appareil.

Pour en avoir discuté avec des contacts bossant chez MS, Sinofsky était quelqu’un d’autoritaire qui voulait imposer sa vision et n’écoutait pas du tout ses collaborateurs. Il s’est mis à dos plein de chef de projets. C’est pour çà qu’ils l’ont viré. Tu pourras chercher sur google certains sites en ont parlé à l’époque et confirme mes propos.

A coté de ça Myerson est beaucoup plus souple et flexible. D’ailleurs sur Windows 10 il a réussi à unifier tous les secteurs de l’entreprise pour une vision commune. Il n’aurait jamais réussi à le faire si il avait eu le même caractère que sinofsky.

Le 06/10/2016 à 17h 21

Je pense que la réécriture complète du code en uwp prendra quelques années. A ce moment là quand uwp sera au niveau(car ce n’est effectivement pas encore le cas) ils vireront toutes les app win32 intégrées et l’ancien panneau de configuration pour éviter les doublons.

Le 06/10/2016 à 11h 56

Je comprends difficilement comment on peut penser que l’ancien panneau de configuration soit plus ergonomique que le nouveau. Je me souviens qu’à une époque le côté bordélique de l’ancien panneau avait été abordé, maintenant c’est devenu un exemple d’ergonomie… C’était nécessaire que Microsoft le reprenne.
En fait avant il n’y avait pas un panneau de configuration mais plusieurs en réalité. Il y avait des binaires séparés pour chaque partie(une vingtaine sur la fin). Et chaque panneau avait un design et une ergonomie totalement différente. Sans compter que les tiers pouvaient rajouter aussi leur propre panneau avec leur propre interface ou même modifier des existants.

Le nouveau panneau de configuration est désormais un seul binaire complètement uniformisé. Il suit le même code stylistique partout. Sur les dernières versions c’est plutôt bien catégorisé. ils ont repris aussi certaines anciennes catégories pour éviter de trop désorienter.

Il reste cependant deux problèmes.
L’ancien panneau n’a pas encore été complètement remplacé. Du coup on jongle avec les deux pour le moment.

Le deuxième ce sont les habitudes. Ce panneau est ancré depuis 20 ans dans les habitudes des utilisateurs windows. Donc forcément il faut réapprendre un peu. Bien sur les gens gueulent que c’est pas ergonomique alors qu’objectivement c’est l’ancien panneau qui ne l’était pas.

Quand Microsoft annoncera un nouvel explorateur uwp, je peux déjà vous annoncer sans me tromper
que beaucoup de gens crieront à l’infamie car c’est typiquement le genre de trucs le plus ancré dans l’interface Windows. Quoi que fasse Microsoft il y aura quand même une tranche d’utilisateurs qui gueulera.
Mais bon c’est normal les professionnels savent qu’il y a toujours une phase de rejet au départ surtout quand c’est vraiment différent et beaucoup finissent par l’accepter avec le temps.