5 ms·

The Road to MS-DOS 2.0

109 points by whobre 2mo ago

walrus01 1mo ago
I know this is software focused, but as much of the work done in DOS 2.0 was to support the introduction of hard disks, it would be worth mentioning what the hardware was in the PC/XT: https://en.wikipedia.org/wiki/ST-506/ST-412 https://en.wikipedia.org/wiki/ST-506/ST-412 https://www.google.com/search?client=firefox-b-d&q=ST-212+hard+drive https://www.google.com/search?client=firefox-b-d&q=ST-212+ha...
- ColdStream 1mo ago
  I love that for the next few years they were commonly called Winchester drives due to IBM's original naming in the early 70's.
  - glimshe 1mo ago
    My dad still called it "Winchester" well into the 80s. I remember when we got our first "Winchester", a 20MB hard drive.
    - WalterBright 1mo ago
      My first hard drive was 6Mb. I had to design/build my own interface board for it, and write the driver for RT-11.
  - walrus01 1mo ago
    As I recall 8 inch class HDD (5, 10, 20MB?) were called Winchester in the pre-PC/XT era, named for the earlier IBM product, and then the terminology carried on into the microcomputer/desktop world when the 5.25" full height HDD was introduced for the XT.
jmclnx 1mo ago
>Even a scaled-down version of Unix was too demanding for the 8086 chip”. Interesting. At my old job I got my hands on Wang IN/ix around 1985, a 16 bit UNIX. It ran on an 8086 but needed 512k memory. It ran fine. I wonder if memory was the main issue ? But seems the issue was probably memory for IBM and MS
- somat 1mo ago
  2BSD is still hanging on getting updates and forked projects to this day. My understanding is that it's longevity in the face of the existence of 4bsd is because it is 16-bit clean, These days it is mainly for people who want a unix for their microcontroller. Here is one, https://github.com/RetroBSD/retrobsd https://github.com/RetroBSD/retrobsd. This is for the pic32, so I may be wrong about the 16-bit thing. I don't know if anyone has done it but it looks like it could fit, perhaps not on a original 8086 PC, but perhaps a 286 with 640K.
- Narishma 1mo ago
  Yes, memory was the main issue. The PC launched with 64KB of RAM. Technically there was a model with 16KB of RAM and no disk drive but I don't think they produced or sold many of those.
  - aYsY4dDQ2NrcNzA 1mo ago
    640
    - Narishma 1mo ago
      64, not 640.
      - defrost 1mo ago
        Well, 16 KB - 256 KB, with a directly addressable 64 KB and a segmented architecture to reach further. I had one of these in mid 1982 to late https://en.wikipedia.org/wiki/IBM_Personal_Computer https://en.wikipedia.org/wiki/IBM_Personal_Computer
add2 1mo ago
Unexpectedly, MS-DOS 2.0 included a /dev directory. https://github.com/microsoft/MS-DOS/blob/main/v2.0/source/CONFIG.txt https://github.com/microsoft/MS-DOS/blob/main/v2.0/source/CO...
- somat 1mo ago
  A lot of early dos development was trying to see how many unix concepts they could fit, directories, pipes, environment, devices.
  - mesrik 1mo ago
    And file handles stdin, stdout, stderr same file numbers also. There was and still is overlapping features with Microsoft later and current operating systems. Linked post is quite good and had forgotten completely XEDOS mentioned Byte article.
- mesrik 1mo ago
  It did, and also up till 3.0 (thus 2.10 and 2.11) had also SWITCHAR which you could change command options character / to - like in it was in UNIX convention, from CONFIG.SYS definition. The problem with changing / to - was, that under MS-DOS command line parsing was left completely to a a loaded program, which then would had to know how to find out this change and act accordingly. And if not only MS-DOS std. utilities behaved properly and others not so much. Thus causing confusion which perhaps then lead to dropping that feature 3.0 onwards. I think it was also before 2.0 or at least what delivered with Apricot PC (UK made PC) 1.25 which I tinkered with few days as we had it on display from Finnish importer ARAIC Rautakirja Oy (Finnish railways VR magazines and other related travel reading importer, also keeper of the R-kiosks). A very nicely built non IBM PC compatible PC with good graphics and then uncommon 3.5" 70kb disk drives before Apple Macintosh made the more popular. https://www.homecomputermuseum.nl/en/collectie/act-computers-ltd/act-apricot-pc/ https://www.homecomputermuseum.nl/en/collectie/act-computers... e: Now did it change also path separator from \ to / ? It may have done it also. I bit later work more with Xenix and can't remember for sure. Starting from 286 versions SvR2.x, 386 SvR3.x up till SCO UNIX SVR4 early 90's and less with MS-DOS besides maintaining couple of TSR's I had written and just checked every MS-DOS release that those still did work.
markus_zhang 1mo ago
I was teaching myself 8086 16-bit assembly a few nights ago on MS-DOS 5.0. It was so much fun getting a color block to display on CGA. Nevertheless, writing system code in assembly was probably going to cause a lot of insomnia and other side effects, especially when Microsoft was far from the domination force on IBM PC.
- WalterBright 1mo ago
  The easy way to write assembler for a machine with no compilers is to write the code in C, get the algorithm right, then translate it to asm.
  - pjmlp 1mo ago
    Or any other compiled language for that matter. :)
    - mesrik 1mo ago
      It is, but some tools like Turbo C did provide asm generating switch (-S AFAIK) directly you to use and saved you from using debug.com or any better disassembler.
      - deleted 1mo ago
        [deleted]
      - pjmlp 1mo ago
        As did many other compiled languages including those predating C, people should stop putting it on pedestal. Fortran 77 manual for UNIX, https://www.unix.com/man_page/v7/1/f77 https://www.unix.com/man_page/v7/1/f77 You can find plenty of other examples, when doing digital archaeology.
        mesrik 1mo ago
        Sure, it wasn't uncommon feature at all, but many fellows I knew had not noticed it before I suggested using it when a colleague or a friend was wondering how he would write that function assembler and try to make it faster. It tells me more about some people not being curious enough to read documents and explore environment they work than others apparently. Assembler generating was long time a standard feature of compilers simply because writing the assembler code was easier than directly runnable or linkable object code. And for language designer and compiler programmer it was easier to read verifying correct code generating that way. Why bother writing assembly compiler, linker etc. when you usually already had them in the system that time. Then later it changed bit as vendors did not any more ship any or just some crippled compliers to compile just a new kernel with the base system to curb their language competition. Which made third party compilers had to either provide with complete set their own creating executables or ask buyer also licensing system vendor compiler toolkit which they would not otherwise need. That then caused prospect third party compiler customer add that licensing fee top of offering and compared which option they would buy if any. That was time when developement toolkits started changing. Under MS-DOS there never was compiler shipped with it that was a situation all the time, but with the minis and larger systems more what described here above. ps. I think you get much too wound up about C-language. For a long time there was no real alternative use to cross environments compatible way developing thing without major rewrite each platform. That what mattered more than anything else then and in some sense also to some these days also. And no language needs to be put on pedestal like you wrote message you already changed or deleted so that I did not get to answer.
peter_d_sherman 1mo ago
>"But it soon became clear that IBM was committed to keeping DOS 2.0 as close as possible to the eight thousand bytes [8K] used by DOS 1.1, so as not to disrupt their existing user base. [...] The first version of MS-DOS 2.0 shipped with IBM PC XT as PC-DOS 2.0 on March 8, 1983. It required about 20 KB of RAM, far more than MS DOS 1.0, so both versions continued to be sold simultaneously for a while." And that approximate doubling, in RAM requirements, year by year (compare to Moore's Law for hardware!) for Microsoft's OS'es, has got us, fellow students of computer history, to where we are today -- with Microsoft OS'es being the size that they are and requiring the RAM that they do! And it all started with upgrading (or "upgrading", take your pick of term!) an 8KB OS to a 20KB OS! :-)
- lproven 1mo ago
  "The hope is that the progress in hardware will cure all software ills. However, a critical observer may observe that software manages to outgrow hardware in size and sluggishness." -- Martin Reiser, quoted by Niklaus Wirth
  - peter_d_sherman 1mo ago
    Well said, Liam Proven, well said!
EvanAnderson 1mo ago
This is enlightening. Growing up playing with Unix boxes (and XENIX, specifically, mostly writing shell scripts and playing in the filesystem) and programming MS-DOS in assembly I could often see strange parallels between how stuff worked in MS-DOS and his stuff was in Unix. I just assumed MSFT programmers had used Unix at some point and wanted to lift features and idioms from it to use in DOS. It never occurred to me, knowing XENIX was a MSFT-licensed Unic derivative, that there might be more direct inspiration in that vague Unix "flavor" in DOS. I never did any CP/M programming, so the whole FCB-based file manipulation API in MS-dos just seemed like strange old cruft to me. Had I been exposed to CP/M the Unix inspiration behind the handle-based API would have been a lot more apparent. (I got in about the MS-DOS 3.3 timeframe...) What a strange world it would have been in MSFT got IBM to buy into the Unix path separator.
- WalterBright 1mo ago
  CP/M showed a lot of similarities to DEC's RT-11.
- euroderf 1mo ago
  > the Unix path separator. Using the backslash: one of those incredibly idiotic things that caused untold misery and time waste further down the road. Future generations cursed the day.
  - jlmcgraw 1mo ago
    It sounds like Microsoft _wanted_ to use '/' as the path separator but was forced by IBM to change it at the last minute: https://www.os2museum.com/wp/why-does-windows-really-use-backslash-as-path-separator/ https://www.os2museum.com/wp/why-does-windows-really-use-bac...
pjmlp 1mo ago
Traditional reference how Microsoft was doubling down on UNIX with Xenix, before having a change of heart. The Future of Xenix, Bill Gates Interview on Unix World, back in 1985 https://archive.org/details/Unix_World_Vol02_10.pdf https://archive.org/details/Unix_World_Vol02_10.pdf
- walrus01 1mo ago
  Xenix was targeted at a hardware spec that was well out of reach for the ordinary home PC consumer. The amount of ram and HDD needed to install and run it would make a computer in 1985/1986 money equivalent to a $12,000 desktop today. They always knew they needed to keep developing DOS for the low end.
  - pjmlp 1mo ago
    Sure, but as the article points out, had it not been for the change of heart, Xenix light could have been something like Coherent. Having learnt UNIX on Xenix, I know how expensive it was, we had a single tower that the teacher carried on into class, while we in groups of 2 students had about 15 minutes time slots to try out our applications that we prepared on MS-DOS ahead of time with Turbo C 2.0.
fsiefken 1mo ago
decades later there are fuzix and elks running on 8085 or 8086 respectively: https://www.fuzix.org/downloads/0.4/ https://www.fuzix.org/downloads/0.4/ https://github.com/ghaerr/elks https://github.com/ghaerr/elks
muaaz359 1mo ago
[dead]
RetroTechie 1mo ago
Note that 2 of the features added: a) support for subdirectories, and b) replacing File Control Blocks (FCB) with file handles, are the same as for MSX-DOS: MSX-DOS (1) uses FCBs and a single root directory MSX-DOS (2) also uses file handles and supports subdirectories MSX-DOS (both versions) build on a low-level driver which controls the floppy/hard drive. This came in ROM and included higher-level disk handling (file operations, Disk-BASIC etc). The "DOS" part came on a floppy (MSX-DOS.SYS/COMMAND.COM or MSX-DOS2.SYS/COMMAND2.COM). Yes Microsoft was involved here too. Note that MSX-DOS offered some CP/M compatibility: some programs pulled straight from CP/M (Z80 flavour) could run under it. Some functions deal with CP/M-derived 128-byte "records" (from CP/M floppy formats' sector sizes) rather than byte sizes. But no CP/M disk formats were supported afaik. Other than that, MSX-DOS2 offered some memory management functions for MSX2's memory mapper. Not sure if equivalent functionality was included in MS-DOS 2?

109 points by whobre 2mo ago

I know this is software focused, but as much of the work done in DOS 2.0 was to support the introduction of hard disks, it would be worth mentioning what the hardware was in the PC/XT: https://en.wikipedia.org/wiki/ST-506/ST-412 https://en.wikipedia.org/wiki/ST-506/ST-412 https://www.google.com/search?client=firefox-b-d&q=ST-212+hard+drive https://www.google.com/search?client=firefox-b-d&q=ST-212+ha...

ColdStream 1mo ago
I love that for the next few years they were commonly called Winchester drives due to IBM's original naming in the early 70's.
- glimshe 1mo ago
  My dad still called it "Winchester" well into the 80s. I remember when we got our first "Winchester", a 20MB hard drive.
  - WalterBright 1mo ago
    My first hard drive was 6Mb. I had to design/build my own interface board for it, and write the driver for RT-11.
- walrus01 1mo ago
  As I recall 8 inch class HDD (5, 10, 20MB?) were called Winchester in the pre-PC/XT era, named for the earlier IBM product, and then the terminology carried on into the microcomputer/desktop world when the 5.25" full height HDD was introduced for the XT.

jmclnx 1mo ago

>Even a scaled-down version of Unix was too demanding for the 8086 chip”. Interesting. At my old job I got my hands on Wang IN/ix around 1985, a 16 bit UNIX. It ran on an 8086 but needed 512k memory. It ran fine. I wonder if memory was the main issue ? But seems the issue was probably memory for IBM and MS

somat 1mo ago
2BSD is still hanging on getting updates and forked projects to this day. My understanding is that it's longevity in the face of the existence of 4bsd is because it is 16-bit clean, These days it is mainly for people who want a unix for their microcontroller. Here is one, https://github.com/RetroBSD/retrobsd https://github.com/RetroBSD/retrobsd. This is for the pic32, so I may be wrong about the 16-bit thing. I don't know if anyone has done it but it looks like it could fit, perhaps not on a original 8086 PC, but perhaps a 286 with 640K.
Narishma 1mo ago
Yes, memory was the main issue. The PC launched with 64KB of RAM. Technically there was a model with 16KB of RAM and no disk drive but I don't think they produced or sold many of those.
- aYsY4dDQ2NrcNzA 1mo ago
  640
  - Narishma 1mo ago
    64, not 640.
    - defrost 1mo ago
      Well, 16 KB - 256 KB, with a directly addressable 64 KB and a segmented architecture to reach further. I had one of these in mid 1982 to late https://en.wikipedia.org/wiki/IBM_Personal_Computer https://en.wikipedia.org/wiki/IBM_Personal_Computer

add2 1mo ago

Unexpectedly, MS-DOS 2.0 included a /dev directory. https://github.com/microsoft/MS-DOS/blob/main/v2.0/source/CONFIG.txt https://github.com/microsoft/MS-DOS/blob/main/v2.0/source/CO...

somat 1mo ago
A lot of early dos development was trying to see how many unix concepts they could fit, directories, pipes, environment, devices.
- mesrik 1mo ago
  And file handles stdin, stdout, stderr same file numbers also. There was and still is overlapping features with Microsoft later and current operating systems. Linked post is quite good and had forgotten completely XEDOS mentioned Byte article.
mesrik 1mo ago
It did, and also up till 3.0 (thus 2.10 and 2.11) had also SWITCHAR which you could change command options character / to - like in it was in UNIX convention, from CONFIG.SYS definition. The problem with changing / to - was, that under MS-DOS command line parsing was left completely to a a loaded program, which then would had to know how to find out this change and act accordingly. And if not only MS-DOS std. utilities behaved properly and others not so much. Thus causing confusion which perhaps then lead to dropping that feature 3.0 onwards. I think it was also before 2.0 or at least what delivered with Apricot PC (UK made PC) 1.25 which I tinkered with few days as we had it on display from Finnish importer ARAIC Rautakirja Oy (Finnish railways VR magazines and other related travel reading importer, also keeper of the R-kiosks). A very nicely built non IBM PC compatible PC with good graphics and then uncommon 3.5" 70kb disk drives before Apple Macintosh made the more popular. https://www.homecomputermuseum.nl/en/collectie/act-computers-ltd/act-apricot-pc/ https://www.homecomputermuseum.nl/en/collectie/act-computers... e: Now did it change also path separator from \ to / ? It may have done it also. I bit later work more with Xenix and can't remember for sure. Starting from 286 versions SvR2.x, 386 SvR3.x up till SCO UNIX SVR4 early 90's and less with MS-DOS besides maintaining couple of TSR's I had written and just checked every MS-DOS release that those still did work.

markus_zhang 1mo ago

I was teaching myself 8086 16-bit assembly a few nights ago on MS-DOS 5.0. It was so much fun getting a color block to display on CGA. Nevertheless, writing system code in assembly was probably going to cause a lot of insomnia and other side effects, especially when Microsoft was far from the domination force on IBM PC.

WalterBright 1mo ago
The easy way to write assembler for a machine with no compilers is to write the code in C, get the algorithm right, then translate it to asm.
- pjmlp 1mo ago
  Or any other compiled language for that matter. :)
  - mesrik 1mo ago
    It is, but some tools like Turbo C did provide asm generating switch (-S AFAIK) directly you to use and saved you from using debug.com or any better disassembler.
    - deleted 1mo ago
      [deleted]
    - pjmlp 1mo ago
      As did many other compiled languages including those predating C, people should stop putting it on pedestal. Fortran 77 manual for UNIX, https://www.unix.com/man_page/v7/1/f77 https://www.unix.com/man_page/v7/1/f77 You can find plenty of other examples, when doing digital archaeology.
      - mesrik 1mo ago
        Sure, it wasn't uncommon feature at all, but many fellows I knew had not noticed it before I suggested using it when a colleague or a friend was wondering how he would write that function assembler and try to make it faster. It tells me more about some people not being curious enough to read documents and explore environment they work than others apparently. Assembler generating was long time a standard feature of compilers simply because writing the assembler code was easier than directly runnable or linkable object code. And for language designer and compiler programmer it was easier to read verifying correct code generating that way. Why bother writing assembly compiler, linker etc. when you usually already had them in the system that time. Then later it changed bit as vendors did not any more ship any or just some crippled compliers to compile just a new kernel with the base system to curb their language competition. Which made third party compilers had to either provide with complete set their own creating executables or ask buyer also licensing system vendor compiler toolkit which they would not otherwise need. That then caused prospect third party compiler customer add that licensing fee top of offering and compared which option they would buy if any. That was time when developement toolkits started changing. Under MS-DOS there never was compiler shipped with it that was a situation all the time, but with the minis and larger systems more what described here above. ps. I think you get much too wound up about C-language. For a long time there was no real alternative use to cross environments compatible way developing thing without major rewrite each platform. That what mattered more than anything else then and in some sense also to some these days also. And no language needs to be put on pedestal like you wrote message you already changed or deleted so that I did not get to answer.

peter_d_sherman 1mo ago

>"But it soon became clear that IBM was committed to keeping DOS 2.0 as close as possible to the eight thousand bytes [8K] used by DOS 1.1, so as not to disrupt their existing user base. [...] The first version of MS-DOS 2.0 shipped with IBM PC XT as PC-DOS 2.0 on March 8, 1983. It required about 20 KB of RAM, far more than MS DOS 1.0, so both versions continued to be sold simultaneously for a while." And that approximate doubling, in RAM requirements, year by year (compare to Moore's Law for hardware!) for Microsoft's OS'es, has got us, fellow students of computer history, to where we are today -- with Microsoft OS'es being the size that they are and requiring the RAM that they do! And it all started with upgrading (or "upgrading", take your pick of term!) an 8KB OS to a 20KB OS! :-)

lproven 1mo ago
"The hope is that the progress in hardware will cure all software ills. However, a critical observer may observe that software manages to outgrow hardware in size and sluggishness." -- Martin Reiser, quoted by Niklaus Wirth
- peter_d_sherman 1mo ago
  Well said, Liam Proven, well said!

EvanAnderson 1mo ago

This is enlightening. Growing up playing with Unix boxes (and XENIX, specifically, mostly writing shell scripts and playing in the filesystem) and programming MS-DOS in assembly I could often see strange parallels between how stuff worked in MS-DOS and his stuff was in Unix. I just assumed MSFT programmers had used Unix at some point and wanted to lift features and idioms from it to use in DOS. It never occurred to me, knowing XENIX was a MSFT-licensed Unic derivative, that there might be more direct inspiration in that vague Unix "flavor" in DOS. I never did any CP/M programming, so the whole FCB-based file manipulation API in MS-dos just seemed like strange old cruft to me. Had I been exposed to CP/M the Unix inspiration behind the handle-based API would have been a lot more apparent. (I got in about the MS-DOS 3.3 timeframe...) What a strange world it would have been in MSFT got IBM to buy into the Unix path separator.

WalterBright 1mo ago
CP/M showed a lot of similarities to DEC's RT-11.
euroderf 1mo ago
> the Unix path separator. Using the backslash: one of those incredibly idiotic things that caused untold misery and time waste further down the road. Future generations cursed the day.
- jlmcgraw 1mo ago
  It sounds like Microsoft _wanted_ to use '/' as the path separator but was forced by IBM to change it at the last minute: https://www.os2museum.com/wp/why-does-windows-really-use-backslash-as-path-separator/ https://www.os2museum.com/wp/why-does-windows-really-use-bac...

pjmlp 1mo ago

Traditional reference how Microsoft was doubling down on UNIX with Xenix, before having a change of heart. The Future of Xenix, Bill Gates Interview on Unix World, back in 1985 https://archive.org/details/Unix_World_Vol02_10.pdf https://archive.org/details/Unix_World_Vol02_10.pdf

walrus01 1mo ago
Xenix was targeted at a hardware spec that was well out of reach for the ordinary home PC consumer. The amount of ram and HDD needed to install and run it would make a computer in 1985/1986 money equivalent to a $12,000 desktop today. They always knew they needed to keep developing DOS for the low end.
- pjmlp 1mo ago
  Sure, but as the article points out, had it not been for the change of heart, Xenix light could have been something like Coherent. Having learnt UNIX on Xenix, I know how expensive it was, we had a single tower that the teacher carried on into class, while we in groups of 2 students had about 15 minutes time slots to try out our applications that we prepared on MS-DOS ahead of time with Turbo C 2.0.

fsiefken 1mo ago

decades later there are fuzix and elks running on 8085 or 8086 respectively: https://www.fuzix.org/downloads/0.4/ https://www.fuzix.org/downloads/0.4/ https://github.com/ghaerr/elks https://github.com/ghaerr/elks

muaaz359 1mo ago

[dead]

RetroTechie 1mo ago

Note that 2 of the features added: a) support for subdirectories, and b) replacing File Control Blocks (FCB) with file handles, are the same as for MSX-DOS: MSX-DOS (1) uses FCBs and a single root directory MSX-DOS (2) also uses file handles and supports subdirectories MSX-DOS (both versions) build on a low-level driver which controls the floppy/hard drive. This came in ROM and included higher-level disk handling (file operations, Disk-BASIC etc). The "DOS" part came on a floppy (MSX-DOS.SYS/COMMAND.COM or MSX-DOS2.SYS/COMMAND2.COM). Yes Microsoft was involved here too. Note that MSX-DOS offered some CP/M compatibility: some programs pulled straight from CP/M (Z80 flavour) could run under it. Some functions deal with CP/M-derived 128-byte "records" (from CP/M floppy formats' sector sizes) rather than byte sizes. But no CP/M disk formats were supported afaik. Other than that, MSX-DOS2 offered some memory management functions for MSX2's memory mapper. Not sure if equivalent functionality was included in MS-DOS 2?