> 仮にファイラー絡みとするなら、
> フォルダーの内容がFAT時代の想定を超えてきているとかないですか？
> 大量にファイルがあったりとか、超大容量のファイルがあったりとか、
> やたら長いファイル名があったりとか。

量は多めですが、該当するような状況は無いと思います。
Win7のフォルダのセキュリティなどが影響することって無いですよね。

> 僕が使ってるk07s3のファイラーは、ファイル名が長かったり、
> ファイルサイズの桁数が多いとき、表示が異常になることがあります。
> （system32とか）

長すぎるファイル名は、お尻をカットしていると思います。
ファイルサイズの桁数が多いと横にはみ出しますよね。
表示だけでVZの動作には影響ないですか。

> VZのソースフォルダーで grep div *.asm すれば問題箇所の候補は列挙できます。
> divに先立って、clr dxやclr ahなどがある場合は99%白です。

うう、結構あるので見当もつきません。

> リンク時のmapファイルがあれば、VTDOSが表示しているアドレスから、
> ソースの箇所を推測できるかもしれません。

アドレスって
VZIBMJ(1954) 1954:2975 
この 2975 でしょうか。
VZ.MAP で近いのは
 0000:256A       FX_NEXTPOOL
 0000:2977       GETPOOLP

これはfiler.asmのこのへんかな。

;----- Set home position -----
;--> CX :files

fsethome	proc
		mov	ax,cx
		cwd
		div	bx
		push	ax
		mov	bx,hfiles
		mov	ax,[bp].fl_home
		cwd
		div	bx
		pop	dx
		sub	dx,ax
		mov	al,[bp].fl_wsy
		cbw
		cmp	dx,ax
	_if l
		mov	[bp].fl_home,0
	_endif
		ret
fsethome	endp

;--- Get pool pointer ---
;<--
; DX:BX :pool ptr

	public	getpoolp
getpoolp proc
	mov	bx,[bp].fl_bcsr
getpoolp1:
	mov	ax,type _dir
	mul	bx
	add	ax,[bp].fl_pooltop
	mov	bx,ax
	mov	dx,[bp].fl_seg
	cmp	bx,[bp].fl_poolend
	ret
getpoolp endp


> symdebの逆アセンブルでも前後の表示は可能と思われます。

debug しか使ったことが無くて、しかもだいぶ忘れてますが

VTDOS|C:\VZ\K07T2>debug VZIBMJ.COM
-u 2960
3D99:2960 8B4610        MOV	AX,[BP+10]                         
3D99:2963 99            CWD	                                   
3D99:2964 F7F3          DIV	BX                                 
3D99:2966 5A            POP	DX                                 
3D99:2967 2BD0          SUB	DX,AX                              
3D99:2969 8A4615        MOV	AL,[BP+15]                         
3D99:296C 98            CBW	                                   
3D99:296D 3BD0          CMP	DX,AX                              
3D99:296F 7D05          JGE	2976                               
3D99:2971 C746100000    MOV	WORD PTR [BP+10],0000              
3D99:2976 C3            RET	                                   
3D99:2977 8B5E0C        MOV	BX,[BP+0C]                         
3D99:297A B81600        MOV	AX,0016                            
3D99:297D F7E3          MUL	BX                                 
3D99:297F 034602        ADD	AX,[BP+02]                         
-q

なにか外していそうですね。もしかして256足しましたっけ。

10#さん

> VTDOSの問題箇所を調べてみましたら16bit除算でした。
> VZのソースで、先立つcwd や clr dx が見当たらない divは
> disp.asmに集中していますね。

参考になります。

VTDOS|C:\VZ\K07T2>WGREP -t -i -k vcb "div" *.*
------------------ DISP.ASM
DISP.ASM 591:	div	bx			;ax=(dx,ax)/bx dx=(dx,ax)%bx
DISP.ASM 648:	div	bx
DISP.ASM 745:	div	bx
DISP.ASM 788:	div	bx
DISP.ASM 978:	div	bx

disp.asmにはこれだけあります。

;--- Indicator bar ---
indibar2:
DISP.ASM 591:	div	bx			;ax=(dx,ax)/bx dx=(dx,ax)%bx
最初の所は自作の拡張インジケータバールーチンです。
オリジナルのルーチンを流用して見よう見まねで80桁に拡張しました。
一番怪しいかもですが、見てもわからないです。

indibar:
DISP.ASM 648:	div	bx
こちらがオリジナルのインジケータバールーチンです。

time2:	msdos	F_GETTIME	; int 21h 2ch  dh=秒
DISP.ASM 745:	div	bx
これは時計表示ルーチンです。
数値の範囲が変わることは無いでしょうからここはシロ？

sysparm2:							;##k08d
DISP.ASM 788:	div	bx
これはテキストサイズかな。VZの動作範囲内なら問題ないですよね。

;--- Display Line header ---
DISP.ASM 978:	div	bx
これは行番号表示ですね。私は普段表示させてないので違うと思います。


ふと思ったんですが、下記のルーチンでも使われてるんですね。
ここは問題は起こりえないですか。
------------------ SPRINTF.INC
SPRINTF.INC 245:		div	bx
SPRINTF.INC 248:		div	bx