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

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.

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

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

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.

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 ?

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

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

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.

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.

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.

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.

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.