Windows NT vs. Unix: Designvergleich

• NT wurde oft als „sehr fortschrittliches“ Betriebssystem bewertet, aber es war nicht klar, warum
  • Ende 2023 wurde die 1. Ausgabe von 'Inside Windows NT' gelesen, woraufhin beschlossen wurde, NT mit Unix zu vergleichen
  • Verglichen wird das Design von NT (Juli 1993) mit den damaligen Unix-Systemen (4.4BSD, Linux 1.0)
  • Als Unix-Experte ohne tiefere NT-Kenntnisse liegt der Fokus auf den Unterschieden von NT
  • Es geht um die Frage, worin NT Unix überlegen war und ob das heute noch gilt

Mission

• Die Geschichte von Unix ist deutlich älter als die von NT
  • Die Entwicklung von Unix begann 1969, und das Hauptziel war, eine komfortable Plattform für Programmierer zu schaffen
  • Unix ließ sich von Multics inspirieren, übertraf Multics jedoch durch den Fokus auf Einfachheit
  • Portabilität und Multitasking waren keine ursprünglichen Designziele von Unix: Diese Eigenschaften kamen erst Jahre später mit den vielen „Forks“ und Neuerfindungen von Unix hinzu
• Die Geschichte von Microsoft
  • Die erste Version von MS-DOS erschien im August 1981, und die erste Version von „Legacy Windows“ (DOS-basierte Versionen) im November 1985
  • MS-DOS war ein großer Erfolg, aber wirklich wichtig wurde Windows erst mit Windows 3.0 im Mai 1990
  • Windows NT wurde 1989 konzipiert und erschien im Juli 1993 mit der Veröffentlichung von NT 3.1
• Microsofts Vorteil
  • Das Design von NT begann 20 Jahre später als das von Unix, was Microsoft einen Vorteil verschaffte
  • Microsoft verfügte dank MS-DOS und Legacy Windows bereits über eine große Nutzerbasis
  • Das Microsoft-Team hinter NT brachte Erkenntnisse aus diesen Entwicklungen, Erfahrung mit anderen Betriebssystemen und Zugang zu aktueller Technik mit, sodass man bei der Entwicklung von NT „nach den Sternen greifen“ konnte

Kernel

• Unix wurde mit wenigen Ausnahmen wie Minix oder GNU Hurd als monolithischer Kernel implementiert und stellt eine Menge von Systemaufrufen bereit, über die mit den vom Betriebssystem angebotenen Funktionen interagiert wird
• NT ist dagegen eine Zwischenform aus monolithischem Kernel und Mikrokernel: Die privilegierte Komponente executive präsentiert sich den subsystems im User Space als Sammlung modularer Komponenten
• Die Subsystems im User Space sind spezielle Prozesse, die von Anwendungen verwendete APIs (POSIX, OS/2 usw.) in Systemaufrufe des Executive „übersetzen“
• Ein wichtiger Teil des NT Executive ist die HAL, die abstrakte Grundbausteine für den Zugriff auf die Hardware einer Maschine bereitstellt und als Grundlage für den Rest des Kernels dient
  • Diese Schicht ist entscheidend dafür, dass NT auf verschiedenen Architekturen wie i386, Alpha und PowerPC laufen kann
  • Unix war damals an bestimmte Architekturen gebunden: Das Unix-Konzept war portabel, die Implementierungen jedoch nicht
  • SunOS unterstützte ursprünglich nur Motorola 68000, 386BSD war das erste BSD-Port auf die Intel-Architektur, und IRIX war eine Unix-Variante für MIPS-basierte Workstations von Silicon Graphics
• Ein weiterer wichtiger Teil des NT Executive ist die Unterstützung für Multiprocessing-Systeme und einen präemptiven Kernel
  • Der Kernel kennt verschiedene Interrupt-Level (im BSD-Jargon SPL), um zu bestimmen, was was unterbrechen darf; wichtiger ist jedoch, dass Kernel-Threads von anderen Kernel-Threads präemptiert werden können
  • Das tun heute alle performanten Unix-Systeme, aber so haben viele Unix-Systeme nicht begonnen
  • Diese Systeme starteten mit Kerneln ohne Unterstützung für Präemption oder Multiprocessing, fügten dann Multiprocessing-Unterstützung im User Space hinzu und erst danach Kernel-Präemption
  • Der letzte Schritt ist der schwierigste, und die Saga um FreeBSD 5.0 veranschaulicht die Hürden
  • Daher ist es interessant, dass NT von Anfang an mit der richtigen Grundlage gestartet ist

Objekte

• NT ist ein objektorientierter Kernel
  • Man könnte meinen, Unix sei das ebenfalls: Prozesse werden als struct definiert, und Dateisystemimplementierungen arbeiten mit vnode („virtueller Knoten“, nicht mit inode verwechseln)
  • Das ist jedoch nicht genau dasselbe wie bei NT: NT erzwingt, dass all diese unterschiedlichen Objekte im System eine gemeinsame Darstellung haben
• Man kann bezweifeln, wie sich für so heterogene Dinge wie Prozesse und File-Handles eine sinnvolle Abstraktion bereitstellen lässt
• Tatsächlich ist das nicht wirklich möglich, aber NT erzwingt, dass sie alle von einem gemeinsamen Objekttyp erben, und erstaunlicherweise bringt das einige gute Eigenschaften mit sich
• Zentralisierte Zugriffskontrolle
  • Objekte können nur durch den object manager erzeugt werden, daher gibt es einen einzigen Ort im Code, an dem Richtlinien durchgesetzt werden können
  • Semantiken wie Berechtigungsprüfungen müssen nur an einer Stelle definiert werden und lassen sich dadurch systemweit einheitlich anwenden, was sehr mächtig ist
  • Auch NetBSD kam zu dem Schluss, dass das eine gute Idee ist, erhielt aber erst 2001 das Framework Kernel Authorization (kauth)
• Gemeinsame IDs
  • Objekte haben IDs, und sie werden alle als einzelner Baum dargestellt
  • Das bedeutet, dass es für alle Objekte einen einheitlichen Namespace gibt, unabhängig davon, ob es sich um Prozesse, File-Handles oder Pipes handelt
  • Objekte im Baum können über Namen (Pfade) adressiert werden, und verschiedene Teile des Baums können unterschiedlichen Subsystemen gehören
  • Ein Teil des Baums kann zum Beispiel ein eingehängtes Dateisystem repräsentieren; traversiert man also den Wurzelknoten dieses Teilbaums, löst das Dateisystem den Rest des Pfads auf
  • Das ähnelt der VFS-Schicht in Unix-Systemen, aber VFS befasst sich nur mit Dateisystemen, während der Objektbaum jedes einzelne Kernel-Objekt umfasst
  • Unix versuchte mit /proc/, /sys/ usw., Nicht-Datei-Objekttypen in das Dateisystem hineinzupressen, aber das wirkt im Vergleich zu dem, was NT bietet, wie nachträglich aufgesetzt
• Einheitliche Ereignisbehandlung
  • Jeder Objekttyp hat einen signaled-Zustand, dessen Bedeutung je nach Objekttyp unterschiedlich ist
  • Ein Prozessobjekt wechselt zum Beispiel in den signaled-Zustand, wenn der Prozess beendet wird, und ein File-Handle-Objekt, wenn eine I/O-Anfrage abgeschlossen ist
  • Dadurch wird es sehr einfach, im User Space ereignisgesteuerten Code (async Code) zu schreiben, weil ein einzelner Wait-artiger Systemaufruf darauf warten kann, dass eine Gruppe von Objekten ihren Zustand ändert
  • In Unix-Systemen ist es mühsam, gleichzeitig auf I/O und die Beendigung von Prozessen zu warten
• Objekte sind eine NT-spezifische Komponente und lassen sich nicht gut auf alle APIs verallgemeinern, die NT unterstützen wollte
  • Ein Beispiel ist das POSIX-Subsystem: POSIX kennt kein Objektkonzept wie NT, aber NT musste POSIX-Anwendungen eine gewisse Art von Kompatibilität bieten
  • Deshalb muss das POSIX-Subsystem, während es im Executive Objekte allokiert, zugleich eine eigene Buchführung für die entsprechenden POSIX-Entitäten führen und fortlaufend logisch zwischen beiden Entitäten übersetzen
  • Das Win32-Subsystem gibt Objekte dagegen ohne Vermittler direkt an Clients weiter

Prozesse

• Prozesse sind ein gemeinsames Objekt von NT und Unix, aber nicht vollständig identisch
  • Unter Unix werden Prozesse als Baum dargestellt: Jeder Prozess hat ein Elternteil und kann null oder mehr Kinder haben
  • NT hat jedoch keine solche Beziehung: Prozesse können Ressourcen von ihrem Erzeuger „erben“, sind nach ihrer Erstellung aber unabhängige Entitäten
• Als NT entworfen wurde, waren Threads noch nicht verbreitet:
  • Mach war 1985 der erste Unix-ähnliche Kernel, der Threads integrierte
  • Das bedeutete, dass andere Unix-Systeme dieses Konzept erst später übernehmen und an ihre bestehenden Designs anpassen mussten
  • Linux entschied sich im Release 2.0 vom Juni 1996 dafür, Threads als Prozesse mit jeweils eigener PID darzustellen, und NetBSD bekam erst mit Release 2.0 im Jahr 2004 Threads, die als vom Prozess getrennte Entität dargestellt wurden
  • Anders als Unix entschied sich NT von Anfang an für die Unterstützung von Threads, weil man wusste, dass sie für Hochleistungsrechnen auf SMP-Maschinen unverzichtbar sind
• NT hat keine Signale im traditionellen Unix-Sinn
  • Stattdessen gibt es alerts, die im Kernel- oder im User-Mode auftreten können
  • User-Mode-Benachrichtigungen muss man wie auf andere Objekte warten, während Kernel-Mode-Benachrichtigungen für den Prozess unsichtbar sind
  • Das POSIX-Subsystem verwendet Kernel-Mode-Benachrichtigungen, um Signale zu emulieren
  • Signale wurden unter Unix oft als Makel bezeichnet, weil sie die Ausführung eines Prozesses unterbrechen: Sie korrekt zu behandeln ist ausgesprochen schwierig, daher wirkt die Alternative von NT eleganter
• Eine interessante neuere Entwicklung in NT war die Einführung von Pico-Prozessen
  • Bis zur Einführung dieser Funktion waren NT-Prozesse recht schwergewichtig: Ein neuer Prozess erhielt beim Start ein Bündel von NT-Runtime-Bibliotheken, die in seinen Adressraum gemappt wurden
  • Bei Pico-Prozessen hat der Prozess nur eine minimale Beziehung zur Windows-Architektur; das wurde zur Implementierung Linux-kompatibler Prozesse in WSL 1 verwendet
  • In mancher Hinsicht sind Pico-Prozesse Unix-Prozessen näher als nativen Windows-Prozessen, werden aber seit dem Wechsel zu WSL 2 trotz ihrer Existenz seit August 2016 nicht mehr stark genutzt
• So sehr man Windows auch für Sicherheitsprobleme kritisieren kann, NT startete mit einem fortschrittlichen Sicherheitsdesign für die frühen Internet-Standards, da das System im Kern als fähigkeitsbasiertes System arbeitet
  • Der erste User-Prozess, der nach dem Login startet, erhält vom Kernel ein Access-Token, das die Rechte der User-Session repräsentiert, und der Prozess sowie seine Kindprozesse müssen dieses Token dem Kernel vorlegen, um Berechtigungen geltend zu machen
  • Das unterscheidet sich von Unix, wo Prozesse einfach einen Bezeichner haben und der Kernel in der Prozesstabelle nachhalten muss, was jeder Prozess tun darf

Kompatibilität

• Ein Hauptziel von NT war die Kompatibilität mit Anwendungen, die für Legacy-Windows, DOS, OS/2 und POSIX geschrieben wurden
  • Ein Grund dafür war technischer Natur, weil das System dadurch zu einem eleganten Design gezwungen wurde
  • Ein anderer Grund war politisch: NT wurde gemeinsam mit IBM entwickelt, und obwohl NT letztlich zu Windows wurde, musste es OS/2-Anwendungen unbedingt unterstützen
• Durch diese Anforderungen an die Kompatibilität unterschied sich das Design von NT stark von Unix
  • Unter Unix kommunizieren User-Space-Anwendungen direkt mit dem Kernel über das System-Call-Interface, und dieses Interface ist das Unix-Interface
  • Die C-Bibliothek stellt den Klebstoff für den Aufruf des Kernels bereit, und Anwendungen führen System-Calls nicht direkt aus, aber das ist ein triviales Detail
• Unter NT kommunizieren Anwendungen nicht direkt mit dem executive (Kernel)
  • Stattdessen kommuniziert jede Anwendung mit einem bestimmten geschützten Subsystem, und diese Subsysteme implementieren die APIs der verschiedenen Betriebssysteme, mit denen NT kompatibel sein soll
  • Diese Subsysteme sind als User-Space-Server implementiert (nicht innerhalb des NT-„Mikrokernels“)
  • Die Unterstützung für Windows-Anwendungen wird vom Win32-Server bereitgestellt, der besonders ist, weil er der einzige Server ist, den Benutzer direkt sehen: Er steuert Konsolenprogramme und DOS-Terminals und besitzt aus Performance-Gründen bestimmte Privilegien
• Im Vergleich zu traditionellem Unix ist das Design von NT sehr anders, da BSD und Linux monolithische Kernel haben
  • Diese Kernel legen ein System-Call-Interface offen, das User-Space-Anwendungen nutzen, um direkt mit dem System zu interagieren
  • BSD unterstützt jedoch schon lange alternative binäre Ausführung innerhalb des monolithischen Kernels: Je nach laufender Binärdatei wird im User Space eine andere System-Call-Tabelle offengelegt, und diese „externen“ System-Calls werden dann in etwas übersetzt, das der Kernel versteht
  • Linux bietet dafür auch begrenzte Unterstützung über personalities
• Obwohl sich der BSD-Ansatz stark davon unterscheidet, wie NT andere Systeme unterstützt, ist WSL 1 sehr ähnlich und nach der ursprünglich definierten Terminologie kein Subsystem
  • In WSL 1 markiert der NT-Kernel Linux-Prozesse als Pico-Prozesse und legt von dort aus ein anderes System-Call-Interface offen
  • Innerhalb des NT-Kernels werden die Linux-spezifischen System-Calls in NT-Operationen übersetzt und wie bei der Linux-Kompatibilität von BSD innerhalb desselben Kernels bereitgestellt
  • Das einzige Problem ist, dass NT kein Unix ist, weshalb die Linux-„Emulation“ schwierig ist und deutlich langsamer als das, was BSD liefern kann
  • Es ist schade, dass WSL 2 die Essenz dieses Designs verloren hat und zu einem vollständigen VM-Design übergegangen ist
• Interessante Details des NT-Designs
  • Ziel des NT-Designs war es, nahtlose I/O-Umleitung zwischen Subsystemen innerhalb einer einzigen Shell zu ermöglichen
  • Subsysteme werden Anwendungen über Ports zugänglich gemacht; das sind NT-Objekte und ähnelt der Art, wie Mach Prozesse und Server kommunizieren lässt

Virtueller Speicher

• NT stützt sich wie Unix auf eine Memory Management Unit (MMU) mit Paging, um Schutz zwischen Prozessen zu bieten und virtuellen Speicher bereitzustellen
  • Das Paging von User-Space-Prozessen ist der übliche Mechanismus, um einen Adressraum bereitzustellen, der größer ist als die Menge des physischen Speichers der Maschine
  • Ein Punkt, in dem NT den Unix-Systemen seiner Zeit voraus war, bestand jedoch darin, dass auch der Kernel selbst auf die Festplatte ausgelagert werden konnte
  • Wenn der gesamte Kernel pagingfähig wäre, könnte man in die Situation geraten, einen Kernel-Page-Fault beheben zu müssen, für den der Code eines ausgelagerten Dateisystemtreibers benötigt wird; dennoch sind erhebliche Teile des Kernels pagingfähig
  • Heute ist das nicht besonders interessant, weil Kernel im Verhältnis zum typischen installierten Arbeitsspeicher einer Maschine klein sind, aber früher machte das einen großen Unterschied, weil jedes Byte zählte
• Heute nehmen wir die Funktionsweise von virtuellem Speicher und Paging als selbstverständlich hin, aber als NT entworfen wurde, war das ein großes Forschungsfeld
  • Frühere Unix-Implementierungen hatten getrennte Speichercaches für Dateisystem und virtuellen Speicher, und erst 1987 implementierte SunOS eine einheitliche Architektur für virtuellen Speicher, um den Overhead früherer Designs zu verringern
  • NT begann dagegen von Anfang an mit einer einheitlichen Speicherarchitektur
  • Man könnte sagen, dass dies leicht war, weil es bereits Einsichten über in Unix gefundene Ineffizienzen gab und man vor Beginn des NT-Designs die von SunOS implementierte Lösung sehen konnte
  • Dennoch sollte man festhalten, dass NT dadurch „fortschrittlicher“ als viele andere Betriebssysteme seiner Zeit war und andere Systeme erst 2002 mit der Unified Buffer Cache(UBC)-Implementierung in NetBSD 1.6 aufschlossen
• Ein interessanter Unterschied zwischen NT und Unix besteht darin, wie Shared Memory verwaltet und dargestellt wird
  • In NT sind Shared-Memory-Sektionen Objekte und unterliegen daher genau denselben Access-Prüfungen wie alle anderen Objekte
  • Außerdem sind sie Teil eines einzigen Objektbaums und können daher genauso adressiert werden wie alle anderen Objekte
  • Unter Unix ist diese Funktion nachträglich angebaut: Shared-Memory-Objekte haben einen anderen Namespace und eine andere API als alle anderen Entitäten, weshalb die üblichen Berechtigungen nicht gelten

I/O-Subsystem

• Frühe Versionen von Unix unterstützten nur ein einziges Dateisystem
  • Dass BSD etwa die Abstraktion des Virtual File System (VFS) erhielt, um mehr als nur UFS zu unterstützen, geschah erst mit 4.3BSD im April 1990
  • NT dagegen wurde von Anfang an so entworfen, dass mehrere Dateisysteme möglich sind
• Um mehrere Dateisysteme zu unterstützen, muss der Kernel deren Namespace auf irgendeine Weise offenlegen
  • Unix verbindet Dateisysteme über Mountpoints zu einer einzigen Dateihierarchie: Die VFS-Schicht liefert einen Mechanismus, um den Knoten zu identifizieren, der der Wurzel des Dateisystems entspricht, und Anfragen beim Durchlaufen eines Pfads an den jeweiligen Dateisystemtreiber weiterzuleiten
  • NT hat ein ähnliches Design, auch wenn Dateisysteme in der Standardbenutzeroberfläche als getrennte Laufwerke erscheinen: Intern stellt das Executive Dateisysteme als Objekte in einem Objektbaum dar, und jedes Objekt ist dafür verantwortlich, den Rest des Pfads zu analysieren
  • Diese Dateisystemobjekte werden anschließend wieder auf DOS-Laufwerke abgebildet, damit aus dem User Space darauf zugegriffen werden kann
  • Auch DOS-Laufwerke sind Objekte unter einem separaten Teilbaum, die I/O an das Dateisystem weiterleiten, auf das sie verweisen
• NT wurde letztlich mit NTFS ausgeliefert
  • Auch wenn NTFS gern wegen angeblich schlechter Performance kritisiert wird (zu Unrecht), war es für seine Zeit ein wirklich fortschrittliches Dateisystem
  • Das I/O-Subsystem von NT bot in Kombination mit NTFS 64-Bit-Adressierung, Journaling und sogar Unicode-Dateinamen
  • Linux erhielt Unterstützung für 64-Bit-Dateien erst Ende der 1990er Jahre, und Journaling erst mit dem Erscheinen von ext3 im Jahr 2001
  • Der alternative Fehlertoleranzmechanismus Soft updates erschien in FreeBSD erst 1998
  • Unix stellt Dateinamen als nullterminierte Byte-Arrays und nicht als Unicode dar
• Weitere Funktionen, die bei der Einführung von NT enthalten waren, waren Disk-Striping und Mirroring (heute als RAID bekannt) sowie Hot-Plugging von Geräten
  • Diese Funktionen waren nicht neu, da SunOS bereits seit den frühen 1990er Jahren RAID-Unterstützung enthielt, aber interessant ist, dass sie alle von Anfang an als Teil des ursprünglichen Designs berücksichtigt wurden
  • Auf einer höheren Ebene macht das I/O-Subsystem von NT im Vergleich zu Unix vor allem die Tatsache deutlich fortschrittlicher, dass seine Schnittstelle grundsätzlich asynchron ist und das von Beginn an war
  • Zur Einordnung: FreeBSD bekam Unterstützung für aio(7) erst mit FreeBSD 3.0 im Jahr 1998, und Linux erst mit Linux 2.5 im Jahr 2002
  • Obwohl Unterstützung für asynchrones I/O seit über 20 Jahren in Unix-Systemen existiert, wird sie noch immer nicht breit genutzt: Kaum jemand kennt diese APIs, die Mehrheit der Anwendungen verwendet sie nicht, und die Performance ist schlecht
  • Linuxs io_uring ist eine vergleichsweise junge Ergänzung zur Verbesserung von asynchronem I/O, war aber eine wesentliche Ursache für Sicherheitslücken und wird nicht breit genutzt

Netzwerk

• Heute ist das Internet allgegenwärtig, aber als NT entworfen wurde, war das noch nicht so
  • Im Microsoft-Ökosystem enthielt DOS 3.1 (1987) zwar die Grundlage für Dateifreigaben auf dem FAT-Dateisystem, aber das "OS" selbst bot keine Netzwerkfunktionen: Das übernahm ein separates Produkt namens Microsoft Networks (MS-NET)
  • Windows 3.0 (1990) enthielt Unterstützung für NetBIOS, das grundlegende Drucker- und Dateifreigaben in lokalen Netzwerken ermöglichte, aber Unterstützung für TCP/IP war nirgends zu finden
• Unix dagegen war gewissermaßen das Internet selbst: Alle grundlegenden Internetprotokolle wurden auf Unix und mit Unix entwickelt
  • Beim Entwurf von NT war es wichtig, gute Netzwerkunterstützung zu berücksichtigen, und tatsächlich wurde NT mit Netzwerkfunktionen ausgeliefert
  • Dadurch unterstützte NT sowohl Internetprotokolle als auch die traditionellen LAN-Protokolle der bestehenden Microsoft-Umgebung, was NT in Unternehmensumgebungen einen Vorsprung vor Unix verschaffte
• Ein Beispiel dafür sind die Netzwerkdomänen von NT
  • Unter Unix synchronisierten Netzwerkadministratoren Benutzerkonten zwischen Maschinen im Allgemeinen manuell
  • Systeme wie SunOS konnten zur Benutzerauthentifizierung zwar das X.500-Verzeichnisprotokoll (1988) und Kerberos (1980er Jahre) einsetzen, aber diese Technologien waren nicht gerade einfach
  • NT bot stattdessen von Anfang an Domänen mit integrierten Verzeichnis- und Authentifizierungsfunktionen, die offenbar deshalb in Unternehmensnetzwerken "gewannen", weil sie wesentlich leichter einzurichten und direkt im System eingebaut waren
• Das Ziel synchronisierter Benutzerkonten ist das Teilen von Ressourcen zwischen Maschinen, vor allem von Dateien, und dabei ist wichtig, wie Berechtigungen dargestellt werden
  • Lange Zeit bot Unix für jede Datei nur einen einfachen Satz aus Lese-, Schreib- und Ausführungsrechten
  • NT dagegen kam von Anfang an mit erweiterten ACLs, was unter Unix bis heute ein Problemfeld ist
  • Linux und BSD haben inzwischen ebenfalls ACLs, aber die Schnittstellen sind zwischen Systemen nicht konsistent und wirken wie ein dem Systemdesign fremder Zusatz
  • In NT arbeiten ACLs auf Objektebene und werden daher konsistent auf alle Kernelfunktionen angewendet
• Wenn man über Dateifreigabe spricht, muss man auch über Netzwerkdateisysteme sprechen
  • Unter Unix war das De-facto-Dateisystem NFS, unter NT SMB
  • SMB wurde von MS-NET und LAN Manager übernommen und über eine Komponente namens Redirector im Kernel implementiert
  • Im Wesentlichen ist der Redirector einfach ein weiteres "einfaches" Dateisystem, das Dateizugriffe abfängt und über das Netzwerk überträgt, so wie NFS es unter Unix tut
• Weil protobuf und gRPC breit verwendet werden, mögen sie wie neue Ideen wirken, beruhen aber auf alten Konzepten
  • Unter Unix wurde seit den frühen 1980er Jahren vor allem zur Unterstützung von NFS Sun RPC verwendet
  • Ebenso brachte NT eingebaute RPC-Unterstützung mit, mit einer eigenen DSL (zur Definition von Schnittstellen und zur Codegenerierung für Remote-Prozeduren, bekannt als MIDL) sowie eigenen Funktionen zur Implementierung von RPC-Clients und -Servern
• Unix-Systeme legten keinen großen Schwerpunkt auf Unterstützung für beliebige Treiber: Sie waren gewöhnlich an bestimmte Maschinen und Anbieter gebunden
  • NT dagegen wollte ein OS für "alle" Maschinen sein und wurde von einem Softwareunternehmen verkauft, daher war Unterstützung für von Dritten geschriebene Treiber wichtig
  • Deshalb verfügte NT über die Network Driver Interface Specification (NDIS), eine Abstraktion zur einfachen Unterstützung von Netzwerkkartentreibern
  • Bis heute sind von Herstellern bereitgestellte Treiber unter Linux nicht besonders verbreitet, was zu interessanten Konstruktionen wie ndiswrapper führte, das Anfang der 2000er Jahre sehr populär war, weil damit Windows-Treiber für WiFi-Karten unter Linux wiederverwendet werden konnten
• Schließlich liegt ein weiterer Unterschied zwischen NT und Unix in der Implementierung benannter Pipes
  • Benannte Pipes sind unter Unix eine lokale Komponente: Sie bieten einen Mechanismus, mit dem zwei Prozesse auf derselben Maschine über einen persistenten Dateinamen auf der Festplatte miteinander kommunizieren können
  • NT besitzt dieselbe Funktionalität, aber benannte Pipes können auch über das Netzwerk hinweg arbeiten
  • Legt man benannte Pipes in einem gemeinsam genutzten Dateisystem ab, können zwei Anwendungen auf unterschiedlichen Computern miteinander kommunizieren, ohne sich um Netzwerkdetails kümmern zu müssen

User-Space

• Konfiguration:
  • NT zentralisierte System- und Anwendungskonfigurationen in einer Datenbank namens Registry und löste sich damit von den alten CONFIG.SYS, AUTOEXEC.BAT und den zahlreichen INI-Dateien aus dem Legacy-Windows
  • Das machte einige Leute zwar sehr wütend, aber letztlich ist eine einheitliche Konfigurationsoberfläche für alle von Vorteil: Anwendungen lassen sich leichter schreiben, weil es nur eine einzige Grundlage zu unterstützen gibt, und Nutzer können das System leichter anpassen, weil es nur einen Ort zum Nachsehen gibt
  • Unix hingegen hat noch immer mit Dutzenden von DSLs und inkonsistenten Speicherorten für Dateien zu kämpfen
  • Jedes Programm, das Konfigurationsdateien unterstützt, hat seine eigene Syntax, und es ist schwer zu wissen, wo ein Programm sie einliest; außerdem ist das nicht immer gut dokumentiert
  • Das Linux-Ökosystem hat mit XDG und dconf (früher GConf) einen NT-ähnlichen Ansatz vorangetrieben, doch während Desktop-Komponenten diese Technologien exklusiv nutzen, haben die grundlegenden Systemkomponenten sie nicht übernommen, was ein inkonsistentes Durcheinander hinterlässt
• Internationalisierung:
  • Microsoft verstand als Großunternehmen, das Windows 3.x bereits weltweit auslieferte, dass Lokalisierung wichtig ist, und sorgte dafür, dass NT solche Funktionen von Anfang an unterstützte
  • Im Gegensatz dazu begann UTF-Unterstützung bei Unix erst Ende der 1990er Jahre aufzutauchen, und andere Sprachen wurden über das optionale Zusatzpaket gettext unterstützt
• C-Sprache:
  • Eine Sache, von der Unix-Systeme wie FreeBSD und NetBSD seit einiger Zeit träumten, war die Entwicklung eines eigenen C-Dialekts, um den Kernel auf sicherere Weise zu implementieren
  • Das führte nirgendwohin, außer bei Linux, das auf GCC-spezifische Erweiterungen setzt
  • Microsoft hingegen hatte das Privileg, einen eigenen C-Compiler zu besitzen, und setzte dies in NT um, das mit Microsoft C geschrieben wurde
  • So stützt sich NT zum Beispiel auf Structured Exception Handling (SEH), also die Möglichkeit, try/except-Klauseln hinzuzufügen, um Software- und Hardware-Ausnahmen zu behandeln
  • Ich würde nicht sagen, dass das ein großer Vorteil ist, aber es ist tatsächlich ein Unterschied

Fazit

• NT war zum Zeitpunkt seiner Veröffentlichung eine bahnbrechende Technologie
• Wie oben beschrieben, waren viele Funktionen, die wir heute im Systemdesign als selbstverständlich ansehen, in NT von Anfang an vorhanden, während fast alle anderen Unix-Systeme sich solche Funktionen im Laufe der Zeit langsam aneignen mussten
• Infolgedessen ließen sich diese Funktionen nicht immer nahtlos in die Unix-Philosophie integrieren
• Es ist jedoch nicht klar, ob NT heute gegenüber Linux oder FreeBSD wirklich „fortschrittlicher“ ist
  • NT hatte von Beginn an robustere Designprinzipien und mehr Funktionen als zeitgenössische Betriebssysteme, aber heute sind die Unterschiede unscharf
  • Mit anderen Worten: NT hat sich weiterentwickelt, ist aber nicht deutlich weiter fortgeschritten als modernes Unix
• Trotz all dieser robusten Designprinzipien bei NT ist es enttäuschend, dass das Design wegen der Aufgeblähtheit der UI nicht zur Geltung kommt
  • Selbst auf extrem leistungsstarken Maschinen kann die Langsamkeit des OS schmerzhaft mitanzusehen sein und möglicherweise sogar zum Untergang dieses OS führen

Zusammenfassung von GN⁺

• Dieser Artikel vergleicht die Designunterschiede zwischen NT und Unix und erklärt, wie fortschrittlich das frühe Design von NT war
• NT wurde von Anfang an mit Blick auf Portabilität, Multiprocessing-Unterstützung und Kompatibilität entworfen, was ein wesentlicher Unterschied zu Unix ist
• Der objektorientierte Kernel von NT, die einheitliche Speicherarchitektur und die asynchrone I/O-Schnittstelle bieten fortschrittlichere Funktionen als Unix
• Heute sind die Unterschiede zwischen NT- und Unix-Systemen jedoch nicht groß, und die aufgeblähte UI von NT führt zu Leistungseinbußen

[GN⁺]

Hacker-News-Meinungen

• Der NT-Kernel ist hervorragend, aber ein veraltetes Design

  • Auf dem NT-Kernel des Windows-Betriebssystems stapeln sich viele überholte Elemente, was zu Problemen führt
  • Microsoft sollte erwägen, sich vom Win32- und MS-DOS-Paradigma zu lösen und ein neues, auf NT basierendes OS-Design zu entwickeln

• Der größte Unterschied zwischen NT und Unix ist der Ansatz bei Treibern

  • NT wurde entwickelt, um die Treiberprobleme von Windows 3.x/95/98 zu lösen
  • Unix betrachtet Treiber als hochzuverlässige Komponenten, die von Kernel-Entwicklern geschrieben werden

• In modernem WinNT ist Direct3D ein essenzieller Teil des Kernels

  • D3D11 kann auch ohne GPU verwendet werden und bietet mit WARP eine Software-Alternative
  • Unter Linux fehlt eine vergleichbare Funktion

• Der NT-Kernel führt Threads aus, nicht Prozesse

  • Threads lassen sich innerhalb weniger Millisekunden erzeugen, während Prozesse schwergewichtig arbeiten
  • Die Geschichte von NT ist in den Grundprinzipien von VMS verwurzelt

• WindowsNT war anfangs ein deutlich besser entworfenes System als Linux

  • NT konnte Win32, OS/2 und POSIX ausführen
  • POSIX wurde für große Softwareverträge mit der US-Regierung hinzugefügt, verlor später jedoch an Bedeutung

• NT vermied als drittes System das Syndrom des zweiten Systems

  • OS/2 löste technisch die falschen Probleme und scheiterte auch organisatorisch
  • NT wurde bis Windows XP nicht breit genutzt

• Aus Entwicklersicht gibt es Unterschiede zwischen Windows und Linux

  • Bei Kommandozeile und Globbing ist Windows überlegen
  • Die Verwendung von wchar_t in Win32 ist problematisch

• Der NT-Kernel besitzt Eleganz, ist aber nicht Open Source

  • Windows mit einem anderen User Space und einer anderen Desktop-Umgebung wäre interessant

• Es gab eine Konvergenz ähnlich wie bei FUSE unter Linux

  • Der Dateisystem-Ansatz von Win NT macht viele Dateisystemoperationen sehr langsam
  • Microsoft hat WSL1 aufgegeben und nutzt Container wie SQLLite oder ZIP-Dateien