De toute façon il est plus que temps que cet OS crève, impossible d’exploiter les nouveaux outils et fonctionnalités tant qu’un tiers des clients restent collés sur les technos et API d’il y a vingt ans.
En tant que développeur je plussoie ,ça nivelle le niveau des applications par le bas. On ne peut pas utiliser les api plus récentes à cause du nombre encore trop important de XP sur le marché.
Le
17/01/2014 à
09h
24
mightmagic a écrit :
Vision à long terme, ça reste à voir.
Quand tu as une vision à long terme, tu empruntes un chemin précis ici c’est tout l’inverse.
.
La vision long terme a été expliquée plusieurs fois. Ils veulent une seule plateforme unifiée qui marche sur n’importe quel appareil connecté: pc,tablette,smartphone console et tous les autres appareils a venir(l’internet des choses). il suffit de voir les vidéos sur le futur publiées par Microsoft il y a quelques années.
Cette vision est censé être amenée au final par un nouveau système Midori.
Windows 8 s’approchait de cette vision mais ils ont fait une erreur de jugement en voulant imposer une orientation tactile sur tous les appareils. Au vu des dernières informations ce problème devrait se régler avec Windows 9. Il faut comprendre aussi que steven sinofsky a voulu tout miser sur le marché des tablettes pour tenter de conquérir le marché mobile ou Microsoft arrivait en retard. Mais il l’a fait au détriment du PC.
Microsoft a bien une vision long terme mais il l’affine sur le temps.
I was also given a case number in case I still want to swap it after the update. The Tech told me he was confident tomorrows firmware update would resolve the issues.
Le
15/01/2014 à
09h
49
J’ai des blèmes de veille depuis le début avec la surface 2 pro. Mais le dernier firmware ça a empiré. Visiblement Microsoft est en train de galérer…
Pour visual studio c’est pas le full screen le problème mais plus de vouloir l’adapter au tactile. Si on adapte un design au tactile ça signifie qu’on utilise de gros carrés ou de grosses zones adaptées au doigt.. ce genre d’interface comme photoshop intègre un très grand nombre de fonctionnalités. Ca passerait pas.
De plus je ne me vois pas bosser sur une tablette 10 pouces. Je travaille sur un gros écran. Faut pas déconner non plus " /> Et je ne parle pas du clavier. Même avec ma surface 2 pro et mon typecover je n’ai pas l’aisance de mon pc.
Le
13/01/2014 à
14h
35
gogo77 a écrit :
Vivement qu’il sorte ce Windows 9, que les gens aient un autre débat à se mettre sous la dent que celui de savoir si Modern UI est naze ou pas… Ça devient un poil ennuyant pour moi qui aime bien lire les commentaires de PCI " />
C’est vrai mais si les critiques ont permis d’améliorer l’ergonomie du prochain Windows je prends " />
Le
13/01/2014 à
14h
13
ArhK a écrit :
Perso je suis en dual screen, et je ne joue qu’en “windowed fullscreen”. Sur l’autre écran j’ai un chrome avec twitch.tv et des streams que je suis plus ou moins distraitement.
On peut utiliser Windows 8 comme ça ou pas ?
Multi screen c’est différent, je n’ai qu’un écran mais je crois que tu peux avoir une appli winrt sur un ecran et une autre sur l’autre ecran.
Je parlais des jeux WinRT. Même Win32 c’est rare qu’un joueur joue en fenêtré.
Le
13/01/2014 à
13h
23
127.0.0.1 a écrit :
Oui, là tu parles juste des modifications “techniquement” pour passer d’un mode de GUI à l’autre.
Mais, selon moi, il y a aussi une grosse différence dans les usages. ModernUI n’est pas juste pensé pour le tactile… mais aussi pour un fonctionnement multi-applications fullscreen. Alors que le desktop était surtout pensé pour un fonctionnement monoapplication multi-fenêtres.
" /> Ce n’est pas l’inverse. L’interface Modern UI permet de lancer une application à la fois, les autres sont suspendus.
Pour le desktop c’est du multitâche complet. Tu peux mater la tv et aller sur le web en même temps si tu veux.
EDIT: Par contre si Microsoft compte lancer plusieurs applications WinRT dans des fênêtres, j’imagine qu’ils devoir aussi modifier ce point.
Le
13/01/2014 à
12h
19
FunnyD a écrit :
Ben moi j’en utilise plein, pbon, principalement des petits jeux " />
Les jeux ce sont l’exception, tu joues rarement en fenêtré " />
Le
13/01/2014 à
12h
14
XalG a écrit :
Je pensais à 8.1, pour windows 9 il change effectivement de stratégie et ça semble bien plus prometteur.
Sur le plan technique ils misent toujours sur WinRT. Sur l’interface on peut le voir en effet comme un changement de stratégie
Le
13/01/2014 à
12h
09
XalG a écrit :
Bah si, les ventes sont nazes et Microsoft fait marche arrière sur plusieurs points " />
Je ne vois pas ça comme une marche arrière. Une marche arrière serait de revenir à Windows 7 et de remiser sur Win32. Pour moi ils affinent leur stratégie sur PC.
Le
13/01/2014 à
12h
01
Edtech a écrit :
Perso, j’en utilise pas mal, mais le gros problème c’est que tous les gros logiciels manquant à l’appel ! Les jeux pourraient s’y mettre sans problème par exemple. Quand je vois Project Spark qui tourne parfaitement par exemple, on se demande ce qu’attendent les développeurs ! (que 7 disparaisse peut-être !).
Un Visual Studio et un Photoshop ModernUI et le bureau deviendra presque invisible chez moi (Teamspeak aussi !).
Je pense que tu fais parti d’une minorité de gens. Tous ceux que je connaisse n’utilisent quasiment jamais d’applications Modern UI sur PC. Sur PCI on le voit d’ailleurs assez souvent.
Perso suis totalement allergique au plein écran WinRT sur PC.
Microsoft a d’ailleurs changé d’avis la dessus. Même si c’est un peu démago le client a toujours raison….
Le
13/01/2014 à
11h
53
Charly32 a écrit :
Un gros +1, ModerUI me sert uniquement de menu démarrer en plein écran en fait.
C’est bien le problème que j’exposais au dessus, les utilisateurs de Windows 8⁄8.1 sur PC n’utilisent jamais les applications Modern UI sur PC.
Le
13/01/2014 à
11h
44
127.0.0.1 a écrit :
Ce n’est pas juste un changement de look & feel. Ok, le changement de look & feel est sujet à polémique (moi le 1er je trouve que unifier les GUI tablette/laptop/desktop n’était pas une bonne idée)
Mais, comme le dit charon, le changement est aussi dans le runtime. Le changement n’est donc pas seulement du coté “utilisateur”, mais également du coté “développeur”.
En fait steven sinofsky pensait que le pc disparaitrait rapidement. Du coup il a tout misé sur les tablettes et il a ignoré les 1,5 milliards d’utilisateurs sur PC.
Steven sinofsky a imposé une ergonomie tactile pour tous les appareils.
Pour WinRT je ne pense pas que beaucoup de changements soient nécessaires. Il faudrait entre autre qu’un xaml soit ajouté pour les applications PC et qu’on puisse lancer les applis WinRT dans des fenêtres sur PC. Par contre les grosses modifications doivent être effectués sur le shell et l’interface elle même
Les rumeurs parlent de trois interfaces différentes(tactile/souris/voix) mais j’imagine que ce sera unifie sur un style graphique metro 2.0
Le
13/01/2014 à
11h
26
ALkyD a écrit :
Marrant, j’ai un clavier et une souris, et j’arrive… à utiliser Métro ! Comment ? Je déplace le curseur sur une tuile, je clique dessus, je défile le contenu avec la molette de la souris, j’appuie sur la touche Windows pour revenir au bureau…
Le système manque certes de cohérence mais il faut vraiment le vouloir pour ne pas réussir à utiliser Metro un minimum…
Au passage, y’a un Windows 7 encapsulé dans W8 avec le mode Bureau.
On peut utiliser Metro avec une souris et un clavier mais c’est quand même plus orienté tactile. Les gros carrés du start screen c’est pour le tactile(ce point ne me gène pas beaucoup personnellement). Ce qui gène surtout c’est qu’on ne puisse pas lancer d’applications Modern UI dans des fenêtres sur PC.
Le
13/01/2014 à
11h
22
Le gros problème sur 8 est que WinRT a été conçu surtout pour le tactile. Si les développeurs veulent faire des applications bureaux ils n’ont pas d’autre choix que d’utiliser Win32. Du coup toutes les nouveautés de la plateforme WinRT ne sont pas utilisées. Au final les utilisateurs sur PC n’utilisent jamais d’applications modern UI. Gros fail….
Par contre j’aime bien ce que compte proposer terry Myerson: Une interface différente pour chaque type d’appareil.
J’imagine qu’on pourrait avoir une nouvelle interface souris avec un style métro mais une ergonomie souris/clavier,
J’espère que ce Mini Start sera dégagé dans la version finale. Et davantage si c’est pour ravoir le style de Windows 7.
Je doute qu’ils remettent le menu démarrer de 7 en l’état. Par contre je vois mal Microsoft changer une chose de cette importance dans un update. A mon avis si ça sort effectivement dans cet update ça sera comme une option. Il y aussi ceux qui préfèrent le start screen qui raleraient…
Je pense qu’il faut que je précise les choses sur mes propos sur les performances. Je sens que ça va être détourné et mal interprété.
Ce sont des propos d’une de mes sources sur un papier qu’il a trouvé avec des benchmarks sur Midori. Mais il m’a juste donné une information globale. Il aurait été intéressant de savoir ce qui a été testé exactement.
Une personne plus haut a repris mes propos en expliquant que j’avais dit que M# serait deux fois plus rapide que c++. je n’ai jamais parlé du langage mais de l’OS.
De plus le résultat final peut encore changer. tout dépend comment ça va s’intégrer à Windows.
Mon propos était juste à titre informatif. Libre aux gens de me croire ou pas , je ne mens pas, je ne fais que reporter des propos.
PS: ceci dit il existe déjà un papier sur le site du MSR sur certains points qui sont testés sur Singularity comme les appels systèmes et c’est plutôt bon. Ou des tests avec la protection de ring cpu désactivé/activé et le MMU activé ou pas.
Le
08/01/2014 à
15h
19
Managed code -> Bytecode dans une machine virtuelle. Ce n’est pas du langage machine, c’est donc de l’interprété. Donc perte de performances.
rien que ça prouve que tu n’as rien compris au sujet. le bytecode intermédiaire est compilé en natif à l’installation. Tu n’as pas de runtime. C’est même le titre d’une présentation de james larus sur singularity
C’est pas du troll, c’est l’approbation de la démonstration de l’INpactien ; c’est positif comme attitude, non ? Promettre des performances en hausse sans preuve, ça c’est du troll.
C’est moi que tu traites de troll. J’ai des sources internes qui m’en ont parlé comme quoi Midori serait globalement deux fois plus rapide que Windows. Ce sont des benchs internes effectués par l”équipe de développeurs Midori. Effectivement je ne peux pas le prouver. Libre à toi de me croire ou pas. mais j’en fous un peu de ton opinion.
Surtout que tu me traites de trolls alors que toi pendant une période tu étais le troll numero un sur PCI. Les personnes qui étaient là doivent s’en souvenir. Moi je n’ai pas oublié. " />
Le
08/01/2014 à
14h
54
Actuellement Intel a une gamme de processeurs many core(TousLesDrivers fournit les drivers) en carte Pci Express je crois.
Je suis tombé sur cette news dernièrement où intel va bientôt sortir un vrai processeur manycore
A noter qu’intel a bossé en 2011 avec Microsoft sur le projet black cloud os. C’est un os dérivé de Singularity/Helios qui tourne sur leur gamme de processeurs many core.
Tout doucement on y arrive….
Le
08/01/2014 à
14h
04
charon.G a écrit :
CaptainDangeax tu te méprends sur le but de l’UAC. Microsoft a toujours dit que l’UAC n’était pas une barrière de sécurité contrairement à la sandbox des applications Windows Store.
Mark Russinovich l’avait clairement dit à l’époque de Vista. Le but de l’UAC était de forcer les développeurs à ne plus écrire d’applications qui demandent les droits administrateurs inutilement. L’UAC n’arrête pas les virus ou malwares. Par contre si les applications tournent avec des droits utilisateurs(stratégie réussie quand Windows 7 est sortie), ça diminue la portée des attaques en cas de faille, ce qui est déjà pas mal.
CaptainDangeax tu te méprends sur le but de l’UAC. Microsoft a toujours dit que l’UAC n’était pas une barrière de sécurité contrairement à la sandbox des applications Windows Store.
Mark Russinovich l’avait clairement dit à l’époque de Vista. Le but de l’UAC était de forcer les développeurs à ne plus écrire d’applications qui demandent les droits administrateurs inutilement. L’UAC n’arrête pas les virus ou malwares. Par contre si les applications tournent avec des droits utilisateurs(stratégie réussie quand Windows 7 est sortie), ça diminue la portée des attaques en cas de faille, ce qui est déjà pas mal.
Le
08/01/2014 à
11h
43
HarmattanBlow a écrit :
Non, s’ils faisaient ça il leur faudrait complètement réécrire les dll pour y ajouter des contrats et communiquer par message avec l’appli, ce qui serait désastreux pour les performances. On ne peut pas facilement séparer une dll pour la mettre dans son SIP.
En fait chaque application déclare à l’avance les dll qu’elle va consommer. Quand Midori charge l’application, il charge en même toutes les dll et c’est cette base de code unifiée qui est ensuite certifiée et fait l’objet d’un élagage (tree shaking / pruning).
Oui c’est le fonctionnement actuel de singularity les dépendances sont listées dans le manifeste et les dlls sont chargées au chargement de l’application.
Cependant felix a trouvé des choses sur ce qu’il appelle le fat binary avec project N.
Wait and see….
Le
08/01/2014 à
09h
26
A propos du tree shaking je voudrais relever un détail. Felix qui est une des sources actives de mary jo foley a analysé freshpaint sur Windows RT 8.1. Il a trouvé des réferences à project N. Il a aussi remarqué que tout le code est désormais dans un binaire. Ce serait une spécificité avec le tree shaking. Sur Singularity la notion de librairies ou de DLL changent déjà vu que les SIP sont isolées. Une DLL sur les systèmes actuels se chargent dans l’espace mémoire du processus et de façon dynamique pour certaines.Avec Singularity une dll devrait tourner dans son propre sip ou être fusionné au code du programme.
D’après les tweets de felix il semblerait qu’au niveau binaire le programme avec toutes ses librairies forment une seule entité. Ce qui permettrait normalement de rendre le tree shaking beaucoup plus efficace.
Oui, je suis le premier à dire qu’il y aura une perte.
Cela dit :
* La valeur de ces micro-optimisations est souvent surévaluée, de moins en moins significative, surtout par à la parallélisation, et les humains font aujourd’hui rarement mieux que les compilateurs (la vectorisation automatique devient aujourd’hui monnaie courante).
* Il y aura des gains par ailleurs : la suppression de la mémoire virtuelle c’est un gros cadeau pour les performances.
Effectivement dans les précédents débats j’expliquais que les pertes pouvaient être compensées par d’autres points.
Joe duffy explique bien dans son post que le compilateur effectue tout un tas d’optimisations poussées.
It’s commonly claimed that with type-safety comes an inherent loss of performance. 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
Il y en a une sur la quelle j’ai débattu sur twitter qui semblerait être aussi utilisée dans project N. C’est letree shaking:
Microsoftil y aussi le fait que M# devrait être conçu pour la programmation many core.
Le
08/01/2014 à
08h
37
Sebdraluorg a écrit :
Wep, j’ai bien lu ce que disait harmattanblow, mais visiblement quelques chose m’échappe… " />
J’ai pas lu le pdf du projet, mais tu dis qu’il passe de js à .Net, tu veux dire quoi au juste par .Net ?
Si tu peux aller de js vers .NET (et donc typé) il n’y a plus d’obstacle pour faire un “patch” à la volée, si ?
Par .net j’appelle le code CIL(pseudo code .net).
Faut que je relise mais une partie du code .net généré est converti en natif en compilation JIT par un runtime spécifique à l’éxécution. ce qui poserait problème.
Le
07/01/2014 à
19h
17
Sebdraluorg a écrit :
Si c’est convertible en .NET, c’est de fait convertible en langage intermédiaire pour Midori non ? A ce niveau ce n’est plus qu’une formalité il me semble…
Comme expliqué précédemment la compilation JIT n’est pas possible à la base sur Midori(enfin il doit exister une méthode mais elle n’est pas encore connue, harmattanblow a proposé quelques idées) parce que le code des SIP est scellé en mémoire à l’exécution.
Une partie du code .net généré par SPUR est crée en compilation JIT à l’exécution.
Le
07/01/2014 à
17h
04
Sinon pour le javascript il existe ce projet :
MicrosoftSPUR compile le code javascript en .net. Même si une partie utilise bartok c’est de la compilation JIT donc ça ne répond pas au problème posé avec midori.
Le
07/01/2014 à
15h
56
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.
je pense que j’ai donné pas mal de liens et de sources sur cette news. Je te réponds juste pour te dire que j’ai retrouvé le brevet en question:
Ce brevet parle d’une techno qui sert à faire communiquer du code unsafe avec des composants haut niveau en safe code de façon sure.
Le
07/01/2014 à
15h
48
HarmattanBlow a écrit :
Par contre le TAL m’inquiète un peu. Aujourd’hui le bytecode dotnet contraint tous les langages dotnet à se taper le même système rigide de types. Impossible de l’enrichir sans implémenter une infrastructure complète au-dessus de l’infrastructure, avec les performances que tu imagines (il suffit de voir F#). Je trouverais dommage que Midori nous enferme ainsi dans un système de typage trop cloisonné. Pour moi c’est le gros point noir.
Je sais déjà que WinRT a son propre système de type, qu’il lie à celui des langages dotnet. Ce que tu me dis me fait penser à un vieux brevet je suis en train de chercher mais pour le moment je ne retrouve pas le lien.
Le
07/01/2014 à
15h
19
HarmattanBlow a écrit :
Midori interdit la modification de l’espace de code par le processus lui-même parce que le processus ne serait plus vérifiable. Mais il y a une solution très simple : soumettre un flux TAL, vérifiable, au noyau. En effet l’ajout d’un code certifié ne peut logiquement pas compromettre la certification du code existant. Le noyau pourrait alors se charger de patcher un SIP existant ou de créer un SIP à la volée, puisque le coût de ces derniers est quasi-nul. Ce type de scénario est parfaitement envisageable.
A vrai dire les deux variantes seraient nécessaires pour un navigateur : un processus par page pour cloisonner les données, puis un patch à la volée parce qu’il n’est pas possible de compiler entièrement le javascript faute d’informations sur le typage, celui-ci n’étant entièrement connu qu’à l’exécution. Et comme il faut partager les données mieux vaut avoir un seul SIP par page plutôt qu’un SIP par fonction !
Pas con merci pour ta réponse " />
Le
07/01/2014 à
14h
41
HarmattanBlow a écrit :
Comme je l’ai dit dans un précédent message, par “certifier” ou “vérifier” on entend uniquement que :
* Le processus n’accède qu’à sa propre mémoire et n’écrit que dans sa propre zone de données.
* Le processus n’exécute aucune des instructions interdites.
Si je ne m’abuse ces deux conditions sont suffisantes et nécessaires pour une exécution en ring 0 sans compromettre la sécurité. Or on peut mettre au point des règles (un bytecode) qui rendent toujours vérifiables ces hypothèses. Et de là créer / adapter plusieurs langages pour les rendre vérifiables.
Quant à certifier le résultat, ça n’a pas d’intérêt pour le problème posé et ce serait effectivement équivalent au problème indécidable de l’arrêt.
Mais si c’est possible. ;)
La communication inter-processus est régulée par quelques contrats que les applications peuvent déclarer et souscrire. Ceux-ci sont définis de façon rigide en définissant toutes les étapes de la conversation et les données échangées à chaque étape, et le système peut vérifier que chacun implémente correctement sa part de la communication.
Le système est même, cadeau bonus non-nécessaire, capable de détecter les deadlocks dans la conversation, les cas non-couverts où l’interférence entre plusieurs applications afin de pouvoir signaler à l’utilisateur que telle application compromettra le fonctionnement de telle autre.
Concernant le débogueur, concrètement celui-ci exposera donc un contrat lui donnant accès à toute la mémoire du souscripteur et le compilateur insèrera en mode debug une souscription à ce contrat dans l’application générée.
Tant que c’est entre adultes consentants, tout est permis.
Tu ne penses pas que cette méthode pourrait être utilisée pour gérer la compilation JIT pour les navigateurs web par exemple? Le problème c’est qu’à la base c’est interdit par singularity et Midori. Mais j’imagine bien que Microsoft avait prévu un truc pour ce problème.
Le
07/01/2014 à
14h
18
Tout à fait : on vérifie en amont que tout le monde est honnête et du coup plus besoin de flics. Dit comme ça ça n’a pas l’air très sûr mais en fait ça l’est beaucoup plus que le système actuel.
Bien résumé c’est le principe de fonctionnement de singularity et Midori " />
Avec Windows on laisse faire et on tente de protéger les dégats avec plein de garde fous.
Avec Singularity/midori on établit les règles du départ. Du coup pas besoin de garde fous inutiles.
Le
07/01/2014 à
13h
42
moi1392 a écrit :
hheeuuu ???? depuis quand ?
Ça a déjà beaucoup plus de sens ! Donc en clair, pas d’isolation.
Maintenant la question qui fache… qui maitrise le compilateur ?
Si il y en a une vu que tout ce qui tourne en kernel mode est du code vérifiable.
Pour le compilateur il n’a pas besoin d’être trusté. Bartok avant de de générer du code natif génère du Typed Assembly language(TAL) , une sorte de pseudo code assembleur vérifiable. Le compilateur est compilé du TAL de mémoire.
L’isolation logicielle se fait au niveau du compilateur qui à la fin vérifie que le code généré soit bien vérifiable et qu’une adresse mémoire n’aille pas pointer sur un autre SIP.C’est une isolation par le langage. Harmattanblow a parlé plus haut de ce point.
Le
07/01/2014 à
13h
30
Kurian a écrit :
Ces SIP sont cencés êtres plus performants que l’utilisation du ring 3 des processeurs c’est ça ?
Oui l’isolation matérielle est beaucoup plus coûteuse en performances.
Ce sont les processus qui tournent sur les os Singularity/Midori. Mais les drivers tournent aussi dans des SIP.
Le
07/01/2014 à
13h
12
Kurian a écrit :
Que viens faire Roslyn dans l’histoire ? Juste un projet annexe ou c’est lié ?
quand Unix a été crée ils ont crée le langage C. Les nouveaux OS s’accompagnent généralement par des changements importants au niveau des compilateurs et des langages.
La on entend parler de roslyn ou project N et redhawk/MRT. A mon avis ça suit bien un but précis.
Le
07/01/2014 à
12h
59
Je pense que ce brevet de galen hunt devrait plus répondre à ta question:
Dans ce brevet Microsoft envisage d’utiliser les ring du cpu et donc l’isolation matérielle pour avoir la délimitation kernel/user mode. La différence par rapport à Windows est que les “process” qui tournent en kernel mode sont isolés logiciellement par des SIP.
C’est une sorte de compromis entre l’isolation matérielle et logicielle et ça devrait résoudre le problème que tu as mis en valeur plus haut.
Le
07/01/2014 à
12h
40
Les API, oui. C++ CX, non. Il n’est pas vérifiable. Il n’y a absolument aucune restriction sur les pointeurs ou les instructions utilisées, tu ne peux pas le faire tourner en ring0 car tu ne peux pas avoir la certitude que telle variable ne pointera pas vers une adresse du noyau au moment où elle sera écrite.
faudrait que je retrouve un vieux ppt mais ils ont incorporé plusieurs mot clés pour s’aligner sur les langages managés. mais disons que la tu es d’accord pour les api.
Pour ce que tu dis sur le ring0 je suis d’accord mais regarde ceci ça va répondre en partie à ta question je pense:
MicrosoftOur Kernel is a non-traditional design divided between a native C++ microKernel and additional managed C# operating system functionality which is injected into each independent hardware address space.
C’est ce que j’avais entendu parler il devrait y avoir un espace d’adressage mémoire indépendant pour le natif. Du coup il n’y aucun risque que l’appli native corrompt le système.
Mais j’ai pas toutes les informations en effet la dessus. Par contre tu ne penses pas que si Microsoft sort une nouvelle plateforme de dev alors que win32 a duré plus de 20 ans, il ne va pas la jeter 3 ou 5 ans après?
Mais arrête de m’insulter enfin !
Je me rappelle avoir discuté de nombreuses fois avec toi de ces sujets mais je ne me rappelle pas s’ils avaient été révélés par toi ni à quel moment par rapport aux autres, c’est aussi simple que ça et il n’est pas du tout étonnant que la chronologie exacte m’échappe des années plus tard.
Et j’ai été très surpris et choqué par tes réactions tout au long de ce sujet. Je suis venu pour une discussion technique sur un sujet qui m’intéresse et je me retrouve avec des approximations et un problème d’égo sorti de nulle part.
Ok tu as oublié pas de soucis désolé " />
Le
07/01/2014 à
12h
15
Tolor a écrit :
Ah ça oui, vous en avez débattu (et vous vous êtes battu " />) plein de fois tous les 2 de Midori " />
Merci de confirmer, Apparemment harmattanblow a certains problèmes de mémoire " />
Le
07/01/2014 à
12h
14
J’ai retrouvé ce lien interessant sur les types en c++/cx:
(For internal use only.) An unsigned 64-bit value that is used as a pointer.
IntPtr
(For internal use only.) A signed 64-bit value that is used as a pointer.
Ca explique bien ce que je disais plus haut, les pointeurs peuvent être utilisés uniquement en interne dans l’application. pas dans des api sinon une exception est déclenchée.(voir le lien avant)
Le
07/01/2014 à
11h
46
Vu qu’harmattanblow a des soucis de mémoire. Voilà une vieille offre d’emploi Microsoft dont nous avons débattu à l’époque:
Microsoftou will write code in a language like C# that has the performance characteristics of C++
mais bien sur il a oublié " />
Le
07/01/2014 à
11h
41
HarmattanBlow a écrit :
Je n’apprécie guère l’insinuation et je n’ai de toute façon jamais prétendu avoir révélé quelque exclusivité que ce soit ou avoir fait partie d’une sorte d’avant-garde. Je n’ai aucune source chez MS, je ne mène aucune investigation sur leurs projets, je n’ai jamais prétendu quoi que ce soit dans ce sens et ça ne m’intéresse absolument pas. Et si tu étais sans doute parmi les premiers à en parler, je n’en ai aucun souvenir. Mais pour ma part je te laisse bien volontiers le titre d’expert des arcanes de Microsoft.
En revanche les langages, architectures OS et matérielles, et les technos de développement m’intéressent et j’apporte souvent une lecture critique et un déchiffrage sur ces aspects précis.
Quelle mauvaise foi!! On en a débattu plein de fois sur plusieurs news.
Tu me décois " />
Le
07/01/2014 à
11h
39
HarmattanBlow a écrit :
Oui mais sandbox est un terme vague. A mon avis c’est quelque chose du type Wine avec en plus une émulation logicielle de certaines fonctionnalités du CPU (comme le MMU). Ou de la virtualisation.
Désolé mais ça n’a rien à voir. Pour commencer le commentaire montre simplement que ne peuvent être exportées de C++ vers C# que les API satisfaisant au dénominateur commun. C’est une simple question d’interopérabilité sans lien avec la sécurité.
.
Les api de WinRT sont safe pour prévoir une portabilité future sur Midori. Tu as lu le tweet d’aleks bromfield. Il est assez clair non?
HarmattanBlow a écrit :
Ensuite les applis WinRT sont des processus comme les autres, enveloppés dans la même sandbox que n’importe quel autre processus Windows. Simplement elles ont un peu moins de privilèges par défaut (et à cela se superpose un jeu de permissions spécifiques à WinRT gérées en mode utilisateur). Mais cette sandbox est assurée par le noyau de Windows depuis les années 90 via les mécanismes dont Midori devrait justement être débarrassé (mémoire virtuelle et anneaux de protection).
tu es en train de nous expliquer que Midori ne sera pas capable de sandboxer des applications, c’est çà? " />
HarmattanBlow a écrit :
Non il ne l’est pas. C++ CX ne fait qu’ajouter au C++ des mécanismes pour consommer les API WinRT. Il ne retire rien de ce qui fait l’invérifiabilité du C++. Notamment les pointeurs pseudonymes sont toujours possibles.
Une application WinRT est en C++ sur son code interne et en C++/CX pour l’appel aux api. Tu ne m’as pas compris ce que j’ai dit je pense. Le code interne à l’application n’est pas vérifiable effectivement . mais vu que les appels au système le sont et que l’“appli tourne dans une sandbox ca ne posera aucun problème.
Le
07/01/2014 à
11h
18
Jed08 a écrit :
Je te l’accorde qu’il y a beaucoup de : “je peux pas le dire” mais en règle général ses propos sont très techniques, cohérents et argumentés.
De plus certains de ses arguments sont vérifiés quelques mois plus tard par des gens de MS.
Bref, c’est pas le profil typique du fanboy
" />
d’ailleurs j”ai été un des premiers à parler de ce langage avant tout le monde. si harmattanblow est un minimum honnête intellectuellement il le confirmera.
Le
07/01/2014 à
11h
15
j’ai oublié de mentionner quelque chose il semble que harmattanblow n’a pas saisi ce point.
Quand on code en C++ sur WinRT ,le code qui appelle les api doit être en C++/CX qui est un safe langage. C’est ce que j’ai expliqué au dessus les appels aux api WinRT sont type et memory safe. Ce point et la sandbox sont suffisantes pour faire marcher une application C++ au dessus de Midori. pas besoin de VM.
2504 commentaires
Windows XP : un an supplémentaire de mises à jour pour Security Essentiels
16/01/2014
Le 17/01/2014 à 10h 07
Le 17/01/2014 à 09h 24
Patch Tuesday de Microsoft : pas de firmware corrigé pour Surface Pro 2
15/01/2014
Le 15/01/2014 à 19h 13
d’après un gars qui a eu le support ms le nouveau firmware pour la surface 2 pro pourrait sortir demain.
Wait and see…
I was also given a case number in case I still want to swap it after the update. The Tech told me he was confident tomorrows firmware update would resolve the issues.
Le 15/01/2014 à 09h 49
J’ai des blèmes de veille depuis le début avec la surface 2 pro. Mais le dernier firmware ça a empiré. Visiblement Microsoft est en train de galérer…
Windows 9, alias Threshold, pourrait sortir dès avril 2015
13/01/2014
Le 13/01/2014 à 16h 31
Pour visual studio c’est pas le full screen le problème mais plus de vouloir l’adapter au tactile. Si on adapte un design au tactile ça signifie qu’on utilise de gros carrés ou de grosses zones adaptées au doigt.. ce genre d’interface comme photoshop intègre un très grand nombre de fonctionnalités. Ca passerait pas.
" /> Et je ne parle pas du clavier. Même avec ma surface 2 pro et mon typecover je n’ai pas l’aisance de mon pc.
De plus je ne me vois pas bosser sur une tablette 10 pouces. Je travaille sur un gros écran. Faut pas déconner non plus
Le 13/01/2014 à 14h 35
Le 13/01/2014 à 14h 13
Le 13/01/2014 à 13h 23
Le 13/01/2014 à 12h 19
Le 13/01/2014 à 12h 14
Le 13/01/2014 à 12h 09
Le 13/01/2014 à 12h 01
Le 13/01/2014 à 11h 53
Le 13/01/2014 à 11h 44
Le 13/01/2014 à 11h 26
Le 13/01/2014 à 11h 22
Le gros problème sur 8 est que WinRT a été conçu surtout pour le tactile. Si les développeurs veulent faire des applications bureaux ils n’ont pas d’autre choix que d’utiliser Win32. Du coup toutes les nouveautés de la plateforme WinRT ne sont pas utilisées. Au final les utilisateurs sur PC n’utilisent jamais d’applications modern UI. Gros fail….
Par contre j’aime bien ce que compte proposer terry Myerson: Une interface différente pour chaque type d’appareil.
J’imagine qu’on pourrait avoir une nouvelle interface souris avec un style métro mais une ergonomie souris/clavier,
[MàJ] L’Update 1 de Windows 8.1 en test chez Microsoft, une sortie en mars
08/01/2014
Le 10/01/2014 à 15h 59
Le 10/01/2014 à 14h 14
Dans trois mois, Windows XP n’aura plus ni support ni Security Essentials
09/01/2014
Le 09/01/2014 à 10h 42
Ca va être la fête du malware
" />
Le système Midori de Microsoft se rapproche de sa phase commerciale
06/01/2014
Le 08/01/2014 à 15h 58
Je pense qu’il faut que je précise les choses sur mes propos sur les performances. Je sens que ça va être détourné et mal interprété.
Ce sont des propos d’une de mes sources sur un papier qu’il a trouvé avec des benchmarks sur Midori. Mais il m’a juste donné une information globale. Il aurait été intéressant de savoir ce qui a été testé exactement.
Une personne plus haut a repris mes propos en expliquant que j’avais dit que M# serait deux fois plus rapide que c++. je n’ai jamais parlé du langage mais de l’OS.
De plus le résultat final peut encore changer. tout dépend comment ça va s’intégrer à Windows.
Mon propos était juste à titre informatif. Libre aux gens de me croire ou pas , je ne mens pas, je ne fais que reporter des propos.
PS: ceci dit il existe déjà un papier sur le site du MSR sur certains points qui sont testés sur Singularity comme les appels systèmes et c’est plutôt bon. Ou des tests avec la protection de ring cpu désactivé/activé et le MMU activé ou pas.
Le 08/01/2014 à 15h 19
Managed code -> Bytecode dans une machine virtuelle. Ce n’est pas du langage machine, c’est donc de l’interprété. Donc perte de performances.
rien que ça prouve que tu n’as rien compris au sujet. le bytecode intermédiaire est compilé en natif à l’installation. Tu n’as pas de runtime. C’est même le titre d’une présentation de james larus sur singularity
C’est pas du troll, c’est l’approbation de la démonstration de l’INpactien ; c’est positif comme attitude, non ? Promettre des performances en hausse sans preuve, ça c’est du troll.
C’est moi que tu traites de troll. J’ai des sources internes qui m’en ont parlé comme quoi Midori serait globalement deux fois plus rapide que Windows. Ce sont des benchs internes effectués par l”équipe de développeurs Midori. Effectivement je ne peux pas le prouver. Libre à toi de me croire ou pas. mais j’en fous un peu de ton opinion.
Surtout que tu me traites de trolls alors que toi pendant une période tu étais le troll numero un sur PCI. Les personnes qui étaient là doivent s’en souvenir. Moi je n’ai pas oublié.
Le 08/01/2014 à 14h 54
Actuellement Intel a une gamme de processeurs many core(TousLesDrivers fournit les drivers) en carte Pci Express je crois.
Je suis tombé sur cette news dernièrement où intel va bientôt sortir un vrai processeur manycore
A noter qu’intel a bossé en 2011 avec Microsoft sur le projet black cloud os. C’est un os dérivé de Singularity/Helios qui tourne sur leur gamme de processeurs many core.
Tout doucement on y arrive….
Le 08/01/2014 à 14h 04
Le 08/01/2014 à 13h 54
CaptainDangeax tu te méprends sur le but de l’UAC. Microsoft a toujours dit que l’UAC n’était pas une barrière de sécurité contrairement à la sandbox des applications Windows Store.
Mark Russinovich l’avait clairement dit à l’époque de Vista. Le but de l’UAC était de forcer les développeurs à ne plus écrire d’applications qui demandent les droits administrateurs inutilement. L’UAC n’arrête pas les virus ou malwares. Par contre si les applications tournent avec des droits utilisateurs(stratégie réussie quand Windows 7 est sortie), ça diminue la portée des attaques en cas de faille, ce qui est déjà pas mal.
Le 08/01/2014 à 11h 43
Le 08/01/2014 à 09h 26
A propos du tree shaking je voudrais relever un détail. Felix qui est une des sources actives de mary jo foley a analysé freshpaint sur Windows RT 8.1. Il a trouvé des réferences à project N. Il a aussi remarqué que tout le code est désormais dans un binaire. Ce serait une spécificité avec le tree shaking. Sur Singularity la notion de librairies ou de DLL changent déjà vu que les SIP sont isolées. Une DLL sur les systèmes actuels se chargent dans l’espace mémoire du processus et de façon dynamique pour certaines.Avec Singularity une dll devrait tourner dans son propre sip ou être fusionné au code du programme.
Twitter
Twitter
Twitter
Twitter
Twitter
Twitter
D’après les tweets de felix il semblerait qu’au niveau binaire le programme avec toutes ses librairies forment une seule entité. Ce qui permettrait normalement de rendre le tree shaking beaucoup plus efficace.
Le 08/01/2014 à 08h 50
Oui, je suis le premier à dire qu’il y aura une perte.
Cela dit :
* La valeur de ces micro-optimisations est souvent surévaluée, de moins en moins significative, surtout par à la parallélisation, et les humains font aujourd’hui rarement mieux que les compilateurs (la vectorisation automatique devient aujourd’hui monnaie courante).
* Il y aura des gains par ailleurs : la suppression de la mémoire virtuelle c’est un gros cadeau pour les performances.
Effectivement dans les précédents débats j’expliquais que les pertes pouvaient être compensées par d’autres points.
Joe duffy explique bien dans son post que le compilateur effectue tout un tas d’optimisations poussées.
It’s commonly claimed that with type-safety comes an inherent loss of performance. 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
Il y en a une sur la quelle j’ai débattu sur twitter qui semblerait être aussi utilisée dans project N. C’est letree shaking:
Le 08/01/2014 à 08h 37
Le 07/01/2014 à 19h 17
Le 07/01/2014 à 17h 04
Sinon pour le javascript il existe ce projet :
MicrosoftSPUR compile le code javascript en .net. Même si une partie utilise bartok c’est de la compilation JIT donc ça ne répond pas au problème posé avec midori.
Le 07/01/2014 à 15h 56
Le 07/01/2014 à 15h 48
Le 07/01/2014 à 15h 19
Le 07/01/2014 à 14h 41
Le 07/01/2014 à 14h 18
Tout à fait : on vérifie en amont que tout le monde est honnête et du coup plus besoin de flics. Dit comme ça ça n’a pas l’air très sûr mais en fait ça l’est beaucoup plus que le système actuel.
Bien résumé c’est le principe de fonctionnement de singularity et Midori
Avec Windows on laisse faire et on tente de protéger les dégats avec plein de garde fous.
Avec Singularity/midori on établit les règles du départ. Du coup pas besoin de garde fous inutiles.
Le 07/01/2014 à 13h 42
Le 07/01/2014 à 13h 36
Le 07/01/2014 à 13h 34
L’isolation logicielle se fait au niveau du compilateur qui à la fin vérifie que le code généré soit bien vérifiable et qu’une adresse mémoire n’aille pas pointer sur un autre SIP.C’est une isolation par le langage. Harmattanblow a parlé plus haut de ce point.
Le 07/01/2014 à 13h 30
Le 07/01/2014 à 13h 21
Le 07/01/2014 à 13h 12
Le 07/01/2014 à 12h 59
Je pense que ce brevet de galen hunt devrait plus répondre à ta question:
http://www.freepatentsonline.com/7882317.pdf
Dans ce brevet Microsoft envisage d’utiliser les ring du cpu et donc l’isolation matérielle pour avoir la délimitation kernel/user mode. La différence par rapport à Windows est que les “process” qui tournent en kernel mode sont isolés logiciellement par des SIP.
C’est une sorte de compromis entre l’isolation matérielle et logicielle et ça devrait résoudre le problème que tu as mis en valeur plus haut.
Le 07/01/2014 à 12h 40
Les API, oui. C++ CX, non. Il n’est pas vérifiable. Il n’y a absolument aucune restriction sur les pointeurs ou les instructions utilisées, tu ne peux pas le faire tourner en ring0 car tu ne peux pas avoir la certitude que telle variable ne pointera pas vers une adresse du noyau au moment où elle sera écrite.
faudrait que je retrouve un vieux ppt mais ils ont incorporé plusieurs mot clés pour s’aligner sur les langages managés. mais disons que la tu es d’accord pour les api.
Pour ce que tu dis sur le ring0 je suis d’accord mais regarde ceci ça va répondre en partie à ta question je pense:
C’est ce que j’avais entendu parler il devrait y avoir un espace d’adressage mémoire indépendant pour le natif. Du coup il n’y aucun risque que l’appli native corrompt le système.
Mais j’ai pas toutes les informations en effet la dessus. Par contre tu ne penses pas que si Microsoft sort une nouvelle plateforme de dev alors que win32 a duré plus de 20 ans, il ne va pas la jeter 3 ou 5 ans après?
Mais arrête de m’insulter enfin !
Je me rappelle avoir discuté de nombreuses fois avec toi de ces sujets mais je ne me rappelle pas s’ils avaient été révélés par toi ni à quel moment par rapport aux autres, c’est aussi simple que ça et il n’est pas du tout étonnant que la chronologie exacte m’échappe des années plus tard.
Et j’ai été très surpris et choqué par tes réactions tout au long de ce sujet. Je suis venu pour une discussion technique sur un sujet qui m’intéresse et je me retrouve avec des approximations et un problème d’égo sorti de nulle part.
Ok tu as oublié pas de soucis désolé
Le 07/01/2014 à 12h 15
Le 07/01/2014 à 12h 14
J’ai retrouvé ce lien interessant sur les types en c++/cx:
MicrosoftUIntPtr
(For internal use only.) An unsigned 64-bit value that is used as a pointer.
IntPtr
(For internal use only.) A signed 64-bit value that is used as a pointer.
Ca explique bien ce que je disais plus haut, les pointeurs peuvent être utilisés uniquement en interne dans l’application. pas dans des api sinon une exception est déclenchée.(voir le lien avant)
Le 07/01/2014 à 11h 46
Vu qu’harmattanblow a des soucis de mémoire. Voilà une vieille offre d’emploi Microsoft dont nous avons débattu à l’époque:
Microsoftou will write code in a language like C# that has the performance characteristics of C++
" />
mais bien sur il a oublié
Le 07/01/2014 à 11h 41
Le 07/01/2014 à 11h 39
Le 07/01/2014 à 11h 18
Le 07/01/2014 à 11h 15
j’ai oublié de mentionner quelque chose il semble que harmattanblow n’a pas saisi ce point.
Quand on code en C++ sur WinRT ,le code qui appelle les api doit être en C++/CX qui est un safe langage. C’est ce que j’ai expliqué au dessus les appels aux api WinRT sont type et memory safe. Ce point et la sandbox sont suffisantes pour faire marcher une application C++ au dessus de Midori. pas besoin de VM.