Etat des lieux

Pour bon nombre de raisons, dont la suprématie de fait des systèmes Microsoft Windows, installés par défaut sur la plupart des machines neuves, peu d'utilisateurs se posent la question de savoir exactement à qui sert un OS, au point de le confondre avec les applications de production.

Pourtant, l'OS est un maillon fondamental, entre la plate-forme matérielle et les applications.

Dans la suite, nous considérons que nous travaillons sur une plate-forme de type PC, la plus répandue, bien qu'un OS trouve sa raison d'être sur toute plate-forme programmable, y compris sur des automates industriels.

Le matériel

Le matériel n'est finalement rien d'autre qu'un tas de composants électroniques, judicieusement agencé, certes, mais bien incapable de faire quoi que ce soit sans programmes informatiques.

Le BIOS

Le BIOS, écrit en mémoire non volatile, est un composant logiciel indispensable, mais tout à fait basique, comme son nom l'indique. Actuellement, il ne fournit que des fonctions d'accès au matériel extrêmement rudimentaires, qui ne servent que de façon transitoire, entre le moment où le matériel est mis sous tension et celui où l'OS est complètement chargé dans la RAM de la machine.

Les applications

A l'autre bout de la chaîne, du côté de l'utilisateur, les applications (traitement de teste, tableur, navigateur internet, jeux...) doivent être le plus possible indépendantes de la base matérielle.

Un exemple simple pour aider à comprendre, est le suivant :

Un même jeu, sans aucune modification du programme, devra fonctionner sur un PC, que celui-ci soit construit avec un processeur INTEL ou AMD, un chipset INTEL, VIA, Nvidia ou autre, une carte graphique ATI, Nvidia ou autre...

Le ciment qui permet de rendre l'ensemble logiciel + matériel homogène n'est autre que le système d'exploitation.

Ce que fait le système

Première approche

Commençons par quelque chose de simple, un système qui ne sait gérer qu'un seul utilisateur à la fois, une seule application à la fois, comme MS DOS ou FreeDOS.

Dans un tel système, nous pouvons être dans l'une des configurations suivantes :

	Le système a fini de démarrer, aucune application ne semble tourner. Pourtant il y en a une, c'est l'interpréteur de commande (command.com). Il est là pour attendre une commande lancée par l'utilisateur et pour la faire exécuter, si possible.
	Lorsque l'utilisateur demande l'exécution d'une application, l'interpréteur de commande s'efface et c'est l'application qui prend le contrôle, pendant toute la durée de son exécution. Lorsque l'application se termine, l'interpréteur de commande doit reprendre sa place.

Finalement, il devient assez clair que l'interpréteur de commande n'est qu'une application, presque comme une autre. Sa seule différence est qu'elle est relancée automatiquement, en l'absence d'une autre application. Si, pour une raison ou une autre, lorsqu'une application se termine, command.com n'est pas relancé, la machine devient muette, l'utilisateur ne peut plus rien lui demander, il y a "plantage" et il faut réinitialiser le système.

Les enseignements

Dans une telle configuration, le système ne peut gérer qu'une seule application à la fois.

L'application utilisateur doit gérer elle même la totalité de ses entrées/sorties (lecture du clavier, affichage à l'écran, lecture et écriture sur la mémoire de masse...), mais elle le fait en faisant appel à des fonctions évoluées, proposées par le système. Autrement dit, elle n'a pas à se préoccuper des spécificités du matériel. Le système apparaît donc comme une bibliothèque de fonctions destinées à permettre aux programmeurs d'applications d'utiliser de façon la plus simple possible les ressources matérielles de la plate-forme.

L'interpréteur de commandes est une simple application, dont la principale tâche est d'attendre que l'utilisateur lance une commande. Cette commande peut, dans le cas de DOS, prendre l'une de ces deux formes :

• la commande est interne, c'est à dire qu'elle est assurée par l'interpréteur lui-même, comme les commandes "dir", "copy", "delete", "type" etc.
• la commande est externe, comme "fdisk", "diskcopy", "format"... Et dans ce cas, elle est traitée comme une application classique, l'interpréteur s'efface pendant la durée d'exécution de la commande.

Dans ce contexte, une application utilisateur, comme un traitement de texte, a rigoureusement le même statut qu'une commande externe du système (et réciproquement).

Il n'y a donc qu'une seule application qui peut s'exécuter sur notre système, il n'y a, en principe, qu'une seule application présente en mémoire, bien qu'il puisse y avoir quelques exceptions à cette règle.

Le cas des programmes "résidents"

Normalement, lorsqu'une application est lancée, l'interpréteur s'efface et c'est l'application qui prend le contrôle total de la machine. Lorsque l'application est terminée, la mémoire qu'elle utilisait est libérée et l'interpréteur reprend la main.

Il peut être cependant nécessaire, dans certains cas spéciaux, de garder en mémoire l'application, bien que l'interpréteur reprenne la main. Un bon exemple est la gestion des lecteurs de CD ROM sous DOS, ou encore une certaine façon de gérer la souris.

Pour gérer correctement un lecteur de CD ROM, il faut effectuer deux opérations :

• la première consiste à ajouter un module ("driver") au noyau du système ("kernel"), au moyen du fichier config.sys,
• la seconde consiste à lancer un petit programme qui va faire quelques opérations d'initialisation, mais qui va rester en mémoire lorsqu'il aura fini de s'exécuter. Sa présence permanente permettra à d'autres applications de faire appel à ses services, lorsque ce sera nécessaire. Fonctionnellement, ça ressemble beaucoup à un "driver", à part qu'un résident sait faire des choses lorsqu'il est chargé, alors qu'un simple module ne sait pas le faire.

Cette fonctionnalité supplémentaire, qui permet donc d'initialiser certains paramètres lors du démarrage du résident, lui confère un avantage par rapport à un simple module, qui se contentera d'ajouter des fonctionnalités au noyau, mais qui ne fera rien tant qu'on ne l'aura pas sollicité.

Un programme résident peut être chargé à tout moment, au moyen de l'autoexec si on le charge au démarrage du système, ou plus tard, si le besoin s'en fait sentir. En revanche, il n'est pas simple de charger un module autrement qu'au moment du chargement du système.

Une approche plus fonctionnelle

Actuellement, plus personne n'utilise de systèmes aussi rudimentaires que DOS sur plate-forme PC, sauf dans des cas très particuliers, généralement du domaine de la maintenance.

Les systèmes modernes sont capables d'autoriser l'exécution "simultanée" de plusieurs applications (multi tâche), et ce, dans des contextes d'utilisation différents (multi utilisateurs). Rien n'interdit en effet de placer sur la même plate forme plusieurs ensembles écran-clavier-souris, et de permettre à plusieurs utilisateurs de travailler simultanément sur la même plate forme matérielle. Windows XP ne le fait pas, (pour des raisons purement commerciales), mais Windows 2003 sait le faire, les systèmes UNIX aussi, dont les diverses distributions GNU/Linux.

A partir du moment où plusieurs applications peuvent cohabiter, l'interpréteur de commandes ne peut plus s'effacer, il doit pouvoir être accessible à tout moment, ce qui n'est d'ailleurs pas un problème, puisque le système sait gérer plusieurs applications en parallèle.

De plus, avec les systèmes graphiques, l'OS fournit aux applications un cadre de travail fenêtré et les applications dialoguent avec les utilisateurs dans des fenêtres et non plus sur la totalité de l'écran.

Le schéma général vu plus haut se complique donc un tout petit peu, pour prendre la forme ci-contre. Les applications s'adressent toujours au système pour exploiter les ressources matérielles, mais comme l'interface de gestion intègre le système des fenêtres, les applications y font appel pour exploiter les fenêtres.

Notez que c'est juste une façon de voir les choses, nous pourrions tout aussi bien représenter de tels systèmes de la façon suivante :

Dans cette représentation, l'interface de gestion est vue comme une couche supplémentaire entre le système d'exploitation proprement dit et les applications. Cette représentation est probablement plus proche de la réalité avec des systèmes comme UNIX, où l'interface graphique peut être choisie dans un large éventail (GNOME et KDE sont actuellement les plus communes), contrairement à Windows, qui n'en propose qu'une.

Nous n'entrerons pas trop dans les détails du système de gestion multi tâches, mais il faut tout de même savoir plusieurs petites choses :

L'ordonnanceur

Les applications ne s'exécutent bien entendu pas toutes en même temps, il ne peut s'en exécuter simultanément que si la plate forme dispose de plusieurs processeurs, et au mieux, autant que de processeurs présents.

Dans les cas les plus courants, les applications sont toutes présentes en mémoire, mais une seule, à un instant donné, est active. C'est l'ordonnanceur (séquenceur, "scheduler" en anglais), qui attribue un temps dactivité, tour à tour, à chaque application présente, en fonction d'un grand nombre de paramètres que nous n'analyserons pas ici.

En réalité, le système ne considère pas les applications, mais les processus (threads). Une application peut être découpée en plusieurs processus. Par exemple, le correcteur orthographique de MS Word, qui souligne en "temps réel" les mots mal orthographiés, tourne en même temps que les processus de saisie au clavier, de mise en forme à l'écran, de sauvegarde automatique...

Le système dispose de droits privilégiés par rapport aux simples applications. En effet, il est en principe toujours possible de reprendre la main sur le système, en cas de "plantage" d'une application, et de forcer le système à mettre fin au(x) processus qui ne répond(ent) plus convenablement. Sous Windows, la combinaison des touches Ctrl+Alt+Suppr lance une application ultra prioritaire, qui permet de gérer les applications qui se perdent. Sous Linux, il est possible d'ouvrir une nouvelle console (interpréteur de commandes) et de demander au système de mettre fin aux applications indésirables.

Les privilèges d'exécution

Les processeurs INTEL permettent d'attribuer différents niveaux de privilèges aux processus. Généralement, deux seulement sont utilisés :

• le niveau le plus haut pour le noyau, ordonnanceur compris,
• le niveau le plus bas pour les applications utilisateurs.

Normalement, les "drivers", qui sont des ajouts au système, devraient disposer de privilèges inférieurs au noyau, mais supérieurs aux applications. Malheureusement, le fait de forcer des niveaux de privilèges différents à ce qui est en train de s'exécuter a un coût important en terme de temps CPU. Pour améliorer les performances, les concepteurs de systèmes placent souvent les drivers au même niveau que le noyau.

Il s'en suit que si un driver est défectueux, le système ne peut pas forcément reprendre l'initiative et dans ce cas, la machine ne répond plus, sans qu'il soit possible de remédier à la situation autrement qu'en forçant un redémarrage.

La mémoire virtuelle

Chaque application tourne dans une sorte de "bac à sable", c'est à dire que le système crée une zone mémoire étanche pour chaque application. Dans un système d'exploitation sérieux, aucune application ne peut interférer avec une autre. Le système y veille et arrête immédiatement toute application qui dépasserait ses limites. Ceci d'ailleurs pose un problème lorsque les applications doivent échanger des données. Un exemple simple est le "Copier / Coller", d'une application dans une autre. Il faut alors utiliser une sorte de sas, sous le contrôle du système, ce qui n'est pas rapide du tout.

Chaque application travaille comme si elle était toute seule, dans un espace mémoire adressé de façon virtuelle. Entendez par là que les adresses manipulées par l'application n'ont rien à voir avec les adresses physiques de la RAM utilisée. C'est encore le système d'exploitation qui opère, conjointement avec un composant spécifique pour la gestion du bus d'adresse.

Il arrive cependant assez rapidement qu'il n'y ait plus assez de RAM installée pour supporter toutes les applications en cours. Dans ce cas, le système, encore lui, a recours à un artifice. Il copie sur la mémoire de masse une zone de mémoire utilisée par des applications inactives, et libère cet espace pour l'application en cours. C'est la zone de "swap", qui est réservée dans la mémoire de masse par le système. Windows crée un fichier d'échange dans une partition quelconque, Linux nécesite une partition spécialement créée pour ça.

Usuellement, cet espace réservé sur le disque est égal au double de la RAM installée, mais rien n'interdit d'en réserver davantage, surtout lorsque l'on utilise des applications gourmandes en mémoire.

Bien entendu, ce "swapping" est très pénalisant pour les performances du système et il convient tout de même de dimensionner correctement la RAM en fonction des besoins estimés. Aujourd'hui, pour un système proposant une interface graphique, 256 Mo de RAM apparaît comme un minimum et 512 Mo comme une bonne moyenne.

Les interruptions

Une interruption, c'est un procédé qui permet d'arrêter une tâche en cours pour en exécuter une autre, jugée plus prioritaire, de telle manière qu'une fois cette tâche plus prioritaire exécutée, le système puisse reprendre la tâche interrompue sans en avoir perdu le fil.

Vous l'avez compris, c'est grâce à ces interruptions que l'ordonnanceur peut gérer efficacement le multi tâches.

Mais il y a sur un PC une multitude de sources d'interruptions :

• la frappe d'une touche sur le clavier génère une interruption,
• l'arrivée d'une donnée sur un port série, sur une interface réseau, génère une interruption,
• pire encore, le simple déplacement de la souris déclenche une cascade d'interruptions, le système ayant absolument besoin à tout moment de savoir analyser les commandes que l'utilisateur lance avec sa souris,
• l'horloge système génère également des interruptions à intervalles fixes (plusieurs fois par seconde), et l'ordonnanceur en profite pour superviser le système.

Un système sérieux doit même être capable de gérer une interruption alors même qu'il est déjà en train d'en gérer une.

Imaginez que le système, dans un mode graphique fenêtré, doive périodiquement analyser toute activité de la souris, déterminer de façon exacte dans quelle zone de l'écran l'utilisateur a déplacé le curseur et a cliqué, avec quel bouton il a cliqué, et transmettre l'information à l'application concernée, pour qu'elle réagisse en fonction de cette commande.

Vous n'avez en général aucune impression d'attente ou de retard dans les commandes que vous lancez avec votre souris, ce qui vous laisse imaginer le travail nécessaire, effectué par le système, rien que pour cette gestion de la souris.

Lorsque vous déplacez une fenêtre sur l'écran et que, pour de simples raisons d'estéthique, le contenu de la fenêtre reste visible durant le déplacement, imaginez le travail fourni, il faut :

• continuer à calculer le contenu de cette fenêtre,
• l'afficher en suivant le déplacement,
• mais il faut aussi faire ce travail pour les fenêtres qui sont au dessous. Elles ne se déplacent pas, mais leur contenu qui était caché doit apparaître, pendant qu'un contenu visible doit être masqué.

Vous avez vraiment l'impression de faire glisser des feuilles de papier les unes sur les autres sur votre bureau, et pourtant, l'image globale affichée sur l'écran est tout ce qu'il y a de plus plate, c'est un seul plan mémoire qui est intégralement recalculé à chaque modification. Je passe sur les divers effets d'ombrage, de dégradé etc, juste là pour faire joli, et qui augmentent considérablement le travail à faire.

Et tout ce travail, pour le réaliser en donnant l'impression qu'il se fait immédiatement à la commande, ne peut être réalisé qu'au travers d'une multitude d'interruptions.

Vous comprendrez mieux pourquoi une interface graphique nécessite à elle seule une grande quantité de ressources, et vous comprendrez aussi pourquoi ce n'est pas forcément une bonne idée que d'imposer une telle interface graphique pour un serveur, dont l'écran est éteint la plupart du temps, mais où tout le dispositif de gestion est en place, même s'il ne fait rien.