command.comの内部動作（エディットバッファ等）と画面表示の問題について

質問

昨日、MS-DOSについて質問させていただいたものです。
私が質問の内容を把握していなかったために皆様に多くの御手数をおかけしましたことをお許し下さい。

昨皆様からのご回答を頂く中で私が聞きたいのはどうやらcommand.comの内部動作（エディットバッファ等）と画面表示上の問題についてということが分かりました。昨日は分かったつもりだったのですが、一晩考えたところ、よく分からない点がありまして出来ればそちらにもご回答いただきたく質問させていただけないでしょうか。どうかよろしくお願いします。質問項目は以下の通りです。

１．command.comは現在入力中の文字列のバッファを
　　持たないということなのですがなぜ画面表示が出来て、
　　しかも入力中の文字列を[ENTER]を押せば解析し
　　実行できるのに、バッファはしていないということになるのですか？
　　（直前の[ENTER]キーを押されて実行した文字列を
　　　バッファしているということは分かりました。）
２．また、編集するには入力中の文字列バッファを持って、
　　現在のカーソルの位置を覚えておくという処理が必要ということも
　　分かったのですが、そうするとDOSKEYと入力することで
　　そういったバッファ領域やカーソル位置を認識する領域を初めて
　　確保するということになるのでしょうか？
　　DOSKEYの内部動作っていうのでしょうか？
　　出来ればそういったものを詳しく教えていただけないでしょうか。
３．それらと画面表示はまったく別物なのでしょうか？

自分がよく分かっていないので質問が的を得ていないかもしれませんが
どの問いに対してでも結構です。どうかご回答のほどよろしくお願いいたします。

回答No.3

KojiS · ベストアンサー

１についてですが、入力バッファが編集用バッファとしての機能を持っていないということです。入力バッファとか編集バッファとかいろいろ書いてしまったのでわかりにくくなったようですね。元々command.comは、CP/Mを拡張して unixの shに近づけて使いやすくしたという頃もあり、また、編集するとなると表示することが面倒（プログラムのメモリ最寄り多く必要になる）なので、そういう拡張はしていません。
２については、DOSKEYは command.comを拡張する常駐ソフトです。編集用のバッファ機能を DOSKEYが提供しているという形になります。キー入力を DOSKEYが受け取り、command.comに渡しているという形になっています。
３についてですが、キー入力と画面表示は別物です。入力した物を画面に表示するということも command.comがしています。

command.comは、DOSという言葉からわかるように、あくまでディスクを操作する（アプリケーションの起動も含めて）ための OSと人の操作をやりとりするための物なので、多くの機能を含める必要性が無く、またメモリも少なくてすむように作られています。

お礼

御回答いただき誠にありがとうございます。

なんだか私の中でも整理がついてきたように思います。
直接command.comに入力するためにバッファされた文字列に対して
←キーを押すことは、バッファされた文字列を後ろから順に
飛び越えていくような作り方はされておらず、そうすること
（そのような機能を持たせること）は、本来の目的である
実行サイズを小さく保つという意に反することであり、
DOSKEYは、そのための常駐ソフト（外部にソフトとして持たせることで
本体を軽くするもの）であるということでしょうか？
ただ、そうあるときにcommand.comから行われるという画面表示と
DOSKEYが行った編集を随時、ディスプレイに表示できるというのは
どういうことなのでしょうか？

何度も質問してしまい非常に恐縮で申し訳ないのですが
出来ましたら御回答いただけますようお願いいたします。

回答No.6

marine

#4の補足です。
突然「CP/M」と言う名前が出てビックリされたと思いますが、何故「CP/M」を紹介したかと言うとソースコード（アセンブラ）が公開されているからです。
MS-DOSは商用OSですから、ソースコードを見る事は出来ません。ですから、答えている方も内部動作を推測して答えてるわけです。
command.comの内部動作に興味があり、アセンブラプログラムが分かるのであれば、ソースコードを見た方が早いと思ったからです。

お礼

御回答ありがとうございます。

早速、本屋に行ってみたのですが思うようなものは見当たらず
検索もしてみたのですがちょっと探しかねました。
もし何かご存じでしたら教えていていただけないでしょうか。
宜しくお願いいたします。

回答No.5

KojiS

DOSKEYの位置づけとしては、だいたいそう考えても言いと思います。

DOSKEYが常駐すると、command.comへの入力は DOSKEYが行っており、キー入力や入力中画面表示（ユーザーインターフェース）は、すべて DOSKEY上で行われます。そこで入力されて作られた文字列のみが command.comへ渡されるようになっています。ですので、DOSKEY常駐後の編集中はすべて DOSKEY上で行われ、command.comのキー入力や画面表示は行われていないということです。

お礼

なるほど。
御陰様で分かってきました。

本当にありがとうございました。

回答No.4

marine

難しく考えないで、単なるcommand.comの仕様と思って下さい。MS-DOSの元になったCP/MのCLIが、そういう仕様だったんです。
CP/Mが作られた頃はCRTディスプレイを使ったPCは存在せず、TTY（いわゆるタイプライタ）で接続するマイコンしかなかったんです。だから矢印キーの概念も無いんです。
詳しい内容が知りたければ、「CP/M」で検索するか、大きな図書館で「CP/M」の本を探して読みなさい。私も本を持っていますが物置の奥です。

お礼

「CP/M」を勉強すればいいのですか？
出てくる言葉全てが新たに聞くものばかりで
何を勉強したらいいのかすら分かりませんでした。
CP/Mという言葉も聞いたことすらありませんでした。
そういったことを教えていただき本当にありがたく思います。

御回答いただきありがとうございました。

回答No.2

arika

1,＃１の回答に補足です。
前回の回答をみてはいないのですが、バッファはあります。カーソル移動キーに対する割り付けがもともとなかったので、今の仕様になっていると推測します。（ESCシーケンスで拡張して入力するようになってる）ASCIIコードを知っていれば，バックスペースに関してはコードがありますが、カーソル移動に対してはないです。
もともとタイプライタが基本ですので、カーソル移動して修正という概念がなかったのではないかと思います。
２、３、これは＃１の回答のままです。もっとしりたければ、DOSのシステムコールを勉強してみてください。

お礼

なるほど、そうなんですか。
私が勉強不足のため、せっかく御答え頂いた内容を
半分も理解し切れていないように思います。
御厚意を無にしないようにDOSのシステムコールを
勉強させて頂こうと思います。

御回答いただきまして、誠にありがとうございました。

回答No.1

DrSumire

1、Command.comで実装するべき機能ではないから、仮にそれらの機能を実装するとCommand.comの実行サイズは大きくなっていまい、LowLevelのインターフェースとしては好ましくない。

2、それはコンソール(Keybord、Display)をDOSKEYが横取りをして、コマンド確定後にCommand.comに命令を流しているから。

3、それらはともにCONデバイスを利用しています。

お礼

何を調べたらいいのか少しずつ分かってきました。
さしあたりCONデバイスについて勉強してみます。

御回答していただきまして、誠にありがとうございました。