Dave Cutler erklärt Windows [Video]
(youtube.com)- Dave Cutler blickt auf der Grundlage seiner Erfahrungen von RSX-11, VMS und Windows NT bis hin zu Azure und Xbox auf den Designhintergrund von Windows NT und die Entwicklungskultur bei Microsoft zurück
- Windows NT zielte von Anfang an auf ein portables Betriebssystem und die Unterstützung mehrerer Laufzeitumgebungen ab, und als sich Windows 3.1 innerhalb von 6 Monaten 16 Millionen Mal verkaufte, wurde Windows statt OS/2 zur zentralen Umgebung
- Das frühe NT behandelte mehrere Architekturen wie i860, MIPS, x86, Alpha und PowerPC sowie HAL, Objektmanager und die Kernel-/Treiberstruktur, und ein großer Teil der Kernstruktur ist bis heute in Windows 11 erhalten
- Bei VMS war das Ziel zur Veröffentlichung 0 bekannte Bugs, und das NT-Entwicklungsteam hielt mit dem Friday WHIM den Zusammenhalt der Organisation aufrecht, doch bei NT, Cairo, Longhorn und den XP-Sicherheitsmaßnahmen wurden Zeitpläne, Qualität und die Aufspaltung der Codebasis zu einer großen Belastung
- Cutler sieht Bugfixing, Tests, Qualitätssicherung und die Zurückhaltung, keine unnötigen Funktionen einzubauen, als zentrale Haltung guter Software-Teams
Betriebssystem-Erfahrung vor Windows NT
- Dave Cutler kam bei DuPont über Echtzeitsysteme und Computersimulationen mit Computern in Berührung und interessierte sich danach stärker für den Computer selbst als nur für Werkzeuge zur Problemlösung
- In einem Projekt zur Simulation des Formularherstellungsprozesses von Scott Paper mit GPSS 3 erlebte er Kartenfehler und Debugging-Probleme
- Um Fehler zu verringern, schrieb er ein Fortran-Programm und erweiterte sein Interesse später bis zur IBM-7044-Assemblersprache auf die interne Funktionsweise von Computern
- In der Echtzeitsystemgruppe von DuPont schrieb er Programme zur automatischen Analyse von Daten aus Instron-Zugversuchen
- Das Datenerfassungsprogramm lief in Echtzeit und las Daten in Intervallen von 1 Millisekunde oder 100 Millisekunden
- Danach übernahm er Arbeiten an Exec II, dem Betriebssystem der Univac 1107, und stieg damit ernsthaft in die Betriebssystementwicklung ein
- Täglich wurde um 17 Uhr der Operator hinausgeschickt, danach liefen zwei Stunden lang experimenteller Code und Tests
- In einer Umgebung mit kaum vorhandenen Debuggern wurde mit Schaltern und
halt instructiondebuggt
Zeit bei DEC: RSX, VMS, Compiler, PRISM
- Bei Digital Equipment Corporation wurde er zunächst für OS/45 eingestellt, übernahm aber bald die Arbeit an RSX-11C
- Der 16-Bit-Adressraum der PDP-11 war aus Cutlers Sicht damals eine große Einschränkung
- RSX-11C war ein kleines System und seiner Einschätzung nach selbst für damalige Maßstäbe funktional begrenzt
- Die Entwicklung von VMS wurde mithilfe der VAX-Hardware und einer PDP-11-kompatiblen Ausführungsschicht gebootstrapped
- Die VAX hatte einen PDP-11-Modus, und mit einer Schicht namens Application Migration Executive wurden RSX-11M-Dienstprogramme ausgeführt
- Auch das Dateisystem Files-11 wurde in VMS neu implementiert, um die Kompatibilität zu erhalten
- In der frühen Entwicklungsphase wurden Kernaufgaben wie Scheduling und Speicherverwaltung auf einem Hardware-Emulator umgesetzt
- VMS nutzte Self-Hosting als Mittel zur Qualitätssicherung
- Als Proto 3 stabil genug lief, arbeitete das Entwicklungsteam direkt auf diesem System
- Wenn das System einen Bug Check auslöste, gingen einige Leute zur Maschine, suchten mit dem Debugger die Ursache, spielten den Fix ein und booteten neu
- Rückblickend hatte VMS zum Veröffentlichungszeitpunkt „0 bekannte Bugs“
- Das bedeutete nicht „es gab keine Bugs“, sondern dass man bis zur Veröffentlichung alle bekannten Fehler beheben wollte
- Noch im letzten Moment wurde eine Race Condition im Festplattentreiber behoben
- Nach VMS war er auch an einem PL/I-Compiler, dem Backend des C-Compilers, der Codegenerierung, Optimierungen und der Registerallokierung beteiligt
- Das PL/I-Frontend wurde von einer Firma in Boston gekauft, das Backend auf der VAX entwickelt
- Ein Teil der Frontend-Arbeit wurde auf Multics am MIT erledigt und die Daten anschließend per Band übertragen
- Bei DEC West arbeitete er am Echtzeitsystem Velon und am MicroVAX-Projekt
- Velon war ein System, in dem Ideen wie User-Mode-Treiber, nachrichtenorientierte Architektur, Multithreading und Multiprozessoren erprobt wurden
- Beim MicroVAX 1 schrieb Cutler den gesamten Microcode
- Das PRISM-Projekt war DECs Versuch einer RISC-Architektur, und am Tag nach der Einstellung des Projekts beschloss Cutler, das Unternehmen zu verlassen
- PRISM hatte Architekturen in 32-Bit- und 64-Bit-Versionen, und auch ein ambitioniertes Softwaresystem namens Micah war in Arbeit
- Nach dem Aus von PRISM wollte er zunächst eine Serverfirma gründen, doch der Kontakt mit Microsoft änderte die Richtung
Einstieg bei Microsoft und das Design von Windows NT
- Der Wechsel zu Microsoft war auch nach dem Gespräch mit Bill Gates noch nicht sicher, wurde aber nach einem Frühstück mit Steve Ballmer bei Denny’s schnell entschieden
- Cutler sieht Ballmer als die Schlüsselfigur, die ihn zu Microsoft brachte
- Die frühen Ziele von NT waren ein portables Betriebssystem und die Unterstützung mehrerer Laufzeitumgebungen
- Die damalige Zielumgebung war OS/2, und auch POSIX war ein wichtiger Kandidat
- Der Kern des Systems sollte grundlegende Dienste bereitstellen, auf denen mehrere Umgebungen aufsetzen
- Ausschlaggebend dafür, dass Windows zur zentralen Umgebung von NT wurde, war der Erfolg von Windows 3.1
- Windows 3.1 verkaufte sich in 6 Monaten 16 Millionen Mal, und Bill Gates entschied, dass Windows die Hauptumgebung des neuen Systems werden würde
- Die NT-Entwicklung lief zeitweise auf OS/2, doch das Team wollte so schnell wie möglich auf NT selbst self-hosted arbeiten
- Der Name NT steht für „New Technology“
- Zwischen dem Codenamen N10 des i860 und NT mag es eine vage Verbindung gegeben haben, doch Cutler versteht NT als New Technology
- Das Marketing wandte ein, ein Name wie „neue Technologie“ könne Käufer abschrecken, doch Cutler setzte den Namen NT durch
- Die erste Version von NT unterstützte mehrere CPU-Architekturen
- Erwähnt werden x86, MIPS R3000/R4000 und Alpha
- PowerPC kam in der Zeit von NT 3.5 oder Daytona hinzu, und Cutler bewertet sowohl die PowerPC-Builds als auch die Hardware-Wettbewerbsfähigkeit als schwach
- Das HAL von NT war ursprünglich eher eine Vendor Abstraction Layer als nur eine Hardware Abstraction Layer
- Anfangs war es als separate DLL aufgebaut, sodass Hersteller das HAL bereitstellen konnten
- Cutler meint rückblickend, es wäre besser gewesen, das HAL stärker als Teil des Betriebssystems zu bauen
- Kernel und HAL von NT enthielten nicht viel Assemblercode
- Einige leistungsrelevante häufige Operationen brauchten Assembler oder Intrinsics
- Bei x64 entschied man sich statt Inline-Assembly eher für Intrinsics
NT-Entwicklungskultur, Cairo, Longhorn, XP-Sicherheit
- Das NT-Team veranstaltete jeden Freitag WHIM, um eine schnell wachsende Organisation zusammenzuhalten
- WHIM steht für Weekly Integration Meeting
- Anfangs brachten Manager Bier und Chips von Safeway mit und hielten das Treffen im Hardware-Labor ab, später wurde es auf größere Räume und Catering ausgeweitet
- Cutler hält Darstellungen, nach denen die NT-Entwicklung die Leute nur ständig verheizt habe, für unzutreffend und sagt, man habe jede Woche bewusst Gelegenheit zum Abschalten geschaffen
- Nach NT 3.5 liefen die Übernahme der Windows-95-Oberfläche nach NT und das Cairo-Projekt parallel
- Tuckwila wurde als eine Art Backup für NT 4.0 weitergeführt; in den täglichen Builds war Tuckwila stabil, Cairo ging dagegen häufig kaputt
- Nach und nach fielen Cairo-Funktionen weg, und als wichtigste übernommene Ergebnisse erinnert sich Cutler vor allem an Dateiserver-Software und Kerberos
- NT 4.0 blieb eine sehr populäre Version, und Cutler sagt, er habe noch Menschen getroffen, die NT 4.0 nutzten
- Der Zeitplan von NT 3.1 war länger als bei VMS
- VMS sei mit einem außergewöhnlich starken Team von rund 20 Leuten in zwei Jahren entstanden
- NT musste mehr leisten, und der Umfang wuchs durch das Aufgeben des i860 sowie das Hinzufügen weiterer Architekturen wie MIPS, x86 und Alpha
- Im Prozess, der zu Longhorn und Vista führte, wurde die Trennung der Codebasis zu einem großen Problem
- Nach Windows 2000 trennten sich die Codebasen für Server und Workstation; während auf der Serverseite viele Sicherheitsprobleme behoben wurden, wurden Builds und Ausführung auf der Consumer-Seite instabil
- XP war ein großer Erfolg, hatte aber viele Bugs, und als die Sicherheitsprobleme zunahmen, floss viel Arbeit in die Behebung von XP-Bugs
- Cutlers Gruppe behob etwa 5.000 sicherheitsbezogene Bugs rund um XP
- AMDs x64-Erweiterung wurde intern bei Microsoft zu einem wichtigen Wendepunkt
- AMD stellte die Idee einer weniger invasiven 64-Bit-Erweiterung vor, die 32-Bit-Anwendungen schnell ausführen konnte
- Cutler entschied, auf Basis der Server-Codebasis 64-Bit-Workstations und -Server zu bauen; das war anfangs kein von der Firma offiziell genehmigtes Projekt
- Als die AMD-Systeme ankamen, wurde zunächst von CD gebootet, und das 64-Bit-System startete und lief sofort
microsoft.comtestete den 64-Bit-Server etwa eine Woche lang und stellte dann um; er wurde als deutlich stabiler als das 32-Bit-System bewertet
- Longhorn wechselte schließlich auf die x64-Codebasis, und diese Codebasis reicht bis heute fort
Interne Windows-Struktur und bis heute erhaltener Code
- In Windows 11 ist noch viel von den Kernfunktionen und -strukturen aus der NT-3.5-Zeit erhalten
- Kernkomponenten wie Kernelcode, Speicherverwaltungsstrukturen, Prozessstrukturen und der Objektmanager bestehen fort
- Der Anteil des ursprünglichen Codes an der Gesamtmenge wird zwar immer kleiner, aber die zentrale Struktur für dieselben Funktionen ist in großem Maß erhalten geblieben
- Cutler nennt den Objektmanager als wichtigen Grund für eine gute Codebasis von NT
- Anders als beim Unix-Prinzip „alles ist eine Datei“ kann man in NT neue Objekt-Typ-Deskriptoren anlegen, in den Objektmanager integrieren und so neue Betriebssystemobjekte hinzufügen
- Objekte können Funktionen wie Synchronisation und Zugriffskontrolle bereitstellen
- Die Handle-Tabelle wurde aus Leistungsgründen mehrfach neu geschrieben
- Die Handle-Übersetzung war ein echtes Performance-Problem
- Als Beispiel nennt Cutler auf seinem Arbeitssystem etwa 60 Prozesse, Hunderte Threads und 150.000 offene Handles
- Das Wachstum des Task-Managers wird als Beispiel für Code Bloat erwähnt
- Ursprünglich wurde der Task-Manager als 85 KB kompiliert, heute soll er 4 MB groß sein
- Er zeigt inzwischen mehr Informationen wie CPU, Netzwerk und Festplatte an, doch Cutler findet nicht, dass der Funktionszuwachs das ganze Größenwachstum erklärt
- Die Entscheidung, Grafiktreiber vom User Mode in den Kernel Mode zu verlagern, war aus Performance-Sicht nötig, brachte aber erhebliche Wachstumsschmerzen mit sich
- Cutler war anfangs gegen den Wechsel in den Kernel Mode
- User Mode und Kernel Mode haben unterschiedliche Synchronisationsmodelle, sodass es keine einfache Codeverschiebung war, und auch 16-Bit-Datenstrukturen und Primitives waren eine Belastung
- Später wurde die Zuverlässigkeit deutlich besser, auch wenn es zeitweise viele Probleme mit Grafiktreibern von Herstellern gab
Azure, Xbox, xCloud
- Nach der Auslieferung von x64-Systemen war Cutler wegen des fcib-Problems so frustriert, dass er Microsoft verlassen wollte; auf Anraten von Steve Ballmer nahm er Urlaub und kehrte im November 2005 zurück
- fcib steht für checked-in binary; weil manche Gruppen Binärdateien statt Quellcode eincheckten, war Portierung schwierig
- Danach beteiligte er sich am frühen Azure-Projekt
- Ray Ozzie stieß das Projekt an, weil es keine gemeinsame Infrastruktur für verschiedene Cloud-basierte Dienste gab
- Das frühe Azure zielte auf Plattforminfrastruktur wie Anwendungsbereitstellung, Konfigurationskontrolle, Versionsverwaltung, Neustarts, Abrechnung und ein Cloud-Dateisystem
- AWS bot eher infrastrukturzentrierte Dienste an, während Microsoft anfangs Plattformservices verkaufen wollte
- Der frühe Azure-Hypervisor entstand auf Basis von Technologie aus der Übernahme von Connectix
- Connectix brachte Produkte wie Virtual PC und Virtual Server mit, und auch die Hypervisor-Entwicklung lief dort bereits in einem frühen Stadium
- Der Hypervisor der Xbox stammt später vom Red-Dog-Hypervisor von Azure ab
- Die Xbox arbeitet mit einer Struktur aus drei VMs
- Das Host-System besitzt alle Geräte und fungiert als Traffic Cop für die Kommunikation zwischen den VMs
- Die Presentation-VM ist für Fenster-Manager und Darstellungssystem zuständig und läuft dauerhaft
- Die Game-VM wird für jedes Spiel gestartet und gestoppt; das Spiel wird zusammen mit dem OS ausgeliefert
- Die Struktur, bei der Spiele mit dem OS paketiert werden, ist vorteilhaft für die Abwärtskompatibilität
- Spieleentwickler paketieren das Spiel zusammen mit dem OS aus dem GDK, und beim Start wird die entsprechende VM mit ausgeführt
- So lässt sich vermeiden, dass Änderungen am Betriebssystem bestehende Spiele kaputtmachen
- Wenn allerdings neue Funktionen in bestehende Spiele gebracht werden mussten, waren Umwege wie ein universal game OS nötig
- Pause/Resume auf der Xbox funktioniert über das Speichern und Wiederherstellen von VMs
- Beim Laden von Spielen sind Datenmengen im Gigabyte-Bereich beteiligt, was Zeit kostet
- Pause/Resume speichert den Zustand der VM und stellt ihn später wieder her
- Als aktuelle Arbeit werden eine Linux-VM und ein Grafik-Stack genannt, die Leerlaufzeiten von xCloud-Konsolen nutzen
- xCloud basiert darauf, Xbox-Konsolen für den Einsatz im Rack neu zu verpacken, in Rechenzentren zu stellen und Fernzugriff bereitzustellen
- Die Konsole ist Single Tenant und wird jeweils nur von einer Person gleichzeitig genutzt, wodurch Leerlaufzeiten entstehen
- Für den Plan, in diesen ungenutzten Zeiten proprietäre Machine-Learning-Workloads von Microsoft auszuführen, arbeitet man an Linux-VM, Xbox-Hypervisor und Grafik-Stack
Qualität, Teamführung, Entwicklungsphilosophie
- Cutler wendet den Satz „Erfolgreiche Menschen tun Dinge, die erfolglose Menschen ablehnen“ auch auf Software-Teams an
- Er sieht Haltungen wie „Ich habe den Code geschrieben, also teste ich ihn nicht“, „Es ist erst 17 Uhr und im Plan ist noch Zeit, also gehe ich trotzdem heim“ oder „Ich will meine eigenen Bugs nicht beheben“ als problematisch an
- Wichtig ist für ihn die Haltung, selbst die nötige Arbeit zu erledigen, damit etwas erfolgreich wird
- Er schätzt den Thinker-doer hoch ein
- Unter Bezug auf Brooks sagt er, es gebe viele Menschen, die nur denken, wenige, die wirklich umsetzen, und noch weniger, die beides tun
- Auch Architekten müssten reale Ergebnisse liefern, die Ziele und Randbedingungen erfüllen
- Den Satz „Wenn man es nicht einbaut, muss man es auch nicht wieder herausnehmen“ hätte er gern an die Laborwand der University of Washington geschrieben
- Er nutzt ihn, um die Zurückhaltung zu betonen, keine unnötigen Funktionen einzubauen
- In frühen Entwicklungsumgebungen waren Debugging-Werkzeuge schwach, daher war eine Haltung wichtig, Fehler von Anfang an zu minimieren
- Früher musste man teilweise sogar Logic Analyzer oder Oszilloskope einsetzen
- Heute helfen Tools stärker dabei, kleine Fehler zu vermeiden, aber der Druck in Bezug auf Qualität sei ein anderer als früher
- Multitasking ist zwar möglich, aber die höchste Produktivität entsteht seiner Ansicht nach bei konzentrierter Arbeit an einer einzigen Aufgabe
- Ein Context Switch kostet Zeit
- Er erklärt jedoch auch, dass er Aufgaben wechselt, um anderen bei blockierenden Problemen zu helfen oder Bugs zu beheben
1 Kommentare
Hacker-News-Kommentare
Der Interviewer Dave Plummer ist selbst eine äußerst interessante Person. Besonders gut fand ich seine Retro-Coding-Videos wie https://www.youtube.com/watch?v=JlZe2JwrJqM und https://www.youtube.com/watch?v=b0zxIfJJLAY
Die Videos sind unterhaltsam, und Hintergrundmusik sowie RGB-Beleuchtung sorgen für Weihnachtsstimmung. Auch Microsoft ließ er für mich in einem völlig anderen Licht erscheinen als das Bild, das ich gewohnt war: Er spricht warmherzig über seine Arbeit, seine Kollegen und Microsoft, während er zugleich die Merkwürdigkeiten von Redmond anerkennt.
Allerdings scheint beim Anschauen dieses Kanals irgendein YouTube-Algorithmus anzuspringen, sodass der Empfehlungs-Feed mit ADHS-Videos überflutet wird. Vermutlich wegen der Videos zu Autismus und ADHS, aber YouTube sollte doch schlau genug sein zu merken, dass ich nur Coding- und Microsoft-Geschichtsvideos angesehen habe.
Ich sage das ungern, aber was er zu Themen außerhalb von Microsoft/Windows sagt, sollte man mit viel Vorsicht genießen. Besonders seit dem folgenden Kommentar [1].
Auch der jüngste Zwang, Adblocker zu deaktivieren, war ein Augenöffner. YouTube-Werbung ist wirklich das Letzte, und es ist fast peinlich, sich vorzustellen, dass echte Menschen darauf reagieren. YouTube scheint sogar den Versuch aufgegeben zu haben, eine gute Nutzererfahrung zu bieten.
Trotzdem lohnt es sich, ein wenig im Schlamm zu wühlen, um so etwas Hervorragendes wie dieses Dave-Cutler-Interview zu sehen.
Das ist kein Witz, und „die Hälfte“ ist auch ziemlich genau. Entweder ist etwas kaputt, oder YouTube hat ein Large Language Model an seine Empfehlungsmaschine angeschlossen.
Mir gefiel es besser, ihn spontan sprechen zu sehen, als ein sauber geschnittenes Video anzuschauen.
Nach diesem einen Video waren meine Empfehlungen voll mit Geschichten über Krebs, Menschen im Sterben und alle möglichen Krankheiten. Dieses Video hatte überhaupt nichts mit den üblichen Inhalten dieser Person zu tun, und ich habe kein einziges der empfohlenen Videos dieser Art angesehen, aber sie wurden mir weiter aufgedrängt.
Ich habe das Video noch nicht gesehen, freue mich aber darauf, weil ich vor ein paar Jahren Showstopper[1] gelesen habe.
Besonders im Gedächtnis geblieben ist mir damals, als ich Anfang 20 war und dachte, man müsse ständig arbeiten, die Stelle, dass Dave seinen Urlaub jedes Mal pünktlich, ohne Diskussion und ganz selbstverständlich nahm.
Auch wenn man Microsoft nicht mögen muss: Das war vermutlich das erste Mal, dass ich wirklich ein Beispiel für eine äußerst fähige und qualifizierte Person sah, die nicht rund um die Uhr zerrieben wurde.
Selbst das so aufzuschreiben fühlt sich immer noch merkwürdig an, aber es war eine Denkweise, die aus einer ländlichen und vom Einzelhandel geprägten Kultur kam, nach dem Motto: „Je mehr man leidet, desto tugendhafter ist man.“
Auch heute fällt es mir schwer, richtig auszuruhen, und es ist leicht, es aufzuschieben, weil X oder Y wichtiger sei. Aber wenn ich an Daves Sichtweise denke, ist das eine gute Erinnerung daran, dass Erholung und X gut zu machen keine Entweder-oder-Entscheidung sind.
[1]: https://www.amazon.com/Show-Stopper-Breakneck-Generation-Mic...
„Gedenke des Sabbattages, dass du ihn heiligst … Sechs Tage sollst du arbeiten und alle deine Werke tun; aber der siebte Tag ist der Sabbat des HERRN, deines Gottes …“
https://en.wikipedia.org/wiki/Protestant_work_ethic
https://www.biblegateway.com/passage/?search=Exodus%2020&ver...
Je mehr Mitarbeiter „die Nase am Schleifstein“ haben und sich „den Rücken krumm machen“, desto mehr steigt der Unternehmensgewinn, ohne dass man ihnen mehr Gehalt zahlen muss. Wenn ihre Gesundheit so weit ruiniert ist, dass sie nicht mehr arbeiten können, ersetzt man sie eben.
Entschuldigung, dass das als spät nachts geschriebene Antwort etwas grob klingt, aber ich denke, die Leute hier wissen das ohnehin intuitiv.
Dann kam der Burnout, und inzwischen sehe ich es nicht nur als persönliche Verantwortung, sondern auch als berufliche Verantwortung, sich zu erholen und Arbeitstage von acht Stunden einzuhalten, außer in echten Notfällen. Das senkt das Burnout-Risiko, und Burnout ist im wörtlichen Sinn für alle schlecht.
Ich habe gelesen, dass gegen Ende der Entwicklung von WinNT 3.1 jemand einen Bildschirmschoner gebaut hatte, der einen Bluescreen anzeigte. Vielleicht war es auf Usenet.
Bis dahin hatte ich noch nie einen Bildschirmschoner geschrieben, aber wegen eines Bugs in einem internen Microsoft-Netzwerktreiber konnte ich meine WinNT-Entwicklungsmaschine zuverlässig zum Bluescreen bringen.
Also las ich die Dokumentation zum Schreiben von Windows-Bildschirmschonern, notierte die Werte, die auf meinem Bluescreen angezeigt wurden, und bastelte meinen ersten und letzten Windows-Bildschirmschoner zusammen.
Aus Spaß schickte ich eine Mail an die Windows-NT-Gruppe und erzählte von meiner Kreation, und ein paar Wochen später beschloss die NT-Build-Gruppe, Dave Cutler einen Streich zu spielen.
Sie installierten meinen Bluescreen-Bildschirmschoner auf einem der Build-Server, zogen außerdem Maus und Tastatur ab und warteten.
Dave Cutler kam vorbei, um nach dem Status des neuesten NT-Builds zu sehen, schaltete den Monitor ein und sah den Bluescreen. Er bewegte die Maus, aber nichts passierte; er tippte auf der Tastatur, aber nichts passierte.
Und dann geschah das Unerwartete. Er streckte die Hand aus und drückte den Power-Button des Build-Servers, um ihn neu zu starten. NOOOOOOOOOOOOOOOOOOOOO
Von den Nachwirkungen oder Konsequenzen dieses Streichs habe ich nie etwas gehört. Mit großer Macht kommt große Verantwortung.
Ich hatte ihn auch installiert, und ein paar Kollegen, die in meiner Nähe saßen, ebenfalls.
Der CTO kam wegen eines Meetings am frühen Morgen vorbei, sah das auf allen Bildschirmen und geriet leicht in Panik, weil er dachte, es sei eine Virusausbreitung oder ein Software-Bug.
Ich empfehle auch das Buch „Showstopper!: The Breakneck Race to Create Windows NT and the Next Generation at Microsoft“, das hier vor ein paar Wochen jemand empfohlen hatte.
Ich bin noch dabei, es zu lesen, aber es ist wirklich spannend, und es lässt mich wünschen, ich wäre Teil dieser Geschichte gewesen. Besonders der Teil, in dem ein völlig neues Betriebssystem dogfooded wurde. Es war nur ein paar Jahre vor meiner Zeit.
Durch das Buch klang ich, als wüsste ich viel mehr, als tatsächlich der Fall war, und ich war für das ganze Gebiet deutlich begeisterter als noch ein paar Tage zuvor.
Ich bekam ein Angebot, nahm die Stelle am Ende aber nicht an.
Dazu gibt es auch das hier: https://blog.codinghorror.com/showstopper/
Interessant fand ich, dass der Xbox-Hypervisor nicht aus der Desktop-Ecke stammt, sondern Azure-basiert ist, und dass Xbox-Spiele nicht von einem einzelnen Betriebssystem auf dem Gerät abhängen, sondern zusammen mit dem Betriebssystem paketiert werden und damit eher Containern ähneln.
Dave sagte außerdem, er arbeite daran, Machine-Learning-Jobs auf im Leerlauf befindlichen Xbox-Cloud-Gaming-Geräten laufen zu lassen. Dass es zwischen Azure und Xbox eine solche architektonische Verbindung gibt, hatte ich überhaupt nicht auf dem Schirm.
Zum Beispiel ist die ausführbare Datei eines Spiels tatsächlich auf der Spiele-Disc verschlüsselt, und selbst das Dumpen des tatsächlich laufenden Binaries ist nahezu unmöglich. Auch der RAM ist verschlüsselt.
Außerdem war einer der Gründe, warum moderne TPMs in die CPU gewandert sind, zu verhindern, dass Leute den TPM-Bus ausspähen, so wie sie es bei der Xbox getan haben.
Ich habe im Windows-Kernel-Team gearbeitet, und meine Lieblingsgeschichte über DC ist, dass er die Itanium-Architektur so sehr hasste, dass er x64 praktisch möglich gemacht hat.
Er arbeitete mit AMD zusammen und trieb das Ganze im Grunde voran, während er in seinem Eckbüro weiter Code schrieb.
Die Idee war: „Wenn man mehrere, manchmal variabel lange Bit-Instruktionen in ein Wort bündelt und den Compiler-Autoren überlässt, die optimale Bündelung der Instruktionen zu finden, wird die Implementierung einfacher und kann schneller werden.“ Wenn der Compiler diese optimale Bündelung aber nicht findet, ist es am Ende langsamer als ein traditionelles Design wie x86.
Irgendjemand sehr weit oben bei Intel muss diese Idee wirklich geliebt haben. Denn über die gesamte Geschichte von Intel als bedeutendem Mikroprozessorhersteller hinweg haben sie es dreimal versucht und sind dreimal gescheitert.
Damals galt AMD64 nicht als gute Idee, weil es „mehr vom Gleichen“ war. Trotzdem war es gut, dass Dave dazu beigetragen hat, den Ballast wegzuräumen, der die RISC-Revolution praktisch beendet hatte.
Hoffentlich schaffe ich es eines Tages auch, in meiner Freizeit etwas annähernd so Beeindruckendes zu bauen.
Leider für Microsoft ging diese Beute an Linux auf x86-64.
Einer der prägendsten Momente meiner Software-Engineering-Laufbahn war, als ich vor 6–7 Jahren den geleakten NT-Quellcode las und parallel dazu Showstopper[1].
Der NT-Leak war besonders faszinierend, weil die gesamte Autorenhistorie enthalten war und man sehen konnte, an welchen Dateien Dave Cutler genau gearbeitet hatte. Das Buch behandelt auch ausführlich Dinge wie die Entstehung auslagerbarer Sections in Kernelmodulen, was schon für sich genommen interessant ist.
Im Buch gibt es eine Szene, in der Cutler hereinkommt und bestimmte Assembly-Routinen überarbeitet, und im tatsächlichen Quellcode kann man genau sehen, welche Routinen das waren.
Cutlers Code war wirklich wunderschöner C-Code, und das ist er sicher auch heute noch. Er hat stark beeinflusst, wie ich C-Code im NT-Stil schreibe.
[1]: https://www.amazon.com/Show-Stopper-Breakneck-Generation-Mic...
Auch das Oral-History-Interview mit David Cutler des Computer History Museum ist sehr gut.
Part 1: https://youtu.be/29RkHH-psrY
Part 2: https://youtu.be/SVgSLud50ss
Ich habe ein paar Ausschnitte aus dem neuen Interview gesehen, bin mir aber bislang nicht sicher, ob ich etwas Neues gehört habe.
Wenn man auf das zurückblickt, was die beiden Daves gesagt haben, wird dem Fertigstellen und Ausliefern enorme Aufmerksamkeit gewidmet, aber es gibt kaum Aussagen zu langfristiger Planung oder einer echten Sicherheitsstrategie.
Es geht alles darum, unter kommerziellem Druck Würste aus dem Fleischwolf zu drehen und Ausfälle auf ein akzeptables Maß zu senken.
Es ist nicht überraschend, dass die Lage in der gesamten Branche nicht besser wird und sich nicht in die richtige Richtung bewegt. Ich dachte, wir würden irgendwann bei capability-basierter Sicherheit ankommen, aber inzwischen sieht es so aus, als blieben wir für immer bei ihrem nahezu wertlosen Cousin hängen: Berechtigungs-Flags für Anwendungen.
Ich mache mir Sorgen um die Zukunft.
Ein gutes Quartal oder ein paar gute Jahre reichen, um den Aufstieg vom VP zum SVP und vom SVP zum CEO zu rechtfertigen. Niemand macht die Person, die drei Jahre später in eine neue Rolle gewechselt ist, für kurzsichtige Entscheidungen in ihrer vorherigen Rolle verantwortlich oder bestraft sie dafür.
Das heißt nicht, dass Cutler so eine Führungskraft ist. Aber er stand offensichtlich unter dem Druck von oben, Releases zu liefern und den Umsatzfluss aufrechtzuerhalten. Wie er zu Beginn des Interviews sagt, hasst er es wirklich, Bugs auszuliefern, ist sehr enttäuscht von der Qualität der Software Engineers in der Branche und verabscheut es auch, wenn Programm-/Projektmanager jeden Bug wie einen seltenen Corner Case behandeln. In allen drei Punkten stimme ich zu.
Die meisten Bugs, die ich melde, werden ebenfalls als „Corner Cases“ behandelt, obwohl ich jeden Tag darüber stolpere und es in der Datenbank mehrere Duplikate gibt oder mein Bug wiederum als Duplikat eines früheren Reports markiert wird.
Ich habe Jahrzehnte in dieser Branche verbracht, ausschließlich in Big Tech, und ich habe noch kein Unternehmen gesehen, das am Ende nicht demselben Druck nachgibt, selbst wenn Engineers und First-Line-Manager darauf drängen, Bugs vor dem Release zu beheben und häufigere Bugfix-Updates fordern.
Das war ein großes Verkaufsargument, kam bei den meisten Nutzern aber kaum an. Tatsächlich hatten viele das Gefühl: „Wozu brauche ich das?“ Und es ließ das System so wirken, als sei es kein Betriebssystem für „normale Nutzer“.
Die Sicherheitsvorstellungen der frühen 1990er – also was Sicherheit ausmacht und für wen sie in welchem Maß relevant ist – passen nicht zu heutigen Erwartungen oder zum aktuellen Stand der Technik.
Es könnte eine Weile dauern, bis das richtig umgesetzt ist. In der Zwischenzeit hoffe ich, dass keine halb gare, den Status quo verstärkende und rückschrittliche Alternative auf Basis einer einzigen Runtime gewinnt.
[0]: https://github.com/bytecodealliance/wasmtime/blob/main/docs/...
Das ist vielleicht der größte wirtschaftliche „Beitrag“, den Software uns gebracht hat: bindende Verträge nach dem Motto „Wir nehmen dein Geld, versprechen aber nichts, du Trottel!“
Dafür wird man bestraft, wenn man erst als Zweiter auf den Markt kommt.
Ich freue mich darauf, mir das alles anzuhören.
Unabhängig davon, was man von ihm oder dem Unternehmen hält, für das er arbeitet: Cutler war durch seine Arbeit an OpenVMS und Windows NT ein sehr einflussreicher Software Engineer. Ich finde, über ihn wird nicht so häufig gesprochen wie über Leute von Bell Labs, Stallman, Linus oder Stroustrup.