MS-DOS user experience was extremely similar CP/M. In fact, one could safely say MS-DOS/PC-DOS only existed in the first place as a "quick and dirty" approximation of CP/M. (because IBM and Digital Research could not agree to licensing terms to bring CP/M to the IBM PC)
> one could safely say MS-DOS/PC-DOS only existed in the first place as a "quick and dirty" approximation of CP/M
One could indeed, especially seeing how the original name of the product Microsoft acquired and turned into MS-DOS 1.0 was QDOS, which stood for "Quick and Dirty Operating System" (see https://en.wikipedia.org/wiki/86-DOS)
The story is weirder than not just agreeing to licensing terms. Gary Kildall (of Digital Research) and IBM have wildly conflicting versions of how their meeting went. To the point that I don't think the exact circumstances will ever be clear.
2.0 was also the "breakout" version of MS-DOS that made it win over CP/M.
It did it by introducing features inspired by another Microsoft OS, the Unix for 8080 known as Xenix:
- tree structured directories
- pipes
- output redirection
- DEV directory (mostly hidden as it didn't catch on, afaik)
CP/M felt like it had its roots in the same tree Tops-10 sprung from.
PIP, Peripheral Interchange Program existed in Digital Equipment, PDP series. It was how you glued IO into the card deck and the line printer or tape printer.
MS-DOS might well have been the category-killer 'avoid paying the IPR tax' OS, but they also said "our customers have never seen a Digital equipment PDP minicomputer, or mainframe. Lets do some things differently"
If you have used a very early version of MSDOS, its is not very different. File names are 8+3 characters long with a dot in between, upper and lower case is not distinguished. There are only 5 "built-in" commands: DIR, ERA (erase files), REN (rename, but the syntax is REN NEW=OLD), SAVE, and TYPE.
There are no directories, but "user areas" numbered from 0 to 15, so different users can have different files on the same disk. User areas are selected with the USER command. However, most people used user areas as poor-man's directories.
There is no COPY command. Copying files (and much more) is done with a program named PIP (peripheral interchange program). For instance,
PIP B:=A:*.COM[E]
would copy all files of the type COM from drive A: to drive B: and echo the file names.
What was great about CP/M was that it allowed programs to run on different computers, as long as they were 8080- or Z80-based. It was a thin, but very effective abstraction layer between the hardware and a program.
MSDOS, which was originally based on CP/M, was a step back, really, because everybody tried to program the hardware directly instead of going through the proper interfaces.
> MSDOS, which was originally based on CP/M, was a step back, really, because everybody tried to program the hardware directly instead of going through the proper interfaces.
That wasn't anything to do with the technical characteristics of MS-DOS versus CP/M. It was about the market conditions – for MS-DOS, the vast majority of users were running it on the IBM PC (and later compatible clones), so developers coded to the IBM PC BIOS and direct hardware access. With CP/M, hardware was far more diverse so developers had an incentive not to do that sort of thing.
It was also about speed. For example, going through BIOS for video was slooooow, so most everyone went straight to the hardware, which buggered up anything that wasn't an MDA/CGA/EGA/VGA video adapter or near identical (like those with a NEC 7220...there were one or two). It meant things like the Wyse 700 (high-res mono video adapter) had to have application specific drivers.
In theory, they should have written to MS-DOS API, and then if BIOS video is slow, Microsoft (or OEMs) could have changed the MS-DOS console device driver to use direct hardware access. The problem was, everyone just went straight to the hardware so there was little impetus on anyone to write a faster console device driver for MS-DOS.
Not only that, but CP/M itself has a rather DEC-ish flavor to it. PIP was found on RT-11 and RSTS/E (maybe RSX-11 as well?), and the drive identifier with a colon is also a nod to DEC.
And at the system level, all the MS-DOS system calls in version 1.0 were direct copies of system calls in CP/M. Made it very easy to translate CP/M programs to MS-DOS if you wanted.
The lineage is pretty clear, especially if you're looking at the early DOS versions and the computers it ran on. DOS basically added a few things, and the hardware progressed a lot.
But in the Turbo Pascal 3 era, the differences weren't that high.
"Big" things were:
- no sub-directories
- no relocatable executables (ie. only .COM, no .EXE)
- no common, advanced graphic standard
So if you're running WordStar or TP3 in black-and-white text mode, you might not be able to tell the difference.
If you're thinking of color text modes (TP 5.5, QBASIC, Word 5) or VGA/EGA games when "DOS" is mentioned, then that's the era beyond that.
CP/M was rather similar to MS-DOS / PC-DOS 1.0 – no subdirectories, only a root directory per a disk.
Later versions of CP/M did add one approximation to directories, each disk contained 16 numbered user areas (0-15), you could switch between them by "USER n" command. But, all files existed in the same physical directory, the user area was just a nibble in the directory entry. Files not in the current user area were hidden.
Some versions of CP/M supported password-protecting individual files (and entire disks). If you set a password on a file/disk, the OS would prompt you for the password before allowing you to read/write it. However, there was no encryption, and the passwords were stored using trivial reversible encryption (XOR with a single byte key), so tools existed to retrieve the password.
CP/M file system did not store exact size of files, only how many 128 byte records they contained. Text files used ^Z character as end of file marker. That is why many DOS programs treated ^Z as an end of file marker, even though unlike CP/M it supported storing file sizes to the byte.
Unlike DOS, earlier versions of CP/M did not store file modification times. Later versions added this.
CP/M only supports 7-bit ASCII in file names since high bit of each file name byte is used to store file attributes (read-only, system, etc). The FAT filesystem stores file attributes in a separate byte, enabling use of 8-bit extended ASCII in filenames (diacritics for European languages, etc)
DOS tended to have friendlier commands. COPY vs PIP (Peripheral Interchange Program)
DOS copied a number of features from CP/M - 8.3 file name format, drive letters, similar system calls – Int 21h started out as a subset of CP/M system calls, but later added many more calls which were not CP/M compatible – .COM as an executable file extension, IO.SYS/MSDOS.SYS split (in CP/M called BIOS vs BDOS – the BIOS of IO.SYS is not the same thing as the system firmware BIOS.) DOS added .EXE file format and FAT filesystem. Starting in DOS 2.0, DOS gained subdirectories and a new Unix-inspired file API.
CP/M most commonly was used on 8080/Z80 systems with maximum 64KB address space, with more memory sometimes accessible through bank switching. MS-DOS ran on 8086 which is much more generous with memory. (However, there were versions of CP/M for other CPUs, including 8086 and 68000, although use of those versions was not very common.)
GEMDOS on the Atari ST (68000) was essentially CP/M 68k with some MS-DOS-like modifications (FAT filesystem, subdirectories, some similar syscalls, etc.) Even used the CP/M 68k relocatable executable format. The GPL'd source for both are out there and very obviously related.
IIRC GEMDOS was written more less from scratch by Jason Loveman (last I heard he was at Microsoft). While it's possible he might have cribbed a bunch from the CP/M-68K codebase, it started "in his garage" as a private effort that he hoped he'd be able to sell to someone. DRI wound up acquiring it (I wasn't privy to the terms, I hope Jason got a lot of money, though) and we wound up using it on the ST because absolutely nobody liked CP/M-68K, OMG.
I'll have to check out the sources and see if I get the same impression. It's been a while.
Well, Commodore Basic allowed you to execute Basic code from outside of a program, at the command-line prompt. CP/M wasn't based on Basic, and didn't let you do that. Neither did MS-DOS.
https://en.wikipedia.org/wiki/Digital_Research#CP/M-86_and_D...