Museum herstelt oude tape met Unix v4: eerste versie in C is nu te downloaden

De 52 jaar oude computertape die dit jaar tijdens opruimwerkzaamheden werd teruggevonden, is hersteld en bevat inderdaad Unix v4: de eerste versie die in C is geschreven. Het uitlezen van de tape en het decoderen van de data is uitgevoerd door het Computer History Museum in Californië.

Het historische besturingssysteem, afkomstig van de universiteit van Utah, is geüpload naar het Internet Archive en daar gratis te downloaden. Gebruikers kunnen de software draaien via de simulator SimH, schrijft The Register. Het Internet Archive biedt zowel de ruwe analoge tapeopname als een digitaal image aan, dat op basis van die opname is gemaakt.

Het uitlezen van de tape vond op 19 december plaats met een speciaal aangepaste lezer en is vastgelegd op video. De output werd vervolgens geanalyseerd met de 'readtapetool' van het Computer History Museum. Dit herstelprogramma leest niet de opgeslagen bytes of sectoren, maar registreert de ruwe magnetische variaties op het opslagmedium. Deze methode maakt een vorm van foutcorrectie mogelijk.

De negentracktape van het befaamde Bell Labs werd gevonden tijdens opruimwerkzaamheden in een kelder van de universiteit van Utah. Op het label, geschreven door informaticus en Unix-expert Jay Lepreau, stond 'UNIX Original from Bell Labs v4'. Dit blijkt nu te kloppen.

De 52 jaar oude tape van de universiteit van Utah, geplaatst in een speciale tapelezer. Bron: Internet Archive

Reacties (107)

[LizardBloke]

Wauw, dat een tape na zoveel jaar nog goed uit te lezen is! Ik ga er sowieso vanuit dat de hiervoor gebruikte tapes van veel beter materiaal zijn gemaakt, maar tapes blijven vaak toch wel erg gevoelig dacht ik. Zijn tapes voor software anders dan tapes voor geluid? Of maakt de codering dat het minder gevoelig is voor afbraak?

[scsirob]

Tapes van die generatie zijn net zo fragiel als audio tapes, met alle gevolgen van dien. Wanneer ze niet goed bewaard worden dan kan machnetische informatie 'doordrukken' van de ene laag naar de andere. De magnetische veldjes hadden geen hele hoge coërcitiviteit. Zet er een stevige magneet of een ouderwetse draaischijftelefoon bij en de bitjes vallen om. Bescherming bestond uit een enkel parity bit, niet heel bijzonder. Fysiek kan de magnetische laag door inwerking van vocht en door uitdrogen van de drager beschadigd raken en zelfs loslaten van de drager. Dat deze tape 52 jaar overleefd heeft is heel netjes. Ik heb zelf wat datatapes van een jaar of 30 oud en die doen het meestal nog wel. De drives daarentegen worden steeds slechter door uitdrogende rubber capstanwieltjes, droge lagertjes etc.

Tapes voor data zijn vanaf de jaren '80 gemaakt voor 30 jaar archief. Erw ordt gebruik gemaakt van read-after-write, ECC error correctie, FEC en nog veel meer om bit errors te detecteren en corrigeren. Voorwaarden voor lange archieftijden zijn een stabiele temperatuur en luchtvochtigheid. De nieuwste generatie LTO-10 tapes worden gemaakt op aramide dragers. Super sterk, maar ook superdun. Veel hogere coërcitiviteit, een flinke magneet heeft geen invloed meer. Ik vermoed dat dat soort tapes over 100 jaar ook nog leesbaar zijn.

[- peter -]

Backups worden/werden ook altijd op tape gedaan. Denk dat t vrij duurzaam is eigenlijk. Maar goed, dit is wel natuurlijk decennia oud.

[LizardBloke]

Ik vraag me af waardoor het zo duurzaam is! Wanneer het gaat om geluidsopnames gaat de kwaliteit relatief snel achteruit. Maar ik kan me voorstellen dat voor de opslag van geluid meer nuance nodig is dan voor de opslag van data.

[Blokker_1999]

Kwaliteit gaat achteruit als je een kopie van een kopie van een kopie maakt. Maar dat is hier niet van toepassing. Magnetische opslag is redelijk duurzaam te noemen. Daarnaast heeft men niet gewoon de tape uitgelezen, maar is men gaan kijken naar de analoge waardes die men vanuit de leeskop krijgt. Hierdoor kan men er een analyse op uitvoeren en zo bepaalde fouten voorkomen door de tolerantie aan te passen waar nodig.

Maar neem je vandaag een VHS casette uit de jaren '90, als je die nog hebt, dan zal je zien dat die kwalitatief ook nog altijd vrij goed is, en dat is dan een tape die vele malen goedkoper gemaakt moest kunnen worden en aan lagere standaarden moest voldoen dan deze tape.

Dus nee, mij verbaasd het niet dat men dit heeft kunnen recupereren.

[Wim Cossement]

Een beetje zoals SpinRite, ik heb dat ook ooit eens kunnen gebruiken om iemand met slechte blokken of sectoren op een gewone HD waar 1 mapje met gebruikersdata onleesbaar was omdat de schijf kuren had.
Ik denk dat ik wel mijn punt inzake regelmatig, zelfs dagelijks, back-ups nemen goed kunnen maken had, want dat als je in je laatste jaar zit als doctoraatsstudent en je bent zo slim geweest om alles in die map te pleuren en te laten gisten en zo 5-4 jaar gegevens en werk kwijt gaat zijn denk ik dat je wel even bleek wordt. Dat is ondertussen ook al bijna 20 jaar terug maar toch...

[LizardBloke]

Mijn referentiekader was vooral het gebruik van tapes in muziekstudio’s waarbij naar wat ik begrijp relatief snel verlies optreedt (zoals in het hogere frequentiebereik). Daarom vroeg ik me vooral af of het verschil in duurzaamheid zit in de tape zelf, of door de manier waarop data wordt opgeslagen op de tape zelf (dus hoe dat in amplitudes en/of frequenties wordt uitgedrukt).

In de context van audio kan een klein verlies van data betekenen dat bepaalde tonen minder goed gereproduceerd worden, maar ik kan me voorstellen dat dat niet opgaat voor digitale opslag. Als je het puur op zou slaan als amplitudesequenties zou het technisch gezien niet veel minder moeten uitmaken als er kleine verliezen optreden bijvoorbeeld.

[scsirob]

Simpel. Een 30TB LTO-10 tape kost misschien 150 Euro. Eenmaal geschreven heeft het geen stroom meer nodig. Stop een library vol en je hebt vele Petabytes onder handbereik, terwijl het relatief weinig stroom vraagt.

Het is geen technologie voor thuis meer, maar hyperscalers en grote banken, verzekeraars en wetenschappelijke organisaties zweren erbij. Hoe denk je dat CERN de data van de collider bewaart? Waar denk je dat AWS Glacier mee gebouwd is?

[LizardBloke]

Dat was niet echt de vraag die ik stelde Ik vind het ook een logische opslagoplossing, maar ik denk vooral aan de duurzaamheid als in dat de data lang goed blijft.

Maar mijn referentiekader is dan ook het gebruik van tapes in muziekstudio’s. Ik hoor weleens dat de kwaliteit van geluidsopnames op tape relatief snel achteruit gaat, zoals detail in het hogere frequentie gebied. Maar de opslag van analoog geluid lijkt mij heel anders dan digitale data in hoe dat met amplitudes wordt uitgedrukt. Ik vroeg me in dat opzicht af hoe dat de duurzaamheid van de opslag beïnvloedt. En of dat dus kwam door de wijze waarop data wordt gecodeerd, of dat het lag aan de tape zelf.

[Cyberpuppy]

In een analoog signaal is geen ruimte voor de extra informatie die nodig is voor error correctie. Bij een digitaal signaal kun je naar hartelust zoveel error correctie toevoegen als dat je zelf nodig acht.

[koelpasta]

Wanneer het gaat om geluidsopnames gaat de kwaliteit relatief snel achteruit.

Hmm., maar audio moet het hebben van piepkleine veranderingen in amplitude. Als je bedenkt dat een 'ouderwetse' CD met 16 bits werkt en dat het laagste bitje een amplitude van 1/32767 heeft dan snap je mischien hoe gevoellig audio is en hoe makkelijk het op tape 'bederft'.

Digitaal is een stuk robuuster, daar hoef je met de amplitude enkel 2 stapjes te coderen, hoog of laag., Zelfs als dat een beetje bedorven is dan kun je meestal alsnog vrij goed achterhalen of het een 1 of een 0 moest voorstellen., En je hebt meestal ook nog iets van error correction.,

[LizardBloke]

Je snapt mijn vraag! Ik vroeg me vooral af of het lag aan de manier waarop data opgeslagen wordt of dat het lag aan het medium zelf.

[maxxer29]

Toch knap, veronderstel dus dat t/m V3 ze alles in machinetaal hebben geprogrammerd en zo C hebben ontwikkeld dan?

[downtime]

Klopt. Toen UNIX steeds populairder werd, en er vraag kwam naar UNIX-releases voor steeds meer verschillende hardware architecturen, begon het schrijven in machinetaal voor al die verschillende platformen toch wel echt een probleem te worden. Machinetaal is complex en foutgevoelig.

C is ontwikkeld zodat ze een groot deel van de architectuur-specifieke machinetaal konden vervangen door code die op alle architecturen kon draaien als ze daar eenmaal een C compiler aan de praat kregen.

[MontyMole]

Machinetaal is complex en foutgevoelig.

Hij hebt duidelijk geen ervaring met programmeren in assembly.

Assembly is op zich helemaal niet complex, je moet alleen echt alles zelf doen, en dat maakt het bij grotere projecten tijdrovender.

[flossed]

Mijn eerste macinetaal opdracht was in hexcode niet eens assembler. Heb je ervaring met hexcode?

[downtime]

Een beetje. Ik had indertijd niet de beschikking over een assembler maar ik had wel goede documentatie van de CPU. Dus ik heb mijn eerste (en waarschijnlijk enige, maar het is al heel wat jaren geleden, en mijn geheugen laat me in de steek) machinetaal routines in hexcodes geschreven. Dat was waarschijnlijk op de Z80.

[flossed]

Leuk nerdspul totaal onmogelijk, maar gelukkig zijn we geevolueerd. Fijne feestdagen. Zodirect met ai verder. Dat kan net zo goed direct in binary gaan.

[MontyMole]

Je beseft toch dat dit "nerdspul" nog steeds noodzakelijk is om een compiler te schrijven voor een of andere architectuur?

[flossed]

Laat ik aan jouw over, ik heb het 40 jaar terug al gedaan, wat mij betreft nooit meer. Tegenwoordig kom je met transpilers en transcoders al een stuk verder, tenzij je echt binary wilt vertalen naar hexcode zou ik je aanraden om dat te doen

[MontyMole]

Volgens jou is uiteindelijk machinecode niet meer noodzakelijk?

[flossed]

Dat zeg ik niet, wat ik zeg is dat de mens niet meer machinecode hoeft te kennen, omdat je beter de tijd kan besteden om uit te denken wat je eigenlijk wil maken, dan uit te zoeken welke bit je nu weer niet goed heb gezet. Kunstmatige Intelligentie met de huidige capaciteiten als chatgpt, claude, openAI , zou bijna onmogelijk zijn als we nog steeds in binary moesten programmeren. Aan het einde van de rit, zorgen compilers ed voor machinecode, ander snap je CPU niet wat iet moet doen. Jij hoef dat niet te snappen.

Net als in de wiskunde onstaat er steeds weer een abstractie laag om nog complexere zaken aan te kunnen pakken. Ik zeg ook niet dat het onmogelijk is. als je je leven wil besteden om een neuraalnetwerk te programeren in assembly, viel spass. vandaag kan je al een basic neuraal netwerk, met de huidige stand van zaken in 1 dag van de grond krijgen.

[MontyMole]

Zeer zeker. Is ook wel nodig als je een uitgebreide eigen low-level disassembler schrijft voor debugging van eigen projecten.

[beerse]

Die hex-code was ongetwijfeld een representatie van assembly code. Als jij in hexcode werkt, dan ben jij in feite de assembler in plaats van het programma dat assembly code in machine code om zet.

Met de comodore64 werd vele met peek en poke gedaan. Ook dat is in veel gevallen een variant op hexcode en/of assembler.

Uiteindelijk is machine code (hex of assembly of wat dan ook) net zo moeilijk als de cpu zelf. Een risc cpu is daarbij duidelijk eenvoudiger dan een cisc cpu: Redused (beperkt) of Complex is daarbij duidelijk.

[flossed]

Hex en binary zitten heel dicht bij de microcode van de cpu zelf. Assembly is een abstactie laag daarboven. Met mnemnonics wordt de code leesbaar. Mov pop push mul zegt meer dan 0xa5 of 01110101.

[beerse]

Zeker weten: HexCode, Binary en Assembly zijn 1 op 1 met elkaar om te zetten. Het is vooral een andere representatie van de zelfde code. Het omzetten daar tussen heet dan ook assembleren, niet compileren.

Ooit, tijdens een opleiding electrotechniek in de jaren '80 van de vorige eeuw, heb ik met logica (and, or, xor en dergelijke) een 4-bits cpu gemaakt die kon optellen en vermenigvuldigen. Daar was de invoer van instructie en data in 4-bits. Uiteindelijk was er een 'assembler' code met 4-bits representaties en alles.

[Cyberpuppy]

Het probleem zit hem niet eens zozeer in de complexiteit. Maar je programmeert letterijk op hardwareniveau. Dus je programma moet dus ook letterlijk voor iedere processor opnieuw aangepast worden. Is geen doen als je je programma op meer dan 1 systeem wilt kunnen draaien.

[MontyMole]

Dat maakt assembly niet plots "complex".

[Cyberpuppy]

In de tijd van de Z80 was het nog wel te doen. In de tijd van de huidige processoren en bijv. een dedicated videokaart wil ik je wel eens "Hello World" op het scherm zien toveren.

[MontyMole]

Dat is nog steeds even simpel als 30 jaar geleden.

section .data
hello: db 'Hello world!',10;
helloLen: equ $-hello;

section .text
global _start

_start:
mov eax,4;
mov ebx,1;
mov ecx,hello;
mov edx,helloLen;
int 80h;
mov eax,1;
mov ebx,0;
int 80h;

[Cyberpuppy]

Een stuk simpeler zie ik. Die string kon je vroeger niet gebruiken op die manier.

Als ik me goed herinner is die int 80h de standaard VGA output.

[tisvonkje]

Toen Unix steeds populairder werd? v5 was de eerste versie die extern gebruikt werd. De switch naar C was daarvoor al ingezet.

[Lecenten]

Dat gebeurt met bootstrapping

V1, V2: de kernel was geschreven in assembly

V3: de kernel was geschreven in assembly, een C compiler (gedeeltelijk geschreven in C) was beschikbaar

V4 en verder: de kernel was geschreven in C

[Pjotr]

Als je meer over die historie wilt weten, kan ik je dit artikel aanraden:

The Development of the C Language - Dennis M. Ritchie

https://www.nokia.com/bell-labs/about/dennis-m-ritchie/chist.pdf

[Bor]

Een stukje geschiedenis komt weer beschikbaar. Dat kan ik alleen maar toejuichen
Tof ook dat de code direct beschikbaar is gemaakt.

[killercow]

Er was niets anders dan broncode, alle unix versies werden gewoon als source gedistribueerd, net als alle programma's. Het is pas veel later 'gewoon' geworden om gecompileerde binaries te slijten aan gebruikers.

[Hansie9999]

Cool,

We komen op een punt dat "IT" een tak van de afdeling "Archeologie" kan worden

[koelpasta]

Dat is het al hoor.
Kijk bijvoorbeeld eens naar het youtubekanaal van curious marc.

[Ricko1]

Mooi stukje historie, maar daar is verder weinig praktisch aan.

Volgens mij is er de laatste jaren miljoenen keren meer code verloren gegaan omdat oudere versies weinig gewaardeerd worden.

Persoonlijk voorbeeld: Ik kan mijn jails in TrueNAS Core al een paar jaar niet meer upgraden omdat de repositories de benodigde informatie verwijderd hebben. FreeBSD ziet de versie in TrueNAS Core als legacy.

Ik moet dus alles opnieuw gaan opbouwen onder het nieuwe TrueNAS Scale met dat app/vm systeem. Die hebben ook al drama gehad met plugins/vm oplossingen die niet meer ondersteund worden en je alles opnieuw moet opbouwen.

[DrPoncho]

Jouw voorbeeld staat wel ongeveer gelijk aan culturele en historische waarde als de eerste in C geschreven versie van Unix uit 1973 ja..

[Jack Flushell]

Heerlijk toch deze extreem kromme vergelijking (van degeen waarop jij reageert). Totale onwetendheid en toch reageren, nujij-style. Ik vind het wel genieten. Zag je een paar jaar geleden niet op Tweakers.

[Reactie gewijzigd door Jack Flushell op 24 december 2025 12:45]

[punishedbrains]

Het is geschiedenis, dat kan praktisch zijn in de zin van uitvogelen waar Unix en verdere systemen vandaan zijn gekomen. Maar ook gewoon vanwege de emotionele waarde, het was een mijlpaal in de IT geschiedenis, dus geweldig om zoiets nog van een oude tape te kunnen plukken, heeft nog iets spannends ook.

Wat betreft je NAS, had deze niet iets meer up-to-date gehouden kunnen worden?

[Ricko1]

Wat betreft je NAS, had deze niet iets meer up-to-date gehouden kunnen worden?

Dat is juist het probleem. Ik hield die netjes up-to-date maar iemand had besloten dat dit niet meer mogelijk is. De boel moet nu volledig offline om te upgraden en alles opnieuw opbouwen met VM's onder Linux ipv FreeBSD. Dat is een eenrichting upgrade waarna het moeilijk is om nog data uit de oude services te halen. Daar zie ik behoorlijk tegenop. Van TrueNAS Scale weet ik niet of ze weer hun app platform of hypervisor overhoop gaan gooien.

[bzzzt]

Volgens mij is er de laatste jaren miljoenen keren meer code verloren gegaan omdat oudere versies weinig gewaardeerd worden.

Binaire code misschien, maar de broncode van de meeste open source code staat onder versiebeheer dus is het prima mogelijk die te reconstrueren.
Je kan van een kilobyte broncode zonder al teveel geks te doen tientallen megabytes aan binaries genereren (compileren inclusief library code, packagen of erger: packagen in een docker container met een half OS er in). Alle minor versies die ooit gereleased zijn bewaren is dan ook eigenlijk niet te doen.

[The Ghost]

Juist een geweldige stap dat dit hersteld is, soms is 1 stap terug 2 stappen voorwaarts.

Hiermee komt een stuk originele code beschikbaar wat zeker kan leiden tot andere inzichten en betere beveiliging in de toekomst

[T-men]

"niet meer ondersteund" is wat anders dan "verdwenen code". De betreffende Unix versie op de tape was geheel kwijt.
Het grappige is dat er wel nieuwere versies waren. Unix werd dus juist wél verder ontwikkeld (= "ondersteund")

[GertMenkel]

Voor die jails kun je toch je eigen repo opzetten? Het is wat meer werk om al die pakketten te compileren maar ik heb weinig gehoord over projecten die volledig verdwenen zijn.

Dat je de boel opnieuw moet opbouwen is inderdaad stom, maar ik vind het weinig lijken op verdwenen code. Verdwenen ondersteuning en een gebrek aan upgradepad wellicht.

[DefaultError]

Een mooi kerstverhaal. Mensen die worden herenigd, huisdieren die terug worden gevonden onder een motorkap ver van huis. En een oude Unix versie van 52 jaar oud is hersteld. Voor diegene die terug in de tijd wil kan er nu ook mee aan de slag middels Simh.

Fijne kerstdagen.

[avlt]

Wow, ik kan me nog herinneren dat we dergelijke tapes binnenkregen in Delft en op onze PDP-11's installeerden. En dan met Lion's commentary regel voor regel de sourcecode doornamen.

[Autisme_tech]

Rond die tijd had ik nog nooit van Unix gehoord, mijn eerste OS was MS-Dos 1.1 en PC-DOS een variant daarop. Toch knap dat ze het hebben weten te herstellen en draaiend kunnen krijgen

[sapphire]

Ik heb niks en kan niks met Unix maar gewoon het feit dat zoiets gevonden, gerestaureerd, beschikbaar gesteld word en dus behouden blijft voor de toekomst vind ik dan wel heel erg gaaf

Toch een stukje geschiedenis wat bewaard blijft

edit:
ik bedoel ik heb niks met Unix qua gevoel, nostalgie of zoiets. Ik heb vast wel iets of ene afgeleide ervan ergens maar ik bedoelde het gevoeld aspect.

[Reactie gewijzigd door sapphire op 24 december 2025 12:22]

[kabelmannetje]

Je hebt niks met Unix? Bijzonder, deze techniek is immers overal te vinden. Je hebt diverse apparaten in huis waar een doorontwikkeling ervan op te vinden is.

[_Pussycat_]

Nou ja, ik gebruikt elke dag Windows maar heb er ook niks mee...

[kabelmannetje]

Je hebt er niks mee? Bijzonder, je gebruikt het toch?

[_Pussycat_]

Ja, maar geweldig vind ik het niet. Sommige dingen als mijn insta360 of Gamin vind ik werkelijk goede producten. Windows, vooral sinds 11, vind ik vooral steeds slechter worder. Ik ben alleen te lui en te vaak teleurgesteld door Linux om over te stappen.

[kabelmannetje]

Garmin en Insta360 draaien echt op Linux. Zie je nu wel dat je er wat mee hebt.

[_Pussycat_]

Garmin iig niet... maar al zouden ze op Linux draaien, het is maar een onderdeel als de batterij, de touchscreen en de knoppen. Ik heb ook niks met schroeven, ook al zitten die erin.

[kabelmannetje]

Graag hoor ik van jou bewijs dat Garmin niet op Linux draait. Mijn Montana 750i en Edge draaien er sowieso op.

Hoe kan dat ze Linux draaien maar er volgens jou niet op draaien?

Je hebt wel wat met schroeven, beetje lastig immers als alles wat je aanraakt meteen inelkaar dondert.

[_Pussycat_]

Schijnbaar hebben we een ander brgrip van "ergens iets mee hebben". Voor mij is dat "Ik heb er een band mee, het betekent iets voor me, ik kan er enthousiast voor zijn". (of zoals amerikanen zouden zeggen "i love it"). Voor mij betekent Linux en schroeven niets bijzonders.

Voor jou schijnt "ergens iets mee hebben" te betekenen "Ik heb er contact mee of gebruik het". Uiteraard heb ik en heeft iedereen contact met Linux en schroeven.

Ik kon geen woordenboek-definitie vinden, maar Gemini definieert hem hetzelfde als ik:

geef definitie of voorbeelden van "er iets mee hebben", in de zin "ik heb iets met linux"

Definitie

"Er iets mee hebben" betekent een affiniteit, interesse, sympathie of persoonlijke voorkeur voelen voor een specifiek onderwerp, object of persoon. Het impliceert een positieve connectie of een intellectuele klik.

Voorbeelden

• Ik heb iets met Linux: De spreker heeft een sterke voorkeur voor of diepgaande interesse in het besturingssysteem Linux.
• Zij heeft iets met klassieke auto's: Zij vindt dit type voertuigen fascinerend en heeft er waarschijnlijk een passie voor.
• Hij heeft niets met moderne kunst: Hij voelt geen enkele connectie of waardering voor dit specifieke genre.
• Ik heb wel iets met die nieuwe collega: De spreker voelt een vorm van sympathie of aantrekkingskracht.
• Wij hebben iets met Scandinavisch design: Er is een uitgesproken voorkeur voor de esthetiek uit die regio.

Hoe kan dat ze Linux draaien maar er volgens jou niet op draaien?

Niet echt belangrijk, maar: https://conference.hitb.org/hitbsecconf2023ams/session/compromising-garmins-sport-watches-a-deep-dive-into-garminos-and-its-monkeyc-virtual-machine/
GarminOS, wat op de horloges draait, is niet Linux.

[kabelmannetje]

Kortom, je hebt wel degelijk wat met Linux. Het zit in diverse apparaten die je dagelijks gebruikt.

[_Pussycat_]

Je het de definieite niet echt gelezen he....

Is okee jong. Je hebt helemaal gelijk. Ik het iets met linux, schroeven, lijm, zuurstof, benzine, en rubber, want die gebruik ik allemaal elke dag.

[kabelmannetje]

Klopt, al die zaken die je opnoemt, spelen toch écht een belangrijke rol in jouw leven.

[killercow]

Je gebruikt ongetwijfeld je hele leven al unix-achtigen of zelfs vrij direct broncode uit unix-en.

[wiseger]

En het grappige is, je maakt continue gebruik van producten en diensten die allemaal draaien op van een afgeleide van het originele Unix.

[sapphire]

Want dat bepaald of ik nostalgische gevoelens voor een OS moet hebben

[Reactie gewijzigd door sapphire op 24 december 2025 14:47]

[Fermion]

Ben benieuwd hoeveel van de originele code nog is terug te vinden.

[Jack Flushell]

Heb je gelezen waar het artikel over gaat en vooral wat er staat?

[mcmd]

Wellicht wordt bedoeld wat je van de orignele code terug kunt vinden in de huidige code?

[Jack Flushell]

Dat zou een hele goede vraag zijn inderdaad. Dan is het wel erg onhandig opgeschreven, als dat wordt bedoeld.

[xzaz]

Dit is de broncode of de compiled version? De vraag is toch terecht; hoeveel van de orginele code er nog terug te vinden is is best interessant?

[Jack Flushell]

Ja dat staat er niet duidelijk, ik woon niet in zijn/haar hoofd. Maar als dat wordt bedoeld: klopt, heel interessant.

[koelpasta]

Ze zeggen dat je het kunt runnen in een emulator, dus ik vermoed dat het een binary is. Maar mischien zitten de sources en compiler er ook bij.

[_Pussycat_]

Alles. Onder de downloadlink.

Of wat bedoel je?