Stor nytta med historisk Unix version 6 från 1975

[abcabc]

Jag har mixtrat en del med en historisk Unix version 6 från 1975. Vad är det för nytta med kan man tänka sig, men det är det:

1) Den är väldigt lite kod radmässigt. All kod i kärnan får plats på 90 A4-sidor.
2) Den finns väl dokumenterad i J. Lions bok "A COMMENTARY ON THE SIXTH EDITION UNIX OPERATING SYSTEM" och medföljande "UNIX OPERATING SYSTEM SOURCE CODE LEVEL SIX", fritt nedladdbar.
3) Källkoden finns lätt nedladdbar och är enkel att starta och köra i den fria SIMH-emulatorn.
4) Koden till största del skriven av Kernighan & Richie är vacker och njutbar att läsa, samma vackra stil som i C-boken K&R.
5) Det är enkelt att kompilera om hela kärnan och alla andra verktyg och kompilatorer.

Man kan ganska enkelt plöja igenom all kod på några dagar, jag har provar att skriva nya systemanrop och skriva nya devicedrivers, det tar bara någon timme.

Någon annan som har provat version 6, eller någon annan version av de historiska Unixarna version 1-7 eller gamla BSD:ar?

[Lennart Aspenryd]

Väldigt intressant!
Var spårade det hela ur då?
När IBM gav uppdraget till William Gates att skapa DOS, som han köpte från en kanadensare!

Har du läst "En dators födelse"? Det är ju klart!

Historien är viktig, den förklarar vart vi befinner oss idag!

[abcabc]

Jag har också en känsla av att Unix spårade ur tidigt. Redan version 7 var det ca 70% mer rader. Det som K&R tyckte var viktigt har helt förlorats. I senare BSD-versioner implementerades ip helt i kärnan och monolitiskt och som jag ser det utan skönhet och stil.

[abcabc]

Jag har lästa "En dators födelse".

Alla ingenjörer borde läsa den, den boken kan ge en verklig inspirationskraft varför man gör det man gör, de ingenjörer som känner sig lite trötta och oinspirerade bör absolut läsa boken, den ger kraft och inspiration.

Dock med risken att man säger upp sig och söker till ett företag på frontlinjen, vad det nu kan var i Sverige. Ericsson? ABB? Google? Spel och musikföretag?

[MiaM]

Lasp:
Den DOS som Microsoft köpte var väl ändå från Seattle, om än hyggligt nära gränsen till Kanada?

Men hur som helst är det ju en annan utveckling. Det OS'et var ju en klon av CP/M.

Visserligen fanns det väl Xenix för 8088 men det måste varit en rätt plågsam upplevelse att köra.

Rätt intressant är att det var Microsoft som köpte licens för Unix och kallade den Xenix och på 80-talet stod för överlägset flest faktiskt körande Unixburkar... (Denna del gled ju mer och mer över till SCO, och hur det blev med dem vet väl alla...).

Att IBM tyckte att OS/2 var en bra idé var väl kanske felet - hade de sagt Unix då det begav sig så hade nog Microsoft varit störst på Unix...

Men på ett sätt så var det väl också bra att det "gick snett". Förutom GUI-API-arvet från 16-bitars Windows så är ju moderna Windows (d.v.s. allt från NT 3.x och nyare) bättre API-mässigt än Unix.

abcabc:
Törs du ge dig på att porta denna gammel-unix till annan hårdvara?

[lillahuset]

Om jag minns rätt hette "OSet" QDOS för "Quick and Dirty OS" som skrevs av ett företag som tillverkade S-100 kort med 8086 som tröttnade på att Digital Research aldrig fick fram sin CP/M-86.
http://en.wikipedia.org/wiki/86-DOS

Fantastisk bok! Rekommenderas!

[pbgp]

Kul läsning och kul projekt!!

Ska nog titta på den där koden vad det lider, jag har ju 11:or att köra den på. Kan nog tyvärr inte bidra till att porta något, men det kan väl inte vara övermäktigt. Det kanske redan är gjort?

[jpalsson]

Gillar kommentarerna

Ovanför "newproc()"

* Create a new process-- the internal version of
1864 rpp->p_ttyp = rip->p_ttyp;
1815 * sys fork. 1865 rpp->p_nice = rip->p_nice;
1816 * It returns 1 in the new process. 1866 rpp->p_textp = rip->p_textp;
1817 * How this happens is rather hard to understand.

[abcabc]

En annan klassisk kommentar är "You are not expected to understand this" i filen slp.c (rad 2030 i Lions bok):

Kod: Markera allt

/*
 * If the new process paused because it was
 * swapped out, set the stack level to the last call
 * to savu(u_ssav). This means that the return
 * which is executed immediately after the call to aretu
 * actually returns from the last routine which did
 * the savu.
 *
 * You are not expected to understand this.
 */
if(rp->p_flag&SSWAP) {
        rp->p_flag =& ~SSWAP;
        aretu(u.u_ssav);
}

Med detta låter det som det är svårt att förstå, men det är tvärtom, koden i v6 tror jag är en av grunderna till tanken att bra skriven kod är självdokumenterande, och den är verkligen lätt att förstå. Just detta avsnitt är lite knepigt, och jag har inte brytt mig i att förstå. Någon som har analyserat just detta?

[MiaM]

Utan att ha tittat mer på koden och utan att ha koll på arkitekturen det körs på så lär det väl vara så att återhoppet från inswappningen görs som ett subrutinsåterhopp trots att processens egentliga kod aldrig gjort något subrutinanrop.

Det är väl gissningsvis bara en typisk standardmetod för att hämta tillbaka allt från stacken på den arkitekturen eller nåt. Ja, eller kanske mer troligt så är det det sätt som det över huvud taget går att göra i C.

Jag har blandade känslor inför konceptet att skriva icke-portabel C-kod som ersättare för assemblerkod. För att förstå koden behöver man ändå ha koll på assembler på arkitekturen i fråga. Fördelen är väl egentligen mest att slippa separatlänka en massa småsnuttar och/eller slippa ha stöd för inlineassembler i c-kompilatorn.

[abcabc]

Det är så klart inte optimalt med cpu-beroende c-kod, men dels så var C ett lite annat språk då, det var innan K&R, och det gjorde det lite svårare att skriva porterbar kod.

Även om v6 portades till andra arkitekturer så anses nog v7 vara den version som var riktigt porterbar.

Om man kollar i koden så var C lite mer av assembler över sig, t.ex. var elementen i en struct bara offset som man kunde utnyttja lite hur man ville, på vilken pekare man så önskade.

Detta att skriva icke porterbar kod istället för assembler: för den Arduino Due som jag trixar med så går det att skriva bootbar kod helt utan assembler, dock så måste man skriva pragma med section för kompilering för att få det att fungera, frågan är om det är bättre då än assembler? Jag har provat både assemblerversion och c-version, båda fungerar.

Det är nog bättre i de flesta fall att skriva assembler istället för cpu-beroende och / eller obegriplig c-kod. Då signalerar man att detta behöver modifiering för en annan arkitektur, och dessutom faktiskt oftast enklare att förstå assembler än C-kod.

[lillahuset]

Petitess: K&R

[TomasL]

Visserligen fanns det väl Xenix för 8088 men det måste varit en rätt plågsam upplevelse att köra.

Har aldrig kört XENIX på 8088, dock körde jag det dagligen på 8 MHz 286, fram till typ 95 eller så. Köpte systemet 83/84 eller nått sånt.
Och det funkade väldigt bra.

[abcabc]

Jag har tidigare träffat på en unixvariant som heter Cromix från Cromemco. Någon annan som har erfarenhet av detta?

[olalofberg]

abcabc: Skönt med överblickbar och snygg kod. (K&R rulez!)

Jag har ändå varit den som TRYCKER in koden snabbt medan jag har den i huvudet...
Jag antar att en Civilingenjörsex. med inriktning på programvaruutv. förändrar en del.

(Kan dock fortfarande ana min forna kodare allt som oftast. Det ska bara FUNKA! -Så fort som möjligt! ; (ingenjörs-fenomen) )