3 Feb
2008
3 Feb
'08
6:19 a.m.
Date: Sat, 02 Feb 2008 13:07:03 -0500
From: Allison <ajp166 at bellatlantic.net>
Actually PDP-8 OS8 started that, all the other DEC OSs
TOPS-10 and RT had
it as well.
"PIP" should be the giveaway. Odd that ISIS used "COPY xxx TO xxx".
Some hated the mandatory "TO" in ISIS copy, but I thought it was a
good idea. How many times under MS-DOS have you mistakenly typed
"COPY D:*.*" and then hit the "enter" key before completing your
thought? On faster machines, it makes a mess before you can stop it.
The PIP "mathematical" syntax with all the strange options could be
confusing in CP/M; some vendors supplied their own version of a file
copier.
However while the IO was better CP/M had a far better
file system that
accomodated fragmentation (scatter/gather) where RT-11 (and NS* DOS) had
the linear tag and dump that made enlarging a files or creating variable
length files harder.
On the other hand, fragmentation on a floppy can result in very bad
performance--and CP/M had no "defragment" utility. I can see the
advantages of a system that tends to keep files in a small number of
pieces. I've seen the single-piece file structure a lot on
industrial equipment controllers.
Assemble CP/M BDOS at around 100k using ASM
and you find any disk under 400K free space is too small. You still see
that today with faster disks and interfaces.
CP/M was singularly ill-equipped to support hard disks of any size
beyond a couple of megabytes. We'd started offering SA-8000 14"
drives as an option and before too many months, we were getting 40MB
drives for what we'd been paying for the single-platter ones. 5.25"
HD size increases went even more quickly. We bought 7 and 14MB
drives from Rodime and it wasn't long before Rodime was telling us
that they were substituting 10MB and 20MB drives. I was asked if I
could artificially (via software) limit the new drives to 7MB and
14MB so that marketing could charge for the extra storage. I
discouraged the idea very strongly, pointing out that the customers
weren't stupid--someone was going to peek inside and read the drive
nameplate.
CP/M's single-level directory wasn't suited at all to this kind of
thing, even using the "user number" feature--something for which DRI
never came up with a command-line syntax to express, which further
hurt matters.
But then DRI was really thinking of the "user number" feature as that-
-there was the system (user 0) and your own files under your number,
never considering that some users might want to use the feature to
organize their data and go cross-number frequently.
Cheers,
Chuck