Microsoft släpper källkoden till MS‑DOS 4.00

Permalänk
Melding Plague

Microsoft släpper källkoden till MS‑DOS 4.00

Företaget har lagt upp hela källkoden till version 1.25, 2.0 och nu även 4.00 av sitt ursprungliga operativsystem på Github.

Läs hela artikeln här

Visa signatur

Observera att samma trivselregler gäller i kommentarstrådarna som i övriga forumet och att brott mot dessa kan leda till avstängning. Kontakta redaktionen om du vill uppmärksamma fel i artikeln eller framföra andra synpunkter.

Permalänk
Medlem

Win 3.11 kommer inom kort, alltså om 15 - 30 år.

Permalänk
Medlem

kod skriven för 386 känns ju inte superkul att titta på, eftersom det går att dra noll lärdomar. inte ens samma mnemonics idag.

Visa signatur

Asus B550E-Gaming / Ryzen 5900X stock / Corsair Vengeance 32GB 3600 MHz CL18 /
ASUS TUF 4080 Gaming OC / Samsung 980 PRO 2TB PCI-Ev4 + 2TB WD Black NVME PCI-Ev3 / Corsair RM850x v2 / Acer Predator XB273UGX 1440p 270 Hz G-Sync / Phantek P500A / Arctic Cooling LF II 240mm / Evo 4 / Sennheiser IE 300 / Rode NT1-A
Synology 1621+ 6*16 / 1513+ 5*8 / LG CX 65" / XBox Series X
Ownit är inte längre bra, alls. Undvik.

Permalänk
Medlem

Undrar hur de landade i att de skulle släppa upp till v4.00 och inte 6.22?

Visa signatur

Amd o Ps5pro o Apple

Permalänk
Medlem
Skrivet av Mindfighter:

Undrar hur de landade i att de skulle släppa upp till v4.00 och inte 6.22?

Att 4.00 är äldre än 6.22, antar jag.

Visa signatur

Desktop: Ryzen 5800X3D || MSI X570S Edge Max Wifi || Sapphire Pulse RX 7900 XTX || Gskill Trident Z 3600 64GB || Kingston KC3000 2TB || Samsung 970 EVO Plus 2TB || Samsung 960 Pro 1TB || Fractal Torrent || Asus PG42UQ 4K OLED
Proxmox server: Ryzen 5900X || Asrock Rack X570D4I-2T || Kingston 64GB ECC || WD Red SN700 1TB || Blandning av WD Red / Seagate Ironwolf för lagring || Fractal Node 304

Permalänk
Medlem
Skrivet av KroesusSork:

kod skriven för 386 känns ju inte superkul att titta på, eftersom det går att dra noll lärdomar. inte ens samma mnemonics idag.

Instruktionsuppsättningen för 386 tillsammans med deras kod är ju extremt givande. Finns hur många lärdomar som helst att få. Maskinnära kod kommer alltid behövas.

Visa signatur

Processor: Motorola 68000 | Klockfrekvens: 7,09 Mhz (PAL) | Minne: 256 kB ROM / 512 kB RAM | Bussbredd: 24 bit | Joystick: Tac2 | Operativsystem: Amiga OS 1.3

Permalänk
Medlem
Skrivet av evil penguin:

Att 4.00 är äldre än 6.22, antar jag.

Absolut, men inte så att någon konkurrent får några fördelar av att se ms-dos 6.22 koden direkt...

Visa signatur

Amd o Ps5pro o Apple

Permalänk

Jag hittade en bugg i källkoden för dos 4.0. Jag kommer genast kontakta Microsoft så de slänger ut en akut patch för denna.

Permalänk
Hedersmedlem

Det här känns mest som en kul grej för den som är intresserad av mjukvaruarkeologi och historia. (Inget fel med det så klart!)

Den som vill ha ett mer användbart open source:at DOS-kompatibelt operativsystem gör dock gott i att kolla på FreeDOS.

Permalänk
Datavetare
Skrivet av talonmas:

Instruktionsuppsättningen för 386 tillsammans med deras kod är ju extremt givande. Finns hur många lärdomar som helst att få. Maskinnära kod kommer alltid behövas.

Maskinnära kod kommer alltid behövs, men mängden assembler som behövs (eller ens är önskvärd) i ett modernt OS är försvinnande liten.

Finns överhuvudtaget inget anledning alls att ett kommando som MORE ska ha en enda rad assembler, i DOS var detta tydligen helt skrivet i assembler.

Den stora lärdomen man kan dra av detta är: detta är ett väldigt bra exempel på varför det historiskt var sådan brutal barriär att byta CPU-arkitektur för ett OS. Även de saker som är skriva i C, t.ex. ATTRIB gör ju direkta referens till CPU-register (vilket man kan göra i C, men ytterst sällan en vettig idé utanför mycket specifika fall).

Det som hänt sedan 80-talet fram till nu är att dels har CPUs mikroarkitektur blivit långt mer komplicerade, ihop med att kompilatorer blivit långt bättre. Även de som fortfarande kan assembler kommer i väldigt få fall kunna skriva kod som presterar bättre än vad en kompilator spottar ur sig på bråkdelen av tiden. Framförallt inte om man vill ha lite bredare stöd över många CPU-modeller.

Idag är inte ens assembler vettigt för det som länge var den sista utposten där det krävdes: SIMD. Problemet med SIMD är att man trodde / hoppas att även det skulle gå att knäcka med "smarta kompilatorer", men efter många mer eller mindre fruktlösa försök har man kommit till insikt att de traditionella programspråken (C, C++, Java, C# etc) inte har den fundamentala design som krävs.

Nvidia knäckte den nöten först med CUDA och GPUer, andra har nu följt efter med liknande tekniker för CPU. Exempel är Intels ISPC kompilator (likt CUDA är det i praktiken ett språk som påminner om C, men med semantik som fungerar för SIMD) och Khronos SyCL (utökning av C++ samt tillhörande hjälpbibliotek, fungerar på allt från CPU, GPU till FPGA).

Allt detta gör assembler till rätt meningslöst utanför extremt specifika fall. Är nära nog hopplöst för en människa att för hand skapa bättre resultat än CUDA, ISPC och SyCL kan göra på en fraktion av tiden.

Till och med det flera av oss drog lite på smilbanden på 90-talet har ju hänt (det lät lite för bra för att kännas realistiskt), även om det fortfarande är mer undantag än regel: JIT-kompilerad kod (från t.e.x Java) kan idag ibland bli snabbare än motsvarande skrivet i C eller C++ och kompilerat direkt till maskinkod. Detta då de mest avancerade runtimes idag "lär sig" hur koden körs och JIT:ar om den under körning för att få en mer optimal maskinkod för den specifika data man råkar använda!

Ändå kul att kunna kika på DOS, det ger rejält med perspektiv på vilken enorm utveckling det varit sedan den tiden!

Visa signatur

Care About Your Craft: Why spend your life developing software unless you care about doing it well? - The Pragmatic Programmer

Permalänk
Medlem
Skrivet av Mindfighter:

Absolut, men inte så att någon konkurrent får några fördelar av att se ms-dos 6.22 koden direkt...

Fann även https://www.theregister.com/2024/04/26/ms_dos_4_open_source/ som har något mer matnyttig rapportering om bakgrunden till vad som släppts och vad som kommer härnäst.

Visa signatur

Desktop: Ryzen 5800X3D || MSI X570S Edge Max Wifi || Sapphire Pulse RX 7900 XTX || Gskill Trident Z 3600 64GB || Kingston KC3000 2TB || Samsung 970 EVO Plus 2TB || Samsung 960 Pro 1TB || Fractal Torrent || Asus PG42UQ 4K OLED
Proxmox server: Ryzen 5900X || Asrock Rack X570D4I-2T || Kingston 64GB ECC || WD Red SN700 1TB || Blandning av WD Red / Seagate Ironwolf för lagring || Fractal Node 304

Permalänk
Medlem

Kul att de släpper något fritt...

Men tror de flesta retro entusiaster föredrar något nyare än DOS 4.0 och jag har svårt att se något kommersiellt intresse/nytta med DOS 4.0

Min första PC hade DOS 6.22 och Windows 3.11
Tror det äldsta DOS jag sett är 5.0

Tror inte källkod till DOS 6.22 hade gett alla konkurrenter insikt om hur Windows 11 fungerar och plötsligt hade Microsoft blivit utkonkurrerade inom ett par år om de släppt DOS 6.22 fritt...

Tidiga Windows versioner som 1.x, 2.x och 3.x borde de väl kunna släppa fritt också ?
Svårt att se hur det skulle användas till något annat än retro och/eller historiska skäl.

2028 borde de väl kunna släppa Windows 95 och Windows 98 fritt också.
Svårt att se hur 30+ år gamla operativsystem skulle vara en konkurrent till deras nyare system.
Speciellt eftersom Windows 95/98/ME var dos baserade och de nyare Windows systemen inte är det. Svårt att se hur de systemen skulle konkurrera mot Windows 10 och Windows 11 även om de släpptes fria.

Permalänk

Kul att testa på lite DOS igen..minns när man satte upp Novell nätverk med DOS.

Permalänk
Medlem
Skrivet av GuessWho:

Tidiga Windows versioner som 1.x, 2.x och 3.x borde de väl kunna släppa fritt också ?
Svårt att se hur det skulle användas till något annat än retro och/eller historiska skäl.

MS-DOS 1.25 och 2.0 finns redan på samma Github-repo. 3.3, 5 och 6 ska tydligen vara på väg också, men det tar troligtvis tid eftersom det kan vara komplicerat att släppa proprietär kod fri med tanke på licenser och dylikt.

Permalänk
Medlem
Skrivet av perost:

MS-DOS 1.25 och 2.0 finns redan på samma Github-repo. 3.3, 5 och 6 ska tydligen vara på väg också, men det tar troligtvis tid eftersom det kan vara komplicerat att släppa proprietär kod fri med tanke på licenser och dylikt.

Före Windows 95 så var DOS och Windows separerade.
Så man kunde ha DOS utan att ha Windows.
Däremot så kunde man inte ha Windows utan att ha DOS.

Eller ja, någon form av DOS kompatibel miljö åtminstone.
Jag körde OS/2 ett tag och kunde köra Windows 3.11 ovanpå OS/2.

I just det stycket du citerade så skrev jag tidiga Windows versioner.
Men så vitt jag förstår det så är inte Windows inkluderat i dessa släpp?

Att det bara är DOS.
Eller har jag missförstått något ?

Permalänk
Medlem
Skrivet av GuessWho:

Före Windows 95 så var DOS och Windows separerade.
Så man kunde ha DOS utan att ha Windows.
Däremot så kunde man inte ha Windows utan att ha DOS.

Eller ja, någon form av DOS kompatibel miljö åtminstone.
Jag körde OS/2 ett tag och kunde köra Windows 3.11 ovanpå OS/2.

I just det stycket du citerade så skrev jag tidiga Windows versioner.
Men så vitt jag förstår det så är inte Windows inkluderat i dessa släpp?

https://upload.wikimedia.org/wikipedia/en/4/4e/Windows1.0.png

Att det bara är DOS.
Eller har jag missförstått något ?

Nej, det stämmer bra att det är olika saker.

Visa signatur

Desktop: Ryzen 5800X3D || MSI X570S Edge Max Wifi || Sapphire Pulse RX 7900 XTX || Gskill Trident Z 3600 64GB || Kingston KC3000 2TB || Samsung 970 EVO Plus 2TB || Samsung 960 Pro 1TB || Fractal Torrent || Asus PG42UQ 4K OLED
Proxmox server: Ryzen 5900X || Asrock Rack X570D4I-2T || Kingston 64GB ECC || WD Red SN700 1TB || Blandning av WD Red / Seagate Ironwolf för lagring || Fractal Node 304

Permalänk
Medlem
Skrivet av Yoshman:

Maskinnära kod kommer alltid behövs, men mängden assembler som behövs (eller ens är önskvärd) i ett modernt OS är försvinnande liten.

Finns överhuvudtaget inget anledning alls att ett kommando som MORE ska ha en enda rad assembler, i DOS var detta tydligen helt skrivet i assembler.

Den stora lärdomen man kan dra av detta är: detta är ett väldigt bra exempel på varför det historiskt var sådan brutal barriär att byta CPU-arkitektur för ett OS. Även de saker som är skriva i C, t.ex. ATTRIB gör ju direkta referens till CPU-register (vilket man kan göra i C, men ytterst sällan en vettig idé utanför mycket specifika fall).

Det som hänt sedan 80-talet fram till nu är att dels har CPUs mikroarkitektur blivit långt mer komplicerade, ihop med att kompilatorer blivit långt bättre. Även de som fortfarande kan assembler kommer i väldigt få fall kunna skriva kod som presterar bättre än vad en kompilator spottar ur sig på bråkdelen av tiden. Framförallt inte om man vill ha lite bredare stöd över många CPU-modeller.

Idag är inte ens assembler vettigt för det som länge var den sista utposten där det krävdes: SIMD. Problemet med SIMD är att man trodde / hoppas att även det skulle gå att knäcka med "smarta kompilatorer", men efter många mer eller mindre fruktlösa försök har man kommit till insikt att de traditionella programspråken (C, C++, Java, C# etc) inte har den fundamentala design som krävs.

Nvidia knäckte den nöten först med CUDA och GPUer, andra har nu följt efter med liknande tekniker för CPU. Exempel är Intels ISPC kompilator (likt CUDA är det i praktiken ett språk som påminner om C, men med semantik som fungerar för SIMD) och Khronos SyCL (utökning av C++ samt tillhörande hjälpbibliotek, fungerar på allt från CPU, GPU till FPGA).

Allt detta gör assembler till rätt meningslöst utanför extremt specifika fall. Är nära nog hopplöst för en människa att för hand skapa bättre resultat än CUDA, ISPC och SyCL kan göra på en fraktion av tiden.

Till och med det flera av oss drog lite på smilbanden på 90-talet har ju hänt (det lät lite för bra för att kännas realistiskt), även om det fortfarande är mer undantag än regel: JIT-kompilerad kod (från t.e.x Java) kan idag ibland bli snabbare än motsvarande skrivet i C eller C++ och kompilerat direkt till maskinkod. Detta då de mest avancerade runtimes idag "lär sig" hur koden körs och JIT:ar om den under körning för att få en mer optimal maskinkod för den specifika data man råkar använda!

Ändå kul att kunna kika på DOS, det ger rejält med perspektiv på vilken enorm utveckling det varit sedan den tiden!

Nu skrivs ju oftast inte maskinnära kod på en modern cpu iof utan på nåt som skapades för 30 år sedan och kostar 5 kr per chip. Jag syftar alltså på inbyggda system, inte mjukvara till gemene man.
Det finns alltid saker att lära av andras arbete. Alltid.

Visa signatur

Processor: Motorola 68000 | Klockfrekvens: 7,09 Mhz (PAL) | Minne: 256 kB ROM / 512 kB RAM | Bussbredd: 24 bit | Joystick: Tac2 | Operativsystem: Amiga OS 1.3

Permalänk
Datavetare
Skrivet av talonmas:

Nu skrivs ju oftast inte maskinnära kod på en modern cpu iof utan på nåt som skapades för 30 år sedan och kostar 5 kr per chip. Jag syftar alltså på inbyggda system, inte mjukvara till gemene man.
Det finns alltid saker att lära av andras arbete. Alltid.

Angående det sista: det finns absolut saker att lära, vad det gäller CPU-design från 70-talet handlar det idag dock mest om exempel på hur man inte bör göra. Frågan är hur värdefullt det är givet att det finns oändligt med sätt att göra saker på dåliga sätt, är bara de bra idéerna som är värda något.

Inbyggda-system är extremt brett. Jobbade själv med detta under ca 20 år, mängden assembler jag skrev var absolut minimal (men var relativt kapabla system, de som under de åren nästan helt gick över till Linux). Blev några rader x86, Arm, MIPS och PowerPC assembler, men skrev totalt sett mer Rust än assembler (och det blev inte speciellt mycket Rust, lite för tidigt men idag används det lite mer).

Gissar att du här refererar till mikrokontrollers, för går man upp lite i storlek domineras idag inbyggda system totalt av Linux där man rätt mycket programmerar med samma verktyg som vilket Linux-system som helst. Även realtids OS som VxWorks används primärt C och C++ (VxWorks är ett exempel där det går att köra C++ i kernel-kontext).

Finns säker någon fortfarande populär MCU där C, C++ eller Rust inte fungerar bra (och enda man bör lära sig då är "varför?"). Just här är ju typexemplet där man kan dra lärdom av tidigare arbete: många tidiga enkla CPUer, framförallt 8-bit, hade en horribel design om man ville skapa en bra C-kompilator.

Men kollar man "moderna" 8-bit CPUer, t.ex. Avr, programmeras de primärt i C även fast de kan ha så lite som 0,5 kB (512 bytes) med RAM. Edit: finns tydligen ned till 128 byte RAM, 512 byte RAM versionen är den minsta jag själv använt (och använde då C).

Senaste embedded-projekten jag jobbat med använder primärt C++ och C# och ett annat (som har väldigt mycket lågnivåkommunikation över flera olika fältbussar) använder främst Go samt lite NodeJS och en skvätt C. Det är språken "on-device", inte vad som används för moltjänsterna ovanför.

Visa signatur

Care About Your Craft: Why spend your life developing software unless you care about doing it well? - The Pragmatic Programmer

Permalänk
Medlem
Skrivet av Yoshman:

Angående det sista: det finns absolut saker att lära, vad det gäller CPU-design från 70-talet handlar det idag dock mest om exempel på hur man inte bör göra. Frågan är hur värdefullt det är givet att det finns oändligt med sätt att göra saker på dåliga sätt, är bara de bra idéerna som är värda något.

Inbyggda-system är extremt brett. Jobbade själv med detta under ca 20 år, mängden assembler jag skrev var absolut minimal (men var relativt kapabla system, de som under de åren nästan helt gick över till Linux). Blev några rader x86, Arm, MIPS och PowerPC assembler, men skrev totalt sett mer Rust än assembler (och det blev inte speciellt mycket Rust, lite för tidigt men idag används det lite mer).

Gissar att du här refererar till mikrokontrollers, för går man upp lite i storlek domineras idag inbyggda system totalt av Linux där man rätt mycket programmerar med samma verktyg som vilket Linux-system som helst. Även realtids OS som VxWorks används primärt C och C++ (VxWorks är ett exempel där det går att köra C++ i kernel-kontext).

Finns säker någon fortfarande populär MCU där C, C++ eller Rust inte fungerar bra (och enda man bör lära sig då är "varför?"). Just här är ju typexemplet där man kan dra lärdom av tidigare arbete: många tidiga enkla CPUer, framförallt 8-bit, hade en horribel design om man ville skapa en bra C-kompilator.

Men kollar man "moderna" 8-bit CPUer, t.ex. Avr, programmeras de primärt i C även fast de kan ha så lite som 0,5 kB (512 bytes) med RAM. Edit: finns tydligen ned till 128 byte RAM, 512 byte RAM versionen är den minsta jag själv använt (och använde då C).

Senaste embedded-projekten jag jobbat med använder primärt C++ och C# och ett annat (som har väldigt mycket lågnivåkommunikation över flera olika fältbussar) använder främst Go samt lite NodeJS och en skvätt C. Det är språken "on-device", inte vad som används för moltjänsterna ovanför.

Min originalciteting var som svar på kommentaren "finns absolut noll att lära". Det triggade mig nåt enormt eftersom det är så fel. Och du har redan själv gett ett bra exempel på saker att lära, t.ex. hur man inte ska göra

Visa signatur

Processor: Motorola 68000 | Klockfrekvens: 7,09 Mhz (PAL) | Minne: 256 kB ROM / 512 kB RAM | Bussbredd: 24 bit | Joystick: Tac2 | Operativsystem: Amiga OS 1.3

Permalänk
Datavetare
Skrivet av talonmas:

Min originalciteting var som svar på kommentaren "finns absolut noll att lära". Det triggade mig nåt enormt eftersom det är så fel. Och du har redan själv gett ett bra exempel på saker att lära, t.ex. hur man inte ska göra

Alright, och det jag reagerade på vad att det skulle finnas mycket att lära. Det kanske finns något, men det är nog tyvärr väldigt begränsat värde.

Stora värdet finns i efterföljande och helt orelaterade idéer. Svårt att se någon som just studerande av 16-bit x86 kod idag kan lära oss. Att lära sig om 16-bit x86- assembler idag är lite som att föröka bli bättre bilförare genom att studera hästskötsel.

Edit: insåg att du inte refererade till mitt svar utan ditt eget ursprungliga svar
Visa signatur

Care About Your Craft: Why spend your life developing software unless you care about doing it well? - The Pragmatic Programmer

Permalänk
Medlem

Kan dom inte släppa källkoden till MS DOS 6.22 eller XENIX..

Permalänk
Medlem
Skrivet av klein:

Kan dom inte släppa källkoden till MS DOS 6.22 eller XENIX..

XENIX kan de nog inte släppa källkoden till, av juridiska skäl.
Dels så var mycket av den licensierad Unix-kod från AT&T, dels så sålde Microsoft Xenix till SCO redan på 80-talet.

Permalänk
Medlem
Skrivet av evil penguin:

Fann även https://www.theregister.com/2024/04/26/ms_dos_4_open_source/ som har något mer matnyttig rapportering om bakgrunden till vad som släppts och vad som kommer härnäst.

Skrivet av klein:

Kan dom inte släppa källkoden till MS DOS 6.22 eller XENIX..

Skrivet av Erik_T:

XENIX kan de nog inte släppa källkoden till, av juridiska skäl.
Dels så var mycket av den licensierad Unix-kod från AT&T, dels så sålde Microsoft Xenix till SCO redan på 80-talet.

"Though Hanselman's efforts are to be commended in making this piece of history available, it would be good if there were some sort of countdown for having the code of other obsolete software released. Hanselman has said that MS-DOS 3.3, 5, and 6 are next on the list, although some of the utilities in the latter would need to be stripped out."

så det låter ju som att 6 (kanske t.o.m. då 6.22?) är planerat att släppas det också, men man får väl anta att det även där finns licensierad kod som inte kan inkluderas eftersom de menar att det finns verktyg som måste plockas bort.

Visa signatur

Desktop: Ryzen 5800X3D || MSI X570S Edge Max Wifi || Sapphire Pulse RX 7900 XTX || Gskill Trident Z 3600 64GB || Kingston KC3000 2TB || Samsung 970 EVO Plus 2TB || Samsung 960 Pro 1TB || Fractal Torrent || Asus PG42UQ 4K OLED
Proxmox server: Ryzen 5900X || Asrock Rack X570D4I-2T || Kingston 64GB ECC || WD Red SN700 1TB || Blandning av WD Red / Seagate Ironwolf för lagring || Fractal Node 304

Permalänk
Medlem

Assembler sån lyx.
Jobbade med CC-DOS på 1980-talet. I varianten för 286 skulle jag fixa en bug med segment smörjan.
Det visade sig att instruktionen jag behövde inte var implementerad i assemblern.
Som tur var kunde man skriva inline HEX så det ordnade sig.
286 var nog den sämsta jag någonsin jobbat med.

Visa signatur

Klient: AMD 7 5800X | ASUS X570-F | 32GB 3200MHz | Corsair RM850 | Gigabyte 3070 | Phanteks P500A | Samsung 980 PRO
HTPC: Intel I7 4770T | 16 GB 1600 | FC8 EVO | Gigabyte GA-H87N-WIFI | Samsung 840 250GB
Server: Intel XEON E5620 x 2| ASUS Z8PE-D18 | 96GB 1333MHz | Corsair AX 1200W | HAF 932 | WD Black 2TB
Nätverk: Telia F@st| Unifi AC Lite/Pro/LR/Nano/Mesh/U6-LR/U6+/U6-Lite | Nighthawk M1 | pfSense | TP-Link TL-WPA8630KIT | Ubiquiti NanoStation M5 | UniFi Switch 8-150W

Permalänk
Medlem

Microsoft Releases DOS 4.0 Source Code... but it Doesn't Compile! - Bryan Lunduke
https://www.youtube.com/watch?v=pzhGAt3wYTI

Permalänk
Medlem

Det där med multitasking dos, det enda jag kände till tidigare som kunde köra flera dosinstanser samtidigt utöver Windows var DR-DOS.

Visa signatur

AMD 3700x, 1700 GB SSD, 18 TB HDD, 32 GB RAM, MSI RTX3070, Dubbla Blueray brännare.

Permalänk
Medlem

Det blir så tydligt när man får den här tillbakablicken på kod. Nästan allt här definierat i assembler. Idag är det oftare definierat i ett högnivåspråk i någon form av dialekt till C. Inom några år är det någon form av engelska i klartext som är mer likt det språk vi förstår själva.

Jag definierar numera mycket kod i prompts (mer som krav) och det är nästan mer användbart att återanvända min text där för att generera fram ny programkod även om koden i sig också är en form av transformerade krav.

Permalänk
Medlem
Skrivet av Erik_T:

XENIX kan de nog inte släppa källkoden till, av juridiska skäl.
Dels så var mycket av den licensierad Unix-kod från AT&T, dels så sålde Microsoft Xenix till SCO redan på 80-talet.

Är väl inte så mycket att hänga i julgrannen längre. Med tanke på att linux har funnits i 30 år. UNIX = Linux idag.

Permalänk
Skrivet av Yoshman:

Alright, och det jag reagerade på vad att det skulle finnas mycket att lära. Det kanske finns något, men det är nog tyvärr väldigt begränsat värde.

Stora värdet finns i efterföljande och helt orelaterade idéer. Svårt att se någon som just studerande av 16-bit x86 kod idag kan lära oss. Att lära sig om 16-bit x86- assembler idag är lite som att föröka bli bättre bilförare genom att studera hästskötsel.

Däremot kan man nog få jobb inom storbankerna som fortfarande använder förlegade system som baseras på assembler.

Permalänk
Medlem
Skrivet av newtoninja:

Däremot kan man nog få jobb inom storbankerna som fortfarande använder förlegade system som baseras på assembler.

Jag trodde bankernas äldre system mest var skrivna i COBOL.
Och om något av det är assembler, så är det ju knappast x86-assembler.