4 ms·

> Since CP/M 2.x has no concept of sub-directories It has the notion of user areas. Each file entry has a 4b field tagging the file indicating which user space

> Since CP/M 2.x has no concept of sub-directories It has the notion of user areas. Each file entry has a 4b field tagging the file indicating which user space it belongs to. When you type "DIR" for example, it will filter and show only files for the current user space. There are no protections across user spaces. Typing "USER n" will change the current user space you are in. Although one could use it to allow multiple people to have a file space on one floppy, often it was used by a single user to partition work, eg, USER 0 is utilities, USER 1 is word processing, USER 2 is source code, USER 3 is games. So with a little squinting, it is possible to view CP/M has having 16 subdirectories, but the file system is flat in each subdirectory.

whartung 6y ago
The cold hard truth, however, is that CP/M is kind of awful. Back then you didn't have directories and subdirectories, what you had were floppies and disk drives. These were your file management components. Hard drives were rare, and CP/M was just not very friendly to large disk spaces. User areas had a marginal affect at the time, since they were really considered more apt to their name "User area", as in "separate users", vs a mechanic to actually organize files. Out of the box CP/M had really poor support for user areas. The simple fun fact that the way you shared a command across user areas was to...copy the file in to each user area. Which is easier said than done. The file copy program, PIP, could copy files FROM one user area to another (i.e. pull a file from one user area in to your current one), but not TO another user area. So, in order to copy files in to a user area, you had to have a copy of PIP in that user area. But you can't use PIP to move PIP in the first place. You have to jump through hoops loading PIP into memory with the debugger to span user areas. Later, new shells and utilities supported the idea of A3:FILE.TXT to represent user area 3 on drive A, started becoming common, but not every program supported it, and the stock OS did not support it either. Recall, in CP/M, the programs did most of the heavy lifting for this stuff. It's unjust, honestly, to criticize CP/M looking backward. It managed to empower great things back in the day, which is what microcomputing was all about. Its influence is felt to this day. But that doesn't necessarily mean it was a great place to be.
- teh_klev 6y ago
  CP/M wasn't that terrible. Some of my first paid development work circa 1985 was writing dBase II apps, with WordStar as an editor, on CP/M on a rather nice NEC PC. It did enough to allow small/medium sized businesses to start "computerising" their workflows for not staggering sums of money.

whartung 6y ago

The cold hard truth, however, is that CP/M is kind of awful. Back then you didn't have directories and subdirectories, what you had were floppies and disk drives. These were your file management components. Hard drives were rare, and CP/M was just not very friendly to large disk spaces. User areas had a marginal affect at the time, since they were really considered more apt to their name "User area", as in "separate users", vs a mechanic to actually organize files. Out of the box CP/M had really poor support for user areas. The simple fun fact that the way you shared a command across user areas was to...copy the file in to each user area. Which is easier said than done. The file copy program, PIP, could copy files FROM one user area to another (i.e. pull a file from one user area in to your current one), but not TO another user area. So, in order to copy files in to a user area, you had to have a copy of PIP in that user area. But you can't use PIP to move PIP in the first place. You have to jump through hoops loading PIP into memory with the debugger to span user areas. Later, new shells and utilities supported the idea of A3:FILE.TXT to represent user area 3 on drive A, started becoming common, but not every program supported it, and the stock OS did not support it either. Recall, in CP/M, the programs did most of the heavy lifting for this stuff. It's unjust, honestly, to criticize CP/M looking backward. It managed to empower great things back in the day, which is what microcomputing was all about. Its influence is felt to this day. But that doesn't necessarily mean it was a great place to be.

teh_klev 6y ago
CP/M wasn't that terrible. Some of my first paid development work circa 1985 was writing dBase II apps, with WordStar as an editor, on CP/M on a rather nice NEC PC. It did enough to allow small/medium sized businesses to start "computerising" their workflows for not staggering sums of money.