Source of MS-DOS 1 released


:D so how about a port for the pandora :p
Porting? Rewriting from scratch!
The code of DOS 1.1 is incomplete, DOS 2.0 consists out of ~45.600 lines of assembler, and Word 1.1 has even more assembler code next to its 400 files of C code...
 
Yep, it's a lot of 8086 assembler code. I'm a bit surprised that DOS was written completely in assembler, even stuff like DIR that is obviously not really performance-critical. I cannot imagine that C would have been too inefficient.
 
Yep, it's a lot of 8086 assembler code. I'm a bit surprised that DOS was written completely in assembler, even stuff like DIR that is obviously not really performance-critical. I cannot imagine that C would have been too inefficient.
Well when it ran on an actual 4.77Mhz 8086 I'm sure it needed to be pretty optimized.
 
Plus I don't know what state x86 C compilers were in before GNU. DOS1 at least was pretty much brought up by its own bootstraps I assume.


I remember seeing a machine running DOS2 in the late 90s. I couldn't see much wrong with it that DOS 6 fixed.
 
Yep, it's a lot of 8086 assembler code. I'm a bit surprised that DOS was written completely in assembler, even stuff like DIR that is obviously not really performance-critical. I cannot imagine that C would have been too inefficient.
Well when it ran on an actual 4.77Mhz 8086 I'm sure it needed to be pretty optimized.
Yeah, ASM rulez!!! :p
 
Yep, it's a lot of 8086 assembler code. I'm a bit surprised that DOS was written completely in assembler, even stuff like DIR that is obviously not really performance-critical. I cannot imagine that C would have been too inefficient.
Well when it ran on an actual 4.77Mhz 8086 I'm sure it needed to be pretty optimized.
Sure, optimizing things like the system calls and the stuff that stays in memory all the time makes sense (for reasons of both time and space). But something like DIR? I would think that something like listing the files in a directory is bottlenecked anyway by IO speeds, I really don't see why you would need to optimize that.
 
At that time assembler was simply common and compilers were rare and expensive, especially good ones for personal computer systems. The Amiga developers - for the non BCPL part - used a professional 68k compiler and ported the assembler output or something like that, but that was already some years later. My brother coded a word processing application around that time for his CBM 8032, completely in assembler (which he also coded himself using a more primitive assembler). I think the programmers simply didn't feel the need for a higher level language and/or didn't have the money.
 
Good compilers were indeed hard to come by, and particularly for new architectures like the 8088. There is a large stash of scanned-in BYTE magazines somewhere on the net, and those are very interesting to read. In particular columns along the lines of "what will be the language of the future" and stuff like that. I read one of those from really fairly late - 83-84-ish - where Jerry Pournelle was sure that the next big language would be Modula-2, taking over after Pascal as the general-purpose high-level language, and possibly Forth could supplant assembler in the low-level area. C was not really on the cards - Too far removed from the established standards (that is, Pascal), too inefficient compilers, in particular generating far to large executables to ever be useful as a systems programming language...
 
Interresting Information.

Can they maybe use Parts from the Code to make Dosbox faster?
no-3.jpg
 
Hah! Found it: BYTE 08-08, that is, August 1983, in an issue with the theme "The C language", Jerry Pournelle goes through the popular languages of the day to figure out what would be the most likely sweepstake language in the microcomputer world. He believes in Modula-2, thinks that "most useful" to learn right then would be a compiled basic (CB80) or Pascal, and has a small side bet on PL/1 taking the world by storm (after all, Gary Kindall likes it). For C, he notes that 

" However, I don't expect it ever to become a highly popular language, and if I had to bet on its future, I'd say that it will take

a respectable niche, after which its growth will be quite slow in comparison to the microcomputer world in general ."

 

I love computing archaeology :)

 

The reasons being that the language is difficult to read, does not enforce good programming habits, and that the compilers generate excessively large executables. He compiles a Hello World-thing with Lattice-C and ends up with an 11 kB executable, which is clearly out of line. He explains why this is (basically, it links a large standard library to "Make up for th missing UNIX environment" that the language expects. Further talk about systems programs in C, rewritten by an irate user in Assembler instead.

 

"There might be implementations that don't generate superfat code, but we haven't come across one."

 

I think PL/1 had some traction as a systems programming language around then still, but writing stuff in pure assembler was quite obviously an option. And this is written 2 years after the original MS-DOS came out (and had a total size almost the same as that Hello World program).
 
Back
Top