10/20版でちょっとした不具合があったので報告ついでにvz常駐の検討をお願いしたところ対応していただけました。
うちで常駐確認したのは次のcommand.comです。
FreeCOMJ 0.82 PL3 VTDOS 対応パッチ ;以前から常駐OK
Windows 98
以下はMSDOS Playerで-v(バージョン指定)が必要です
PC DOS J6.30/V			;-v6.3
PC DOS J7.0/V（PC DOS 2000）	;-v7.0
MS DOS 6.2/V			;-v6.2

私のチェックは甘いのでkonnoさん、皆さん試してください。
タケダ様対応ありがとうございます。

> 10/20版でちょっとした不具合があったので報告ついでにvz常駐の検討をお願いしたところ対応していただけました。

そうだったのですか、ありがとうございます。
更新内容を張りますね。

-----------------------------------------------------------

2024/10/24
INT 21h, AH=0Fh/10h/11h/12h/13h/16h/17h/23h/29hを修正しました。
FCBを使ったサービスで失敗したときに、拡張エラーコードを設定するようにしました。
V6.22のCOMMAND.COMで、DIR実行時にエラーが表示されなくなっています。
INT 21h, AH=4Eh/AX=714Ehを修正しました。
最初のエントリが見つからないときに、適切なエラーコードを返すようにしました。

INT 2Fh, AX=0502hで拡張エラーメッセージを返すようにしました。
パラメータエラーの筈なのですが、COMMAND.COMは拡張エラーを期待しているようです。
INT 2Fh, AX=122Eh, DL=00h/02h/04h/06hで取得するエラーテーブルを追加しました。
ただし全種類共通で、中身の空っぽな単一のテーブルを参照しています。
またDL=01h/03h/05h/07hでエラーテーブルのアドレスを変更できるようにしました。

プロセス起動時のメモリ確保のコードを整理しました。
コンベンショナルメモリが不足の場合、常に自動的にUMBを使用するようにしました。
COMモデルの起動時に、64KBのメモリの空きがないときに失敗するようにしました。
プロセス終了時に、開放するメモリのMCBが壊れている場合に修復するようにしました。

INT 2Fh,AX=4810hのサポートを廃止しました。
DOSKEYの１行入力ですが、従来よりDOSKEYは未インストール扱いとなっています。
Windows 98のCOMMAND.COMがインストールチェック無しに使っていたため、
一応サポートしてましたが、VZの常駐の妨げになっていたため廃止することにしました。

Windows 98のCOMMAND.COM上で、VZを常駐した状態でバッチファイルを実行すると、
バッチファイルから子プロセスを起動するとき、コンベンショナルメモリの空きが
0になってしまう問題が発生しています。
常駐時は、VZ.BAT経由ではなくVZIBMJ.COMを直に起動するようにしてください。
（V6.22のCOMMAND.COMだとそのような問題は発生しないのですが…）

MS-DOS Playerの起動時に、スペース入りのargvを渡された場合、仮想マシンに渡す
コマンドラインにダブルクォーテーションで括って追加するようにしました。

-----------------------------------------------------------

> うちで常駐確認したのは次のcommand.comです。
> FreeCOMJ 0.82 PL3 VTDOS 対応パッチ ;以前から常駐OK
> Windows 98
> 以下はMSDOS Playerで-v(バージョン指定)が必要です
> PC DOS J6.30/V			;-v6.3
> PC DOS J7.0/V（PC DOS 2000）	;-v7.0
> MS DOS 6.2/V			;-v6.2

Win95(v7.00) や Win98ME(v8.00) も出来ますね。MSDOS6.22(v6.22) も出来ました。
DOS5 が無いので誰か試してくれるとありがたいです。
まさか NT 2Fh,AX=4810h がVZ常駐の邪魔をしていたとは思いもしませんでした。(>_<)

私はVZ常駐するとすぐに VMAP を見る癖があって、見てみたら、なんと！

***** Memory Arena Trashed!

と表示されて、umbからメインメモリのエリアが表示されません。
直後のコンソールの表示も何かおかしい気が。表示がダブってる？

meu で見ると、空きメモリが２００以上に分断されて見えます。
zmap を起動したら固まってしまいました。
それ以外は普通に動作しているようです。

武田さんにメールで報告しました。ついでに、#11551 の件も報告しました。
VZはDOS画面を保存していて編集画面などからコマンドラインに降りた時にDOS画面再描画していると思い出したので
MS-DOS Player で何も表示されないのは画面消去しているのかなと思ったのです。
この時非常駐VZではプロンプトが表示されますが、常駐VZではプロンプトも表示されないのも関連があるかも。

> X8MAPでみるとEMSもVZで使ってるけどVMAPは表示なしですね。

この X8MAP ってどこにあるのか検索しても出ませんでした。
仕方ないので VECTOR の一番人気のメモリマップを落としてみたら X8MAP でした。(^^;
これはいいですね、CPUの表示も出来て便利です。

VTDOS 		CPU   :  80286 
MS-DOS Player	CPU   :  [Neko Project]F:M:R=6:7:2   PenPro 以降 + 80x87
DOSVAXJ3	CPU   :  [GenuineIntel]F:M:R=4:0:2      468 以降 + 80x87

DOSVAXJ3 の 468 以降 は 486 でしょうかね。(^^;

> 私も報告してたのですが常駐画面の件は対応されてなかったので先ほど画像添付で再度確認依頼しました。正常、異常画像を比べてvmapの結果に気づいた次第です。

げげ、ダブってしまいましたね。(^^;　でもこれで対応してもらえたらありがたいです。

VZの問題なので、自分でもちょっと見てみました。

SCRNIBM.ASM  1367行目　DOS画面保存？　これを呼ぶ前にDOS画面クリアしているのか？
;--- Get dos/current screen ---
	public	getdosscrn
getdosscrn proc
	call	is_dossilent
	call	getgvseg
	mov	di,dosscrn
	clr	si
	call	getscrn
	ret
getdosscrn endp

SCRNIBM.ASM  1443行目　DOS画面描画？　ここか、この後でDOS画面クリアしているのか？
;--- Put dos/current screen ---
	public	putdosscrn
putdosscrn proc
	call	is_dossilent
	mov	msgon,0
	call	resetfp			; ##155.79
	mov	savef,FALSE
	call	setdosVM
	mov	si,dosscrn
	clr	di
	call	getgvseg
	call	putscrn
IFDEF DOSV
	call	vrefreshscrn		; DOSVでVRAM画面を表示させる？
ENDIF
IFNDEF J31
	call	resetpalette
ENDIF
clrfkey:
	mov	fkeymode,0
pdos9:	ret
putdosscrn endp


MAIN.ASM 1503:	call	getdosscrn
OPEN.ASM 267:	call	getdosscrn

DOS.ASM 267:	call	putdosscrn
MAIN.ASM 1564:	call	putdosscrn
OPEN.ASM 266:	call	putdosscrn


MAIN.ASM 1503:	call	getdosscrn
;--- Enter the editor ---
;<-- CY :out of memory
	public	enter_vz
enter_vz proc				; DOS画面で[Enter]押したときに呼ばれる？
	movseg	ds,ss
	movseg	es,ss
	call	check_vwx
	call	getdosscrn
	call	setdoswindow
	call	setint24
	call	getcurdir

OPEN.ASM 267:	call	getdosscrn
close1:					; 編集画面からコマンドラインに降りた時か？
	call	putdosscrn		; getdosscrn の前に呼んでいるのは何故？
	call	getdosscrn
	call	setcmdwindow
	call	setdoswindow


DOS.ASM 267:	call	putdosscrn
;--- Exec from editor ---
	public	se_command
se_command proc
	tstb	cs:cmdlinef
_ifn z
quit1:	jmp	quit_vz
_endif
	movseg	ds,ss
	call	putdosscrn
・・・・
	call	enter_vz		; この後でこれが呼ばれる？


MAIN.ASM 1564:	call	putdosscrn
;--- Quit editor ---
	public	quit_vz
quit_vz proc
	call	ld_wact
_if z
	call	clrstack		; ##100.09
	mov	gends,INVALID
	test	syssw,SW_INIOPT
  _ifn z
	call	load_iniopt
  _endif
_endif
	movseg	ds,ss
	call	write_logtbl
	call	putdosscrn		; 
	call	setfnckey
	tstb	tsrflag				; 常駐VZか？
	jmpln	z,quit_tsr
	call	setdoskey
	call	setdoscsr
	call	resetfp


こんなところでしょうか、コメントは想像で適当に付けたものです。
私にはこれ以上はわからないです。

> INT 10hでブレークして見てみましたが、DOS画面の復帰云々というよりも、
> [ESC]Eで、黄色いプロンプトを通り過ぎて、直にCOMMAND.COMに行っている感じです。
> その辺のモード遷移の問題のような気がします。

見ていただきありがとうございます。私も VZのソースを弄って VZの挙動を見てみました。
	call	dispprmpt
これをコメントにすると非常駐VZのプロンプトは出なくなりましたが常駐VZでは挙動が変わりませんでした。
どうやら常駐VZのプロンプトは command.com が出しているようです。
つまり常駐VZの場合、ここは通っていないのかも。
それでこんどは putdosscrn をあちこちに入れてみたけどどうも VRAMの内容をゲット出来てないような気がしてきました。
次はその辺を追っかけてみたいんですが、はたして出来るやら。

[ESC]Eの後、非常駐の場合はINT 21h, AH=19hや47hで現在のディレクトリを取得して、
プロンプトを表示する方向に進むのですが、
常駐したVZを呼び出した場合は、INT 21h,AH=50hで現在のプロセスIDを変更したりと、
如何にもVZを終わらせてコマンドプロンプトに戻ろうとしている感じです。

多分、以下のところでcs:cmdlinfの値によってquit_vzに飛んでるのかと。

;--- Exec from editor ---
	public	se_command
se_command proc
	tstb	cs:cmdlinef
_ifn z
quit1:	jmp	quit_vz
_endif

> 多分、以下のところでcs:cmdlinfの値によってquit_vzに飛んでるのかと。

私もそこまでは追っかけました。その先で
	call	putdosscrn
があるので、VRAMのDOS画面復帰してプロンプトも一緒に表示しているのだと思います。
ところが　MS-DOS Player ではそれが表示されないのです。
なので getdosscrn がちゃんとDOS画面を保存出来ているか、保存できてないなら何故なのかを知りたいのです。

> DOS/Vなので、テキストはグラフィック画面に描画されていて、
> VZのDOS画面の退避・復帰もグラフィックVRAMが対象になってるみたいですね。

なるほど、VRAMを見れば何かわかりそうですね。
MS-DOS Player のVRAMは v.com で見ると
VRAM Address       = F800:0000 (Real VRAM)
と出るので、DUMPマクロで見てみたら、編集画面では表示されている文字が見えました。
ところがコマンドラインで見るとVRAMが全部スペースで埋まり初期化かCLS状態になっているようです。
他のDOSエミュではコマンドラインでもVRAMの文字が表示されていました。
どうやらこの違いが原因のようです。

> MS-DOS Playerは、仮想テキストVRAMに書き込まれた内容を、INT 10h, AH=FFhで
> グラフィック画面ではなくコンソールにテキストとして書き込んでいるので、
> そもそも食い合わせが悪いです。

そうなのですか、そのあたりはわからないので自分なりに考えてみました。
DOSは本来コンソールでコマンドを解釈、実行してその結果はコンソールに吐き出されるのですよね。
その文字はVRAMに書き込まれてパソコンの画面に表示されますよね。
つまりコマンドラインにいても画面に文字が表示されている時はVRAMに文字があるはずだと思います。
実際他のDOSエミュではコマンドラインでもVRAMの文字が表示されていました。
ところがMS-DOS Playerではそれがスペースで埋められているのです。
なので、もしかしたら MS-DOS Player ではコマンドが実行された時にVRAMの文字消去しているのではないかと思ったのです。
DOSVではVRAMの文字消去しても、フラッシュだかしないと画面に反映しないそうなので。

MS-DOS Player のソースをちょっと覗いてみたら、VRAMの初期化らしいところはありました。
void clear_scr_buffer(WORD attr)
これはあちこちで呼ばれているようですが、どこがコマンドラインかとか全くわかりませんでした。
全然わかってないので間違っていたらごめんなさいです。

> すみません、本件はギブアップです（苦笑）

VZはコンソール画面が使えるので問題ないです。対応していただいて感謝してます。
常駐VZでコマンドラインに降りた時にプロンプトが見えないのはちょっとだけ不便に感じます。(^^;

今思いついたのですが、VRAMの画面最下行だけ消去しないようにしたらもしかしてプロンプト表示しませんかね。
自分でコンパイル出来れば試したいところですが今の自分は色々頭が回らないもので。
色々対応していただきありがとうございました。

> vz常駐後DOSコマンド実行してvz -zで常駐解除してcls後にvz非常駐起動するとvz -zだけ再描画されますね。

どうも VRAM画面の最下行だけ表示が残っているように見えますね。
MS-DOS Player のソースは x64版はVC++2017でビルド出来るというので、コンパイルしてみたら出来ました。

void clear_scr_buffer(WORD attr)
{
//	for(int y = 0; y < scr_height; y++) {
	for(int y = 0; y <= scr_height; y++) {		//クリア行1行増やしても変わらない？
		for(int x = 0; x < scr_width; x++) {
//			SCR_BUF(y,x).Char.AsciiChar = ' ';	//この2行をコメントにしたら
//			SCR_BUF(y,x).Attributes = attr;		//コマンドと改行は残るようになった
		}
	}
}

このように修正してみました。
クリア行1行増やしたつもりでも変わらないようです。どこか間違っているのかも。
また、2行をコメントにしたらコマンドと改行は残るようになりました。
この辺が関係しているように思われますが、これ以上はわからないです。

> MS-DOS Playerは、仮想テキストVRAMに書き込まれた内容を、INT 10h, AH=FFhで
> グラフィック画面ではなくコンソールにテキストとして書き込んでいるので、

やはりこの辺を解明できないと駄目みたいですね。

> 別件で以下の方が気になったりしてます。
> 内臓コマンドでDEL *.txtすると不明なエラーです．となり実行できないです。
> *が認識されてない？他にもあるかもです。

うちの環境では問題無いようですが、何が違うのでしょうね。

> 変更内容としては、テキストVRAMの読み取り時に、現在表示されているコンソールの内容を返すようにしました。

武田さん、ありがとうございます。
朝は寝ぼけてたので、今別のPCで確認してみました。
MS-DOS Player は B8000h の CGA VRAM領域に書き込んでいるように見えます。
そして、VZは起動時のDOS画面のみ再描画しているように見えます。画面クリアの場合もあるようです。

v.com で見ると 
VRAM Address       = F800:0000 (Real VRAM)
この領域には文字が書き込まれていない（クリアされている？）、VZはここを見ているのではないかと思います。

CHEJ 02 　で謎のCGAモードにすると
VRAM Address       = B800:0000 (Real VRAM)
このモードでは完全にDOS画面を再描画してくれますが、日本語は化けています。

MS-DOS Player が F8000h の VRAM領域に書き込んでくれたら完璧な動作になるような気がします。

USモードでは VRAM が B8000h になると思いますが、
CHEJ US 　で USモードにすると
VRAM Address       = F800:0000 (Real VRAM)
このようになるので、この辺の調整も必要かなと感じます。
確認してもらえたらありがたいです。

v.com でVRAMの判定がエミュ3種で違っているのが気になって、
どう判定しているのか逆汗してみました。
ソーサーでも全部は逆汗できず、SYMDEB でアセンブルした部分を張ります。

2AA1:0145 6A40           PUSH   40                            ;'@' 
2AA1:0147 07             POP    ES 
2AA1:0148 BEA603         MOV    SI,03A6                 ; 09[00]
2AA1:014B 26A04900       MOV    AL,ES:[0049]            ; Video mode
2AA1:014F 32E4           XOR    AH,AH 
2AA1:0151 8904           MOV    [SI],AX                 ; [si]=00xx  vmode
2AA1:0153 26A14A00       MOV    AX,ES:[004A]            ; 桁数
2AA1:0157 894402         MOV    [SI+02],AX              ; [si+2]= column
2AA1:015A 26A08400       MOV    AL,ES:[0084]            ; 行数 line
2AA1:015E 32E4           XOR    AH,AH 
2AA1:0160 40             INC    AX 
2AA1:0161 894404         MOV    [SI+04],AX              ; [si+4]= line+1
2AA1:0164 26A18500       MOV    AX,ES:[0085]            ; font H
2AA1:0168 894406         MOV    [SI+06],AX              ; [si+6]= font H
2AA1:016B 6800B8         PUSH   B800                    ; B800h
2AA1:016E 07             POP    ES                      ; ES=B800h
2AA1:016F 33FF           XOR    DI,DI                   ; DI=0
2AA1:0171 26833DFF       CMP    Word Ptr ES:[DI],-01    ; [B800:0]=ffffh なら ES=A000h
2AA1:0175 7508           JNZ    017F                    ; not FFFF --> 017f jump
2AA1:0177 6800A0         PUSH   A000                    ; A000h
2AA1:017A 07             POP    ES                      ; ES=A000h
2AA1:017B 83440804       ADD    Word Ptr [SI+08],+04    ; [si+8]=[si+8]+04
  017f:
2AA1:017F B4FE           MOV    AH,FE                   ; ah=FEh   擬似テキストバッファ先頭アドレス取得
2AA1:0181 CD10           int    10                      ; int 10h, 擬似テキストバッファ先頭アドレス取得
2AA1:0183 8C440A         MOV    [SI+0A],ES 
2AA1:0186 897C0C         MOV    [SI+0C],DI 
2AA1:0189 8CC0           MOV    AX,ES 
2AA1:018B 3C00           CMP    AL,00 
2AA1:018D 7404           JZ     0193 
2AA1:018F 83440E05       ADD    Word Ptr [SI+0E],+05 

2AA1:0193 BBDC02         MOV    BX,02DC 
2AA1:0196 E83800         CALL   01D1 
2AA1:0199 B8004C         MOV    AX,4C00 
2AA1:019C CD21           INT    21 


これでわかったことは、CGA VRAM B800h の先頭2バイトが 'FF FF' かどうかチェックしてるんですね。
え？　と思って、DOSVAXJ3 のコマンドラインで DUMPマクロで見たら
B800h から 8000h の間が FFh で埋まっていました。

VTDOS は B800h から 00h で埋まってる、というか、ゴミもあるので普通のメモリ領域のようです。

MS-DOS Player は B800h から 1C20h の間が 20h 17h で埋まっていました。
つまり、MS-DOS Player だけ B800h の領域をVRAMとして初期化しているということでしょうか。
これを踏まえて私の理解を纏めると

DOSVAXJ3
VRAM Mode          = APA                        ; B800h == FF FF の時
VRAM Address       = C679:0000 (Virturl VRAM)   ; 仮想VRAM と認識

VTDOS
VRAM Mode          = A/N                        ; B800h != FF FF == 00 00 の時
VRAM Address       = D000:0000 (Real VRAM)      ; リアルVRAM と認識

MS-DOS Player
VRAM Mode          = A/N                        ; B800h != FF FF == 20 17 の時
VRAM Address       = F800:0000 (Real VRAM)      ;リアルVRAM と認識し、B800h が仮想VRAMとなる？

もしもこの考えが合っているとしたら、B800h を FF,FFか 00,00 で初期化すれば うまくいきそうな気がします。
その場合、仮想VRAMは、上のチェックルーチンを見ると、 VGA A000h に設定すれば良さそうに思えます。
VTEXTは画面モードは03で、実際は 70h になっていますが、03 は本来 CGA モードだと思うので
この辺の辻褄をうまく合わせてやればいいのかなと素人考えで思いました。

武田さん、この考えどう思いますでしょうか。

> 私はCHEJは特に使用していませんが、vzはint10h ah=fehで取得した仮想テキストバッファのアドレスの、f8000hを読みに来ているようです。
> 書き込み時も、同じアドレスに書き込んで、int10h ah=ffhで画面に反映してるのではないかと。

私もそう思います。
ところがコマンドラインでは f8000h がスペースで埋まり、b8000h に文字が見えるのです。
DOS画面の保存、復帰のタイミングは VZしかわからないので、VZですり替え出来ないかやってみました。
scrnibm.asm 1483行あたり

getscrn	proc
	pushm	<ds,es>
	mov	es,ax
	mov	ds,dsp.@seg

	push	ax		; ##k 241101  MS-DOS Player
	mov	ax,ds		; ds は
	cmp	ax,0f800h	; VRAM F800h か？
	jnz	mpmod		; 違うならJUMP
	cmp	cs:os_win,7	; MS-DOS Playerか？
	jnz	mpmod		; 違うならJUMP
	mov	ax,0b800h	; CGA VRAM にすり替え  'ｸ^@ｸ'  b8h (00h b8h)
	push	ax		; 'P' 50h
	pop	ds		; ds:si(ソース) --> es:di
mpmod:	pop	ax		;

IFNDEF IBM
cpyscrn:

ここにコメント行を追加して VRAMアドレスのすり替えをしたら保存・復帰が出来ました。＼(^^)／ ﾔｯﾀ-
MS-DOS Player の判定に失敗することが有るので見直して公開したいと思います。
安全対策を2重にしているので問題ないでしょう。
将来 B8000hが変わるとヤバいので、その時は VZ.COMを開いて 'ｸ^@ｸP' を検索してアドレスを書き換えます。(^^;
^@ は実際はヌル文字です。(^^;;

必要があって DIR を取ろうと思ったら、各種DOSエミュでみんな書式が違うんですね。
ちょっと比べてみました。

VTDOS	MSDOS 6.20	DIRは内蔵  LFNのみの表示
2011/02/16  20:35               616 FGAL.DEF
2004/06/21  00:46             3,104 fgaldc_14_8086.log

DOSVAXJ3		内蔵　SFNと LFN両方表示
FGAL     DEF                616 2011-02-16 20:35 FGAL.DEF
FGALDC~1 LOG              3,104 2004-06-21  0:46 fgaldc_14_8086.log

MS-DOS Player	MSDOS 6.20
FGAL     DEF           616 11/02/16   20:35
FGALDC~1 LOG         3,104 04/06/21    0:46

MS-DOS Player	FreeCom 7.00
FGAL     DEF           616  11/02/16 20:35
FGALDC~1 LOG         3,104  04/06/21  0:46

MS-DOS Player	Win95 〜 Win98ME
FGAL     DEF           616  11/02/16  20:35 FGAL.DEF
FGALDC~1 LOG         3,104  04/06/21   0:46 fgaldc_14_8086.log

今回は SFNのみの表示が欲しいので MS-DOS PlayerのDOS6.2かFreeCom かな。
と思ったら、MS-DOS Player + FreeComで dir > file とやったら、改行が 0Ah でした。(>_<)
VTDOSで確認しようとしたら > が効かないし、FreeCom ってやっぱり癖が強いようですね。

> VTDOSってcommand.comを差し替えられたような気がします。
> もし私の記憶が確かなら、MS-DOS Playerと同じ結果が得られるようにできるのでは
> ないかなぁ。

くだけた話かもですが、#11616 で書いています。
> VTDOS	MSDOS 6.20	DIRは内蔵  LFNのみの表示
DIRは VTDOS内蔵のものなのですよね、なので FreeCom の問題かどうか確認するために
> VTDOSで確認しようとしたら > が効かないし、FreeCom ってやっぱり癖が強いようですね。
VTDOSで FreeComを入れたのですが、環境領域が不足して動作が不安定みたいだったのです。
それでリダイレクトが動かなかったので確認できなかったのです。
どなたか確認できる人いませんかね。

> あと、DOSVAXはDOSのエミュレータではなくてマシンのエミュレータだと思い込んで
> いたのですが、これは私の認識が妖しい、ないしはおかしい、かも。

確かにDOSBOXベースでマシンをエミュレートしているので、PCエミュレータとなるでしょうか。
でも最近のは内蔵DOSで直接DOSエミュレート出来るので、DOSエミュというのも間違いではないかと。

対義語は「ネコにちゅ〜る」かな。

> くだけた話かもですが、#11616 で書いています。
> > VTDOS	MSDOS 6.20	DIRは内蔵  LFNのみの表示

どうやら話がすれ違っているらしい。
私、VTDOSの仕様を忘れてしまっているのですが、たしかSHELL指定ができましたよね。
なので、これを指定すればそっちのDIRが使われると思っていました。
そして、これを指定しなかった結果が#11616、と思い込んだわけです。そこで、これ
の指定でcommand.comを他のものに差し替えてみれば、というのが#11618。
だけど、

> DIRは VTDOS内蔵のものなのですよね、なので FreeCom の問題かどうか確認するために

ということは、VTDOSではSHELLを指定しても内蔵DIRが使われる、ということのよう
ですね。

どうも大変失礼しました。

> もはや内容とは関係ないところで暗闘している感が。(^^;

確かに。
お互い、一体何をやってんだか。

> というか、ポケット某 って何ですか、もうわけわかです。

そんなことを言うダーリンには黄色い電気ねずみがでんげきバリバリだっちゃ！
＃でんげきつながりやめろ


USECMDについてなんですが、うちのVTDOS1.22の vtdos.txt には

> USECMD
>   ビルトインコマンドの実行にCMD.EXEを利用します。

しか書いていないんですよ。なので、0と1のどちらがデフォルトなのかもわからない
し、どちらを指定したときにCMD.EXEを使うのかもわからない。ということで、実は

> > 古いXPマシンを引っ張り出してきて、私のところのVTDOSの設定を確認してみたら、
> > USECMD=1がコメントアウトしてあった。ということは、SHELLで指定している
> > command.comを使う、ということだと思う。

これもあてずっぽだったりする。たまたま正解だったようですが。

> > もはや内容とは関係ないところで暗闘している感が。(^^;
> 
> 確かに。
> お互い、一体何をやってんだか。
> 
> > というか、ポケット某 って何ですか、もうわけわかです。
> そんなことを言うダーリンには黄色い電気ねずみがでんげきバリバリだっちゃ！
> ＃でんげきつながりやめろ

黄色い電気ねずみで、とある小さなモンスターが浮かびました。
それで、「○○モン パール」で検索したら色々ダイヤなどもザクザク出てきました。
うーむ、私は全く見てないもので。見てるのは一見不細工な猫のような先生ものとか。(^^;

> USECMDについてなんですが、うちのVTDOS1.22の vtdos.txt には
> > USECMD
> >   ビルトインコマンドの実行にCMD.EXEを利用します。
> しか書いていないんですよ。なので、0と1のどちらがデフォルトなのかもわからない
> し、どちらを指定したときにCMD.EXEを使うのかもわからない。ということで

確かにわかりにくいかもですね、私もそれで勘違いしていた部分はあるかも。(^^;

> > > 古いXPマシンを引っ張り出してきて、私のところのVTDOSの設定を確認してみたら、
> > > USECMD=1がコメントアウトしてあった。ということは、SHELLで指定している
> > > command.comを使う、ということだと思う。
> これもあてずっぽだったりする。たまたま正解だったようですが。

おかげさまで私の勘違いがわかりました。お礼に何かプレゼン