Windows NT et Unix

Windows NT 3.1 en 1993. C’est ainsi que Windows
NT et Unix évoluent depuis la moitié des années 70 et ont tous deux été influencés
par les tendances de la recherche universitaire sur les OS. En outre les deux
OS ont des objectifs de conception communs : portabilité, avolutivité et possibilité
de tourner sur des ordinateurs allant des PC de bureau aux serveurs départementaux.

En interne, Windows NT est très semblable à  VMS, mais dans quelle mesure ses capacités
et ses fonctions correspondent-elles à  celles d’Unix ? Il est difficile de faire
la lumière sur cette question, parce que même les trois leaders d’Unix – Solaris,
HP/UX et AIX – sont à  bien des égards aussi différents l’un de l’autre que chacun
ne l’est de NT. Il n’y a donc pas d’Unix  » définitif  » à  comparer avec Windows
NT et je me servirai des caractéristiques et des implémentations d’Unix traditionnelles
ou prévalentes de chaque sous-système dans la comparaison qui va suivre entre
NT et Unix. Je m’en tiendrai aux trois leaders du marché et à  trois autres variantes
d’Unix : Linux, BSD 4.4 et Digital Unix.

L’architecture de la plupart des versions d’Unix est semblable à  celle de Windows
NT. Les Figures 1 et 2 montrent respectivement les architectures des deux OS.
Elle présentent, toutes les deux, deux modes de fonctionnement : le mode utilisateur
et le mode kernel. Les applications familières comme les traitements de texte
et les programmes de bases de données s’exécutent en mode utilisateur. Le mode
utilisateur est non privilégié, ce qui signifie que le système restreint
les possibilités des programmes d’accéder directement au matériel et aux ressources
appartenant à  d’autres programmes. La majeure partie du code de l’OS s’exécute
en mode kernel. Le mode kernel est privilégié, ce qui signifie que le code
peut accéder au matériel et aux ressources appartenant à  une application quelconque,
avec très peu de limites.

Solaris, HP/UX et AIX sont à  bien des égards aussi différents l’un de
l’autre que chacun ne l’est de Windows NT

L’une des différences majeures entre l’architecture d’Unix et de Windows NT
réside dans le fait qu’Unix n’intègre pas son système de fenêtrage – c’est-à -dire
le sous-système qui gère l’interface graphique utilisateur pour les applications
– dans le mode kernel, comme c’est le cas de Windows NT 4.0. En revanche, le système
de fenêtrage d’Unix est une application add-on en mode utilisateur écrite par
ses développeurs au moyen d’API Unix publiquement définies ; des produits tiers
peuvent donc remplacer le système de fenêtrage d’Unix. Toutefois la majorité des
Unixiens ont adopté X-Windows du MIT comme standard d’interface graphique
de facto, sinon officielle. Avant Windows NT 4.0, le système de fenêtrage Windows
NT était une implémentation en mode utilisateur, mais Microsoft a estimé que les
performances des applications gourmandes en graphiques s’amélioraient lorsque
le système de fenêtrage fonctionnait en mode kernel.

Les architectures des OS diffèrent également en ce sens que les applications Unix
peuvent appeler directement les fonctions du kernel, ou appels système.
Dans Windows NT, les applications appellent les API exportées par l’environnement
de l’OS pour lequel elles sont codées (DOS, Windows 3.x, OS/2, POSIX). Une interface
d’appels système du kernel fournit des API pour gérer les processus, la mémoire
et les fichiers. L’interface d’appels système de Windows NT, baptisée API native,
est cachée aux programmeurs et très peu documentée. Le nombre d’appels système
Unix est à  peu près équivalent à  celui des API natives, soit de 200 à  300. L’API
vers laquelle écrivent les applications Unix est l’interface d’appels système
Unix, alors que celles vers laquelle écrivent la plupart des applications Windows
NT est l’API Win32, qui traduit un grand nombre d’appels API Win32 en API natives.

Espace de noms et gestion des objets

L’espace de noms d’un OS donne aux applications la possibilité d’identifier
et de partager des ressources. La partie la plus visible de l’espace de noms d’un
OS est sans doute l’espace de noms du système de fichiers, qui contient dans Unix
des noms tels que /usr/mark/bin/csh et, dans Windows NT, des noms comme
C:\BIN\CSH.EXE. Parmi les autres ressources exigeant des noms pour permettre à 
deux ou plusieurs applications de les identifier de manière unique pour le partage,
se trouvent celles de synchronisation (par exemple mutants, sémaphores, événements
de notification) et la mémoire partagée.

Le sous-système Gestionnaire des objets de Windows NT implémente l’espace de noms
de Windows NT. Ce Gestionnaire se compose d’un ensemble de fonctions du kernel
assurant la gestion uniforme des ressources, l’attribution de noms et la sécurité
aux applications et à  d’autres sous-systèmes en mode kernel. Ces derniers définissent
les objets du Gestionnaire des objets pour représenter les types de ressources
des sous-systèmes, et reposent sur les sous-programmes de support du Gestionnaire
des objets pour les noms et la sécurité.
Ainsi, le Gestionnaire des objets représente les processus comme des objets processus,
les fichiers comme des objets fichiers et les sémaphores comme des objets sémaphores.
Le mécanisme de suivi des objets du Gestionnaire des objets indique à  un sous-système
possédant un objet lorsque les applications ferment, ouvrent ou demandent l’objet.
La notification adressée par le Gestionnaire des objets aux sous-systèmes se fait
via des méthodes, que les sous-systèmes enregistrent lorsqu’ils définissent un
type d’objet. En réponse à  la notification du Gestionnaire, un sous-système peut
accomplir des actions spécifiques au type de l’objet géré par le sous-système.

L’espace de noms du Gestionnaire des objets permet l’attribution de nom de tout
objet, ainsi que l’accès à  l’espace de noms du file system familier implémenté
par le sous-système Gestionnaire d’E/S. Le nom de système de fichiers C:\BIN\CSH.EXE
est le nom du fichier csh.exe. Dans le kernel de Windows NT, le nom de csh.exe
est \Device\Harddisk0\Partition1\BIN\CSH. Il s’agit du nom d’un objet périphérique
dans l’espace de noms du Gestionnaire des objets ; ce périphérique est une voie
d’accès à  l’espace de noms du système de fichiers du Gestionnaire d’E/S. Un objet
baptisé \Registry dans l’espace de noms du Gestionnaire des objets est une voie
d’accès identique à  l’espace de noms du Registre.

Dans le modèle d’objet de Windows NT, les drivers de périphériques peuvent facilement
mettre en oeuvre des objets dans l’espace de noms. Par exemple, un driver de périphérique
peut créer un objet baptisé \Proc qui, une fois lu par une application, renvoie
des informations sur les processus actifs dans le système.

Le mécanisme de suivi des objets d’Unix n’est pas aussi formel que celui de Windows
NT. L’espace de noms d’Unix est centré sur le système de fichiers de l’OS et s’est
développé à  partir de l’espace de noms du système de fichiers Unix original. Les
structures de données baptisées vnodes (ou inodes dans certaines variantes
plus anciennes d’Unix) sont l’équivalent des objets du Gestionnaire des objets
de Windows NT et représentent des fichiers, la mémoire partagée, des objets de
synchronisation et des ressources non-standards. (Dans cet article j’utilise le
terme vnode pour désigner à  la fois les inodes et les vnodes). L’exemple de nom
de système de fichiers Unix que j’ai donné précédemment, /usr/mark/bin/csh n’a
aucune traduction dans le kernel. Mais tout élément de ce nom peut servir de lien
avec un espace de noms différent implémenté par un driver de système de fichiers
particulier. Traditionnellement, le répertoire /dev se trouvant dans l’espace
de noms Unix contient des objets qui sont des voies d’accès à  des espaces de noms
autres que les systèmes de fichiers (tous les fournisseurs d’espaces de noms dans
Unix agissent comme des drivers de périphériques).
Ainsi /dev/proc est habituellement une voie d’accès à  un driver de processus.
Une application lisant dans le fichier peut obtenir des informations sur les processus
en cours d’exécution sur le système.

Le code de support du système de fichiers d’Unix notifie aux drivers de systèmes
de fichiers les actions opérées par les applications sur les vnodes gérés par
les systèmes de fichiers. Le code de support réalise cette notification en appelant
les fonctions enregistrées dans une table, que le système de fichiers associe
aux vnodes possédant le système de fichiers.
Par exemple, le code de support appelle le système de fichiers chaque fois qu’une
application ouvre, ferme, ou supprime un objet représenté par le vnode du système
de fichiers.

Les concepts d’espace de noms et de gestion des ressources de NT et Unix sont
semblables quant à  leurs objectifs et même à  leur implémentation. Ils utilisent
tous les deux un espace de noms hiérarchique identique à  un espace de noms de
système de fichiers traditionnel et mettent en oeuvre des fonctions de notification
des objets et la gestion des comptes de références. Cette similitude des mécanismes
de support des objets découle de l’objectif, commun à  Windows NT et Unix, de fournir
une infrastructure de suivi des ressources généralisée intégrée à  l’espace de
noms.

Les concepts d’espace de noms et de gestion des ressources de NT et Unix
sont semblables dans à  leurs objectifs et leurs implémentations

Gestion des processus

La gestion des processus englobe à  la fois la manière dont l’OS définit et
implémente les applications des utilisateurs et la méthode utilisée pour diviser
le temps CPU (ou la ressource processeur) entre plusieurs applications actives.
Windows NT et Unix sont des OS temps partagé, qui essaient de diviser le temps
de CPU équitablement entre applications rivales. Aucun des deux OS ne convient
aux environnements nécessitant des garanties rigoureuses de réactivité des applications.
Toutefois ils offrent tous deux des modes d’exécution plus réactifs que leurs
modes standards, si bien qu’ils sont en mesure d’exécuter, avec un certain degré
d’efficacité, des applications requérant un  » temps presque réel « . La manière
dont un OS gère les processus a un impact significatif sur sa capacité à  évoluer
vers des systèmes multiprocesseurs.

Windows NT définit une application au moyen d’un objet processus servant
de conteneur pour toutes les informations de l’application. L’objet processus
comprend la définition de l’espace mémoire contenant le code et les données de
l’application, une table qui identifie les ressources auxquelles l’application
accède, des informations statistiques concernant l’exécution de l’application,
l’identité de l’utilisateur avec lequel l’application est associée et un ou plusieurs
threads d’exécution. L’ordonnanceur de Windows NT répartit le temps entre les
threads (non entre les applications). Un thread est un état d’exécution de kernel
qui détermine en quel point d’une application le système devrait exécuter le code.
Les applications peuvent créer des threads supplémentaires et tous les threads
d’une application partagent ses ressources et son espace mémoire.

L’ordonnanceur de NT tente toujours de donner du temps CPU au thread disponible
ayant la priorité la plus élevée. Il définit deux catégories d’ordonnancement
: dynamique et temps réel. Les threads s’exécutant avec des priorités appartenant
à  la moitié dynamique du spectre des priorités ont un niveau de priorité compris
entre 1 et 15 (les numéros les plus élevés correspondent aux priorités les plus
élevées). Cette série est qualifiée de dynamique, parce que l’ordonnanceur peut
moduler les priorités des threads en boostant temporairement leur niveau de priorité
en fonction de divers événements, comme la frappe d’une touche du clavier. Les
valeurs des priorités des threads de la série temps réel vont de 16 à  31 et sont
fixes ; l’ordonnanceur ne les module pas. Normalement, seul un petit nombre de
threads possédés par l’OS s’exécutent dans la plage temps réel. Lorsque l’ordonnanceur
donne au thread accès à  la CPU, la longueur de l’accès, baptisée quantum
(tranche), se trouve dans la plage de 20 à  120 millisecondes. Lorsque le quantum
d’un thread est dépassé, ou si le thread cède son tour plus tôt que prévu, l’ordonnanceur
programme à  tour de rôle les autres threads ayant la même priorité (s’il en existe).

Windows NT supporte le SMP. Dans les systèmes SMP, toutes les CPU sont identiques
et ont un accès équivalent à  la mémoire et aux périphériques d’E/S. Les structures
de données internes de NT limitent son utilisation à  un maximum de 32 processeurs,
mais les limitations posées par les licences restreignent habituellement le nombre
de processeurs à  8, voire moins encore. Windows NT tourne rarement sur des systèmes
ayant plus de 8 CPU. L’une des caractéristique importantes de l’ordonnanceur de
Windows NT est de pouvoir préempter totalement le kernel.
Par exemple, même si un thread est en cours d’exécution dans le kernel, l’ordonnanceur
peut mettre un terme au tour de ce thread et en mettre un autre à  sa place. En
outre plusieurs threads peuvent simultanément exécuter activement du code kernel
sur des CPU distinctes. Les fonctions de préemption du kernel et d’exécution du
code kernel sur des CPU séparées sont nécessaires pour l’évolutivité des multiprocesseurs.

La gestion des processus dans la plupart des variantes modernes d’Unix est semblable
à  celle de Windows NT. Les deux OS utilisent la structure de données d’un processus
pour définir des applications. Cette structure englobe à  peu près les mêmes composants
qu’un processus Windows NT, à  savoir un espace adressable, des identificateurs
(handles) de ressources, et des statistiques.
De plus, les variantes récentes d’Unix divisent le temps de CPU entre les threads
du mode kernel et définissent les processus comme ayant au moins un thread.

Les ordonnanceurs Unix mettent habituellement en oeuvre trois catégories de priorité
– temps réel, système, et dynamique – couvrant des numéros de priorité allant
de 0 à  100. Les numéros de priorité les plus bas identifient les threads ayant
la priorité la plus élevée. Les catégories de priorité  » temps réel  » et  » système
 » d’Unix s’apparentent à  la classe temps réel de Windows NT, en ce sens que l’ordonnanceur
d’Unix ne modifie pas les priorités des threads s’exécutant dans ces catégories.
En revanche, il peut abaisser la priorité (c’est-à -dire monter le numéro) des
threads qui s’exécutent dans la catégorie dynamique, lorsque ceux-ci continuent
à  s’exécuter sans céder leur tour volontairement. La longueur du quantum d’un
ordonnanceur Unix est identique à  la celle de Windows NT : de dix à  plusieurs
centièmes de millisecondes.

Le support SMP d’Unix est plus avancé que celui de Windows NT : jusqu’à 
32 processeurs et plus

Le support SMP d’Unix est plus avancé que celui de Windows NT. Plusieurs variantes
d’Unix, dont HP/UX, Solaris et AIX, tournent sur des systèmes SMP à  32 CPU et
plus. Certaines versions d’Unix peuvent même tourner sur des multiprocesseurs
asymétriques. Tout comme celui de Windows NT, les kernels de la plupart des implémentations
Unix sont totalement préemptifs et simultanément exécutables sur différentes CPU.

Windows NT et Unix ont beaucoup de points communs en matière de gestion des processus
: ils définissent tous les deux les applications comme des processus ayant un
ou plusieurs threads de kernel. Les différences entre NT et Unix impliquent la
distinction de systèmes et de subtilités de priorités dans les algorithmes d’ordonnancement.
Une différence notable tient, par exemple, à  ce que Windows NT booste les priorités
des threads dynamiques par réaction à  des événements tels que la saisie, alors
qu’Unix abaisse les priorités des threads dynamiques au fur et à  mesure qu’ils
consomment de la CPU. Les deux OS essaient de traiter les threads tributaires
de l’unité centrale et gourmands en E/S à  égalité avec les autres threads, mais
chacun traite cette tâche différemment.

Gestion de mémoire

Le gestionnaire de mémoire d’un OS est chargé de définir des espaces adressables
virtuelles pour le code et les données applicatives et de partager la mémoire
physique de l’ordinateur entre différentes applications. Un gestionnaire de mémoire
devrait attribuer davantage de mémoire physique aux applications nécessitant une
grande quantité de mémoire, tout en restant réactif aux besoins de toutes les
applications. Les stratégies et l’implémentation du gestionnaire de mémoire déterminent
la manière dont l’OS supporte plusieurs applications simultanément.

Le Gestionnaire de mémoire de Windows NT définit une cartographie d’adresses virtuelles
32 bits, schématisée dans la Figure 3, allant de 2 à  4 Go. L’espace est divisé
entre le code et les données des applications du mode utilisateur, et le code
et les données du mode kernel. Habituellement, Windows NT attribue les 2 Go inférieurs
(c’est-à -dire de 0 à  2 Go) au mode utilisateur – cet espace s’appelle l’espace
utilisateur – et les 2 Go supérieurs (c’est-à -dire de 2 à  4 Go) au mode kernel
; c’est l’espace kernel. Windows NT ne donne pas aux applications l’accès
direct à  la partie de l’espace adressable du mode kernel ; certaines versions
de Windows NT (par exemple Windows NT Server 4.0 Enterprise Edition) supportent
un switch qui modifie la division de l’espace adressable virtuel, avec 3 Go pour
l’espace utilisateur et 1 Go pour le kernel. L’espace kernel mappe en permanence
le kernel et les drivers de périphériques de Windows NT, mais le mapping de l’espace
utilisateur change pour correspondre au thread en cours d’exécution.
Par exemple, si un thread de Microsoft Word s’exécute, le code et les données
de Word sont mappés dans l’espace utilisateur. Mais si l’ordonnanceur bascule
vers un thread Lotus Notes, le Gestionnaire de mémoire met à  jour l’espace utilisateur
avec le code et les données de Lotus Notes.

Le Gestionnaire de mémoire de Windows NT met en oeuvre la mémoire virtuelle paginée
à  la demande, qui consiste à  introduire le code et les données en mémoire physique
lorsqu’une application y accède. Le Gestionnaire de mémoire implémente les fonctions
indispensables à  un OS moderne, à  savoir, notamment, permettre aux applications
de partager des tranches d’adresses avec d’autres applications ; permettre le
copy-on-write pour un partage efficace de la mémoire ; permettre le mapping des
fichiers en mémoire. Les fichiers mappés en mémoire permettent aux applications
de lire et modifier efficacement les données des fichiers ; tous les changements
apportés par l’application au fichier mappé sont automatiquement reflétés sur
l’image du fichier sur disque.

Windows NT fonde sa gestion de la mémoire physique sur l’attribution à  chaque
application de limites supérieures et inférieures. En langage Windows NT, la quantité
de mémoire physique allouée à  une application est son working set. Lorsqu’une
application atteint la limite supérieure de son working set et accède à  davantage
de données ou de code, le Gestionnaire de mémoire utilise un algorithme d’ancienneté
(LRU), ou algorithme de l’horloge, pour trouver les données du working
set à  remplacer. Lorsque le Gestionnaire de mémoire doit introduire des données
ou du code à  partir d’un fichier sur le disque, il introduit légèrement plus que
ne le demande l’application. Cette optimisation est baptisée clustering
(groupage).

La plupart des gestionnaires de mémoire Unix sont généralement semblables à  celui
de Windows NT. Les gestionnaires de mémoire Unix définissent un espace adressable
virtuel divisé entre l’espace utilisateur et l’espace kernel. Certaines variantes
d’Unix mettent en oeuvre les mêmes espaces utilisateur et kernel que Windows NT,
soit respectivement 2 et 2 Go, ou 3 et 1 Go.
En revanche, d’autres variantes d’Unix donnent la majorité de l’espace adressable
aux applications, en réservant seulement quelques centaines de Mo pour le kernel.
Tout comme celui de Windows NT, les gestionnaires de mémoire d’Unix mettent en
oeuvre la mémoire virtuelle paginée à  la demande et supportent la mémoire partagée,
copy-on-write, et les fichiers mappés en mémoire.

Une comparaison point par point de la gestion de mémoire de Windows NT
et Unix révèle beaucoup de similitudes

Les gestionnaires de mémoire Unix diffèrent de celui de Windows NT en ce sens
qu’ils gèrent la mémoire globalement – ils ne contraignent pas les applications
individuelles par des limites supérieures et inférieures.
En outre, lorsqu’une application Unix accède à  du code ou à  des données devant
être mis en mémoire, le gestionnaire de mémoire utilise l’algorithme d’ancienneté,
ou une variante proche, pour trouver les données ou le code appartenant à  une
application – pas nécessairement celle en train d’effectuer l’accès – pour remplacer
le code ou les données qu’il mappe en mémoire. Cette politique permet aux applications
Unix gourmandes en mémoire de priver d’autres programmes, au risque de provoquer
un goulot d’étranglement des performances connu sous le nom de thrashing.
Pour résoudre les problèmes de thrashing, la plupart des variantes d’Unix ont
un sous-programme de transfert (un processus en tâche de fond), qui fait sortir
des applications entières hors de la mémoire. Le programme de transfert bascule
donc les applications pour soulager une situation de thrashing.

Une comparaison point par point de la gestion de mémoire de Windows NT et Unix
révèle beaucoup de similitudes : implémentation de la mémoire virtuelle paginée
à  la demande, définitions similaires d’espace adressable et utilisation de variantes
de l’algorithme d’ancienneté pour le remplacement des données en mémoire. Les
deux OS diffèrent néanmoins sur plusieurs points : Windows NT gère la mémoire
par processus, alors qu’Unix la gère globalement. Unix fait appel au swapping
pour éviter le thrashing, alors que Windows NT évite cette situation, grâce à 
la gestion par processus.
D’autres différences sont plus importantes. Ainsi, plusieurs variantes d’Unix,
dont Solaris, HP/UX et Digital Unix peuvent utiliser les espaces adressables 64
bits sur les processeurs 64 bits. Il n’existera pas de version 64 bits de Windows
NT avant au moins un an. L’utilisation des espaces adressables 64 bits peut booster
les performances des applications de serveurs gourmands en données tels que les
serveurs de bases de données.

Sécurité

Un OS moderne peut assurer la protection des données sensibles de ses utilisateurs
: les caractéristiques de ses sous-systèmes de sécurité jouent un rôle déterminant
pour la sécurité globale. Les fonctions de sécurité de NT ont obtenu un classement
C2 (en tant que système autonome non mis en réseau), considéré comme le niveau
minimum requis pour un OS moderne. Le modèle de sécurité de NT repose sur les
concepts d’utilisateurs et de groupes d’utilisateurs.
Windows NT définit les utilisateurs comme ayant certains privilèges, tels que
la capacité d’arrêter l’ordinateur, de sauvegarder des fichiers ou de charger
des drivers de périphériques. Les utilisateurs de Windows NT peuvent appartenir
à  un nombre quelconque de groupes. Le support de la sécurité centralisée du Gestionnaire
des objets de signifie que ce dernier peut sécuriser tout objet – y compris des
objets de synchronisation, la mémoire partagée et les fichiers.

Windows NT spécifie les paramètres de sécurité d’un objet en mettant en oeuvre
des ACL (Access Control List, listes de contrôle d’accès). L’ACL d’un objet peut
avoir un nombre quelconque de valeurs de contrôle d’accès (Access Control Entry,
ACE), chacune spécifiant les actions qu’un utilisateur ou un groupe particulier
peut effectuer sur cet objet.
Cette flexibilité permet aux administrateurs de contrôler précisément l’accès
à  un objet. La possibilité pour NT d’auditer le succès ou l’échec des tentatives
d’accès à  un objet, contribue également à  satisfaire aux impératifs de sécurité
C2. Windows NT met en oeuvre l’audit de contrôle de la même manière que le contrôle
des accès, c’est-à -dire en affectant aux objets des ACE d’audit définissant quelles
sont les actions des utilisateurs ou des groupes qui génèrent un enregistrement
d’audit. Le modèle de sécurité NT se caractérise par une autre fonction puissante
qui permet aux applications de maintenir des informations de sécurité pour leurs
objets (définis à  titre privé) et d’utiliser des API de sécurité pour valider
l’accès des clients à  ces objets.

Le modèle de sécurité Unix de base est beaucoup moins puissant. Tout comme Windows
NT, Unix peut attribuer aux utilisateurs l’adhésion à  un groupe, mais les groupes
Unix n’ont pas de privilèges de sécurité.
En revanche, Unix repose sur un compte d’utilisateur spécial, ou racine, pouvant
contourner tous les paramètres de sécurité. La sécurité d’Unix n’étant pas ouverte
aux applications, la sécurité ne s’applique qu’aux fichiers. Un fichier est défini
en fonction d’un utilisateur et d’un groupe qui en est propriétaire, et des drapeaux
identifient les actions de lecture, écriture et exécution que l’utilisateur du
fichier, le groupe, ou quiconque peut effectuer sur le fichier.

L’absence d’ACL et d’audit empêche la souche commune d’Unix de bénéficier
du classement de sécurité C2

L’absence d’ACL et d’audit empêche la souche commune d’Unix de bénéficier
du classement de sécurité C2. Cette situation a conduit pratiquement tous les
acteurs significatifs du monde Unix à  créer une version propriétaire implémentant