改行コード
アプリケーションからハードウェアの詳細を隠蔽するデバイスドライバという概念がまだ発展していなかったため、アプリケーションはテレタイプ端末と直接やりとりをし、テレタイプ端末の慣習に従う必要があったためである。このシステムでは、プリンタヘッドが右端から復帰するのに1文字の時間では間に合わなかった。これがCRが先に送られた理由である。実際には、プリンタヘッドが停止するのを待つためにCR+LF+NUL(最後に「何もしない」という命令を送る)やCR+CR+LF(CRを2度送る)というシーケンスを送らなければいけないこともあった。このようなシステムが消滅してからはCR+LFのような2文字の改行コードは技術的な意味を持たないが、現在も一部のシステムで存続している。
86-DOS(マイクロソフトが買収し、MS-DOSと改名した)がCR+LFを採用したのは、CP/Mの実装を真似たためだと考えられている。更に、CP/MがCR+LFを採用した理由はいくつかの説が考えられている。1つは、CP/MはUNIXをモデルとしていたため、UNIXの著作権を侵害したとしてAT&T/ベル研究所から訴えられる可能性を軽減しようとしたという説、もう1つは、CP/MはRT-11のようなDECオペレーティングシステムをモデルとしており、DECはもともとテレタイプ端末としての使用を想定して設計されていたという説である。
この慣習は、後のWindowsに継承されている。
これらの関数は、「0D 0A(16進)」の使用を要求する通信プロトコルを使ってテキストをやりとりする場合に問題になる。そのようなストリームに対し、printf関数などを使い'\n'を出力すると、Windowsシステムでは期待通り「0D 0A(16進)」が送信されるが、UNIXでは「0A(16進)」しか送信されないため、問題となる。解決策として、バイナリモードを使って目的の数値(0D(16進) 0A(16進))を直接送るとどのような場合も正しく動作する。
Java言語でも'\n'(改行)、'\r'(復帰)の2つのエスケープシーケンスを提供している。言語処理系はこれらのエスケープシーケンスを、それぞれ、16ビットの数値000A(16進)、000D(16進)に変換する。
よく使われるjava.io.PrintStreamクラスのprintメソッドやprintlnメソッド、printfメソッドは、C言語の printf 関数とは異なり、これらの数値を特別扱いせず、環境依存の改行コードに変換しない。ただし、printfメソッドで使われる書式文字列中では「改行」を表現するための特殊な表記として「%n」を使える。printfメソッドはこの部分を実行環境依存の改行コードに置換した文字列を出力する。また、いずれのメソッドでも、出力されるバイト数、バイト順については設定された文字符号化方式に依存する。