Microsoft zet MS-DOS 1.25 en 2.0 op GitHub

Microsoft heeft de broncode van MS-DOS versie 1.25 en 2.0 vrijgegeven op GitHub. De code is opensource gemaakt onder de licentie van MIT. Dit betekent dat iedereen die wil, de broncode kan delen, aanpassen en toepassen in hun eigen code.

Volgens de beschrijving op GitHub is niets veranderd aan de broncode en binaire bestanden in de repository. De publicatie is gedaan vanwege de historische waarde. De versies van de MS-DOS-broncode zijn vrij te gebruiken voor iedereen. De reden om de broncode op GitHub neer te zetten is om het makkelijker vindbaar te maken.

Het is niet de eerste keer dat Microsoft de broncode van het OS vrijgeeft. In 2014 mocht het Amerikaanse Computer History Museum de code voor MS-DOS 1.1 en 2.0 publiceren voor educatieve doeleinden. Dat gebeurde onder een strengere eigen licentie.

MS-DOS 1.25 en 2.0 zijn geschreven in 8086-assembleertaal en de 86-DOS-broncode waarop ze gebaseerd zijn, dateert van 29 december 1980. In augustus van dat jaar bracht Seattle Computer Products de eerste versie van 86-DOS uit, gemaakt door programmeur Tim Paterson. MS-DOS 1.25 zelf dateert van 9 mei 1983 en bestaat uit zeven bronbestanden. De 2.0-versie is drie maanden later geschreven en omvatte na verloop van tijd honderd .asm-bestanden.

ms dos 1.25

Reacties (81)

franssie 1 oktober 2018 16:16

Nobel om dit te delen. Maar de newbie die ik dan ben als het aankomt op processors, kan je dit compileren voor een moderne 64 bit processor of zal je met een emulator moeten werken, en zo bestaan die? Lijkt me nutteloos leuk om weer eens het oude DOS te zien.

Cebby

@franssie • 1 oktober 2018 16:25

Het ziet ernaar uit dat de code op het moment nog helemaal niet te compileren is omdat er stukken (lijken te) missen. https://github.com/Microsoft/MS-DOS/issues/8

Niet Henk @Cebby • 1 oktober 2018 16:56

Zie deze comment. Het lijkt wel te compileren te zijn, met wat haken en ogen.

Waarom ze het je lastig maken zou ik niet weten, zulk soort dingen worden altijd op gegeven moment opgelost.

Blokker_1999

Microsoft

@Niet Henk • 1 oktober 2018 18:11

Ik zou verwachten dat die opzettelijke fouten er al van in de jaren 80 inzitten en dat men nu gewoon de source ergens is tegengekomen en deze online hebben gegooid.

Lrrr

@Blokker_1999 • 1 oktober 2018 21:02

Obviously these aren’t the original filenames as long filenames didn’t exist until Win95 !

redzebrax @Lrrr • 1 oktober 2018 21:39

ik vermoed dat ze hun eigen aangepaste compiler gebruikten die de versie nummers eruit sloopte en laatste vervangen (degene die het succesfull compileerde had blijkbaar dat idee). Sowieso is het geen goed idee om long file names te gebruiken in 9x versies windows omwille van compatibiliteit met software die toen geschreven is, de long filenames gebruiken reserved places en die werden al eens ongewild gewist of aangepast.
.

[Reactie gewijzigd door redzebrax op 22 juli 2024 20:07]

Lrrr

@redzebrax • 1 oktober 2018 22:48

Maar de bestanden kunnen nooit uit het DOS-tijdperk stammen omdat de filenames te lang zijn. Ik neem niet aan dat ze een compiler hadden die het opeens mogelijk maakte om wel long filenames te hebben in dat tijdperk.

redzebrax @Lrrr • 1 oktober 2018 22:58

kan best wel aangezien er genoeg reserved bits waren in names, intern konden ze ermee doen wat ze wilden. Long names komt ergens van, meestal werd dit intern in het bedrijf al gebruikt, daarom zei ik dat het geen goed idee is om long names te gebruiken in win 9x versies. In die tijd was reserved idem als free to use.

[Reactie gewijzigd door redzebrax op 22 juli 2024 20:07]

redzebrax @franssie • 1 oktober 2018 16:54

PCEM emuleert complete systemen, 8086 tot en met pentiums (voor deze heb je al een zware pc nodig) met correcte timings etc. Het is alsof je werkt op een oud systeem inclusief bios etc.
Ik gebruik het om oude games nog eens te draaien, het is ook de enige die perfect een win95 omgeving laat draaien.
https://pcem-emulator.co.uk/index.html

voorbeeld:
win95 met voodoo2 emulatie
https://tweakers.net/ext/f/0U3B0HEO28qX7KXLAFY7Tc1g/full.jpg

Xaphod @redzebrax • 1 oktober 2018 17:01

Leuke link, die kende ik nog niet.

Werkt de Voodoo 2 emulatie goed? Die staat nog niet in de ondersteunde hardware.

redzebrax @Xaphod • 1 oktober 2018 18:23

die zit er standaard in: Het is wel even zoeken naar de correcte drivers (pcem emuleert alleen hardware), tot nu toe werkt hij perfect bij mij.

https://tweakers.net/ext/f/a7HsE8jX4Au2f4sm5mR9q6yI/full.jpg

Hou er rekening mee dat je met een leeg systeem begint. Dos installeren (mscdex voor cdrom access)
Als je images maakt van cdroms (voor je drivers) gebruik dan ISO 9660 Dos 8.3 filenames.
Geheugenoptimalisatie, IRQ's en al wat je vroeger moest doen om een systeem werkend te krijgen.

Wingman555 @redzebrax • 1 oktober 2018 20:10

Heb er nu alwwer zin in. Heb hier zelf nog een P3 800 staan met voodoo2 kaart maar op deze manier kan ik mijn oude 80286 vitueel weer leven in roepen. Commander keen here i come! $_/-\o_$

Xaphod @redzebrax • 2 oktober 2018 16:25

Bedankt, ik heb nog twee win 98 pc's staan, eentje met een voodoo 2 en een Gravis Ultrasound.
In een virtuele omgeving is het wat minder tijdrovend om fouten te maken en weer opnieuw te beginnen.

franssie @redzebrax • 1 oktober 2018 17:02

Ha top - ga ik eens mee spelen. Ook omdat ik nog wel wat legacy hardware heb voor W95 die ik werkelijk nergens aan de praat krijg, eens zien of ik die kan reverse engeneren.

anandus @redzebrax • 2 oktober 2018 10:32

het is ook de enige die perfect een win95 omgeving laat draaien.

Hehehe, zelfs win95 kon niet eens een win95-omgeving perfect draaien

barchettanl @redzebrax • 2 oktober 2018 14:03

Is PCEM zoiets als DOSBOX?

~edit~ het lijkt meer op MESS (is nu geïntegreerd in MAME geloof ik)

[Reactie gewijzigd door barchettanl op 22 juli 2024 20:07]

MSalters @franssie • 1 oktober 2018 16:35

Je kunt het zelfs niet compileren voor een oude 32 bits processor. Dit is nog klassieke 16 bits assembly voor de 8086. Ook DOS 2.0 is van voor de tijd dat je EMM386 en dergelijke had.

Noitisnt @MSalters • 2 oktober 2018 09:07

Tijd om de Compaq Portable I weer eens aan te slingeren

supertanno @franssie • 1 oktober 2018 16:23

64-bits systemen kan je beter OpenDOS op zetten, of een emulator als DOSBox gebruiken.

jqv @supertanno • 1 oktober 2018 16:28

En wat is er beter aan opendos?

En dat was niet de vraag van @franssie

Om antwoord te geven.
Begin eens met een emulator.
Dan ben je verzekert van een werkende omgeving.

Als kennismaking kun je ook gebruikmaken van Opendos of Dosbox.

gjmi @franssie • 1 oktober 2018 16:42

Je miet wel een oude processor hebben die dit kan draaien.
Intel processoren zijn lang backwards compatibel, maar af en toen veranderen een paar dingen. En echt oude software en OS zijn niet meer compatibel.

Simon Weel 1 oktober 2018 16:23

Ooit begonnen met DOS 2.0. Dat kende, als ik het me goed herinner, het begrip 'sub-directories' nog niet. Maar aangezien alleen met floppies werd gewerkt, was dat geen gemis....

wildhagen

@Simon Weel • 1 oktober 2018 16:30

Versie 2.0 kende wel degelijk subdirectories, dit concept werd namelijk in 2.0 geintroduceerd

MS-DOS 1.x kende idd geen directories, daar gooide je alles in de root.

MS-DOS 2.0 was ook de eerste door MS in-house geschreven versie, en week behoorlijk af van het (op 86-DOS gebaseerde) 1.x.

Naast directories had 2.0 nog een aantal nieuwe features, zoals ondersteuning voor harddisks (1.x kon daar nog niet mee overweg), piped redirection, en achtergrondprocessen. En ook device drivers deden met versie 2.0 hun intrede.

boudewijnrempt @wildhagen • 1 oktober 2018 17:05

Het vreemdste dat ik gezien heb was de handleiding voor mijn Spring Circle Super Turbo PC: die kwam met Dos 2.0, en de handleiding gaf een uitvoerig overzicht van een typische directory structuur. /bin, /etc, /usr -- helemaal alsof het Unix was. Zonder enige verdere begrijpelijke uitleg. Ik was toen nog niet zo goed in Chinees Engels. En ik was 16 en wist niets van Unix, dus ik nam aan dat /bin "vuilnisbak" betekende, en zo lang als ik MS-Dos heb gebruikt had iedere floppy-disk die ik gebruikte voor data een bin directory waar ik oude versies van bestanden en dingen die ik niet meer nodig had in stopte.

Duckman51 @boudewijnrempt • 1 oktober 2018 17:29

"dus ik nam aan dat /bin "vuilnisbak" betekende"
hahaha mn pa zou het ook zo vertalen, die kan echt geen engels

FooLsKi @Duckman51 • 1 oktober 2018 18:06

Het woord "bin" is toch echt wel Engels voor vuilnisbak. Ik vind het geen gekke gedachte als je niets van Unix af weet

CivLord

@FooLsKi • 2 oktober 2018 08:21

'Bin' is Engels voor 'bak'.
'Dustbin' is het Engelse woord voor 'vuilnisbak'. Het wordt wel vaak afgekort tot 'bin'.
'Trashcan' is een ander Engels woord voor 'vuilnisbak' en wanneer de context duidelijk is wordt dat ook vaak afgekort tot 'can'. 'Can' wordt ook wel eens gebruikt voor 'toilet', maar ik weet zo even niet waar dat vandaan komt.

anandus @CivLord • 2 oktober 2018 10:38

In het (Brits) Engels wordt 'bin' een stuk meer gebruikt dan 'garbage bin' of 'dust bin' (eerlijk gezegd heb ik nooit iemand dat laatste horen zeggen).
'Trash can' is overigens Amerikaans Engels.

CivLord

@anandus • 2 oktober 2018 12:54

Dustbin is het Engelse woord dat ik op school heb geleerd. (Een eeuwigheid geleden.)
Maar school Engels heeft wel meer 'aansluitproblemen' met het Engels dat aan de andere kant van het kanaal gesproken wordt. (Om over het dialect dat er aan de andere kant van de oceaan gesproken wordt maar te zwijgen.)

boudewijnrempt @Duckman51 • 1 oktober 2018 18:08

Wel, technisch gesproken heeft je pa gelijk. "bin" betekent "bak, doos, kist, vuilnisbak, prullebak". Een huisgenote van me, wat later, toen ik al studeerde, nam mijn system over, maar bij haar heette de directory "prullie".

Luno @Simon Weel • 1 oktober 2018 16:39

Versie 1 kende de geen subdirs Versie 2 wel (in elk geval versie 2.11). Groter probleem was dat versie 1 dus maar DIR's kende op root niveau en dat daar een limiet op zat qua aantal (ergens rond de 100 files of zo).

wildhagen

@Luno • 1 oktober 2018 16:45

Op zich was dat niet zo'n bezwaar, want de grootste floppy disk die 1.x ondersteunde was een 160 kB-floppydisk, je liep dus niet zo snel tegen die maximumlimiet aan.

Pas met versie 2.0 kwam er support voor 180 kB en 360 kB-floppy disks (5.25 inch uiteraard).

Versie 1.0 kende maar een zeer beperkt aantal commando's, alleen DIR, COPY, ERASE, PAUSE, REM, RENAME, en TYPE werden herkend, en voor DATE en TIME had je externe programma's. Batch-files kende DOS 1.x ook, maar zeer beperkt tov latere versies.

Leuk artikel over 1.x: http://www.os2museum.com/wp/dos/dos-1-0-and-1-1/ (voor 2.0: http://www.os2museum.com/wp/dos/dos-2-0-and-2-1/)

Edit: kleine aanpassing, nav terechte opmerking @-jacQues- hieronder, was me geheel ontschoten na 20+ jaar

[Reactie gewijzigd door wildhagen op 22 juli 2024 20:07]

-jacQues- @wildhagen • 1 oktober 2018 17:22

PAUSE en REM zijn nochtans specifiek voor batch-files?

veloce @wildhagen • 2 oktober 2018 10:53

Ms-Dos 2.0 ondersteunde ook al een harddisk, met een max. van 15 Mb.
De FAT was beperkt tot 12 Bits, wat gebruikelijk was voor floppies.
in Ms-Dos 3.0 werd de FAT 16 Bits en de partitie tot 32 Mb. vergroot, vanaf van V 3.3 konden er ook meerdere logische schijven/partities gemaakt worden.
Speciale versies hiervan zoals die van Compaq (4.0) en Zenith (3.3+) konden een grotere partitie dan 32 Mb. aan omdat ze "logical sectoring" toepasten.

bartje 1 oktober 2018 16:24

vraag me af ofdat er code in staat die nu nog steeds in Windows wordt gebruikt als CMD commando

wildhagen

@bartje • 1 oktober 2018 16:50

Lijkt me niet, aangezien alles toen 16-bits was. Tegenwoordig ondersteunt Windows 16-bits niet eens meer, zelfs voor 32-bit wordt al een WoW (Windows-on-Windows) laag gebruikt (bij x64-versies van Windows).

CMD.EXE is ook geen DOS-prompt, maar een commandprompt. Een wezenlijk verschil, hoewel ze uiteraard wel heel erg op elkaar lijken, is het niet precies hetzelfde. Tot een paar Windows-versies geleden had je, naast CMD.EXE, ook nog COMMAND.COM wat wel de oude DOS-interpreter was (lees: Windows 9x).

[Reactie gewijzigd door wildhagen op 22 juli 2024 20:07]

redzebrax @wildhagen • 1 oktober 2018 19:06

Klopt, 9x was dan ook de link tussen 16-bits dos en windows, die 9x systemen starten dan ook nog op met een aangepaste dosversie alvorens ze het roer in handen namen, daarom was de command.com nog present.

gjmi @bartje • 1 oktober 2018 16:49

Tegenwoordig zal de meeste code niet meer in assembler geschreven zijn. En dit is 16 bit assembler. Dat zal niet werken op een moderne x86 processor. Dus ik durf te zeggen: nee, er zal geen code uit deze versie in de huidige Windows gebruikt worden.

gimbal @gjmi • 1 oktober 2018 19:29

Backwards compatibility is nog steeds een ding.

Zie deze held bijvoorbeeld die msdos installeerde op een gaming monster uit 2017:

https://www.youtube.com/watch?v=bS9hiSwL1KY

Werkt gewoon. Kleurtjes van legacy beeldformaten kloppen niet en je gaat nooit van zijn leven een geluidskaart aan de praat krijgen maar wel gewoon ratelen.

arsimo @gimbal • 1 oktober 2018 20:13

De kleuren komen prima overeen met zoals het was. Gewone cga kleuren.

gjmi @gimbal • 1 oktober 2018 20:18

ok, maar MS-dos 6.22 is al heel andere koek dan 1.25 en 2.0

gimbal @gjmi • 2 oktober 2018 10:33

Punt is dat de huidige hardware nog steeds net alsof kan doen dat het een oude x86 is mocht je spontaan zeer verouderde software installeren. Ik denk niet dat je Dos 2 nog gaat kunnen installeren op de hardeschijf, maar booten vanaf floppy zal nog wel lukken vermoed ik zo.

gjmi @gimbal • 2 oktober 2018 11:02

Nee, 16 bit wil echt niet meer.

Waterbeesje @gjmi • 2 oktober 2018 13:27

Zeker wel. Maar niet wanneer je eerst een zuiver 32 bit of 64 bit OS zonder backward compatibility gaat laden. En je BIOS/UEFI moet dit ondersteunen.
Voor industriële toepassingen zijn die er nog gewoon te vinden, want er is nog steeds afhankelijkheid van een uniek stukje software voor machine X uit 1983 welke te duur is om te vervangen en de komende 35 jaar waarschijnlijk ook nog prima werkt.

Een 16 bit OS of een 32 bit+ met backward compatibility zal het gewoon doen, en jouw (kopie van) Prince of Persia gewoon draaien zonder problemen.

Een deftige ondersteuning voor je RTX2080 kun je uiteraard wel vergeten op een 16b DOS 2.0 / 3.30 / 5.02 / 6.22

(hoewel het ongetwijfeld beeld zal geven als het start)

Henk Poley @Waterbeesje • 3 oktober 2018 08:45

Info van Intel: https://www.intel.com/con...000006778/processors.html

Can my 16-bit application run with the 4th, 5th, and 6th Generation Intel® Processors?

64-bit operating systems don't support 16-bit components, 16-bit processes, or 16-bit applications
16-bit applications and software aren't validated on 4th Generation Intel® Processor families
16-bit may run on 32-bit operating systems, but it's not optimized for 32-bit OS
Consult with your software vendor for a 32-bit or 64-bit version to use with the newer hardware and operating system

Het lijkt er op dat ze gezegd hebben "Dit stukje CPU logica doet alle 16bit, daar gaan we vanaf nu vanaf blijven". Want valideren (testen) doen ze dus niet meer.

[Reactie gewijzigd door Henk Poley op 22 juli 2024 20:07]

NaliXL 1 oktober 2018 16:28

Waarom niet - pak 'm beet - ms dos 5.0 dan ook vrijgeven vraag ik mij af (zonder af te doen aan het feit dat ik het prachtig vind dat microsoft versie 1.25 en 2.0 vrijgeeft)? Ik kan mij niet voorstellen dat er veel belangen bij gebaat zijn om het niet te doen.

MSalters @NaliXL • 1 oktober 2018 16:37

Gokje: rond MS-DOS 5 had Microsoft patentproblemen met doublespace/drivespace. Het patent zelf is wel verlopen, maar ze hebben de zaak toen geschikt. En die schikking heeft vermoedelijk geen einddatum.

wildhagen

@MSalters • 1 oktober 2018 17:04

MS-DOS 5.0 kende nog geen DoubleSpace, dat werd pas met MS-DOS 6.0 geintroduceerd

De rechtzaak met Stacker speelde dus ook over versie 6.0 (en later 6.20). Daarna kwam MS met MS-DOS 6.21, waar DoubleSpace uit verwijderd was, na de rechterlijke uitspraak.

In versie 6.22 werd daarna DriveSpace herintroduceerd, waarbij die patenten van Stacker niet meer werden gebruikt. DriveSpace was verder volledig compatible met DoubleSpace, en werkte ook exact hetzelfde voor de user.

veloce @wildhagen • 2 oktober 2018 11:02

Stacker had heel sneaky patenten opgekocht tijdens de ontwikkeling van Ms-Dos 6, het is nooit bewezen, dat het hun intentie was hier een rechtzaak uit te slepen, maar dat is wel gebeurd.
Deze zaak is toen geschikt door Microsoft, en om geen patent inbreuk meer te doen heeft men 6.22 uitgebracht.
Er was wél een conversie nodig, maar bij upgrade van 6.0/20 naar 6.22 werd het Doublespace volume automatisch geconverteerd, dit ging in de béta's nog wel eens fout, ik heb enkele "gebruikers ervaringen" aan de lijn gehad indertijd van mensen die geen béta tester waren en dit toch in handen hadden gekregen.

[Reactie gewijzigd door veloce op 22 juli 2024 20:07]

Hachy @MSalters • 1 oktober 2018 17:13

@MSalters Doublespace kwam volgens mij pas in MS-DOS 6.0.
3.3 en 5.0 waren toch echt wel de beste en populairste releases destijds.

wildhagen

@NaliXL • 1 oktober 2018 16:34

Ik denk omdat MS-DOS 1.x en 2.x meer historische waarde hebben dan versie 5.x en 6.x. Het waren grotere stappen die toen gemaakt werden.

Wel zouden ze imho MS-DOS 3.3 ook nog vrij mogen geven. Dit is de eerste MS-DOS versie die écht succesvol geweest is, en heel erg lang is gebruikt door velen, ook nadat 4.x en 5.x al uitkwamen. In die versie werd bijvoorbeeld ook voor het eerst support ingebouwd voor 3.5 inch 1.44 MB floppies.

DeMoN @wildhagen • 1 oktober 2018 22:50

Diskettes he, geen floppies

GekkePrutser 1 oktober 2018 16:57

Tja, in die tijd was heel veel "open source" omdat het in assembler was geschreven dat zich 1:1 vertaalde naar een binary

(assembler macro's en commentaar even daargelaten maargoed).

Grappig dat Unix programma's in die tijd al in C werden geschreven maar PC programma's meestal niet. C was dan ook een van de grote verbeteringen van Unix (en je kreeg er in het begin de source zelfs bij).

In die tijd kon je een heel programma schrijven en/of aanpassen met DEBUG.EXE. Handig was anders, maar het kon..

[Reactie gewijzigd door GekkePrutser op 22 juli 2024 20:07]

mashell @GekkePrutser • 1 oktober 2018 17:34

C is toch gemaakt om Unix in te kunnen schrijven?

Blokker_1999

Microsoft

@mashell • 1 oktober 2018 18:19

C is gemaakt met het doel van Unix te herschrijven. Unix zelf is ouder dan de taal. C kan ook aanzien worden als de opvolger van B

GekkePrutser @mashell • 1 oktober 2018 17:54

Ja klopt en daardoor werden de meeste applicaties er ook in geschreven (je moest voor de kernel functies immers linken met C libraries dus die keuze lag voor de hand). De compiler werd ook meegeleverd.

Dus dat heeft de adoptie enorm toe doen nemen. Met DOS kreeg je er alleen BASIC bij (eerst BASIC van Microsoft en later gwbasic), dat niet echt geschikt was voor serieuze programma's. Maargoed PC's waren ook een stuk zuiniger uitgevoerd qua componenten dus je had die extra efficientie ook wel nodig.

[Reactie gewijzigd door GekkePrutser op 22 juli 2024 20:07]

wildhagen

1 oktober 2018 17:33

Ook aardig: van MS-DOS zijn trouwens ook vervies voor andere platformen gemaakt dan enkel x86. Een bekend voorbeeld was MSX-DOS, voor de MSX (MicroSoft Extended), een zéér populaire homecomputer in de jaren 80 en 90, en grote concurrent van de Commodore 64.

De MSX draaide immers niet op x86, maar op een 8-bits Zilog Z80 processor (initieel op 2.5 Mhz).

Qua features liep die redelijk gelijk op met MS-DOS 1.25 en MS-DOS 2.0: ook de eerste versie van MSX-DOS ondersteunde geen harddisks en subdirectories, maar met MSX-DOS 2.0 werd dat ook voor de MSX geintroduceerd.

Zelf was ik in die tijd ook heel actief in de MSX-wereld (Philips VG/NMS en Sony HitBit met name), en heb toen aardig met MS(X)-DOS kunnen stoeien. De kenners kennen vast "_SYSTEM" nog wel, waar je MSX-DOS mee kon starten vanuit MSX-BASIC

Ik weet niet of er naast de Z80 en x86 nog meer MS-DOS versies voor andere platformen zijn geweest.

arsimo @wildhagen • 1 oktober 2018 20:17

Het leuke was dat die MSX-DOS compatible was met CP/M, de voorloper van MS-DOS op 8080 en Z80. Daarom draaiden toen nog veelgebruikte en bekende software als Wordstar, dBase II en Turbo Pascal (tot 3.0) op msx computers.

psychicist @wildhagen • 1 oktober 2018 23:31

Mijn eerste computer was ook een MSX2 Sony Hitbit. Die heb ik nog tot 1998 gebruikt, toen ik mijn eerste PC kocht. Linux en NT4 gebruikte ik op de universiteit. Tot een paar jaar daarna heb ik thuis Windows 95, 98 en 2000 gebruikt, totdat ik volledig overschakelde op Linux, omdat Windows mijn bestanden had opgegeten.

pleiadian 1 oktober 2018 16:30

Geweldig... in die tijd moest je als eerste de datum en tijd ingeven.

Switching Power @pleiadian • 1 oktober 2018 16:41

Dat kwam niet door DOS zelf maar omdat PC's in die tijd simpelweg geen klok hadden.
Als je MS-DOS 7 op de originele PC zou draaien krijg je dezelfde vraag voor datum en tijd.

Blokker_1999

Microsoft

@Switching Power • 1 oktober 2018 18:15

Ze hadden uiteraard wel een klok, maar geen mogelijkheid om die correct te laten lopen als de PC eenmaal stroomloos werd gezet.

TheVMaster Moderator WOS @Blokker_1999 • 1 oktober 2018 20:47

Onze Tulip Compact 2 had gewoon een batterij. Het feit dat je datum+tijd elke keer moest invullen, kwam volgens mij alleen voor als je geen Autoexec.bat/config.sys had aangemaakt....met eventueel een prompt $p$g (ofzoiets) voor een mooie C:\> prompt.

ToolBee @pleiadian • 1 oktober 2018 16:35

Maar eerst een stapel floppies laden!

RobinJ1995

1 oktober 2018 16:14

Dus hoe groot zou het verschil zijn tussen MS-DOS en de DOS die Microsoft oorspronkelijk gekocht heeft en dan een Microsoft rebrand gegeven heeft?

The Third Man @RobinJ1995 • 1 oktober 2018 16:24

Staat toch beschreven alhier?

RobinJ1995

@The Third Man • 1 oktober 2018 16:32

Grappig, dus exact dat. Een rebrand

dfader 1 oktober 2018 20:09

De source code van Edlin... Echt nooit gedacht dat ik dat ooit nog eens zou zien

TheVMaster Moderator WOS @dfader • 1 oktober 2018 20:53

Cool....dat is lang geleden....daar worstelde mijn pa altijd mee eind jaren 80....hehe tijdens zijn MS-DOS cursus....

xorpd @dfader • 2 oktober 2018 10:33

World's worst editor ever...

Sjah 1 oktober 2018 18:39

Toen mannen nog van staal waren en hun baarden jaren 70.....geschreven in machinetaal...dus snel. Tegenwoordig zal de overhead wat groter zijn, lees de inefficientie vd talen.

Skyrunner @Sjah • 1 oktober 2018 19:04

Tegenwoordig wordt de hardware naar de software gemaakt, niet vice versa, zoals ten tijde van assembly. Kijk maar naar de C64 (waar vandaag de dag nog steeds het uiterste uit de hardware wordt geperst met geoptimaliseerde code).

Sjah @Skyrunner • 1 oktober 2018 19:09

Das mij op zich bekend.
Maar ik kan genieten van Firefox dat veel sneller is gemaakt toen de engine herschreven werd in de taal Rust, dus het kan nog wel, en bij browsers is het ook nodig ook.

Op dit item kan niet meer gereageerd worden.

Microsoft zet MS-DOS 1.25 en 2.0 op GitHub

Lees meer

Reacties (81)

Sorteer op:

Weergave: