C70:info-cpm (06/05/82)
>From lauren@Ucla-Security Sat Jun 5 00:47:54 1982
Oops. I don't want to be misleading. Simply reducing the block
size down to 256 on a typical CP/M system would have rather
negative effects since the support for accessing the file in
reasonable ways is essentially non-existent. In order to get away
with such a block size, you really have to switch over to a more
complex environment where most disk file management is within the
OS, where uniform buffer management can be enforced.
An unfortunate aspect of CP/M is that every user program must contain
all disk I/O buffer management -- since CP/M has no such functionality
built in. Subjectively, I have found that similar programs running
under MARC and CP/M seem to run faster under MARC -- even given
disk I/O to arbitrary pathnames at various levels in the filesystem
tree. Part of the gain appears to be from the adoption of the Unix
"sync" mechanism for flushing some blocks to disk only when required
by the program (or internal system requirements). On text files,
the use of a single newline character rather than CR/LF (and that inane
^Z business) seems to buy even more efficiency in most cases.
Personally, the single aspect of CP/M that has irked me the most is
the crock of putting ^Z at the end of text files ... SOMETIMES.
Of course, if you HAPPEN to end up on an even sector boundary, you
might not find a ^Z. This single fact has probably caused me the
most headaches in finding a reasonable way to allow CP/M programs
(which often don't seem to care how many files they open or if they
ever bother to close them) to operate reasonably under a "real" OS
(as opposed to a glorified file-"manager"). End of flame.
--Lauren--