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

一括表示


  VTDOS+VZ で #N、#P でのエラー - konno 18/10/18-20:58 No.8375
 ┣ Re: VTDOS+VZ で #N、#P でのエラー - 10♯ 18/10/18-21:54 No.8376
 ┃ ┗ Re^2: VTDOS+VZ で #N、#P でのエラー - konno 18/10/18-22:20 No.8378
 ┃ ┗ Re^3: VTDOS+VZ で #N、#P でのエラー - konno 18/10/19-02:18 No.8384
 ┃  ┗ Re^4: VTDOS+VZ で #N、#P でのエラー - 文太 18/10/19-11:05 No.8385
 ┃   ┗ !Abort でエラー回避 - konno 18/10/20-01:57 No.8386
 ┗ Re: VTDOS+VZ で #N、#P でのエラー - 文太 18/10/18-22:03 No.8377
  ┗ Re^2: VTDOS+VZ で #N、#P でのエラー - konno 18/10/18-22:47 No.8379
   ┗ Re^3: VTDOS+VZ で #N、#P でのエラー - 文太 18/10/19-00:13 No.8380
    ┗ Re^4: VTDOS+VZ で #N、#P でのエラー - 文太 18/10/19-00:35 No.8381
     ┣ vz.com, s>0の問題みたい - 文太 18/10/19-00:55 No.8382
     ┃ ┗ 痩せたVz、太ったVz - 文太 18/10/19-01:26 No.8383
     ┃ ┗ Re: 痩せたVz、太ったVz - 10♯ 18/10/20-13:55 No.8387
     ┃  ┣ si と di のチェック? - konno 18/10/20-20:02 No.8388
     ┃  ┃ ┗ Re: si と di のチェック? - 10♯ 18/10/20-21:38 No.8390
     ┃  ┗ Re^2: 痩せたVz、太ったVz - 文太 18/10/20-22:27 No.8392
     ┃  ┃ ┗ Re^3: 痩せたVz、太ったVz - 10♯ 18/10/20-22:32 No.8394
     ┃  ┃ ┗ Re^4: 痩せたVz、太ったVz - 文太 18/10/20-22:45 No.8395
     ┗ Re^5: VTDOS+VZ で #N、#P でのエラー - konno 18/10/20-20:18 No.8389
      ┣ 暗闇の中の僕 - 文太 18/10/20-22:12 No.8391
      ┃ ┗ Re: 暗闇の中の僕 - 10♯ 18/10/20-22:31 No.8393
      ┃ ┣ Re^2: 暗闇の中の僕 - 文太 18/10/20-22:48 No.8396
      ┃ ┗ Re^2: 暗闇の中の僕 - konno 18/10/21-00:18 No.8400
      ┃ ┃ ┗ Re^3: 暗闇の中の僕 - 10♯ 18/10/21-01:19 No.8404
      ┃ ┃ ┗ うーむ - 文太 18/10/21-01:28 No.8405
      ┗ まとめの試み - 文太 18/10/20-23:04 No.8397
       ┗ Re: まとめの試み - konno 18/10/20-23:38 No.8398
        ┣ Re^2: まとめの試み - 10♯ 18/10/20-23:54 No.8399
        ┃ ┗ Re^3: まとめの試み - konno 18/10/21-00:30 No.8401
        ┃ ┗ EMSがらみと言う - 文太 18/10/21-00:56 No.8402
        ┃ ┃ ┗ Re: EMSがらみと言う - 10♯ 18/10/21-01:12 No.8403
        ┃ ┃ ┗ Re^2: EMSがらみと言う - 文太 18/10/21-01:34 No.8406
        ┗ Re^2: まとめの試み - 文太 18/10/21-11:12 No.8407
         ┗ Re^3: まとめの試み - としき 18/10/21-21:48 No.8408
          ┣ &z("") on dos6.2 - 文太 18/10/21-23:07 No.8409
          ┃┃┣ Re: &z("") on dos6.2 - としき 18/10/22-18:00 No.8414
          ┃┃┗ &z("") on WinME - 文太 18/10/22-22:06 No.8416
          ┃ ┗ &z("") on DOSモバ (dos6.22) - konno 18/10/22-23:27 No.8418
          ┃ ┣ Re: &z("") on DOSモバ (dos6.22) - 10♯ 18/10/22-23:50 No.8419
          ┃ ┃ ┗ rep 命令で矛盾があった時の動作 - konno 18/10/26-23:04 No.8427
          ┃ ┃ ┣ Re: rep 命令で矛盾があった時の動作 - 文太 18/10/27-00:24 No.8428
          ┃ ┃ ┗ Re: rep 命令で矛盾があった時の動作 - 10♯ 18/10/27-01:49 No.8429
          ┃ ┃ ┃ ┗ Re^2: rep 命令で矛盾があった時の動作 - konno 18/10/28-02:26 No.8432
          ┃ ┃ ┃ ┗ Re^3: rep 命令で矛盾があった時の動作 - 10♯ 18/10/28-03:58 No.8435
          ┃ ┗ Re: &z("") on DOSモバ (dos6.22) - 文太 18/10/23-00:22 No.8420
          ┣ Re^4: まとめの試み - 10♯ 18/10/22-06:12 No.8412
          ┃ ┗ Re^5: まとめの試み - としき 18/10/22-17:57 No.8413
          ┃ ┗ Re^6: まとめの試み - 10♯ 18/10/22-19:43 No.8415
          ┗ Re^4: まとめの試み - としき 18/10/23-01:25 No.8421
           ┣ 落ちない悩み WinXP - 文太 18/10/23-08:58 No.8422
           ┃ ┗ Re: 落ちない悩み WinXP - 文太 18/10/23-09:10 No.8423
           ┣ Re^5: まとめの試み - konno 18/10/23-21:59 No.8424
           ┃ ┗ 懐かしがれない過去 - 文太 18/10/23-23:38 No.8425
           ┗ Re^5: まとめの試み - としき 18/10/24-03:28 No.8426
            ┗ Re^6: まとめの試み - としき 18/10/27-22:07 No.8430
             ┣ Re^7: まとめの試み - 文太 18/10/28-00:10 No.8431
             ┃┃┣ k07t3 は内部ワークの位置ズレ有り、公開停止します - konno 18/10/28-02:37 No.8433
             ┃┃┗ Re: k07t3 は内部ワークの位置ズレ有り、公開停止します - 文太 18/10/28-13:57 No.8436
             ┃ ┗ Re^8: まとめの試み - としき 18/10/28-14:22 No.8438
             ┃ ┗ Re^9: まとめの試み - 文太 18/10/28-15:31 No.8439
             ┃ ┃ ┗ Re^10: まとめの試み - としき 18/10/28-16:26 No.8440
             ┃ ┃ ┣ Re^11: まとめの試み - 文太 18/10/28-17:58 No.8441
             ┃ ┃ ┃ ┗ Re^12: まとめの試み - としき 18/10/28-22:33 No.8448
             ┃ ┃ ┗ Re^11: まとめの試み - としき 18/10/29-11:19 No.8453
             ┃ ┃  ┗ Re^12: まとめの試み - としき 18/10/30-22:32 No.8461
             ┣ Re^7: まとめの試み - konno 18/10/28-02:53 No.8434
             ┃ ┗ Re^8: まとめの試み - としき 18/10/28-14:02 No.8437
             ┃ ┗ Re^9: まとめの試み - konno 18/10/28-18:43 No.8442
             ┃ ┃┃┣ Re^10: まとめの試み - 文太 18/10/28-18:53 No.8443
             ┃ ┃ ┗ Re^10: まとめの試み - としき 18/10/28-22:21 No.8446
             ┗ Re^7: まとめの試み - としき 18/10/28-22:13 No.8444
              ┣ Re^8: まとめの試み - 10♯ 18/10/28-22:19 No.8445
              ┃┃┣ Re^9: まとめの試み - としき 18/10/28-22:24 No.8447
              ┃┃┗ Re^10: まとめの試み - 10♯ 18/10/28-23:24 No.8449
              ┃┃ ┗ Re^11: まとめの試み - としき 18/10/28-23:49 No.8451
              ┃ ┗ Re^9: まとめの試み - 10♯ 18/10/28-23:39 No.8450
              ┃ ┗ Re^10: まとめの試み - 10♯ 18/10/29-19:09 No.8455
              ┃  ┗ Re^11: まとめの試み - konno 18/10/30-02:02 No.8456
              ┃   ┗ Re^12: まとめの試み - 10♯ 18/10/30-02:21 No.8457
              ┃    ┣ Re^13: まとめの試み - 10♯ 18/10/30-14:36 No.8458
              ┃    ┃ ┗ Re^14: まとめの試み - 10♯ 18/11/05-03:06 No.8511
              ┃    ┗ Re^13: まとめの試み - konno 18/10/31-00:08 No.8462
              ┃     ┗ Re^14: まとめの試み - 10♯ 18/10/31-00:30 No.8463
              ┃      ┗ Re^15: まとめの試み - konno 18/10/31-01:24 No.8464
              ┃       ┗ Re^16: まとめの試み - 10♯ 18/10/31-01:34 No.8465
              ┃        ┣ Re^17: まとめの試み - 10♯ 18/10/31-01:38 No.8466
              ┃        ┗ Re^17: まとめの試み - konno 18/10/31-19:43 No.8468
              ┗ PC-98のファンクションキー - としき 18/10/29-10:20 No.8452
               ┗ 【訂正】PC-98のファンクションキー - としき 18/10/29-11:26 No.8454

(8375) 8375VTDOS+VZ で #N、#P でのエラー  投稿者:konno   2018/10/18(木) 20:58
   コメント数 2

VTDOS+VZ でファイル編集中に #N や、#P で、拙作の TAGL_F5.DEF を実行すると
&z("expand") を呼ぶところでマクロエラーになります。
ESC を押すと、VTDOSが、ラップアラウンドエラーで落ちます。

実は、私の環境では、expand.def が無かったんです。
つまり、ファイル操作窓で、マクロ呼び出しなどでファイルが無いエラーになると
ESC で入力窓を閉じる時、VTDOSが、ラップアラウンドエラーで落ちるのです。
エラー内容は

2018-10-18 20:29:03 VZIBMJ(17EA) 17EA:DE8E 'REP MOVSW 命令ラップアラウンド'

AX=0023 BX=4000 CX=0082 DX=FF00 SI=EA60 DI=FF04 BP=CBEE DS=E800 ES=F800 FLAGS=0246

CS:IP=17EA:DE8E
17EA:DE7E 40 06 51 57 51 57 E8 B1 00 E8 2D 04 5F 59 F3 A5 
17EA:DE8E E8 44 04 5F 59 36 03 3E 46 06 48 75 E5 E8 AC 2E 

SS:SP=274A:CACE
274A:CABE 00 00 04 FF CD E2 04 FF 23 00 8A DE 04 FF 82 00 
274A:CACE 04 FF 82 00 4A 27 4A 27 76 03 DB A3 90 06 00 FF 

-u 17EA:DE7E
17EA:DE7E 40            INC	AX                                 
17EA:DE7F 06            PUSH	ES                                 
17EA:DE80 51            PUSH	CX                                 
17EA:DE81 57            PUSH	DI                                 
17EA:DE82 51            PUSH	CX                                 
17EA:DE83 57            PUSH	DI                                 
17EA:DE84 E8B100        CALL	DF38                               
17EA:DE87 E82D04        CALL	E2B7                               
17EA:DE8A 5F            POP	DI                                 
17EA:DE8B 59            POP	CX                                 
17EA:DE8C F3            REPZ	                                   
17EA:DE8D A5            MOVSW	                                   
17EA:DE8E E84404        CALL	E2D5                               
17EA:DE91 5F            POP	DI                                 
17EA:DE92 59            POP	CX                                 
17EA:DE93 36            SS:	                                   
17EA:DE94 033E4606      ADD	DI,[0646]                          
17EA:DE98 48            DEC	AX                                 
17EA:DE99 75E5          JNZ	DE80                               
17EA:DE9B E8AC2E        CALL	0D4A                               
-q

 0000:DE59       POPWINDOW

ここは、入力窓ルーチンの窓を閉じるところですね。
SORT.DEF も、バックアップルーチンで、#N を使用していますが、
何かエラーが出ていた気がします。

MSDOSPlayer や、DOS窓では、マクロエラーがあっても落ちません。
この辺に何かありそうな気がするのですが。


      - No.8375 -    このTreeへ           [リストへもどる] pre

(8375) 8376Re: VTDOS+VZ で #N、#P でのエラー  投稿者:10♯   2018/10/18(木) 21:54
    8375 番 konno さんへのコメント    コメント数 1

ざっくりですが、画面の出力座標かサイズに問題が起こってるようですね。
外してるかも知れませんけど、scrn.asm の win か doswd2
これらはマクロからアクセスしてログを取ることなどは出来ますか?
      - No.8376 -    このTreeへ    コメント元:8375 へ [リストへもどる] soft

(8375) 8378Re^2: VTDOS+VZ で #N、#P でのエラー  投稿者:konno   2018/10/18(木) 22:20
    8376 番 10♯ さんへのコメント    コメント数 1

> ざっくりですが、画面の出力座標かサイズに問題が起こってるようですね。
> 外してるかも知れませんけど、scrn.asm の win か doswd2
> これらはマクロからアクセスしてログを取ることなどは出来ますか?

えーと、何をすればいいのかわかりませんが

VTDOS環境では、全てのVZで同じ操作で落ちました。
オリジナルVZとオリジナルDEFでも、#Nで、拙作の TAGL_F5.DEF を実行して
落ちます。

TAGL_F5.DEF の冒頭は

24  [F05] "検索文字列の取得"
	(s==1||s==2)? { &z("expand") >* }	; コマンドライン

こうなっていて、これは、上村さんの、GET.DEF と同じです。
私はこのマクロをベースに改造したのですが、expand.def が無いのに
気が付かなかったのです。

入力窓の中で、マクロがエラーで止まって、フラグとか
スタックとかの数値に矛盾が出てるんでしょうかね。


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

(8375) 8384Re^3: VTDOS+VZ で #N、#P でのエラー  投稿者:konno   2018/10/19(金) 02:18
    8378 番 konno さんへのコメント    コメント数 1

とりあえず、VZ.DEF か、VZ2.DEF のようなインクルードマクロに
エラーイベントマクロ

1 "!Abort" /

を入れると、今回のエラーで落ちるのは無くなったようです。
'/' は、全マクロ終了だったかな。
副作用はわからないです。

おそらく、マクロ終了時の処理、オプションの初期化みたいなことを
やっているのではと想像しますが、本当のところはわかりません。


でも、SORT.DEF はやっぱり落ちるみたい。


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

(8375) 8385Re^4: VTDOS+VZ で #N、#P でのエラー  投稿者:文太   2018/10/19(金) 11:05
    8384 番 konno さんへのコメント    コメント数 1

 /     マクロの実行を終了
   ネストレベルに関係なく全てのマクロが終了する
   マクロを終了するときは '.' を使うほうがよい
   (モード型のマクロも終了してしまうため)

 誰かがもう少し詳しく纏めていたような気もしますが、僕に分かったのは
これだけです。使ったことないですよね。ほとんど禁止されてたみたいなもの
だった気もするし。

 「/ マクロを強制中断(使用禁止?)」(上村さんの「道場」より)
 プッシュ・ポップも戻さないで、強制終了。
 僕の印象のソースは、ここかもしれません。

 でも、その!abort技、ありなんじゃないでしょうか。かなり稀な緊急事態のような
気もするし。こうなったら、Vzを再起動せよ、で、いいような。

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

(8375) 8386 !Abort でエラー回避  投稿者:konno   2018/10/20(土) 01:57
    8385 番 文太 さんへのコメント

過去ログを読んでも、!Abort 処理は挙動がよくわからないので、
皆さん入れてない人が多いのではないでしょうか。
老師の言によると

> 03777/03785 XXXXXXXX  m.gann           RE:Q:lbuf を文字列として扱うのは可
> (15)   97/01/03 21:30  03719へのコメント

>  通常、「変更できません」や「オープンできません」などのエラーで、実行中
>  の全マクロ(モード型を含む)が強制終了してしまいます。
>  これは、'/' 抜きの !Abort で解消できますが、各マクロで、(r)?. などの、
>  自前のエラー処理が必要となります。

> === test
> * M
> 1 ^\ "" ?. mr[$80, #28 mr], #] &b(3) &m("r: %d",r)
> 1 "!V"  ?. &m("a") &b(3) &w(60) ''
> 1 "!A"  &m(r) &b(3) &w(60)
> *


こういう記事を見て、下記のようにしました。

1 "!Abort" 
	 &m("!Abort %s",r) &b(3) &w(60) 
;        (r>0&&r<45)?&m(r) s-, &w(60) &d &b(3) cm0~,

下側のコメントは、別の書き込みの物で、今交互に試しています。
!Abort を通ると、"/" が無くても、#N の事例でVTDOSが落ちないようです。

現状副作用として、View モードの時、Enter でファイルが閉じなくなりました。

1 "!View" マクロの

	(cm==4)?{ &m("") (mb)?. #C &d. }			;#m

この行が最後のほうにあったのを、先頭に持ってきたら正常動作になりました。
これでしばらく様子を見ようと思います。


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

(8375) 8377Re: VTDOS+VZ で #N、#P でのエラー  投稿者:文太   2018/10/18(木) 22:03
    8375 番 konno さんへのコメント    コメント数 1

 いつもの超断片的補足です。(^^;

http://tamaneko.world.coocan.jp/vz/TAGL_F5.def

=== tagl_f5.def v.06 ===
* M
24  [F05] "検索文字列の取得"
	(s==1||s==2)? { &z("expand") >* }	; コマンドライン

 このように、tagl_f5.defは、sが

     1 : 文字列入力モード
     2 : コマンドラインモード

であると、expand.defが呼ばれる仕様になっているのですが、
expand.defがないばあい(%vzdef%ディレクトリに、かな?)、つまり

>ファイル操作窓で、マクロ呼び出しなどで、ファイルが存在せずエラーになると
>ESC で入力窓を閉じる時、VTDOSが、ラップアラウンドエラーで落ちるのです。

 失礼しました。
 マクロを見るまで、何を言ってるのかよく分からなかったもので。m(__)m


#N
 #72  #N  新規ファイルオープン
 [ESC]N @N

#P
 #25  #P  ファイル名の複写
 ^QN  le_copyfile
   r は常に 0
   編集中のフルパスのファイル名が
   カーソル位置に書き込まれる
   &?(wa+146) と同じ

 に何かあるのかも? と。

 追試するには、まだまだ環境整備がままなりません。m(__)m


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

(8375) 8379Re^2: VTDOS+VZ で #N、#P でのエラー  投稿者:konno   2018/10/18(木) 22:47
    8377 番 文太 さんへのコメント    コメント数 1

文太さん、解説どうもです。(^^;
私はいつも説明不足というか、舌足らずというか。

#8378 に書いたように、上村さんの、GET.DEF をベースに改造したので
この部分が問題になるとは思ってもいませんでした。

上村さんの、GET.DEF の最後のほうには

 ●ファイル名の補完
 文字入力ウィンドウまたはコマンドラインで実行すると、ファイル名を補完
します。(T.Tanomura氏作EXPAND.DEF必要)

とあります。
上村さんが他人のマクロを組み込むなんて想像もできなかった。
T.Tanomura氏も凄い人だったんだなぁ。


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

(8375) 8380Re^3: VTDOS+VZ で #N、#P でのエラー  投稿者:文太   2018/10/19(金) 00:13
    8379 番 konno さんへのコメント    コメント数 1

>#8378 に書いたように、上村さんの、GET.DEF をベースに改造したので
>この部分が問題になるとは思ってもいませんでした。
 こんな風に話がすぐに先に進むのであれば、何の問題もありません。
 上村さんの、GET.DEFは、存じておりませんでした。

>上村さんが他人のマクロを組み込むなんて想像もできなかった。
>T.Tanomura氏も凄い人だったんだなぁ。
 うーん、どうなんだろう。
 でも、fgalapぐらい?、fgalpk初期には、「たのむら〜、たのむわ〜」
みたいな感じで、上村さんは色んな人から貪欲に、超速で、勉強して
いましたよ。ほんとVzの基本を徹底的に勉強した人でしたねぇ。
いまごろ、ほんと偉いと思う。
 田野村さんは、計算に強い人だった感じかなぁ。expand.def、僕も
使ってますよ。
 って、何か変な感じ。
 ボク、1999年くらいにniftyデビューだったので。もう高橋さんも
いない頃。

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

(8375) 8381Re^4: VTDOS+VZ で #N、#P でのエラー  投稿者:文太   2018/10/19(金) 00:35
    8380 番 文太 さんへのコメント    コメント数 2

 もう少し問題を絞り込んだほうが良いような気がしますが。
 マクロのどの部分でかとか。 
(s==1||s==2)? { &z("expand") >* }	; コマンドライン
 この部分だけで落ちますね。

 で、落ちるのはvtdos環境に限定されていないと思います。今、純DOSで
expand.defを0expand.defにリネームして、
=== tagl_f5.def v.06 ===
* M
24  [F05] "検索文字列の取得"
 のマクロを再カスタマイズ、検索窓で[F05]したら、マシンが落ちました。
落ちるのはまずいだろう、とは思いますが。
 マクロがいけない? vz.comがいけない? マシンが落ちるのが正しい?
 補足でした。

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

(8375) 8382vz.com, s>0の問題みたい  投稿者:文太   2018/10/19(金) 00:55
    8381 番 文太 さんへのコメント    コメント数 1

 す、すげえ。
 「画面の出力座標かサイズに問題」。これに一票。
 vz.comの問題だと思う。

=== Macrotmp by B ===;
* M
50 ^^ "Macrotmp"

&z("expand") >*

*
  これをexpand.defがない環境でやりました。
 s==0, [ESC]が効いて、マシンは落ちない。「c:\def\expand.defが見つかりません」
のメッセージが出る。
 s==1, 落ちる。
 存在しないファイルを窓を開けた状態から&z()(???)でファイルオープンしないこと、ですかね。
 #Nとかについては、また別件でしょうか?



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

(8375) 8383痩せたVz、太ったVz  投稿者:文太   2018/10/19(金) 01:26
    8382 番 文太 さんへのコメント    コメント数 1

 お疲れ様です。
 僕の一票で候補者が当選しても、とうぜん、僕にできることは何もありません。
 冗談でなく。

 ふと、これは高橋さんも知らなかったのかなぁ、と考えていて。いや、この手
のことを全部潰していたら、ゼロ戦Vzはゼロ戦でなくなり、きっと、comに
収まらなくなっていたのだろうと想像しました。
 大昔の10#さんのVzソースレビュー(メモリ管理?)を思い出してそう
思いました。
 これってマクロで対処できるのでしょうかね? 僕はユーザがそういうことを
しないこと、でいいような気がしました。
 もう我々しかいないのだから、Vzを無意味に(?)太らせないほうがいい、と。

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

(8375) 8387Re: 痩せたVz、太ったVz  投稿者:10♯   2018/10/20(土) 13:55
参照先:http://q
    8383 番 文太 さんへのコメント    コメント数 2

この件でVTDOSに手を入れてログを取ったりしてちょこっと追っかけてみたけど、
これやるの?って所まで来てる(精神的に
      - No.8387 -    このTreeへ    コメント元:8383 へ [リストへもどる] soft

(8375) 8388si と di のチェック?  投稿者:konno   2018/10/20(土) 20:02
    8387 番 10♯ さんへのコメント    コメント数 1

> この件でVTDOSに手を入れてログを取ったりしてちょこっと追っかけてみたけど、
> これやるの?って所まで来てる(精神的に

10#さん、ご面倒をおかけして、すみません。

SCRNIBM.ASM	 の中のエラーになるルーチン
popwindow proc 	 のところで rep	movsw の手前に

	cmp	si,imgstack
	jc	popw8
	cmp	si,di				;★追加
	jbe	popw8				;★
	mov	si,[si-2]
	mov	imagep,si
_repeat
IFDEF J31
	call	putline
ELSE
	pushm	<cx,di>
  IFDEF DOSV
	pushm	<cx,di>
    IFNDEF US
	call	chkkanjilow
    ENDIF
	call	vrestore
	popm	<di,cx>
    rep	movsw				;★★★


このように、si と di のチェックを追加したら、#N でのマクロエラーで
!Abort が無くても落ちなくなりました。

これで何かわかりますでしょうか。


ちなみに、CX がゼロ以下かのチェックを入れても変わらなかったです。

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

(8375) 8390Re: si と di のチェック?  投稿者:10♯   2018/10/20(土) 21:38
    8388 番 konno さんへのコメント

このmovswのsiはおそらく窓がセーブした内容でdiが画面のバッファでは無いかと思ってるんですが、
だとするならsiとdiの比較はあまり意味が無い気はします。
ログを見るとdiがFF4Cとかって異常値になってるんですよね。
おそらく窓の表示位置が異常値になってる。
      - No.8390 -    このTreeへ    コメント元:8388 へ [リストへもどる] soft

(8375) 8392Re^2: 痩せたVz、太ったVz  投稿者:文太   2018/10/20(土) 22:27
    8387 番 10♯ さんへのコメント    コメント数 1

 ゆっくりと、お休みくだされ。さ、さ、粗茶を。
 (もうちょっと巧い表現があったんだけどなぁ。絵文字が
ないのが、いけないのかなぁ)
 む、無責任。
 うーん、でも、お休みじゃないですか。もうすぐ日曜だし。


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

(8375) 8394Re^3: 痩せたVz、太ったVz  投稿者:10♯   2018/10/20(土) 22:32
    8392 番 文太 さんへのコメント    コメント数 1

休日にこれはやりません
      - No.8394 -    このTreeへ    コメント元:8392 へ [リストへもどる] soft

(8375) 8395Re^4: 痩せたVz、太ったVz  投稿者:文太   2018/10/20(土) 22:45
    8394 番 10♯ さんへのコメント

 正しい! に1票。

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

(8375) 8389Re^5: VTDOS+VZ で #N、#P でのエラー  投稿者:konno   2018/10/20(土) 20:18
    8381 番 文太 さんへのコメント    コメント数 2

>  で、落ちるのはvtdos環境に限定されていないと思います。今、純DOSで
> expand.defを0expand.defにリネームして、
> === tagl_f5.def v.06 ===
> * M
> 24 [F05] "検索文字列の取得"
>  のマクロを再カスタマイズ、検索窓で[F05]したら、マシンが落ちました。

これは環境によって落ちたり落ちなかったりしているのかも。
つまりメモリのどこかを壊しているが、たまたまそこで落ちないだけとか。

そうだとすると、VTDOSのチェックは、VZが異常になっていることを
教えてくれているということで、マクロや環境を見直した方がいいと
いうことかもしれませんね。

DOSのメモリ管理は厳密ではないとはちょっと思いますね。

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

(8375) 8391暗闇の中の僕  投稿者:文太   2018/10/20(土) 22:12
    8389 番 konno さんへのコメント    コメント数 1

(A)
>これは環境によって落ちたり落ちなかったりしているのかも。
>つまりメモリのどこかを壊しているが、たまたまそこで落ちないだけとか。
 すいません、話が見えておりません。

 検索窓を出す、&z("xxx") >*をする、xxx.defは%vzdef%に存在しない。
 これで落ちない環境ってあるのでしょうか?
 申し訳ないことに、vtdos環境ではやっていないのですが、DOS, WinMEでは、
上でしっかり100%落ちました(実験2回ですが)。
 窓落とすのもマシン落とすのも嫌い。

 通じていると思いますが、s==0の編集モードでは、エラーメッセージが
出て、落ちません。


 こちらは僕が完全に話の流れを見失ったのかもしれませんが、上の件と、#N
は繋がってるのですか? 「ここで繋がっていたでしょう!」というばあい、
発言番号でポイントしていただけますでしょうか。
 #Nって、sort.defから来てますよね?
 (#Nって、よっぽど特殊なファイル名?を指定しないとファイルオープン
に成功するのじゃなかったでしたっけ? これでは上のファイルオープン
失敗の&z("")の話とのリンクがない???)

 上の件(A)は、&z("")の手抜き仕様(仕様は仕様)みたいに想像していました。

 ご面倒でしたら、スルーしていただいて構いませんよ。
 何か、僕に考えられることは、もうないような、気が、して、おりまして、、、。


>マクロや環境を見直した方がいいということかもしれませんね。
>DOSのメモリ管理は厳密ではないとはちょっと思いますね。
 話が見えません。m(__)m

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

(8375) 8393Re: 暗闇の中の僕  投稿者:10♯   2018/10/20(土) 22:31
    8391 番 文太 さんへのコメント    コメント数 2

90 [F11] ""
   &z("xxx") >*

これで窓(なんでもいい)でF11押すと落ちます。

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

(8375) 8396Re^2: 暗闇の中の僕  投稿者:文太   2018/10/20(土) 22:48
    8393 番 10♯ さんへのコメント

 でしょ? だから、&z("xxx")をxxx.defがないときに、窓で、
してはいけない、&z("")の仕様、なんでしょ? >konnoさん, too
      - No.8396 -    このTreeへ    コメント元:8393 へ [リストへもどる] soft

(8375) 8400Re^2: 暗闇の中の僕  投稿者:konno   2018/10/21(日) 00:18
    8393 番 10♯ さんへのコメント    コメント数 1

> 90 [F11] ""
>    &z("xxx") >*
> 
> これで窓(なんでもいい)でF11押すと落ちます。

DOS窓やMSDOSPlayerではやっぱり私の環境では落ちなかったです。
私家版は弄っているので、オリジナルVZで確認しました。


MSDOSPlayerでは、
#N 窓では、エラー表示は出ますが、黄色いマクロコードは表示しません。
ESC 2回までは画面が変化なし。
ESC 3回目で入力窓が消えるので、画面の再表示になっているのでしょう。


DOS窓では、
げげ、オプションエラーのせいか、起動前に窓が落ちた。
高橋版も同様でした。
修正前の公開版VZk07t1 では、カスタマイズエラーと出ますが起動成功。
Rf オプションが無いからですね。

で、#N 窓では、エラー表示が出て、黄色いマクロコードも表示しました。
ESC 1回で、画面にゴミが表示されます。
ポップウインドウで、違う領域のメモリを画面に書き込んでいると思われ。

ESC 3回目で入力窓が消え、画面も再表示されて正常に戻ります。
その後、おかしくなりやすいファイラーコマンドなども特に異常なしです。


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

(8375) 8404Re^3: 暗闇の中の僕  投稿者:10♯   2018/10/21(日) 01:19
    8400 番 konno さんへのコメント    コメント数 1

VTDOSでもセグメントラップアラウンドチェックでアボートするようにしなければ、
素知らぬ顔して動き続けると思います。

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

(8375) 8405うーむ  投稿者:文太   2018/10/21(日) 01:28
    8404 番 10♯ さんへのコメント

 (またしてもどこに繋げてよいのか分からない。直近のここに失礼します)

#8273

2018-10-09 23:49:11 VZ(15F3) 15F3:DC5B 'REP MOVSW 命令ラップアラウンド'
AX=000C BX=269C CX=009F DX=FF7D SI=2440 DI=FFE4 BP=CF52 DS=D000 ES=C000 FLAGS=0206
CS:IP=15F3:DC5B
15F3:DC4B 67 EB 8E C0 58 8B F7 36 8B 3E 40 06 51 56 F3 A5 

 この話、ここから始まっているんですよね。
 で、


#8349 (sort.defのコード)
	pf[=pr,bl[=kp-k,#N #P #m  
	(r<0||wa..13+v<bl+v) bl],pf],?{ #C r+,>e}		;<v>僕、読んでませーん。

 の#N #P に何かあるということになった(???)
 僕は、マクロコードを説明しただけです。ここに何かあるなんて言ってません。


#8375 
VTDOS+VZ でファイル編集中に #N や、#P で、拙作の TAGL_F5.DEF を実行すると

 うーん、僕も、#8273 のことを後で考えていたとき、その前に、何かが起こって、
デバッグエラーコードが指すルーチンは、おかしなsi, diをもらって発狂したんだろう、
そのルーチン(pushwindow)に問題があるわけではなく、と思ったのです。教えて
もらって、そう想像したのです。

#8309

>> 改めて調べてみたら該当箇所はscrnibm.asmのpushwindowでした。
>> ざっと見た感じではfarsegの内容?のように思えますが、
>> これが何なのか…

>私も確認しました。
>これはおそらく、メニューウインドウの裏のテキストを退避、復帰している
>のだと思います。

 すると、今回の件も、そもそも、&z("")に手抜きの仕様があり、#Nで起きていることは
「おかしなsi, diをもらって発狂」という事態なんじゃないのかな、sort.defの#N #P
と繋げるべきなのかなぁ、などと思っています。

 それより、sort.defが#Nの箇所で狂っている、って事実は確認されたのかなぁ、と
いうことが、少し気になりました。


 総じて、引っ込んでいたほうがいいようですね。そうさせて頂きます。お休みの日です。
安息日です。敬虔なクリスチャンなのです。嘘です。クリスチャンは嘘をつきません、
たしか。だといいな。

 あ、まだ休んでない。休みましょうよ、疲れた。


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

(8375) 8397まとめの試み  投稿者:文太   2018/10/20(土) 23:04
    8389 番 konno さんへのコメント    コメント数 1

 もちろん、僕にはVzのソースを読むことなんてできません。
 い、いつか、、、。

in #8375 konno wrote:
(上に逆アセコード)
>ここは、入力窓ルーチンの窓を閉じるところですね。
 これをみて、

in #8376 10# wrote:
>画面の出力座標かサイズに問題が起こってるようですね。

 細かい点がちゃんと分かっているわけでもない文太は、偉そうに

in #8382 文太wrote:
>「画面の出力座標かサイズに問題」。これに一票。
>vz.comの問題だと思う。
 とか書いてます。窓が出るか、出ないか、この違いだ、と。


 下がkonnoさんの仮説ですが、うーん、ですよね。
>SORT.DEF も、バックアップルーチンで、#N を使用していますが、
>何かエラーが出ていた気がします。


>MSDOSPlayer や、DOS窓では、マクロエラーがあっても落ちません。
>この辺に何かありそうな気がするのですが。
 検索窓で&z("xxx") >*をする、xxxは存在しない。
 これで、落ちませんか? 純DOSで落ちる場合、Vz的には
落ちるのが正しい、というのが僕の判定なのですが。


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

(8375) 8398Re: まとめの試み  投稿者:konno   2018/10/20(土) 23:38
    8397 番 文太 さんへのコメント    コメント数 2

> >MSDOSPlayer や、DOS窓では、マクロエラーがあっても落ちません。
> >この辺に何かありそうな気がするのですが。
>  検索窓で&z("xxx") >*をする、xxxは存在しない。
>  これで、落ちませんか? 純DOSで落ちる場合、Vz的には
> 落ちるのが正しい、というのが僕の判定なのですが。

ここは、同じ実験をした結果なので、手順を間違えていなければ
どちらも事実だと思います。
VTDOSでは、REP 命令でチェックしているために落ちていますが
DOS窓やMSDOSPlayerではそこにチェックルーチンはありません。
そして、私の環境では落ちなかったのです。

純DOS環境は今無いので、私の環境ではどうなるかわかりません。
でも、すぐにVZが落ちることはなかったですね。
#N などの入力窓で出た記憶は無いので。

マクロがエラーになると、画面下に黄色くマクロコードが出ますよね。
私のマクロはバグが多いので昔からよくこの状況に会っていますが
このエラーが出ると大抵マクロの動作がおかしくなって、VZを再起動
するはめになっています。
ポインタやスタックが狂ってしまうんでしょうね。


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

(8375) 8399Re^2: まとめの試み  投稿者:10♯   2018/10/20(土) 23:54
    8398 番 konno さんへのコメント    コメント数 1

VTDOSで見る限りは、V-TEXTの疑似テキストバッファに対して、
その逸脱した位置に書き込みを行ってるようですが、
他の環境でも同じ事が起こっていると仮定すると、
疑似テキストバッファがどこに置かれてるかによって
その後の挙動は変わってくるでしょうね。

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

(8375) 8401Re^3: まとめの試み  投稿者:konno   2018/10/21(日) 00:30
    8399 番 10♯ さんへのコメント    コメント数 1

> VTDOSで見る限りは、V-TEXTの疑似テキストバッファに対して、
> その逸脱した位置に書き込みを行ってるようですが、
> 他の環境でも同じ事が起こっていると仮定すると、
> 疑似テキストバッファがどこに置かれてるかによって
> その後の挙動は変わってくるでしょうね。

外しているかもですが
私の見た感じでは、入力窓のプッシュポップは、表示画面に対して実行して
いると思ったので、テキストデータには影響ないのかなと思いました。

あ、テキストバッファというのが、VRAM のことですか。

純DOS時代もマクロのバグで画面がおかしくなったり、ファイラーコマンドの
キーがずれたり、マクロが起動しなくなったりはよくありましたが
VZが即座に落ちたというのは、QVIEW.DEF (DOS窓)くらいの記憶です。

たぶんVZが即落ちしたら即座にマクロを修正して、憶えていないだけかも。(^^;


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

(8375) 8402EMSがらみと言う  投稿者:文太   2018/10/21(日) 00:56
    8401 番 konno さんへのコメント    コメント数 1

 (どこに繋げていいのか分からないので、ここに)

 MS-DOS 6.2Vの環境で、#Nの窓で試しました。
 s==1なんて一般論でなく、#Nの窓にこだわっていたわけですね。
 お二人のやり取りを見ていたら、以下にあまり深い意味があるような気は
しないのですが、いちおう報告です。
 落ちました。しかし、今日は、こんなメッセージが出て、エンターを押して
マシンを再起動してね、と。
 「EMM386はエラー#6をアプリケーション内のメモリアドレスに見つけました。
0048:096B etc etc」
 アプリケーション内っていうから、Vzかと思ったら、DOSのお腹じゃないの?
とだけ思いました。
 必要とあれば追試しますが、僕が口を出せる領域ではないですね。

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

(8375) 8403Re: EMSがらみと言う  投稿者:10♯   2018/10/21(日) 01:12
    8402 番 文太 さんへのコメント    コメント数 1

ttp://radioc.web.fc2.com/weblib/ms/dos62v/405963.htm

どういう訳かあらぬアドレスにジャンプしたようですね。
あらぬアドレスが書き換えられたのであればあらぬアドレスにジャンプすることも起こりえるでしょう。
例えばスタックのリターンアドレスが書き換わったとか。
      - No.8403 -    このTreeへ    コメント元:8402 へ [リストへもどる] soft

(8375) 8406Re^2: EMSがらみと言う  投稿者:文太   2018/10/21(日) 01:34
    8403 番 10♯ さんへのコメント

 ありがとうございました。
 こんなことが調べられるとは、、、。

EMM386.EXEのエラー(Exception Error)について
#6   Invalid opcode  (無効オぺコード)

 どっか変なところへ飛んでいった。
 お休みなさい。

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

(8375) 8407Re^2: まとめの試み  投稿者:文太   2018/10/21(日) 11:12
    8398 番 konno さんへのコメント    コメント数 1

Bunta wrote:
>>  検索窓で&z("xxx") >*をする、xxxは存在しない。
>>  これで、落ちませんか?

konno wrote:
>ここは、同じ実験をした結果なので、手順を間違えていなければ
>どちらも事実だと思います。〔=MSDOSPlayer や、DOS窓では、
>マクロエラーがあっても落ちません。〕
>VTDOSでは、REP 命令でチェックしているために落ちていますが
>DOS窓やMSDOSPlayerではそこにチェックルーチンはありません。
>そして、私の環境では落ちなかったのです。
>
>マクロがエラーになると、画面下に黄色くマクロコードが出ますよね。
>私のマクロはバグが多いので昔からよくこの状況に会っていますが
>このエラーが出ると大抵マクロの動作がおかしくなって、VZを再起動
>するはめになっています。
>ポインタやスタックが狂ってしまうんでしょうね。

(A)
#N &z("xxx") >*		;xxx.def存在せず

 というコードで、落ちたり、あるいは、致命的打撃を受け、その後Vz
の再起動を余儀なくされたりする。
 &z()は、s>0でのエラーチェックが弱いので、si, di(たとえば)を
ぐちゃぐちゃにする。
 #N時に&z()されると、まだ#Nは処理を終了していないのに&z()に
「ポインタやスタックを狂わされている」ので、落ちる、あるいはやがて
再起動ということになる。

 #Nの問題なのだろうか、というのが、変わらぬ(進歩しない)僕の疑問
です。

>MSDOSPlayer や、DOS窓では、マクロエラーがあっても落ちません。
 を僕は、ここ以降の記述も考慮して、上で「致命的打撃を受けたけれど」
と解釈しました。
 (A)のあと、ふつうにVzで作業を続けられる状態【だった】のですか?
続けられる状態【なの】ですか?

 konnoさんのvtdos+vz.comにむけての意図は理解しているつもりです。
 上の僕の疑問点に回答をいただいても、もう僕にできることはないだろう、
と思っております。
 話の整理をしようとしているだけで、2年後の僕に、状況を分かりやすく
してやっているだけです。


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

(8375) 8408Re^3: まとめの試み  投稿者:としき   2018/10/21(日) 21:48
参照先:http://toshiki.la.coocan.jp/
    8407 番 文太 さんへのコメント    コメント数 3

話題の進行が速すぎてついていけていませんが。

> Bunta wrote:
> >>  検索窓で&z("xxx") >*をする、xxxは存在しない。
> >>  これで、落ちませんか?

#8382の文太さんのマクロ、および#8393の10♯さんのマクロをWin7のCMD窓で試して
みました。Vzは1.60t03k非常駐。
s==0でもs==1でも「c:\def\expand.defが見つかりません」のメッセージが出て
マクロは止まります。左下には黄色く「>*」が表示されています。
編集モードでは、以後、そのまま編集可能。
窓では、[ESC]で抜けると画面が乱れますが、そこで何か文字を入力すると画面は
復旧します。カーソルキーでは画面は復旧しませんでした。
なお、試した窓は検索窓とファイルオープン窓だけです。他の窓は試していません。

>  (A)のあと、ふつうにVzで作業を続けられる状態【だった】のですか?
> 続けられる状態【なの】ですか?

上記の後、正常に編集継続可能。しばらくの間、普通に編集操作を続けていました
が、ファイルが失われるようなことはありませんでした。
このことから考えて、もしかしたら、これが原因で爆弾が埋め込まれた可能性は
あるかもしれませんが、何らかの起爆スイッチが押されない限りは爆発しないの
かもしれません。もちろん、爆弾は埋め込まれていないかもしれませんが、ここ
までの調査から、その可能性は低いかと。

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

(8375) 8409&z("") on dos6.2  投稿者:文太   2018/10/21(日) 23:07
    8408 番 としき さんへのコメント    コメント数 2

 konno版07t(旧版) on MS-DOS 6.2Vでは、以下の結果でした。
 きれいに全部落ちました。
 ラップアランドを見直すことで、vz on vtdosの振る舞い全般が改善するので
あれば、それは僕にとっても喜ばしいことですが、、、。

=== Macrotmp by B ===;
xxx.defは%vzdef%に存在しない。
窓はもう少しあったと思うけど、いいんじゃないですか? 描画のし直しで問題が
顕在化する(そこでVzが死ぬ)と分かっているのだと思うので。
* M
50 ^^ "Macrotmp"
			;常駐			非常駐
#F &z("xxx") >*		;dead emm386 etc	dead 0で除算
;#N &z("xxx") >*	;dead 0で除算		dead 0で除算
;#O &z("xxx") >*	;dead emm386 etc	dead 0で除算
;#J &z("xxx") >*	;dead 0で除算		dead emm386 etc
*

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

(8375) 8414Re: &z("") on dos6.2  投稿者:としき   2018/10/22(月) 18:00
参照先:http://toshiki.la.coocan.jp/
    8409 番 文太 さんへのコメント    コメント数 1

>  konno版07t(旧版) on MS-DOS 6.2Vでは、以下の結果でした。

常駐と非常駐で結果が変わるというのがとても興味深いですね。
例によって勘でモノを言いますが、EMSドライバのない環境では、全てゼロ除算に
なると想像しました。

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

(8375) 8416&z("") on WinME  投稿者:文太   2018/10/22(月) 22:06
    8414 番 としき さんへのコメント


 意味ないでしょうね。

=== Macrotmp by B ===;
マシンにしろ窓にしろ、落とすの嫌だなぁ。EMSありです。
* M
50 ^^ "Macrotmp"
			;常駐(80x25)	非常駐(80x25)
#F &z("xxx") >*		;マシン落ち	マシン落ち
			;常駐(80x30)	非常駐(80x30)
;#F &z("xxx") >*	;窓落ち		窓落ち
*

*当然のことながら、このような場面で、WinMEは大変に弱いOSです。
 「マシン落ち」はOS再起動を、
 「窓落ち」はOSは落ちないが窓は落ちること
 を意味します。
*問題の切りわけのため必要な作業なのでしょうが、EMSなしのVzは、
 そのような状態でVzが起動する設定(各種バッファの縮小)を捜すのが、
 そもそも大変なことなので、パスです。

4F1A <--    2  138512  vz 1.60t -z                1B 21 29 FA
70ED        1  115920  <free>
8D3B 0007   4   72736  emsmagic

----- EMS ver4.0 (frame: 8F00h) -----       ----- XMS ver3.00 -----
handle pages   size  name                   HMA used: 61 KB by DOS
------ ----- ------  --------               EMB free: 2048 KB (max: 5120 KB)
     1     2    32k  for Vwx!
     2     6    96k  VZ

 このようにファイルをほとんど読み込んでいなくても、EMSは6ページ確保
されるvz.defでありvzfl.defです。NEC98の時代から、こうなのです。
 このノートは元XP用で、emsmagicを使わないといけないという特殊なマシンです。
ありがたいけど、これすら嫌い。このように我侭な人間には、昨今のOSでVzする
のは、やはり困難なことなのでしょう。


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

(8375) 8418&z("") on DOSモバ (dos6.22)  投稿者:konno   2018/10/22(月) 23:27
    8409 番 文太 さんへのコメント    コメント数 2

>  konno版07t(旧版) on MS-DOS 6.2Vでは、以下の結果でした。
>  きれいに全部落ちました。

#8417 で、DOSモバ 復活したので、検証してみました。

EMM386 エラー #6 で即落ちました。

うーむ、EMM386 は、メモリチェックをキチンとしているという事ですかね?

ちなみに、PC98エミュの、NP2 では問題なく動作しました。

VZ の &z は、編集モードのみ動作保証しているようで、ファイラーで誤動作は
周知徹底してますが、入力窓も駄目ということですね。


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

(8375) 8419Re: &z("") on DOSモバ (dos6.22)  投稿者:10♯   2018/10/22(月) 23:50
    8418 番 konno さんへのコメント    コメント数 1

> EMM386 エラー #6 で即落ちました。
> うーむ、EMM386 は、メモリチェックをキチンとしているという事ですかね?

既出ですが、EMM386の#6は無効命令例外ですね。
この例外は8086/88には存在しないため通常のDOSにはそのハンドラーは存在しないはずです。
これらのCPUで無効命令を実行した場合の挙動は未定義になってると思います。
仮想86モードを利用するEMM386にはそのハンドラーが存在するようですね。
通常、この状態になると言うことは、予期しないアドレスで実行してるはずなので、
8086/88ではフリーズか暴走してると思われますが、問題なく動作しているということは、
PC98では現象が発生してないように思います。

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

(8375) 8427rep 命令で矛盾があった時の動作  投稿者:konno   2018/10/26(金) 23:04
    8419 番 10♯ さんへのコメント    コメント数 2

> 既出ですが、EMM386の#6は無効命令例外ですね。
> この例外は8086/88には存在しないため通常のDOSにはそのハンドラーは存在しないはずです。
> これらのCPUで無効命令を実行した場合の挙動は未定義になってると思います。
> 仮想86モードを利用するEMM386にはそのハンドラーが存在するようですね。
> 通常、この状態になると言うことは、予期しないアドレスで実行してるはずなので、

なるほど、これが出るという事は、致命的なエラーなのだという事ですね。
ユーザー的には、エラーで落ちずに安全に止まってくれればとは思います。

> 8086/88ではフリーズか暴走してると思われますが、問題なく動作しているということは、
> PC98では現象が発生してないように思います。

PC98エミュのNP2 も落ちなかったので、そうなんですかね。

それで思ったんですが、NT系のDOS窓など、落ちないDOS環境もあるのはなぜかと。

例えば素人プログラムなどでは、CLD とSTD を間違えるとか、VZマクロでも
プログラムミスやエラー中断などで、si と di の関係がおかしくなることは
よくありそうな気がします。

そのたび窓が落ちたりしないように、rep 命令で、si と di が矛盾していたら
そのループ命令は実行しないでスルーするという風なルーチンを仕込んでいる
DOSがあるという事は無いでしょうか。
つまり、0回のループとしているとかで。

これは妄想の想像にすぎないかもしれませんが、VTDOSに現在ある、SCASB_MODE=1
というオプションは、rep 命令で矛盾があってもスルーするのですよね。
ということは、上記と似たようなルーチンになっているのでしょうか。

このモードで、矛盾を検知した時には、エラーログは出力していないですよね。
これを、エラーログ出力するようにできないでしょうか。
SCASB_MODE=2
というように、オプションで切り替えるとか。
動作がおかしいと思った時に、エラーログでチェックできれば意味があるかな
と思います。


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

(8375) 8428Re: rep 命令で矛盾があった時の動作  投稿者:文太   2018/10/27(土) 00:24
    8427 番 konno さんへのコメント

>rep 命令で、si と di が矛盾していたら
>そのループ命令は実行しないでスルーするという風なルーチンを仕込んでいる
>DOSがあるという事は無いでしょうか。

 10#さんからの解説を待ちたいところではあるのですが。
 konnoさんが目指している「方向」については、おぼろげながらも理解している
つもりです(ほんとうなのだろうか?)

 でも、ここで、konnoさんは、「si と di の矛盾」をどのようにイメージ
(「定義」は硬すぎると思うので)されていますでしょうか。

 僕ら人間は先読みができます。でも、このsi, diはないよ、という判断を
プログラムはどうすれば下せるのだろう? と思いました。
 XPのntvdmとかは、確かにそれをしてそうではあるよな、とは思っているの
ですが。
 お教えいただければ、幸いです。

 窓ないしマシンを落とすところまで行かせないような「保護回路」みたいな
ものが働いてるみたいだ、という感触はあったのですけれど。

 これを言ってはお終いですが、僕はVzのあくまでユーザとして、とにかく、
思ったとおりにVzが動かなければ何もできない、そうでなければ、そもそも
Vzをいまどき使っている意味はないと、安定のプラットフォーム、WinME or
MS-DOSでの使用を真剣に考え始め、環境整備を進めています。m(__)m


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

(8375) 8429Re: rep 命令で矛盾があった時の動作  投稿者:10♯   2018/10/27(土) 01:49
    8427 番 konno さんへのコメント    コメント数 1

既に説明していますけど、EMM386#6は定義されていない命令を実行しようとしたときに発生するもので、
通常これは予期しないアドレスにジャンプした場合か、予期していたジャンプ先が書き換えられた場合に発生します。
その直接的な原因はスタックのpush/popが狂った、スタックのリターンアドレスが書き換えられた、
ジャンプテーブルの内容が書き換えられた、ジャンプテーブルのインデックスが異常になった、
コードセグメントの一部が書き換えられた、割り込みベクタが書き換えられた
等が考えられます。

> そのたび窓が落ちたりしないように、rep 命令で、si と di が矛盾していたら
> そのループ命令は実行しないでスルーするという風なルーチンを仕込んでいる
> DOSがあるという事は無いでしょうか。
> つまり、0回のループとしているとかで。

一般的なx86プロセッサはストリング命令のセグメントラップアラウンドはそのまま処理します。
この命令にトラップを掛ける機能はありません。
例えば転送先が 8000:fff0 で転送バイト数が100hバイトだった場合、8000:fff0からffffまでに転送したのに続いて
8000:0000から00efまでに転送します。

DOSのEMM386#6の原因にストリング命令は直接的には関与していないと思われます。
間接的に関与していたりとか、双方の原因となる論理的なエラーが発生している可能性はあります。
少なくともMS-DOS/V+EMM386とNP2/NTVDMの間には非互換性があるようです。   

> これは妄想の想像にすぎないかもしれませんが、VTDOSに現在ある、SCASB_MODE=1
> というオプションは、rep 命令で矛盾があってもスルーするのですよね。

SCASB_MODE=1 はスルーしているのではなく、セグメントラップアラウンドを正確にエミュレートしています。

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

(8375) 8432Re^2: rep 命令で矛盾があった時の動作  投稿者:konno   2018/10/28(日) 02:26
    8429 番 10♯ さんへのコメント    コメント数 1

> 既に説明していますけど、EMM386#6は定義されていない命令を実行しようとしたときに発生するもので、
> 通常これは予期しないアドレスにジャンプした場合か、予期していたジャンプ先が書き換えられた場合に発生します。
> その直接的な原因はスタックのpush/popが狂った、スタックのリターンアドレスが書き換えられた、
> ジャンプテーブルの内容が書き換えられた、ジャンプテーブルのインデックスが異常になった、
> コードセグメントの一部が書き換えられた、割り込みベクタが書き換えられた
> 等が考えられます。

なるほど、VZマクロはスタックセグメントで実行されているため、マシン語マクロも
同じセグメントで動作するので、マクロのエラーや中断などでセグメントが違ってしまう
事もあるかのなと思っていました。
セグメントが違えば、そこには実行コードと違うものが存在しているので、無効命令と
なってしまうのかなと思っていました。

とすると、EMM386 の場合は、rep 命令で落ちているのではなくて、そのメモリ操作
によって、予期しない不正な場所のメモリが書き換えられたからエラーとなる。
こういう理解で合ってますかね。

VZの入力窓のポップは、退避していたVRAMデータを書き戻しているだけなので
多くても2000bytes 程度だし、辻褄が狂ってゴミデータをVRAMに書き込むだけなら
実害は無いのですが、別の場所(セグメントなど)に書き込むとしたら危険ですね。
例のマクロでEMM386 エラーが出るのはその実例ということですかね。


> DOSのEMM386#6の原因にストリング命令は直接的には関与していないと思われます。
> 間接的に関与していたりとか、双方の原因となる論理的なエラーが発生している可能性はあります。
> 少なくともMS-DOS/V+EMM386とNP2/NTVDMには非互換性があるようです。   

> SCASB_MODE=1 はスルーしているのではなく、セグメントラップアラウンドを正確にエミュレートしています。

ここが最初あれ? と思ったのですが、上の文章と合わせて読むと、非互換性に対処する
処理を追加したモードというか、互換性を高めたモードと考えればいいわけですか。


ポップウインドウの問題はVZの手抜き仕様が原因なので、VZのソースで対策した
ほうが良さそうな気がしています。
単にスルーさせるだけより、何かエラーメッセージ的なことが出来ないかなと
考えています。


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

(8375) 8435Re^3: rep 命令で矛盾があった時の動作  投稿者:10♯   2018/10/28(日) 03:58
    8432 番 konno さんへのコメント

> なるほど、VZマクロはスタックセグメントで実行されているため、マシン語マクロも
> 同じセグメントで動作するので、マクロのエラーや中断などでセグメントが違ってしまう
> 事もあるかのなと思っていました。
> セグメントが違えば、そこには実行コードと違うものが存在しているので、無効命令と
> なってしまうのかなと思っていました。

x86は全て命令実行はcsとなってますね。スタックセグメントで動作する、というのは、
csとssが同一であるということですかね?確かVzはss=dsでcsは分離でしたが、
マクロのマシン語はss配置ですか。
「セグメントが違う」というのはいろんな意味合いに取れてしまいますが、
例えばセグメントレジスタが予期しないものとなった場合は予期せぬ動作からの無効命令は
あるかもしれません。

> とすると、EMM386 の場合は、rep 命令で落ちているのではなくて、そのメモリ操作
> によって、予期しない不正な場所のメモリが書き換えられたからエラーとなる。
> こういう理解で合ってますかね。

ストリング命令が無効命令例外を発生させることはありませんが、その結果が無効命令例外に
繋がる可能性はあります。別の所に原因がある可能性もありますよ。


> VZの入力窓のポップは、退避していたVRAMデータを書き戻しているだけなので
> 多くても2000bytes 程度だし、辻褄が狂ってゴミデータをVRAMに書き込むだけなら
> 実害は無いのですが、別の場所(セグメントなど)に書き込むとしたら危険ですね。
> 例のマクロでEMM386 エラーが出るのはその実例ということですかね。

VTDOSのエラーログを見る限りdiがFFxx付近を示してるため、ここは疑似VRAMとは違う場所になります。


> > DOSのEMM386#6の原因にストリング命令は直接的には関与していないと思われます。
> > 間接的に関与していたりとか、双方の原因となる論理的なエラーが発生している可能性はあります。
> > 少なくともMS-DOS/V+EMM386とNP2/NTVDMには非互換性があるようです。   
> 
> > SCASB_MODE=1 はスルーしているのではなく、セグメントラップアラウンドを正確にエミュレートしています。
> 
> ここが最初あれ? と思ったのですが、上の文章と合わせて読むと、非互換性に対処する
> 処理を追加したモードというか、互換性を高めたモードと考えればいいわけですか。

セグメントラップアラウンドの説明は以前に行いましたので省略しますが、
これをなにがしかの実装テクニックとして活用する可能性もなきにしもあらずなんですが、
一般的なセグメントの構成は上位伸張か下位伸張かのどちらかで、通常はオフセット0000付近か
FFFF付近(スタック)に集中するため、セグメントの両端を一度に操作するセグメントラップアラウンドを
活用する設計はきわめて不自然であると言わざるを得ません。
実際にVZのソースに於いてストリング命令の箇所は全て確認しましたけど、そのようなメモリ配置を
行ってると推測される事例は見当たりませんでした。
こういった理由からVTDOSではセグメントラップアラウンドは何らかの問題の結果と見なして、
通常は致命的エラーとしています。
また、セグメントラップアラウンドのエミュレーションはコスト高になるというのも理由です。
SCAS_MODE=1は、わざわざコストを払って何らかの問題を見て見ぬふりをしてるというのが僕の認識です。

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

(8375) 8420Re: &z("") on DOSモバ (dos6.22)  投稿者:文太   2018/10/23(火) 00:22
    8418 番 konno さんへのコメント

>VZ の &z は、編集モードのみ動作保証しているようで、ファイラーで誤動作は
>周知徹底してますが、入力窓も駄目ということですね。
 いろいろありそうだよなぁ、とは思いますが、以下のようなのは、ふつうにうまく
いきましたよ。
 もちろん、expand.defがある状態で実行しました。

=== Macrotmp by B ===;
* M
50 ^^ "Macrotmp"

#F "auto" &z("expand") >*
&m("%s",ps)
*
kekka: autoexec.bat

C:\>type autoexec.bat
REM Dummy file for NTVDM
 そういうものだったんだ。

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

(8375) 8412Re^4: まとめの試み  投稿者:10♯   2018/10/22(月) 06:12
    8408 番 としき さんへのコメント    コメント数 1

例のマクロをVTDOS上で、80X30の画面サイズで実行したら正常に動作しました。
画面サイズに限界点があるようですね。

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

(8375) 8413Re^5: まとめの試み  投稿者:としき   2018/10/22(月) 17:57
参照先:http://toshiki.la.coocan.jp/
    8412 番 10♯ さんへのコメント    コメント数 1

うわ、画面サイズも関係しますか。
まさか関係あるとは思わなかったので書かなかったのですが、実は#8408の実験は
いずれも80x50で行っているんですよ。

すると、人によってTcだのFwだのの値が違うわけで、画面の限界サイズも異なって
来るということが容易に予想できます。うぅん、今頃になって、Vzの暗黙の仕様
またはバグが表面化するなんて。konnoさんが簡単に手を入れられるところだと
うれしいな。
そしてSORT.DEFの場合、アセンブラで書かれている中身がアクセスしている部分が
やはりどこか限界を突破しているのでしょうけど、とりあえず、こちらは一旦
保留して、Vz本体のほうを調べたほうがいいのかも。もちろん、一つの山を攻略
するのに複数の方角からアプローチするというのも悪くはないかもしれませんが、
下手をすると二正面作戦になりかねない。

とりあえず、めざらさんがCSEGMAP.DEFを作られたいきさつのニフティのログを
再度読み返してきます。

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

(8375) 8415Re^6: まとめの試み  投稿者:10♯   2018/10/22(月) 19:43
    8413 番 としき さんへのコメント

今追試したら80X30でやっぱりダメでした。
あと、僕のテスト環境はEMS無しです。
      - No.8415 -    このTreeへ    コメント元:8413 へ [リストへもどる] soft

(8375) 8421Re^4: まとめの試み  投稿者:としき   2018/10/23(火) 01:25
参照先:http://toshiki.la.coocan.jp/
    8408 番 としき さんへのコメント    コメント数 3

とりあえず、自分のところにつけます。

すぐに引っ張り出せる古い環境というと、WinXPしかありませんでした。
そこで、#8382の文太さんのマクロ、および#8393の10♯さんのマクロをWinXPの
CMD窓で試そうとしてみました。あいにく、CMD.EXEおよびcommand.comの設定等を
忘れてしまっています。なので、CMD窓は画面サイズが80x50にしてあっても、
command.comを呼び出すと80x25に縮んでしまう。これ、command.com直呼び出し
でもこのサイズ。どうやれば80x50にできるかわからない。

それはさておき。Vzは1.60t03k。EMSは10ページ。
常駐と非常駐の両方で試してみました。
結果。
全て、#8408と全く同じ。すなわち

> s==0でもs==1でも「c:\def\expand.defが見つかりません」のメッセージが出て
> マクロは止まります。左下には黄色く「>*」が表示されています。
> 編集モードでは、以後、そのまま編集可能。
> 窓では、[ESC]で抜けると画面が乱れますが、そこで何か文字を入力すると画面は
> 復旧します。カーソルキーでは画面は復旧しませんでした。
> なお、試した窓は検索窓とファイルオープン窓だけです。他の窓は試していません。

です。
うぅん、落ちない。
みなさんとはVzのバージョンが異なるせいかなぁ。
もしかして、新しいkonno版なら落ちる、ということではありませんよね?
オプションの数値をいじれば落とせるようになるかなぁ。
      - No.8421 -    このTreeへ    コメント元:8408 へ [リストへもどる] soft

(8375) 8422落ちない悩み WinXP  投稿者:文太   2018/10/23(火) 08:58
    8421 番 としき さんへのコメント    コメント数 1

>オプションの数値をいじれば落とせるようになるかなぁ。
 落とせない悩み(笑)
 XPのntvdmが、ある意味優秀になったということなのかな?

>すぐに引っ張り出せる古い環境というと、WinXPしかありませんでした。
>command.comを呼び出すと80x25に縮んでしまう。これ、command.com直呼び出し
>でもこのサイズ。どうやれば80x50にできるかわからない。
 XPでvtdosを使用していないばあい、25行にしかなれない、というのがXP
の仕様だったんではなかったでしたっけ?

#F &z("xxx") >*

 はい、WinXP with command.com	落ちません
 はい、WinXP with vtdos	落ちます

 konno版(k07t, 旧版)+EMSあり。


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

(8375) 8423Re: 落ちない悩み WinXP  投稿者:文太   2018/10/23(火) 09:10
    8422 番 文太 さんへのコメント

http://mezala.la.coocan.jp/bbs/upload/clip.cgi?
 XPでも色々と無理すれば、できなくはなかったのですね。
 僕は荒野に一人で足を踏み入れないタイプなのだった。

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

(8375) 8424Re^5: まとめの試み  投稿者:konno   2018/10/23(火) 21:59
    8421 番 としき さんへのコメント    コメント数 1

> そこで、#8382の文太さんのマクロ、および#8393の10♯さんのマクロをWinXPの
> CMD窓で試そうとしてみました。あいにく、CMD.EXEおよびcommand.comの設定等を
> 忘れてしまっています。なので、CMD窓は画面サイズが80x50にしてあっても、
> command.comを呼び出すと80x25に縮んでしまう。これ、command.com直呼び出し
> でもこのサイズ。どうやれば80x50にできるかわからない。

これ、もしかして、#5819 の記事

> 2chの情報で、もうだいぶ前の書き込みですが、参考にさせていただき、
> Win7のDOS窓VZで30行以上の表示ができました。\(^^)/ ヤッタ-

これの事ではないですか?
Win7 ではVZで50行に出来たけれども、WinXP では、出来なかったような。


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

(8375) 8425懐かしがれない過去  投稿者:文太   2018/10/23(火) 23:38
    8424 番 konno さんへのコメント

>これ、もしかして、#5819 の記事
 懐かしい記事を紹介くださりありがとうございます。
 というのは嘘で、僕は、このやり取りについての記憶がまったく
ありません。懐かしくなれない。たったの6年前なのに。
 古い話を持ち出して恐縮ですが、emsmagic+atok8は、EMS不可で
ずっときています。Vzが起動できれば、atokがEMSにいってくれなくても、
僕の使用感としては大きな問題ではない、という感じでずっときています。
 我侭いうな、というのは、WinXP以来、しっかり仕込まれました。
 ほんとか?

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

(8375) 8426Re^5: まとめの試み  投稿者:としき   2018/10/24(水) 03:28
参照先:http://toshiki.la.coocan.jp/
    8421 番 としき さんへのコメント    コメント数 1

とりあえず、自分のところにつけます。

> すぐに引っ張り出せる古い環境というと、WinXPしかありませんでした。

このマシンに、古いVTDOSが入っていました。VTDOS122。
2010年のタイムスタンプですね。
これを起動したら、80x50で立ち上がりました。
当時の私がそのように設定したのでしょう。

それはさておき。同じマシンなのでVzは1.60t03k。EMSはたくさん。
常駐と非常駐で試してみました。
結果。
全て、#8408と全く同じ。すなわち

> s==0でもs==1でも「c:\def\expand.defが見つかりません」のメッセージが出て
> マクロは止まります。左下には黄色く「>*」が表示されています。
> 編集モードでは、以後、そのまま編集可能。
> 窓では、[ESC]で抜けると画面が乱れますが、そこで何か文字を入力すると画面は
> 復旧します。カーソルキーでは画面は復旧しませんでした。
> なお、試した窓は検索窓とファイルオープン窓だけです。他の窓は試していません。

です。
落ちません。

みなさんとの違いといったら、Vzのバージョンと、あとは、各オプションの値。
えと、私も含めみなさん、自分が普段使っているVZ.DEFで試していると思うのです
が、もしかして、例えばオリジナルというか、1993年12月6日のタイムスタンプの
DEFファイルでVzを起動して、落ちるか試してみるべきなのかもしれません。
純正というか、その設定なら状況は発生しないけど、Windows時代に合わせて、
とあるオプションの値を潤沢にしたら落ちるようになった、というようなことが
あるかも。そして、たまたま私は、みなさんが大きな値にしているところが小さな
値のままだった、とか。
あるいは、あとのバージョンで追加されたオプションを、みなさんはきちんと設定
しているけど、私は使わないからと設定をサボっていた、とか。
      - No.8426 -    このTreeへ    コメント元:8421 へ [リストへもどる] soft

(8375) 8430Re^6: まとめの試み  投稿者:としき   2018/10/27(土) 22:07
参照先:http://toshiki.la.coocan.jp/
    8426 番 としき さんへのコメント    コメント数 3

とりあえず、自分のところにつけます。

みなさんの発言から、落ちる/落ちないを拾って表にしてみました。

       発言 試験          常駐   画面      
報告者 番号 方法 結果     有無   サイズ 環境         VzVer
konno  8314 SORT 落ちる   ?      ?      VTDOS        ?
konno  8342 SORT 落ちない ?      ?      DOS窓(?)     ?
konno  8342 SORT 固まる   常駐   ?      VTDOS        榊原版
konno  8342 SORT 落ちない 非常駐 ?      VTDOS        榊原版
konno  8375 &z   落ちる   ?      ?      VTDOS        ?
konno  8375 &z   落ちない ?      ?      DOS窓(?)     ?
文太   8381 &z   落ちる   ?      ?      純DOS(6.2?)  ?
文太   8391 &z   落ちる   ?      ?      純DOS(6.2?)  ?
文太   8391 &z   落ちる   ?      ?      DOS窓(WinME) ?
10#    8393 &z   落ちる   ?      ?      VTDOS        ?
konno  8400 &z   落ちない ?      ?      DOS窓(?)     ?
文太   8402 &z   落ちる   ?      ?      DOS6.2       ?
としき 8408 &z   落ちない 非常駐 80x50  DOS窓(Win7)  1.60t03k
文太   8409 &z   落ちる   常駐   ?      DOS6.2       k07t
文太   8409 &z   落ちる   非常駐 ?      DOS6.2       k07t
文太   8416 &z   落ちる   常駐   80x25  DOS窓(Win7)  ?(k07t)
文太   8416 &z   落ちる   常駐   80x30  DOS窓(Win7)  ?(k07t)
文太   8416 &z   落ちる   非常駐 80x25  DOS窓(Win7)  ?(k07t)
文太   8416 &z   落ちる   非常駐 80x30  DOS窓(Win7)  ?(k07t)
konno  8418 ?    落ちる   ?      80x25  DOS6.2       ?(k07t)
としき 8421 &z   落ちない 常駐   80x25  DOS窓(WinXP) 1.60t03k
としき 8421 &z   落ちない 非常駐 80x25  DOS窓(WinXP) 1.60t03k
文太   8422 &z   落ちない ?      80x25  DOS窓(WinXP) k07t
文太   8422 &z   落ちる   ?      80x25  VTDOS        k07t
としき 8426 &z   落ちない 常駐   80x50  VTDOS122     1.60t03k
としき 8426 &z   落ちない 非常駐 80x50  VTDOS122     1.60t03k

純DOSは80x25と決め打ちさせていただきました。
V-TEXT使っていたらごめんなさい。
また、間違っている部分があれば、それもごめんなさい。併せて、私が見落として
いる部分や、不明で「?」としている部分を補完していただけると助かります。

この表を一見してわかることは、いろんなOSや画面サイズで事象が発生していると
いうこと。一方で、報告者に偏りがあるところが弱点ではありますが、高橋版では
全く落ちていないという状況があります。
やはりこれ、Vzのバージョンとか各人のvz.defでのオプション設定が影響している
可能性があるのではないかなぁ。

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

(8375) 8431Re^7: まとめの試み  投稿者:文太   2018/10/28(日) 00:10
    8430 番 としき さんへのコメント    コメント数 2

>純DOSは80x25と決め打ちさせていただきました。
 文太的には問題ありません。
 僕の純DOSは、MSの6.2Vです。
 たぶん正確だろうと思いますが(そうしてください)、僕のvz versionは
すべてk07tです。
 常駐・非常駐で不明の箇所は、「常駐」で統一していただいて良いと思います。

>高橋版では全く落ちていないという状況があります。
 あはははは。このあいだ作るだけ作ったのですが、どうするぅ? みたいな
ことになってます。
 k07t3(最新版)って、avか何かで変なことになりませんか。
 画面に縦方向に色が残ることがあるのですが?
 うん、縦にカーソルを動かすとavの色が残るみたい???
 Win7+vtdosの環境下での話です。他の環境は、k07tのまま。怠惰。


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

(8375) 8433k07t3 は内部ワークの位置ズレ有り、公開停止します  投稿者:konno   2018/10/28(日) 02:37
    8431 番 文太 さんへのコメント    コメント数 1

>  k07t3(最新版)って、avか何かで変なことになりませんか。
>  画面に縦方向に色が残ることがあるのですが?
>  うん、縦にカーソルを動かすとavの色が残るみたい???
>  Win7+vtdosの環境下での話です。他の環境は、k07tのまま。怠惰。

k07t3 は、内部ワークの位置をずらしていました。
TAGLIGHT.EXE などでも問題がありましたので、この版は公開停止します。

互換性を考えると、k07t1 までが良いと思います。


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

(8375) 8436Re: k07t3 は内部ワークの位置ズレ有り、公開停止します  投稿者:文太   2018/10/28(日) 13:57
    8433 番 konno さんへのコメント

>互換性を考えると、k07t1 までが良いと思います。
 了解です。それでは、t1でいきましょう!
 サンクスです。m(__)m

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

(8375) 8438Re^8: まとめの試み  投稿者:としき   2018/10/28(日) 14:22
参照先:http://toshiki.la.coocan.jp/
    8431 番 文太 さんへのコメント    コメント数 1

>  文太的には問題ありません。

例の表について、文太さんが報告を上げられた部分については、環境と常駐有無
について追記させていただきます。

>  あはははは。このあいだ作るだけ作ったのですが、どうするぅ? みたいな

えと、作れるということは、オリジナルのVzとオリジナルのDEFファイルがあると
いうことですよね。
であれば、それらを使って、DOS6.2の#N窓から&zでどうなるかの実験を行えます?

・93年版Vzと93年版DEFでDOS6.2
・konno版Vzと93年版DEFでDOS6.2
・93年版Vzと文太常用DEFでDOS6.2

最後のやつはカスタマイズエラーが出るかな。
これらの結果がわかれば、DEFファイルのオプションの値によって、すなわち各種
バッファの位置などによりバグが顕在化するのか、それとも全く関係ないのか、
ということが明確になりそうです。
ならない可能性も高いけど。

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

(8375) 8439Re^9: まとめの試み  投稿者:文太   2018/10/28(日) 15:31
    8438 番 としき さんへのコメント    コメント数 1

>ということが明確になりそうです。
>ならない可能性も高いけど。
 ならなかったと思う。

 全て非常駐です。

・93年版Vzと93年版DEFでDOS6.2	落ちる
・konno版Vzと93年版DEFでDOS6.2	落ちる(0除算)k03t3(まだ、、、)
・93年版Vzと文太常用DEFでDOS6.2	落ちる		5つエラー。Nf,dw,色3つ

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

(8375) 8440Re^10: まとめの試み  投稿者:としき   2018/10/28(日) 16:26
参照先:http://toshiki.la.coocan.jp/
    8439 番 文太 さんへのコメント    コメント数 2

>  ならなかったと思う。

そんな感じですね。
でも、今まで誰からも報告がなかったことが報告されるということは、解決できる
かどうかは別として、少なくとも解決の方向に1歩進んだことは間違いない。
誰かのせりふで
「失敗したということも大切な成果」
というようなのがありましたよね。

あと、

> ・93年版Vzと93年版DEFでDOS6.2	落ちる

これがわかったことは、私にとっては大収穫。
なぜなら、現状の私は落ちない環境を持っているわけなので、比較すれば、どこ、
または何が悪いか、絞り込める可能性があるというわけで。
もちろん、スキルその他の問題で、絞り込めない可能性のほうが高いのですけど。
あともう一つ、ある意味で純粋な環境で落ちたということは、エミュレーション
環境であるVTDOSでも落ちる必要がある、ということを意味すると思うのですが、
この私の解釈であっていますでしょうか。

えと、確認ですが、DOS6.2で落ちるということは、リセットが必要になるという
ことでよろしいですよね。EMMあたりがエラーをはくか、単に黙ってフリーズする
か、そのあたりは別として。なぜ、それほど特殊とも思えないような設定による
不具合が今まで発覚しなかったのか、というのも不思議な気はします。

とりあえず、私が次にできることは、落ちる環境探しです。
がんばってみましょう。
      - No.8440 -    このTreeへ    コメント元:8439 へ [リストへもどる] pre

(8375) 8441Re^11: まとめの試み  投稿者:文太   2018/10/28(日) 17:58
    8440 番 としき さんへのコメント    コメント数 1

>とりあえず、私が次にできることは、落ちる環境探しです。
>がんばってみましょう。
 がんばってください。爆。
 ポケ3で落ちるでしょう?

>環境であるVTDOSでも落ちる必要がある、ということを意味すると思うのですが、
>この私の解釈であっていますでしょうか。
 さて。vtdosはともかく、僕は前に「VZ的に落ちるのが正しい」と表現しました。

>えと、確認ですが、DOS6.2で落ちるということは、リセットが必要になるという
 はい。窓がありませんので、リセットです。

>それほど特殊とも思えないような設定による
>不具合が今まで発覚しなかったのか、というのも不思議な気はします。
 そうですかねぇ。特殊ですよ、この「#F (#N) &z("xxx") >*」に限って言えば。
 僕はやったことがありそうな気がしますが、かなり間抜けてますよ、これ。
ちゃんとロード関数を【書いて】いながら(これをマニュアル操作する人は
まずいない)、該当デフがvzdefディレクトリにないのですから。
 あるいは、そのときに書かず、既にvz.defに書いてあったとしても、vz.def
はあるのに、他のデフはないのですから。
 僕のように、病気で、何台もマシンを管理して、USBメモリからがばっと
defs をコピーするなんて、少なくとも昔はそんなこと誰もしませんでしたよ。
 こんなことが普通に可能になったとき、Vzerの数は、、、。
 USBメモリ一般化、たぶん2003年近辺。

 感触としては、まだマシンの設定が済んでなくて、落ちた、いけね、俺が
いけない(Vzの手抜きとは思わない)となってたんじゃないですかね。
 Win95でも、すでに、色々ありましたから。
 僕は、Win95でniftyしながら、NEC98でVzしてました。
 まず、皆がWindowsを嫌がり、最初、誰もがかなりの低レベルからスタート
した時代とか。dirwriteで、WinのLFNをぐちゃぐちゃにしちゃった、とか。
 やばい、懐古モードだ。


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

(8375) 8448Re^12: まとめの試み  投稿者:としき   2018/10/28(日) 22:33
参照先:http://toshiki.la.coocan.jp/
    8441 番 文太 さんへのコメント

>  ポケ3で落ちるでしょう?

あ゛〜、引っ張り出してくるのがちょっとだけ面倒。
PC-98でも落ちなかったくらいだから、もしかしたらポケ3でも落ちないかも。

>  そうですかねぇ。特殊ですよ、この「#F (#N) &z("xxx") >*」に限って言えば。

あ、そうか。
マクロ名の間違い、というか、存在しないマクロファイルを指定しなければ発現
しないわけか。特殊というか、確かに、悪条件が重なる必要がありますね。

>  USBメモリ一般化、たぶん2003年近辺。

いや、フロッピーだって、その気になれば。

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

(8375) 8453Re^11: まとめの試み  投稿者:としき   2018/10/29(月) 11:19
参照先:http://toshiki.la.coocan.jp/
    8440 番 としき さんへのコメント    コメント数 1

> とりあえず、私が次にできることは、落ちる環境探しです。

どうも再現性が不安定なんですが、落ちそうなマシンに当たりました。

先の、VTDOS122が入っていたマシンよりももっと長く使っていないマシンが出て
きました。WinXPマシンですが、中に入っていたファイルから、それなりに使って
いたのは2009年ごろが最後みたい。
これに入っていたVzはk08q2。
奇しくも実家のPC-98に入っていたのと同じバージョンですが、あたりまえですが
こちらはDOS/V版です。おそらくPC-98と同時にバージョンアップをしたのですが、
こちらのマシンは新居に運んでそのまま触らなかった、というパターンかと。

このマシン、まだそんなに何回も試していませんが、いろいろと不安定。
まず、デスクトップにMS-DOSのアイコンがあるのですが、こいつが起動しない。
スタートメニューからファイル名指定ならCOMMAN.COMで起動するし、CMD窓からの
Vz起動も可能ですが、当時の私はなぜ、使えないアイコンをデスクトップに放置
していたのやら。
そして、&zの試験マクロを実行させると、一発でNTVDMエラーが出たこともある。
その他にも、CMD窓から起動させたときだったかな、エラーは出なかったのだけど
勝手にCMD窓に戻ったり、検索窓からの実行時かな、窓が固まってしまって閉じる
ボタンで強制終了する必要があったり。


とりあえず、これで手元に、落ちる環境と落ちない環境がそろいました。
共通点はWinXPというだけ。
Vzのバージョンは異なるし、おそらく、DEFファイルも異なることでしょう。
いろいろと環境を入れ替えて、何が悪いか切り分けたいと思います。
あ、あと、Vzのオリジナル版も確保しました。
ということで、93年版、99年版、06年版の比較もできます。
konnoさんの手元では99年版でも落ちているようなので、私の手元で99年版が落ち
る、または落ちない条件が特定できればうれしいのですが、難しいかな。
仮に条件が特定できたとして、それが回避できるか否かはもっと難しい問題かと。

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

(8375) 8461Re^12: まとめの試み  投稿者:としき   2018/10/30(火) 22:32
参照先:http://toshiki.la.coocan.jp/
    8453 番 としき さんへのコメント

> どうも再現性が不安定なんですが、落ちそうなマシンに当たりました。

う〜ん、どうもよくわからん。
もしかしたら、ハードウェアの問題も絡んでくるのかも。
とりあえず、途中経過。

試験方法としては、DOS窓、またはVTDOS122窓を開き、対象Vzのあるディレクトリ
をカレントにして、誤って別のDEFファイルを読まないようにしました。そして、
Vzを起動し、存在しないファイルを&zで呼ぶマクロのファイルをオープン。^K^で
読み込み。そのまま、そのマクロファイルを開いた状態で、新規ファイルを開く
窓と検索窓でファンクションキーから呼び出し、というもの。
マシンについては、2台のWinXPマシンで行いました。
1台は、VTDOS122の入っていたマシン、富士通の一体型デスクトップです。
もう1台はVz k08q2の入っていたマシン、東芝のノートです。
なお、DEFファイルは、93年版のCOMファイルには93年版のDEFファイルを、その他
はそれぞれ同じディレクトリに入っていたものを使っております。


さて、結果です。

       試験          常駐   画面      
マシン 方法 結果     有無   サイズ 環境         VzVer
Note   &z   落ちない 両方   80x25  DOS窓(WinXP) 931206
Note   &z   落ちる   両方   80x25  DOS窓(WinXP) 1.60t03k
Note   &z   落ちる   両方   80x25  DOS窓(WinXP) k08q2

DskTop &z   落ちない 両方   80x25  DOS窓(WinXP) 931206
DskTop &z   落ちない 両方   80x25  DOS窓(WinXP) 1.60t03k
DskTop &z   落ちない 両方   80x25  DOS窓(WinXP) k08q2

DskTop &z   落ちない 両方   80x50  VTDOS122     931206
DskTop &z   落ちない 両方   80x50  VTDOS122     1.60t03k
DskTop &z   落ちない 両方   80x50  VTDOS122     k08q2


う〜ん、これは。
VTDOS122はロバストだから、Vzがどんなバージョンでも落ちないのかもしれない
けど。でも、Vzのバージョンによって落ちるか否かが決まる、という私の仮説は
もろくも崩れ去りました。あ、落ちないというのも、単に落ちないというだけで
あって、画面は乱れまくるので、一旦コマンドラインに抜けるなりしてから編集
画面に戻る必要はあります。
でも、私の環境では、オリジナルバージョンが、なかなか落ちない。
文太さんのところでは簡単に落ちたようだし、konnoさんのところでも落ちている
のですよね。そうすると、やっぱりハードウェアの関係もあるのかも。

新しく話が出てきたのは、疑似VRAMの位置ですか。
あとで、それぞれの環境で調べてみます。

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

(8375) 8434Re^7: まとめの試み  投稿者:konno   2018/10/28(日) 02:53
    8430 番 としき さんへのコメント    コメント数 1

> 一方で、報告者に偏りがあるところが弱点ではありますが、高橋版では
> 全く落ちていないという状況があります。

高橋版では落ちていないという報告は見てないような気がします。
SORT では、私の手持ちの主なVZを全て試したので、高橋版も駄目だったです。
榊原版は、その後の追試で落ちたように思います。

&z は高橋版も試したか忘れましたが、ここのルーチンは同じなので
落ちると思います。
今試しましたが、やっぱり落ちました。
si、di のチェックを入れた私家版では落ちません。

これに関しては、VZの手抜き仕様で、こういう操作をしたらバグるという
事例だと思います。
メモリを壊す危険性があるということなので、対策はした方がいいでしょう。


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

(8375) 8437Re^8: まとめの試み  投稿者:としき   2018/10/28(日) 14:02
参照先:http://toshiki.la.coocan.jp/
    8434 番 konno さんへのコメント    コメント数 1

> 高橋版では落ちていないという報告は見てないような気がします。

そうですか、それは申し訳ありません。
#8430の表も含め、今まで何回も書いた「1.60t03k」というのは高橋版のつもり
だったのですが、99年12月19日版というのは高橋版ではなかったようです。
大変失礼しました。

> SORT では、私の手持ちの主なVZを全て試したので、高橋版も駄目だったです。

ごめんなさい。
今度は逆に、私のほうがその報告を見落としていたようです。
何番の発言に掲載されておりますでしょうか。
あの表に追記したいと思っておりますので、発言番号を教えてください。

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

(8375) 8442Re^9: まとめの試み  投稿者:konno   2018/10/28(日) 18:43
    8437 番 としき さんへのコメント    コメント数 2

> > 高橋版では落ちていないという報告は見てないような気がします。
> 
> そうですか、それは申し訳ありません。
> #8430の表も含め、今まで何回も書いた「1.60t03k」というのは高橋版のつもり
> だったのですが、99年12月19日版というのは高橋版ではなかったようです。
> 大変失礼しました。

あう、す、すみません、私が見落としていただけでした。m(__)m
こちらこそ大変失礼いたしました。
ごめんなさい。m(__)m


> > SORT では、私の手持ちの主なVZを全て試したので、高橋版も駄目だったです。
> 
> ごめんなさい。
> 今度は逆に、私のほうがその報告を見落としていたようです。
> 何番の発言に掲載されておりますでしょうか。
> あの表に追記したいと思っておりますので、発言番号を教えてください。

試したのは、#8342 です。

> SORT.DEF(高橋版)を色々な環境で試してみました。

> ここからは、SCASB_MODE=0 のVTDOS環境です。
> 
> ・VZS 榊原版VZ
> 常駐ではソート実行時に固まった。
> 非常駐では動いた。何で?
> 
> ・その他のVZは皆駄目でした。
>  なお、非常駐VZだと、エラーになってもVZが落ちるだけで
>  VTDOSは動き続けますね。

このように書いたので、これではわからないですよね。
事象を正確に伝えるのも把握するのも難しいものだと改めて思いました。


ところで、私も思い込みで書いてしまったのは、#8430 の記事で

> この表を一見してわかることは、いろんなOSや画面サイズで事象が発生していると
> いうこと。一方で、報告者に偏りがあるところが弱点ではありますが、高橋版では
> 全く落ちていないという状況があります。
> やはりこれ、Vzのバージョンとか各人のvz.defでのオプション設定が影響している
> 可能性があるのではないかなぁ。

ここを読んで、あれ? と思ったからですが、私が高橋版と書かなかったのと逆に、
としきさんは、高橋版でテストしていたんですね。

#8416 の文太さんの環境は、Win7のDOS窓ではなくてWinMEのDOS窓だと思ったのですが。
つまり、私が読み間違えていなければ、NT系のDOS窓ではどのVZも落ちないという認識です。


VTDOS122 では、&z テストが落ちないんですね。
それで、過去ログを見てみたら、#6582> 20100326 0125	REP MOVSB セグメントラップアラウンド修正・LHA対応
> 20100123 0122	ストリング命令セグメントラップアラウンドチェック不具合修正
> これで、もしかして、と思い、VTDOS Ver121 でSORT.DEFを試してみたら
> 無事に動きましたよ。

とありました。
この辺のVTDOS は何かが違うのかもですね。


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

(8375) 8443Re^10: まとめの試み  投稿者:文太   2018/10/28(日) 18:53
    8442 番 konno さんへのコメント

>#8416 の文太さんの環境は、Win7のDOS窓ではなくてWinMEのDOS窓だと思ったのですが。
>つまり、私が読み間違えていなければ、NT系のDOS窓ではどのVZも落ちないという認識です。
 konnoさんが正しいです。僕は見落としてました。

>それで、過去ログを見てみたら、#6582

>> 20100326 0125	REP MOVSB セグメントラップアラウンド修正・LHA対応
>> 20100123 0122	ストリング命令セグメントラップアラウンドチェック不具合修正
>> これで、もしかして、と思い、VTDOS Ver121 でSORT.DEFを試してみたら
>> 無事に動きましたよ。

 す、すごい。執念。

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

(8375) 8446Re^10: まとめの試み  投稿者:としき   2018/10/28(日) 22:21
参照先:http://toshiki.la.coocan.jp/
    8442 番 konno さんへのコメント

> #8416 の文太さんの環境は、Win7のDOS窓ではなくてWinMEのDOS窓だと思ったのですが。

あ、本当だ、表が間違っている。あとで訂正します。
タイトルを読まずに、本文だけ読んで思い込みで表を作った模様です。
いや、タイトルを読んだ上で転記ミス、という可能性もあるけど。

> この辺のVTDOS は何かが違うのかもですね。

その可能性はありますね。
ただ、現在のVTDOSの挙動の方が正当というかエミュレーション度合いが高いの
かもしれません。つまり、落ちるほうが正解、という意味で。

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

(8375) 8444Re^7: まとめの試み  投稿者:としき   2018/10/28(日) 22:13
参照先:http://toshiki.la.coocan.jp/
    8430 番 としき さんへのコメント    コメント数 2

例によって、自分のところにつけます。

私の持っているPC-98時代のフリーウェアに対する引き合いが来たもので、実家に
来ています。ついでなんで、&zの実験をしました。かなり意味ないと思うけど。
Vzのバージョンはk08q2。NECのDOS6.2ですが、画面は30biosで80x30です。

[F11]にキーをアサインして、編集画面で起動すれば、ごく普通に、左下に黄色く
「"xxx"は入力できません」のメッセージと *> のマーク。
ところが、次に#Nの窓で[F11]を押しても、マクロが無反応。黄色いメッセージも
出ないし、特に何かが落ちるということもない。PC-98だからかなぁ。
念のため、#Oの窓でも同じ状況であることを確認。
次、検索窓では[F11]を押したら、これは危ない。
テキストVRAMの裏のG-VRAMに、何か怪しげなビットが現れました。
つまり、明らかに、変なメモリに変なデータを転送している。
ただ、それだけ。落ちない。以降の挙動に関しては、#8408と全く同じ。すなわち、
編集モードに戻ったら、以後、そのまま編集可能。
窓は、[ESC]で抜けた直後は画面が乱れますが、そこで何か文字を入力すると画面
は復旧します。カーソルキーでは画面は復旧しませんでした。

おそらく、かなり高い確率で、使い続ければ何かが起こるのでしょう。
ただ、スクロールとカーソル移動、それにほんのちょっとの文字入力という程度
だと、30分あまりの継続使用では落ちませんでした。


うぅん、なぜに落ちない。

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

(8375) 8445Re^8: まとめの試み  投稿者:10♯   2018/10/28(日) 22:19
    8444 番 としき さんへのコメント    コメント数 2

この98の事例に関して言うとヒットした先がG-VRAMだったから実害が無かったんじゃ無いですかね?
DOS/Vの疑似VRAMが通常どの辺りに割り当てられているのか把握していませんけど、
もし、実際に意味のあるコードやらデーター領域の隣接する辺りであるなら、
その周辺にヒットすれば実害が出る可能性はあると思われます。

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

(8375) 8447Re^9: まとめの試み  投稿者:としき   2018/10/28(日) 22:24
参照先:http://toshiki.la.coocan.jp/
    8445 番 10♯ さんへのコメント    コメント数 1

> この98の事例に関して言うとヒットした先がG-VRAMだったから実害が無かった

あぁ、なるほど。
コードとして走る部分ではないところなら、いくら書き換えられても大丈夫、という
ことですね。
ということは、このまま継続使用しても落ちない可能性が高い、ということですね。

だんだん挙動が見えてきました。
      - No.8447 -    このTreeへ    コメント元:8445 へ [リストへもどる] soft

(8375) 8449Re^10: まとめの試み  投稿者:10♯   2018/10/28(日) 23:24
    8447 番 としき さんへのコメント    コメント数 1

> テキストVRAMの裏のG-VRAMに、何か怪しげなビットが現れました。

98の場合TEXT-VRAMが0a000h:0からで、0a800h:0からがG-VRAM青プレーンになってます。
この現象で青色のノイズが出ていればVTDOSで起こってる現象と一致すると思われます。

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

(8375) 8451Re^11: まとめの試み  投稿者:としき   2018/10/28(日) 23:49
参照先:http://toshiki.la.coocan.jp/
    8449 番 10♯ さんへのコメント

> この現象で青色のノイズが出ていればVTDOSで起こってる現象と一致すると思われます。

青です。間違いなく、青いノイズが出ていました。

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

(8375) 8450Re^9: まとめの試み  投稿者:10♯   2018/10/28(日) 23:39
    8445 番 10♯ さんへのコメント    コメント数 1

> DOS/Vの疑似VRAMが通常どの辺りに割り当てられているのか把握していませんけど、
> もし、実際に意味のあるコードやらデーター領域の隣接する辺りであるなら、
> その周辺にヒットすれば実害が出る可能性はあると思われます。

なお、この「DOS/Vの疑似VRAM」はコンベンショナルメモリー内に存在しますが、
ディスプレイドライバーが定義する場所であり、ディスプレイドライバーによってまちまちになる可能性があります。
一般的にはCGAとは別の場所に設けられるようです。

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

(8375) 8455Re^10: まとめの試み  投稿者:10♯   2018/10/29(月) 19:09
    8450 番 10♯ さんへのコメント    コメント数 1

V-TEXTは環境によって実装が異なり、疑似VRAMの割り当て位置も違っていると思われますが、
それらの情報を表示するVTI.EXEというソフトが存在します。
VTDOSでは以下のような表示になります。

ttps://www.vector.co.jp/soft/dos/hardware/se012553.html

VTI.EXE Version 1.10  (c)鯖/LP-Project,1994.

--- BIOS ($Disp.sys) ---

Video Mode          70h
Screen Size         127x62
Int 10h Vector      FFFF:0060h
DOS/V $Disp.sys     Installed.
$IAS.sys            Installed. (Not Active.)
Psuedo Text Buffer  F800:0000h
Buffer Size         7B08h (31496 Bytes)

EGA Palette  0   1   2   3   4   5   6   7   8   9  10  11  12  13  14  15  Ovr
            00h 01h 02h 03h 04h 05h 06h 38h 07h 09h 12h 1Bh 24h 2Dh 36h 3Fh 00h

--- DOS/V Extension Info. ---
Not Supported.

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

(8375) 8456Re^11: まとめの試み  投稿者:konno   2018/10/30(火) 02:02
    8455 番 10♯ さんへのコメント    コメント数 1

> V-TEXTは環境によって実装が異なり、疑似VRAMの割り当て位置も違っていると思われますが、
> それらの情報を表示するVTI.EXEというソフトが存在します。
> VTDOSでは以下のような表示になります。

おお、これがありましたね。
DOS窓では、V-TEXT が無いので、v.com というもう一つのソフトと
両方表示させてみました。


vv	; ====== Win10 DOS窓 ======
V - Video mode information
    R1.0  (C)ChaN,1993

Current Video Mode = 03h
Screen Size        = 80x28
Character Height   = 14
VRAM Mode          = A/N
VRAM Address       = B800:0000 (Real VRAM)

vti
VTI.EXE Version 1.10  (c)鯖/LP-Project,1994. 

--- BIOS ($Disp.sys) ---

Video Mode          03h
Screen Size         80x28
Int 10h Vector      08BE:0A11h
DOS/V $Disp.sys     Not Installed.   (Int 7Dh not Defined!)
$IAS.sys            Not Installed.
Psuedo Text Buffer  --- None ---
Buffer Size         1180h (4480 Bytes)

EGA Palette  0   1   2   3   4   5   6   7   8   9  10  11  12  13  14  15  Ovr
            00h 01h 02h 03h 04h 05h 14h 07h 38h 39h 3Ah 3Bh 3Ch 3Dh 3Eh 3Fh 00h

--- DOS/V Extension Info. ---
Not Supported.


; ====== MSDOS Player ======
vti
VTI.EXE Version 1.10  (c)鯖/LP-Project,1994. 

--- BIOS ($Disp.sys) ---

Video Mode          03h
Screen Size         120x32
Int 10h Vector      08EC:0A11h
DOS/V $Disp.sys     Installed.
$IAS.sys            Installed. (Active.)
Psuedo Text Buffer  F800:0000h
Buffer Size         2000h (8192 Bytes)

EGA Palette         --- Not Supported ---

--- DOS/V Extension Info. ---
Not Supported.


; ===== Win10 VTDOS =======
VTDOS|C:\VZ>vti
VTI.EXE Version 1.10  (c)鯖/LP-Project,1994. 

--- BIOS ($Disp.sys) ---

Video Mode          70h
Screen Size         126x33
Int 10h Vector      16AA:0A11h
DOS/V $Disp.sys     Installed.
$IAS.sys            Installed. (Active.)
Psuedo Text Buffer  F800:0000h
Buffer Size         40F8h (16632 Bytes)

EGA Palette  0   1   2   3   4   5   6   7   8   9  10  11  12  13  14  15  Ovr
            00h 01h 02h 03h 04h 05h 06h 38h 07h 09h 12h 1Bh 24h 2Dh 36h 3Fh 00h

--- DOS/V Extension Info. ---
Not Supported.


こうして見ると、VTDOS だけ、Video Mode 70h と認識されてますね。
これが何か関係しているのだろうか。


VTDOS121 落ちない

VTI.EXE Version 1.10  (c)鯖/LP-Project,1994. 

--- BIOS ($Disp.sys) ---

Video Mode          70h
Screen Size         100x40
Int 10h Vector      FFFF:0060h
DOS/V $Disp.sys     Installed.
$IAS.sys            Not Installed.
Psuedo Text Buffer  D000:0000h
Buffer Size         3E80h (16000 Bytes)

EGA Palette  0   1   2   3   4   5   6   7   8   9  10  11  12  13  14  15  Ovr
            00h 01h 02h 03h 04h 05h 06h 38h 07h 09h 12h 1Bh 24h 2Dh 36h 3Fh 00h

--- DOS/V Extension Info. ---
Not Supported.


VTDOS124 落ちない

BREAK=1
;PASTEDELAY=10
;USECMD=1
;TPAEXT=1
TPALOW=1

VTI.EXE Version 1.10  (c)鯖/LP-Project,1994. 

--- BIOS ($Disp.sys) ---

Video Mode          70h
Screen Size         80x25
Int 10h Vector      FFFF:0060h
DOS/V $Disp.sys     Installed.
$IAS.sys            Not Installed.
Psuedo Text Buffer  D000:0000h
Buffer Size         1F40h (8000 Bytes)

EGA Palette  0   1   2   3   4   5   6   7   8   9  10  11  12  13  14  15  Ovr
            00h 01h 02h 03h 04h 05h 06h 38h 07h 09h 12h 1Bh 24h 2Dh 36h 3Fh 00h

--- DOS/V Extension Info. ---
Not Supported.


VTDOS125 落ちる

VTI.EXE Version 1.10  (c)鯖/LP-Project,1994. 

--- BIOS ($Disp.sys) ---

Video Mode          70h
Screen Size         80x25
Int 10h Vector      FFFF:0060h
DOS/V $Disp.sys     Installed.
$IAS.sys            Not Installed.
Psuedo Text Buffer  FC00:0000h
Buffer Size         1F40h (8000 Bytes)

EGA Palette  0   1   2   3   4   5   6   7   8   9  10  11  12  13  14  15  Ovr
            00h 01h 02h 03h 04h 05h 06h 38h 07h 09h 12h 1Bh 24h 2Dh 36h 3Fh 00h

--- DOS/V Extension Info. ---
Not Supported.


VTDOS.CFG を、124に合わせても落ちる

VTI.EXE Version 1.10  (c)鯖/LP-Project,1994. 

--- BIOS ($Disp.sys) ---

Video Mode          70h
Screen Size         80x25
Int 10h Vector      FFFF:0060h
DOS/V $Disp.sys     Installed.
$IAS.sys            Not Installed.
Psuedo Text Buffer  D000:0000h
Buffer Size         1F40h (8000 Bytes)

EGA Palette  0   1   2   3   4   5   6   7   8   9  10  11  12  13  14  15  Ovr
            00h 01h 02h 03h 04h 05h 06h 38h 07h 09h 12h 1Bh 24h 2Dh 36h 3Fh 00h

--- DOS/V Extension Info. ---
Not Supported.


VTDOS124までは落ちなくて、125 以降は落ちるようです。
何が違うかは、わかりません。


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

(8375) 8457Re^12: まとめの試み  投稿者:10♯   2018/10/30(火) 02:21
    8456 番 konno さんへのコメント    コメント数 2

このサンプルだけに関して言うと、VTDOSがセグメントラップアラウンドを致命的エラーにしてる、というだけのことだと思います。
Win10のNTVDMはDOS/V相当では無く、CGAとして扱ってるようですね。あるいはJEGA?
MS-DOS/Vのサンプルがあれば、それが落ちる理由がはっきりするかも知れません。

#僕が試験したWIn10ではVTIは動作しませんでした。

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

(8375) 8458Re^13: まとめの試み  投稿者:10♯   2018/10/30(火) 14:36
    8457 番 10♯ さんへのコメント    コメント数 1

> Win10のNTVDMはDOS/V相当では無く、CGAとして扱ってるようですね。あるいはJEGA?

WinXPのNTVDMも同じVRAMだとすると、この領域でセグメントラップアラウンドが発生しても、
近い領域にUMBを確保してTSRをロードしていない限り現象は顕在化しませんね。

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

(8375) 8511Re^14: まとめの試み  投稿者:10♯   2018/11/05(月) 03:06
    8458 番 10♯ さんへのコメント

XPのNTVDMはDOS/V相当でした。
疑似VRAMはアッパー領域に取っているため、例の現象が発生しても落ちません。

VTI.EXE Version 1.10  (c)鯖/LP-Project,1994.

--- BIOS ($Disp.sys) ---

Video Mode          03h
Screen Size         80x25
Int 10h Vector      0617:19D3h
DOS/V $Disp.sys     Installed.
$IAS.sys            Not Installed.
Psuedo Text Buffer  D853:0000h
Buffer Size         1000h (4096 Bytes)

EGA Palette  0   1   2   3   4   5   6   7   8   9  10  11  12  13  14  15  Ovr
            00h 01h 02h 03h 04h 05h 14h 07h 38h 39h 3Ah 3Bh 3Ch 3Dh 3Eh 3Fh 00h

--- DOS/V Extension Info. ---
Not Supported.

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

(8375) 8462Re^13: まとめの試み  投稿者:konno   2018/10/31(水) 00:08
    8457 番 10♯ さんへのコメント    コメント数 1

> このサンプルだけに関して言うと、VTDOSがセグメントラップアラウンドを
 致命的エラーにしてる、というだけのことだと思います。

なるほど、納得です。

> Win10のNTVDMはDOS/V相当では無く、CGAとして扱ってるようですね。あるいはJEGA?

JEGA ってなんだっけ? と思ったら、昔のAXの規格ですか。
基本は、CGA なのかなとは思います。

関係ない話ですが、Win10の64ビット版にVTDOS導入するときに、漢字の片割れ
半角分しか表示しなくて、焦ったことがあります。
フォントの設定がなかなか入らないんですよ。

> MS-DOS/Vのサンプルがあれば、それが落ちる理由がはっきりするかも知れません。

MSDOS6.22 の DOSモバで試してみました。メモリカードのデータ移動が大変でした。

A:\DOS>A:\UT\VTI.EXE
VTI.EXE Version 1.10  (c)鯖/LP-Project,1994. 

--- BIOS ($Disp.sys) ---

Video Mode          70h
Screen Size         80x15
Int 10h Vector      097C:37F0h
DOS/V $Disp.sys     Installed.
$IAS.sys            Not Installed.
Psuedo Text Buffer  0AA1:0000h
Buffer Size         0960h (2400 Bytes)

EGA Palette         --- Not Supported ---

--- DOS/V Extension Info. ---
Not Supported.


DOSモードの初期状態では、VZIBMJ.COMは表示が異常で動作しません。

A:\DOS>vv
V - Video mode information
    R1.0  (C)ChaN,1993

Current Video Mode = 03h
Screen Size        = 40x25
Character Height   = 0
VRAM Mode          = A/N
VRAM Address       = B800:0000 (Real VRAM)

確かこんなだったような。
英語版VZは動くだろうか。


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

(8375) 8463Re^14: まとめの試み  投稿者:10♯   2018/10/31(水) 00:30
    8462 番 konno さんへのコメント    コメント数 1

> Video Mode          70h
> Screen Size         80x15
> Int 10h Vector      097C:37F0h
> DOS/V $Disp.sys     Installed.
> $IAS.sys            Not Installed.
> Psuedo Text Buffer  0AA1:0000h
> Buffer Size         0960h (2400 Bytes)

ディスプレイドライバーのロードアドレスは不明ですが、エントリーポイントが097c:37f0hで、
疑似VRAMが0AA1:0hとなってますね。
ディスプレイドライバーが自分自身のロードアドレスの直後に疑似VRAMを配置してると思われます。
TPAがどこからスタートしているかは不明ですけど、このセグメントのオフセット0FFxxh付近に書き込みが
行われれば何らか問題が生じるんじゃ無いですかね?
これの VMAP は見れますか?

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

(8375) 8464Re^15: まとめの試み  投稿者:konno   2018/10/31(水) 01:24
    8463 番 10♯ さんへのコメント    コメント数 1

> ディスプレイドライバーのロードアドレスは不明ですが、エントリーポイントが097c:37f0hで、
> 疑似VRAMが0AA1:0hとなってますね。
> ディスプレイドライバーが自分自身のロードアドレスの直後に疑似VRAMを配置してると思われます。
> TPAがどこからスタートしているかは不明ですけど、このセグメントのオフセット0FFxxh付近に書き込みが
> 行われれば何らか問題が生じるんじゃ無いですかね?
> これの VMAP は見れますか?

ちょっと長いですが

A:\DOS>Vmap 
VMAP Version 2.01  Copyright (C) 1989-91 by c.mos

addr PSP  blks   size  owner/parameters           hooked vectors
---- ---- ---- ------  -------------------------  -----------------------------
D403 sys    1   11376  cardlite                   1A
D6CC sys    1   11184  sramata
D989 sys    1    4640  power                      13 14 17 25 26 28 2A 6C
DAAD sys    1    4080  kkcfunc
DBAD        1     112  <free>
DBB5 <--    1    2192  dblpatch
DC3F-DCFE   1    3056  <free>
E003 sys    1    3072  apmexdrv
E0C5 sys    1    1552  sounddrv
E128 sys    1    3680  ssricoh
E210 sys    1   34976  dblspace
EA9B ED25   1     112  unstick (env)
EAA3 <--    1   10256  keyb JP,932,J:\DOS\KEYBOA
ED25 <--    1    6928  unstick                    0F 33 81
EED7 EEDF   3     736  setpow
EF08 <--    1     720  dkick                      09
EF36        1     112  <free>
EF3E <--    1    1008  cmfctrl                    84
EF7E-F000   1    2080  <free>
                       --- UMB total: 100 KB ---
0271 sys    1    1104  himem
02B7 sys    1    2688  ramdrive
0360 sys    1   10416  emm386                     4B 67
05EC sys    1    4592  unfont
070C sys    6    5312  <config>
085E <--    3    4240  command                    22 23 24 2E
096A        1     256  <free>
097C <--    1   18480  mogd -v4                   10 15 16 7D
0E00 <--    1    3088  pansi                      2F
0EC2 <--    1    3888  vz 1.60t -z                1B 21 29
0FB6-9FFF   1  590992  <free>

----- EMS ver4.0 (frame: C000h) -----       ----- XMS ver3.00 -----
handle pages   size  name                   HMA used: 63 KB by DOS
------ ----- ------  --------               EMB free: 106 KB
     1     6    96k  VZ
  free    32   512k
 total    38   608k


DOSモバのディスプレイドライバーはいくつかありますが
ここでは、MOGD.COM というのを使っています。
入力窓などでのキー入力に若干問題があって、常用するには難があります。
今回&zテストではすぐに落ちず、ファイルクローズでEMM386エラーが出ました。


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

(8375) 8465Re^16: まとめの試み  投稿者:10♯   2018/10/31(水) 01:34
    8464 番 konno さんへのコメント    コメント数 2

このVMAPからすると、例の現象が発生していればVZのセグメントの
オフセット0bfc0h付近にヒットしてると思われます。
VZの版にもよりますけど、おそらくコード領域ですよね。

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

(8375) 8466Re^17: まとめの試み  投稿者:10♯   2018/10/31(水) 01:38
    8465 番 10♯ さんへのコメント

MS-DOS/Vであればオリジナル版でも検証は出来そうですね。

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

(8375) 8468Re^17: まとめの試み  投稿者:konno   2018/10/31(水) 19:43
    8465 番 10♯ さんへのコメント

> このVMAPからすると、例の現象が発生していればVZのセグメントの
> オフセット0bfc0h付近にヒットしてると思われます。
> VZの版にもよりますけど、おそらくコード領域ですよね。

たったこれだけの情報でそこまでピンポイントに分るとは驚きです。

どっちにしても&z の不具合はVZ で直すしかないと思われるので
アセンブラの再履修やります。


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

(8375) 8452PC-98のファンクションキー  投稿者:としき   2018/10/29(月) 10:20
参照先:http://toshiki.la.coocan.jp/
    8444 番 としき さんへのコメント    コメント数 1

誰が得をするんだ、という話もありますが、とりあえず備忘録として。
PC-98で例の試験マクロをアサインしたファンクションキーの挙動について。

あとから^K^でマクロを組み込んでいるわけですから、後優先の法則が働くはず
で、実際、先にファンクションキーに割り付けていた機能は効かなくなります。
でも、例の試験マクロがきちんと動いているかというと、ちょっと怪しい。

試したキーは[F01][F02][F10][F11]の4つです。
また、状況としては、編集画面、新規ファイルオープン窓、検索窓です。

先に報告したとおり、[F11]の#N窓では、何も反応がありませんでした。
ところが、[F01]では、三つの状況のすべてで無反応。
[F02]と[F10]の検索窓でも[F11]の検索窓と同じで、エラーが表示されてVRAMへの
怪しい転送が発生します。
問題は、[F02]と[F10]の#N窓。いずれも、窓が勝手に閉じます。
そして、もとのカーソルがあった位置に、半角アルファベットが1文字、勝手に
入力されていました。[F02]だと「T」、[F10]だと「Z」です。
何がどうしてこんなことが起こっているのかは不明です。

だからなんだというような話ですが、とりあえず報告まで。

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

(8375) 8454【訂正】PC-98のファンクションキー  投稿者:としき   2018/10/29(月) 11:26
参照先:http://toshiki.la.coocan.jp/
    8452 番 としき さんへのコメント

大変ごめんなさい。

> 試したキーは[F01][F02][F10][F11]の4つです。

> ところが、[F01]では、三つの状況のすべてで無反応。

単に[F01]キーが死んでいるだけでした。
ごめんなさい。

あぁ、キーボードを何とかしなくては。

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