In CP/M, how does control-Z (hex 1a decimal 26) not interfere with ordinary file storage?












2














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 controlZ at end of file a hard rule across CP/M - i.e. do all files have this as an end of file marker?



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










share|improve this question
























  • 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
    33 mins ago












  • CP/M is very, very simple. Logic typically went in the transient programs.
    – Thorbjørn Ravn Andersen
    3 mins ago
















2














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 controlZ at end of file a hard rule across CP/M - i.e. do all files have this as an end of file marker?



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










share|improve this question
























  • 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
    33 mins ago












  • CP/M is very, very simple. Logic typically went in the transient programs.
    – Thorbjørn Ravn Andersen
    3 mins ago














2












2








2







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 controlZ at end of file a hard rule across CP/M - i.e. do all files have this as an end of file marker?



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










share|improve this question















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 controlZ at end of file a hard rule across CP/M - i.e. do all files have this as an end of file marker?



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







cp-m






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited 2 hours ago







Duke Dougal

















asked 3 hours ago









Duke DougalDuke Dougal

1364




1364












  • 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
    33 mins ago












  • CP/M is very, very simple. Logic typically went in the transient programs.
    – Thorbjørn Ravn Andersen
    3 mins ago


















  • 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
    33 mins ago












  • CP/M is very, very simple. Logic typically went in the transient programs.
    – Thorbjørn Ravn Andersen
    3 mins ago
















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
33 mins ago






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
33 mins ago














CP/M is very, very simple. Logic typically went in the transient programs.
– Thorbjørn Ravn Andersen
3 mins ago




CP/M is very, very simple. Logic typically went in the transient programs.
– Thorbjørn Ravn Andersen
3 mins ago










2 Answers
2






active

oldest

votes


















4















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) special. 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. So it's 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 on 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 meta data (directory extend). Length was only noted as number of 128 byte records of the last extend. On DOS level read and write operation where always record based i.e. in 128 byte chunks (*1). While there was a function to calculate file size, it did as well only work with 128 byte granuality.



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



CP/M 3.0 utilized a prior unused directory extend 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 on byte level, still the 128 byte record granuality was to be observed.






share|improve this answer























  • 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
    2 hours ago










  • 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
    2 hours ago





















1














To highlight what @Raffzahn said, the ^Z part is part and partial 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.






share|improve this answer





















    Your Answer








    StackExchange.ready(function() {
    var channelOptions = {
    tags: "".split(" "),
    id: "648"
    };
    initTagRenderer("".split(" "), "".split(" "), channelOptions);

    StackExchange.using("externalEditor", function() {
    // Have to fire editor after snippets, if snippets enabled
    if (StackExchange.settings.snippets.snippetsEnabled) {
    StackExchange.using("snippets", function() {
    createEditor();
    });
    }
    else {
    createEditor();
    }
    });

    function createEditor() {
    StackExchange.prepareEditor({
    heartbeatType: 'answer',
    autoActivateHeartbeat: false,
    convertImagesToLinks: false,
    noModals: true,
    showLowRepImageUploadWarning: true,
    reputationToPostImages: null,
    bindNavPrevention: true,
    postfix: "",
    imageUploader: {
    brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
    contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
    allowUrls: true
    },
    noCode: true, onDemand: true,
    discardSelector: ".discard-answer"
    ,immediatelyShowMarkdownHelp:true
    });


    }
    });














    draft saved

    draft discarded


















    StackExchange.ready(
    function () {
    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fretrocomputing.stackexchange.com%2fquestions%2f8719%2fin-cp-m-how-does-control-z-hex-1a-decimal-26-not-interfere-with-ordinary-file%23new-answer', 'question_page');
    }
    );

    Post as a guest















    Required, but never shown

























    2 Answers
    2






    active

    oldest

    votes








    2 Answers
    2






    active

    oldest

    votes









    active

    oldest

    votes






    active

    oldest

    votes









    4















    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) special. 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. So it's 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 on 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 meta data (directory extend). Length was only noted as number of 128 byte records of the last extend. On DOS level read and write operation where always record based i.e. in 128 byte chunks (*1). While there was a function to calculate file size, it did as well only work with 128 byte granuality.



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



    CP/M 3.0 utilized a prior unused directory extend 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 on byte level, still the 128 byte record granuality was to be observed.






    share|improve this answer























    • 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
      2 hours ago










    • 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
      2 hours ago


















    4















    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) special. 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. So it's 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 on 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 meta data (directory extend). Length was only noted as number of 128 byte records of the last extend. On DOS level read and write operation where always record based i.e. in 128 byte chunks (*1). While there was a function to calculate file size, it did as well only work with 128 byte granuality.



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



    CP/M 3.0 utilized a prior unused directory extend 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 on byte level, still the 128 byte record granuality was to be observed.






    share|improve this answer























    • 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
      2 hours ago










    • 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
      2 hours ago
















    4












    4








    4







    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) special. 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. So it's 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 on 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 meta data (directory extend). Length was only noted as number of 128 byte records of the last extend. On DOS level read and write operation where always record based i.e. in 128 byte chunks (*1). While there was a function to calculate file size, it did as well only work with 128 byte granuality.



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



    CP/M 3.0 utilized a prior unused directory extend 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 on byte level, still the 128 byte record granuality was to be observed.






    share|improve this answer















    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) special. 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. So it's 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 on 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 meta data (directory extend). Length was only noted as number of 128 byte records of the last extend. On DOS level read and write operation where always record based i.e. in 128 byte chunks (*1). While there was a function to calculate file size, it did as well only work with 128 byte granuality.



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



    CP/M 3.0 utilized a prior unused directory extend 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 on byte level, still the 128 byte record granuality was to be observed.







    share|improve this answer














    share|improve this answer



    share|improve this answer








    edited 2 hours ago

























    answered 2 hours ago









    RaffzahnRaffzahn

    46.4k5104188




    46.4k5104188












    • 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
      2 hours ago










    • 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
      2 hours ago




















    • 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
      2 hours ago










    • 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
      2 hours ago


















    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
    2 hours ago




    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
    2 hours ago












    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
    2 hours ago






    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
    2 hours ago













    1














    To highlight what @Raffzahn said, the ^Z part is part and partial 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.






    share|improve this answer


























      1














      To highlight what @Raffzahn said, the ^Z part is part and partial 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.






      share|improve this answer
























        1












        1








        1






        To highlight what @Raffzahn said, the ^Z part is part and partial 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.






        share|improve this answer












        To highlight what @Raffzahn said, the ^Z part is part and partial 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.







        share|improve this answer












        share|improve this answer



        share|improve this answer










        answered 2 hours ago









        Will HartungWill Hartung

        3,763821




        3,763821






























            draft saved

            draft discarded




















































            Thanks for contributing an answer to Retrocomputing Stack Exchange!


            • Please be sure to answer the question. Provide details and share your research!

            But avoid



            • Asking for help, clarification, or responding to other answers.

            • Making statements based on opinion; back them up with references or personal experience.


            To learn more, see our tips on writing great answers.




            draft saved


            draft discarded














            StackExchange.ready(
            function () {
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fretrocomputing.stackexchange.com%2fquestions%2f8719%2fin-cp-m-how-does-control-z-hex-1a-decimal-26-not-interfere-with-ordinary-file%23new-answer', 'question_page');
            }
            );

            Post as a guest















            Required, but never shown





















































            Required, but never shown














            Required, but never shown












            Required, but never shown







            Required, but never shown

































            Required, but never shown














            Required, but never shown












            Required, but never shown







            Required, but never shown







            Popular posts from this blog

            數位音樂下載

            When can things happen in Etherscan, such as the picture below?

            格利澤436b