Au début du projet, Windows 7 était réellement censé être la version 7.0 du noyau NT, mais Microsoft a décidé d’en faire une version mineure : 6.1. D’après l’éditeur, les changements sont suffisamment majeurs pour que Windows 7 soit considéré comme une version 7.0, mais plusieurs applications vérifient en interne la version de Windows et cela aurait pu poser des problèmes de compatibilité avec plusieurs applications. Microsoft recommande pourtant depuis longtemps dans ses guidelines de ne pas utiliser la version pour vérifier la présence de composant ou API Windows.
Il y a une deuxième raison : Microsoft a amorcé un développement modulaire avec Windows Vista qui représente la première version dans cette direction. Le choix de la dénomination de version 6.1 appuie le fait que Windows 7 sera entièrement compatible avec les applications et pilotes Vista existants.

Dans Windows 7, les développeurs ont la possibilité de mentionner les systèmes d’exploitation supportés dans le manifeste par des identifiants uniques (GUID) et spécifiques à chaque système. L’idée est d’empêcher la vérification de la version au lancement de l’application avec l’API GetVersion par exemple. En effet à chaque nouvelle version de Windows, certaines applications refusent de se lancer. Avec cette nouvelle fonctionnalité, c’est Microsoft qui décide si l’application peut fonctionner ou pas. Microsoft évoque l’idée de faire tourner les applications pour le système adapté dans un futur proche.
MinWin
Le cœur de Windows 7, aussi appelé « Core OS », reste globalement inchangé dans son architecture par rapport à Vista. Pour rappel, le Core OS est constitué du noyau ainsi que des différents sous-systèmes (audio, réseau, graphique, stockage…) qui gravitent autour de ce dernier. Ces sous-systèmes sont eux-mêmes composés de modules fonctionnant en espace noyau ou espace utilisateur.
Le travail effectué sur le Core OS de Windows 7 est essentiellement de l’optimisation. La Windows Core Team, à l’aide d’outils internes, a cherché à optimiser les ressources mémoires et les accès I/O sur l’ensemble de ce Core OS, ainsi qu’à améliorer les différents sous-systèmes afin d’augmenter nettement les performances.
Les évolutions sont contrôlées par l’architecture modulaire introduite dans Vista. D’après les informations présentes sur MSDN, le portail de documentation technique réservé aux développeurs, tous les pilotes et applications tournant sur Vista devraient fonctionner correctement sur Windows 7 en version finale.
L’une des principales réalisations sur Windows 7 est cependant le projet MinWin. De nombreuses désinformations sont parues sur ce sujet et il est utile de réexpliquer en quoi cela consiste. On a pu lire en effet qu’il s’agissait d’un nouveau noyau qui remplacerait le noyau NT. C’est faux : le noyau de Windows 7 est une version 6.1 de NT : une légère évolution du noyau Vista.
Mark Russinovitch, expert Microsoft, s’est exprimé depuis, plusieurs fois sur le sujet. MinWin est essentiellement un chantier sur les dépendances de Windows. Il consiste à délimiter les frontières d’une brique minimale de base pouvant fonctionner de manière autonome. Cette brique est constituée entre autres du noyau, de la HAL (Hardware Abstraction Layer), des systèmes de fichiers et des sous-systèmes réseau. En revanche, il n’intègre pas le sous-système graphique. En octobre 2007 MinWin était constitué d’une centaine de fichiers environ. Il occupait 25 Mo sur le disque dur et environ 40 Mo en mémoire. Il est intéressant de le comparer au Server Core de Windows Server 2008 qui constitue l’installation minimale à ce jour. Elle occupe environ 1 Go sur le disque et, contrairement à MinWin, n’est pas autonome dans le sens où elle a besoin des autres fichiers sources Windows pour compiler.
Avec MinWin, Microsoft a redirigé les dépendances de façon à ce qu’aucun appel ne soit fait vers des composants de plus haut niveau. Concrètement, la société a redirigé plusieurs API de kernel32.dll et advapi32.dll vers le nouveau dll kernelbase.dll.
On obtient alors enfin une brique minimale totalement autonome du reste de Windows. Quel est son but ? Il en existe en fait plusieurs. La première que cite Microsoft sur MSDN est la possibilité dans un futur proche de proposer un Windows plus modulaire afin de réduire la surface d’attaque ou la consommation mémoire et l’espace disque. La deuxième raison serait un gain en termes d’évolutivité. Il serait plus simple en effet d’effectuer de gros changements futurs sur cette brique fondamentale.
Une autre raison serait la possibilité pour Microsoft de partager la même base de code pour l’ensemble de ses systèmes. On pourrait par exemple imaginer un futur Windows Mobile basé sur MinWin. La dernière raison est un point de jonction pour accéder à Windows. Si Microsoft compte passer à Midori (l’application commerciale du noyau de recherche Singularity), la compatibilité avec Windows pourrait en être facilitée.
Noyau et Multithreads
Le noyau de Windows 7 reste globalement inchangé par rapport à celui de Windows Vista bien que certains petits changements intéressants soient intervenus.
Il y a plusieurs années, David Cutler, l’un des pères du noyau NT, avait placé un verrou global utilisé par le noyau pour la synchronisation des threads lors, par exemple, de l’accès exclusif à certains objets. Ce verrou avait pour conséquence de stopper l’exécution de tous les cœurs d’exécution pour donner l’accès exclusif d’un objet à un seul cœur. Jusqu’à aujourd’hui, ce mécanisme ne posait pas de problème, mais avec l’arrivée des machines massivement multicœurs, ce fonctionnement induisait des temps de repos du thread assez long. Arun Kishan, un autre développeur du noyau, s’est attaqué au problème pour Windows 7. Il a éclaté ce verrou global en verrous plus fins et a ajouté un nouvel état d’attente pour les threads.
De même, il existait aussi un verrou sur la table de pagination (qui décrit la mémoire physique au niveau du noyau) qui a été aussi supprimé. Selon Microsoft ces deux verrous enlevés augmenteraient nettement les performances des applications multithreads.
Le noyau de Windows 7 est maintenant capable de gérer jusqu’à 256 processeurs logiques. La notion de processeurs logiques correspond au nombre de processeurs vus par le système d’exploitation. Pour donner un exemple, une machine avec 3 processeurs octocœurs avec HyperThreading posséderait en fait 3 x 8 x 2 = 48 processeurs logiques.
Sur Windows, on peut régler pour un thread ou un processus les processeurs logiques qui seront utilisés. Cette notion s’appelle l’affinité du processeur. L’affinité est stockée sous forme d’un entier de 32 bits pour les systèmes 32 bits et de 64 bits pour les systèmes 64 bits. Chaque bit correspondant à un processeur logique. Microsoft ajoute la notion de groupe de processeurs logiques. Il est ainsi possible d’avoir 4 groupes de 64 processeurs logiques ce qui fait bien 256 processeurs logiques au maximum. Cette méthode permet de conserver la compatibilité avec les applications existantes tout en augmentant le nombre de processeurs logiques utilisables par les nouvelles applications.
Noyau et regroupement des alarmes
Pour améliorer l’autonomie d’un portable, le système doit s’attaquer à deux choses :
Diminuer le temps total d’utilisation du CPU par les applications en optimisant le code
Augmenter également la durée pendant laquelle le processeur reste à l’état de repos.
Le noyau de 7 apporte une solution à ce second problème. Quand il n’y a aucune activité logicielle, et si la durée pendant laquelle le processeur va ne rien faire est suffisamment élevée (la durée est calculée par le système), le processeur est mis en repos.
En effet, mettre en repos et réveiller le processeur sur une durée trop brève ne ferait qu’augmenter la consommation d’énergie au lieu de l’économiser. Le but va donc être d’élargir les périodes de repos afin d’augmenter l’autonomie.
Toutes les 15,6 ms environ, l’horloge système envoie un signal d’interruption au processeur qui court-circuite l’exécution d’un programme pour passer la main au noyau. C’est à ce moment là que l’ordonnanceur (scheduler) peut donner la main à un autre processus. C’est le fonctionnement même des systèmes multitâches actuels. Quand le noyau prend la main il va aussi regarder si des alarmes ont expiré. En effet, les logiciels et les pilotes ajoutent des alarmes pour déclencher régulièrement différentes routines. Le temps d’exécution des ces routines diminue les durées de repos du processeur.

Dans le cas des machines avec plusieurs processeurs logiques, un processeur est dédié au noyau, les autres aux applications, et on les appellera les processeurs d’applications (AP). Avant Windows 7, les signaux d’interruptions de l’horloge étaient reportés aux processeurs d’applications quand ils étaient en état de repos. Sur Windows 7, le noyau réveillera les processeurs d’applications seulement si une alarme logicielle a expiré ou si un signal d’interruption matérielle autre que l’horloge est envoyé. On voit donc une première augmentation de la durée de repos pour les processeurs d’applications.

La deuxième technique introduite est le regroupement des alarmes pour les applications et pilotes afin qu’elles expirent au même moment. Microsoft propose aussi de nouvelles API pour que les développeurs puissent spécifier une tolérance sur l’alarme. Par défaut, elle est de 32ms. Cette tolérance indique le temps maximum avant que l’alarme ne soit déclenchée. Le noyau de 7 regroupera ainsi plusieurs alarmes qui se déclencheront au même moment.
On voit bien sur ce dernier schéma l’augmentation nette des durées de repos du processeur grâce aux deux techniques mises en œuvre.

Noyau, heap (tas)
Le tas (heap) est une zone mémoire où des blocs mémoires sont alloués dynamiquement. Un nouveau tas système tolérant aux fautes a été conçu. Il est capable de résoudre les problèmes de gestion mémoire les plus répandus en évitant ainsi aux applications de planter. Microsoft estime qu’actuellement 15 % des crashs des applications sont dus à des corruptions de tas.
Noyau, réflexion des processus
Sur Windows 7, quand un processus plante, il est maintenant cloné en mémoire. Cette méthode permettrait d’améliorer la fiabilité du diagnostic pour créer le rapport et les fichiers dump du processus.
Noyau, démarrage
Windows Vista intègre le « Customer Experience Improvement Program ». Ce programme envoie, si l’utilisateur le permet, différentes informations statistiques sur l’utilisation générale du PC. Le but est de permettre à Microsoft d’améliorer les futures versions de Windows. Plusieurs millions d’utilisateurs ayant accepté d’activer ce programme, l’éditeur a pu réunir des statistiques sur les temps de démarrage de Vista.

35% des machines démarrent en moins de 35 secondes et 75% des machines en 50 secondes. Microsoft, avec Windows 7, compte arriver à atteindre 15 secondes et moins pour la majorité des PC. Pour cela il travaille sur plusieurs points :
- Réduire la consommation mémoire/CPU mais aussi les accès disques
- Diminuer le temps de démarrage de tous les services systèmes (nous reviendrons sur ce point plus loin dans le dossier)
- Charger les pilotes en parallèle
Ce qui s’affiche durant le démarrage a aussi son importance. Sur Windows Vista, la résolution minimale de l’écran de démarrage était de 640 x 480 pixels, avec une profondeur de couleurs de 16 bits. Sur Windows 7, on passe à une résolution minimale de 1024x768 et une profondeur de couleurs de 32 bits, ce qui permet ainsi de fournir une animation plus conviviale pour l’utilisateur (les écrans type netbook ne gérant pas la résolution native minimale de 1024x768 verront apparaitre l’ancien écran de démarrage de Vista). Microsoft a repris la méthode de chargement de l’animation afin d’éviter les latences que l’on pouvait observer sur Vista. Il réduit l’image à une petite zone de l’écran, ce qui diminue la taille des images à gérer. Ces images sont stockées comme des bitmaps compressés avec le format WIM (format d’image disque introduit avec Vista pour accélérer l’installation).
Sur Vista, avant d’arriver à l’écran de connexion, on pouvait voir apparaitre une transition supplémentaire avec une perle Windows. Cet écran n’apparaissait qu’à la fin du démarrage, quand le sous-système graphique avait été initialisé, et augmentait le temps d’arrivée au bureau. Sur Windows 7, cette transition a été supprimée pour donner plus rapidement accès au bureau.
Enfin, la partie « son » a également changé puisque sa gestion est devenue asynchrone. Windows n’attend donc plus que la pile audio soit chargée et cela diminue encore un peu le temps de démarrage.
Enfin, les constructeurs OEM auront la possibilité de proposer d’autres écrans de démarrage pour les mettre plus en phase avec l’image de leur marque.
SSD
Certaines dispositions ont été prises pour la prise en charge des SSD. L’alignement des partitions NTFS a ainsi été modifié car les SSD ont des secteurs de 4 Ko en comparaison des 512 octets des disques durs actuels. Le système des secteurs à 512 octets est toujours émulé mais peut provoquer des problèmes de performances.
Les cellules des SSD nécessitent d’être effacées avant que l’on puisse à nouveau y écrire. Les nouveaux modèles intègrent la commande TRIM, qui informe le système d’exploitation que des données ont été effacées. Le système peut alors effacer les cellules à l’avance en tâche de fond. Windows 7 supporte cette commande (depuis la Release Candidate) lors des différentes opérations sur les fichiers, mais également au niveau du gestionnaire de partitions et du système de restauration. Ceci est censé améliorer les performances.
Il est important également de préciser que si Windows 7 détecte l’utilisation d’un SSD en lieu et place d’un disque dur, plusieurs composants sont alors désactivés :
- Le défragmenteur
- Le service SuperFetch (cache pour l’accélération du lancement des applications)
- Le service ReadyBoost
Services
Windows intègre depuis NT4 une gestion des tâches de fond : les services. Un service peut être réglé soit en démarrage automatique, soit en démarrage manuel, mais Vista a ajouté le démarrage différé.
Actuellement, un grand nombre de services restent configurés en automatique et sont donc chargés en permanence. Cela affecte le démarrage et l’arrêt du PC, qui peuvent s’allonger. Cela affecte aussi la consommation mémoire et la batterie. Enfin, sur le plan de la sécurité, la surface d’attaque est d’autant plus grande que le nombre de services actifs est important.
Pour résoudre ce problème, Windows 7 introduit la notion de déclencheurs. Ce sont des événements qui vont provoquer le démarrage ou l’arrêt d’un service. L’idée derrière ce mécanisme est qu’un service doit être actif seulement si cela est nécessaire. Voici une liste des principaux déclencheurs :
- Un service est démarré à l’arrivée de la première IP sur la pile réseau et stoppé à la dernière IP
- Un service peut démarrer à la connexion d’un matériel et stoppé à sa déconnexion
- Un service est démarré si l’ordinateur rejoint un domaine et stoppé quand il s’en déconnecte
- Un service peut démarrer à un changement d’une politique de groupe dans les outils d’administrations.
Élément important : les développeurs peuvent créer eux-mêmes un déclencheur personnalisé.
Windows 7 permet en clair un contrôle beaucoup plus fin des services démarrés et affecte ainsi les différents points cités plus haut.
Parallel Computing Platform

À l’heure actuelle, peu d’applications exploitent correctement les processeurs multicœurs. Dès 2011, les processeurs vendus pourraient atteindre 16 cœurs. L’équipe de la Parallel Computing Platform est chargée de ce problème. Une double architecture en C++ et .NET a en conséquence été conçue, portant respectivement les noms de « Native Concurrency Runtime » et de « Concurrency and Coordination Runtime ».
Ces deux infrastructures fournissent une série d’API de synchronisation et de gestion des threads aux développeurs, leur permettant de se faciliter la tâche et de pouvoir rendre assez facilement leurs applications multithreads.
Ces « frameworks » reposent en outre sur un concept important : les UMS threads (User Mode Scheduled Threads). Les threads sont plus ou moins des tâches qui tournent sur un cœur du processeur, et les processus sont constitués d’un certain nombre de threads. Les threads classiques sont gérés au niveau du noyau, par un composant appelé ordonnanceur, dont le rôle est de partager l’utilisation du CPU entre chacun d’entre eux.
Contrairement à ces threads classiques, les UMS sont des threads tournant en mode utilisateur. Il existe deux gros avantages :
- La transition entre le mode utilisateur et le mode noyau est très coûteuse. Ce n’est pas le cas avec les UMS, et l’on gagne ainsi en performances.
- Ils garantissent l’utilisation totale du quantum de temps assigné par le système si un UMS bloque, quelle que soit la raison.
Bruno Boucard, spécialiste chez Microsoft, a effectué un test avec une multiplication de matrice avec et sans optimisation par le Concurrency Runtime. Il est arrivé à diviser le temps d’exécution de son programme par 4,5.
__
Sensor et Location Platform__
Windows 7 intègre une architecture unifiée pour l’utilisation de tous les types de capteurs. Parmi ces derniers, on trouve ceux destinés à la localisation géographique comme les GPS intégrés, les accéléromètres, mais aussi les capteurs de lumière, de température, caméras d’identification, microphones, boussoles, détecteurs de mouvement, de trafic, de météo ou encore les puces RFID.
Ces capteurs ne sont pas nécessairement sur la machine mais peuvent être accessibles via Internet. Par exemple on peut localiser géographiquement un ordinateur par son adresse IP. Les pilotes associés sont développés avec UDMF, le framework de pilotes utilisateurs introduit dans Vista (un pilote UDMF ne peut pas faire planter la machine).
L’API Windows Location s’appuie sur la Sensor Platform et permet de retrouver la position géographique, soit par la latitude et la longitude, soit par un lieu (rue, ville, pays). On trouve d’ailleurs un nouveau panneau de configuration qui permet d’inscrire manuellement la localisation par défaut en cas d’absence de capteurs géographiques sur le système. Il est aussi possible de désactiver cette fonctionnalité pour des problèmes de confidentialité et de vie privée. À noter qu’il est créé un log dans l'observateur d'événements qui trace tous les changements de lieux physiques du portable.
Les applications pourront bien sûr exploiter ces nouvelles API, ce qui existe par exemple d’ailleurs sur l’iPhone d’Apple et laisse une bonne idée de ce qu’il est possible de faire.

Chose intéressante sur un portable muni de capteur : Windows ajustera automatiquement le niveau de luminosité selon la lumière ambiante. Windows 7 diminue aussi la luminosité de l’écran après une certaine période d’activité afin de faire baisser la consommation d’énergie.
Autres SDK
Microsoft met à disposition des développeurs la Windows Vista Bridge Library qui permet de proposer les nouvelles API spécifiques à Vista et 7 aux développeurs .NET. La firme tente ainsi d’unifier le système pour que les développeurs C++ et .NET puissent avoir accès à la plupart des fonctions. Cette bibliothèque est en fait une interface P/Invoke pour proposer les API natives aux applications .NET.
De même, mais dans l’autre sens, les API XPS, la technologie XML dérivée de XAML (utilisée dans le sous-système d’impression de Windows Vista/7) est maintenant disponible en natif. Elle était jusqu’à présent réservée aux développeurs .NET.
Microsoft met aussi à disposition un SDK pour supporter le format de fichier OPC (Open packaging conventions) utilisé dans le format OpenXML et XPS.