探してみたら、こんなものがありました。

> 05665/05668 xxxxxxxx  Emmett           VZBUG(2) サイレントモード関連のバグ
> (15)   97/04/15 10:58

> ■　ＶＺバグ大全（２）：サイレントモード関連のバグ

> （Ａ）サイレントモードでの #k または #y の反復
> 　サイレントモードで、非ブロックモードでの行記憶またはカット（#k、#y）を連
>   続して実行すると、ある特定の点までくると、テキストスタックに格納される文
>   字列の最後が化けることがあります。


これは非ブロックモードの話なので、今回は違うかもしれませんが

> （Ｂ）サイレントモードでの #_
>   どうやらサイレントで実行された #_ は、特定の条件下でカーソル位置ポインタを
>   算出しまちがえるらしい。

> 　このトラブルは、 #_ 直後に #? などで最終行を一度表示してやれば回避するこ
>   とができます。これは #_ 直後でなければ駄目で、#38 のあとでは遅すぎます。
 
> 　　・サイレントでの #_ のあとには #? &s
> 　と習慣づけておくといいでしょう。


どうやらこれが関係ありそうです。
高橋版でもこのバグは潰しきれなかったような気がします。

 [ESC]I @I "I カーソル位置へ挿入" のマクロを

;	#b #_ (ct)?{ #> #m #x }
	#b #_ #? &s (ct)?{ #> #m #x }

このようにするか、&s を取ってしまうと、改善がみられました。

前回と同じ条件で実行して、ファイルサイズが一致するようになりました。
ただし、中身はおかしくなっているようです。
これはおそらく VTDOS の EMS がらみの不具合と思われます。

この実験で、榊原版VZだけは、ファイルサイズが小さくなりました。
ファイル挿入が途中で終わっているのか、それとも？


今まで実験に使用した生ログファイルは

 280,386 wf_log.cgi
 380,844 wf_log130407.cgi
 381,081 wf_log130408.cgi

このうちの 381k のファイルの途中に 380k のファイルを挿入していました。
挿入する 380k のファイルに問題があるのか確認のため、今度は
 280k のファイルの途中に 380k のファイルを挿入する実験をしました。

そうしたら、榊原版以外の VZ は正常に終了しました。
榊原版VZだけは、ファイルサイズが2バイト大きくなりました。
改行が1つよけいに入っていました。

この現象について、野ざらし言#4651 で、めざらさんの発言

> テキストスタックに複写する際に，テキストバッファサイズの境界付近に
> たまたまラインバッファサイズを超える長い行が存在した場合の振る舞い
> （結構レア？）に係ることかもしれないですね。「新発見」かも。

これが関係しているかもしれないと私も思いました。

ただ、MSDOS Player と DOSVAXJ3 では正常に動作しているのが謎なのです。
プラットフォームのメモリ管理とVZの相性で不具合が出ているのではないかと感じるのです。
VTDOSとXP（NTVDM）の共通点は、32ビットのメモリ管理で16ビットのVZを動かしているところ？

前回の書き込みで

> ただ、MSDOS Player と DOSVAXJ3 では正常に動作しているのが謎なのです。
> プラットフォームのメモリ管理とVZの相性で不具合が出ているのではないかと感じるのです。
> VTDOSとXP（NTVDM）の共通点は、32ビットのメモリ管理で16ビットのVZを動かしているところ？

このように書きましたが、32ビットのメモリ管理で、ふと思ったことがあります。
ちょっと前の記事ですが

#10145：MS-DOS Player 12/30版 　投稿者：konno 　 2021/12/31(金) 

> さっそく使ってみましたが、ia32版では、自作のアプリでエラーが出ます。
> 自作アプリとは、turbo basic の古いプログラムで、VGAでないと動きません。
> 
> 実は、今までの MS-DOS Player では、エラーが出て使えませんでした。
> 軟式さんの DOSVAXJ3 では使えていました。
> 
> ia32_x86	数字4桁の入力で、OE+2?? （??は数字によって変わる）エラーで止まる
> ia32_x64	数字4桁の入力で、OE+2?? （??は数字によって変わる）エラーで止まる


MS-DOS Player でも ia32版では16ビットのアプリでエラーが出ます。
なので、今は ia32版は使っていません。
VTDOS も、ia32 を使っているとしたら、ここに共通の問題があるのではないかと感じました。


#10157：turbo basic は VTDOSで動かない 　投稿者：konno 　 2022/01/15

> このプログラムを、VTDOS で動かしてみましたが、動きませんでした。
> エラーログを見てみると、ログが残っていました。
> 
> 2022-01-15 16:28:00 AISYO(17BA) 17CA:0EC8 'Out Byte 0043 34'
> 
> AX=2534 BX=0006 CX=0004 DX=1F10 SI=703A DI=7070 BP=17BA DS=17CA ES=0040 FLAGS=0046
> 
> CS:IP=17CA:0EC8
> 17CA:0EB8 2E F6 06 6E 34 40 75 13 50 E8 6D 27 B0 34 E6 43 
> 17CA:0EC8 EB 00 32 C0 E6 40 EB 00 E6 40 58 CF 50 FB 32 C0 
> 
> SS:SP=17CA:0072
> 17CA:0062 00 00 00 00 40 36 CA 17 46 00 CA 17 10 1F C4 0E 
> 17CA:0072 00 01 7B 03 CA 17 06 02 F6 01 CB 01 00 00 00 00 
> 
> 2022-01-15 16:28:00 AISYO(17BA) 17CA:0EDA 'Out Byte 0043 00'
> 
> AX=0100 BX=0006 CX=0004 DX=1F10 SI=703A DI=7070 BP=17BA DS=17CA ES=0040 FLAGS=0246
> 
> CS:IP=17CA:0EDA
> 17CA:0ECA 32 C0 E6 40 EB 00 E6 40 58 CF 50 FB 32 C0 E6 43 
> 17CA:0EDA FA EB 00 E4 40 8A E0 EB 00 E4 40 86 C4 F7 D8 40 
> 
> SS:SP=17CA:0072
> 17CA:0062 00 00 00 00 40 36 CA 17 46 00 CA 17 CA 17 BA 17 
> 17CA:0072 00 01 7E 03 CA 17 06 02 F6 01 CB 01 00 00 00 00 
> 
> 'Out Byte 0043 34'　と、'Out Byte 0043 00' の２つのエラーがあるみたいです。

このエラーが16ビットメモリ操作の裏技に由来するとしたら？
VZはメモリの裏技をバンバン使っているようですし。
 ia32 のメモリ管理は16ビットアプリの使用には問題があるとか？
メモリの自己書き換えなどを許さない仕様とか？

VTDOS では ia32 は使っていないというのであれば私の思い違いということで。m(__)m

野ざらし言#4654 に書きましたが、ここにも再掲します。

insfile.def を見てみると、ループ中に #B を使っていません。
としきさんが、#B が怪しいとにらんでいるのは正解かもと思い
製品版の [ESC]I マクロを修正してみました。


= esci.def =

製品版の [ESC]I マクロのバグ回避は、#B を使わないこと

*m


8  [ESC]I @I "I カーソル位置へ挿入"
	?. (mr==$80)?{ &m(36) . }
	&m("カーソル位置へファイルを読み込みます")
	n=wn, c=wc,
;	#R
	#R #m					;★ 直接ファイラーへ
:A	(s)?{ &c >A }
	(wc==c)? >Z
	mr=-1,
	&s
	#W &#T(n)
:B	#W &#T(c+1)
	#b #_ (ct)?{ #> #m #x }
;	#b #_ (ct|lh)?{ #> #m }		; #x は不要  T.Tanomura 94/01/05 15:48
:C
;	#y (mb)?{ #W #< #i (ek)?? #B #W >C }
	#y (mb)??>D				;★ ブロックでなければループを抜ける
	#W #< ek[+, #i ek], #W >C		;★ #B を使わない
:D	#C &#T(n)
	#< #i (ek)?? #B
	(wc>c)? >B
 	&d
:Z	&m("")

*


これで、今まで VTDOS153 で異常が出ていたファイルも正常に処理出来ました。
サイレントのままでも、試した全てのVZで問題なく動作しました。

結論として、#B にはバグがあるということですね。
そのバグは、VTDOS や NTVDM で出やすいようだというのが今の状況です。

そういえば、非常駐VZ のコマンドラインで [Enter] で COMMAND.COM を呼び出せたよなぁ
と思ってやってみたら
 
Microsoft(R) MS-DOS(R) Version 6.20
            (C)Copyright Microsoft Corp 1981-1993.

こういう表示が出ます。VZは正常に動いているようです。
ここで、さらに command.com を呼び出してみようとしました。

VTDOS|C:\VZ>command vmap
COMMAND.COMのパスは絶対パスで与えられなければなりません.
つまり, ドライブ文字とそれに続く \ から始める必要があります.
例： C:\FDOS

COMMAND.COMは現在以下のパスを想定しています.
C:\VZ\VMAP
ファイル 'C:\VZ\VMAP' を開くことができません.

FreeCom version 0.82 pl 3 [Mar 13 2013 16:40:42]


こうなりました。あれれれ？
このメッセージは、FreeCom の command.com が出しているんですよね？
そういえば MS-DOS Player の更新時に、実行ファイルのPATHに変更していました。
#10300 で書きましたが

> MSDOS.EXE と同じところに置いて指定して見ましたが VZ常駐起動はしないようです。

よく考えたら、command.com も実行ファイルの一つでしたね。
私は command.com を色々切り替えてテストすることが多いので、実行ファイルのPATHに置いたら駄目ですね。
今回の現象は、私のポカミスが原因だったようです。

お騒がせして申し訳ありませんでした。m(__)m