(6578)
6578：
VTDOSでWGREP
投稿者：
konno
2015/01/23(金) 22:27
コメント数 1
私はVTDOS環境の今でも検索はWGREPを愛用しています。
ヒット数が多すぎるとVTDOSが落ちることがありますが、窓になってからか
NT系になってからか、たまに起こっていたので、しかたがないかと諦めていました。
VTDOSでは結構頻繁に落ちます。
また、WGREP使用後に不安定になることもしばしばあります。
GREPの使用頻度は高いので、YAGREP に変えてみたところ、安定しているようです。
ところで、最近VTDOSBBSで
＞core.asm の endline 手続きで発生している
というのを見て、ソースを眺めていたところ、ふと閃いて、少し弄ってみました。
・・・・
おお、WGREPが安定して動くようになった！！
ヒット数が多くても全然問題なし！！
ということで、現在検証中というか、しばらく使ってみます。
まったくのカンで弄ったので、どこかを壊していないとも限らないので。(^^;
- No.6578 -
このTreeへ
[リストへもどる]
soft
(6578)
6579：
Re: VTDOSでWGREP
投稿者：
shadow
2015/01/25(日) 09:53
6578 番 konno さんへのコメント コメント数 1
konno さん、お世話になっております。
> GREPの使用頻度は高いので、YAGREP に変えてみたところ、安定しているようです。
私の環境では、vtdos bbsに書いたSORT.DEF（高橋版）では100%の確率で落ちるのでSORT.DEF 0.51金近真一／木村修版に変更しています。
また、vgrep.defでも時々落ちる状況です。
> おお、WGREPが安定して動くようになった！！
> ヒット数が多くても全然問題なし！！
vtdosでは直ぐに対応することが難しいとのことなのでvzの対策が問題なければ変更箇所の情報をUPして頂ければありがたいです。
- No.6579 -
このTreeへ
コメント元:6578 へ
[リストへもどる]
soft
(6578)
6580：
Re^2: VTDOSでSORT.DEFの場合
投稿者：
konno
2015/01/28(水) 23:07
6579 番 shadow さんへのコメント コメント数 1
> 私の環境では、vtdos bbsに書いたSORT.DEF（高橋版）では100%の確率で落ちるのでSORT.DEF 0.51金近真一／木村修版に変更しています。
SORT.DEF（高橋版）はやっぱり落ちますね。調べてみたところ、
メニューを抜けた時のファイルクローズ処理で落ちているようです。
マクロの最後のサブルーチンです。
06: ; close
(u)??.
(u<0)?{&s id[,&#T(u) #C u-,&#T(-0]) &d.}
bx=u,ax$3E00,&i($21) dx=pq..149,ax$4100,&i($21) u-, ; ★
ここをコメントにすると、編集ファイルを閉じた時に落ちます。
; F_CLOSE equ 3Eh ; Close a File Handle
; F_DELETE equ 41h ; Delete a Directory Entry
ここではこの2つのDOSコールを読んでいますが、おそらく
VTDOSはF_CLOSEのタイミングでエラーメッセージを出しているのでしょう。
エラーメッセージ自体はまったく同じです。
今のところはこれ以上はわからないです。
> また、vgrep.defでも時々落ちる状況です。
これも調べてみますね。
> vtdosでは直ぐに対応することが難しいとのことなのでvzの対策が問題なければ変更箇所の情報をUPして頂ければありがたいです。
上記のように改善されていないので、効果のほどは？？？ですね。
(6578)
6581：
Re^3: VTDOSでSORT.DEFの場合
投稿者：
konno
2015/01/30(金) 23:05
6580 番 konno さんへのコメント コメント数 2
SORT.DEF（高橋版）の件ですが、落ちない場合もありますね。
不思議なのは、ファイルサイズが600bytes程度でも落ちることがあることです。
ラップアラウンドって、64ｋを超えることではなかったのかなぁ？
カウントの数値が64ｋになったとか？
-1 ＝ ＄FFFF で検出しているということはないでしょうが、どうにも腑に落ちない。
カウントは+方向と-方向をｃｌｄとｓｔｄで変えていると思いますが、この辺で
何かがおこっていないだろうかと（Windowsのシステム的に）
実はこういう疑問からVZのルーチンを弄ってみたのです。
NP2やDOSBOXやNTVDMでは同じファイルでも落ちませんね。
ちなみに、SORTルーチンのマシン語を逆汗してみたら、”REPNE SCASB”ありますね。
- No.6581 -
このTreeへ
コメント元:6580 へ
[リストへもどる]
soft
(6578)
6582：
Re^4: VTDOSでSORT.DEFの場合
投稿者：
konno
2015/01/30(金) 23:48
6581 番 konno さんへのコメント
「セグメントラップアラウンド」でググってみたら、VTDOSBBSがヒットしました。(^^;
それで、VTDOS.TXT で検索したら
20100326 0125 REP MOVSB セグメントラップアラウンド修正・LHA対応
20100123 0122 ストリング命令セグメントラップアラウンドチェック不具合修正
これで、もしかして、と思い、VTDOS Ver121 でSORT.DEFを試してみたら
無事に動きましたよ。
更に、「セグメントラップアラウンド VTDOS」でここの掲示板もヒット
この当時のいきさつが話題になっていました。(^^;
ちょっとあっちに行ってきます。(^^;
(6578)
6583：
Re^4: VTDOSでSORT.DEFの場合
投稿者：
shadow
2015/01/31(土) 20:03
6581 番 konno さんへのコメント コメント数 1
konno さん
> SORT.DEF（高橋版）の件ですが、落ちない場合もありますね。
> 不思議なのは、ファイルサイズが600bytes程度でも落ちることがあることです。
私の環境では7行、300bytes程度でもオリジナルを含めてすべてのvzで100%落ちます。
> NP2やDOSBOXやNTVDMでは同じファイルでも落ちませんね。
確かにNP2、T98-NEXT及びanex86（PC286エミュ）の98エミュでは落ちないです。
> ちなみに、SORTルーチンのマシン語を逆汗してみたら、”REPNE SCASB”ありますね。
プログラムに関することは理解不能なのでよろしくお願いします。
- No.6583 -
このTreeへ
コメント元:6581 へ
[リストへもどる]
soft
(6578)
6584：
Re^5: VTDOSでSORT.DEFの場合
投稿者：
konno
2015/02/15(日) 13:48
6583 番 shadow さんへのコメント
VTDOS BBS のほうで10#さんが対応してくれました。
以下に引用します。
---------------------------------------------
ご推測の通り、std、逆方向の rep scasb で
セグメントラップアラウンドが発生しています。
改行文字をes:diから逆方向にサーチしてるんですが、
このときcxが0ffffhになっていて、改行文字が見つからないため、
VTDOSがセグメントラップアラウンドエラーを吐いています。
セグメントラップアラウンド後もcxが０になるまでrep scasbを
続けるように変更すると、一見正常に動作します。
しかし、複数ファイルを編集していると、高い確率でVZのバッファーが
クラッシュしています。
ですので、根本的な原因が他にあるのでは？と推測しています。
ストリング命令は32bitでもストリング命令として実行されますが、
ラップアラウンドが発生すると、全く違うアドレスを処理することになるため、
ストリング処理を２回行う必要があります。
しかし、多くの場合セグメントラップアラウンドは何らかの不具合が
原因で起こるため、VTDOSでは致命的エラーとして扱っています。
あと、VTDOSはInt21hを32bitコードで処理するため、このエラーは、
アプリケーション（ユーザープロセス）コード上でのみ発生します。
------------------------------------------------------
ということのようで、この件についてはオプションスイッチで対応していただき
動作するようになりました。
10#さん、対応有難うございました。
> しかし、複数ファイルを編集していると、高い確率でVZのバッファーが
クラッシュしています。
まだ確認できていませんが、使用時は自己責任でお願いします。＞ALL
- No.6584 -
このTreeへ
コメント元:6583 へ
[リストへもどる]
soft