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.
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.
Thankfully they ditched it. One of the best things about DOS was that it gave users control over the directory structure. While other OS's just barfed a billions directories all over your disk on install and spewed system files wherever they felt like it, DOS let you decide where you wanted things with the exception of a couple of files in the root directory. This did mean that some people just dumped everything into the root of their system drive, but everyone else could organize things however they wanted. You could learn a lot about someone, and their system, with a single dir command.
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.
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.
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.
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.
As did many other compiled languages, and to stay on the same company, you could do that in Turbo BASIC, Turbo Pascal, Turbo Modula-2 (short lived) and Turbo Prolog (also short lived).
Also generate linker maps with related Assembly content.
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.
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.
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:
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.
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.
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.
I could get the extra 48KB memory for less than IBM charged. More importantly, double sided floppy drives were already on the market but you couldn't get them from IBM at any price.
So I went to a local component supplier and got a pair of double sided drives. They worked "out of the box" in DOS, but unsurprisingly, only side 1 of each drive showed up as A: and B: drives.
So I wrote a TSR to add C: and D: drive letterss which were side 2 of each drive.
It was super easy.
Later I heard about a fancier TSR that combined side 1 and 2 of each drive into a single drive letter with twice the capacity.
But that was a much more complicated task, and I was happy enough with my four-drive-letter solution.
>"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! :-)
Unexpectedly, MS-DOS 2.0 included a /dev directory.
https://github.com/microsoft/MS-DOS/blob/main/v2.0/source/CO...
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...
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.
> under MS-DOS command line parsing was left completely to a a loaded program
And in the many decades and OS rewrites since, they have long since corrected this mistake... right?
Oh my, I'm sorry how many typos I made and forgot to fix.
s/ARAIC/AFAIC/g s/70kb/720kB/g
Thankfully they ditched it. One of the best things about DOS was that it gave users control over the directory structure. While other OS's just barfed a billions directories all over your disk on install and spewed system files wherever they felt like it, DOS let you decide where you wanted things with the exception of a couple of files in the root directory. This did mean that some people just dumped everything into the root of their system drive, but everyone else could organize things however they wanted. You could learn a lot about someone, and their system, with a single dir command.
>gave users control over the directory structure
try making an AUX directory, or CON file, or PRN
A lot of early dos development was trying to see how many unix concepts they could fit, directories, pipes, environment, devices.
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.
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
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.
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.
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.
I agree. Not sure whether that was the case for MS-DOS but I’m sure it was useful.
Gotta find some time to read some of the code to chill.
Or any other compiled language for that matter. :)
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.
As did many other compiled languages, and to stay on the same company, you could do that in Turbo BASIC, Turbo Pascal, Turbo Modula-2 (short lived) and Turbo Prolog (also short lived).
Also generate linker maps with related Assembly content.
People should stop putting C on pedestal.
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.
CP/M showed a lot of similarities to DEC's RT-11.
> 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.
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://www.google.com/search?client=firefox-b-d&q=ST-212+ha...
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.
My dad still called it "Winchester" well into the 80s. I remember when we got our first "Winchester", a 20MB hard drive.
My first hard drive was 6Mb. I had to design/build my own interface board for it, and write the driver for RT-11.
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.
>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
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. 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.
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.
16KB and no floppy drive. That was my first PC!
I could get the extra 48KB memory for less than IBM charged. More importantly, double sided floppy drives were already on the market but you couldn't get them from IBM at any price.
So I went to a local component supplier and got a pair of double sided drives. They worked "out of the box" in DOS, but unsurprisingly, only side 1 of each drive showed up as A: and B: drives.
So I wrote a TSR to add C: and D: drive letterss which were side 2 of each drive.
It was super easy.
Later I heard about a fancier TSR that combined side 1 and 2 of each drive into a single drive letter with twice the capacity.
But that was a much more complicated task, and I was happy enough with my four-drive-letter solution.
640
64, not 640.
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
And it included a cassette interface.
>"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! :-)