And on the issue of using the INT instruction, dispatching into a table of kernel routines is very much not new, going back far beyond the EMT instruction to the System/360 SVC instruction.
Given that Paterson has stoutly denied ever looking at any CP/M code (and nobody has ever produced any contradicting evidence), it's clear that in his “quick and dirty operating system”, he took the CP/M user documentation and built something with somewhat the same architecture and user-visible behaviour, using his own code, and tailoring it to the somewhat more powerful 8086. OS designers have been doing this for decades: look at the documentation for Univac and RCA lookalikes for System/360 (available on bitsavers), and compare to DOS/360. Or that “hobby” system written by some guy named Torvalds...
Without bothering to look into old MS-DOS programming books, I remember the COM executable format, and the way some MS-DOS memory buffers related to file handles worked had a compatible layout to ease porting code from CP/M.
> There are subtle differences but PC-DOS is fundamentally the same as the 8-bit version of CP/M as far as the user is concerned, and also as far as the program interface
CP/M has no tree shaped file system. MS-DOS borrows from Unix as much as from CP/M. For instance the ".." directory being parent (in spite of there being no such directory entry), navigated by a "cd" command, and command pipelines separated by | (in spite of there being no multitasking; all done via temporary files under the hood).
Later versions of MS-DOS had a "Xenix" API, inspired and named after Microsoft's Unix flavor.
The term "BIOS" comes from CP/M, referring to the low-level hardware-abstraction layer of CP/M (Basic Input/Output System), the machine-dependent part.
IBM PC family machines put the BIOS into the machine rather than OS image, allowing machine-language programs to take it for granted that they can invoke BIOS routines.
Directory support and hierarchical filesystems were only supported after version 2.0. Until then, the experience was identical to CP/M.
Not that it was that much of an important feature at that time either. With the 360KB size of 5.25" drives, there were only so many files you could put in a disk. Support for hard drives was also introduced later, with version 2.0 and if I remember correctly, support for 3.5" 720KB drives came only with MSDOS 3.20.
I've heard that PC-DOS 1 had no directory support, and got drive letters as a replacement. DOS 2 found this already limiting, and introduced dirs, but the drive letters already existed.
The fact that devices like CON exist (virtually) in every dir is also a consequence of this.
And on the issue of using the INT instruction, dispatching into a table of kernel routines is very much not new, going back far beyond the EMT instruction to the System/360 SVC instruction.
Given that Paterson has stoutly denied ever looking at any CP/M code (and nobody has ever produced any contradicting evidence), it's clear that in his “quick and dirty operating system”, he took the CP/M user documentation and built something with somewhat the same architecture and user-visible behaviour, using his own code, and tailoring it to the somewhat more powerful 8086. OS designers have been doing this for decades: look at the documentation for Univac and RCA lookalikes for System/360 (available on bitsavers), and compare to DOS/360. Or that “hobby” system written by some guy named Torvalds...
Without bothering to look into old MS-DOS programming books, I remember the COM executable format, and the way some MS-DOS memory buffers related to file handles worked had a compatible layout to ease porting code from CP/M.
You probably remember File Control Blocks which are briefly mentioned in the article…
> There are subtle differences but PC-DOS is fundamentally the same as the 8-bit version of CP/M as far as the user is concerned, and also as far as the program interface
CP/M has no tree shaped file system. MS-DOS borrows from Unix as much as from CP/M. For instance the ".." directory being parent (in spite of there being no such directory entry), navigated by a "cd" command, and command pipelines separated by | (in spite of there being no multitasking; all done via temporary files under the hood).
Later versions of MS-DOS had a "Xenix" API, inspired and named after Microsoft's Unix flavor.
The term "BIOS" comes from CP/M, referring to the low-level hardware-abstraction layer of CP/M (Basic Input/Output System), the machine-dependent part.
IBM PC family machines put the BIOS into the machine rather than OS image, allowing machine-language programs to take it for granted that they can invoke BIOS routines.
Directory support and hierarchical filesystems were only supported after version 2.0. Until then, the experience was identical to CP/M.
Not that it was that much of an important feature at that time either. With the 360KB size of 5.25" drives, there were only so many files you could put in a disk. Support for hard drives was also introduced later, with version 2.0 and if I remember correctly, support for 3.5" 720KB drives came only with MSDOS 3.20.
I've heard that PC-DOS 1 had no directory support, and got drive letters as a replacement. DOS 2 found this already limiting, and introduced dirs, but the drive letters already existed.
The fact that devices like CON exist (virtually) in every dir is also a consequence of this.
When I started using PCs, MS-DOS 3.3 was the latest version, and my memory also tells me that directories were introduced in version 2.
This is about DOS 1, which in fact didn't have subdirectories.