現状のVTDOSを安全に使用する為の設定です。
XMSもEMSもフルで指定した場合、VZは XMS を優先に使用します。XMSを使い切るまで EMSは使われません。
この環境ならまあまあ安定するはずですが、EMSを使用した場合の挙動は保証されません。
メモリ拡張オプションの不具合も、もしかしたら EMSが原因だった可能性もあります。

ということで、今の私のVTDOS.CFG は
TPAEXT=1
TPALOW=1
を復活させました。VZの起動バッチには
$XSET vzsym=NOQ  VTDOS
を仕込み、vz.def には

#if VTDOS	; VTDOS
XM1
EM0
SW1
#endif

こうしてEMSを使わず XMS だけにしてコード領域のスワップを止めました。
vwx.com も EMSを使うので、不安なら起動オプションで、Z1 にすれば良いでしょう。
それでも VMAP では

07D6 <--    1   20944  vwx 1.08b -z1 -v2 -x1 -l6
0E21 <--    1  222080  vzibmj 1.60v -sw2 -z       00 1B 21 29 3F
445A-E7FE   1  670272  <free>

これだけメモリが空いています。余裕ですね。
コンソールやファイラーでEMSを使いたいなら、EM4 は必要です。
ある程度EMSが欲しいなら、EM128 （2M）くらいならほとんど問題ないかと思います。
オリジナルVZでは、#if VTDOS が効かないので、EM128 は残してあります。

としきさんのデータは今まで色々検証してきているので、プロが見れば特定できる可能性があると思います。
みんなで共有できる共通の検証環境として、10＃さんに、としきさんのデータと VZO.DEF を送りました。

 添付ファイルは

2022/03/03 01:00 170,335 0007.cgi	オープンするファイル
2022/03/02 23:04 132,553 0007.cg	[ESC]I で挿入するファイル
2022/03/03 19:11 302,888 0007-i.cgi	正常な結果ファイル（比較用）
2023/03/20 14:45  15,980 vzo.def	オリジナルVZ.DEF  DS+ に変更

まずは、オリジナルのVZ.DEFを、DS+ と変更し、VZO.DEF とします。
DS+ でファイルサイズが表示されるので、比較するまでもなくテキスト破壊がわかります。
オリジナルは、BT64 BL2048 SW3 で、[ESC]I マクロでは内容破壊、サイズが小さくなります。

BL128 〜 2048 の範囲では、VTDOS+EMS環境だけが異常になります。
SW0 BT32 でも異常になりました。


検証手順は

VZ /vzo 　で起動します。(VZは各種VZを任意に指定）

170k の 0007.cgi をオープンする

[ESC]I で132k の 0007.cg を挿入する　ファイルサイズは、302,888 になる
この時点でファイルサイズが違っていたら内容が壊れています。

ファイルサイズが同じなら、^QR でカーソルをテキスト先頭に
302k の比較用 0007-i.cgi をオープンして、[F04] で分割して [Shift][F03] で比較する
「一致しました」というメッセージが出たら、正常です。


この検証で興味深いのは、BL の値で結果が変わることです。
BL128 〜 2048 の範囲では、VTDOS+EMS環境だけが異常になります。　※他のVZ環境では全て正常になる
BL1024*3（3072）のあたりでは、ファイルサイズが変わって致命的なエラー　※VZのバグ
BL1024*8（8192）のあたりでは、CP ズレが起こり、ブロックが入れ替わります。　※VZのバグ

もしかしたら、1か所のルーチンの不具合でこの3つの不具合が起こっている可能性もあるかもです。

今回の問題が見つかったきっかけは、1年前の野ざらし言の書き込みからでした。
関連しそうなツリーや記事のリンクを張っておきたいと思います。

野ざらし言#4609.ファイルの挿入 - としき 22/02/05-18:33 
★　全てはこのツリーから始まった。非常に長いツリーです。


野ざらし言#4700.ファイルの挿入とオプションの値 - としき 22/05/03-22:43
★　非常に長いツリーです。

野ざらし言#4753　 konno
 &t トレースでは ek-, の時 #i の挿入でカーソル位置がズレたように見えたので。

野ざらし言#4784  添付ファイルは　konno
2022/03/03 01:00 170,335 0007.cgi オープンするファイル
2022/03/02 23:04 132,553 0007.cg [ESC]I で挿入するファイル
2022/03/03 19:11 302,888 0007-i.cgi 正常な結果ファイル（比較用）

野ざらし言#4800  行ブロックズレはマクロのせい？　konno
トレースで見ると、3回目の #i のブロックペースト後が問題です。
 Ek- の時カーソル位置更新しますが、その位置が1文字ズレて改行の所になります。
本来なら行頭にくるはずなんですが、1文字ズレることがあるんですね。

野ざらし言#4835　めざら
現象から言えば，確かに #< があることで論理行が入れ替わるということになりますが，不具合の根本的な因子はそこではないと思います。
以前にもちょこと書きましたが，#< にはページングにおける KY (保存されたY位置)を更新する効果があって，ヒトの目線のズレ修正に貢献していると考えているのですが，c.mosさんとしては「美しい動作」というのが脳裏にあって #< を使っていたのではないかと想像しています。（まるきり外してるかも）

野ざらし言#4840　としき
> 異常挿入を起こす0007.cgiの冒頭からの真の最小のファイルサイズ
見つけました。
27932バイトでは異常発生、27931バイトでは正常挿入。

野ざらし言#4892  Blの指定可能な値について　めざら
bl 34452 / pq..148==$776A, pq..149==$FDFE
bl 34453 メモリが足りません.
512バイトの緩衝領域＋2バイトを前方（最上位メモリ）に確保しさえすれば，大きなラインバッファの「確保」は可能。ただし，正常に使用可能かは不明。

野ざらし言#4883　としき
上記の、異常挿入を起こす最小サイズとしては27932バイトなわけですが、元のファイルではその部分はちょうど２バイト文字の真ん中に当たります。なので、２バイト文字の区切りで１文字増やした27933バイトのファイル、これに0007.cgファイルを挿入しようとすると当然、異常挿入になります。この場合、ファイル末尾は「気」という文字です。
ところが、同様に0007.cgiファイルのこの行の「気」の文字の次に改行を入れたファイルを作り、このファイルを開きなおして0007.cgファイルを挿入しても、正常挿入。ところが、そこにさらにもう１バイト、何でもいいけど半角文字を追加して保存して開きなおし、0007.cgファイルを挿入しようとするとそれは見事に異常挿入。
不思議だ、なぜ２バイトずれる。


野ざらし言#4711.ファイル挿入(1) 1.60製品版 - めざら 22/05/07-21:13 
★　非常に長いツリーです。

野ざらし言#4934　なんというか、なかなか面白い結果となりました。　としき
特に面白いと思ったのは、あとから0007.CGファイルを読み込ませるとき、先に開いて
いたファイルのサイズとBlの値によって、きれいに挙動が変化する部分。すなわち、
以下のところですね。
先に開いていた　 Blの値
ファイルのサイズ 8191  8192  8193  
27931バイト　　　正常　正常　異常
27932バイト　　　正常　異常　異常
27933バイト　　　異常　異常　異常
また、Blを16384まで大きくすれば常に正常挿入になるかと思ったけどそうはならない、
という部分もなかなか興味深いところ。

野ざらし言#4995　これの続きを試してみました。　としき
先に開いていた　 Blの値
ファイルのサイズ 8190  8191  8192  8193  8194
27930バイト                        正常  異常
27931バイト　　　      正常　正常　異常
27932バイト　　　      正常　異常　異常
27933バイト　　　正常  異常　異常　異常
27934バイト      異常

野ざらし言#4997] EM の値で [ESC]i の挙動が変わる konno 2022/09/03(Sat) 18:24
何気なく、EM1024 を、EM12 とか小さくしてみたら [ESC]i の症状が良くなったみたいです。
それで、EMの値を変えて色々試してみました。
EM1017 を超えるとNG で、EM1010 ならほとんどのVZ環境で問題改善するようです。
今まで同じVTDOSでも私の環境で [ESC]i の挙動が良くなかった原因が分かった気がします。

★　EM1024-1017=7  16k*7=112k  つまり、XMSは112kでそれ以上はEMSが使われて異常が出たと考えられる
★　EM1024-1010=14 16k*14=224k つまり、XMSは224kでそれ以上はEMSが使われる
★　この時点で、VTDOSのEMSの挙動に気づかなかったのが悔しいです。

　我々（僕以外の我々）が追っていたものとは関係ないだろうと思います。
　ま、しっかし、偉いなぁ、皆さま

　ＳＶＣのログです。

>03472/03472 xxxxxxxx  tanosan          ちょっとしたバグなど（やや長文）
>( 2)   94/01/05 15:48
>
>　◎「カーソル位置へ挿入」マクロで、挿入するファイルの最後の行長が 
>    wd の整数倍で、末尾に改行がないとき（つまり、#_ でジャンプした
>    先が ct==0 && lh!=0 のとき）、その行が読み込まれません。次の修
>    正でＯＫ。
> 
>	#b #_ (ct)?{ #> #m #x }
>         ↓  #x は不要
>	#b #_ (ct|lh)?{ #> #m }

　もちろん偶然です。グレップすらしていません。
　[ESC]I って、ほんと色々あったのねぇ。上村さんのinsfile.defを『強化書』
の頃から（たぶん）、使っているから、えー、そういうのあったんだ、程度の認識
なのですが。

　ただ、filter.defは、似たようなことをしてたわけですよ。

> >　◎「カーソル位置へ挿入」マクロで、挿入するファイルの最後の行長が 
> >    wd の整数倍で、末尾に改行がないとき（つまり、#_ でジャンプした
> >    先が ct==0 && lh!=0 のとき）、その行が読み込まれません。次の修
> >    正でＯＫ。
> > 
> >	#b #_ (ct)?{ #> #m #x }
> >         ↓  #x は不要
> >	#b #_ (ct|lh)?{ #> #m }

こ、これは・・・
確か、[ESC]i マクロの不具合の件で、野ざらし言に書き込んでいたと思います。
「#x は不要」で検索したら、過去ログにありました。
野ざらし言#4612 から、野ざらし言#4617 で 2022/02/13 の発言で

> この元ネタを探してみたんですが見つけられませんでした。
> 私の思い込みで勝手に変えちゃったのかもしれません。
> T.Tanomura さん、不確かなもので名前を挙げてしまいすみませんでした。m(__)m

探せなくて、こう書いていたんですが、SVC でしたか・・・
この会議室は、バグ報告の宝庫ですねぇ、この発言だけでも他に
-------------------------------------------------------------------
　◎FD からの子プロ起動時に !Open がトレースモードに入る現象ですが、
    必ず、!Open の最初のキーワードを実行し、２番目のキーワードの実
    行に入るところでトレースモードになるようです。1.6 の標準 DEF で
    は「?ts=」で止まります。こうした事情から考えられる原因はありま
    せんか？
 
　◎常駐-解放-常駐を行うと、解放したはずの VZ が居座っていることが
    あります（再現条件不明）。これは VZ 側の問題でしょうか、それと
    も用法に問題があるのでしょうか？
 
　　　2536 <--    1   96800  vz 1.60  -em30 -z
　　　3CD9 <--    1    3840  vz 1.60  -em30 -z          06 21 29
　　　3DCA-A000   1  402272  <free>
 
　◎ファイル名入力窓で、すでにファイル名＋スペースを入力した状態で
    ヒストリーをさかのぼると、「->17EE」のようなものまで単独で再現
    されてしまいます。
 
　○ファイル名入力窓のための仕様だと思いますが、カーソルの直前がス
    ペースのとき、文字列ヒストリー中のすべての文字列が再現されてし
    まいます。コマンドラインも文字列入力窓も共通。この動作を、ファ
    イル名入力窓に限定することはむずかしいですか？
 
　○Ds+ で表示される文字コードが、^M で 0D0Ah になります。ちなみに、
    0ah のときは問題ありません。
 
　○^M が[EOF]に‘吸収’されてしまいます。例えば、ファイルを新規に
    開いて「123^M456」と入力しても「123456[EOF]」としか表示されず、
    ファイルには「123456^M」のように順序が狂った形でセーブされてし
    まいます。
-------------------------------------------------------------------
 これだけあるんだもの。(^^;

>  ◎常駐-解放-常駐を行うと、解放したはずの VZ が居座っていることが
>    あります（再現条件不明）。これは VZ 側の問題でしょうか、それと
>    も用法に問題があるのでしょうか？

この現象、最近 MS-DOS Player + FreeCOM 環境で起こっています。VZの版は関係ないかも。
普通、常駐解除すると、プロンプトカーソルがアンダーラインのようになるのに、そうならない時があるのです。
その時に一度 [ESC] を押すと、^[ と出て、常駐解除出来たのかと思いますがもう一度 [ESC] を押すと、VZの入力窓が出るのです。
割り込みベクタの書き戻しとかが上手くいってないのかなぁ。

> 　ただ、filter.defは、似たようなことをしてたわけですよ。

同じかわかりませんが、手持ちの filter.def にはこんなルーチンがありますね。

10:	; overwrite
	(fb)? {
		ek[+,
		#W xc[, #y
		#W #^ #< #i #b #_ #y #^ #<
		#W #b #i r], (r==-1)? #B
		ek],
		(0)

なんだか　[ESC]i マクロによく似ていますね。
#B も使っているし、もしかして xc[, を　r], に戻してその値で #B 使っている？
確か、xc もバグがあったような。
これは怪しいですね。どうでしょ　＞めざらさん

　はい、そうなんです、filter.def。でもね、、、。

http://mezala.la.coocan.jp/vz/notes/vars.html

xc	v1.6		ブロック範囲比較変数
値	カーソル位置(cp)と選択開始位置(tblkp)との比較
-1	cp < tblkp
0	cp == tblkp
1	cp > tblkp

※比較はオフセット値で行われるため，常に正しいというわけではない。
64KBの敷居をまたぐ可能性がある時に正確な比較をするためには，
カーソル位置のロングポインタ（マークで使用）を用いる必要がある。
-------------------------------------------------------------------

　少なくともこれに引っかかったとは思えないんですよねぇ。
　そんなに運は悪くないだろうと。処理対象（範囲）が大きくない、が
より客観的で合理的な根拠ですが。
　64KB。またしてもテキストバッファの限界値。
　セグメントの境界だものね。？？？

　.com ファイルの制限、これも。

vzo.com  57,694  1993-12-06  02:00	;cmos
vz.com   62,184  2018-10-17  19:11	;konno 一杯ま近ですよ。

あらら，実際のファイルで調べもしないで適当なこと言っちゃいました。
すみません．

わたしのファイルだと，急拵えしたこんなマクロで 1600バイトほどと表示されました。
1 ^\ "" ?.
	a-,
	#^ #<
 :l	; ---- main loop ----
	cp[,
	#> r=cp-0],
	(r>a)?a=r,
	#d (r)??>l
	&m("%u",a)
 :z	; ---- exit ----
	&d #] .

うちのラインバッファも 8192 取ってるので，断然余裕ですが。

　awkだとどう書くんだっけ？　と。ちゃんと忘れてました。

--- maxlen.awk ---
{ if (maxlen < length) 		# length()が推奨されているらしい
	maxlen=length 
	}
END { print maxlen }
------------------

C:\>jgawk -f maxlen.awk c:\0etxt\asm\tbook\mast_td.txt
141
　問題まったくないですね。すっかり安全志向。

　ただ、どっかでkonnoさんが、bl の値により、挙動（結果）が違う、
と書かれていたので、それの再検証からいくかな等々、いちおう真剣に
考えてはいます。BL=8192 bytes これには、実用上、問題は何もない
と思っていますが。

　タネをしこんで厨房に立ち、カレーを作り始める（時間がかかる。時間を
かけると美味しい）。そしたら、とらじさんのように、なるへそ、
そう攻めてみるか、とか思いつくのかなぁなんて思ったけど、別に何も
思いつきませんでした。カレー作りに夢中になっただけだった。
　（「どこどこ」開発中の会話より。doko2.defを相当ひさしぶりに動かした。
　　　いえいえ、キーの格納のされ方もすごいです）

　あ、こういうのゴミ発言って言うんでしたよね。

追伸でなく本題：clppst.defの件、発現条件は分かりました。10#さんからの
回答の意味も少しわかりました。多謝＞めざらさん。

xc のバグといえば、あむのさんの対策を思い出します。
CODEX.DEF で検索しましたが、BL2048 だと CODEX.DEFが起動しない！ まいった。(>_<)
BL4096 なら起動できたので、以下に引用します。(^^;

-----------------------------------------------------------
> 06847/06847 xxxxxxxx  あむの           xc にはご注意！
> (15)   97/07/10 07:56  06827へのコメント

　変数 xc にはよく知られたバグがあります。
 
    (1)  32,767 byte の前後にかかる後ブロック（注）で xc の値が 0 となる
        
        ファイル   32767      65536     65K+32767       (byte)
        +------------+----------+--- .... ---+---------- ......
                  ･========*               ･====*
                    blk                     blk
                                        （*印がカーソル位置）
 
        本来ならば xc == 1 。
        
    (2) 文字境界ブロック (mb==2) 限定のバグ
        ・ファイル先頭行にブロックがかかること。
        ・前ブロック（注）であること。
        ・カーソルカラム数がブロック終端のカラム数(wa..51)より小さい。
 
        この場合、xc の値が 0 となる。（本来はxc == -1)
        
        （例）　ファイル先頭
        +-------------------------------+
        |   *===========================|
        |======･    blk                 |
        |                               |
                    （*印がカーソル位置）
        
    （注）  前ブロック      カーソルがブロックの前の場合(xc:-1)
            後ブロック      カーソルがブロックの後の場合(xc:1)
 
　ですから、上記バグの条件にあたらないことが明確ならば、xc は有用です
が、それ以外の場合には使わない方が良いかと思います。
 
            *               *               *
 
　xcの代替手段としては、マーク機能(&#M(n))をブロック前後で使って、その
マークの値を比較するというのが一般的ですが、これまたちょっと問題を孕ん
でいます^^;。
　というのは、純正Ｖｚには、ロング整数を比較する&Lcという関数にも著名
なバグがあって、使えないのです（榊原さん版Ｖｚは修正されています）。
 
　というわけで、自力ですると、例えばこんな↓ふうになります。
　FGALPK Mes13 #02168 94/12/17 y.mikome さん ご紹介の方法に若干手抜き
したものです。
 
=Test
カーソルをブロックの前にする。
マーク＃０  wa+126 (wa..63,wa..64)
マーク＃１  wa+130 (wa..65,wa..66)
* M
89 ^\ ""
    ?.(mb)??.
    #M #B &#M(1) #B p$8000,     ;ブロック前後でマークする（位置は元に）
    (wa..64 > wa..66 || (wa..64 == wa..66 && p+wa..63 > p+wa..65) )?#B
*

ここまで　-----------------------------------------------------------
 
私は xc を使ったこともなく、よくわかっていなかったのですが
今このマクロを見ると、なんとなく読める気がします。（気の精）

＃　読める！　私にも読めるぞぉ！　ララァ

06858番の発言では
-----------------------------------------------------------

　あ、いえ、ブロックのサイズの問題ではないのです。ファイルサイズとブロ
ックの位置の問題なんです。
　百聞は一見に如かず、ということでこの↓マクロを実行して xc の値を確か
めて下さい。
 
=Test
巨大なファイル（例えばログファイル）上で実行して下さい。
* M
80 ^\ ""
    ?.mb0,&d
    &Im(wa+126,0) wa..63=$7FFF,
    #U #< #b #> #d
    &m("xc:%d",xc)
*
 
　また、幸い？なことにバグは xc==0 のときだけのようですから、その時は
実行させず、警告メッセージを出すだけにしても良いかもしれませんね（特に
今回のマクロの場合は、バグでない xc==0 の時も実行させる必要もなさそう
ですから）。

ここまで　-----------------------------------------------------------

これを踏まえて、気が向いたら調べてみたいですね。（無責任モード）

良い知らせと悪い知らせがあります。

10＃さんとのやりとりで私が上手く伝えられなくてどうなることかと思いましたが
再現が出来たと朗報がありました。
それとともに、新たなVZのバグが発覚したようです。

メールの返信の内容を貼り付けます。
-----------------------------------------------------------

>試験をやり直した結果再現しました。

おお、再現出来ましたか、よかったです。

>余談になりますが、僕の試験で把握出来た事をお伝えします。
>まずこの現象はEk+では再現されないようですが、この場合は前回僕がお伝えした結果になります。
>それから、試験をパスした(一致した)状態で窓替え(F2)を行ってすぐ比較を行うと相違が出ます。
>これはMS-DOS上のオリジナル版でも出ます。

試験をパスした(一致した)状態で窓替え(F2)を行ってすぐ比較を行うと相違が出るのですか。
この現象は知りませんでした。やはり検証不足だったようです。

MS-DOS Player や DOSVAXJ3 でも同じ現象になりました。
[F02]の後の比較マクロで6か所文字化けが出ますが、これは VZ のバグだと思われます。

思い当たるルーチンが有るので修正したVZで試してみました。
MS-DOS Player や DOSVAXJ3 では、文字化けが無くなり、正常になりました。
VTDOS では、やはり内容が変わっています。
10＃さんのおかげで、一歩前進出来たみたいです。ありがとうございます。

>この事を踏まえ調査を行うつもりです。

よろしくお願いいたします。
私ももっと検証を進めたいと思います。

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

ということで、調査をしていただけるのはうれしい知らせですが
比較で一致しても直後に[F02]窓替えで再比較すると文字化けが出るという新たなVZのバグが発覚しました。
これは、BL1024 か BL2048 の時だと思われるので、BLの影響で長い行の途中に改行が入るのではないかと想像しました。

過去記事の
#10322：Bl3072 の大穴が塞がったかも 　投稿者：konno 　 2022/10/11(火) 21:59 

> Bl3072 では 3700bytes を超えるところで改行が入っていました。
> ソースに改行を挿入するところがあるはずだと当たりをつけて
> 「,LF」で検索すると、それらしいところが TEXT.ASM にありました。
> 
> fread	proc
> 中略 410行目
> 	cmp	si,di
> 	jne	read3
> 	mov	byte ptr [si-1],LF
>   _break
> read3:	cmp	byte ptr [si-1],LF
> _until e
> 	clz
> 	ret
> read9:	stz
> read_x:	ret
> 
> 
> ここの
> 	mov	byte ptr [si-1],LF
> があやしいと思い、色々試したところ 
> 
> 	cmp	si,di
> 	jne	read3
> 	stc					;★##k 221011 キャリーをセット
> 	jmps	read9x				;★ ゼロフラグをクリアしてリターン
> ;	mov	byte ptr [si-1],LF		;★ Bl3072 の時 3700bytesで強制改行（実行しない）
>   _break
> read3:	cmp	byte ptr [si-1],LF
> _until e
> read9x:	clz					;★ ゼロフラグをクリアしてリターン
> 	ret
> read9:	stz
> read_x:	ret
> 
> 
> このように変更したら、Bl3072 で改行文字化けが無くなりました。

これを思い出し

	cmp	si,di
	jne	read3
	jmps	read9x				;★ ゼロフラグをクリアしてリターンへ
	mov	byte ptr [si-1],LF
  _break
read3:	cmp	byte ptr [si-1],LF
_until e
;	clz
read9x:	clz					; or	sp,sp = zf0 cf0
	ret

このようにシンプルに修正したVZでは、文字化けも無く正常処理出来ました。
今までは余計なところまで弄ってエンバグしていたようです。
正常動作するVZは、だいぶ前に戻ってしまいました。
今まで積み上げてきたものが全部崩れてしまった感じです。(^^;


＃　まるで賽の河原で石積みをしているような・・・　だって私、VZの亡者ですから。