Editing XMODEM (section)

==Problems==
Although XMODEM was robust enough for a journalist in 1982 to transmit stories from Pakistan to the United States with an [[Osborne 1]] and [[acoustic coupler]] over poor-quality telephone lines,<ref name="kline198207">{{cite news | url=https://archive.org/stream/kilobaudmagazine-1982-07/Microcomputing_1982_July#page/n43/mode/2up | title=Osborne—Behind Guerrilla Lines | work=Microcomputing | date=July 1982 | access-date=15 February 2016 | author=Kline, David | pages=42–50}}</ref> the protocol had several flaws.

===Minor problems===

XMODEM was written for [[CP/M]] machines, and bears several marks of that [[operating system]]. Notably, files on CP/M were always multiples of 128 bytes, and their end was marked within a block with the <kbd><EOT></kbd> character. These characteristics were transplanted directly into XMODEM. However, other operating systems did not feature either of these peculiarities, and the widespread introduction of [[MS-DOS]] in the early 1980s led to XMODEM having to be updated to notice either a <kbd><EOT></kbd> ''or'' <kbd><EOF></kbd> as the end-of-file marker.

For some time it was suggested{{Weasel inline|date=April 2025}} that sending a <kbd><CAN></kbd> character instead of an <kbd><ACK></kbd> or <kbd><NAK></kbd> should be supported in order to easily abort the transfer from the receiving end. Likewise, a <kbd><CAN></kbd> received in place of the <kbd><SOH></kbd> indicated the sender wished to cancel the transfer. However, this character could be easily "created" via simple noise-related errors of what was meant to be an <kbd><ACK></kbd> or <kbd><NAK></kbd>. A double-<kbd><CAN></kbd> was proposed to avoid this problem, but it is not clear if this was widely implemented.

===Major problems===

XMODEM was designed for simplicity, without much knowledge of other file transfer protocols – which were fairly rare anyway. Due to its simplicity, there were a number of very basic errors that could cause a transfer to fail, or worse, result in an incorrect file which went unnoticed by the protocol. Most of this was due to the use of a simple checksum for error correction,{{r|meeks198902}} which is susceptible to missing errors in the data if ''two'' bits are reversed, which can happen with a suitably short burst of noise. Additionally, similar damage to the header or checksum could lead to a failed transfer in cases where the data itself was undamaged.

Many authors introduced extensions to XMODEM to address these and other problems. Many asked for these extensions to be included as part of a new XMODEM standard. However, Ward Christensen refused to do this, as it was precisely the ''lack'' of these features, and the associated coding needed to support them, which led to XMODEM's widespread use. As he explained:

:It was a quick hack I threw together, very unplanned (like everything I do), to satisfy a personal need to communicate with some other people. ONLY the fact that it was done in 8/77, and that I put it in the public domain immediately, made it become the standard that it is...
:...People who suggest I make SIGNIFICANT changes to the protocol, such as 'full duplex', 'multiple outstanding blocks', 'multiple destinations', etc etc don't understand that the incredible simplicity of the protocol is one of the reasons it survived.