[HOME]  [全部表示 会議室風]  [全部表示 保存用]  [HOME]  [リストへもどる] [リストへもどる]

一括表示


  VTDOS1.41 - konno 14/06/14-22:08 No.6549
 ┣ Re: VTDOS1.41+CKWV7 で C:\ の入力 - konno 14/06/14-22:44 No.6551
 ┃ ┗ Re^2: VTDOS1.41+CKWV7 で C:\ の入力 - 10♯ 14/06/15-20:29 No.6553
 ┃ ┗ Re^3: WinIMEで C:\ の入力モード設定 - konno 14/06/15-21:36 No.6555
 ┗ Re: VTDOS1.41 - 10# 14/06/15-16:35 No.6552
  ┗ Re^2: VTDOS1.41 - konno 14/06/15-21:26 No.6554
   ┗ Re^3: VTDOS1.41 - 10# 14/06/16-00:37 No.6556
    ┗ Re^4: VZの除算オーバーフロー - konno 14/06/17-00:11 No.6557
     ┗ Re^5: VZの除算オーバーフロー - 10# 14/06/17-01:20 No.6558
      ┗ Re^6: VZの除算オーバーフロー - konno 14/06/19-23:48 No.6559
       ┗ Re^7: VZの除算オーバーフロー - 10♯ 14/06/20-20:52 No.6560
        ┗ Re^8: VZの除算オーバーフロー - konno 14/06/23-00:44 No.6561

(6549) 6549VTDOS1.41  投稿者:konno   2014/06/14(土) 22:08
   コメント数 2

VTDOS1.41+CKWV7を現在使用中ですが、2度致命的エラーで落ちました。

2014-06-11 23:24:51 VZIBMJ(1954) 1954:2975 '致命的エラー: 一般保護例外 0xc0000095 0x00413FE5'
2014-06-14 21:55:26 VZIBMJ(1954) 1954:2975 '致命的エラー: 一般保護例外 0xc0000095 0x00413FE5'

まだ原因再現の特定までいってないですが、コンソールの編集で
IME使用中にファイラーオープンしようとしたときに落ちたような。
私の環境が問題なのかもしれません。

      - No.6549 -    このTreeへ           [リストへもどる] soft

(6549) 6551Re: VTDOS1.41+CKWV7 で C:\ の入力  投稿者:konno   2014/06/14(土) 22:44
    6549 番 konno さんへのコメント    コメント数 1

VTDOS1.41+CKWV7 で、IME使用中に、IME ON のままで、半角の

C:\

を入力すると、IMEが OFF になりますね。
うちの環境だけかもですが。

高橋版VZ + オリジナルVZ.DEF でも同じになります。

オリジナルVZ + オリジナルVZ.DEF も同様ですが、IMEの自動制御が効かないようですね。
この違いは高橋さんがDOS窓でFEP制御できるようにしてくれたからかな。


      - No.6551 -    このTreeへ    コメント元:6549 へ [リストへもどる] soft

(6549) 6553Re^2: VTDOS1.41+CKWV7 で C:\ の入力  投稿者:10♯   2014/06/15(日) 20:29
    6551 番 konno さんへのコメント    コメント数 1

これは僕の環境ではVTDOS以外でも同じ結果になります。
IMEの仕様というか設定じゃないですかね。

      - No.6553 -    このTreeへ    コメント元:6551 へ [リストへもどる] soft

(6549) 6555Re^3: WinIMEで C:\ の入力モード設定  投稿者:konno   2014/06/15(日) 21:36
    6553 番 10♯ さんへのコメント

> これは僕の環境ではVTDOS以外でも同じ結果になります。
> IMEの仕様というか設定じゃないですかね。

IMEの設定でした。

IMEのツール、プロパティ、和英混在入力タブに
「対象文字列を自動で英数に変換する」と言う項目があり、
\\  直接入力モード
C:\  直接入力モード
となっていました。
この「直接入力モード」を例えば「一時的に半角英数モード」に変更すれば
IMEがOFFにならないですね。

おさわがせしました。


      - No.6555 -    このTreeへ    コメント元:6553 へ [リストへもどる] soft

(6549) 6552Re: VTDOS1.41  投稿者:10#   2014/06/15(日) 16:35
    6549 番 konno さんへのコメント    コメント数 1

除算オーバーフローが起こっているようです。
現状VTDOSは0除算エラーをエミュレートしていますが、
除算オーバーフローを想定していません。
どう対応するかは検討課題とさせていただきますが、
通常このエラーは16bitコードの不具合に起因するため、
被除数の上位バイト/ワードに問題がないか確認をお勧めします。


      - No.6552 -    このTreeへ    コメント元:6549 へ [リストへもどる] soft

(6549) 6554Re^2: VTDOS1.41  投稿者:konno   2014/06/15(日) 21:26
    6552 番 10# さんへのコメント    コメント数 1

> 除算オーバーフローが起こっているようです。
> 通常このエラーは16bitコードの不具合に起因するため、
> 被除数の上位バイト/ワードに問題がないか確認をお勧めします。

げげ、もしかして、VZ ・・・なのか・・・
私のVZ.DEFの問題?・・・まだ続いているのかも。
外部コマンドで、WGREP を繰り返し使用している状況が多いので
コマンドラインの不安定さがまだあるのかもですね。
確認と言っても全然わからないですが。


      - No.6554 -    このTreeへ    コメント元:6552 へ [リストへもどる] soft

(6549) 6556Re^3: VTDOS1.41  投稿者:10#   2014/06/16(月) 00:37
    6554 番 konno さんへのコメント    コメント数 1

仮にファイラー絡みとするなら、
フォルダーの内容がFAT時代の想定を超えてきているとかないですか?
大量にファイルがあったりとか、超大容量のファイルがあったりとか、
やたら長いファイル名があったりとか。
僕が使ってるk07s3のファイラーは、ファイル名が長かったり、
ファイルサイズの桁数が多いとき、表示が異常になることがあります。
(system32とか)

VZのソースフォルダーで grep div *.asm すれば問題箇所の候補は列挙できます。
divに先立って、clr dxやclr ahなどがある場合は99%白です。
リンク時のmapファイルがあれば、VTDOSが表示しているアドレスから、
ソースの箇所を推測できるかもしれません。
symdebの逆アセンブルでも前後の表示は可能と思われます。

      - No.6556 -    このTreeへ    コメント元:6554 へ [リストへもどる] soft

(6549) 6557Re^4: VZの除算オーバーフロー  投稿者:konno   2014/06/17(火) 00:11
    6556 番 10# さんへのコメント    コメント数 1

> 仮にファイラー絡みとするなら、
> フォルダーの内容が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足しましたっけ。

      - No.6557 -    このTreeへ    コメント元:6556 へ [リストへもどる] pre

(6549) 6558Re^5: VZの除算オーバーフロー  投稿者:10#   2014/06/17(火) 01:20
    6557 番 konno さんへのコメント    コメント数 1

VTDOSの問題箇所を調べてみましたら16bit除算でした。
VZのソースで、先立つcwd や clr dx が見当たらない divは
disp.asmに集中していますね。
参考になりますか?
      - No.6558 -    このTreeへ    コメント元:6557 へ [リストへもどる] soft

(6549) 6559Re^6: VZの除算オーバーフロー  投稿者:konno   2014/06/19(木) 23:48
    6558 番 10# さんへのコメント    コメント数 1

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




      - No.6559 -    このTreeへ    コメント元:6558 へ [リストへもどる] pre

(6549) 6560Re^7: VZの除算オーバーフロー  投稿者:10♯   2014/06/20(金) 20:52
    6559 番 konno さんへのコメント    コメント数 1

sprintf.incは基数で割った余りを基数で割っているので、これは問題無いでしょう。
disp.asmの最後のdivは直前にclr dxがあるため問題ないと思われます。
それ以外はすべてgetcurptrの戻り値を処理してるようですね。
current ptrがtext sizeを大幅(2^16倍以上)に上回らない限り問題ないと思われます。

current ptrやtext sizeは、たぶんそのまんまの意味だと思うんですが、
current ptrがtext sizeを上回るような可能性はありますか?

      - No.6560 -    このTreeへ    コメント元:6559 へ [リストへもどる] soft

(6549) 6561Re^8: VZの除算オーバーフロー  投稿者:konno   2014/06/23(月) 00:44
    6560 番 10♯ さんへのコメント

> sprintf.incは基数で割った余りを基数で割っているので、これは問題無いでしょう。

そうなんですか、勉強になります。

> current ptrがtext sizeを大幅(2^16倍以上)に上回らない限り問題ないと思われます。
> current ptrやtext sizeは、たぶんそのまんまの意味だと思うんですが、
> current ptrがtext sizeを上回るような可能性はありますか?

うう、全然わからないです。

エラーの出た状況がコンソールとコマンドライン、ファイラーの行き来なので
また出たらお知らせします。

      - No.6561 -    このTreeへ    コメント元:6560 へ [リストへもどる] soft