L’éditeur n’a jamais vraiment communiqué de manière claire sur l’ensemble des nouveautés prévues dans son système. Comme le signale Neowin, il aura fallu attendre la quatrième année de Windows 11 pour que Microsoft fournisse une « roadmap » à son produit.
Sur une page dédiée, on peut constater 26 éléments référencés, accompagnés d’un descriptif, de leur statut et de la date prévue pour leur disponibilité en version finale. On peut d’ailleurs voir que l’élément en tête de liste, Recall, est considéré comme disponible en préversion depuis novembre dernier, mais sans date de déploiement prévue.
Quitte à arriver bien tard avec cette roadmap, Microsoft a quand même fait les choses correctement. La liste peut ainsi être triée selon plusieurs facteurs, on dispose d’un champ de recherche et de nombreux éléments ont un lien vers un billet de blog dédié et détaillé sur la fonction.
La liste permet ainsi d’avoir une vue de synthèse sur ce qui est prévu dans le système au cours des prochains mois. « Improved Windows Search », par exemple, fait référence à une nouvelle recherche intégrée, basée sur l’indexation sémantique et réservée aux PC Copilot+. Son déploiement vient de commencer.
On peut également voir qu’une mise à jour importante arrivera le mois prochain. On y trouvera plusieurs nouveautés intéressantes, comme la navigation du clavier logiciel à la manette de jeu, un calcul plus fiable du taux d’occupation CPU dans le gestionnaire des tâches, la possibilité de supprimer l’historique de géolocalisation, plusieurs améliorations pour l’accessibilité (dont Voice Access), ou encore la possibilité de choisir et personnaliser des widgets à épingler sur l’écran verrouillé. Notez que les ajouts prévus pour le mois prochain sont en cours de test sur la branche Release Preview.
Pour l’instant, la liste renseigne surtout sur les plus gros ajouts prévus à court terme. Si on descend, Microsoft affiche aussi ceux réalisés au cours des quelques derniers mois. On espère que l'entreprise tiendra correctement à jour cette page.
Commentaires (10)
Abonnez-vous pour prendre part au débat
Déjà abonné ? Se connecter
Cet article est en accès libre, mais il est le fruit du travail d'une rédaction qui ne travaille que pour ses lecteurs, sur un média sans pub et sans tracker. Soutenez le journalisme tech de qualité en vous abonnant.
Accédez en illimité aux articles
Profitez d’un média expert et unique
Intégrez la communauté et prenez part aux débats
Partagez des articles premium à vos contacts
Abonnez-vousLe 28/03/2025 à 10h52
avec un spnapdragon, si c'est une machine avec un AMD Ryzen AI ou un Intel Ultra c'est pour plus tard
Le 28/03/2025 à 12h17
Le 28/03/2025 à 12h50
Suivant l'outil ; on n'a jamais vraiment des chiffres concordants entre le gestionnaire de base et le reste des outils qui semblent être plutôt d'accord entre eux.
Le 04/04/2025 à 09h19
Le 04/04/2025 à 14h01
Il n'y a aucune obligation d'occuper l'entièreté de la mémoire. D'ailleurs, c'est le signe de "leak" ou de comportements non désirés (comme le détournement de ressource et autres "bot").
Ce n'est pas normal d'avoir un logiciel qui occupe (ou réserve) la mémoire entière alors qu'il ne l'utilise pas, ou qu'il ne devrait prendre quelques centaines de kilooctets. C'est comme bloquer un parking de 100 places pour une seule voiture. C'est aussi le signe de programmeur du dimanche. Ou de conducteur du dimanche, d'ailleurs.
Que les usages ait gonflé comme une brioche avec le temps ; soit. C'est souvent le fait d'augmentation de détails (icônes de boutons plus détaillées, sons, etc.). Ça fait vendre de la RAM. Mais de là à en faire une justification... Je vais laisser cela sur la pile des idées à penser plus tard.
Modifié le 14/04/2025 à 13h55
L'usage ne gonfle pas tant que ça en fait.
Quand un Chrome affiche consommer 10 go de RAM ce n'est pas parce qu'il est mal codé, mais simplement qu'il y'en a suffisamment à disposition, et que ni l'OS, ni le navigateur n'ont estimé utile de perdre du temps pour en libérer, et préfère les garder prêt à servir en cas de besoin.
Le même Chrome, avec les mêmes onglets ouverts sur une machine avec moins de RAM se contentera de quelques giga, sans pour autant ramer.
Un logiciel ne peut pas déléguer entièrement sa gestion de la mémoire à l'OS: seul le logiciel sait ce qui doit rester en mémoire (ex: le context javascript d'un onglet actif), et ce qui pourrait être libéré (ex: cache HTTP, ce ne serait pas trop grave d'aller le relire sur le disque-dur, mais dans le doute autant le garder en mémoire au cas où il doive ressortir). Si le navigateur déléguait tout ça à l'OS, il n'aurait pas de préférence, et risque de conserver du cache HTTP en mémoire, tout en swappant le contexte javascript pourtant en cours d'exécution. Donc des perfs dégradées à cause de cache miss bien plus fréquents.
Tu peux reprendre ton image du parking : si les voitures ont toutes le même propriétaire, tu peux optimisé l'essence et ne pas bougé certaines voitures tant qu'il reste de la place, ou à l'inverse garer certaines au 4ème sous-sol car elles sont moins régulièrement utilisées.
Le 14/04/2025 à 14h45
Et 'Malloc' c'est quoi d'après toi ? Ou encore
myObject01 = new myObject(). Ça fait quoi d'après toi ?Même sans descendre aussi bas niveau que
malloc(). Utiliser une fonction système pour lire un fichier et le stocker en mémoire, c'est obligatoirement passer par le système. Que cela soit direct ou pas (framework). Donc toute la gestion reste du côté OS.Tu ne verras personne se casser la tête à faire et gérer du cache à la main plutôt que d'utiliser ces fonctions. Surtout dans le cas de logiciels opérant sur différent OS. C'est juste se tirer une balle dans le pied pour la maintenabilité. Et pire. Cela devient gênant pour l'OS d'avoir un pâté de mémoire sur lequel, il n'a pas la main. On va y venir.
Maintenant si on suit ta logique. Juste pour voir.
Un soft occupe toute la RAM en prévision de ses futurs besoins. Admettons. L'utilisateur décide de lancer un autre logiciel. Que se passe-t-il ?
Bon, aller. On va dire que le soft parle au système et charge, quand il peut, ce qu'il souhaite. Cela suppose donc une réciprocité des deux éléments. L'un dit : "je veux ça" et l'OS lui accorde tant que ça passe. Mais du coup, l'OS catalogue et catégorise tout cela pour savoir lequel jeter au moment venu ; afin de libérer de la place. Et enfin pouvoir lancer une application dans les segments libérés.
C'est encore un peu toute la gestion coté OS... Hmmm...
Et ce n'est pas pour rien. Il y a un tas de raisons pratiques incontournables et des raisons de sécurité en plus.
Au passage :
On est passé aux SSD... le cache, on s'en fout un peu aujourd'hui. Si on met des SSDs dans des "Filers" c'est que la robustesse est présente. C'est tellement rapide qu'on a l'impression que c'est de la RAM. Du coup, occuper la RAM ça a moins de sens... bref.
Que ton exemple fonctionne d'une autre manière sur un autre OS ou parce qu'il est configuré pour faire comme cela ; soit. C'est un fonctionnement comme un autre. Mais il ne faut pas en faire une généralité.
Le 17/04/2025 à 09h14
Je n'ai pas Chrome sous la main mais "about:memory" dans Firefox est assez équivoque, il gère lui même sa mémoire et dispose d'un algo de garbage collector !
Windows ne va pas laisser un seul logiciel consommer toute la RAM, à un moment il va répondre à ses malloc avec du swap.
Sous Windows si tu n'as plus ni RAM ni swap , t'as une popup "mémoire insuffisante Windows essaie de libérer de la mémoire" (j'imagine que Windows envoie un signal "libérer de la mémoire" aux applis, pour que chaqcun déclenche leur garbage collector), en général ça ne fonctionne pas et précède un écran bleu :)
De mémoire (ça fait 20ans que je n'en ai pas codé
Le 17/04/2025 à 22h18
Pour cet exemple Firefox, tu fais donc allusion au Heap :
Firefox est écrit en plein de chose aujourd'hui (et ça dépend si on parle de Gecko ou pas en plus) mais on peut dire ceci. Si on regarde le "About:Memory" que tu cites, on voit des mots comme heap et gc. A.K.A le Tas et le Camion poubelle.
Le mécanisme est de réserver un pâté de RAM au système pour s'en servir. Une sorte de RamDisk pour l'audience des boomers (si vous êtes arrivé jusque-là). Mais ce n'est pas forcément une volonté de faire. Tout simplement parce que le framework (du langage) le fournit et qu'on fait avec.
Note sur le côté : Idem pour Java pour ne citer qui lui. Il y a un outil qui permet de voir en temps réel le comportement d'un programme Java et de son Heap. C'est VisualVM.
Seulement, il fut un temps où ces logiciels gourmands cherchaient à trop réserver à un moment où les ressources n'étaient pas si abondantes (RAM, CPU, I/Os). Et l'activation du GC était vu comme du vaudou. Donc atteindre un 100% RAM ça pouvait arriver. Mais cela relevait plus de la niaiserie que d'un souhait de privilégier les performances.
Aujourd'hui c'est plutôt de tailler au plus juste avec une ressource abondante. Aujourd'hui, ce sont les moins malins qui ne se servent pas de GC. Parce que les perfs, on les a. À l'heure des CPUs capable de virtualisation, faire des
malloc()en boucle ne pose plus de problème à proprement parler.Le deuxième "mais". Bin c'est que même s'il y a un Heap cela reste toujours au bon vouloir du système de valider les segments mémoire attribués. Pour une raison très simple. Un process (ou sous process) doit être sous contrôle et ne pas "déborder", ou faire nawak. C'est juste que l'attribution (éventuellement autorisation) passe par une couche entre le développeur et le système (le fameux framework intégré au langage).
On ne peut pas faire autrement. Télécharger un fichier JavaScript et l'exécuter dépend tellement du système (process alloué, quel cœur, % de temps (quand dispo), protection, etc) que le principe est et restera pour longtemps, je suppose, de soumettre au système et d'avoir un retour positif ou négatif en cas de catastrophe. Surtout si on veut le faire fonctionner sur plusieurs environnements (Linux, Win1x, autre).
Qui dit Heap dit obligatoirement système hôte.
Le 29/03/2025 à 17h23