Le 31/05/2016 à 08h 17

Relis bien mes précédents propos tu te méprends, pour gérer les chemins de plus de 260 caractères les api unicode ne sont pas suffisantes. Il faut aussi placer un préfixe \?\ devant le path. Je t’invite à lire la doc msdn sur le sujet. Si tu lis les autres liens, Win32 filtre bien les path si tu ne mets pas le préfixe. Donc c’est bien une limitation Win32…

MicrosoftIn the ANSI version of this function, the name is limited to MAX_PATH characters. To extend this limit to 32,767 wide characters, call the Unicode version of the function and prepend “\?\” to the path.

catseye a écrit :



Le manifest n’existe pas pour les anciennes applications, tu n’as aucune idée de laquelle supporte quoi, donc t’es exactement de retour à la case départ.







Pour le manifeste tu peux en mettre un dans les ressources de l’application depuis Windows XP. Je le fais moi même depuis longtemps dans mes applications. C’est d’ailleurs la méthode utilisée pour activer la dernière version ComCtl32 ou sur vista déclarer l’admin UAC.



Microsoftcatseye a écrit :



Microsoft aurait du faire un changement radical quitte à mettre par terre un paquet d’application.





Vista ne ne t’as pas suffit? Microsoft ne sera jamais prêt à lâcher la compatibilité Win32. D’ailleurs toute leur stratégie d”unification Windows repose sur le succès de la version desktop et de sa compatibilité Win32 même si elle accumule une grosse dette technique.

Je peux te dire que si Microsoft appliquait ton conseil il y aurait une énorme levée de boucliers autant du côté des utilisateurs que des entreprises qui réclament un support de plus en plus long.

Le 31/05/2016 à 07h 38

Microsoft aurait du faire un changement radical quitte à mettre par terre un paquet d’application.



Vista ne t’a pas suffit…

Si Microsoft cherche à préserver la compatibilité de Win32 ce n’est pas pour rien…

Le 29/05/2016 à 08h 27

Pour ceux qui pensent que ce n’est pas une limitation de Win32. ce que je vais dire parait évident mais apparemment pas. Vu que les chemins dépassants 260 caractères sont bloqués par défaut dans l’implémentation Win32 des api sur les fichiers. Par définition c’est bien une limitation Win32….

Le 29/05/2016 à 08h 06

catseye a écrit :



Cette limitation n’existe pas au niveau Win32.

…





Bien sur que c’est une limitation win32 vu que ce n’est pas le fonctionnement par défaut pour l’ensemble des api win32 relatifs aux fichiers. Si tu veux utiliser des chemins long tu dois obligatoirement utiliser des api unicode et surtout mettre le prefixe \?\ devant le path.

Vu que j’utilise un préfixe très semblable pour interroger mon driver j’imagine bien que cela permet d’accéder au namespace NT.







catseye a écrit :



Heuu non, y a aucun cas où ça posait un problème … ils ont juste traîné des pieds, et ils ont complètement foiré pour .Net, parce que seulement une partie de .Net accepte les long path et bizarrement pas tous les objets/fonctions.



Y a rien qui les empêchait d’ouvrir des path de MAX_PATH de long dans les anciennes applications, puisque c’est beaucoup plus petit que la limite réelle. C’est dans l’autre sens que ça aurait été un problème.



Rien n’aurait empêché non plus de virer cette limite de 260 chars, et dans le mode ‘compatibilité’ de la remettre pour les applications récalcitrantes. Franchement: no excuse.

Il auraient pu faire un truc encore plus fort, regarder si le binaire des exécutable ont été buildés avant la sortie de Vista par exemple, si oui: limite à 260 chars et mode compatibilité par défaut à ON pour eux seulement, pour les autres assumer qu’ils sont bien programmés. Bref les solutions existaient depuis longtemps.





Bon alors déjà je voudrais mettre au clair mes propos. j’en ai plein le cul qu’on me prête des intentions que je n’ai pas. Je le répète et j’ai bien dis : Microsoft n’a pas d’excuses de ne pas l’avoir sorti avant. La solution avec le manifeste il pouvait le faire depuis Windows XP minimum. Surtout que je me rappelle que la limitation réelle n’existe plus depuis le passage aux systèmes NT.



Avec ton explication du path je suis pas d’accord. Dans le cas où tu ouvres un fichier avec une variable qui contenait déjà tout le path, je suis d’accord pas de risque de buffer overflow. Dans beaucoup de cas tu peux utiliser d’autres api win32 manipulant des fichiers et répertoires qui vont te renvoyer un path fourni par le système que le gars aura stocké dans une variable limitée a 260 caractères. Je pense en particulier à FindFirstFile et FindNextFile mais c’est loin d’être les seules.



Sinon tu surestimes bien les devs Windows , vu ce que je vois tous les jours je pense que ce problème concerne beaucoup d’applications. Surtout qu’à la base jusqu’à maintenant la limitation de 260 caractères est censée être la norme pour tous les devs windows. Je crois même que sur pas mal d’exemples MSDN tu vois ce type de code..



Pour le mode de compatibilité c’est du tout ou rien. Imaginons que Ms l’active à partir des os plus anciens que redstone. Vu le très grand nombre d’applications concernées beaucoup d’applis se mettraient à planter. En effet ils gèrent une base d’exceptions. Je n’ose pas imaginer la taille de la liste. Et surtout ils ne mettront que les applications les plus répandues dans cette liste. Au final la solution du manifeste choisie par Microsoft dans redstone est pour moi bien meilleure et ne peut pas provoquer de casse au niveau de la compatiblité. Avec le manifeste c’est le développeur qui indique si il gère les path long ou pas. Aucun risque et tout le monde est content.

Le 28/05/2016 à 11h 34

Sinon le mode de compatibilité n’aurait pas marché. Ca concerne toutes les applications jusqu’à aujourd’hui. De plus il faut que le programme soit liste dans une base. La technique du manifeste utilisé dans redstone reste la meilleure solution.

Le 28/05/2016 à 11h 28

Tu m’as mal lu ou mal compris, je n’ai jamais dit qu’ils ne pouvaient pas le faire avant. j’ai juste dit que si ils activaient cette option pour l’ensemble des programmes ça poserait problème. relis bien ce que j’ai écris.

Ca aurait du être géré depuis longtemps et sur .NET aussi voir mon message précédent.

Le 28/05/2016 à 11h 05

Oui les deux prérequis c’est d’utiliser les api win32 unicode et le préfixe \?\

Après je me suis aperçu que .NET ne les utilise pas. j’ai été obligé de passer par des wrapper win32.

Le 28/05/2016 à 10h 58

Pour le problème de limitations de chemins, j’y avais été confronté sur un projet. En fait comme le dit vincent dans l’article, NTFS gère jusqu’à 32000 caractères. Il existait une méthode de contournement en mettant le prefixe \?\ devant le chemin.

Ca permet d’accéder au namespace kernel. Cette limitation existe uniquement au niveau de win32 et pas du noyau NT.



Si Microsoft n’a pas activé l’option par défaut pour tous les programmes c’est pour la compatibilité. Beaucoup de logiciels ont du code de ce type:

char path[MAX_PATH];

où MAX_PATH est une constante à 260. Si Microsoft activait l’option par défaut il créerait des buffer overflow sur beaucoup de vieux programmes qui n’ont pas géré le fait que les chemins puissent dépasser 260 caractères.



je pense aussi à un autre cas du même type. C’est l’utilisation des lecteurs dos c: d: qui perdurent dans windows NT pour la compatibilité. Sur Windows NT il existe une nomenclature interne \device\harddisk1 \device\harddisk2 similaire à la nomenclature unix /dev/hda, /dev/hdb. les lecteurs C, D sur NT sont de simples points de montage.



C’est à cause de ce genre de choses que Microsoft arrive à assurer des supports de plus de dix ans sur ses OS.



A ce propos en fin de cet article sur les pico process ils expliquent dans la même veine que le noyau gère aussi la casse des chemins mais cette option n’est pas activée dans le sous système win32. Visiblement ils voudraient donner aussi la possibilité de l’activer. Je me demande d’ailleurs si le sous système linux de redstone ne l’exploite pas.

Le 26/05/2016 à 10h 38

Oui je trouve aussi, c’est le meilleur dossier que j’ai pu lire sur le sujet. Il va très loin.

Le 26/05/2016 à 09h 13

crowtown super la référence….

Pour la deuxième partie du message, je suis d’accord ballmer s’est bien vautré. D’après ce qu’il a expliqué c’est suite au retard de Vista. C’est facile de réécrire l’histoire maintenant mais Microsoft avait tellement de problèmes techniques à l’époque(je pense aux problèmes de dépendances et de compatibilités), à mon avis ils étaient obligé de se vautrer avec Vista quoi qu’ils fassent. Et encore si ils n’avaient pas fait le reset en 2004 la situation aurait été bien pire. Je ne vais pas tout réexpliquer je l’ai fais des dizaines de fois.

Le 26/05/2016 à 08h 50

Pour ceux que ça intéresse Arstechnica a sorti un dossier très complet surl’histoire de la stratégie “windows everywhere”

Le 26/05/2016 à 08h 40

LA stratégie de l’unification si elle est menée a terme permettra à un produit MS peu vendu de profiter de la percée d’un autre produit qui pourrait marcher. L’unification ne se limite pas qu’au PC et au mobile.

Le 26/05/2016 à 08h 31

Konrad a écrit :



Certains ont cru au miracle : Windows Phone 8 devait tout déchirer, puis Windows Phone 10 allait arriver et offrir les mêmes applis que sur desktop, Continuum et tout le tralala… Mais sisi, vous allez voir, ça va décoller avec les ventes de Noël… Oui, sauf que dans la réalité, les chiffres n’ont jamais décollé depuis 5 ans, et aujourd’hui Microsoft licencie en masse dans son secteur mobile.





Il faudrait que tu nous expliques d’où tu sors çà. Déjà l’unification est en place que depuis un an et ne peut agir qu’à moyen long terme. Si tu réfléchis un petit peu tu comprendras que pour l’unification ait un effet significatif il faut que la plateforme Windows 10 atteigne un certain seuil en nombre d’utilisateurs. C’est pour cette raison que la plupart des gens parlaient de deux trois ans. Actuellement on est seulement à 300 millions. Si effectivement la gratuité des mises à jours cesse , il faudra attendre bien plus longtemps.



Il n’est pas compliqué de comprendre qu’une plateforme avec peu d’applications et de jeux compatibles n’intéressera jamais personne.



l’autre problème c’est le manque de flagship sur le marché W10M. En lisant cette news ce n’est pas prêt de s’arranger.



Par contre deux trois ans c’est beaucoup trop tard , Je pense que Windows Mobile ne pourra jamais remonter donc sur ce point tu as raison. Microsoft a plutôt intérêt à innover sur autre chose. C’est surement la stratégie de nadella. Je pense en particulier à la possibilité de sortir un hololens mobile.

Le 06/05/2016 à 07h 06

TheDidouille a écrit :



ta ruche, c’est ce que fait Android / iOS depuis toujours (je crois même MacOSX depuis 2000)…





Et alors je ne vois pas le rapport. Je parle d’une technologie destinée à rendre compatible Win32 de la même façon que uwp et les autres systèmes mobiles.

Ce mécanisme de données isolées existe dans winRT depuis windows 8 et idem sur les systèmes mobiles, je n’ai jamais dit le contraire.

Ce que j’explique c’est une méthode pour pouvoir sandboxer win32 ou du moins s’en approcher. Je parle en particulier d’un moyen de gérer correctement la BDR qui existe depuis Windows 95. iOS et Android ne sont forcément pas concernés puisqu’ils ne gèrent pas le passif existant comme Microsoft.



Pour MacOSX tu racontes de la merde. Déjà au début il n’avait même pas de système d’installation. Ensuite OSX n’a jamais sandboxé ou virtualisé les fichiers. Une application Desktop OSX peut potentiellement écrire n’importe ou dans le compte user.

Le 04/05/2016 à 10h 02

Pour l’aspect installation en une fois. les app centennial sont des app win32 qui ont été convertis en AppX qui est censé devenir la pile d’installation par défaut sur Windows.

Ensuite il y aussi une redirection des fichiers et clés de registre au runtime pas seulement à l’installation. Ce n’est pas le cas de click once.

Le 04/05/2016 à 09h 43

Oui ce serait le même principe que UWP.

Le but de centennial est de s’aligner sur l’App Model de UWP. pas de winrot ,toutes les données de l’application sont supprimées en une fois à la désinstallation.

Le 04/05/2016 à 08h 06

Drepanocytose a écrit :



Et puis dès que tu rentres dedans, ca pique

==> loin





J’avais déjà abordé le point du “gros foutoir dans la base de registre”. En terme de performances pour les petites données, la base de registre reste le mécanisme le plus performant devant le xml et les fichiers textes.

Il est d’ailleurs utilisé pour stocker les préférences des drivers.



Le problème de la base de registre est que Microsoft a donné un accès global à la BDR pour toutes les applications.

Cela avait été abordé sur channel 9 par des développeurs du noyau NT. Dans l’idéal la BDR devrait être utilisée uniquement pour le système et au niveau applicatif isoler les données entre elles.

L’approche utilisée dans UWP est intéressante. chaque application a sa propre ruche dans un dossier sandboxé. Et elle peut stocker avec de nouvelles api locales des données dans cette ruche. Si vous désinstallez l’application la ruche est supprimée avec les autres fichiers de l’application.

Le 04/05/2016 à 07h 55

Je n’ai pas l’explication officielle mais une ruche est composée de multiples petits rayons pour stocker le miel et le pollen. La ruche de la base de registre permet aussi de stocker tous un tas de données de petites tailles.

Le 04/05/2016 à 07h 23

psn00ps a écrit :



Heu… non.

Elles pourront toujours laisser des clés dans TA base de registres, et des fichiers dans tes répertoires utilisateurs.

Et magie du store ironie, elle peuvent être désinstallées par Microsoft.





Complètement faux…



Pour les applications UWP elles sont sandboxées et il n’existe pas d’api pour accéder à la base de registre. Il existent par contre des api de settings locales propres à UWP dont l’implémentation utilise la BDR mais dont les données sont stockées dans une ruche séparée. Cette ruche est dans le dossier sandboxé.



Pour les applications Win32 du store, tu n’as pas du tout accès à l’ensemble des fichiers utilisateurs ou de la base de registre. Une forme virtualisée est fournie. Les fichiers et les clés de registre sont redirigées vers un même dossier. Avec Centennial tu ne peux plus pourrir ton PC C’est une grosse avancée.



Cependant pour le moment les processus centennial sont full trust. Donc en terme de sécurité c’est contournable. Il suffirait par exemple de télécharger avec les api win32 disponibles un exécutable et de le lancer pour sortir de ces limitations.

Mais si une application légale utilise ce genre de choses, elle ne sera surement pas validée sur le store.



Pour résumer ça reste une bonne chose pour la disparition du winRot, pour la sécurité des applications win32 ce n’est pas encore au point.



Sur ce que j’ai entendu Microsoft travaille sur un projet nommé barcelona qui servirait à isoler les applications win32 du système dans des conteneurs. Il faut voir centennial comme une première étape.

Le 29/04/2016 à 07h 30

Sur singularity/Midori la notion de dll n’existe pas. En fait si tu veux faire un dll c’est un SIP(Process isolé). Mais bon c’est un tout autre fonctionnement.



Sur UWP en effet l’api LoadLibrary ne marche pas. Cependant tu peux utiliser cette api:

MicrosoftLoadPackagedLibrary permet de charger un dll à la condition qu’il soit défini dans le manifeste et dans le package. La notion de dll partagée n’existe plus sur UWP.

Cette règle à mon avis ne casserait pas la compatibilité sur un portage vers une base midori like. Comme les dlls sont tous connus par l’installeur. Le système pourrait les précharger et respecter la condition de processus isolé après la compilation.



Pour le JIT, Windows 10 a intégré une nouvelle permission et ajouter ces api:

VirtualProtectFromApp

CreateFileMappingFromApp

OpenFileMappingFromApp

MapViewOfFileFromApp

Ce sont des wrapper d’api win32 existantes qui faisaient déjà le boulot.



Pour le portage du JIT sur un système comme Singu/ Midori normalement ce n’est pas possible à ma connaissance. Ils ont peut être trouvé une solution depuis.



Sur Redstone Microsoft a intégré un nouveau système d’extensions plus fiable. Car pour le moment ce n’était pas possible sur UWP.

Le 28/04/2016 à 10h 40

eh oui mais je pense qu’à l’époque c’était plus rentable le propriétaire pour Microsoft. La situation n’était pas la même non plus. Je trouve que nadella fait preuve d’ouverture , d’intelligence et de clairvoyance.

Le 28/04/2016 à 09h 48

J’ai déjà dit ce que je pensais sur le sujet. J’ai toujours pensé que Windows finira par devenir open-source. Un changement de cet ampleur ne peut pas se faire en une fois. Mais ils ont déjà commencé avec plusieurs technos.

Microsoft a surement la plus grosse communauté de développeurs. Ce n’est pas windows qui va passer à linux c’est windows qui deviendra open-source et a des chances de devenir le plus gros projet open source.

Au final oui l’open source gagnera mais pas avec Linux…

Le 28/04/2016 à 08h 03

arno53 a écrit :



En parlant de Midori, Charon de DriversCloud.com m’a parlé de cette video Channel9 - Project Rome: Driving User Engagement with Connected Apps and Devices. Selon lui ca reprend certain concept de Midori : la notion de DLL n’existe plus, les apps UWP communiquent entre elles via des contrats etc… Il en parlera surement mieux si il passe par ici.



D’ailleurs il a plusieurs fois été dit que les apps WinRT était en partie pensé pour pouvoir fonctionner sur Midori (vu qu’elles sont memory safe etc…), et il est clair qu’à court terme c’est bien l’UWP qui profite le plus des concepts de Singularity/Midori





Si Le projet Midori a été annulé dans sa forme initiale, c’est surtout parce que c’était un os de rupture en soit incompatible avec Windows. Techniquement ils pouvaient en effet faire tourner win32 dans des conteneurs. C’est ce qui arrivera de toute façon mais gérer deux os totalement différents n’était pas une solution.

Windows 8 en soit était un os de rupture avec ses deux interfaces et plateformes logicielles incompatibles. Si Microsoft avait persévéré vers cette voie avec Midori l’échec était assuré.

La stratégie de nadella est d’incorporer les nouveautés dans Windows 10 progressivement pour éviter une rupture. Ils ont commencé par les composants haut niveau. La base changera surement en tout dernier.



Si on regarde bien la plateforme UWP intègre plusieurs choses qui viennent ou sont inspirés de Midori.



Déjà ils ont isolé la plateforme UWP de la platforme win32 surement dans l’espoir de la rendre native sur un autre base à terme.

Toutes les api UWP sont memory et type safe même pour les applications UWP en C++. Surement dans l’idée de marcher nativement sur un os managé.

Le système d’installation AppX est une grosse inspiration du système d’installation de Singularity. Toutes les dépendances ,les capacités sont définies dans un manifeste XML. Les applications sont toutes sandboxées.



Sur Singularity la notion de dll n’existe pas . Tout le code est scellé avant l’exécution. Les extensions tournent dans des process séparées. C’est un des piliers de Singularity pour la fiabilité.

Au niveau d’uwp les dll existent toujours car c’est Windows mais les dlls sont internes à un AppX et tous les dll internes utilisées sont définies dans le manifeste. Celà permettrait donc un préchargement sur un système comme Singularity.

Au niveau des échanges IPC(InterProcess) Deux SIP(process Singularity isolé) utilisent un système de contrat qui spécifient toutes les données échangées par des données typées. C’est aussi le même système pour appeler des api du systèmes ou d’autres extensions(les extensions sont des process). L’implémentation des api est aussi complètement décorréllé de l’interface qui définit ces API. Sur windows et Linux les api sont juste des routines exportées dans des dll ou .so en tant que symbole dans la table d’exportation du binaire. Potentiellement une application peut utiliser n’importe quel dll et api du système, même si les api exportées sont à usage interne. Singularity définit complètement les api qui peuvent être utilisées par les applications. le but est aussi de faciliter l’évolution de la plateforme pour la compatibilité.



Sur UWP ils ont repris la notion de contrats. Je crois que d’ailleurs joe duffy avait admis que le travail sur le sujet venait de Midori. Toutes les api UWP sont exposées dans du métadata(C:\Windows\System32\WinMetadata) qui va relier les api avec son implémentation. Ils existent des outils(h0x0d en a crée un) qui vont lire ce métadata et renvoient toutes les classes UWP avec toutes les méthodes exposées par le système aux applications. Les api sont regroupées par contrat.



Redstone intègre un nouveau système d’extensions qui fonctionne de la même façon que Singu/Midori décrite au dessus. Toutes les extensions tournent dans un processus séparé. Les échanges IPC se font aussi avec des contrats qui sont spécifiés dans le manifeste APPX.



Microsoft a travaillé sur un autre projet qui s’appelle Helios. C’est un dérivé de Singularity. C’est un système multikernel et distribué. Imaginer un noyau par coeur de processeur. Les SIP(process) sont balancés par un ordonnanceur à l’un des noyaux. Les différents noyaux communiquent par les SIP. La différence par rapport à singularity est qu’on peut faire des échanges entre SIP au niveau local mais aussi connecté. techniquement le SIP peut être exécuté sur une autre machine ou une instance azure de façon transparente.

Il se trouve que le projet Rome destiné à la synchronisation des appareils utilisent un système de contrat pour échanger les données entre les applications sur différents appareils. Bien sur ça n’agira pas à un niveau si bas qu’helios mais certaines idées ont été reprises.



La grosse différence actuelle entre Singu/Midori et UWP reste que UWP agit à un niveau plus élevé. Par exemple avec Singu/Midori le fonctionnement des SIP s’étend aussi aux drivers, ce qui n’est pas encore le cas sur Windows. Mais on ne peut pas nier que UWP a surement été conçue dans l’idée de tourner un jour sur une base similaire.

Le 28/04/2016 à 06h 55

Arno53 a très bien résumé la situation. En effet si Microsoft décidait de passer sur un noyau Linux les problèmes lors du passage de XP à Vista , ce ne serait rien à côté. Tout ça pour un intérêt quasi nul.

Le 28/04/2016 à 06h 51

Il y a plusieurs années la question a été posée à bill gates directement pourquoi il ne passait pas Windows sur un noyau Linux. En gros il a répondu exactement çà qu’il pensait pouvoir faire mieux.

Le 28/04/2016 à 06h 47

J’ai bu de l’eau du fleuve léthé j’ai oublié mon chemin " />



Plus sérieusement je suis sur un gros projet j’ai moins le temps et comme dit arno53 il y a de plus en plus de trolls j”interviens ponctuellement….

Le 09/04/2016 à 11h 34

Non les applications win32 centennial ne marchent que sur PC.

Le 09/04/2016 à 07h 46

Oui la première implémentation (app-v like), les process win32 sont en full trust. Il y a une redirection des fichiers et des clés de registres dans un endroit unique par application mais c’est effectivement contournable vu que ce n’est pas réellement sandboxé.



D’après mes sources centennial est censé évolué vers une technologie de conteneurs. Les nouvelles applications Linux seront elles aussi concernées. Mary jo foley a évoqué le projet barcelona qui serait une technologie de conteneurs destiné au client windows qui servirait à isoler les applications du système.

Le 09/04/2016 à 07h 08

+1 sur un ppt de la build , il parle de “software modern installer” qui destiné à devenir la nouvelle pile d’installation de windows par défaut.

En effet le sideloading prend une part importante.

Le 08/04/2016 à 09h 42

seblutfr a écrit :



Pas de bol :-/ Chez moi, aucun souci, et dans tous ceux de mon entourage, aucun problème non plus, ça passe comme une lettre à la poste. Ils n’ont pas joué les cascadeurs avec les Insiders, ça doit jouer, mais même en dehors de ça, je le trouve particulièrement stable.





Le truc c’est qu’on trouvera toujours des problèmes à chaque lancement de windows. Même sur 7 c’était pareil. On en parle juste plus….

Le 08/04/2016 à 09h 36

C’est ce que je t’ai dit au dessus le processus de migration n’est pas au point. C’est le même processus que la migration de 7 vers 10.

Sinon oui j’ai rencontré pas mal de gens où la mise à jour vers la 10586 ne s’est pas faite. La RTM avait quelques bugs.

Le 08/04/2016 à 09h 07

Ecoute ne j’ai pas la même expérience que toi je gère un site qui est pas mal utilisé dans le dépannage de PC et je suis directement exposé au grand public. J’ai aussi plusieurs contacts assembleurs qui me parlent de leurs retours. Les problèmes les plus fréquents rencontrés proviennent de la migration de ⁷⁄₈ vers 10.

Mais sinon les gens sont globalement satisfaits de la stabilité de Windows 10. Je l’ai mis aussi sur plusieurs machines je ne rencontre aucun problème.

Ensuite à chaque Windows il manque des drivers ou les drivers proposés ne sont pas vraiment stables. 10 n’échappe pas à la règle.



Pour les contrôles qualités ils vont être renforcé sur redstone.

Windows 10 n’est pas fini mais ça ne veut pas dire qu’il est massivement buggé ce sont deux choses différentes.

Le 08/04/2016 à 08h 45

Etre_Libre a écrit :



Oui je le sais bien étant dans l’informatique, mais ça donne un goût de “pas fini” et “cul entre 2 chaises”.





Je reprend ta phrase quand tu dis que 10 a un goût de pas fini. C’est la réalité il n’est pas fini. Microsoft est en train de reprendre le code complètement. Il a commencé par le niveau applicatif. Les applications universelles ce n’est pas juste l’interface qui change c’est tout le code. Ils repartent de zero. Si tu regardes Windows 8 au lancement et que tu compares aux premières bétas de redstone on ne peut pas nier que les applications UWP se sont enrichis et que l’interface s’est améliorée.

Rome ne n’est pas faite en un jour donc laissons du temps….

Le 08/04/2016 à 08h 30

Rien ne t’oblige à passer sur Windows 10 si cela ne te plait pas, arrête de te faire du mal " />



Pour la pauvreté je ne suis pas d’accord les applications WinRT/UWP ont bien évolué depuis le début. Regarde l’application mail par exemple que je trouve excellente. La pauvreté est principalement due au fait qu’ils n’ont pas encore tout recoder. Pour ma part , ce problème concerne surtout le nouveau panneau de configuration que je trouve trop sobre mais il est amené à évoluer.

Le 08/04/2016 à 08h 03

Si tu diminues la taille des textes Modern UI, tout le travail d’ergonomie et de design serait foutu en l’air. Demande l’avis d’ un graphiste , il te dira que c’ est un sacrilège. Les applications Modern UI ont été conçues pour cet effet immersif. Si tu mettais la même taille que win32 tout deviendrait moche. L’inverse aussi serait une catastrophe.



A mon avis c’est pour cette raison que Modern UI au départ ne marchait qu’en plein écran pour éviter l’interférence visuelle avec le reste. Il n’existe pas de solution simple.

La seule solution long terme est d’attendre que tout soit passée en modern UI.

Le 08/04/2016 à 07h 51

Modern UI joue sur la grandeur des textes pour mettre en avant le contenu. Personnellement ça me gène pas,c’est une histoire de goûts et d’habitude.

Le vrai problème à mon avis est qu’il reste encore tout un tas d’applications win32 intégrées qui tranche avec le reste. Donc en effet tu ne peux pas changer le réglage high dpi car il affecterait aussi ces applications.

Le 08/04/2016 à 07h 17

Comme indiqué au dessus X11 semble marcher. Une capture:

Twitter

Le 07/04/2016 à 11h 51

Les anciennes versions c’était une compatibilité POSIX. Ici c’est une vraie compatibilité Linux.

Ca utilise une ubuntu 14.04 LTS

Le 07/04/2016 à 11h 13

En effet vu que ça communique par réseau théoriquement çà devrait marcher avec un serveur X tierce " />

Le 07/04/2016 à 10h 34

A la build ils ont annoncé une fonctionnalité intéressant: uwp extensibility framework



C’est un système d’extensions au sein de la plateforme UWP. Il est fortement inspiré du fonctionnement de Singularity et Midori. C’est un système d’extensions qui tourne dans une app séparée. L’application définit un contrat qui cible exactement les informations IPC échangées. Ce système d’extension fait parti intégrante du modern software installer(appx). Edge utilise ce framework et d’après mes sources il devrait être utilisé sur l’ensemble des applications UWP intégrées. Personnellement j’imagine bien le nouvel explorateur universel intégré ce framework pour remplacer les shell extensions.

Le 07/04/2016 à 10h 14

Etre_Libre a écrit :



Et les 2 panneaux de configuration, pas toujours évident à expliquer aux utilisateurs.





L’ancien panneau de configuration va disparaître C’est temporaire uniquement car pour le moment toutes les options n’ont pas encore été portées sur le nouveau panneau. Microsoft ne va pas laisser en double des applications Win32 et UWP , Elles font grossir le système inutilement.

Le 07/04/2016 à 10h 05

+1 les applications qui ne peuvent pas être portées sont essentiellement des applications systèmes comme la mienne. C’est même pas 1% du marché…

Le 07/04/2016 à 09h 52

D’après ce qu’on m’a dit à vérifier seules les applications en ligne de commande marcheraient. J’imagine qu’ils n’ont pas porté pour le moment de serveur X11. C’est compréhensible ils visent en priorité le marché pro et les admins réseaux.

Le 01/04/2016 à 13h 35

Ouh la il faut prendre de la tisane ;) Bejarid tu devrais envoyer un mail à Vincent et discuter en privé. Vincent fait son travail de journaliste. Après il fait des erreurs comme tout le monde si tu lui signales ce sera pris en compte.

Je pense que tu as un faux a priori sur vincent.



Ensuite j’ai l’impression que tu attends de Vincent ce qu’on trouve sur un blog développeur. Vincent n’est pas développeur et il doit aussi vulgariser au plus grand nombre. Personnellement je ne saurai pas faire son travail de journaliste.

Le 01/04/2016 à 10h 17

pas de soucis juste une discussion entre devs.

Le 01/04/2016 à 06h 51

J’ai envisagé de passer à Qt à un moment donné c’est bien sauf que si tu ne fais pas d’open source tu dois te taper plusieurs Mo de libs à integrer sur Windows dans ton application. du coup me suis rabattu sur POCO et Boost.

Le 31/03/2016 à 19h 14

oui tu sors " />

Ou je la réécris en VB? " />

Le 31/03/2016 à 19h 02

Apparemment il existe un système de communication entre le process win32 et uwp dans centennial. Il ne parle pas des limitations mais la dernière fois qu’ils en ont parlé on ne pouvait pas installer ou appeler de drivers kernel mode. En effet sinon on pourrait facilement contourner la sandbox. J’envisage de sortir une version light de DriversCloud avec ces limitations pour pouvoir la proposer sur le store.

Le 31/03/2016 à 15h 58

Je comptais y passer j’ai bien fait d’attendre un peu :)

Le 31/03/2016 à 11h 56

J’ai quitté Apple pour les jeux j’allais pas revenir dessus ^^. Et mon père avait toujours un Mac à cette période.