are there some special about '\x1a' symbol

[Matthew Woodcraft]

Steve Holden <steve at holdenweb.com> writes:

> Unknown wrote:
>> On 2009-01-12, John Machin <sjmachin at 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-