Connexion

Catégories

Droit Économie Flock Hardware IA Internet Logiciel Sciences Sécurité Société

Nous Suivre

Contact rédaction Contact site Forum
Flux RSS GitHub Discord

À propos

Abonnez-vous

Windows 10 : la build 14352 améliore Cortana et Ink, active les chemins longs NTFS

32 000 >> 260

Windows 10 : la build 14352 améliore Cortana et Ink, active les chemins longs NTFS

Le 28 mai 2016 à 10h00

Microsoft propose depuis hier soir une build 14352 pour les testeurs de Windows 10 inscrits au programme Insider. Les améliorations principales se concentrent sur Cortana et Ink, deux fonctionnalités qui seront prochainement mises en avant avec l’arrivée de l’Anniverasry Update.

Les testeurs du Fast Ring peuvent depuis cette nuit se rendre sur Windows Update pour récupérer la dernière build. Estampillée 14352, elle commence par renforcer Cortana, décidément à l’honneur de la prochaine grosse évolution du système.

Cortana et Ink : le gros des améliorations

À commencer par un ajout qui ne sera, décidément, disponible qu’aux États-Unis : la possibilité de lancer n’importe quel titre du catalogue de Groove (musique), dès lors que l’utilisateur possède un mot de passe. Jusqu’à présent, cette fonction n’était valable que pour les fichiers locaux. Le tout avec des commandes vocales, comme d’ailleurs l’autre fonctionnalité : le lancement d’un minuteur. Là encore, avec la voix, on pourra en créer, demander à Cortana combien de temps il reste ou l’annuler.

Les Notes évoluent fortement dans cette préversion, à la fois pour Cortana et pour Windows Ink. Rappelons que ce dernier regroupe tout un ensemble d’outils et de capacités associées au stylet. L’assistant peut ainsi analyser les notes manuscrites et les convertir en rappel, une fonctionnalité montrée durant la conférence Build. Les numéros de téléphone peuvent en outre servir à appeler, une adresse email à envoyer un courrier, etc. Malheureusement, et une fois de plus, certaines possibilités ne sont disponibles qu’outre-Atlantique.

Parmi les autres améliorations d’Ink, la règle – l’un des points forts de la démonstration en avril – se dote d’un compas, situé en plein centre. Dès qu’elle se trouve alignée avec l’un des quatre points cardinaux, l’indicateur du compas devient gras. Microsoft en a profité pour polir un peu l’expérience globale, signalant au passage de meilleures performances.

Chemins NTFS : une exploitation plus simple

Quelques autres nouveautés sont à signaler. L’icône d’Explorer reprend de la couleur, après un passage par le blanc dont Microsoft dit qu’il n’a pas été apprécié. La fonction Game DVR d’enregistrement vidéo prend par ailleurs en compte six nouveaux jeux en mode plein écran : League of Legends, World of Warcraft, DOTA 2, Battlefield 4, Counterstrike: Global Offensive et Diablo III. Enfin, en entreprise, le passage d’une édition Pro à Enterprise ne réclame plus aucun redémarrage une fois que la clé a été changée.

Enfin, et bien que la nouvelle ne soit placardée par Microsoft, la build 14352 introduit un changement qui pourrait avoir une grande importance pour les développeurs. SI NTFS gère en effet des longueurs de chemins de 32 000 caractères, les API Win32 les limitaient à 260, pour des questions de compatibilité et de sécurité. Désormais, avec le renseignement idoine dans le manifeste d’une application Win32 ou UWP (LongPathsEnabled = Enable), la limite est levée.

Comme toujours avec les préversions, la nouvelle build se récupère directement dans Windows Update. La machine doit être déclarée comme participant au programme Insider, en Fast Ring.

Commentaires (41)

Vous devez être abonné pour pouvoir commenter.

Abonnez-vous
votre avatar

Non charon.G, … j’aime ton dévouement à la cause, mais là: non.



Rien, absolument rien ne peut expliquer que je ne puisse pas ouvrir mon fichier Microsoft Excel 2013 depuis l’explorateur de fichier de mon Microsoft Windows 8.1 Pro (2013), et cela pour une raison de longueur du chemin. Non, rien.



Quand à l’excuse du “pour rester compatible, on limite tout l’OS”… comment dire… la gestion des modes de compatibilité est intégré dans l’OS depuis windows XP. Suffit d’exécuter les programmes dans le bon mode suivant leur limitation (et ca petut être automatisé par une base, la date/signature. …)



Alors on peut se féliciter que Ms lève cette limitation, on peut déplorer que ca arrive aussi tardivement… mais, non, on ne peut pas leur donner d’excuse, surtout aussi bidon.

votre avatar

Surtout qu’ils ont emmerdés pendant plus de 16 ans tout le monde avec une limite stupide.

votre avatar

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.

votre avatar

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.

votre avatar

Ah bah récupérée ce matin et enfin, finit la limitation, ouf !!

Bon après, il y a plein de petites nouveautés bien sympas. :)



Je retourne dessus pour faire bien le tour.

votre avatar

Petit détail, que j’attendais personnellement depuis le début, l’heure et la date font leur apparition sur toutes les barre de tâches, sur tous les écrans ! <img data-src=" />

votre avatar







hollaamic a écrit :



Microsoft danse encore d’un pied sur l’autre : d’un côté on nous dit que Cortana ne sera compatible que Bing et Edge (ce que j’ai trouvé complètement WTF) et de l’autre on peut l’utiliser maintenant pour faire de nouvelles choses avec Groove et le minuteur. Ou alors ces derniers sont considérés comme des composants de l’OS et pas Edge ni bing ?






Rien à voir. La limitation à propos d'Edge et Bing a été instauré expressément après la mise au point par Alphabet d'une technique qui pourrissait Cortana quand Chrome était le navigateur par défaut, et Google son moteur de recherche.      







Alphabet est en mode guerre ouverte avec MS, et MS n'a fait que fermer ses volets pour arrêter d'avoir à remplacer ses fenêtres brisées. L'ouverture de Cortana n'est pas remise en cause, elle va continuer à aller vers de plus en plus de "bots" extérieurs, tout comme Skype. Mais à travers des API, pas juste une redirection Win32.

votre avatar

Detaille un peu cette attaque de Chrome sur Cortana, je n’ai rien vu passer.

Hoax ou encore une protection incroyable dont bénéficie Google…

En tout cas, soit Microsoft avait laissé trop de possibilités aux tiers…. et Google s’en est servi….sans doute que Microsoft va corriger le tir.

Soit c’est une malfaisance pure et simple de Google

&nbsp;

Dans tous les cas, pourquoi Microsoft n’a pas attaqué en justice ?

votre avatar

C’est toujours le même problème…..

Apple rompt la compatibilité ascendante….. génial Apple avance, tant pis pour les retardataires rétrogrades

Microsoft rompt la compatibilité ascendante…. quel scandale, comment va fonctionner mon appli assembleur de 1982 sur disquettes 8 pouces ?

votre avatar

Quelqu’un a réellement essayé/utilisé un chemin+nom de 32000 caractères ?

Cela doit représenter un certain temps pour être créé.

&nbsp;

&nbsp;

votre avatar

Mouais… L’Explorateur Windows a un manifeste à jour ou on doit se débrouiller ?



Non je demande parce que c’est exclusivement l’explorateur qui me fait ça et ça complique parfois les sauvegardes car forcément ça foire… Les rares fois où j’ai vu cela chez d’autres personnes, c’était par exemple du fait d’un rangement de très nombreux fichiers Office dans un répertoire à de trop multiples étages à noms longs.









Mithrill a écrit :



Bonne nouvelle pour les chemins long en tout cas ! Windows 10 progresse dans le bon sens.





…ou rattrape son retard. Ça dépend de comment on voit la chose.


votre avatar







AlphaBeta a écrit :



Detaille un peu cette attaque de Chrome sur Cortana, je n’ai rien vu passer. 



 Hoax ou encore une protection incroyable dont bénéficie Google...       


 En tout cas, soit Microsoft avait laissé trop de possibilités aux tiers.... et Google s'en est servi....sans doute que Microsoft va corriger le tir.       


 Soit c'est une malfaisance pure et simple de Google       


 &nbsp;       


 Dans tous les cas, pourquoi Microsoft n'a pas attaqué en justice ?









On peut considéré que oui, MS avait laissé plus de possibilité qu'il n'était raisonnable, et Google en a joué avec. Volontaire ou pas, ça bousillait les résultats de Cortana, puisqu'elle redirige vers une recherche web (donc navigateur+moteur par défaut).      







Au final, MS a verrouillé Cortana avant que la modif n'arrive dans le canal stable de Chrome, donc non, ceux qui ne sont pas en Canary n'ont rien vu passé, et il n'y évidement pas matière à attaque judiciaire. MS a imaginer que les navigateurs joueraient le jeu, l'un d'eux n'était manifestement pas de cette idée :)




Don’t be Evil qui disait !


votre avatar







AlphaBeta a écrit :



C’est toujours le même problème…..

Apple rompt la compatibilité ascendante….. génial Apple avance, tant pis pour les retardataires rétrogrades

Microsoft rompt la compatibilité ascendante…. quel scandale, comment va fonctionner mon appli assembleur de 1982 sur disquettes 8 pouces ?





Pour moi ce n’est pas un problème, c’est la différence entre le monde du grand public et le monde professionnel.



Le grand public tu le convaincs de ce dont il a besoin, le pro tu lui donnes ce qu’il demande (je forcis le trait, mais le fond y est). Chaque entreprise ses points forts, chacun son domaine de prédilection :)


votre avatar

Quand tu télécharges beaucoup de distrib linux (😂) sur les newsgroup, tu peux te retrouver avec des noms de dossiers + fichiers à rallonge et qui donc dépassent les 260.

votre avatar







askana a écrit :



mouai il faudrait que cortana fonctionne au Québec ca serai sympa





Microsoft avait annoncé que la langue « Français Canada » arriverait l’automne dernier, mais moi aussi j’attend toujours…&nbsp;



EDIT : Je viens de rechercher à nouveau sur le sujet, apparemment que c’est implémenté dans les dernières builds pour Insider. Sans doute prévu pour cet été !


votre avatar







charon.G a écrit :



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.







Cette limitation n’existe pas au niveau Win32.



Seules quelques applications, notamment de Microsoft (malheureusement les plus connues comme Windows Explorer) ont cette limitation ridicule.

N’importe quelle autre application Win32 qui n’est pas codée avec les moufles se fout de ces limitations depuis des lustres et évolue naturellement OS près OS sans avoir besoin d’être recodée. Et tu peux aussi noter que d’autres ‘limites’ n’existent plus depuis Vista (genre au niveau variables d’environnement), mais que certains programmeurs n’en tiennent pas compte et se croient encore sous Windows 95 alors que l’API Win32 en arrière n’a jamais eu aucune de ces limitations, seule la version de l’OS renvoie un buffer de taille X ou Y, mais la taille se calculait déjà dynamiquement il y a 20 ans (plutôt que d’hardcoder un buffer de 64k bêtement pour gagner 2us).


votre avatar







Tarvos a écrit :



Quelqu’un a réellement essayé/utilisé un chemin+nom de 32000 caractères ?

Cela doit représenter un certain temps pour être créé.







J’en utilise tous les jours … depuis des années sous Windows … évidemment je n’utilise pas Windows Explorer pour les gérer.


votre avatar







charon.G a écrit :



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.







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.


votre avatar

Je te le confirme, dans les paramètres de Cortana, il y a un choix de variantes de français, qui ne contient pour le moment que “Français (Canada)”.

votre avatar

Ca avait été fait dans les bêtas de Windows Vista de mémoire (ou alors c’était 7, je ne sais plus), puis ils étaient revenu en arrière. Il devait bien y avoir une raison !



Et puis, là, on parle de l’inverse ! Une application qui gère 255 caractères avec laquelle on tente d’accéder à un chemin beaucoup plus long. Seul moyen d’empêcher que ça n’arrive : interdire de créer des chemins trop longs dans l’explorer… Par contre, on avait tout de même le problème puisque d’autres programmes en créaient tout de même (par exemple, 7zip).



D’ailleurs, Windows lui-même quand il fait une mise à niveau, le dossier Windows.old étant non-supprimable manuellement à cause de ça, il faut alors passer par le nettoyage de disque qui lui, gère les chemins longs.

votre avatar







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.


votre avatar

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….

votre avatar

LongPathsEnabled = Enable

Ho là là … super pratique et dans un sens … super bordélique aussi.



Vous avez vu ce que donne un chemin long sous Hubic ou DropBox ? Courage fuyons.

D’un autre côté, si Windows est enfin capable de faire copier / coller d’un disque dur local sur un disque USB environ 15 Go de fichiers et d’arborescence créées par un vulgus pecum qui créer des noms de fichier énormes et des sous-arborescences pires …. ce ne sera pas plus mal.



Quand je pense que je devais booter sous Windows pour faire des sauvegardes de données user avant manipulation, c’est plutôt une bonne nouvelle.

votre avatar

Je ne pensais pas voir cette maudite limitation de caractère disparaître de mon vivant. Je n’y croyais plus&nbsp;



Une galère sans nom, notamment avec utilisation de dropbox sur des fichiers créés sous nux&nbsp;



Comme beaucoup c’était un des éléments m’ayant fait quitter windows définitivement&nbsp;

votre avatar







charon.G a écrit :



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….







Sauf qu’ils ne l’ont jamais été …

Depuis des lustres tu peux ouvrir un fichier avec un PATH de 32000 caractères avec CreateFile … CreateFile, CopyFile, MoveFile … c’est l’API win32. “fopen” c’est pas l’API Win32.



Seul l’OS et/ou le filesystem t’en empêchait (exemple Windows 95). Les Windows supportant NTFS capables de rouler du code buildé en Unicode n’avaient pas ces limitations. Et Unicode, Windows NT et j’en passe, ça date pas de la semaine dernière.


votre avatar







charon.G a écrit :



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.







Oui et ça fait un bail que les API Unicodes existent …

Et il n’y a pas de ‘comportement par défaut’. Soit tu build pour NT et donc en Unicode soit tu build pour du compatible DOS et donc ANSI. C’est un choix délibéré ! Depuis longtemps par défaut Visual Studio crée des applications Unicode et pas ANSI via les wizard, donc les développeurs doivent délibérément forcer le mode ANSI. Ce faisant ils introduisent des limitations (qui n’ont plus lieu d’être depuis au mois 15 ans).







charon.G a écrit :



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.







FindFirstFile ne renvoie pas un path limité à 260 caractères. Il part d’où tu veux et renvoie un nom de fichier limité à MAX_PATH caractères, sur lequel tu append le path de départ (jusqu’à 32,767 chars). Le path de départ support les long path.







charon.G a écrit :



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..







M’en fous des mauvais développeurs, je te dis que cette limite n’existe pas dans l’API Win32. Et elle n’existe pas.







charon.G a écrit :



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 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.

Microsoft aurait du faire un changement radical quitte à mettre par terre un paquet d’application. Seulement, combien de fois tu as l’occasion pour le grand public et même les pro de pousser un long path ? Rarement en fait, donc ça n’aurait pas posé le moindre problème, les applications n’auraient pas été impactées, au pire par défaut les API auraient pu renvoyer un short name 8.3 en permanence pour gagner encore un peu plus de temps avant la réécriture.



C’est pas comme si lors de la sortie de Windows 2000 ou XP il n’y avait pas eu un paquet d’applications comme drivers qui ont d’un coup arrêté de fonctionner, une de plus ou de moins rendu là … Windows 2000/XP auraient du amener ce changement dans Windows Explorer.


votre avatar



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…

votre avatar

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…

msdn.microsoft.com Microsoft





In 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.



msdn.microsoft.com Microsoft







catseye 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.


votre avatar

En relisant tes propos je m’aperçois que ton discours n’est pas du tout cohérent. D’un cote tu nous racontes qu’il n’y pas de limitation Win32 qu’on peut gérer les chemins dépassant plus de 260 caractères sans rien faire depuis longtemps(car en effet les api unicode ça fait un bail qu’elles existent et que le code de windows a migré dessus). Et d’un autre tu nous dis qu’ils auraient du appliquer ta méthode même si ça cassait plein d’applications. C’est totalement illogique ^^

Sans compter que si tout marchait déjà correctement Microsoft n’aurait pas activé ce feature sur redstone….

votre avatar

La longueur des caractères max fait partie des petites gênes qui, accumulées, m’ont fait quitter le système.



&nbsp;C’est cool de les voir aussi agressifs dans les mises à jours maintenant.

votre avatar

Tant mieux car pour les chemins en Japonais, Chinois etc.. (déjà que le le symbole Y dans les chemins posaient soucis .) cela était trop court .

votre avatar

Microsoft danse encore d’un pied sur l’autre : d’un côté on nous dit que Cortana ne sera compatible que Bing et Edge (ce que j’ai trouvé complètement WTF) et de l’autre on peut l’utiliser maintenant pour faire de nouvelles choses avec Groove et le minuteur. Ou alors ces derniers sont considérés comme des composants de l’OS et pas Edge ni bing ?


votre avatar

Après les premiers retours ne faisant pas état de problèmes majeurs, et compte tenu du faible nombre de bugs annoncés, j’essaye désespérément de repasser sur les build insider après avoir fait toute les build insider de la toute première technical preview a la première release de Windows 10. Mais malgré que le programme insider soit bien configuré en fast, il ne me propose toujours pas la build. J’espère qu’elle arrivera assez vite…

votre avatar

Cette longueur de chemins est une plaie dont sur Server 2012 R2, j’espère que le Server 2016 pourra bénéficier de cette avancée ;)

votre avatar



SI NTFS gère en effet des longueurs de chemins de 32 000 caractères, les API Win32 les limitaient à 260, pour des questions de compatibilité et de sécurité.



Certaines API permettaient quand même de passer outre la limite, généralement en appelant la version unicode de la fonction.

votre avatar

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.

votre avatar

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.

votre avatar

Ce qui foutait le bordel on se retrouvais avec des fichiers illisibles ou des dossiers inaccessibles, voir impossible à supprimer… Il était temps… parce que j’ai récemment eu le problème avec Typescript & NPM, plus possible de compiler parce que le build générait des fichiers que le système n’arrivait pas a atteindre.



Du coup, ça dépasse la limite sous Linux qui est de 4096.

votre avatar

mouai il faudrait que cortana fonctionne au Québec ca serai sympa

votre avatar







charon.G a écrit :



Vista ne t’a pas suffit…

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







Sauf que ça n’a rien à voir, Win32 n’a pas changé d’un iota, il marchait avant et marche encore comme avant …

Une fois de plus le problème ne vient pas de Win32.


votre avatar







charon.G a écrit :



En relisant tes propos je m’aperçois que ton discours n’est pas du tout cohérent. D’un cote tu nous racontes qu’il n’y pas de limitation Win32 qu’on peut gérer les chemins dépassant plus de 260 caractères sans rien faire depuis longtemps(car en effet les api unicode ça fait un bail qu’elles existent et que le code de windows a migré dessus). Et d’un autre tu nous dis qu’ils auraient du appliquer ta méthode même si ça cassait plein d’applications. C’est totalement illogique ^^

Sans compter que si tout marchait déjà correctement Microsoft n’aurait pas activé ce feature sur redstone….







C’est parfaitement cohérent sauf que tu ne lis que ce qui t’arrange …



La limite n’existe plus depuis au moins Windows 2000 (voire NT4 et avant …), donc des applications unicode y en a pleins depuis des lustres et elles ne sont pas du tout limité. D’ailleurs les Total Commander, TeraCopy, superCopier, zipper et autres applis Java de ce monde n’ont jamais été limitées par les 260 caractères.



Donc pour les applications codées avec les pieds, si tu leur passes un chemin vers un fichier de moins de 260 caractères je vois mal comment, avant comme aujourd’hui, elle planterait. Hors les chemins de moins de 260 caractères c’est 99% des chemins exploités par les utilisateurs, donc non, y avait pas et y a toujours pas de problèmes avec ces applis. Autrement dit ça fait plus de 15 ans que Windows Explorer aurait du supporter les long path. En quoi c’est pas cohérent ?

Maintenant si tu passes un long path à une appli boiteuse, il est possible pour Microsoft de le réduire avant de le passer (c’est là que tu enclenches le mode compatibilité).



Ensuite pourquoi Microsoft ne l’a pas fait avant ? Parce que ça leur rapportait pas un centime. Pourquoi ils le font maintenant, parce qu’à force ils sont chaque jour plus ridicules que la veille (et aussi parce que pleins d’applications par défaut de Windows sont largement détournées par les soft que j’ai cité, et donc les soft Microsoft sont de moins en moins utilisés ce qui ne les arrange pas en terme d’image).


Windows 10 : la build 14352 améliore Cortana et Ink, active les chemins longs NTFS

  • Cortana et Ink : le gros des améliorations

  • Chemins NTFS : une exploitation plus simple

Fermer