野ざらし言#5053 に書いた記事ですが転載します。


[ESC]I のバグがVZ1.57a で出ないので、ソースを見比べていました。
そうしたら、気になる箇所があったので、Vn のマーカーを入れてみました。

 text.asm 1.57a 1484行目

seekb_x:
	pushf
	add	ax,[bp].ttop		; ##1.5
	popf
	call	qclose


text.asm 1.6k07t01 1884行目

seekb_x:
	pushf
	add	ax,[bp].ttop		; ##1.5
	cmp	ax,[bp].tend
_if ae
	mov	ax,[bp].tend
	dec	ax
	mov	byte ptr [bp].atrtxt1,1 ;★; Vnマーカー追加
_endif
	popf
	call	qclose


VTDOSの結果は、Bl2048 では NG で、Vn0 反応なし
念のため、Bl8192 を試したら NG で、Vn1 反応あり

おお、と思ってここのルーチンを 1.5 と同じにしてみたら
なんと、VZ1.6では Bl8192 は全て NG だったのが OK になりました！！
MS-DOS Player や DOSVAXJ3 では、Bl1024〜Bl8192 OK
VTDOS では、Bl4096〜Bl8192 OK

ただし、Bl1024*3 だけは、1.57a を含む全てのVZ、環境で誤動作します。
正常時に比べてファイルサイズが大きくなるし、VZが壊れる可能性も。
VTDOS では 'REP MOVSW 命令ラップアラウンド' エラーでVZが落ちます。
これは別のバグ発見か？

現在色々検証中です。

＃　シン・ゴジラのエネルギー源を突き止めたくらいに興奮しました！！

検証用にWinMEノートが使えないか、腐海をあさって見ました。
ほとんどのノートPCは液晶が駄目になっていましたが Libretto が起動できました。
仕様は下記のサイトから
https://dynabook.com/pc/catalog/libretto/010507l1/spec.htm

> Libretto L1/060TNCMモデル
> Transmeta Crusoe プロセッサ　TM5600 600MHz
> メモリ 	標準/最大 	128MB／256MB（PC100対応、SDRAMうち16MBはシステムで使用）
> 内部ディスプレイ 	10型FLサイドライト付き低温ポリシリコンワイドTFT液晶（※1）1,280×600ドット：1,677万色
> ハードディスク	 	10GB（Ultra ATA対応　全領域がFAT32で設定（Cドライブ1パーティションで設定）。
> 外形寸法(突起部含まず) 	268mm(幅)×167.2mm(奥行)×20.5(最薄部)/29.3mm(高さ)
> 質量 	約1.1Kg（バッテリパック装着時）

さらに、Wikipediaから
> Libretto L1
>     2001年5月18日発売。技術の粋を集めた旧シリーズとは異なり「実用的で低価格なモバイルノート」を標榜。
>     当時としては珍しい「ワイドSXGA」横1280ドット×縦600ドットの10インチ低温ポリシリコンTFT液晶を採用。
>     Windows XPの発売を控えていた事もありWindows Meをプリインストールした。

IBMのWin2000ノートが液晶の四隅が滲んでいるのに、Libretto は綺麗なままです。
最初はハードディスクが回らなかったので、叩いたら回るようになりました。
ファンの音が煩くて使わなくなっていたんですが、まだまだ使えそうです。


さて、本題ですが、検証の結果は、MS-DOS PlayerやDOSVAXJ3 と同じでした。
以上。(^^;

c.mosさんが1.6でルーチンを追加したからには何か意味があるはずです。
結果的にバグが出たのはルーチンが不完全だったのかも。
私にはまったくわからないですが、ADD 命令でオーバーフローの可能性は考えられます。
その対策の追加ルーチンだとしたら、違和感を感じますね。

普通は ADC とか、JC で分岐させるのにそれをしない理由はわかりませんが
とりあえず JNC 追加で1.6のルーチンを復活させてみました。

Vn のマーカーも入れましたが、NGファイルのテストでも Vn に引っ掛かりません。
なので、オーバーフローしたらマクロトレース状態で止まるルーチンも追加しました。

seekb_x:
	pushf
	add	ax,[bp].ttop		; ##1.57
	jnc	seekb_9			;##k 220923 Bl8192対策？
	add	byte ptr [bp].atrtxt1,1 ;★;; オーバーフローなら Vn1+
	cmp	ax,[bp].tend		;##1.6 ttopとtendアドレスを比較
_if ae					;　ttopが上だったら
	mov	ax,[bp].tend		;　ax(ttop)にtendを代入
	dec	ax			;　アドレスを一つずらす
	add	byte ptr [bp].atrtxt1,10 ;★;; 1.6の修正ルーチン実行で Vn10+
_endif					;
	push	ax				;★トレースONルーチン
	mov	al,1				;
	xchg	cs:stopf,al			;トレースモードに
	pop	ax				;
seekb_9:				;
	popf
	call	qclose
	popm	<di,si,cx,bx>
	ret
seektext endp


この状態でVZを普通に使ってみて様子をみています。
今のところ引っ掛かりませんがね。

ちなみに、このルーチンを公開版 VZk07t01 に追加すると常駐で動かないの。(;_;)
私の私家版常用環境では動くのに。(^^;
やれやれ、どうしたものか。

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 で改行文字化けが無くなりました。
大穴と思っていたところが塞がったのです。
もちろんこの変更で他の所に穴が開いた可能性もあります。
しばらく Bl3072 で運用してみようと思います。


あと、CORE.ASM の 276行目

endlin	proc
	pushm	<cx,di,es>
	movseg	es,ds
	mov	di,si
;	mov	cx,-1			;★ VTDOS でラップアラウンドエラーの原因？
	mov	cx,3000h		;★##k 221009 ラインバッファ＋アルファ
	mov	al,LF
  repne	scasb

このようにしたら、Bl3072 で起きていた VTDOS でのラップアラウンドエラーが無くなりました。
ここが原因だったのでしょうか？


これで Bl8192 と Bl3072 の蟲の居所がわかりましたが
まだ他にもポインタズレという蟲が残っているようです。

 0007.CGI (170335bytes) を後ろから削っていって
 66882bytes にしたテストファイル
 66882.CGI (66882bytes) に
 0007.CG (132553bytes) を挿入するテストでは
ポインタズレによる行の入れ替えが起こっています。
今回の修正で、他のVZよりは改善したようですが。


＃　深淵の大穴は無限に続くのか？

間違った情報を揚げてしまいました。m(__)m


> これで Bl8192 と Bl3072 の蟲の居所がわかりましたが
> まだ他にもポインタズレという蟲が残っているようです。
> 
>  0007.CGI (170335bytes) を後ろから削っていって
>  66882bytes にしたテストファイル
>  66882.CGI (66882bytes) に
>  0007.CG (132553bytes) を挿入するテストでは
> ポインタズレによる行の入れ替えが起こっています。

このテストファイル、作成時点で間違えて行が入れ替わっていました。(>_<)
ズレて蟲が湧いていたのは私の頭でした。(;_;)
このテストファイルのことは忘れてください。m(__)m

結論を言うと、ポインタズレも無くなっていました。
[ESC]i 関連のバグは全て無くなったように見えます。

> あと、CORE.ASM の 276行目
> 
> endlin	proc
> 	pushm	<cx,di,es>
> 	movseg	es,ds
> 	mov	di,si
> ;	mov	cx,-1			;★ VTDOS でラップアラウンドエラーの原因？
> 	mov	cx,3000h		;★##k 221009 ラインバッファ＋アルファ
> 	mov	al,LF
>   repne	scasb
> 
> このようにしたら、Bl3072 で起きていた VTDOS でのラップアラウンドエラーが無くなりました。

このルーチンも元に戻しても問題無くなりました。
バグのせいでエラーになっていたようです。（VTDOSのチェック凄い！）
他の環境ではたまたま問題が顕在化しなかったのかもしれませんね。
このルーチンは他からも呼ばれているので、3000h とかは危ないかもしれません。

ということで、あとは運用試験で問題が出ないか様子を見るだけとなりました。


＃ このまま問題が出ませんように（祈）

#10303 で

> ちなみに、このルーチンを公開版 VZk07t01 に追加すると常駐で動かないの。(;_;)
> 私の私家版常用環境では動くのに。(^^;

と書いていましたが、弄りすぎて原型がわからなくなっていたので
元に戻そうとしましたが戻せない。(>_<)
バイナリの比較で一致するまで散々苦労しました。
やっぱり公開版のフォルダは保存しておかないとなぁ、と。（何回目だ）

やっと元に戻ったので、Bl3072対応の修正だけしてみましたが効果なし。
Bl8192対応の修正もして、こちらは直ったのですが、Bl3072 は駄目です。

ラップアラウンドエラーが、MEMO.asm の memmove のルーチンの934行目
	rep	movsw				;VTDOS ERR
で出ているので、そこを読んでいる所を片っ端から調べました。
そうしたら、やっとわかりました。

OPEN.ASM 2139行目の
add_logtbl	proc
　　　　中略　2177行目
		sub	cx,si
		jc	addlog9			;★ ##k 221014 Bl3072 対策2
		call	memmove			;※ ここの rep movsw でエラーになる
		add	di,cx
		lea	si,[bp].path
	_endif
		call	strcpy
		inc	di
		mov	si,di
		mov	ax,[bp].lnumb
		call	set_logtbl
		clr	al
		stosb
addlog9:	popm	<es,ds>
		ret
add_logtbl	endp

このように、memmove の直前に キャリー分岐を入れたら直りました。＼(^^)／ ﾔｯﾀ-
常用している私家版では先の2か所の修正だけで直ったので、謎が残りますが。

色々試してみて問題ないようならテスト版としてアップしようと思います。

VTDOS のエラーは #i のルーチンで起こっているように見えます。
今回はその中からエラー回避でき、テストデータで問題が出ない箇所を見つけました。

MEMO.ASM 855行目あたり

txtmov1	proc
	push	es
	movseg	es,ds
	mov	cx,[bp].tend
	sub	cx,si
	jc	txtm19			;★##k 221108 VTDOSエラー回避
	call	memmove			;VTDOS err?
	add	cx,di
	mov	[bp].tend,cx		; update tend
txtm19:	pop	es			;
	ret
txtmov1	endp

この★印を追加することで Bl1024*3 でもエラーで落ちなくなりました。
Bl1024*3 の時は内容が壊れますが、この追加があれば他の修正がいらないようです。
非常駐だと Bl1024*3 でも正常処理されます。謎です。違いは何なのだろう。

完全ではありませんがこれと Bl8192 の修正をしたテスト版VZを揚げてみようと思います。

konnoさま（さま付けかよ）

　お疲れ様です。

>完全ではありませんがこれと Bl8192 の修正をしたテスト版VZを揚げてみようと思います。

　テスト版を是非。ただ、ベースになった版も明記ください。じゃないと長期にわたって
使用し、バグ、出る？　出ない？　とはできないからです。
　もっとも安定したヴァージョンをベースにしてくれると嬉しいです。それは、どの版？

--- my vz.def ---
Bl8192			;line buf (256..(Bt*1024/8))
-----------------

　これは、日本語を使う身としては、さすがに譲れませんから。日常業務において。

　テストだけしてみて欲しいというのであれば、曖昧でもいいですから、こういう場合はどう？
と指示してくださると嬉しいです。しばらくテスターになる気持ち（ほい？）はありますよ。

> 　テスト版を是非。ただ、ベースになった版も明記ください。じゃないと長期にわたって
> 使用し、バグ、出る？　出ない？　とはできないからです。
> 　もっとも安定したヴァージョンをベースにしてくれると嬉しいです。それは、どの版？

ベースは VZK07T01 です。過去記事で
#10257：Re^2: すれ違いと待ち伏せ 　投稿者：文太 　 2022/08/24(水) 

> 　僕は、Vzk k07t01 という版を使っているようです。うーん、このキー増強とか
> だけ、k07t01 に入れたいな、とか思っています。

こう書かれていたので、VZK07T01 が良いのかなと思いました。
それで確認のためにVZの部屋を見てみたら、げげ、VZK07T01.LZH が公開停止になっている！！
検索してみると
#8590： VZk07t01 公開停止 ＆ VZk07t 公開版の差し替え 投稿者： konno 　 2018/11/16(金)

> #8369 で公開したVZk07T1 (2018/10/17) は、バグが有ったので、公開停止しました。
> 使用されている人はすぐに使用中止願います。
> 代わりに、VZk07t 公開版の pc ズレ修正・差し替え版をアップしました。
> こちらは問題ないと思います。

こう書いていました。その理由は #8591 で

> DOSモバでSORT.DEF（高橋版）を試してみました。
> VZO、VZT、は問題なく動作しました。が
> VZK07t1 は、起動BATで常駐した時は、異常になります。
> 
> 調べてみたら、アセンブルでポカミスしていました。
> この版はすぐに公開停止しましたが、使用している人はすぐ使用中止願います。
> ご迷惑おかけして申し訳ありません。

ということなんですが、どうも文太さんとshadowさんは、K07T01 をお使いのようで。
#08611 の文太さんの書き込みでは

> 2018/10/17  19:11            62,184 vz.com	(k07t01)	;最新−１（前の版）

この日付とサイズの版が良いということですよね。
私はこのころ話がすれ違っているのに気が付いていなかったようです。
こちらの方が問題ないということであれば、再公開しようと思います。
ソースも公開すれば違いとか確認できますね。

> 　テストだけしてみて欲しいというのであれば、曖昧でもいいですから、こういう場合はどう？
> と指示してくださると嬉しいです。しばらくテスターになる気持ち（ほい？）はありますよ。

ファイルが壊れる可能性はありますが、テストしていただいて問題点がわかればうれしいです。
よろしくお願いいたします。