3 ms·

Interesting, clever and beautiful. Now, why did they have to be so defensive against corruption? What purpose does it serve? If I had to detect corruption I wo

by jraph 3y ago

Interesting, clever and beautiful. Now, why did they have to be so defensive against corruption? What purpose does it serve? If I had to detect corruption I would probably use something like CRC, it seems more complete and more robust.

ogurechny 3y ago
Not all modem standards had built-in error detection. If you got garbage or drop outs because of line noise or someone else trying to use the parallel phone, that was all you got. The sending side did know nothing about that. For reliable transfer of binary files, software on both sides had to implement X/Y/Zmodem or some other protocol which added metadata for correctness checks. Files that were cut too soon when copying over the modem or from one floppy to the other, or because the process moving data died for some reason, were also not uncommon. Historical 7 bit protocols were still used. Even though systems of their origin were a thing of the past, and links had 8 bit characters, existing software handling those protocols often mangled the “spare” highest bit for its own reasons. In simple terms, the PNG header allowed to check that the file had always been handled in binary mode, and maybe even to revert some types of the damage. Those were the last days of distinction between terminal-style “text mode” processing (with hardware or software components in the middle silently converting the code pages, line endings, and control codes if they were different on two sides), and “binary mode” direct copying, soon to become the only expected option. People writing binary data to files today almost never invent the means to escape certain “special” values in anticipation of possible transfer over this or over that.
hnfong 3y ago
Reply from a sibling comment of yours: https://news.ycombinator.com/item?id=39246642 https://news.ycombinator.com/item?id=39246642 > A FTP client was set in the wrong mode could easily corrupt everything. When PNG came out that was actually a super common thing that happens. And specifically it would corrupt the newline characters.

by jraph 3y ago

ogurechny 3y ago

Not all modem standards had built-in error detection. If you got garbage or drop outs because of line noise or someone else trying to use the parallel phone, that was all you got. The sending side did know nothing about that. For reliable transfer of binary files, software on both sides had to implement X/Y/Zmodem or some other protocol which added metadata for correctness checks. Files that were cut too soon when copying over the modem or from one floppy to the other, or because the process moving data died for some reason, were also not uncommon. Historical 7 bit protocols were still used. Even though systems of their origin were a thing of the past, and links had 8 bit characters, existing software handling those protocols often mangled the “spare” highest bit for its own reasons. In simple terms, the PNG header allowed to check that the file had always been handled in binary mode, and maybe even to revert some types of the damage. Those were the last days of distinction between terminal-style “text mode” processing (with hardware or software components in the middle silently converting the code pages, line endings, and control codes if they were different on two sides), and “binary mode” direct copying, soon to become the only expected option. People writing binary data to files today almost never invent the means to escape certain “special” values in anticipation of possible transfer over this or over that.

hnfong 3y ago

Reply from a sibling comment of yours: https://news.ycombinator.com/item?id=39246642 https://news.ycombinator.com/item?id=39246642 > A FTP client was set in the wrong mode could easily corrupt everything. When PNG came out that was actually a super common thing that happens. And specifically it would corrupt the newline characters.