Zum Ruhestand veröffentlicht ein Entwickler seinen in über 40 Jahren aufgebauten Quellcode

 (dunfield.themindfactory.com)
5 Punkte von GN⁺ 2023-11-04 | 1 Kommentare | Auf WhatsApp teilen
  • Ein Entwickler veröffentlicht anlässlich seines Ruhestands den über mehr als 40 Jahre angesammelten Quellcode, sodass alte Systeme, Werkzeuge und persönliche Projekte direkt eingesehen werden können
  • Der Umfang der Veröffentlichung reicht bis zu Betriebssystemen und Kerneln, darunter ein Multi-Prozess-/Task-Kernel für ARM, ein Betriebssystem für die 6809-CPU und ein frühes OS aus der Altair-1980-Ära
  • Ebenfalls enthalten sind Low-Level-Entwicklungswerkzeuge wie der Micro-C Compiler, Cross-Assembler, Disassembler, ein 8052-Emulator und Debugger
  • Breit veröffentlicht werden zudem Utilities für die PC-Arbeit wie DOSBox, DOS-Utilities, Dateisynchronisierung, ZIP-Verarbeitung, Erzeugung von Installationspaketen und Texteditoren
  • Auch persönliche Hardwareprojekte wie Amateurfunk, eine RS-232-Infrarot-Fernbedienung, Ethernet TTY, X10-Steuerung und ein Roboter zum Einlesen von 1500 DVDs sind enthalten, was der Sammlung hohen Archivwert verleiht

Zweck der Veröffentlichung und Begleitdokumente

  • Anlässlich seines Ruhestands veröffentlicht der Autor über 40 Jahre angesammelten Quellcode, also Dinge, „die ich geschrieben habe“
  • Ziel der Veröffentlichung ist, dass andere diesen Code nützlich verwenden oder an Teilen davon lernen können
  • Auf der Veröffentlichungsseite werden außerdem folgende Dokumente genannt:

Betriebssysteme, Kernel, virtuelle Maschinen, Simulation

  • ARMOS: Multi-Prozess-/Task-Kernel für ARM
  • CUBIX: Betriebssystem für die 6809-CPU
  • DMF: frühes OS aus der Altair-1980-Ära
  • DVM: Dunfield Virtual Machine
  • SIMSYS: Systeme rund um Altair, D6809, H8, Horizon und Mod8
  • MONITORS: Monitore für verschiedene Embedded-Prozessoren
  • 8051ICE: In-Circuit-Emulator mit EMILY
  • EMILY52: 8052-Emulator

Compiler, Assembler, Debugger, Entwicklungswerkzeuge

  • MICRO-C: Micro-C Compiler
  • MCSAMPLE: Beispielprogramme für Micro-C
  • XASM: Cross-Assembler und Werkzeuge
  • DISASM: Cross-Disassembler
  • DMS: Dunfield MicroScope Debugger
  • DESMO: Debug Scripting Monitor
  • DDSIDE: Dunfield Development Systems IDE
  • BLDTOOL: Werkzeug zur Unterstützung von Build-Aufgaben
  • PUBSRC: Wartungswerkzeug für den Bereich veröffentlichter Quellcodes
  • HFC: Help File Compiler
  • ESL: Extensible Script Language

DOS-, Datei-, Disk-, Editier- und Packaging-Utilities

  • DBBD: Boot-Floppy-Disk für DosBox
  • DBUTIL: DosBox-Utilities
  • DD_DBSRC: DosBox-Quellcodebaum
  • DOSUTIL: verschiedene DOS-Utilities
  • FDI: Floppy Disk Image
  • IMDSRC: ImageDisk
  • EDT: EDT-Texteditor
  • ELF: Werkzeug zum Bearbeiten langer Dateinamen
  • FTOOLS: verschiedene Werkzeuge für Dateioperationen
  • SYNC: Synchronisierung zweier Verzeichnisbäume
  • ZDIR: Dateien in ZIP-Archiven auflisten und touch
  • MAR: MicroARchiver zum Komprimieren von Installationsdateien
  • MKPKG: Erzeugung von Installationsdateien als einzelne .exe-Pakete
  • ESP: Patchen von Zeichenketten in ausführbaren Dateien
  • PT: PaperTape-Werkzeuge
  • MICROCAD: sehr kleines CAD-Zeichenprogramm

Hardware, Kommunikation, Steuerung, persönliche Projekte

  • DARC: Dunfield Amateur Radio Controller
  • HTX242: Steuerung des Amateur-Transceivers RS HTX-242
  • ICOMCIV: ICOM-CI-V-Interface-Code für den Amateurfunk
  • IR232: lernfähige RS-232-Infrarot-Fernbedienung
  • ETTY: Ethernet TTY
  • SNIFF: Ethernet-Sniffer
  • DLM: Data Line Monitor
  • ITS: Interactive Terminal Switch
  • DDLINK: DavesDataLink für Dateiübertragungen über COM, LPT und NET
  • SERCNCT: Umschaltung mehrerer Geräte an einem COM-Port
  • DBOX: Sony-VCR-Controller
  • DVDROBOT: Roboter zum Einlesen von 1500 DVDs
  • EPROM: EPROM-Programmiergerät
  • 8031DWG: Musterdesign auf Basis des 8031
  • X10CTRL: Steuerung von X10-Geräten vom PC aus
  • RINGSW: Schalter für distinctive ring auf Telefonleitungen
  • PC100: VT-100-Terminalemulator
  • LABTOOLS: verschiedene Labor-/Testwerkzeuge
  • CAM: Projekt für Kinder mit Entwicklungsstörungen
  • MACMON: Überwachung/Protokollierung der Netzwerknutzung von Kindern
  • TRANZTCL: Entwicklungstools für Verifone TRANZ PointOfSale

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2023-11-04
Hacker-News-Kommentare

  • Beim Durchsehen von DOSUTIL.ZIP gefallen mir die einfachen und eleganten C-Programme wirklich gut
    Beeindruckend ist auch, dass viele davon nur ein bis zwei Zeilen Standard-C-#includes verwenden und es in 20.000 Zeilen C-Code nur 24 #ifs gibt
    Die Erfahrung, eine solche Codebase zu lesen, war eine Inspiration, als ich mit der Arbeit an Cosmopolitan Libc begann

    • Wenn es nur ein Build-Ziel gibt, kann man die Zahl der #if-Makros stark reduzieren
    • Alte C-Compiler ließen alle möglichen Fehler einfach durchgehen, die moderne C-Compiler sauber erkennen würden
    • Auf der Rust-Seite habe ich einen einfachen HTTP-Listener mit einer einzigen Route geschrieben, und Cargo zog etwa 105 Abhängigkeiten heran, um ihn zu bauen
      Für einen fairen Vergleich muss man aber sagen, dass es nur zwei use-Anweisungen sind
    • Umgekehrt gibt es in C auch eine Hash-Tabelle, die nur mit Makros implementiert ist. Ziemlich cool: https://troydhanson.github.io/uthash/

  • Die Konvention True=7 in STYLE.TXT kam mir ungewohnt vor
    Dort steht, dass man wegen Erfahrung mit Low-Level-Code und Hardware, um „auf niedriger Ebene möglichst wenig schiefgehen zu lassen“, in C manchmal 7 statt 1 als wahr verwendet hat, unter Ausnutzung der Tatsache, dass 0==FALSE und !0==TRUE gilt
    Das ist eine gewohnheitsmäßige Entscheidung, weil eine Differenz von 3 Bits besser sei als eine von 1 Bit; tatsächlich würde bei einem solchen 1-Bit-Hardwarefehler wohl der Großteil des Systems kaputtgehen, und der Autor räumt selbst ein, dass es töricht ist
    Ich frage mich, ob früher zufällige Bit-Flips häufig Bedingungen zerstört haben

    • Selbst wenn so etwas vorkam, kann man nicht jede Bedingung wie einen ternären Boolean betrachten
      Man müsste festlegen, welcher Zweig im Fehlerfall sicher ausgeführt werden darf, ob man die Bits jeder Bedingung zählt und sie als wahr ansieht, wenn mehr Einsen als Nullen vorhanden sind, und ob man ohne Fehlerkorrektur protokolliert oder den Operator informiert, dass ein Bit umgekippt ist
      Es gibt Bereiche, in denen Fehlererkennungscodes nützlich sind, aber einfach wahr als 7 festzulegen reicht nicht aus
    • Der Autor hat im Grunde selbst eingeräumt, dass es eine törichte Angewohnheit ist, und ich finde sogar, dass die Absicht dadurch weniger klar wird
      Trotzdem hat es Spaß gemacht, das Style-Dokument zu lesen, und ich finde gut, dass er alles so offen zugänglich gemacht hat. Für irgendjemanden ist da bestimmt genau das passende Werkzeug dabei
    • Wenn man prüft, ob eine serielle Datenleitung funktioniert, verwendet man 0xA5 (1010 0101), um eine leicht abgewandelte alternierende Bitfolge zu senden
      So versucht man, möglichst viele mögliche Fehler auf einmal zu erkennen
    • Wenn man sich darüber so viele Sorgen macht, ist TRUE=7 keine echte Lösung
      Bei einer booleschen Variable müsste man für jede Bedingung if (var == TRUE), else if (var == FALSE) und den Fall anderer Werte behandeln, und dieser Behandlungscode selbst darf ebenfalls nicht abstürzen
      Außerdem können Bit-Flips auch Variablen betreffen, die in einem switch verwendet werden, Bedingungen wie if (i > 17), Pointer, Rücksprungadressen auf dem Stack oder den Code selbst
      Bestenfalls ist das eine sehr partielle Lösung, und die Umsetzung ist auch nicht trivial; als Standardkonvention kann man es daher kaum betrachten
    • Es ist wohl weniger ein häufiges Problem als eher „es könnte passieren, also verhindern wir es dort, wo es einfach ist“
      Persönlich hätte ich vermutlich -1 verwendet

  • Ich bedauere sehr, dass ich meinen alten Code nicht ordentlich aufbewahrt habe
    Mein erstes nicht triviales Programm, ein Snake-Spiel, mein erstes in Assembler geschriebenes Utility, mein erster Gerätetreiber für einen Centronics-Drucker und sogar ein in Pascal in einer Stunde mit heftigem Kater für eine Uni-Aufgabe geschriebener ewiger Kalender – all das hielt ich für belanglos und nicht aufhebenswert
    Am Ende ist kein Code von vor Ende der 1990er übrig geblieben. Junge Entwickler sollten ihren Code gut aufbewahren

    • Da Kinder heute Git und verschiedene Hosting-Hubs verwenden, verschwindet Code seltener; dieses Problem dürfte wohl nur unsere Generation betreffen
      Natürlich wird es zum Problem, wenn solche „kostenlosen“ Dienste eingestellt werden, daher ist Self-Hosting ebenfalls sinnvoll
    • Ich habe noch viel alten Code, aber er ist mir zu peinlich, um ihn mir noch einmal anzusehen
    • Bei mir ist es ähnlich. Ich habe auch ein DOS-Tabellenkalkulationsprogramm geschrieben, es gab modeX-Diagramme und Formeln, außerdem ein paar Spiele und ein paar Viren
      Damals wirkten TSRs wie Magie. Vielleicht liegt das alles noch irgendwo auf Disketten im Keller meiner Mutter

  • Auch der Text, in dem der Autor auf seinen Beinahe-Tod 2019 zurückblickt, ist lesenswert: https://dunfield.themindfactory.com/2019.htm

    • Das war eindringlich. Es erinnerte mich an meinen Schwiegervater, der 2015 einen Herzinfarkt hatte, bei dem 90 % seines Herzens geschädigt wurden
      Seine Untersuchungsergebnisse waren so schlecht, dass ein Arzt die Behandlung verweigerte, aus Angst, er könne jederzeit während des Termins sterben
      Aber er lebt immer noch, kommt normal zurecht und läuft jeden Samstag am Strand. Die Befunde sind nicht besser geworden und er ist ständig kurzatmig, aber er wirkt einfach wie jemand, der sich weigert zu sterben
      Das ähnelt dem Satz des Arztes im Link: „Sie sehen viel besser aus, als es auf dem Papier steht“
    • Ich frage mich, warum Ärzte so etwas tun
      In dem Text gab es die Stelle, dass ihm sogar Dinge wie „die Kinder umarmen, im eigenen Bett schlafen, essen und ein wenig mit den Händen arbeiten“ abgesprochen wurden; als sich mein Vater mit Leukämie und Lungenentzündung nicht besserte und nicht vom Beatmungsschlauch wegkam, sagten die Ärzte ebenso nachdrücklich, dass er lebenslang behindert sein werde
    • Seltsamerweise musste ich an H. P. Lovecrafts The Shadow Out of Time denken
    • Düster, aber am Ende wirkt es wie ein Happy End

  • Wirklich gut. Ich habe schon oft daran gedacht, irgendwann einmal etwas Ähnliches zu machen.
    Es ist ein bisschen so, als würde man von den Großeltern einen Nachlass bekommen. Echte Juwelen und kuriose Dinge werden zwischen Krimskrams und Müll liegen, aber das Ganze erzählt die Geschichte realer Menschen, die ein reiches und interessantes Leben geführt haben.
    Mit ein paar Highlights allein lässt sich dieses Leben nicht wirklich einfangen.

    • Warum sollte man das erst nach der Rente tun? Warum nicht gleich jetzt?
    • Ich wünschte, ich hätte von den Dingen, die ich in 40 Jahren Programmieren gebaut habe, etwas aufgehoben, aber bei jedem Wechsel zu einem neuen Job habe ich alles zurückgelassen.
      Zum Glück habe ich noch einen kommerziellen Speicher-Allokator aus den späten 90ern. Er war single-threaded und unterstützte nur Metrowerks CodeWarrior und das alte MacOS, war aber der schnellste und fehlerfreieste Allokator auf dem Mac.
      Mit dem Erscheinen von MacOS X wurde er nutzlos, und ich weiß nicht, wen das heute noch interessieren würde.
      Wie ich gestern sagte, habe ich den Quellcode von Trapeze verloren (https://en.wikipedia.org/wiki/Trapeze_(spreadsheet_program)). Ich glaube, ich bin nie auf die Idee gekommen, meine Arbeit aufzubewahren, um sie später zu teilen, wenn sich niemand mehr darum kümmert.

  • Wirklich großartig. Verglichen damit, wie meine Code-Historie später einmal aussehen wird, wirkt das wie ziemlich reiner Code.
    Im Jahr 2040 wird mein Code vermutlich Spuren davon zeigen, dass er jede Menge Bibliotheken und Frameworks verwendet hat, die „heute niemand mehr nutzt“.
    Das ist keine Frage von gut oder schlecht, sondern nur ein Spiegel der Zeit.

    • Wenn du diese Abhängigkeiten nicht selbst archivierst, kann es später sein, dass niemand den Code noch richtig lesen oder bauen kann.
      Die heute beliebten Entwicklungspraktiken sind erstaunlich vergänglich und fragil. Von den heutigen Projekten werden nur sehr wenige 10 Jahre unbetreut überstehen, 40 Jahre erst recht nicht.
    • Dieses ganze pip install und npm install wird wertlos werden.

  • Das einflussreichste Utility ist meiner Meinung nach ImageDisk.
    Es wurde genutzt, um mit IBM-PCs Disketten aus verschiedensten Computertypen zu sichern, und viel alte Software auf bitsavers.org und archive.org wurde mit diesem Tool wiederhergestellt.

  • In Vernor Vinges A Deepness in the Sky gibt es eine menschliche Gesellschaft Tausende Jahre in der Zukunft, in der fast jede Software bereits geschrieben ist und das Problem nur darin besteht, sie zu finden.
    Deshalb durchstöbern Programmierer-Archäologen Archive und führen Code bei Bedarf in einem Emulator in einem Emulator in einem Emulator aus: https://garethrees.org/2013/06/12/archaeology/
    Du hast also zu einem Schatzhaufen beigetragen, von dem jemand profitieren wird, ob morgen oder in 5.000 Jahren.

    • Ingenieure, die Vinge mögen, lieben besonders die Stelle, an der man gemeinhin annimmt, der Kalender der Gegenwart, also der fernen Zukunft, richte sich nach der ersten bemannten Mondlandung, in Wirklichkeit aber nach der Unix Epoch.

  • Als Scherz über den letzten Bugfix kurz vor der Rente: Ich wollte mir micro-cad ansehen, bekam aber einen 404.
    URL: https://dunfield.themindfactory.com/dnld/sc/MICROCAD.ZIP
    Erwartetes Verhalten wäre, dass man die .zip-Datei herunterladen kann.

    • Im MCSAMPLE-Zip scheint das Ganze mit enthalten zu sein.
    • Ich bin auf denselben 404 gestoßen. Es gibt nicht viele originale CAD-Programme, deshalb würde ich mir dieses unbedingt ansehen wollen.

  • Hervorragend. Ich habe mir einige persönliche „Bibeln“ aufgebaut, die ich bei bestimmten Sprachen oder Automatisierungsaufgaben immer griffbereit habe, und auch einige Organisationsmethoden, die ich auf HN gelernt habe.
    Allerdings kamen sie mir immer zu persönlich und zu sehr auf meine Denkweise zugeschnitten vor, sodass ich nie daran gedacht habe, sie zu veröffentlichen.
    Aber nachdem ich solche Materialien gesehen habe, fühle ich mich inspiriert. Eine wirklich großartige Idee, und wenn möglich würde ich das Ruhestandsprojekt auch gern als Dank finanziell unterstützen.

    • Ich bin neugierig, was du mit „Bibeln“ genau meinst.
      Und ich würde gern wissen, welche Organisationsmethoden du gelernt hast. Ich bin immer daran interessiert, Produktivitätstipps oder Software anderer Leute kennenzulernen.
    • Ich habe auch eine ganze Reihe solcher Bibeln.
      Falls du Interesse hast, würde ich gern Dateien austauschen. Ich glaube, ich könnte aus deinen Materialien viel lernen. Mein Gmail-Nutzername ist derselbe wie mein HN-Nutzername.