14

Consider this - I have made a file called test.bin on a Windows machine. It is exactly 256 bytes long, and contains nothing more than 00 to ff in each byte.

What would happen if I transferred this file to a CP/M system? (in fact this is exactly what I am trying to do).

Since the CP/M end of file marker is control-Z or 1A in hex, will CP/M think that my 256 byte file stops when it gets to byte 1A?

I would have thought that hex 1A can appear all over the place in binary files such as executable COM files. How is it that CP/M uses this for an end of file marker without constantly truncating files early?

Is usage of control-Z at end of file a hard rule across CP/M - i.e. do all files have this as an end of file marker?

Is control-Z actually enforced by the operating system in any way, or is it simply a convention?

Improve this question
8
  • To highlight what @Raffzahn said, the ^Z part is part and parcel to TEXT files. Binary files had to deal with the file size issue differently, since you can't rely on ^Z not being in the data. <!----->
    – Will Hartung
    Jan 11, 2019 at 1:01
  • 1
    I'm pretty sure ^z only counted as a special character to the file system if a file name ends in ".txt". Otherwise files are considered binary and the file system has no interest regarding their actual content.
    – RichF
    Jan 11, 2019 at 3:03
  • 2
    Windows and MS-DOS is stopping too ... its just a matter of type of file access you can open file as text or as binary ... the text files access type interprets certain control codes (or escape codes) as commands and many text and file related routines adherse them ... for example that is why if you print/list binary file as text you hear sometimes the beeps, sometimes its cut down premature etc ...
    – Spektre
    Jan 11, 2019 at 9:14
  • 2
    @RichF CP/M, with the exception of executables, did not "understand" filename extensions - i.e., nothing magic about .txt (or .dat or .dbf etc.). ^Z was treated special in any program that used a file as "text" rather than "binary". But the file extension had nothing to do with it, except to assist lowly humans in identifying files.
    – manassehkatz-Moving 2 Codidact
    Jan 11, 2019 at 15:12
  • 1
    @manassehkatz Thank you for the correction of my misconception.
    – RichF
    Jan 11, 2019 at 17:09

1 Answer 1

Reset to default
21

What would happen if I transferred this file to a CP/M system?

Depends on your transfer utility and how it handles the data presented.

Since the CP/M end of file marker is control Z or 1A in hex, will CP/M think that my 256 byte file stops when it gets to byte 1A?

No, at least not the OS itself. CP/M does not handle CTRL-Z (or any content) specially. Your file transfer utility may do so.

Is controlZ actually enforced by the operating system in any way, or is it simply a convention?

No, it doesn't enforce anything. So it is a convention among text-based utilities.

How do I know when I have got to the end of the end of an executable file?

(from a comment)

You don't. At least not at byte level. Loading an executable is always done up to the next 128 byte record.

The long read

CP/M, up to and including 2.2 did not maintain a bytewise file length in its metadata (directory extent). Length was only noted as the number of 128 byte records of the last extent. At DOS level read and write operation were always record based i.e. in 128 byte chunks (*1). While there was a function to calculate file size, it only worked with 128 byte granularity.

To allow termination of a file holding ASCII data, CTRL-Z was used as an end marker within the last record. All text oriented utilities followed that scheme. But there is no hard provision.

CP/M 3.0 utilized a previously unused directory extent byte to note the bytes used within the last record. For compatibility a value of 128 is noted as zero.

*1 - Random access could operate at byte level, but the 128-byte record granularity was still to be observed.

Improve this answer
5
  • Interesting. Looks like I am using CP/M 2.2 - does 2.2 actually save the exact file length somehow, even for binary files? How do I know when I have got to the end of the end of an executable file?
    – Duke Dougal
    Jan 11, 2019 at 0:46
  • Sorry, I had the 2.2 part wrong, it wasn't until 3.0 that an exact file length was introduced. I also added further information to the answer.
    – Raffzahn
    Jan 11, 2019 at 1:22
  • The same misconception is also false about MS/PC/DR-DOS. jdebp.uk./FGA/dos-character-26-is-not-special.html
    – JdeBP
    Jan 11, 2019 at 19:21
  • @JdeBP For MS-DOS it's more of a compatibility addition toward CP/M to make CTRL-Z work alike on the command line. After all, File length was now maintained on byte level.
    – Raffzahn
    Jan 11, 2019 at 19:35
  • PIP knows about Ctrl-Z being EOF (See option O) and MSDOS has binary options on the copy command (for copy a.txt+b.txt c.txt)
    – PeterI
    Jan 12, 2019 at 1:14

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .