Les services du NT Executive tournent aussi en mode noyau. Ce
sont donc des parties importantes, indispensables au système
d'exploitation. Leur rôle est de fournir les services de base aux
sous-systèmes d'environnement. La Figure 1.2
présente les différents services du NT Executive.
Figure 1.2 : Architecture des éléments
du NT Exécutive [3] Pour mieux comprendre cette figure,
énumérons un peu le rôle de chacun :
· l'Object Manager, ou Gestionnaire d'Objets
:
Sous Windows NT, tout est représenté sous forme
d'objet : un processus, un thread, un périphérique quelconque
sont des objets. Chaque objet contient une ACL : Access Control List, Liste de
Contrôle d'Accès, une liste définissant les droits que les
autres objets ont sur lui. Pour travailler avec un objet, on utilise un
handle11. Ce handle est une référence
représentant l'objet. Il contient notamment un pointeur sur l'objet
ainsi que les droits que l'on possède sur cet objet. C'est le
gestionnaire d'objets qui fournit tous les handle que les autres objets lui
demandent. Les objets sont créés, modifiés et
supprimés par le gestionnaire d'objets. Le gestionnaire d'objets
supprime les objets orphelins. Un objet ne doit exister que s'il est
utilisé. Le gestionnaire d'objet compte le nombre d'objets utilisant
chaque objet. Quand ce nombre
10 Swappé signifie que le
code d'exécution est transféré de la mémoire vive
vers le disque pour récupérer un peu de mémoire ; il sera
replacé en mémoire quand on en aura besoin.
11 Un handle est une valeur
numérique identifiant un objet informatique.
11
arrive à zéro, l'objet n'est plus
utilisé, donc supprimé. Le gestionnaire d'objet veille à
ce que chaque objet ne consomme pas trop de ressources.
s le Process Manager, ou Gestionnaire de
processus
Son rôle est de créer, modifier l'état et
supprimer les threads. Il renseigne sur l'état de chaque thread. Son
rôle n'est pas de cadencer les threads. Tout processus contient au moins
un thread initial, dans laquelle tourne effectivement le programme.
s Le Virtual Memory Manager, ou gestionnaire de
mémoire virtuelle
Son rôle est d'allouer 4 Go d'espace mémoire
à tous les processus en exécution, indépendamment de
l'espace mémoire effectivement disponible sur le système. Sur ces
4 Go, 2Go seront réservés au système, les deux restants
seront à la disposition du programmeur. Sur les systèmes
contenant suffisamment de mémoire, il sera possible d'allouer plus
d'espace pour la partie applicative (donc moins pour le système).
Il s'assure que chaque application reste dans son espace
d'adressage attribué. C'est le gestionnaire de mémoire virtuelle
qui gère le swap. Les programmes demandent des pages mémoire au
gestionnaire. Le gestionnaire leurs fournit, qu'elles soient en mémoire
vive ou swappées.
s Le LPC: Local Procedure Call, ou Appel de
Procédure Locale
Dans un système d'exploitation, tournent en permanence
un certain nombre de threads. Tous les services systèmes par exemple
sont des threads ; les sous-environnements aussi. Viennent ensuite les
applications utilisateur. Tous ces threads dialoguent en permanence entre
elles, les applications vers le sous-système d'environnement, le
sous-système d'environnement vers les services système, les
services système entre eux. Tous ces dialogues passent par le LPC qui
gère la communication entre threads. C'est un programme
spécifiquement développé pour optimiser les communications
locales entre processus.
s Le SRM : Security Ressource Manager, ou gestionnaire
de sécurité des ressources
Son rôle est de gérer la sécurité
en local sur la machine. Il sécurise l'accès à tout objet
du système. Quand un utilisateur veut utiliser un objet, il fait une
demande de handle auprès du gestionnaire d'objet. Le gestionnaire
d'objet demande au SRM quels droits l'utilisateur a effectivement sur l'objet
demandé. Le SRM compare le SAT (Secure Access Tocken, Jeton
d'accès sécurité) de l'utilisateur, contenant les droits
de l'utilisateur (appartenance aux groupes
12
donc héritage), à l'ACL de l'objet
demandé et en déduit le niveau d'accès de l'utilisateur
sur l'objet. Ce niveau d'accès sera stocké dans le handle.
· Le I/O Manager, ou Gestionnaire
d'Entrées-Sorties
C'est une grosse partie du système d'exploitation. Il
est divisé lui-même en plusieurs couches de manière
à être le plus modulaire possible. Il est constitué de
telle manière que lorsque l'on veut ajouter ou changer un driver
quelconque (disque dur, carte réseau) on ait le moins de code possible
à développer. Il faudra simplement ajouter la couche qui va bien
au bon endroit. Celle-ci s'appuiera sur ses couches supérieures et
inférieures, qui n'auront pas à être modifiées. Plus
les couches sont hautes, moins elles connaissent le système physique.
Le gestionnaire d'entrées-sorties coordonne et
gère les communications entre drivers. Ces communications se font avec
des messages spéciaux appelés I/O Request Packets. Le
gestionnaire d'entrées-sorties gère notamment les systèmes
de fichiers et les redirecteurs réseau (c'est grâce à lui
que peuvent cohabiter plusieurs systèmes de fichier, par redirection des
packets vers la bonne couche suivant leur type). Un redirecteur réseau
n'est en fait rien d'autre qu'un système de fichier spécial. Pour
une application, la méthode pour aller chercher une information sur le
serveur ou sur un map réseau est strictement identique. Le gestionnaire
d'entrées-sorties gérant les systèmes de fichier, il est
normal qu'il gère aussi le cache disque (c'est le cache qui optimise les
lectures sur le disque). Au lieu de diriger les requêtes disques
directement vers le disque, il regarde d'abord dans le cache. S'il ne trouve
pas le bloc demandé, il va alors transmettre la requête au disque.
La réponse repassera forcément par le cache, qui cette fois ci
stockera l'information. [3]
· Le Graphic Manager, ou gestionnaire
graphique
Il regroupe les deux sous-modules GDI et USER, correspondant
respectivement à l'interface graphique et au gestionnaire de
fenêtres. Ce module n'était pas présent dans le NT
Executive sur Windows NT3, ceci a été présent à
partir du Windows NT4 et présent aujourd'hui dans les autres Windows NT
jusqu'à la version 6.1 correspondant au noyau de Windows 7. Sous Windows
NT3, GDI et USER se trouvaient dans le sous-environnement Win32. Leur choix,
contesté par certains, a été justifié pour la
raison suivante : Sous Windows NT3, quand le sous-environnement Win32 plantait,
on ne pouvait absolument plus rien faire, le système était
bloqué. En le mettant dans le NT Executive, lorsque le
sous-environnement Win32 plante, le noyau est capable de repeindre votre
écran en bleu et vous afficher des informations susceptibles de vous
aider à résoudre, du moins comprendre, le problème. De
plus, par la commande CTRL-ALT-SUPPR, il décharge le système
d'exploitation. [3]
