votre avatar

charon.G

est avec nous depuis le 29 avril 2005 ❤️

2504 commentaires

Le 07/08/2014 à 09h 27

Avant Windows 9: c’est nul Microsoft n’intègre pas les bureaux virtuels sur Windows!!



Après Windows 9: Microsoft ce sont des nuls, les bureaux virtuels ça existe depuis 25 ans sous linux!!

<img data-src=" />

Le 06/08/2014 à 16h 56







arno53 a écrit :



Comme dit Bejarid …



A quoi bon mettre un menu démarrer & co sur Windows 8.x quand les gens se rappelleront que leur fils/neveu/voisin a dit y’a 9 mois que Windows 8 c’était de la merde …



Autant mettre toutes les ressources dispo sur Windows 9 avec pourquoi pas un maj gratuite ou peu chere pour les user de Windows 8 (voir de 7, Vista et XP pour certaines rumeurs)…



Les trolls et certains journalistes ont gagné … mieux vaut entamer une nouvelle guerre sur un nouveau terrain que sur ce champs plein de boue et de mine …





+1 c’est perdu en terme d’image pour Windows 8, ça sert à rien pour Microsoft d’insister dessus.


Le 06/08/2014 à 13h 33







jinge a écrit :



La génération du code est prise en charge par le .Net dans ses dernières versions il me semble, après la limitation provient peut être du sous-ensemble utilisé pour RT.

Enfin le travail n’est pas terminé, vivement qu’ils arrivent à une version plus proche de la définitive. Par contre on peut se demander ce qu’ils feront après, s’ils vont nous resortir un nouveau langage UI ou quoi ^^ Ils ont commencé par WPF, puis silverlight, puis silverlight WP, puis RT, tout ça en moins de 10 ans <img data-src=" />

Heureusement que la base .Net reste!





je pense que ce sera WinRT v2. Il a été conçu pour évoluer facilement.


Le 06/08/2014 à 11h 39







jmanici a écrit :



Oui. Mais il sera quand même supporté pour les professionnels pendant plusieurs décennies. Et Microsoft va même continuer à ajouter des fonctionnalités à win32/.net desktop pendant cette période de transition.





Une fois que midori sera sorti(surement pas dans dix ans avec satya qui veut réveiller Microsoft), je doute que win32 évolue. J’ai lu plusieurs offres d’emploi et papiers qui expliquent que win32 c’est mort pour le many core, il ne peut pas évoluer. ils sont obligés de passer à autre chose.

Pour beaucoup WinRT ce sont des sous applications mais bientôt ce sera le contraire les applications Win32 seront des sous applications.


Le 06/08/2014 à 10h 54

De plus si Microsoft autorisait les applications Win32 sur le store ça n’inciterait pas les développeurs à passer sur WinRT. Win32 est condamné à terme.

Le 06/08/2014 à 10h 46







jinge a écrit :



L’installeur n’est pas ce qu’il y a de plus compliqué à changer dans une appli, surtout si ça peut lui faire gagner en visibilité.

Bien entendu les anciennes applis ne seraient pas compatibles, bien entendu la sécurité n’est pas la même et bien entendu ça n’est pas pareil, mais ça a toujours été à mon avis le gros manque de windows (et windows mobile d’ailleurs): le manque d’un store.

Il existe un nombre impressionnant d’applis sous windows, mais on a accès à à peine 1% voire moins car le reste est caché, non disponible, etc. pour des raisons diverses, notamment la difficulté de monnayer son appli (j’ai moi même développé de très belles applis, qui sont restées confidentielles pour cette raison).

Un store pour les applis Win32 donnerait un nouvel élan à Windows à mon avis, même si c’est beaucoup plus dur à gérer que celui de RT. Mais en prélevant 20% du prix de commercialisation, MS se ferait beaucoup plus d’argent qu’avec son store RT à mon avis, et de l’autre coté, les devs auraient enfin une plateforme où être visible.





Pour moi proposer les applications win32 sur le store sans sandbox serait un pur massacre en terme de sécurité et ternirait fortement l’image du store Windows.

Donc soi ils arrivent à sandboxer Win32 ou ils comptent sur le succès futur de WinRT.


Le 06/08/2014 à 10h 41







Bill2 a écrit :



Quand on voit que certains galèrent à comprendre ce qu’est “le bureau”, qu’ils sont dépassés par le “bi écran”, alors avec des “bureaux virtuels” ça va être marrant :)



Surtout si chaque bureau ne peut pas avoir un wallpaper différent pour s’y retrouver <img data-src=" />



Alors, mon raccourcis, je l’ai mis sur l’écran de droite, sur le bureau virtuel numéro 4 … <img data-src=" /><img data-src=" />





Je pense que les noobs utiliseront l’interface tactile de 9 avec une tablette.

Microsoft est confronté depuis longtemps au fait que windows est utilisé à la fois par des noobs et des pros. Depuis un moment ils essayaient de simplifier l’interface Windows et cela a donné Windows 8.



Sur 9 il devrait y avoir deux interfaces: une pour la consommation de contenu adapté au grand public. Et une autre pour la production de contenu pour les pros et les geeks.



Le fait d’avoir deux interfaces règle beaucoup de problèmes.

ils peuvent ajouter de nouvelles fonctionnalités pour les pro et remettre celles que sinofsky a viré(les gadgets )



Vincent a écrit une news intéressante sur le sujet il y a quelque temps.


Le 06/08/2014 à 10h 29







jinge a écrit :



Oui et non car les capacités des applis RT et Win32 ne sont pas vraiment les mêmes… (déjà d’un point de vue isolation, les Win32 ne sont pas sandboxées et ont accès au système de fichiers, pratique pour dézipper… WinRAR qui est installé sur de très nombreux postes pourrait par exemple profiter du store pour se vendre 1€ au lieu d’être utilisé en version d’essai/piraté tout le temps)





Si tu ne peux pas installer des applications Win32 du store il y plusieurs raisons:



La première: pas de sandbox Win32. Ils ne peuvent pas assurer la sécurité des utilisateurs qui téléchargeraient ces applications.



La deuxième, sur le Desktop les technologies d’installations ne sont pas unifiés. Un simple exe peut servir d’installeur dans certains cas. Pour le store il faut une installation click once. Après ils pourraient porter appx sur desktop. Mais le store ne marcherait pas avec les applications legacy.


Le 06/08/2014 à 10h 13

c’est pas mal Microsoft devrait être plus réactif face à la concurrence.

Sinon certains vont être contents les bureaux virtuels arrivent sur Windows 9<img data-src=" />

Le 04/08/2014 à 12h 01







gokudomatic a écrit :



C’est vrai qu’il était très pénible, cet ada. Surtout que quand il y avait une erreur, c’était pas comme java. Il te dit rien sauf qu’il y a une erreur, débrouille-toi, il fait le strict minimum syndical.





C’est clair mais pour former les étudiants il y a pas mieux je trouve.


Le 04/08/2014 à 08h 42







lossendae a écrit :



PHP à bien changé depuis 7 ans.



Ceci dit, c’est aussi une volonté de la core team de ne pas inclure du typage fort.

Il y a eue plusieurs vote en ce sens (typage fort optionnel), tous ont été recalés.



C’est l’une des raisons pour laquelle Facebook à sorti son propre PHP (Hack)





Je codais en PHP il y a encore 3 ans. Et pour moi le typage faible de PHP c’est rédhibitoire. Au début des études informatiques on t’ explique systématiquement qu”‘un bon langage doit spécifier au maximum les types de données pour que la plupart des erreurs soient stoppées avant l’exécution. Dans mon cas les professeurs nous enseignaient le langage ADA qui doit être l’un des langages les plus restrictif.


Le 04/08/2014 à 08h 27







white_tentacle a écrit :



De même qu’il est présomptueux de se croire meilleur, il est aussi très dommage de se priver de toutes les évolutions qu’a connue le langage et ses bibliothèques depuis des années.



C++11 fournit plein d’outils pour se prémunir de ce genre de problème, et les techniques de programmation ont énormément évolué aussi. Il ne faut pas négliger que la plupart des buffer overflow qu’on trouve dans les OS viennent de code en C ou dans ce qu’on appelle couramment le C/C++, mélange infâme des deux langages qui est malheureusement ce qui est le plus couramment répandu.



Dans un code C++ moderne, il n’y a (presque) pas de pointeurs nus, pas de new et pas de delete. Les unique_ptr, array, vector et autres permettent de s’en passer, avec une sécurité grandement accrue.





Ecoute en fait j’ai envie de vous croire, ça me donne envie d’essayer de reprendre mon programme écrit actuellement en C++ pour éviter totalement l’utilisation de pointeurs. Par contre j’utilise beaucoup d’api systèmes manipulant des pointeurs et je manipule des structures systèmes ou je lis directement les bits à l’intérieur.

Je vais voir si il est réellement possible de s’en passer. <img data-src=" />

Pour les pointeurs intelligents je les utilisais déjà pour certaines classes.


Le 03/08/2014 à 18h 55







sr17 a écrit :



Il faut également ajouter que le C++ est un langage de programmation plus rigoureux grâce à son typage fort. Il est probable qu’au final ce langage enlèverait plus de problèmes de sécurité qu’il n’en apporterait. <img data-src=" />





Tu compares à PHP je suppose car c# utilise aussi un typage fort c’est d’ailleurs l’une des raisons principales pour lesquels j’ai laissé tombé PHP.


Le 03/08/2014 à 17h 40







Fnux a écrit :



Manifestement, il y en a qui aiment ça (le C ANSI 99 pur et dur) et qui s’en sortent très bien en utilisant les Dynamic xbuffers.



Maintenant, il y a aussi Javascript disponible côté client ET côté serveur (NodeJS) qui devrait aussi convenir à pas mal de gens.



Maintenant, c’est aussi une affaire de goûts personnels.





En effet, tu peux programmer en mode sur en c++ en gérant tes buffers en faisant gaffe à vérifier la taille de tes tableaux. Mais dans la réalité sur de gros projets tu vas manipuler des pointeurs à tout va avec des api systèmes ou d’autres bibliothèques qui manipulent systématiquement des pointeurs. hélas tu ne peux pas être sur de commettre quelques bugs. On trouve régulièrement des buffer overflow dans tous les OS, les navigateurs et la plupart des gros produits. Il serait présomptueux de croire être meilleur que les autres développeurs C++…


Le 03/08/2014 à 16h 53







warenbe a écrit :



pour revenir au sujet principal (PHP), je n’utilise plus PHP… j’ai un peu testé à une époque mais j’ai trouvé ça brouillon comme pas possible



j’ai appris à programmer en c# tout seul, et j’avoue que par confort je suis resté à ce langage en sortant de l’école. (d’ailleurs merci Fnux de m’avoir appris que je ne suis pas un vrai développeur)



mais alors PHP, je trouve ça imbutable: illisible rapidement, les méthodes n’ont aucune cohérence dans leur nom, je trouve que faire de l’objet est vraiment compliqué et merdique à souhait…

bref, j’espère que dans la prochaine version que je testerai si je peux je trouverai mon bonheur…

parce que du coup, ça me manque un peu parfois (car à coté php est très souple)





+1 perso j’ai utilisé php pendant 7 ans pour passer à C# et je ne regrette pas.

Pour le développement d’un site web en C/C++ c’est un peu une hérésie en terme de sécurité…

Je code depuis 15 ans en C++ pour de la programmation cliente ça me viendrait jamais à l’idée de coder en C++ sur serveur. Mais bon c’est vrai qu’il existe des dieux qui codent sans introduire aucun buffer overflow dans leur code <img data-src=" />


Le 01/08/2014 à 12h 51







arno53 a écrit :



Hong Kong non ?





A peu près sauf qu’il est en france <img data-src=" />


Le 01/08/2014 à 12h 37







arno53 a écrit :



Enfin l’inpactien Jmanici en parlera surement mieux <img data-src=" />





A cette heure là il doit pas être réveillé. Il ne vit pas au même fuseau horaire que nous <img data-src=" /> (julien <img data-src=" />)


Le 24/07/2014 à 10h 19







jmanici a écrit :



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



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



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



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

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





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







jmanici a écrit :



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





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







jmanici a écrit :



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



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





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

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

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


Le 24/07/2014 à 06h 57







arno53 a écrit :



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





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


Le 24/07/2014 à 06h 51







jmanici a écrit :



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



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



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



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





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

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



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



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

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



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

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



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


Le 23/07/2014 à 16h 31







Khalev a écrit :



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

Et pour corriger les failles aussi du coup.





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


Le 23/07/2014 à 11h 52







Firefly’ a écrit :



ça remplace une couche d’abstraction par une autre ça n’en rajoute pas..

Les amélioratons prévu pour DX12 ont justement pour but de réduire cette couche d’abstraction API/Materiel.



Ce nouveau framework sera à fortiori basé sur ce nouveau DX ( ou pas si c’est compatible win 8/.1 mais avec les rumeurs d’update gratuite tout ça ..) donc tant que rien est annoncé, difficile de leur lancer la pierre..



Concernant Midori, sans dire de bêtise , c’est pas du c#, mais un autre langage M# ( Tada on change une lettre ça change tout ! ), proche syntaxiquement certes, donc on ne peut pas se baser sur les perfs du c# pour dire si ça sera bien ou pas. Charon l’explique bien et en parle depuis plusieurs années.





Oui et midori c’est tout le contraire de rajouter des couches d’abstractions. ils reprennent de zero des concepts qui ont plus de 30 ans sur les OS. Et midori serait surtout beaucoup plus léger que windows.



Pour WinRT je me souviens qu’ils ont viré certains features de WPF comme les bitmap effect justement car elles n’étaient pas accélérés par le GPU. Après je doute que faire la même chose en GDI soit meilleur niveau performance et je ne parle même pas de la complexité du code.


Le 22/07/2014 à 16h 01







youtpout978 a écrit :



Par l’intermédiaire du JS ?





En interne tous les objets WinRT sont des objets COM+. Quand tu appelles une méthode WinRT. Tu vas au final appeler un objet COM+ par projection. Toutes les api WinRT sont référencées par du métadata WinMD. je t’invite à lire le dossier NXI sur Windows 8 tout est expliqué en détail.



source


Le 22/07/2014 à 15h 44







youtpout978 a écrit :



Ça revient à faire une espèce d’ASP pour du client lourd parce qu’actuellement ils se font pas chier les apps HTML/CSS/JS ne font que se lancer avec le moteur d’IE.





En fait pour WinRT comme l’a indiqué arno53 au dessus tu peux déjà coder un composant WinRT en C++ ou C# et un autre composant WinRT en HTML/JS/CSS et les faire communiquer ensemble.


Le 22/07/2014 à 15h 18







youtpout978 a écrit :



Comment gérer tout ce qui est binding et autre possibilité offerte par le xaml, à la fin on aura un html avec plein de nouveau attribut pas forcément compatible avec tous les navigateurs pour le coup.

Ou faudrait une classe intermédiaire qui s’occupe de faire ça mais ça ne ferait que complexifier les choses.

Je ne suis pas contre pouvoir faire du HTML/CSS pour faire des apps mais pas pour que ça remplace XAML, toute façon on aura surement la possibilité de faire ces apps en HTML/CSS/JS sur cette nouvelle UI.





Il ne s’agit pas de remplacer le XAML. Mais vu que le HTML/CSS est très répandu et marche partout, ça reste intéressant d’avoir les deux.

Perso avec ma-config.com j’utilise une séparation architecturale similaire depuis dix ans.


Le 22/07/2014 à 14h 57







youtpout978 a écrit :



Le xaml offre plus de possibilité que le couple HTML/CSS pourquoi alors utiliser une technologie faite pour le web même si au niveau syntaxe les 2 peuvent se ressembler.





Le seul avantage du HTML/CSS c’est que ça marche partout. Coder le moteur en C++/C# et l’interface en HTML/CSS est un bon compromis.


Le 22/07/2014 à 14h 39







Adrian Shephard a écrit :



Non en fait je retire ce qui serait vraiment bien c’est de pouvoir écrire des interfaces entièrement en html/javascript. Comme ça on pourrait utiliser les outils qu’on veut, que ça soit pour générer du html ou javascript, et arrêter de se demander à longueur de temps pour quelle plateforme on écrit.





Avec WinRT depuis 8 tu peux écrire une application entièrement en javascript/HTML5 si tu veux.

La version 2 de winJS est multiplateforme


Le 22/07/2014 à 14h 34







DDReaper a écrit :



C’est pas du tout la nouvelle interface mais juste une version de travail 1 an avant la sortie supposé.

Par exemple voila une image de windows 7 M1 datant de 2008 :

http://i1-news.softpedia-static.com/images/news2/Installing-Windows-7-Milestone-…





+1 les premières versions ressemblent toujours à l’os précédent. Ca devrait changer. Surtout que d’après des contacts de neowin, on verrait nettement la différence graphique entre 8 et 9. ils disent même qu’il y aurait plus de différences entre le bureau de 8 et 9 qu’entre le bureau de 7 et 8.


Le 20/07/2014 à 13h 58







JR Ewing a écrit :



tient! l’autre fanboy de MWP! <img data-src=" />



Evidemment que j’ai laissé toutes les options de sécurité activées! Tu me prends pour un quitouche de merde qui va désactiver le pare-feu et l’UAC sous prétexte que “ouais ça te bloquera plus, puis ça sert à rien ces machins”? <img data-src=" />







Arrête d’éssayer de dévier le débat, bien entendu que je parle du bureau, tout le monde ici aura compris, sauf toi qui cherche la petite bête! <img data-src=" />





Faudrait sérieusement que tu songes à être moins aggressif dans tes propos. Tu te plains régulièrement des trolls mais franchement tu ne fais pas mieux qu’eux… C’était une remarque anodine en rien une critique. Je ne t’ai à aucun moment manquer de respect. j’aimerai que ce soit le cas pour moi merci…


Le 17/07/2014 à 06h 20







JR Ewing a écrit :



euh… Non pas vraiment! Je dépanne souvent des PC sous Windows 8 qui sont infectés de virus et malwares en tout genre car les gens cliquent comme des cons sur toutes les banières qui passent et téléchargent donc les pourriciels censés “optimiser” leur PC. <img data-src=" /> Bref, Win 8 n’est pas mieux que les autres à ce niveau! <img data-src=" /> (bon, dans un sens tant mieux ça me donne du boulot! <img data-src=" /> )





Ca dépend de quelle version on parle. Sur Windows 8.1 pro les applications bureaux ne sont toujours pas sandboxées donc c’est pareil qu’avant je suis d’accord.



Sur Windows RT par contre ça change tout. Au pire tu peux avoir un malware dans l’application mais il ne pourra pas infecter autre chose que sa propre application. pour nettoyer il suffit juste de supprimer l’application. Pour les applications bureaux c’est nettement plus fastidieux à nettoyer.


Le 17/07/2014 à 06h 14







arno53 a écrit :



Je pensais plus à l’évolution de Windows RT/Windows Phone qui sera techniquement un Windows Phone mais avec le bureau XAML et les apps WinRT fenêtré. Il ne sera en effet pas compatible avec Win32 mais on aura au moins un vrai clone de ChromeOS sur le plan de la sécurité, de l’espace de stockage et des applications sandboxé pensé pour le clavier/souris.



Après oui les PC qui garderont la compatibilité Win32 auront toujours les meme inconvénient/avantages qu’un Windows 8 actuel …



HS : Ah et j’ai réinitialisé mon mot de passe sur le forum et j’ai maintenant re-accès à la messagerie privée de NXI





Oui sur les version adaptées au dessus de Windows phone l’espace disque devrait baisser drastiquement <img data-src=" />


Le 16/07/2014 à 15h 56







arno53 a écrit :



Alors autant sur des engins à 200/250€ c’est nécessaire (coté tablette aussi pour concurrencer la Nexus 7 & co) autant un PC/tablette à 99€ ça va être catastrophique et donner une super mauvaise image de l’OS … Surtout que pour l’instant c’est encore Windows 8 / Windows RT et donc un espace de stockage assez limité …



Faudra vraiment attendre Windows 9 pour avoir un vrai concurrent en terme de sécurité/ergonomie/fonctionnalité à ChromeOS





Je ne pense pas que 9 changera grand chose la dessus. Windows est gros à cause de la compatibilité. A moins que 9 soit une rupture totale(je doute la dessus), windows 9 devrait utiliser quasiment autant d’espace disque que 8. il y aura surement quelques optimisations mais je doute qu’ils fassent des miracles sur ce point précis.


Le 19/07/2014 à 18h 55







Konrad a écrit :



OK, Dell fait fort, ils fournissent une 8” sous Windows 8 pour 250 € (200 € avec remise si j’ai bien compris).



Lenovo pratique donc des tarifs prohibitifs sur ses tablettes Windows, c’est la seule conclusion possible.



Chez ASUS on trouve une tablette 8” sous Android, avec 2 Go de RAM, un SSD de 32 Go, pour 190 € chez RDC par exemple. Il n’y a donc plus que la différence de prix entre les deux CPU (Atom/ARM) entre les deux tablettes.



Maintenant, on trouve des tablettes Android avec des specs moindres : 1 Go de RAM et un SSD de 16 Go, ce qui donne des tablettes encore moins chères. Pourquoi n’est-ce pas le cas du côté de Windows 8 ? Est-ce une volonté politique de Microsoft, ou est-ce que Windows 8 ne tournerait tout simplement pas (j’ai lu que le système prenait dans les 20 Go donc un SSD de 16 Go semble hors de question).





Windows 8 n’a jamais pris dans les 20Go. plus dans les 12Go(il faut aussi compter le fichier d’hibernation dont la taille dépend de la quantité de ram). Ensuite sur Windows 8 update 1 ils ont introduit un mécanisme pour utiliser directement les fichiers WIM d’installation et les décompresser à la volée. Avec cette technique ils arrivent à 4go. Par contre j’émets des doutes sur des possibles problèmes de performance liée à la décompression sur du matériel bas de gamme.



Et comme l’a indiqué bejarid plus haut,au vu des rumeurs(foley en a aussi parlé) microsoft pourrait repartir sur une base Windows phone pour Windows 9. Et Windows Phone est beaucoup plus léger que Windows RT


Le 19/07/2014 à 18h 13







Bejarid a écrit :



Pas vraiment non, le bureau devient très utile des lors que tu branche un écran et une souris.



Clairemlent WinRT est en train d’être enterré par tout le monde, et rien n’indique pour l’instant que MS travail à une version RT de Win9.





En fait la version basique de Windows 9 devrait être similaire à Windows RT sauf qu’elle ne serait plus limitée aux seules architectures ARM. De plus pour les tablettes il ne devrait plus y avoir de bureau et donc plus du tout de compatibilité Win32. Windows RT ne fait déjà pas marcher les applications bureau non microsoft mais il intègre quand même Win32 pour faire tourner office.


Le 18/07/2014 à 12h 17







jinge a écrit :



Hum, pour le premier point, faire marcher les applis WinRT sur iOS et Android, je pense que Nokia X était un bon terrain de jeu pour tester justement

Pour le chemin inverse, je ne suis pas sûr que MS y ait vraiment intérêt, car je pense qu’ils préfèrent pousser .Net et l’environnement de dev MS… Et en plus les devs pousseraient du coup beaucoup plus leurs applis android (donc optimisées pour android) avec emulation sur WP, ce qui entrainerait que les applis sur WP seraient toujours de moindre qualité…





C’est vrai mais hélas ce que je pense ce qu’ils vont faire n’est pas forcément en accord avec ce que j’aimerais qu’ils fassent. j’attends de voir ce que satya va faire….


Le 17/07/2014 à 18h 47







pilote91 a écrit :



Os/2, c’était IBM (même si développé en grande partie par MS, mais pour le compte d’IBM et sur cahier des charges IBM -même si MS n’a pas forcement respecté le dit cahier des charges et beaucoup utilisé les fonds du développement d’Os/2 pour developper Windows et NT, c’est d’ailleurs la cause de la fin des accords entre IBM et µ$). <img data-src=" />





Je n’ai pas dit le contraire. Je me suis mal exprimé je pense. J’expliquais que NT supportait aussi la compatibilité des applications os/2


Le 17/07/2014 à 17h 38







arno53 a écrit :



Mais justement OS/2 faisait tourner ses app + celle du concurrent DOS.

Microsoft voudrait faire tourner ses apps WinRT + celle du concurrent Android …



A l’époque les devs ne se sont pas fait chier et ont pris le plus grand dénominateur commun, c’était DOS.

Aujourd’hui le plus grand dénominateur commun c’est Android pas les 3 apps WinRT qui se battent en duel dans le store <img data-src=" />



Axé sur Xamarin est bien plus intelligent …



Lien intéressant sur OS/2





Nt intégrait un sous système OS/2, Ce qui a fait la différence c’était les outils de de développement. Voilà pourquoi je pense qu’il faut faire les deux et pas juste un.


Le 17/07/2014 à 17h 29







arno53 a écrit :



Cette possibilité de faire tourner les apps Android dans Windows via Drawbridge est vraiment à double tranchant … Certes ça peut permettre a plus de gens de switcher vers WP mais ça peut surtout inciter les devs à ne rien faire pour l’environnement WinRT <img data-src=" />



Je serais MS j’axerai tout sur Xamarin, les apps universelle iOS/Android/WP/PC et si vraiment ca suffit pas a attirer les devs vers le C#, je utiliserai Drawbridge-Android que plusieurs années après comme plan Z <img data-src=" />





En fait Microsoft l’avait fait avec os/2 on sait ce qui est arrivé à os/2.


Le 17/07/2014 à 16h 48







jinge a écrit :



Moi je trouve ça très dommage. Je veux bien que niveau cohérence c’est plus logique, mais ça donnait aussi une bonne base pour développer le cross-plateforme… Ca veut aussi dire que les applis développées pour ça vont partir aux oubliettes.

Je trouvais le projet intéressant pour s’immerger dans le monde de MS sans pour autant y entrer complètement: un premier pas.

J’aurais bien essayé un Nokia X (bien que les specs soient vraiment bas de gamme), et à la limite pris un pour le dev puisqu’ils ne sont pas cher.



Après c’est une stratégie, mais ils auraient aussi bien fait de revendre cette partie de la boite en en gardant une bonne participation (Nokia X + Asha) plutôt que de tout fermer, ça aurait permis de pousser dans leur sens en cas de succès.

Je trouve ça vraiment dommage, mais c’est pas moi le chef :)





je pense que la façon d’aborder android avec nokia X était mauvaise. Je pense plutôt qu’ils ont d’autres idées bien meilleures dans la tête.



Nadella ne fait que répéter qu’il veut voir marcher ses applications et services partout.

Je vois deux axes principaux qui vont ensemble.



*Faire marcher les applications WinRT sur IOS et android



*et peut être carrément supporté la compatibilité des applications android dans Windows(avec drawbridge par exemple). Il y a des rumeurs persistantes sur le sujet depuis un moment.



Si ils font ces deux choses ça pousserait les développeurs à porter leurs applications sur WinRT vu qu’elles marcheraient à la fois sur smartphone tablette,PC mais aussi android et IOS.


Le 17/07/2014 à 16h 10

ca manquera à personne je pense <img data-src=" />

Le 14/07/2014 à 15h 47







teddyalbina a écrit :



Rien que le noyau Windows c’est pas loin de 50 millions de lignes de code. Vista faisait 6 milliards de ligne. Avec les réécritures qu’ils font depuis plusieurs année on a beaucoup moins de problème. En l’occurrence pour ce bulletin il s’agit vraisemblablement d’une faille croisée.



Le principale problème des OS est la mémoire partagée :s





C’est faux 50 millions de lignes de code c’était vista tout entier. Le noyau fait environ 1 Mo il fait pas 50 millions de lignes de code c’est exagéré.

Après oui dans 50 millions de lignes de code il y a énormément de failles potentielles.


Le 13/07/2014 à 13h 56

C’est pas étonnant j’en ai parlé avec des collègues qui tiennent des gros sites français. Cette année les revenus de publicité ont bien diminué. Ils licencient en masse dans les régies publicitaires et plusieurs sites webs :(



D’après ce que j’ai compris c’est le marché informatique qui est morose ajouté à la crise. Les constructeurs ont réduit drastiquement leur budget pub.

J’espère bien que l’année prochaine sera meilleure pour NXI :)

Le 11/07/2014 à 16h 15







yl a écrit :



Transformer un OS en machine a dérouler du bytecode, afin d’avoir un max de réutilisation entre plateformes, cela n’a jamais été optimal. C’est juste lourd, à tout points de vue. Je sais bien que mémoire/processeurs permettent d’empiler les couches sans trop affecter l’expérience utilisateur, mais j”aime pas le gâchis! <img data-src=" />





<img data-src=" />

La compatibilité des applications du store entre les plateformes n’est pas binaire. Enfin seulement pour les applications écrites en .net ou javascript.

Beaucoup d’applications WinRT restent écrites en C++. (je sais que beaucoup de gens ici sont persuadés que WinRT==.NET <img data-src=" />)

La compatibilité elle est au niveau des api.

pour les performances vu que Windows 7 était plus rapide que Vista et 8 plus rapide que 7. Il y a des chances pour que Microsoft optimise un peu plus pour windows 9.


Le 11/07/2014 à 15h 14







cosmocat a écrit :



Écrire une telle news sans même évoquer docker, LA solution de conteneurisation qui explose en ce moment est une gageur. Alors que libswarm a été lancé par la boite derrière docker.



Étant développeur .net, docker est une technologie qui fait rêver mais qui est malheureusement incompatible avec l’ecosystème windows.

Et chaque jour je m’en mort les doigts :(

Microsoft avec une telle techno vient de se prendre une claque technologique :(





Tu as Drawbridgequi va bien plus loin. Ca ne devrait pas tarder à sortir à mon avis vu que Windows 8.1 intègre un dll pour communiquer avec les picoprocess utilisés dans drawbridge.



Sinon j’ai vu passé une news il y a quelque temps ils bossent aussi sur des solutions d’interopérabilité entre .NET et docker.


Le 09/07/2014 à 19h 31

J’en ai parlé aussi en détail dans le dossier windows 8 sur NXI

Le 09/07/2014 à 15h 11







athlon64 a écrit :



Ok, je n’avais pas compris <img data-src=" />



L’avantage de la veille prolongée c’est justement de pouvoir reprendre le travail tout de suite





Oui sauf que l’hibernation classique écrit un plus gros fichier sur le disque à l’extinction. Sur Windows 8 il écrit que le système. C’est pour cela que je disais plus haut que c’est une sorte de compromis.


Le 09/07/2014 à 15h 05







athlon64 a écrit :



Quand je démarre le PC après la veille prolongée, j’arrive sur l’écran de sélection de l’utilisateur (pas de mdp donc directement la touchée Entrée) et j’arrive ensuite sur mon bureau avec toujours les fenetres que j’avais ouvertes avant la mise en veille prolongée





Je parlais du fonctionnement de Windows 8. Windows 7 tu récupères toutes tes applications dans l’état ou tu l’as laissé.

Sur Windows 8 tu ouvres la session et ça fait comme un démarrage standard.



L’intérêt de mettre en hibernation seulement le système,ça permet de diminuer la taille du fichier d’hibernation. Du coup l’extinction reste assez rapide.


Le 09/07/2014 à 13h 10







athlon64 a écrit :



C’est pas similaire a la veille prolongée dispo sous Windows 7 ? Ca met la RAM sur le HDD et dès que tu rallumes ca renvoie tout





En fait seulement le système est mis en hibernation. Quand tu démarres ça reprend de l’hibernation. Puis ça démarre la session utilisateur normalement.

C’est une sorte de compromis.

Sur Windows 7 il met tout en hibernation même la session utilisateur.


Le 09/07/2014 à 19h 16







Konrad a écrit :



On peut apprécier le flat design sur smartphone/tablette (Android, iOS, Windows Phone…), et le détester sur son PC de bureau (Windows 8), ça n’a rien de paradoxal.



On peut aussi aimer les deux. Bref tous les goûts sont dans la nature, rien ne sert de traiter son prochain d’attardé…





Tu sais que le flat design n’a rien à voir avec le type de device. Microsoft a sorti une implémentation particulière avec Modern UI plutôt adaptée pour les tablettes /smartphones mais tu peux très bien avoir du flat design pour PC.



Je te montre juste un concept de desktop qui prouve que le flat design pourrait aussi être beau sur PC. theverge.com The VergeLes gens qui critiquent Modern UI à 95% ne le font pas sur le design en lui même mais plus sur l’ergonomie, comme le full screen imposé sur les applications Modern UI ou les gros carrés conçus plutôt pour un usage tactile que pour un PC.



D’ailleurs Microsoft devrait sortir un métro 2.0 pour PC avec Windows 9. Je pense que le flat design peut très bien recevoir un bon accueil si il est bien adapté en terme d’ergonomie.


Le 04/07/2014 à 18h 22







wagaf a écrit :



Le problème c’est qu’on entend ça pour chaque version de Windows sans exception : “ok la version actuelle est moisie mais ça va être réglé dans la prochaine version, c’est Microsoft qui l’a dit !”.



Bien entendu, 6 mois après la sortie, MS commence à créer du buzz pour la version N+1, histoire de faire oublier les critiques de la version actuelle et pour faire rêver les fans. La version anciennement défendue bec et ongles est soudainement admise comme étant moisie, mais c’est pas grave, la prochaine sortira bientôt… <img data-src=" />





Windows 7 a bien fonctionné en part de marché. Pour Windows 8 il a apporte pas mal de choses mais à mon sens ils se sont viandé sur la version PC. Personnellement j’ai évoqué plusieurs de ses défauts avant la sortie de Windows 8. Plusieurs de mes arguments ont été ensuite repris par certaines personnes <img data-src=" />