A lot of conventions in CP/M are similar to DEC operating systems of that period (RT-11, RSTS/E, etc) For instance in RT-11 files had the same "device:filename.ext" format. However the device spec was 2-3 characters, not just one letter.
One thing I never quite understood: in a home computing context, what is the advantage of having a system like CP/M, compared to, say, using a BASIC interpreter which includes the same commands?
CP/M abstracted IO operations and allowed you to write applications that where machine agnostic. This was a big deal at the time since there were a large number of BASICs that were incompatible for doing low-level operations.
As an example Reddit's /r/retrobattlestations had their annual BASIC week[0] where they take a BASIC program and port it to a bunch of different machines. As you can see they have 11 different versions.
The hardware was not quite standardized at that time so CP/M had a layered structure consisting of a BIOS, BDOS and the command line processor. The BIOS was the hardware abstraction layer and was ported to the specific combination of hardware. The BDOS provided the file system and the command line processor provided a standardized interface. On top of this you would run the BASIC interpreter as an application.
Right, but while BASIC is running, the command line processor isn't. So if you want to run a command... what then? Presumably the BASIC has to reimplement it. I guess that's the point. Having this layered approach is valuable, but having a separate command processor, perhaps less so.
(I never used CP/M but I used to have an Acorn BBC Micro and that had the command line processing built in to the OS, in its equivalent of the BIOS, I suppose to work around this very issue. All an application needed to do was get a string from somewhere, then pass it to the appropriate OS routine. So many programs ended up effectively having the standard command processor embedded, in addition to whatever interface they might themselves support. Though obviously the user had to be careful not to do anything silly like load a new program that overwrote the running program or overwrote their data. Different times.)
12 comments
[ 69.0 ms ] story [ 765 ms ] threadThere may be earlier antecedents as well.
As for Windows, in the NT line you can also refer to drives via \Devices\... when using object paths in Windows API.
Go educate yourself on why mine is God's official temple.
You will eventually stop being in denial.
As an example Reddit's /r/retrobattlestations had their annual BASIC week[0] where they take a BASIC program and port it to a bunch of different machines. As you can see they have 11 different versions.
[0] https://www.reddit.com/r/retrobattlestations/comments/2fn1zq...
(I never used CP/M but I used to have an Acorn BBC Micro and that had the command line processing built in to the OS, in its equivalent of the BIOS, I suppose to work around this very issue. All an application needed to do was get a string from somewhere, then pass it to the appropriate OS routine. So many programs ended up effectively having the standard command processor embedded, in addition to whatever interface they might themselves support. Though obviously the user had to be careful not to do anything silly like load a new program that overwrote the running program or overwrote their data. Different times.)