[HOME]  [リストへもどる]
一括表示

  VTDOSで[ESC]I "カーソル位置へ挿入"不具合 - konno 22/02/21-22:10 No.10177
  ┣ VTDOSとXP(NTVDM)の共通点? - konno 22/02/26-19:34 No.10178
  ┃┗ もしかして ia32 の問題絡み? - konno 22/02/27-15:23 No.10179
  ┃ ┗ VTDOSでTPAEXT=1 は危険かも - konno 22/05/28-00:36 No.10187
  ┣ 製品版 [ESC]I マクロのバグは、#B だった - konno 22/02/28-18:06 No.10180
  ┣ VTDOS だけ実行出来ないコマンドがある? - konno 22/09/10-23:24 No.10290
  ┗ VTDOSで command /c 実行出来ない? - konno 22/09/25-18:00 No.10301
   ┗ command.comは実行ファイルのPATHに置いたら駄目 - konno 22/09/25-20:54 No.10302

(10177) 10177VTDOSで[ESC]I "カーソル位置へ挿入"不具合  投稿者:konno   2022/02/21(月) 22:10
   コメント数 4

めざらさんの掲示板 野ざらし言#4609 で今話題になっていますが
VZの [ESC]I "カーソル位置へ挿入"マクロで不具合の事例があるようです。
私も手持ちの生ログで実験してみましたが、VTDOS環境で不具合が再現しました。

以下、野ざらし言の書き込みを再掲します。

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

> > VZ(184B) 184B:149A 'REPNE SCASB 命令ラップアラウンド'
> > アプリケーションでエラーが発生しました。VTDOS を復帰します
> VTDOSでこれが出ると VZは強制終了になっています。
> 特定のマクロなどでたまに出るんですが、MSDOS Pleyer では動いたりするんですよね。
> 私も今回の実験で一度出ていました。

これ、VTDOS.CFG を見たら
SCASB_MODE=0 になっていました。

SCASB_MODE=1 にしたら、エラーは出なくなりましたが、動作に異常があります。
挿入ファイルが途中までしか入っていません。改行で区切られてはいますが。
381081byteのファイルに380844byteのファイルを挿入して、761925byte になるはずが
759882byte になっています。2043byte が失われました。

VTDOSでは、試した全てのVZで同じ状態になりました。
MSDOS Player や DOSVAXJ3 は問題ないです。

&t でトレースしてみたら、ブロック移動ループの途中で挿入ブロックが切れてきました。
つまり、ファイル末までブロックがかからなくなってきたということです。
そして、何回目かの #y の行削除でVTDOSが落ちました。

SCASB_MODE=1 にしても、同じ個所までしかファイル挿入されずに終了しています。
その直前の行が、1行で 4551byte ありました。

試しに、EMS無しで、XMSだけでVZ起動してやってみたら正常に終了しました。
試した全てのVZでこのマクロが正常に動作したのです。

これは、VTDOSの EMS とVZの間に問題があるということでしょうか。
この問題は、これ以降は私の掲示板で続けます。

としきさんの場合も何か参考になれば幸いです。

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

わかりにくいかと思うので、もう一度現時点での結論を書くと

> VTDOSの EMS とVZの間で問題が出ることがある

と思われるということです。

これから色々検証してみたいと思います。


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

(10177) 10178VTDOSとXP(NTVDM)の共通点?  投稿者:konno   2022/02/26(土) 19:34
    10177 番 konno さんへのコメント    コメント数 1

探してみたら、こんなものがありました。

> 05665/05668 xxxxxxxx  Emmett           VZBUG(2) サイレントモード関連のバグ
> (15)   97/04/15 10:58

> ■ VZバグ大全(2):サイレントモード関連のバグ

> (A)サイレントモードでの #k または #y の反復
>  サイレントモードで、非ブロックモードでの行記憶またはカット(#k、#y)を連
>   続して実行すると、ある特定の点までくると、テキストスタックに格納される文
>   字列の最後が化けることがあります。


これは非ブロックモードの話なので、今回は違うかもしれませんが

> (B)サイレントモードでの #_
>   どうやらサイレントで実行された #_ は、特定の条件下でカーソル位置ポインタを
>   算出しまちがえるらしい。

>  このトラブルは、 #_ 直後に #? などで最終行を一度表示してやれば回避するこ
>   とができます。これは #_ 直後でなければ駄目で、#38 のあとでは遅すぎます。
 
>   ・サイレントでの #_ のあとには #? &s
>  と習慣づけておくといいでしょう。


どうやらこれが関係ありそうです。
高橋版でもこのバグは潰しきれなかったような気がします。

 [ESC]I @I "I カーソル位置へ挿入" のマクロを

;	#b #_ (ct)?{ #> #m #x }
	#b #_ #? &s (ct)?{ #> #m #x }

このようにするか、&s を取ってしまうと、改善がみられました。

前回と同じ条件で実行して、ファイルサイズが一致するようになりました。
ただし、中身はおかしくなっているようです。
これはおそらく VTDOS の EMS がらみの不具合と思われます。

この実験で、榊原版VZだけは、ファイルサイズが小さくなりました。
ファイル挿入が途中で終わっているのか、それとも?


今まで実験に使用した生ログファイルは

 280,386 wf_log.cgi
 380,844 wf_log130407.cgi
 381,081 wf_log130408.cgi

このうちの 381k のファイルの途中に 380k のファイルを挿入していました。
挿入する 380k のファイルに問題があるのか確認のため、今度は
 280k のファイルの途中に 380k のファイルを挿入する実験をしました。

そうしたら、榊原版以外の VZ は正常に終了しました。
榊原版VZだけは、ファイルサイズが2バイト大きくなりました。
改行が1つよけいに入っていました。

この現象について、野ざらし言#4651 で、めざらさんの発言

> テキストスタックに複写する際に,テキストバッファサイズの境界付近に
> たまたまラインバッファサイズを超える長い行が存在した場合の振る舞い
> (結構レア?)に係ることかもしれないですね。「新発見」かも。

これが関係しているかもしれないと私も思いました。

ただ、MSDOS Player と DOSVAXJ3 では正常に動作しているのが謎なのです。
プラットフォームのメモリ管理とVZの相性で不具合が出ているのではないかと感じるのです。
VTDOSとXP(NTVDM)の共通点は、32ビットのメモリ管理で16ビットのVZを動かしているところ?

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

(10177) 10179もしかして ia32 の問題絡み?  投稿者:konno   2022/02/27(日) 15:23
    10178 番 konno さんへのコメント    コメント数 1

前回の書き込みで

> ただ、MSDOS Player と DOSVAXJ3 では正常に動作しているのが謎なのです。
> プラットフォームのメモリ管理とVZの相性で不具合が出ているのではないかと感じるのです。
> VTDOSとXP(NTVDM)の共通点は、32ビットのメモリ管理で16ビットのVZを動かしているところ?

このように書きましたが、32ビットのメモリ管理で、ふと思ったことがあります。
ちょっと前の記事ですが

#10145:MS-DOS Player 12/30版  投稿者:konno   2021/12/31(金) 

> さっそく使ってみましたが、ia32版では、自作のアプリでエラーが出ます。
> 自作アプリとは、turbo basic の古いプログラムで、VGAでないと動きません。
> 
> 実は、今までの MS-DOS Player では、エラーが出て使えませんでした。
> 軟式さんの DOSVAXJ3 では使えていました。
> 
> ia32_x86	数字4桁の入力で、OE+2?? (??は数字によって変わる)エラーで止まる
> ia32_x64	数字4桁の入力で、OE+2?? (??は数字によって変わる)エラーで止まる


MS-DOS Player でも ia32版では16ビットのアプリでエラーが出ます。
なので、今は ia32版は使っていません。
VTDOS も、ia32 を使っているとしたら、ここに共通の問題があるのではないかと感じました。


#10157:turbo basic は VTDOSで動かない  投稿者:konno   2022/01/15

> このプログラムを、VTDOS で動かしてみましたが、動きませんでした。
> エラーログを見てみると、ログが残っていました。
> 
> 2022-01-15 16:28:00 AISYO(17BA) 17CA:0EC8 'Out Byte 0043 34'
> 
> AX=2534 BX=0006 CX=0004 DX=1F10 SI=703A DI=7070 BP=17BA DS=17CA ES=0040 FLAGS=0046
> 
> CS:IP=17CA:0EC8
> 17CA:0EB8 2E F6 06 6E 34 40 75 13 50 E8 6D 27 B0 34 E6 43 
> 17CA:0EC8 EB 00 32 C0 E6 40 EB 00 E6 40 58 CF 50 FB 32 C0 
> 
> SS:SP=17CA:0072
> 17CA:0062 00 00 00 00 40 36 CA 17 46 00 CA 17 10 1F C4 0E 
> 17CA:0072 00 01 7B 03 CA 17 06 02 F6 01 CB 01 00 00 00 00 
> 
> 2022-01-15 16:28:00 AISYO(17BA) 17CA:0EDA 'Out Byte 0043 00'
> 
> AX=0100 BX=0006 CX=0004 DX=1F10 SI=703A DI=7070 BP=17BA DS=17CA ES=0040 FLAGS=0246
> 
> CS:IP=17CA:0EDA
> 17CA:0ECA 32 C0 E6 40 EB 00 E6 40 58 CF 50 FB 32 C0 E6 43 
> 17CA:0EDA FA EB 00 E4 40 8A E0 EB 00 E4 40 86 C4 F7 D8 40 
> 
> SS:SP=17CA:0072
> 17CA:0062 00 00 00 00 40 36 CA 17 46 00 CA 17 CA 17 BA 17 
> 17CA:0072 00 01 7E 03 CA 17 06 02 F6 01 CB 01 00 00 00 00 
> 
> 'Out Byte 0043 34' と、'Out Byte 0043 00' の2つのエラーがあるみたいです。

このエラーが16ビットメモリ操作の裏技に由来するとしたら?
VZはメモリの裏技をバンバン使っているようですし。
 ia32 のメモリ管理は16ビットアプリの使用には問題があるとか?
メモリの自己書き換えなどを許さない仕様とか?

VTDOS では ia32 は使っていないというのであれば私の思い違いということで。m(__)m

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

(10177) 10187VTDOSでTPAEXT=1 は危険かも  投稿者:konno   2022/05/28(土) 00:36
    10179 番 konno さんへのコメント

先日5月11日の野ざらし言#4714 の発言でVTDOS関連の情報を書きました。
こちらにも転載します。

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

"> WinXP(32),VTDOS1.22(ckwvなし)"
"> 以下略。"
"> cmd+command.comのところをVTDOSに変えただけですが、結果、VZの挙動は全く変わらず。"

ええっ、VTDOS1.22 では、OK になるんですか!
私の所では、VTDOSは今まで NG だったんですよ。

それで、VTDOS1.22 を引っ張り出して、何度か試行錯誤していたら出来ました。

VTDOS122 恐らく全てのVZ共通
Bl1024*4 OK
Bl1024*5 OK

Bl がこの範囲以外では NG になります。
としきさんの場合はこれ以外でも OK ということですか。


あと、VTDOS1.53 では、エラーで落ちてしまいました。
VTDOS1.22 と何かが違うのでしょうか。
取り敢えず、メモリ関連オプションを全部コメントにしてみたら

Bl1024*4 OK
Bl1024*5 OK

OK になりました! \(^^)/ ヤッタ-
なので、今度はメモリ関連オプションを一つづつコメント外してみたら

TPAEXT=1 NG

このオプションが駄目だったようです。なので
TPALOW=1
は問題なさそうなので設定しました。

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

これで大分安定しましたが、まだ何かあるかもしれません。

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

(10177) 10180製品版 [ESC]I マクロのバグは、#B だった  投稿者:konno   2022/02/28(月) 18:06
    10177 番 konno さんへのコメント

野ざらし言#4654 に書きましたが、ここにも再掲します。

insfile.def を見てみると、ループ中に #B を使っていません。
としきさんが、#B が怪しいとにらんでいるのは正解かもと思い
製品版の [ESC]I マクロを修正してみました。


= esci.def =

製品版の [ESC]I マクロのバグ回避は、#B を使わないこと

*m


8  [ESC]I @I "I カーソル位置へ挿入"
	?. (mr==$80)?{ &m(36) . }
	&m("カーソル位置へファイルを読み込みます")
	n=wn, c=wc,
;	#R
	#R #m					;★ 直接ファイラーへ
:A	(s)?{ &c >A }
	(wc==c)? >Z
	mr=-1,
	&s
	#W &#T(n)
:B	#W &#T(c+1)
	#b #_ (ct)?{ #> #m #x }
;	#b #_ (ct|lh)?{ #> #m }		; #x は不要  T.Tanomura 94/01/05 15:48
:C
;	#y (mb)?{ #W #< #i (ek)?? #B #W >C }
	#y (mb)??>D				;★ ブロックでなければループを抜ける
	#W #< ek[+, #i ek], #W >C		;★ #B を使わない
:D	#C &#T(n)
	#< #i (ek)?? #B
	(wc>c)? >B
 	&d
:Z	&m("")

*


これで、今まで VTDOS153 で異常が出ていたファイルも正常に処理出来ました。
サイレントのままでも、試した全てのVZで問題なく動作しました。

結論として、#B にはバグがあるということですね。
そのバグは、VTDOS や NTVDM で出やすいようだというのが今の状況です。


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

(10177) 10290VTDOS だけ実行出来ないコマンドがある?  投稿者:konno   2022/09/10(土) 23:24
    10177 番 konno さんへのコメント

最近、野ざらし言#5004 からのツリーで話題にしたのですが

FO.COM という古い公開プログラムがあって、VTDOS だけ実行できないのです。
この FO.COM はソースも公開されているのですが、BX を初期化しないまま使っていました。

野ざらし言#5045 から引用すると
---------------------------------------------

先の実験で、純DOSの MSDOS6.2 では BX を 初期化していると思われます。
同じ fo.com を使っているので、fo.com もシロだと思います。
そして、command.com も、コマンドの一つだということ。
コマンドやプログラムをメモリにロードして実行させているのは、DOS システムだということになります。

ということは、BX を汚しているのは、VTDOS だということになります。
レジスタを初期化しないまま使うプログラムは手抜きか行儀が悪いか、うっかりか。
それでも純DOSの時代は問題なかったから、わざと手抜きしていた可能性もありますね。

でもエミュレータを作る時は、基本のルールに則って作るので、ルール違反は想定外だった。
という可能性がありますね。
この事例は私の掲示板でも告知して注意喚起したほうがよさそうです。

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

ということで

> プログラムを作成するということは、ルールに則って作成するべきです。
> 手抜きプログラムは自分一人だけで使うならいいですが、公開するのは問題がありますね。

これが基本だとは思いますが、レジスタを初期化しないまま使うプログラムも有りうるということで
純DOSでは コマンド実行時にレジスタを初期化しているのだと思われます。
VTDOS はどうも初期化していないのかもしれないので、ご注意願います。
10# さん、この件、確認していただくとありがたいです。

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

(10177) 10301VTDOSで command /c 実行出来ない?  投稿者:konno   2022/09/25(日) 18:00
    10177 番 konno さんへのコメント    コメント数 1

最近 VZ1.57 のアセンブルをする機会があり、VTDOS で MK.BAT を実行したら

VTDOS1.53
C:\VZ\VZ16\VZ157\SRC>mk ibmj
ロケーションテーブルが不良です. ドライブ 5D58:
File allocation taGラーです.
Memory allocation error\
COMMAND を読み込めません. システムは停止しました.
Cannot load COMMAND, system halted

こんなメッセージが出て VTDOSが停止してしまいました。
VTDOS1.22 でも試してみましたが、同じメッセージで止まります。

VTDOS1.21 では
Cannot load COMMAND, system halted
8(0002) 9B7D:48DF '無効命令 00'
8(0002) 9B7D:48DF '致命的エラー: アクセス違反 0x02380000 0x004140D5'
VTDOSを終了します。

こんなメッセージだったかな。
最近 MSDOS player を更新して システムの環境変数に
MSDOS_COMSPEC=C:\UT\COMMAND.COM
これを追加しましたが、関係ないですよね。

調べてみると、MK.BAT の中の

command /c ac %1

ここで落ちているようです。コマンドラインで、

command /c VMAP

などとやっても同じメッセージが出て落ちました。
VTDOS で MK.BAT を実行しても落ちない時もあったようなのでわけわかです。
うーん、Windows の他のタスクが干渉しているのかなぁ。
もう少し調べてみます。

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

(10177) 10302command.comは実行ファイルのPATHに置いたら駄目  投稿者:konno   2022/09/25(日) 20:54
    10301 番 konno さんへのコメント

そういえば、非常駐VZ のコマンドラインで [Enter] で COMMAND.COM を呼び出せたよなぁ
と思ってやってみたら
 
Microsoft(R) MS-DOS(R) Version 6.20
            (C)Copyright Microsoft Corp 1981-1993.

こういう表示が出ます。VZは正常に動いているようです。
ここで、さらに command.com を呼び出してみようとしました。

VTDOS|C:\VZ>command vmap
COMMAND.COMのパスは絶対パスで与えられなければなりません.
つまり, ドライブ文字とそれに続く \ から始める必要があります.
例: C:\FDOS

COMMAND.COMは現在以下のパスを想定しています.
C:\VZ\VMAP
ファイル 'C:\VZ\VMAP' を開くことができません.

FreeCom version 0.82 pl 3 [Mar 13 2013 16:40:42]


こうなりました。あれれれ?
このメッセージは、FreeCom の command.com が出しているんですよね?
そういえば MS-DOS Player の更新時に、実行ファイルのPATHに変更していました。
#10300 で書きましたが

> MSDOS.EXE と同じところに置いて指定して見ましたが VZ常駐起動はしないようです。

よく考えたら、command.com も実行ファイルの一つでしたね。
私は command.com を色々切り替えてテストすることが多いので、実行ファイルのPATHに置いたら駄目ですね。
今回の現象は、私のポカミスが原因だったようです。

お騒がせして申し訳ありませんでした。m(__)m


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