Steve Holden <st...@holdenweb.com> writes: > Unknown wrote: >> On 2009-01-12, John Machin <sjmac...@lexicon.net> wrote: >> >>> I didn't think your question was stupid. Stupid was (a) CP/M recording >>> file size as number of 128-byte sectors, forcing the use of an in-band >>> EOF marker for text files (b) MS continuing to regard Ctrl-Z as an EOF >>> decades after people stopped writing Ctrl-Z at the end of text files. >> >> I believe that "feature" was inherited by CP/M from DEC OSes >> (RSX-11 or RSTS-11). AFAICT, all of CP/M's file I/O API >> (including the FCB) was lifted almost directly from DEC's >> PDP-11 stuff, which probably copied it from PDP-8 stuff. >> >> Perhaps in the early 60's somebody at DEC had a reason. The >> really interesting thing is that we're still suffering because >> of it 40+ years later. >> > I suspect this is probably a leftover from some paper tape data formats, > when it was easier to detect the end of a file with a sentinel byte than > it was to detect run-off as end of file. It could easily date back to > the PDP-8.
I think it was a reasonable way for CP/M to work. It's a nice simple interface for reading and writing files: you always read and write from/to a fixed 128-byte buffer. Allowing files to be arbitrary-length byte sequences would have made the system calls more complicated, and it would also have needed another byte in the on-disk file control block (so 7.3 filenames rather than 8.3, or some other compromise). For CP/M programs, it's hard to see what the gain would have been; it's easy to design a binary file format so that it doesn't matter whether or not there's junk on the end, and CP/M didn't have a tradition of storing data in 'plain text' files (for good reasons of disk space). It certainly is a shame that we didn't leave all this behind when MS/DOS 2 appeared, though. -M- -- http://mail.python.org/mailman/listinfo/python-list
