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

一括表示


  VTDOSでWGREP - konno 15/01/23-22:27 No.6578
 ┗ Re: VTDOSでWGREP - shadow 15/01/25-09:53 No.6579
  ┗ Re^2: VTDOSでSORT.DEFの場合 - konno 15/01/28-23:07 No.6580
   ┗ Re^3: VTDOSでSORT.DEFの場合 - konno 15/01/30-23:05 No.6581
    ┣ Re^4: VTDOSでSORT.DEFの場合 - konno 15/01/30-23:48 No.6582
    ┗ Re^4: VTDOSでSORT.DEFの場合 - shadow 15/01/31-20:03 No.6583
     ┗ Re^5: VTDOSでSORT.DEFの場合 - konno 15/02/15-13:48 No.6584

(6578) 6578VTDOSで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) 6579Re: 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) 6580Re^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して頂ければありがたいです。

上記のように改善されていないので、効果のほどは???ですね。

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

(6578) 6581Re^3: VTDOSでSORT.DEFの場合  投稿者:konno   2015/01/30(金) 23:05
    6580 番 konno さんへのコメント    コメント数 2

SORT.DEF(高橋版)の件ですが、落ちない場合もありますね。
不思議なのは、ファイルサイズが600bytes程度でも落ちることがあることです。

ラップアラウンドって、64kを超えることではなかったのかなぁ?
カウントの数値が64kになったとか?
-1 = $FFFF で検出しているということはないでしょうが、どうにも腑に落ちない。
カウントは+方向と-方向をcldとstdで変えていると思いますが、この辺で
何かがおこっていないだろうかと(Windowsのシステム的に)
実はこういう疑問からVZのルーチンを弄ってみたのです。

NP2やDOSBOXやNTVDMでは同じファイルでも落ちませんね。

ちなみに、SORTルーチンのマシン語を逆汗してみたら、”REPNE SCASB”ありますね。

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

(6578) 6582Re^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」でここの掲示板もヒット
この当時のいきさつが話題になっていました。(^^;


ちょっとあっちに行ってきます。(^^;

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

(6578) 6583Re^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) 6584Re^5: VTDOSでSORT.DEFの場合  投稿者:konno   2015/02/15(日) 13:48
    6583 番 shadow さんへのコメント

VTDOS BBS のほうで10#さんが対応してくれました。
以下に引用します。

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

ご推測の通り、std、逆方向の rep scasb で
セグメントラップアラウンドが発生しています。
改行文字をes:diから逆方向にサーチしてるんですが、
このときcxが0ffffhになっていて、改行文字が見つからないため、
VTDOSがセグメントラップアラウンドエラーを吐いています。

セグメントラップアラウンド後もcxが0になるまでrep scasbを
続けるように変更すると、一見正常に動作します。
しかし、複数ファイルを編集していると、高い確率でVZのバッファーが
クラッシュしています。
ですので、根本的な原因が他にあるのでは?と推測しています。

ストリング命令は32bitでもストリング命令として実行されますが、
ラップアラウンドが発生すると、全く違うアドレスを処理することになるため、
ストリング処理を2回行う必要があります。
しかし、多くの場合セグメントラップアラウンドは何らかの不具合が
原因で起こるため、VTDOSでは致命的エラーとして扱っています。

あと、VTDOSはInt21hを32bitコードで処理するため、このエラーは、
アプリケーション(ユーザープロセス)コード上でのみ発生します。

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

ということのようで、この件についてはオプションスイッチで対応していただき
動作するようになりました。

10#さん、対応有難うございました。

> しかし、複数ファイルを編集していると、高い確率でVZのバッファーが
クラッシュしています。

まだ確認できていませんが、使用時は自己責任でお願いします。>ALL


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