Le 07/01/2014 à 11h 08

HarmattanBlow a écrit :



Je n’ai jamais dit que le C++ ne fonctionnerait plus et je regrette mais je n’ai pas le temps de regarder des vidéos promotionnelles d’une heure ou de consulter des centaines de brevets. Je t’invite à me dire en une phrase ce dont il s’agit. Mais trouver un moyen pour faire tourner les applis traditionnelles n’a rien de sorcier, le problème c’est que ce n’est pas gratuit, qu’il s’agisse de virtualisation ou de maintien d’une archi traditionnelle avec ring3 pour ces vieilles applis.





Il peut y avoir un C++ dédié pour crées des applis Midori, comme le C++ CLI. Mais à part ça il y a aussi la question de savoir si oui ou non ils cherchent à maintenir la compatibilité avec les applis existantes. Ce qui encore une fois ne serait pas gratuit.





Tu fais de la mauvaise foi? voilà ce que tu as ecrit:





Pas avec Midori. Ou alors avec du C++ modifié ou emballé dans une VM. Mais par définition Midori ne peut exécuter que du code vérifiable, ce qui n’est pas le cas du C++.

Le 07/01/2014 à 11h 02

Khalev a écrit :



T’as des liens vers ces brevets? Parce que jusqu’à présent quand je te lis j’ai plus l’impression de lire un fanboy sans esprit critique qui croit tout ce que lui dit le grand Microsoft que quelqu’un de vraiment raisonné.

Un peu de sources sur tes dires serait bienvenu (et permettrait de mettre tout le monde à niveau). Comme le dit HarmattanBlow, on a pas tous le temps de faire un veille exhaustive.





J’ai source des tweet de gens de Midori qui l’expliquent. Tu as aussi un lien dans mon précedent commentaire.

Pour le brevet il s’agissait de faire tourner des applis natives sur un os safe en passant par un module qui vérifiaient les données communiquées. ca ressemblait fortement à WinRT.

Ce brevet je l’ai vu en 2009 ou 2010 et je ne garde pas tous les liens que je lis. Je m’en fous un peu que tu ne me crois pas. Surtout quand on me traite de fan boy pour me discréditer. " />

Le 07/01/2014 à 10h 55

HarmattanBlow a écrit :



Il faut entendre “vérifiable” de façon contextuelle. Ici on appelle en substance vérifiable un code dont on est sûr qu’il ne pourra pas écrire ailleurs que dans ses propres pages mémoire de données et qu’il n’exécutera pas certaines instructions CPU. Quand ces conditions sont garanties on peut le faire tourner en ring 0 sans risques de le voir compromettre un autre processus ou le noyau, ou de violer ses privilèges d’accès.



Le processus est libre de se deadlocker et d’oublier de nettoyer sa mémoire, peu importe, ça ne fait pas partie du contrat à vérifier puisque le système sait de toute façon faire face à ces événements s’ils devaient survenir.



Une telle vérification est liée au langage. Le C++ ne peut pas être vérifié à cause de des pointeurs pseudonymes, de l’asm et peut-être d’une ou deux autres choses. Le C#, lui, peut être vérifié.





Je n’ai jamais dit que le C++ ne fonctionnerait plus et je regrette mais je n’ai pas le temps de regarder des vidéos promotionnelles d’une heure ou de consulter des centaines de brevets. Je t’invite à me dire en une phrase ce dont il s’agit. Mais trouver un moyen pour faire tourner les applis traditionnelles n’a rien de sorcier, le problème c’est que ce n’est pas gratuit, qu’il s’agisse de virtualisation ou de maintien d’une archi traditionnelle avec ring3 pour ces vieilles applis.





Il peut y avoir un C++ dédié pour crées des applis Midori, comme le C++ CLI. Mais à part ça il y a aussi la question de savoir si oui ou non ils cherchent à maintenir la compatibilité avec les applis existantes. Ce qui encore une fois ne serait pas gratuit.





Commentaire 94:

Les applications C++ WinRT tournent dans une sandbox. La sécurité et la fiabilité est donc assurée. Les api de WinRT sont déjà type safes.



Voilà ce qui se passe si tu communiques un pointeur dans une api winRT

Le 07/01/2014 à 10h 50

youtpout978 a écrit :



Il existe bien le c++ CLI, ça sera peut être la même chose sur Midori.





C++ cli c’est une adaptation du C++ en managé par Microsoft. C’était vu comme un langage transitoire pour passer à C# , ça n’a jamais marché.

J’ai cité un propos d’aleks bromfield plus haut qui explique bien que le modèle applicatif ne change pas. Avec WinRT on peut coder dans tous les langages. C’était le but

Le 07/01/2014 à 10h 37

ldesnogu a écrit :



Ils n’ont pas le choix : s’ils interdisent l’utilisation des langages les plus utilisés par les devs, leur OS est mort-né. Même Apple n’a pas osé sur iOS.





Tout a fait

Le 07/01/2014 à 10h 20

Au début je pensais aussi la même chose qu’harmattanblow :que le c++ ne marcherait plus sur Midori. Mais j’ai pu lire des brevets et certaines lectures qui m’ont fait changé d’avis.



Microsoft mise toujours sur le c++

Le but de WinRT était de mettre au même niveau tous les langages. Avant si on codais en C++ ,on ne profitait pas des mêmes api qu’en codant en .NET



Avec WinRT le framework est uniforme pour tous les langages.

.

En effet Windows est un os first class c++ et Midori un os first class M# mais le C++ devrait subsister.



De nombreux projets sont écrits en C++. Ca reste plus simple de porter le projet sur WinRT (surtout pour les projets multi) que de complètement tout réécrire en M#



Au final seuls les développeurs systèmes devront coder en M#. mais vu les gains en terme de rapidité de développement et de fiabilité, je doute que ce soit un problème.

Le 07/01/2014 à 09h 29

Tophe a écrit :



Non, les noyaux CE et NT n’ont strictement rien à voir. Il y a certes une compatibilité parce que l’API Win32 est utilisée dans les 2 cas pour le dev applicatif, mais côté CE, c’est un sous ensemble.

Les compilateurs ARM ne sont pas les mêmes par exemple. (chose qui a changé avec Compact 2013, qui utilise la même ABI que Windows 8)



La possibilité d’utiliser des applications Phone7 sur Phone 8 est effective grace au Compact Framework 3.9.





Je n’ai pas dis non plus que CE et NT sont pareils mais ils ont été tous les deux concus autour de win32. Le changement vers Midori est bien plus radical.

Après pour te donner raison le passage de wp7 vers wp8 s’est aussi accompagné d’un changement de plateforme de développement avec WinRT. WinRT est censé subsisté.

Le 07/01/2014 à 09h 26

HarmattanBlow a écrit :



Pas avec Midori. Ou alors avec du C++ modifié ou emballé dans une VM. Mais par définition Midori ne peut exécuter que du code vérifiable, ce qui n’est pas le cas du C++.





regarde ce tweet de alleks bromfield qui bossait sur midori:

Twitterou can have a more reliable system, written in a better language, that still has the same application model.



Je l’ai expliqué dans le dossier de Win8. WinRT tourne dans une sandbox native actuellement. Mais les api de winrt sont déjà type safe.

WinRT devrait pouvoir tourner sur Midori. En clair l’application c++ tournerait dans une sandbox. Les api communiquerait avec Midori vu qu’elles sont déjà safe.

Enfin drawbridge est prévu aussi pour tourner sur Midori et ce sont aussi des applications natives.

Le 07/01/2014 à 09h 20

ff9098 a écrit :



Oui c’est présenté comme le langage parfait, on verra bien. En attendant espérons au moins que MS le libère sous une licence libre







My goal is to eventually open source this thing, but before we can do that we need to button up a few aspects of the language and, more importantly, move to the Roslyn code-base so the C# relationship is more elegant. Hopefully in 2014.





Microsoft est en train de changer de stratégie économique. Il y a plusieurs années ,a propos de la vision long terme de ray ozzie , il parlait d’une économie software and service pour Microsoft. J’avais expliqué sur PCI à l’époque que Windows pourrait devenir sur le long terme gratuit voir open source, on m’avais pris pour un fou.



Les dernières rumeurs sur threshold laissent entendre que terry Myerson veut rendre gratuit windows phone 8 et RT. Avec threshold le sku de base devrait se baser sur ces versions, il y a donc de fortes chances pour que ce soit aussi gratuit.



Quand à midori il a été concu pour une nouvelle stratégie économique(celle évoquée par ray ozzie). C’est probable qu’il soit gratuit et open source.

Le 07/01/2014 à 09h 10

metaphore54 a écrit :



WP 7 ====> WP8 changement de tel obligatoire alors que l’OS a eu moins de changement que là, donc je ne me fais pas d’illusion.





D’après sdtimes qui avait écrit sur Midori, Midori peut faire tourner les drivers windows dans des services midori. Donc Microsoft pourrait assurer une compatibilité.

Le 07/01/2014 à 09h 02

Tophe a écrit :



Moins de changements ! " />

On est passé d’un noyau Windows CE (version 6.0 qui ne gérait à l’époque “que” 512Mo de RAM au maximum et était singe core only) vers un noyau Windows NT. Le changement est du même ordre de grandeur.





Pas vraiment car on restait sur du Windows. Là on parle de remplacer Windows même si le nom pourrait subsister pour des raisons marketing.

Le 07/01/2014 à 09h 00

Ce n’est pas du blabla et c’est même une définition claire du domaine de ce langage. L’asm ne sera pas autorisé dans cet OS donc ce sera bien pour les dévs Windows le plus bas langage dont ils auront besoin, celui conçu pour écrire jusqu’aux pilotes de périphériques et pour écrire tous les pilotes. C’est la contrainte sur laquelle ils travaillent, par opposition à C# qui restera dédié à des applications de plus haut niveau.





Oui tout a fait, au niveau système le M# sera obligatoire pour éviter les bsod sur les pilotes entre autres et les failles de sécurités dans le système.



Par contre au niveau applicatif rien ne changera on devrait pouvoir toujours coder e C++ avec WinRT

Le 07/01/2014 à 08h 52

HarmattanBlow a écrit :



Ils n’ont pas fini d’écrire le langage avec lequel ils comptent le programmer ! Je pense que ça en dit long… Qui plus est WP9 est sans doute déjà en développement depuis un bail et WP10 aussi, en quelque sorte.



Pour l’instant je n’y vois que la confirmation que MS a validé toutes les recherches menées et amorce la réalisation de produits finis et la transition vers ceux-ci. Et puis d’abord je ne sais pas si Windows phone est le premier concerné par ces technos, même s’il le sera à terme.





Regarde cette offre sur la prochaine version majeur de Windows phone(visibiblement wp9):

MicrosoftDo you ever wonder what it takes to bring-up an entire new OS foundation to life? Do you wonder what the core new features of the next major release of Windows Phone are? Do you want to have the pride of working on the foundations of an Operating System that serves all other feature teams?





Même si j’ai pas le droit d’en parler ils sont beaucoup plus avancés que tu le penses. Si ça sortait dans trois ou cinq ans crois moi joe duffy et d’autres n’auraient jamais communiqué. Ils évitent ce genre de choses depuis Vista…



M# est dérivé de langages existants comme le sing# et le c# compile aussi directement avec le compilo m# d’après joe duffy. D’après ce que je sais il marche déjà.

Le 06/01/2014 à 21h 24

arno53 a écrit :



Les entreprises auront toujours besoin d’un OS pour la bureautique/développement/dessin. Je vois mal Microsoft laisser ce marcher à une distrib Linux …



Windows et Win32 peuvent encore durer 10 ans mais bon le petit noyau NT aimerait bien profiter de la retraite aussi " />



Et Terry Myerson (vu les papiers ecrit par thurrott) a l’air d’avoir une bonne vision pour l’avenir : 1 coeur, plusieurs interface adapté … Le fait de pouvoir faire prochainement tourner des applis WinRT sur le Bureau est de bonne augure pour un Midori Desktop.



Mais les devices connecté et les serveurs seront sans doutes leur priorité en effet.





Oui Terry Myerson a l’air d’avoir une bonne vision. Wait and see…

Le 06/01/2014 à 20h 55

brazomyna a écrit :



Pour le moment, rien ne permet de dire que la target principale serait le pc de bureau.



Au contraire, la tendance actuelle lourde c’est plutôt de voir sortir l’informatique de cet environnement traditionnel (cf. développement des mobiles, objets connectés, …). On cherche de plus en plus à intégrer de l’applicatif qui se complexifie dans des objets tiers (google car, google glass, jenesaisquoi).



J’aurais donc tendance à penser que ce système est justement prévu pour défricher de nouvelles contrées. Le gros refactoring de Windows depuis Vista jusqu’a win8 étant suffisant pour assurer l’évolution du desktop traditionnel pour au moins une décénie amha.





Oui tout a fait, je pense que windows reste trop gros pour certains appareils mobiles ou connectés. Et le fait d’avoir des applications .net en MSIL indépendants de l’architecture. (compilation en natif à l’installation ) est intéressant.



Par contre le desktop(c’est un souhait personnel j’en sais rien), j’espère qu’il ne mourra pas ou au moins que microsoft proposera toujours une interface adaptée à la souris et aux PC sur ce nouvel os.

Le 06/01/2014 à 20h 31

arno53 a écrit :



Si, si, Midori est codé a 99% en code managé à l’exception de la base mais verifié mathématiquement comme dit par Charon (comm n°19)



Sinon @PCI et surtout @P.A c’est normal de ne plus avoir les comm’s sur les archives ? Je pense notamment à ces news sur Singularity/Midori (ici, la, encore la et re-par ici) ? J’ai pourtant cru les avoir lu y’a une semaine ou 2 justement … Et Charon et Laere expliquait plutôt bien les principes mis en jeu … Ca serait dommage de perdre ces explications a jamais " />





Oui j’ai vu ça les vieux commentaires ont disparu " />

Le 06/01/2014 à 20h 14

francois-battail a écrit :



C’est inexact. Tu veux dire qu’il n’y pas besoin de transition Ring 3 -> Ring 0 pour des system calls et de séparation user / system. Néanmoins la commutation de contexte lors de l’ordonnancement des tâches est toujours d’actualité vu que j’imagine que c’est toujours un système préemptif et non pas coopératif.





Oui en effet désolé mal exprimé. par contre la gestion de la pagination mémoire n”utilise pas non le cpu. ce qui permet aussi de gagner en performance.

Le 06/01/2014 à 20h 04

francois-battail a écrit :



Il y a le mot « aggressively » qui laisse penser à une optimisation « on the edge » mais pour le moment on est en plein « vaporware » faute d’information détaillée.





un vaporware qui va sortir " /> , t’as lu la news?

Le 06/01/2014 à 19h 48

hadoken a écrit :



L’objectif de Windows (NT et Midori) n’a jamais été d’être embarqué dans un controller 8 bits. Bien évidemment que le C ne va pas mourir :)



En entreprise on se pose 2 questions principales pour choisir un langage de dév: 1) quelle(s) target(s) pour l’application 2) quelles compétences dans la team de dév



Et pour le 1), si la target c’est un microcontroller 8-bits où faut recoder l’intégralité des drivers pour gérer toutes les I/O, alors va pour le C ou l’ASM. Si la target c’est Windows, alors va pour .Net.





Tout a fait Midori est fait pour remplacer Windows pas tourner sur des micro controlleurs…..

Le 06/01/2014 à 19h 46

francois-battail a écrit :



Il y a le mot « aggressively » qui laisse penser à une optimisation « on the edge » mais pour le moment on est en plein « vaporware » faute d’information détaillée.





J’ai des contacts au sein de Microsoft. il y a des papiers internes qui circulent sur ce système. Je sais qu’il est globalement deux fois plus rapide que Windows voir plus. je sais que tu ne me croiras pas. Mais tout ce qui a été dit ici j’en parle depuis des années sur PCI. Et ce qui a été révélé soutient mes propos précédents sur le sujet.

Mais bon quand ça sortira j’imagine que certains continueront à renier la réalité….

Le 06/01/2014 à 19h 40

francois-battail a écrit :



Justement on est bien d’accord, je me place exclusivement dans l’optique système comme réaliser les changements de contexte, manipuler le hard, etc. Un langage managé est inutilisable en l’espèce et de plus des contraintes matérielles rendent impensables de devoir caser un framework de taille monstrueuse.





Tu devrais plus te renseigner sur singularity. Tout tourne en ring 0. les SIP qui sont des processus(ou drivers) sont isolés entre eux. Pas de chargement dynamique de code après l’execution. Le code est scellé au runtime. Bartok le compilateur ahead of time s’assure à la compilation en verifiant le code que les sip sont bien scellés.

Du coup l’isolation est assurée par le langage et pas par le processeur. Du coup tu n’as pas de context switch. Les api systèmes sont de simples routines d’appels. Tu peux aller jeter un oeil sur le site du msr il y a plein de papiers sur le sujet.

Mais Singularity règle élégamment le problème des contextes switch sur les micro noyau modernes. Ils ont même fait des benchs. les api systèmes sont bien plus rapides que la plupart des systèmes.



Singularity et Midori ont été conçus pour le code safe.

Le 06/01/2014 à 19h 30

francois-battail a écrit :



Merci d’avoir cité le passage sur le GC mais je le comprends comme une optimisation qui permet de déceler plus de cas ou la désallocation peut être automatique et implicite que comme un système véritablement déterministe (c’est à dire de pouvoir borner la consommation mémoire quel que soit la branche de code exécuté).

Et sinon pour le lifetime understanding il y a un vieux truc très utilisé en embarqué ça s’appelle un pool et là on est complètement déterministe.







This allows us to aggressively stack allocate objects, deterministically destruct, and more.



Ce que tu interprètes plutôt, il dit clairement que les destructions sont déterministes.

Le 06/01/2014 à 19h 04

francois-battail a écrit :



Je ne suis pas certain d’avoir lu le bon billet, mais le jour où ce sera conforme à DO-178A on aura l’occasion d’en reparler.







J’attends avec impatience du Midori sur des micro-contrôleurs 8 ou 16 bits… mais pour le moment le C et l’assembleur (et pas le C++) pour du système ça convient parfaitement, après utiliser une couche d’abstraction en managé pour une interface graphique et des APIs pourquoi pas mais là on est au niveau de l’applicatif.







Lifetime understanding. C++ has RAII, deterministic destruction, and efficient allocation of objects. C# and Java both coax developers into relying too heavily on the GC heap, and offers only “loose” support for deterministic destruction via IDisposable. Part of what my team does is regularly convert C# programs to this new language, and it’s not uncommon for us to encounter 30-50% time spent in GC. For servers, this kills throughput; for clients, it degrades the experience, by injecting latency into the interaction. We’ve stolen a page from C++ — in areas like rvalue references, move semantics, destruction, references / borrowing — and yet retained the necessary elements of safety, and merged them with ideas from functional languages. This allows us to aggressively stack allocate objects, deterministically destruct, and more.

Le 06/01/2014 à 18h 53

En fait la news en parle,c’est que j’avais prédis à l’époque dans le dossier sur Windows 8. WinRT a été conçu pour tourner au dessus de Midori.

Pour Win32 il y a drawbridge.

Le 06/01/2014 à 18h 50

127.0.0.1 a écrit :



Le 2, ca nécessiterait que Midori autorise l’accès a certains fichiers/sites et pas à d’autres pour chaque application. Un peu ce que fait SELinux…





Les applications seront surement sandboxes comme WinRT. Il ne sera pas possible de faire d’escalade de privileges vu que l’os sera safe donc on ne pourra pas exploiter de faille a ce dessein.

Le 06/01/2014 à 18h 45

127.0.0.1 a écrit :



hum… C’est pas si simple.



Faut différencier deux types de failles:

1. La faille du browser web qui permet d’exécuter du code arbitraire
   


2. La faille de l’OS qui permet à une application d’accéder à des ressources non-autorisées (API, fichiers, interfaces…)
   
   
   
   Pour le premier type de faille, il est vrai que du simple “bound-checking” éviterait beaucoup d’attaques par débordement de buffer. Mais pas besoin de créer un nouvel OS pour cela (même si c’est un moyen draconien).
   
   
   
   Pour le second type de faille, du tree-shaking empêcherait l’appli “vérolée” d’accéder a des API qui ne sont pas utilisées/autorisées. Mais un browser web utilise/autorise l’accès au API réseau, aux fichiers, … Donc ca n’empêcherai pas l’appli “vérolée” de voler/modifier des données, par exemple.
   
   
   
   Enfin bon, je suis impatient de voir ce que ca peut donner… Même si je suppose que l’adoption sur PC risque d’être freinée par l’obligation de renoncer à l’éco-système existant (sauf virtualisation/émulation).
   
   
   
   
   
   Effectivement le 1 sera réglé par le langage et le 2 par l’os (ce n’est plus windows le fonctionnement differe)

Le 06/01/2014 à 18h 41

francois-battail a écrit :



C’est vrai. Mettre un garbage collector dans un système élimine toute application temps réel vu que ce n’est plus déterministe, ensuite un langage managé est absolument inutilisable pour du code système vu que nécessairement il faut du « code sale » pour travailler au niveau du hard. Ce « code sale » (natif) sera signé Microsoft et enlèvera toute possibilité à des développeurs tiers de développer des choses un peu tricky sans passer par un circuit de certification Microsoft.

Ça fait plus de 25 ans que je vois passer des trucs où on cherche à protéger le système du développeur, quand - comme moi - on a fait pas mal de système il est difficile de prendre ça au sérieux.





Pour le gc tu devrais lire le billet de joe duffy ils ont fait un gc deterministe.

Pour le code natif restant et le fait qu’il ne peut pas etre prouve j’ai répondu dans mon commentaire précédent.

Le 06/01/2014 à 18h 37

brazomyna a écrit :



Le M# s’arrête forcément quelque part pour laisser la place à du code machine. La limite est encore floue.





Il n’y a pas que le “bound checking” qui définit les attributs d’un langage managé.





Je partage globalement cette vision des choses, car quelques pourcents de perfs, c’est quelques mois d’évolution de la puissance de traitement des puces. Un langage a une vision beaucoup plus long terme.





Midori est dérive du noyau Singularity. Le noyau est entièrement en code safe à part la HAL et le compilateur bartok intégré.

Mais il existait des projets a coté pour prouver le code natif sans bug avec boogie PL à base de preuves mathématiques.

http://www.blog.ma-config.com/index.php?post/2010/11/14/SafeOS:-un-OS-enti�%…

Le bound checking est généralement ce qui est repris le plus pour dire que les langages safes sont plus lents.

Le 06/01/2014 à 18h 33

Arnard a écrit :



" />

M# n’est pas un langage associé à Microsoft. M# n’est jamais mentionné dans le blog de Duffy !!

(uniquement dans les commentaires de mecs qui ont fait des associations de mots)

M# est développé par une société britannique et mis en œuvre pour la réalisation de sites web WikipediaCe langage n’a rien a voir avec M# qui est un projet de recherche interne a microsoft.

Le nom M# vient de cette offre d’emploi sur Midori:

Microsoft. All development is in M#, a C#-like language for writing asynchronous and parallel operating system components with strong guarantees of correctness.



Dans les commentaires ou les tweets d’aleks j’ai oublié ça été confirmé que M# était le nom de code de ce langage.

Le 06/01/2014 à 18h 28

hadoken a écrit :



Avant de critiquer il faut voir hein… De plus le managé peut être extrêmement puissant si la phase de compilation/optimisation est bien gérée. Sans compter que pour le coup, là c’est vraiment différent (no JIT). Et pour le GC, certes c’est quelques fois un vrai bottleneck, mais ils annoncent de gros progrès dessus.



Et mieux vaut sacrifier 2% de perfs et bénéficier de type et memory safety. Je dirais qu’au moins 80% des BSOD et un paquet de failles de sécurité viennent de leur absence.





Et je l’expliquais déjà à l’époque, joe duffy l’a confirmé, le compilateur effectue un maximum d’optimisations qui permettent de rattraper les pertes de perfs dues aux “bound checking”

Le 06/01/2014 à 18h 26

brazomyna a écrit :



Le gugus ne dit pas qu’il est utilisé pour le noyau, il dit que c’est le langage de référence pour l’écosystème autour de ce noyau.

‘





Si Midori est écrit avec M# d’ou le nom. Comme dit le titre c’est un langage système. il fait pour écrire des noyaux de systèmes,des drivers ou des serveurs.

Le 06/01/2014 à 18h 23

metaphore54 a écrit :



Je répondrais avant de mettre un " /> attendons que :





Tu crois qu’il va salir sa réputation en annonçant des trucs faux. De toute façon même quand ça sortira certains resteront toujours dans le deni….

Le 06/01/2014 à 18h 21

francois-battail a écrit :



" /> code système sous un langage managé le tout avec un garbage collector ! Le C n’est pas prêt de prendre sa retraite.

M c’est pour marronnier ? Le super langage qui va tout révolutionner c’est un peu lassant à force surtout quand ça prétend être en mesure de faire du système.





M comme Midori c’est un nom de code.

J’ai argumenté au dessus ce qui n’est pas ton cas . T’es surement plus intelligent que joe duffy.. Je ne pense pas que joe duffy aurait annoncé une telle chose si il n’y est pas effectivement arrivé. Comme expliqué au dessus Tout le monde vérifiera ses dires. il risque sa réputation de développeur.

Le 06/01/2014 à 17h 44

hadoken a écrit :



“The idea is that M# should be the lowest-level language that you’ll ever need. It sits at the very bottom of the stack. But it’s also safe and productive enough to be appropriate for writing higher-level systems, like Web services,”





Vivement " />





Il a les avantages des langages manages et les performances des langages natifs " />

Le 06/01/2014 à 17h 42

J’en avais parlé dans de précédents commentaires avec sr17 et harmattanblow.

Le M# est un langage derivé de c# qui est type et memory safe mais qui obtient les mêmes performances que le C++.



Joe duffy l’explique clairement. Les débats sur le sujet comparaient à l’implémentation actuelle du .NET. Mais ca ne marche pas du tout pareil. Joe duffy expose plusieurs points:



1)ce n’est pas de la compilation JIT mais un compilateur ahead of time. le codé est compilé directement en natif.



2)L’autre point débattu à l’époque c’était les mauvaises performances du garbage collector actuel. Visiblement ils ont travaillé dessus.



3)Le point majeur débattu: Avec des langages manages il y a une vérification des dépassement de tableaux par défaut pour éviter les buffer overflow. J’expliquais que ce serait largement compensé par de fortes optimisations avec le compilateur. C’est confirmé ici:





It is true that bounds checking is non-negotiable, and that we prefer overflow checking by default. It’s surprising what a good optimizing compiler can do here, versus JIT compiling.



Se renseigner aussi sur le tree shaking qui est une des optimisations importantes. Voir ici



De toute façon quand on voit le nombre de failles dans les navigateurs web par exemple ça prouve bien qu’on peut pas compter sur les développeurs pour éviter de pondre des failles.

1. un autre aspect qui n’a pas encore été abordé par joe duffy pour le moment ,ce langage a été conçu pour la programmation many core.
   
   
   
   Au final M# devrait bien obtenir les performances nécessaires pour la programmation système.
   
   
   
   Je finirai sur le fait que joe duffy l’a annoncé clairement qu’il est arrivé au but. C’est fort probable que des milliers de développeurs vérifieront ses propos.

Le 06/01/2014 à 12h 32

Annonce de la première beta de Midori " />





First, I heard from two of my contacts that Midori – Microsoft’s non-Windows-based operating-system project – moved into the Unified Operating System group under Executive Vice President Terry Myerson. (Before that, it was an incubation project, without a potential commercialization home inside the company.)

Le 02/01/2014 à 18h 22

TheDidouille a écrit :



Tout ce baratin pour rien… C’est amusant comment certains se monte la tête. Merci pour la barre de rire, commentaires presque aussi balaise que sur clubic (le passage AES… Dantesque ! ! Ça en dit long sur le niveau).





Baratin Pour rien? Tu croyais que joe duffy allait annoncer la sortie de midori avant que les dirigeants ms le décident. Ils le feront au dernier moment quand ils le décideront, surement pas sur un blog.

Ce n’est pas pour rien si tu lis la news de foley Midori a migré sur le groupe os unifié de terry myerson. Ce qui signifie que ça va sortir en produit final d’ici peu. Sans compter plusieurs personnes du groupe midori qui se sont mis à parler pour la première fois.

Le 31/12/2013 à 08h 15

Nyco87 a écrit :



Bon le monsieur veut casser toutes nos spéculations !





Reaction classique. sauf que Midori ne dépend plus du MSR. Ils n’ont pas intérêt à l’annoncer trop tôt non plus

Le 31/12/2013 à 07h 51

Nyco87 a écrit :



Bon pour wp8.1 c’est un peu foutu " />



Par contre pour la suite avec wp et windows RT… Tant qu’ils ne refont pas le coup de “changement de noyau, pas de mise à jour”.





Je pense que le jobs se referrait à wp9

Le 31/12/2013 à 07h 45

Nyco87 a écrit :



C’est peut-être trop tôt pour la Build 2014 mais peut-être pour 2015… Ou alors ça serait un big event si ça arrivait pour 2014… (remarque ça irait avec la rumeur que Threshold est un windows 9 et non un 8.2)





Pour L’unification foley avait raconté que pour l’unification il partait de windows phone pour ajouter de nouveaux features car il était plus petit. Vu le job que j’avais trouvé il y a des chances que le prochain windows phone tourne sur Midori.

Je doute fort qu’il fasse un travail d’une telle ampleur sans se baser sur Midori.

Le 31/12/2013 à 07h 34

Nyco87 a écrit :



En recoupant un peu toutes les informations que tu nous décryptes, et les futurs plan pour un système unique “cross-device”, même si c’est le noyau NT qui a été porté du téléphone à la Xbox en passant par les tablettes et le pc, ne serait-il pas possible d’envisager qu’au final, l’unification tant spéculé se fasse avec Midori et la fin de NT ?



Toutes les briques s’emboite bien dans cette idée : librairisation de win32, winRT type Safe, M#, et les trucs de compilation (j’ai oublié tous les noms de code je ne suis pas assez réveillé).



Et surtout, comme tu le dis, le fait qu’ils commences à parler de tout ça publiquement est un signe qu’ils approchent du but.





C’est fort probable

Le 30/12/2013 à 19h 13

metaphore54 a écrit :



Reste à voir ce qui va être fait de nos données personnelles, c’est là dessus que je suis méfiant.





Je pense qu’on gardera toujours un disques dur pour nos données privées.

microsoft n’est pas google. Après je prefère 10000 fois un cloud Midori qu’un cloud google.

Vu qu’il ne devrait plus être possible d’exploiter de failles sur les serveurs. Le seul risque restant ce sera la nsa " />

Le 30/12/2013 à 18h 50

metaphore54 a écrit :



Windows gratuit, je ne sais pas si c’est une bonne nouvelle ou pas. J’ai bien peur de la googlelisation du modèle écoomique de MS. " />





Pour Microsoft il peut espérer drainer plus d’utilisateurs rapidement sur son nouveau système.

Le 30/12/2013 à 18h 46

Tolor a écrit :



La question la plus intéressante, c’est s’il y aura toujours un intérêt à faire du C++ par rapport à du M# (en dehors des considérations d’habitude/environnement/…)





La portablité multi-plateforme je vois que ça (et encore ce n’est même pas sur on connait pas les plans ms la dessus )sinon en effet C et C++ n’ont plus d’intérêt. ca devrait être un langage killer….



Windows a toujours été C first langage.



Pour Midori ce sera plutôt M# first language.

Le 30/12/2013 à 17h 27

Dans le dossier sur Windows 8 j’avais expliqué que même si l’implémentation de WinRT dans Windows était native. Les api étaient type safe. On ne peux pas communiquer de pointeurs dans les api WinRT . J’avais expliqué qu’à l’époque le but final était surement de porter WinRT sur un os “safe”.



Même si l’application est écrite en c++, elle tournera dans une sandbox(géré par un os managé) avec des api managées.

Le 30/12/2013 à 17h 21

You can have a more reliable system, written in a better language, that still has the same application model.





Par rapport a ce que je disais sur le développement au niveau système et le développement au niveau applicatif, aleks bromfield qui a bossé sur midori le confirme sur un de ses tweets.



On pourra toujours coder en c++ sur WinRT. C’est juste le système et les drivers qui seront codes en M#

Le 30/12/2013 à 14h 36

arno53 a écrit :



Reste toujours la question de l’autorisation ou non du JIT pour les navigateurs Web …

Vu que ca a l’air bannie de l’OS, je me demande si Microsoft va s’autoriser ce droit comme sur Windows RT où si ils ont une autre solution à proposer …





Je n’ai jamais trouvé la réponse à cette question. Ils ont peut être une techno pour gérer ce cas. Mais là déjà joe duffy dit bien que la reflection classique ne marche pas. il faut passer par de la “compile time reflection”

Le 30/12/2013 à 14h 20

Le truc c’est que M# sera surement obligatoire pour coder au niveau système. J’en avais déjà parler. C/C++ ne sont pas des langages safes. La fiabilité et la sécurité dans Singularity et Midori nécessite un tel langage.

Par contre au niveau applicatif on devrait pouvoir utiliser le langage qu’on veut comme actuellement avec WinRT.

Le 31/12/2013 à 20h 39

sniperdc a écrit :



Bonne année PCI " />



Mais s’il vous plait pas de flat design " />





Globalement je n’aime pas non plus le flat design mais je pense que tu sous estimes mon graphiste(david), il serait capable de faire un truc énorme en flat design :)

Le 31/12/2013 à 20h 37

Bonne année à toute l’équipe et aux inpactiens " />