Windows NT vs. Unix : comparaison de conception

• NT a souvent été considéré comme un système d’exploitation « très avancé », sans que l’auteur comprenne vraiment pourquoi
  • Fin 2023, après avoir lu la 1re édition de Inside Windows NT, il a décidé de comparer NT et Unix
  • Il s’agit d’une comparaison entre la conception de NT (juillet 1993) et celle des systèmes Unix de l’époque (4.4BSD, Linux 1.0)
  • En tant que spécialiste d’Unix, l’auteur connaît moins bien NT et se concentre donc surtout sur les différences de NT
  • Le texte examine ce que NT faisait mieux qu’Unix, et si c’est toujours le cas aujourd’hui

Mission

• L’histoire d’Unix est bien plus ancienne que celle de NT
  • Le développement d’Unix a commencé en 1969, avec pour objectif principal de fournir une plateforme pratique aux programmeurs
  • Unix s’est inspiré de Multics, mais l’a surpassé en misant sur la simplicité
  • La portabilité et le multitâche ne faisaient pas partie des objectifs initiaux de conception d’Unix : ces fonctions ont été ajoutées plusieurs années plus tard, au fil des nombreux « forks » et réinventions d’Unix
• L’histoire de Microsoft
  • La première version de MS-DOS est sortie en août 1981, et la première version de « Windows hérité » (les versions basées sur DOS) en novembre 1985
  • MS-DOS a connu un large succès, mais Windows n’est vraiment devenu important qu’à partir de Windows 3.0 en mai 1990
  • Windows NT a été imaginé en 1989 et s’est montré au monde avec la sortie de NT 3.1 en juillet 1993
• L’avantage de Microsoft
  • La conception de NT a commencé 20 ans après celle d’Unix, ce qui a donné un avantage à Microsoft
  • Microsoft disposait déjà d’une vaste base d’utilisateurs grâce à MS-DOS et à Windows hérité
  • L’équipe Microsoft qui a conçu NT bénéficiait des enseignements tirés de ces développements, d’une expérience dans la création d’autres systèmes d’exploitation et d’un accès aux technologies récentes, ce qui lui a permis de « viser la lune » avec NT

Noyau

• Unix est implémenté sous la forme d’un noyau monolithique, à quelques exceptions près comme Minix ou GNU Hurd, et expose un ensemble d’appels système permettant d’interagir avec les fonctions fournies par le système d’exploitation
• NT, à l’inverse, se situe à mi-chemin entre noyau monolithique et microkernel : le composant privilégié, l’executive, se présente aux subsystems en espace utilisateur comme un ensemble modulaire de composants
• Les subsystems en espace utilisateur sont des processus spécialisés qui « traduisent » les API utilisées par les applications (POSIX, OS/2, etc.) en appels système de l’executive
• Une partie importante de l’executive de NT est la HAL, qui fournit des primitives d’abstraction pour accéder au matériel de la machine et sert de base au reste du noyau
  • Cette couche est essentielle pour permettre à NT de fonctionner sur diverses architectures, notamment i386, Alpha et PowerPC
  • À l’époque, Unix était lié à des architectures spécifiques : les concepts Unix étaient portables, mais pas leurs implémentations
  • SunOS ne prenait en charge au départ que le Motorola 68000, 386BSD était le premier portage de BSD sur architecture Intel, et IRIX était une variante d’Unix destinée aux stations de travail MIPS de Silicon Graphics
• Une autre partie importante de l’executive de NT est la prise en charge des systèmes multiprocesseurs et d’un noyau préemptif
  • Le noyau comporte plusieurs niveaux d’interruption (SPL dans la terminologie BSD) pour déterminer ce qui peut interrompre quoi, mais le point le plus important est que les threads du noyau peuvent être préemptés par d’autres threads du noyau
  • C’est ce que font aujourd’hui tous les systèmes Unix hautes performances, mais ce n’est pas ainsi que beaucoup d’Unix ont commencé
  • Ces systèmes ont d’abord démarré avec des noyaux ne prenant pas en charge la préemption ou le multiprocesseur, puis ont ajouté la prise en charge du multiprocesseur en espace utilisateur, avant d’ajouter ensuite la préemption du noyau
  • Cette dernière étape est la plus difficile, et la saga de FreeBSD 5.0 illustre bien ces difficultés
  • Il est donc intéressant de voir que NT est parti dès le départ sur de bonnes bases

Objets

• NT est un noyau orienté objet
  • On pourrait penser qu’Unix l’est aussi : les processus sont définis par des struct et les implémentations de systèmes de fichiers manipulent des vnode (« nœuds virtuels », à ne pas confondre avec les inode)
  • Mais ce n’est pas exactement la même chose que ce que fait NT : NT impose que tous ces objets différents partagent une représentation commune dans le système
• On peut douter qu’il soit possible de fournir une abstraction pertinente pour des choses aussi hétérogènes que les processus et les handles de fichier
• En pratique, ce n’est pas vraiment possible, mais NT impose malgré tout que tous héritent d’un type d’objet commun, et cela présente, de manière surprenante, plusieurs propriétés intéressantes
• Contrôle d’accès centralisé
  • Les objets n’étant créés que par l’object manager, il existe un point unique dans le code où appliquer les politiques
  • Des sémantiques comme la vérification des autorisations peuvent être définies à un seul endroit et appliquées uniformément à tout le système, ce qui est puissant
  • NetBSD a également conclu que c’était une bonne idée, mais n’a obtenu le framework Kernel Authorization (kauth) qu’en 2001
• Identité commune
  • Les objets ont un identifiant et sont tous représentés dans un arbre unique
  • Cela signifie qu’il existe un espace de noms unique pour tous les objets, qu’il s’agisse de processus, de handles de fichier ou de pipes
  • Les objets de l’arbre peuvent être adressés par leur nom (chemin), et différentes parties de l’arbre peuvent appartenir à différents sous-systèmes
  • Par exemple, une partie de l’arbre peut représenter un système de fichiers monté ; ainsi, lorsqu’on traverse le nœud racine de ce sous-arbre, le système de fichiers résout le reste du chemin
  • Cela ressemble à la couche VFS des systèmes Unix, mais la VFS ne traite que des systèmes de fichiers, alors que l’arbre d’objets couvre tous les objets du noyau sans exception
  • Unix a tenté d’intégrer des types d’objets non liés aux fichiers dans le système de fichiers via /proc/, /sys/, etc., mais cela donne l’impression d’un ajout a posteriori par rapport à ce que propose NT
• Gestion unifiée des événements
  • Tous les types d’objets possèdent un état signaled, dont la signification varie selon le type d’objet
  • Par exemple, un objet processus passe à l’état signaled lorsque le processus se termine, et un objet handle de fichier passe à l’état signaled lorsqu’une requête d’E/S est terminée
  • Cela facilite énormément l’écriture de code piloté par événements (code async) en espace utilisateur, puisqu’un seul appel système de type wait peut attendre qu’un groupe d’objets change d’état
  • Sur les systèmes Unix, attendre simultanément des E/S et la fin de processus est pénible
• Les objets sont un composant propre à NT et ne se généralisent pas bien à toutes les API que NT cherche à prendre en charge
  • Prenons par exemple le sous-système POSIX : POSIX n’a pas de concept d’objet comme NT, mais NT doit tout de même fournir une certaine forme de compatibilité aux applications POSIX
  • Pour cette raison, lorsque le sous-système POSIX alloue des objets dans l’executive, il doit en parallèle tenir sa propre comptabilité pour représenter ces entités POSIX et effectuer en permanence la conversion logique entre les deux
  • À l’inverse, le sous-système Win32 transmet directement les objets au client, sans intermédiaire

Processus

• Les processus sont un objet commun à NT et à Unix, mais ils ne sont pas totalement identiques
  • Sous Unix, les processus sont représentés sous forme d’arbre : chaque processus a un parent et peut avoir zéro, un ou plusieurs enfants
  • NT, en revanche, n’a pas cette relation : un processus peut « hériter » de ressources de son créateur, mais une fois créé, il devient une entité indépendante
• À l’époque de la conception de NT, les threads étaient encore peu répandus :
  • Mach a été le premier noyau de type Unix à intégrer les threads en 1985
  • Cela signifie que les autres Unix ont dû adopter ce concept plus tard et l’adapter à leur conception existante
  • Linux a choisi, dans la version 2.0 publiée en juin 1996, de représenter les threads comme des processus disposant chacun de leur propre PID, et NetBSD n’a obtenu des threads représentés comme des entités distinctes des processus qu’avec la version 2.0 en 2004
  • Contrairement à Unix, NT a fait le choix de prendre en charge les threads dès le départ, en partant du principe qu’ils étaient indispensables au calcul haute performance sur des machines SMP
• NT ne possède pas de signaux au sens traditionnel d’Unix
  • À la place, il existe des alerts, qui peuvent être en mode noyau ou en mode utilisateur
  • Les alertes en mode utilisateur doivent être attendues comme n’importe quel autre objet, tandis que les alertes en mode noyau ne sont pas visibles par le processus
  • Le sous-système POSIX utilise les alertes en mode noyau pour émuler les signaux
  • Les signaux ont souvent été qualifiés de verrue dans Unix en raison de la façon dont ils interrompent l’exécution des processus : les gérer correctement demande un effort considérable, si bien que l’alternative de NT paraît plus élégante
• Un développement intéressant plus récent dans NT a été l’introduction des picoprocess
  • Jusqu’à l’ajout de cette fonctionnalité, les processus NT étaient assez lourds : un nouveau processus recevait au démarrage un ensemble de bibliothèques d’exécution NT mappées dans son espace d’adressage
  • Avec les picoprocess, un processus n’a qu’un lien minimal avec l’architecture Windows, ce qui a été utilisé pour implémenter des processus compatibles Linux dans WSL 1
  • À certains égards, les picoprocess sont plus proches des processus Unix que des processus Windows natifs, mais avec le passage à WSL 2, ils sont aujourd’hui peu utilisés, bien qu’ils existent depuis août 2016
• On a beau reprocher à Windows ses problèmes de sécurité, NT est parti d’une conception de sécurité avancée pour les standards naissants de l’Internet, dans le sens où le système fonctionne fondamentalement comme un système basé sur les capacités
  • Le premier processus utilisateur lancé après la connexion reçoit du noyau un jeton d’accès représentant les droits de la session utilisateur, et le processus ainsi que ses sous-processus doivent présenter ce jeton au noyau pour revendiquer des privilèges
  • Cela diffère d’Unix, où un processus possède simplement un identifiant et où le noyau doit suivre dans la table des processus ce que chacun est autorisé à faire

Compatibilité

• L’un des objectifs majeurs de NT était d’être compatible avec les applications écrites pour les anciens Windows, DOS, OS/2 et POSIX
  • L’une des raisons était technique, car cela forçait le système à adopter une conception élégante
  • L’autre raison était politique : NT a été développé conjointement avec IBM et, même si NT est finalement devenu Windows, il devait impérativement prendre en charge les applications OS/2
• Ce besoin de compatibilité a conduit à une conception très différente de celle d’Unix
  • Sous Unix, les applications en espace utilisateur communiquent directement avec le noyau via l’interface des appels système, qui constitue l’interface Unix
  • La bibliothèque C fournit la couche de liaison permettant d’appeler le noyau, et les applications n’exécutent pas directement les appels système, mais c’est un détail mineur
• Dans NT, les applications ne communiquent pas directement avec l’executive (le noyau)
  • À la place, chaque application communique avec un sous-système protégé spécifique, ces sous-systèmes implémentant les API des différents systèmes d’exploitation avec lesquels NT veut être compatible
  • Ces sous-systèmes sont implémentés comme des serveurs en espace utilisateur, pas à l’intérieur du « microkernel » NT
  • La prise en charge des applications Windows est assurée par le serveur Win32, qui est particulier parce que c’est le seul serveur directement visible par l’utilisateur : il contrôle les programmes console et les terminaux DOS, et dispose de certains privilèges pour des raisons de performance
• Par comparaison avec Unix traditionnel, la conception de NT est très différente, car BSD et Linux ont des noyaux monolithiques
  • Ces noyaux exposent une interface d’appels système que les applications en espace utilisateur exploitent pour interagir directement avec le système
  • BSD prend cependant en charge depuis longtemps l’exécution de binaires alternatifs à l’intérieur de son noyau monolithique : cela consiste à exposer en espace utilisateur différentes tables d’appels système selon le binaire en cours d’exécution, puis à convertir ces appels système « externes » en opérations comprises par le noyau
  • Linux offre également une prise en charge limitée de ce mécanisme via les personalities
• Bien que l’approche de BSD soit très différente de la façon dont NT prend en charge d’autres systèmes, WSL 1 lui ressemble beaucoup et n’est pas un sous-système au sens originel du terme
  • Dans WSL 1, le noyau NT marque les processus Linux comme des picoprocess et expose à partir de là une autre interface d’appels système
  • Au sein du noyau NT, ces appels système liés à Linux sont convertis en opérations NT et fournis dans le même noyau, à l’image de la compatibilité Linux de BSD
  • Le seul problème est que NT n’étant pas Unix, l’« émulation » de Linux est délicate et bien plus lente que ce que BSD peut offrir
  • Il est regrettable que WSL 2 ait perdu l’essence de cette conception en adoptant une architecture reposant sur une VM complète
• Détail intéressant de la conception de NT
  • L’un des objectifs de la conception de NT était de permettre des redirections d’E/S transparentes entre sous-systèmes depuis un shell unique
  • Les sous-systèmes sont exposés aux applications via des ports, qui sont des objets NT, à la manière dont Mach permet la communication entre processus et serveurs

Mémoire virtuelle

• Comme Unix, NT s’appuie sur une Memory Management Unit (MMU) avec pagination pour assurer l’isolation entre processus et fournir de la mémoire virtuelle
  • La pagination des processus en espace utilisateur est le mécanisme habituel permettant de fournir un espace d’adressage plus grand que la quantité de mémoire physique de la machine
  • Mais l’un des éléments qui donnait à NT une avance sur les systèmes Unix de son époque était que le noyau lui-même pouvait aussi être paginé vers le disque
  • Si l’intégralité du noyau était pageable, on pourrait se retrouver dans une situation où la résolution d’un défaut de page du noyau nécessiterait le code d’un pilote de système de fichiers lui-même paginé, mais une part importante du noyau reste tout de même pageable
  • Aujourd’hui, ce n’est plus particulièrement remarquable, car le noyau est petit par rapport à la mémoire généralement installée sur une machine, mais autrefois, quand chaque octet comptait, cela faisait une grande différence
• Aujourd’hui, nous tenons pour acquis le fonctionnement de la mémoire virtuelle et de la pagination, mais c’était un important domaine de recherche lorsque NT a été conçu
  • Les implémentations Unix antérieures disposaient de caches mémoire séparés pour le système de fichiers et pour la mémoire virtuelle, et ce n’est qu’en 1987 que SunOS a mis en œuvre une architecture de mémoire virtuelle unifiée afin de réduire le surcoût des conceptions précédentes
  • NT, à l’inverse, est parti dès le départ sur une architecture mémoire unifiée
  • On peut dire que cela a été plus facile à réaliser grâce à la compréhension des inefficacités observées dans Unix et parce qu’il était possible d’examiner la solution implémentée par SunOS avant le début de la conception de NT
  • Il faut toutefois noter que cela rendait NT « plus avancé » que beaucoup d’autres systèmes d’exploitation de l’époque, et que d’autres systèmes n’ont rattrapé ce niveau qu’en 2002 avec l’implémentation du Unified Buffer Cache (UBC) dans NetBSD 1.6
• Une différence intéressante entre NT et Unix réside dans la manière de gérer et de représenter la mémoire partagée
  • Dans NT, les sections de mémoire partagée sont des objets et sont donc soumises exactement aux mêmes contrôles de validité d’accès que tous les autres objets
  • Elles font également partie d’un arbre d’objets unique, ce qui permet de les adresser de la même manière que tous les autres objets
  • Dans Unix, cette fonctionnalité a été ajoutée de façon ad hoc : les objets de mémoire partagée utilisent un autre espace de noms et une API différente de celle des autres entités, de sorte que les permissions habituelles ne s’appliquent pas

Sous-système d’E/S

• Les premières versions d’Unix ne prenaient en charge qu’un seul système de fichiers
  • Par exemple, BSD n’a obtenu l’abstraction Virtual File System (VFS) pour prendre en charge davantage qu’UFS qu’avec 4.3BSD en avril 1990
  • NT, en revanche, a été conçu dès le départ pour autoriser plusieurs systèmes de fichiers
• Pour prendre en charge plusieurs systèmes de fichiers, le noyau doit exposer cet espace de noms d’une manière ou d’une autre
  • Unix combine les systèmes de fichiers dans une hiérarchie de fichiers unique via des points de montage : la couche VFS fournit un mécanisme permettant d’identifier le nœud correspondant à la racine du système de fichiers et de rediriger les requêtes vers le pilote de ce système de fichiers lors de la traversée d’un chemin
  • NT adopte une conception similaire, même si dans l’interface utilisateur standard les systèmes de fichiers apparaissent comme des lecteurs séparés : en interne, l’executive représente les systèmes de fichiers comme des objets dans un arbre d’objets, et chaque objet est chargé d’analyser le reste du chemin
  • Ces objets de système de fichiers sont ensuite remappés en lecteurs DOS afin d’être accessibles depuis l’espace utilisateur
  • Les lecteurs DOS sont eux aussi des objets situés sous un sous-arbre distinct qui redirige les E/S vers le système de fichiers référencé
• NT a finalement été lancé avec NTFS
  • Même s’il aime être critiqué pour ses performances supposément médiocres (à tort), NTFS était pour l’époque un système de fichiers réellement avancé
  • Le sous-système d’E/S de NT, combiné à NTFS, apportait l’adressage 64 bits, le journaling et même les noms de fichiers Unicode
  • Linux n’a obtenu la prise en charge des fichiers 64 bits qu’à la fin des années 1990, et le journaling seulement avec la sortie d’ext3 en 2001
  • Soft updates, un mécanisme alternatif de tolérance aux pannes, n’est apparu dans FreeBSD qu’en 1998
  • Unix représente les noms de fichiers comme des tableaux d’octets terminés par un octet nul, et non en Unicode
• Parmi les autres fonctionnalités incluses lors de la sortie de NT figuraient le disk striping et le mirroring (connus aujourd’hui sous le nom de RAID), ainsi que le hot-plug de périphériques
  • Ces fonctions n’étaient pas nouvelles, puisque SunOS incluait déjà la prise en charge du RAID dès le début des années 1990, mais ce qui est intéressant, c’est qu’elles avaient toutes été envisagées comme faisant partie de la conception d’origine
  • À un niveau plus élevé, ce qui rend le sous-système d’E/S de NT bien plus avancé que celui d’Unix, c’est le fait que son interface est fondamentalement asynchrone, et qu’elle l’était dès le départ
  • Pour remettre cela en perspective, FreeBSD n’a pris en charge aio(7) qu’avec FreeBSD 3.0 en 1998, et Linux seulement avec Linux 2.5 en 2002
  • Bien que la prise en charge des E/S asynchrones existe sur les systèmes Unix depuis plus de 20 ans, elle reste encore peu utilisée : presque personne ne connaît ces API, la majorité des applications ne les utilisent pas, et leurs performances sont médiocres
  • io_uring de Linux est un ajout relativement récent qui améliore les E/S asynchrones, mais il a été une source majeure de vulnérabilités de sécurité et n’est pas largement utilisé

Réseau

• Aujourd’hui, Internet est omniprésent, mais ce n’était pas le cas lorsque NT a été conçu
  • Si l’on regarde l’écosystème Microsoft, DOS 3.1 (1987) incluait les bases du partage de fichiers sur le système de fichiers FAT, mais l’« OS » lui-même ne fournissait pas de fonctions réseau : c’était un produit séparé appelé Microsoft Networks (MS-NET) qui s’en chargeait
  • Windows 3.0 (1990) incluait la prise en charge de NetBIOS, permettant un partage basique d’imprimantes et de fichiers sur un réseau local, mais on n’y trouvait aucun support de TCP/IP
• Unix, en revanche, était en quelque sorte Internet lui-même : tous les protocoles fondamentaux d’Internet ont été écrits sur Unix et avec Unix
  • Lors de la conception de NT, il était important de prévoir une excellente prise en charge réseau, et de fait NT a été lancé avec des fonctions réseau
  • En conséquence, NT prenait en charge à la fois les protocoles Internet et les protocoles LAN traditionnels utilisés dans l’environnement Microsoft existant, ce qui lui a donné un avantage sur Unix en entreprise
• On peut prendre comme exemple les domaines réseau de NT
  • Sous Unix, les administrateurs réseau synchronisaient généralement les comptes utilisateurs manuellement entre les machines
  • Ils pouvaient utiliser le protocole d’annuaire X.500 (1988), implémenté par des systèmes comme SunOS, ainsi que Kerberos (années 1980) pour l’authentification des utilisateurs, mais ces technologies n’étaient pas particulièrement simples
  • NT proposait au contraire dès le départ des domaines intégrant annuaire et authentification, ce qui semble lui avoir permis de « gagner » dans les réseaux d’entreprise, car c’était bien plus simple à configurer et intégré au système
• L’objectif des comptes utilisateurs synchronisés est de partager des ressources entre les machines, principalement des fichiers, et dans ce cadre la manière de représenter les permissions est importante
  • Pendant longtemps, Unix ne proposait qu’un simple ensemble de permissions lecture/écriture/exécution pour chaque fichier
  • NT, lui, a été fourni dès le départ avec des ACL avancées, ce qui reste encore un point sensible sur Unix
  • Linux et BSD disposent désormais eux aussi d’ACL, mais les interfaces ne sont pas cohérentes d’un système à l’autre et cela ressemble à un ajout étranger à la conception du système
  • Sur NT, les ACL fonctionnent au niveau des objets, ce qui permet une application cohérente à toutes les fonctions du noyau
• Parler de partage de fichiers impose de parler des systèmes de fichiers réseau
  • Sous Unix, le système de fichiers réseau de facto était NFS, et sous NT c’était SMB
  • SMB était hérité de MS-NET et de LAN Manager, et implémenté dans le noyau via un composant appelé redirector
  • En substance, le redirector est « simplement » un autre système de fichiers qui intercepte les opérations sur les fichiers et les transmet sur le réseau, comme le fait NFS sur Unix
• protobuf et gRPC sont aujourd’hui largement utilisés et peuvent sembler être des idées nouvelles, mais ils reposent sur des idées anciennes
  • Sous Unix, Sun RPC était utilisé principalement pour prendre en charge NFS dès le début des années 1980
  • De même, NT était livré avec une prise en charge RPC intégrée, via son propre DSL (connu sous le nom de MIDL pour spécifier les définitions d’interfaces et générer du code pour les procédures distantes) ainsi que ses propres fonctions pour implémenter des clients et serveurs RPC
• Les systèmes Unix n’accordaient pas une attention particulière à la prise en charge de pilotes arbitraires : ils étaient généralement liés à des machines et des fournisseurs spécifiques
  • NT, au contraire, voulait être l’OS pour « toutes » les machines, et comme il était commercialisé par un éditeur de logiciels, il était important de prendre en charge des pilotes écrits par d’autres
  • NT a ainsi été livré avec NDIS, le Network Driver Interface Specification, une abstraction destinée à faciliter la prise en charge des pilotes de cartes réseau
  • Encore aujourd’hui, les pilotes fournis par les fabricants ne sont pas si courants sur Linux, ce qui a donné naissance au début des années 2000 à des outils intéressants comme ndiswrapper, très populaire, qui permettait de réutiliser sous Linux des pilotes Windows pour des cartes Wi‑Fi
• Enfin, une autre différence entre NT et Unix concerne l’implémentation des named pipes
  • Sous Unix, les named pipes sont un mécanisme local : ils permettent à deux processus sur une même machine de communiquer entre eux via un nom de fichier persistant sur le disque
  • NT offre la même fonctionnalité, mais les named pipes peuvent aussi fonctionner sur le réseau
  • En plaçant des named pipes sur un système de fichiers partagé, deux applications sur des ordinateurs différents peuvent communiquer entre elles sans avoir à se soucier des détails du réseau

Espace utilisateur

• Configuration :
  • NT a centralisé la configuration du système et des applications dans une base de données appelée registre, abandonnant l’ancien CONFIG.SYS, AUTOEXEC.BAT et les innombrables fichiers INI utilisés par les anciennes versions de Windows
  • Cela a beaucoup contrarié certaines personnes, mais au final une interface de configuration unifiée profite à tout le monde : il est plus facile d’écrire des applications puisqu’il n’y a qu’une seule base à prendre en charge, et les utilisateurs peuvent plus facilement ajuster le système puisqu’il n’y a qu’un seul endroit à examiner
  • En revanche, Unix continue de pâtir de dizaines de DSL et d’emplacements de fichiers incohérents
  • Chaque programme qui prend en charge des fichiers de configuration a sa propre syntaxe, et il est difficile de savoir où le programme les lit, sans que cela soit toujours bien documenté
  • L’écosystème Linux a poussé une approche similaire à NT avec XDG et dconf (anciennement GConf), mais les composants du bureau utilisent exclusivement ces technologies tandis que les composants de base du système ne les ont pas adoptées, laissant un ensemble incohérent et désordonné
• Internationalisation :
  • Microsoft, déjà grande entreprise commercialisant Windows 3.x dans le monde entier, comprenait l’importance de la localisation et a fait en sorte que NT prenne en charge ces fonctionnalités dès le départ
  • À comparer avec Unix, où la prise en charge d’UTF n’a commencé à apparaître qu’à la fin des années 1990 et où la prise en charge d’autres langues passait par l’ajout optionnel de gettext
• Langage C :
  • Une chose dont des systèmes Unix comme FreeBSD et NetBSD rêvent depuis longtemps est d’inventer leur propre dialecte du C pour implémenter le noyau de façon plus sûre
  • Cela n’a mené nulle part, sauf pour Linux qui s’appuie sur des extensions spécifiques à GCC
  • Microsoft, en revanche, avait le privilège de posséder son propre compilateur C, et NT l’a donc fait avec Microsoft C
  • Par exemple, NT s’appuie sur Structured Exception Handling (SEH), qui ajoute notamment des clauses try/except pour gérer les exceptions logicielles et matérielles
  • Je ne dirais pas que c’est un énorme avantage, mais c’est effectivement une différence

Conclusion

• NT était une technologie révolutionnaire au moment de sa sortie
• Comme expliqué plus haut, de nombreuses fonctionnalités considérées comme allant de soi dans la conception des systèmes actuels étaient présentes dans NT dès l’origine, alors que presque tous les autres systèmes Unix ont dû les acquérir lentement avec le temps
• En conséquence, ces fonctionnalités ne s’intègrent pas toujours harmonieusement à la philosophie Unix
• Cependant, il n’est pas évident qu’aujourd’hui NT soit réellement « plus avancé » que Linux ou FreeBSD
  • NT disposait dès le départ de principes de conception plus solides et de davantage de fonctionnalités que les systèmes d’exploitation contemporains, mais de nos jours la différence est floue
  • Autrement dit, NT a progressé, mais pas au point d’être nettement plus avancé que les Unix modernes
• Il est regrettable que, malgré tous ces principes de conception solides, l’alourdissement de l’UI empêche cette conception de vraiment briller
  • Même sur des machines très puissantes, la lenteur de l’OS peut être pénible à constater et pourrait même conduire à la disparition de cet OS

Résumé de GN⁺

• Cet article compare les différences de conception entre NT et Unix afin d’expliquer à quel point la conception initiale de NT était avancée
• NT a été conçu dès le départ avec comme objectifs la portabilité, la prise en charge du multitraitement et la compatibilité, ce qui constitue une différence majeure avec Unix
• Son noyau orienté objet, son architecture mémoire unifiée et son interface d’E/S asynchrones lui offrent des fonctionnalités plus avancées que Unix
• Cependant, aujourd’hui, les différences entre NT et les systèmes Unix ne sont pas importantes, et l’alourdissement de l’UI de NT entraîne une baisse des performances

[GN⁺]

Avis Hacker News

• Le noyau NT est excellent, mais sa conception est ancienne

  • Le système d’exploitation Windows accumule de nombreux éléments obsolètes au-dessus du noyau NT, ce qui entraîne des problèmes
  • Microsoft devrait envisager une nouvelle conception d’OS fondée sur NT, en s’éloignant des paradigmes Win32 et MS-DOS

• La plus grande différence entre NT et Unix réside dans l’approche des pilotes

  • NT a été conçu pour résoudre les problèmes de pilotes de Windows 3.x/95/98
  • Unix considère les pilotes comme des composants à très haute fiabilité, écrits par les développeurs du noyau

• Dans le WinNT moderne, Direct3D est une partie essentielle du noyau

  • D3D11 peut être utilisé même sans GPU, grâce à WARP, qui fournit une alternative logicielle
  • Linux manque d’une fonctionnalité comparable

• Le noyau NT exécute des threads plutôt que des processus

  • Les threads peuvent être créés en quelques millisecondes, tandis que les processus sont lourds
  • L’histoire de NT est enracinée dans les principes fondamentaux de VMS

• À ses débuts, WindowsNT était un système bien mieux conçu que Linux

  • NT pouvait exécuter Win32, OS/2 et POSIX
  • POSIX a été ajouté pour répondre aux grands contrats logiciels du gouvernement américain, puis a perdu de l’intérêt

• NT, en tant que troisième système, a évité le syndrome du deuxième système

  • OS/2 résolvait des problèmes techniquement mal posés et a aussi échoué sur le plan organisationnel
  • NT n’a pas été largement adopté avant Windows XP

• Il existe des différences entre Windows et Linux du point de vue des développeurs

  • Windows est supérieur pour la ligne de commande et la gestion du globbing
  • L’usage de wchar_t dans Win32 est problématique

• Le noyau NT a une certaine élégance, mais il n’est pas open source

  • Un Windows avec un autre espace utilisateur et un autre environnement de bureau serait intéressant

• Il y a eu une forme de convergence semblable à FUSE dans Linux

  • L’approche de Win NT vis-à-vis du système de fichiers rend de nombreuses opérations sur les fichiers très lentes
  • Microsoft a abandonné WSL1 et utilise des conteneurs comme SQLLite ou des fichiers ZIP