Au cœur d’UNIX et de Windows

Deux familles de systèmes d’exploitation couvrent presque tout. Chaque téléphone, serveur, portable et ordinateur de bureau en service aujourd’hui fait tourner un descendant de l’un ou de l’autre : Linux et Android, macOS et iOS du côté d’UNIX, Windows de l’autre. Ce chapitre les compare (histoire, structure, appels système, mémoire, fichiers, processus) avec les systèmes actuels et de vraies mesures.

Deux arbres généalogiques

UNIX a été écrit aux Bell Labs à partir de 1969 par Ken Thompson et Dennis Ritchie, d’abord en assembleur du PDP-7, puis, à partir de 1973, en C, le langage que Ritchie avait créé pour lui. AT&T l’a concédé à bas prix aux universités, avec son code source, et l’université de Californie à Berkeley en a fait BSD, en y ajoutant la mémoire virtuelle paginée, les noms de fichiers longs et la pile réseau TCP/IP sur laquelle a grandi Internet. La lignée d’AT&T est devenue System V. La séparation entre les deux a rendu les logiciels UNIX difficiles à porter, jusqu’à ce que la norme POSIX définisse une interface commune.

L’arbre se ramifie ensuite jusqu’aux systèmes d’aujourd’hui :

• En 1987 paraît MINIX, un petit système de type UNIX destiné à l’enseignement. Un étudiant finlandais qui l’avait étudié, Linus Torvalds, a commencé à écrire son propre noyau en 1991 : Linux. Associé aux outils du projet GNU, il est devenu un système complet, puis le noyau d’Android.
• BSD survit dans FreeBSD, NetBSD et OpenBSD, ainsi que dans les systèmes d’Apple : NeXTSTEP, chez NeXT, associait le noyau Mach à BSD, et quand Apple a racheté NeXT, il est devenu Mac OS X en 2001, aujourd’hui macOS, iOS et leurs cousins. Apple fait certifier macOS selon la norme UNIX 03 depuis 2007 : c’est officiellement un UNIX. Linux n’est pas certifié, mais se comporte comme tel.

Windows a deux lignées. La première, MS-DOS et les Windows 3.x, 95, 98 et Me construits dessus, est éteinte. La seconde est Windows NT, un système 32 bits entièrement nouveau conçu par une équipe dirigée par Dave Cutler, venu du VMS de DEC, et sorti en 1993. Windows 2000, XP, Vista, 7, 8, 10 et 11 sont tous des NT ; le support de Windows 10 a pris fin en octobre 2025, laissant Windows 11. NT était portable dès l’origine (les premières versions tournaient sur x86, MIPS et Alpha), et il tourne aujourd’hui sur x86-64 et ARM64.

Les systèmes se présentent eux-mêmes. Sur le Mac où ce chapitre a été écrit :

$ sw_vers
ProductName:    macOS
ProductVersion: 26.6.2
BuildVersion:   25G83
$ sysctl kern.version
kern.version: Darwin Kernel Version 25.6.0: Fri Jul 31 19:18:48 PDT 2026; root:xnu-12377.161.14~5/RELEASE_ARM64_T6020

et dans la machine virtuelle Linux du même ordinateur :

$ cat /proc/version
Linux version 6.12.76-linuxkit (root@buildkitsandbox) (gcc (Alpine 15.2.0) 15.2.0, GNU ld (GNU Binutils) 2.45.1) #1 SMP Thu Apr 30 11:19:05 UTC 2026

Le noyau de macOS est XNU, celui de Darwin, ici dans sa version 12377 ; le noyau Linux est la version 6.12, compilée avec GCC 15.2.

Trois structures de noyau

L’image classique d’UNIX est celle d’un noyau unique contenant le système de fichiers, le cache de blocs, les pilotes de périphériques, la gestion des processus, l’IPC, l’ordonnancement et la gestion mémoire, avec le shell et tous les programmes à l’extérieur. Linux est toujours construit ainsi : un noyau monolithique, un gros programme qui tourne en mode noyau, dont chaque partie peut appeler directement n’importe quelle autre. Il n’est pas figé pour autant : pilotes et systèmes de fichiers peuvent être compilés en modules chargeables et ajoutés au noyau en marche. Mais une fois chargé, un module est aussi privilégié que le reste, et un bug dans n’importe quel pilote peut faire tomber tout le système.

Windows NT est qualifié d’hybride. Sa structure : une couche d’abstraction du matériel (HAL) tout en bas ; au-dessus, le noyau proprement dit (traitement des déroutements, ordonnancement, synchronisation) et l’exécutif (processus et threads, mémoire virtuelle, gestionnaire d’objets, gestionnaire d’E/S, gestionnaire de cache, moniteur de sécurité), réunis dans ntoskrnl.exe ; les pilotes à côté, le tout en mode noyau. La conception initiale de NT laissait davantage en mode utilisateur, plus près d’un micronoyau ; NT 4.0 a fait entrer le gestionnaire de fenêtres et le graphisme dans le noyau, sous la forme de win32k.sys, pour gagner en vitesse.

XNU est lui aussi un hybride, d’un autre genre : le micronoyau Mach de Carnegie Mellon, qui fournit tâches, threads, mémoire virtuelle et ports de messages ; une couche BSD par-dessus pour les processus, les appels système POSIX, les fichiers et le réseau ; et I/O Kit, un cadre pour les pilotes écrit dans un C++ restreint. Contrairement à un vrai micronoyau, les trois tournent ensemble en mode noyau. La seule conception de noyau qu’aucun des trois n’a adoptée est le véritable micronoyau, où pilotes et systèmes de fichiers sont des processus séparés en mode utilisateur, ce que fait MINIX 3.

Les interfaces d’appels système

Les appels système d’UNIX sont peu nombreux et documentés : la première partie de POSIX en définissait une soixantaine, et les UNIX du début des années 2010 environ 200 ; Linux sur ARM 64 bits numérote désormais ses appels jusqu’à 450. Les programmes peuvent les appeler directement, et Linux garde leurs numéros stables pour toujours, comme l’a décrit le chapitre sur les appels système. Dans le simulateur, qui suit la numérotation de Linux x86-64 :

getpid renvoie 1000 et getppid renvoie 1 : le parent du processus simulé est init. Les mêmes appels portent des numéros différents sur chaque système, même au sein d’une même famille de processeurs :

Les numéros de macOS sont ceux de BSD, vieux de plusieurs décennies : fork vaut 2 et exit 1. Le sys/syscall.h de son SDK en définit 459, numérotés jusqu’à 557, et XNU en a un second jeu, les Mach traps, pour les services propres à Mach. Mais Apple, contrairement à Linux, ne prend en charge que les appels passés par sa bibliothèque système.

Windows va plus loin. L’interface documentée est l’API Win32 (qui couvre aujourd’hui aussi Windows 64 bits), une vaste bibliothèque de fonctions dans des DLL comme kernel32.dll. Sa philosophie est l’inverse de l’ensemble minimal d’UNIX : Win32 se veut complète, offre souvent plusieurs façons de faire la même chose, et contient des fonctions qui ne sont pas du tout des appels système, comme CopyFile. En dessous se trouve l’API native de ntdll.dll (NtCreateFile, NtWriteFile), qui fait les vrais appels système, et dont les numéros changent d’une version de Windows à l’autre. Un programme Windows ne les voit jamais. Compilée pour Windows, l’ouverture d’un fichier ressemble à ceci :

open_it:
    sub   rsp, 0x38
    mov   qword ptr [rsp + 0x30], 0x0      ; 7th argument: template file
    mov   dword ptr [rsp + 0x28], 0x0      ; 6th: flags and attributes
    mov   dword ptr [rsp + 0x20], 0x3      ; 5th: OPEN_EXISTING
    mov   edx, 0x80000000                  ; 2nd: GENERIC_READ (1st, the name, is already in rcx)
    xor   r8d, r8d                         ; 3rd: no sharing
    xor   r9d, r9d                         ; 4th: default security
    call  qword ptr [rip + __imp_CreateFileW]

Sept arguments, quatre dans des registres (rcx, rdx, r8, r9 selon la convention d’appel de Windows) et trois sur la pile, et un appel indirect à travers la table d’importation, que le chargeur remplit avec l’adresse de CreateFileW dans kernel32.dll. Cette fonction appellera NtCreateFile dans ntdll.dll, qui exécute syscall. L’équivalent UNIX, open(name, O_RDONLY), prend deux arguments.

Là où UNIX a des descripteurs de fichiers, Windows a des handles : des numéros qui désignent des objets du noyau de toute sorte (fichiers, processus, threads, événements, mutex, clés du registre) à travers une table de handles propre à chaque processus, avec un descripteur de sécurité sur chaque objet. Le « tout est fichier » d’UNIX a son pendant sous Windows : tout est objet.

Processus et threads

UNIX crée les processus avec fork et exec, décrits dans le chapitre sur les processus. Windows crée un processus et y charge son programme en un seul appel, CreateProcess, qui prend dix paramètres. Windows ne tient aucune hiérarchie parent-enfant, même si le handle que reçoit le créateur lui donne la main sur l’enfant.

Les modèles de threads diffèrent plus par la forme que par le fond. Dans NT, un processus est un conteneur (un espace d’adressage, une table de handles, un jeton de sécurité), et les threads sont ce que l’ordonnanceur exécute. Linux n’a pas d’objet thread séparé : chaque thread est une tâche, comme un processus, créée par clone avec des options qui partagent l’espace d’adressage, les fichiers et les gestionnaires de signaux, et un « processus » est un groupe de tâches partageant un même identifiant. XNU suit Mach : une tâche détient l’espace d’adressage et les ressources, des threads s’y exécutent, et une structure de processus BSD se superpose à chaque tâche.

Les compter montre ce que fait tourner chaque système. Sur le Mac, top indiquait 1 240 processus et 10 462 threads : le bureau, ses services et les applications ouvertes. Dans la VM Linux derrière Docker, la liste de tous les processus en montrait 303, dont 288 threads du noyau (les enfants de kthreadd : travailleurs par CPU, rappels RCU, auxiliaires d’E/S), et seulement une douzaine de programmes en espace utilisateur : /initd (l’init de la VM, avec 12 threads), containerd, dockerd, quelques démons RPC et un login. En comptant les threads, on arrivait à 428 tâches. Une VM de serveur peut être presque vide ; un système de bureau ne l’est jamais.

La mémoire

On résume classiquement la mémoire d’UNIX à trois segments par processus (code, données qui montent, pile qui descend), avec mmap pour projeter des fichiers. C’est toujours le cœur du modèle, même si un vrai espace d’adressage, comme le montre /proc/self/maps, compte des dizaines de régions : bibliothèques, tas, piles des threads, projections anonymes. Windows sépare la réservation d’espace d’adressage de l’engagement (commit) de mémoire : VirtualAlloc peut réserver une grande plage sans rien imputer à la mémoire, puis engager des pages au besoin, et MapViewOfFile projette des fichiers. Les deux paginent à la demande, les deux copient sur écriture, les deux utilisent les mécanismes du chapitre sur la mémoire virtuelle.

Les processus Windows 64 bits disposaient de 8 To d’espace d’adressage utilisateur jusqu’à Windows 8 ; depuis Windows 8.1, c’est 128 To, comme Linux sur x86-64.

Les fichiers

Le duo classique était le système de fichiers de l’UNIX d’origine, avec ses inodes de 64 octets, et NTFS, avec sa table maîtresse des fichiers. Aujourd’hui, ce sont ext4 ou XFS sous Linux, APFS sur les systèmes d’Apple, et toujours NTFS sous Windows, comme le décrit le chapitre sur les fichiers. Les modèles de nommage diffèrent toujours. UNIX a une seule arborescence partant de /, où chaque disque est monté quelque part ; Windows garde les lettres de lecteur, C:\, avec des barres obliques inversées héritées de MS-DOS, même si NTFS peut aussi monter des volumes dans des dossiers. NTFS peut stocker des noms qui ne diffèrent que par la casse, mais Win32 traite FOO et foo comme le même fichier ; les volumes APFS de macOS sont eux aussi insensibles à la casse par défaut, alors que les systèmes de fichiers de Linux y sont sensibles.

Les modèles de sécurité

Dans le modèle d’UNIX, chaque fichier a un propriétaire, un groupe et trois jeux de bits lecture, écriture et exécution, et chaque processus s’exécute sous un utilisateur et des groupes ; le superutilisateur, root, contourne les vérifications. Les vrais systèmes ont ajouté des couches : listes de contrôle d’accès, capacités de Linux (qui découpent le pouvoir de root en morceaux), politiques obligatoires comme SELinux et AppArmor, et sous macOS la protection de l’intégrité du système (SIP), qui empêche même root de modifier le système, plus des bacs à sable par application et des autorisations de confidentialité.

Le modèle de Windows est plus riche dès le départ : chaque processus porte un jeton d’accès avec le SID de l’utilisateur, ses groupes et ses privilèges, et chaque objet porte un descripteur de sécurité avec une ACL, dont les entrées autorisent ou refusent des opérations précises à des SID précis. Vista a ajouté les niveaux d’intégrité, qui empêchent par exemple le processus de faible intégrité d’un navigateur d’écrire dans les fichiers ordinaires, même pour le même utilisateur, et le contrôle de compte d’utilisateur (UAC), qui donne aux administrateurs un jeton limité tant qu’ils n’ont pas approuvé l’élévation.

Les appels de synchronisation classiques de Windows restent pour l’essentiel valables, à une exception près : PulseEvent, censé libérer tous les threads qui attendent un événement, est aujourd’hui documenté par Microsoft comme peu fiable, à ne pas utiliser.

Où ils tournent aujourd’hui

• Linux fait tourner la plupart des serveurs et presque tout le cloud, chacun des 500 supercalculateurs les plus rapides (c’est vrai de chaque liste TOP500 depuis novembre 2017), et, comme noyau d’Android, la plupart des téléphones du monde. Il tourne aussi à l’intérieur des deux autres : dans la VM de Docker sur ce Mac, et dans WSL 2 sous Windows, qui depuis 2019 exécute un vrai noyau Linux dans une machine virtuelle Hyper-V légère.
• Windows reste le système de la plupart des PC de bureau et portables, et de nombreux serveurs d’entreprise.
• XNU, sous les noms de macOS, iOS, iPadOS et leurs variantes, fait tourner tous les appareils d’Apple.

UNIX et Windows diffèrent plus par leur philosophie que par leurs capacités. Les deux ont une mémoire virtuelle paginée à la demande, des threads préemptifs, des systèmes de fichiers riches, un contrôle d’accès et la virtualisation matérielle. Les différences se situent aux interfaces : un petit ensemble stable d’appels système contre une vaste bibliothèque posée sur des appels instables ; des descripteurs de fichiers contre des handles ; fork contre CreateProcess.

À retenir

• UNIX (1969) a donné BSD, System V et POSIX, puis Linux (1991) et, via NeXTSTEP, macOS et iOS. Windows NT (1993) est la base de tous les Windows actuels.
• Linux est un noyau monolithique à modules chargeables ; NT un hybride fait d’une HAL, d’un noyau, d’un exécutif et de pilotes en mode noyau ; XNU réunit Mach, BSD et I/O Kit, tous en mode noyau.
• UNIX offre un petit ensemble d’appels système documentés, avec des numéros différents sur chaque système (getppid vaut 110, 173 ou 39). Les programmes Windows utilisent l’API Win32, qui appelle l’API native de ntdll.dll, dont les numéros d’appels système changent d’une version à l’autre.
• Les threads de Linux sont des tâches créées par clone ; NT et XNU séparent le processus (ou la tâche) de ses threads. Ce Mac faisait tourner 1 240 processus et 10 462 threads ; la VM Linux 303 processus, dont 288 threads du noyau.
• UNIX désigne les choses par des descripteurs de fichiers, Windows par des handles vers des objets du noyau. La sécurité repose sur utilisateur, groupe et bits de droits plus des couches ajoutées sous UNIX, sur des jetons, des SID et des ACL sous Windows.
• Linux domine les serveurs, les supercalculateurs et les téléphones ; Windows, les PC ; XNU, les appareils d’Apple.