<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-family:"times new roman",serif;font-size:large"><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Sep 18, 2023 at 7:08 PM Dan Cross <<a href="mailto:crossd@gmail.com">crossd@gmail.com</a>> wrote:</div><div dir="ltr" class="gmail_attr"><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">but there was no total byte<br>
count, so it was assumed that the final block would be padded with a<br>
throwaway character.<br></blockquote><div><br></div><div class="gmail_default" style="font-family:"times new roman",serif;font-size:large">CP/M, like RT-11 and OS/8 before it, did not track the sizes of files in bytes or words, only in blocks.  Text files ended in ^Z and were then padded with either NULs or more ^Zs if necessary; binary files were usually padded with NULs.</div><div class="gmail_default" style="font-family:"times new roman",serif;font-size:large"><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
ZMODEM was, as I understood it, designed for transfers across telenet,<br>
which was pretty reliable; instead of the highly synchronous<br>
send/wait-for-ack cycle of xmodem and ymodem, zmodem relies on error<br>
detection and correction and is basically a streaming protocol: a<br>
packet in a sliding window could be NAK'ed, thus rewinding the<br>
transfer, but otherwise it basically just sends data until done.<br></blockquote><div><br></div><div class="gmail_default" style="font-family:"times new roman",serif;font-size:large">It's an analogue of TCP/IP, in fact.</div></div></div>