[HOME]  [掲示板トップへもどる]  [全部表示]  [最新100]  [最新50]   [新着40] 
番号順 最新50記事     FGALVZ  

08336/08113 CRG00666 文太 回数の訂正
( 1) 18/10/14 12:22 08305:文太さんへのコメント コメント数:1

 個人的環境や使用法に依存する数値なので、どこまで有意味なのか分かりません。
 が、正確な数字が出せるときには、出しておいたほうがいいと考え、過去の記載を
「編集・修正」しようとしたのですが、このような形のほうが、記事の有用性は
ともかく、数字が読みやすいと思い、ここにこれを繋げておきます。

 文字列を同一文字列で置換すれば、正確な回数が出たのに、といちばん最初に
思ったのに、さぼっていました。


 僕のエラーログでの出現回数

A:
'REP MOVSW 命令ラップアラウンド'	76回

B:
67 EB 8E C0 58 8B F7 36 8B 3E 40 06 51 56 F3 A5
 上記のエラーダンプ、コード列		49回
(こちらには、前の僕の記事に誤記があったはずです。ずっと少なく数えていた)


 BがすべてAに含まれているのかまでは分かりません。
 「ラップアラウンド」以外で、同一のコード列が出力されていた可能性もある
でしょう。
 ちょっとしたスクリプトかマクロを書けば、これを調査することは可能ですが、
そもそも上のA、Bのデータにどれだけの意味があるのか分からないときに、
Cのデータを出す行為は不要だろうと考えました。


 最初にこの話題をあげたとき、こんなに頻繁に(多数回にわたり)、起こって
いた事象だとは思いませんでした。
 ただ、オペレーションのパターンと不具合発現のパターンには、たしかな
手ごたえ、「前にも何度もあった」という感触があったのです。そして、起きたとき、
オペレーションが、ふだんよりずっとシンプルだったのです。それで原因解明が
比較的容易かもしれないと、、、。
 ずっと深いですね、きっと。


08337/08113 BQO00549 konno Re: 回数の訂正
( 1) 18/10/14 15:56 08336:文太さんへのコメント コメント数:1

>  僕のエラーログでの出現回数
> 'REP MOVSW 命令ラップアラウンド'	76回
>  ただ、オペレーションのパターンと不具合発現のパターンには、たしかな
> 手ごたえ、「前にも何度もあった」という感触があったのです。そして、起きたとき、
> オペレーションが、ふだんよりずっとシンプルだったのです。それで原因解明が
> 比較的容易かもしれないと、、、。

そのログのVZはずっと K07t1 なんですよね。
原因究明に役立つかもしれませんので、そのエラーログをメールで
送ってくれませんか。

エラーの出たアドレスが手掛かりになるかもしれないからです。
私のログはVZのバージョンがコロコロ変わっているので特定が難しいのです。
今までは特定が無理だと思って諦めていたのです。



08338/08113 CRG00666 文太 Re^2: 回数の訂正
( 1) 18/10/14 17:08 08337:konnoさんへのコメント コメント数:1

 送らせていただきました。
 10分ぐらい経って、戻ってきておりませんので、届いているかと
思います。



08339/08113 BQO00549 konno Re^3: 回数の訂正
( 1) 18/10/14 18:33 08338:文太さんへのコメント

>  送らせていただきました。
>  10分ぐらい経って、戻ってきておりませんので、届いているかと
> 思います。

ログいただきました。
VZのどこでエラーが多いかなど色々参考にさせていただきます。



08340/08306 GST01234 10♯ Re: SWの適正値
( 1) 18/10/15 16:00 08306:文太さんへのコメント コメント数:1

僕の設定はSW1でした。
元々SW3で、SW2で運用してた時期もあったようなので、
なんらかの利点があってSW1にしてるのだと思いますが、詳細は覚えていません。
あと、SW0はなんらかの制限があったような気がします。


08341/08306 CRG00666 文太 Re^2: SWの適正値
( 1) 18/10/15 17:34 08340:10♯さんへのコメント

 ありがとうございます。
 SW0で、やばそうだと感じたら、次はSW1にしたいと思います。
 SW0,調子いいみたいですよ(100%信憑性のない発言)。

 ふと。
 「なぜそんなに古いソフトを使ってるの? 新しいのにすれば良いのでは
ないかしら? そんなに分かりやすく落ち込んで。そのため息、不幸がうつり
そうで嫌よ」
 「あのね、10年かかって英語の通訳になれたんだよ。それを次の日に
英語が敵性語だから、今日からイタリア語の通訳になれって言われている
ようなものなの。無理なんだよ。その古いソフトでなければできないことが
たくさんある。分かんないだろうけど」
 (メタファーは適材適所。フィクションです。落ち込んでません。この日
のために、周到にWinMEを準備してきました。ダイジョーブ、マイ・フレンド)

 プラットフォームは変更しますが、生涯Vzerです。
 気分の悪い思いをさせてしまいました。申し訳ございませんでした。


08342/08314 BQO00549 konno SORT.DEF(高橋版)の問題はここ?
( 1) 18/10/15 23:17 08328:konnoさんへのコメント コメント数:1

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

・MSDOS Player
ソート実行時に固まった。
&t でステップ実行したら固まらずに終了した。
其の後は普通に動くようになった。何で?

・DOS窓VZ
普通に動いた。


ここからは、SCASB_MODE=0 のVTDOS環境です。

・VZS 榊原版VZ
常駐ではソート実行時に固まった。
非常駐では動いた。何で?

・その他のVZは皆駄目でした。
 なお、非常駐VZだと、エラーになってもVZが落ちるだけで
 VTDOSは動き続けますね。


・SORT.DEF(高橋版)のオプションを変更
;	o32+64+512, ;(ec)?o|=2,		;options
	o32+64, ;(ec)?o|=2,		;options

こう変更して、バックアップ無しとしたら
普通に動いてしまった。 あれぇ?

マクロの中に
:f	&Sc(dx=pq..149,pq) &Sy(dx) &Sc(bx,"sort.$$$$$$")

こういう行があるので、バックアップのファイル名で使用していると
思われるが、どうも何かがおかしい。
それで、その後にあるマシン語を逆汗したら

	sub_1		proc	near
4E		dec	si
4E		dec	si
8B 0C		mov	cx,[si]
4E		dec	si
2B F1		sub	si,cx
3B F7		cmp	si,di
74 07		je	loc_ret_5		; Jump if equal
56		push	si
51		push	cx
E8 FFF0		call	sub_1	         	; ★★ (014E)
59		pop	cx       
5A		pop	dx       
                                 
		loc_ret_5:	         	;  xref 7810:0157
C3		retn             
	sub_1		endp     


こういうサブルーチンがあるんですが、この中で

E8 FFF0		call	sub_1	         	; ★★ (014E)

この行、自分自身を呼び出していますよね。
これ、条件次第では無限ループになってしまうのではないでしょうか。

上記の実験で固まったときは、Ctrl+Breck も効かないので
ここで無限ループになってしまったのではないでしょうか。

もしかして、これを直せたら、SORT.DEF(高橋版)の問題は解決してしまうかも。

なお、動いたと言ってもソートが正常に出来ているかはわかりません。



08343/08314 CXB00940 としき Re: SORT.DEF(高橋版)の問題はここ?
( 1) 18/10/16 00:19 08342:konnoさんへのコメント コメント数:2
参照先:http://toshiki.la.coocan.jp/

> この行、自分自身を呼び出していますよね。

sortで自分自身の呼出しと言ったら、普通、再帰だと思います。
高橋さんなら、当然、quick sortを使っていそうだし。
あと、cxもdxもdiも変えずにsiだけを変えているように見えますから、
いつかどこかで止まるような気はします。

以上、勘だけでものを言ってみました。

08344/08314 GST01234 10♯ Re^2: SORT.DEF(高橋版)の問題はここ?
( 1) 18/10/16 00:48 08343:としきさんへのコメント コメント数:1

※一回編集しています

この部分のコードを見る限りは、ある内容のバイト列とそれの2バイトの長さから成る表を逆向きにスキャンしているようですね。
これは再帰呼び出しである必要は無いように見えますけど再帰呼び出しにしている理由が分りません。
あと、終了条件が後方スキャンしてるsiのdiに対する一致なので何を出力してるのか不明です。
スキャンしてる表に問題があれば固まるので、固まるか固まらないかだけのルーチンになってるように見えます。
率直に言うと意味が分らないので不可解なコードではあります。
クイックソートのようには見えないかな?


08345/08314 BQO00549 konno Re^2: SORT.DEF(高橋版)の問題はここ?
( 1) 18/10/16 01:19 08343:としきさんへのコメント コメント数:1

> sortで自分自身の呼出しと言ったら、普通、再帰だと思います。
> 高橋さんなら、当然、quick sortを使っていそうだし。

ソートルーチンならそうでしょうが、これはバックアップのルーチンなんですよ。
バックアップのルーチンには2か所マシン語ルーチンがあり、これは後半のものです。
省略したサブルーチンの上の部分をアップします。マシン語では一繋がりです。

0100		start:
0100  8B 36 01AC	mov	si,ds:data_2e	; (7810:01AC=0)
0104  8E 1E 01AA	mov	ds,ds:data_1e	; (7810:01AA=0)
0108  33 ED		xor	bp,bp		; Zero register
010A  32 C0		xor	al,al		; Zero register
010C		loc_1:				;  xref 7810:0119
010C  4E		dec	si
010D  4E		dec	si
010E  8B 0C		mov	cx,[si]
0110  03 E9		add	bp,cx
0112  4E		dec	si
0113  88 04		mov	[si],al
0115  2B F1		sub	si,cx
0117  3B F2		cmp	si,dx
0119  75 F1		jne	loc_1		; Jump if not equal
011B		loc_2:				;  xref 7810:0138
011B  8B D6		mov	dx,si
011D		loc_3:				;  xref 7810:0120
011D  AC		lodsb			; String [si] to al
011E  0A C0		or	al,al		; Zero ?
0120  75 FB		jnz	loc_3		; Jump if not zero
0122  C6 44 FF 01	mov	byte ptr [si-1],1
0126  8B CE		mov	cx,si
0128  49		dec	cx
0129  2B CA		sub	cx,dx
012B  B4 40		mov	ah,40h		; '@'
012D  CD 21		int	21h		; DOS Services  ah=function 40h
						;  write file cx=bytes, to ds:dx
012F  72 1C		jc	loc_ret_4	; Jump if carry Set
0131  46		inc	si
0132  46		inc	si
0133  36: 3B 36 01AC	cmp	si,ss:data_2e	; (7810:01AC=0)
0138  75 E1		jne	loc_2		; Jump if not equal
013A  16		push	ss
013B  1F		pop	ds
013C  55		push	bp
013D  B4 01		mov	ah,1
013F  50		push	ax
0140  8B D4		mov	dx,sp
0142  42		inc	dx
0143  33 C9		xor	cx,cx		; Zero register
0145  B1 03		mov	cl,3
0147  B4 40		mov	ah,40h		; '@'
0149  CD 21		int	21h		; DOS Services  ah=function 40h
						;  write file cx=bytes, to ds:dx
014B  58		pop	ax
014C  58		pop	ax
014D		loc_ret_4:			;  xref 7810:012F
014D  C3		retn

バックアップファイルの書き込みルーチンのようですが、くだんの
サブルーチンへは飛んでいませんね。 あれぇ???

もしかしてあのサブルーチンはデコイか盲腸か?
バルタン星人はトラップ大統領だった・・・


> あと、cxもdxもdiも変えずにsiだけを変えているように見えますから、
> いつかどこかで止まるような気はします。

なるほど、止まるまでに64K回ループしてしまうんですね。(違うと思う)



08346/08314 BQO00549 konno Re^3: SORT.DEF(高橋版)の問題はここ?
( 1) 18/10/16 02:10 08344:10♯さんへのコメント コメント数:1

10#さん、#8345 に書いたように、このサブルーチンは使われていないようです。
でも、もし使ったとしたら

56		push	si
51		push	cx
E8 FFF0		call	sub_1	         	; ★★ (014E)

ここで、プッシュ2回してループしているので、たとえ一回のループで抜けた
としても、プッシュポップの辻褄が合わなくてハングアップしてしまうような
気がします。

とりあえず、バックアップオプションを使わなければ動作するようですが
できれば不具合の原因を突き止めたいものですね。



08347/08314 GST01234 10♯ Re^4: SORT.DEF(高橋版)の問題はここ?
( 1) 18/10/16 03:07 08346:konnoさんへのコメント コメント数:2

> 56		push	si
> 51		push	cx
> E8 FFF0		call	sub_1	         	; ★★ (014E)
> 
> ここで、プッシュ2回してループしているので、たとえ一回のループで抜けた
> としても、プッシュポップの辻褄が合わなくてハングアップしてしまうような
> 気がします。

最早どうでもいいようなミクロな話ですけど、push/popの数が一致してて
且つ、終了条件にヒットすればpopしたsi→dxの内容が使われることは無いので、
この手続きの中では問題にはなりませんね。

しかし、このマクロもマシン語コードもVZのワークを多々直接参照してるようなので、
コワいことやってるなーって素朴な印象です。
p*系の変数からオフセット足したアドレスを参照してたりとか…
マシン語コードのSSの参照先とか、waのオフセット13とかがワークのどれを見てるとか分りますか?
あと、pfにprをコピーしてたりとかしますね。
率直に言ってコワイ。


08348/08314 GST01234 10♯ Re^3: SORT.DEF(高橋版)の問題はここ?
( 1) 18/10/16 09:33 08345:konnoさんへのコメント コメント数:1

<1行目の内容><01h>
<2行目の内容><01h>
...
<最終行の内容><01h>
<各行の合計バイトサイズ>


08349/08314 CRG00666 文太 Re^5: SORT.DEF(高橋版)の問題はここ?
( 1) 18/10/16 18:45 08347:10♯さんへのコメント コメント数:1

*字句、修正しました

 まったく的はずれだったら、どうかお許しください。

 僕は、自分が逃げたとはいえ、Vzの脆弱性やvtdosの不具合が少しでもなくなって
くれることをひたすらに願っています。
 そして、10#さんは、やっぱりプロ、さすが、と驚嘆しています。背伸びをして申し
あげると、少し勉強になってもいます。

>マシン語コードのSSの参照先とか、waのオフセット13とかがワークのどれを見てるとか分りますか?
>あと、pfにprをコピーしてたりとかしますね。
>率直に言ってコワイ。

	pf[=pr,bl[=kp-k,#N #P #m  
	(r<0||wa..13+v<bl+v) bl],pf],?{ #C r+,>e}		;<v>僕、読んでませーん。
								;変数調べただけ m(__)m

 この件なのですが、間違っているかもしれませんが、内部ワークを「参照」するのは、ほぼ公認です。
 ちゃんと書き戻せば、いっときの書き換えもOK。
 バグさえなければ、コードセグメントだって、commnad.comの常駐部だって書き換えて「DOSを
騙す」(意味がちゃんと分かってません)ことも、Vzマクロはできます。

 pfにprをコピーはマクロ初心者でも、仕組みが分かればやります。
ps[=pa, nantoka syori  ps],
(バッファすり替え=検索バッファにゴミを残さない)は、この手のことの最初の一歩で(おそらく)、
ポインタの知識のある人なら、Vzマクロを始めて1週間としなくても、なるほど、と使う技です。
pf(#Nするので、ファイル名ヒストリーバッファに)にゴミを残さないためにpr(リネーム用ワーク)
とすり替えています。

 もしpfの内容を何がしかの理由で、prにコピーしたければ、histcopyで&Sh(pr,pf)(length注意)
で、c.mosさんがvz1.6で表に出してくれた関数で、できます。


@wa..13 @wb..13 @tmax 
テキスト構造体
dw  text buffer end ptr

 テキストバッファの終端を示すポインタですね。
 EMSにいることも(=異セグ)あるのではなかったでしたっけ?
 とにかく、wa..13は、テキストバッファを参照して、#Cをしていいか判断しているようです。
 ラインバッファなら異セグにいかないので、僕でもワークとして使います。bl(ラインバッファサイズ)、
これがこのマクロのワークだとドックにありますね。

 これを眺めてみてください。
http://mezala.la.coocan.jp/vz/notes/segmap.html

Text record(オープンファイルごとに。wa..XX) wa..13はここの欄

 上のサイトに「内部ワーク」(参照するだけなら僕もする)の地図があります。(先日は、害が
ないので、ファンクションキーラベルを書き換えました。驚いたことに、あの長大なツリーの基点。
見る意味はありません。)ここからテキストバッファでもテキストスタックでもファイラプールでも、
どこでもアクセスできます。普通マシン語を使うでしょうが、セグメントを一瞬変えれば、
. or .. (ポインタ演算子)でも、書き替えられます。

 危険な行為かもしれませんが、危険にならないようにプログラムするのが我々の仕事です。
 コワクはないですよ、きっと。

 SSの参照先は僕も気になりますが、スタックセグメントって、DOSから見ると、Vzのデータ
セグメントのことではなかったかと思うので、そこでポインタで示された内容(アドレス)の意味
が分かれば、たとえば前回のコード列内の(SS:[0640])も、どこだか、何を指しているのか、
分かりそうだと思っていました。Vzマクロから見れば、上の「内部ワーク」のことでしょう。
 (僕は、SS:[0640]に意味を見出してはいませんが。たとえ意味が分かっても何もできません)


see #08276
3C70:0107 368B3E4006     MOV    DI,SS:[0640]

 とにかく、sort.def, 逆アセコード内のSSは、vzの挙動を把握しているkonnoさんが調べれば
分かるのか分からないのか、というところなのでしょう。

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

 最後に無知な文太が一言:
 Vzの世界では、「ローテクはハイテク」という言い回しで表現されてきました。
 コマンド・関数・変数としてc.mosさんが表に出してくれたものを、短く賢く使って、マクロを書くのが正道
という意味なのでしょう。と同時に、ローテクは後ろでVz自体が、(いわゆる)ハイテク・Vzコードが、
ガサッガサッと動いて仕事をしてくれていることを意味するので、マシン語が偉いってわけじゃないよ、
という意味だとも僕は解しています。

 上のコードをみて、#N #P #m  #C(ローテク技)をしているとき、色々やって調べてる(調整してる)な、
と思ったものですから。
 だから、すいません、マシン語マクロばかりがコワイわけではありません。普通のマクロもvtdosを
落とせる、と僕は思っています。
 ブロックをコピーしただけで、テキストスタック(EMS上のあること多し)がガサっと動いて、EMS
の窓がこれまた動くのだと思いますので。このとき、マクロバッファもファイラプールも窓移動で、
ガサッガサッと。
 分かってない奴の、分かったような、分かんないような、抽象論でした。m(__)m


 背伸びはせず、格好つけず、知ったかぶりせず、書いたつもりです。それでも、間違いが含まれている
可能性は、すいません、僕のばあい、いつも、あります。m(__)m

 有益なことが言えるとも思えませんので、レス不要ですよ。



08350/08314 GST01234 10♯ Re^6: SORT.DEF(高橋版)の問題はここ?
( 1) 18/10/16 19:11 08349:文太さんへのコメント コメント数:2

c.mos氏はこのdseg内のオフセットを保証しているとは思いますが、
僕のvzでは例えばpcは0111hになってたりとかします。
こういったことは改版の時点で厳密な管理が無いとズレていくものだと思うのですが、
マクロの中の、特にマシン語が直接参照するdsegのアドレスには問題無いのでしょうか?

※追記
あと、VTDOSにはEMSを禁止するオプションもあります。
これはVZにもありますが、問題切り分けには使えます。

08351/08314 CRG00666 文太 Re^7: SORT.DEF(高橋版)の問題はここ?
( 1) 18/10/16 20:53 08350:10♯さんへのコメント コメント数:1

 ありがとうございます。

>c.mos氏はこのdseg内のオフセットを保証しているとは思いますが、
>僕のvzでは例えばpcは0111hになってたりとかします。
>こういったことは改版の時点で厳密な管理が無いとズレていくものだと思うのですが、
>マクロの中の、特にマシン語が直接参照するdsegのアドレスには問題無いのでしょうか?

 よりによって、僕がこれに何かコメントを返すのは、躊躇われますが、大間違いなこと
を書けば、さすがに、konnoさんが、やんわり修正してくれるでしょう。
 はい、「改版の時点で厳密な管理」はされてきたと思います。前に書いた、Vzの伝統
です。めざらさんのセグマップで「絶対アドレス」と書かれてますよね。pcが0111hなのは、
10#さんのところでも僕のところでも、同じはずです。
 コードは(残りのぶんだけ)太っていい。でもデータは動かすな、なのかな?

 sort.defなどのマクロに関していえば、マクロ語のなかで、ax=pc,のようにすれば、
マシン語ルーチンでもなんら問題ないはずですよね、マシン語で、mov ax,0111とかは
あんまりしないではないのでしょうか。してないのではないでしょうか。この辺は、
分かりません。上のように「厳密な管理がなされている」という前提なら、問題ではない
のだろうとも考えますが。

 これが厳格に守られてきたのが「伝統」なのだろうと僕は思っています。
 たぶん、間違ってない歴史的エピソード。Win95のころ、Win対応として、ちゅーぱっち
というのが出ました。VzがWin環境で動くようになった(詳細は不明。テンポラリーファイル
の管理、かな?)。しかし、上のdseg内のアドレスへの配慮はなかった。既存マクロが動かない
という大きな問題がniftyで指摘されたようなことはなかったと思いますが、niftyのfgaldcには、
そこの空気があったのです、おそらく。「これでは、既存マクロが動かないよ」、とたぶん、
高橋さんは言った。それで、高橋版ドックの冒頭が、こうなっているのだと思います。(注)

 「マクロを作るならば、マクロをよく知っている人の作った Vz がいい」
http://mezala.la.coocan.jp/vz/env/win/win98.html#vzt03k2

 高橋版の前の榊原版も、ここは守った。Vzが1.5から1.6になったとき、c.mosさんが、
コードセグメントとデータセブメントの分離という大きな変更をしたにもかかわらず、
1.5マクロが1.6Vzで大混乱しないような配慮をした。これを、踏襲してのことだったと、
僕は理解しています。
 おかげで、セグメント変数って、わ、分からない、、、。

 前に、konno版に関して、konnoさんの「保守性」(安全第一主義)に関して、「アドレスが
1バイトずれただけで」と書きました。これのことを言っていたつもりです。僕の理解では、、、。



>あと、VTDOSにはEMSを禁止するオプションもあります。
>これはVZにもありますが、問題切り分けには使えます。
 「問題の切り分け」ですね。うん、うん、ちょっと分かるぞ、これ。サンクスです。m(__)m
 問題は、EMSのないVzを僕がうまく使えないことなんですが、これは僕の問題。ファイラ
などのワークというかバッファをどこまで縮めれば(制限を受け入れれば)、テストができるの
かさえ、うううう。ま、ゆっくりやります。
 お教え、ありがとうございます。


(注)ちゅーぱっちをどれくらいの人が使ったのかは分かりません。特定のマクロ、あるいは
もっと広く、ワークを参照するマクロを使わない人には害はなかったはずで、マクロ師、マクロイド、
マニアックなマクロ・ユーザ以外には、ありがたかったのではないかと思います。



08352/08314 GST01234 10♯ Re^8: SORT.DEF(高橋版)の問題はここ?
( 1) 18/10/16 21:14 08351:文太さんへのコメント コメント数:2

僕はワークやバッファ類をどこに置くとかは全く把握してないのであれなんですけど、
なんならXMSを使えば大容量ファイルの置き場にはなったと思います。
(確かEMSに比べて制限は大きかった)
このあたりの、XMSを導入してむにゃむにゃしてる頃に、僕の環境は
EXTTPAのSW1になったようです。
僕文太さんに言われるまでcyupatch使ってましたよ。

絶対アドレスは絶対安全か?
それを盲目的に信じる前提はあるのかも知れませんが、
sort.defは絶対安全という前提があるが故にこれを読まなくて良いかというと、
読まないと切り分けは出来ませんですな。
マクロ師の力を必要としてるのは他ならぬマクロユーザーなのでは?


08353/08314 BQO00549 konno Re^5: SORT.DEF(高橋版)の問題はここ?
( 1) 18/10/16 22:22 08347:10♯さんへのコメント コメント数:1

> マシン語コードのSSの参照先とか、waのオフセット13とかがワークのどれを見てるとか分りますか?

私もよくわかっていないのですが、MAC16.DOC には

■ セグメントの変更
-----------------------------
 コードセグメントとデータセグメントを分離したため、マクロでアクセスするワークエリアは、全てスタックセグメントに移動しました。このため、

	dz=gz, p=wa+$92, .. dz=cz,

のように、セグメントを変更する必要はありません。
 また、このように「dz=cz,」でセグメントを復帰しているマクロとの互換性を考慮して、「cz,dz.gz」はすべてスタックセグメントを指しています。真のコードセグメントの値は、セグメント変数「vz」が示します。


こうあるので、VZのコードはCSEGで、その他はほとんど、SSEG なのだと思います。
今の私の環境では、SORT.DEF のエラーで

2018-10-16 11:38:29 VZIBMJ(17EA) 17EA:14A1 'REPNE SCASB 命令ラップアラウンド'

AX=000A BX=CCDA CX=FFF7 DX=0100 SI=0001 DI=0001 BP=CCDA DS=3E51 ES=3E51 FLAGS=0646

CS:IP=17EA:14A1
17EA:1491 C3 FC 51 57 06 1E 07 8B FE B9 FF FF B0 0A F2 AE 
17EA:14A1 8B F7 07 5F 59 C3 B2 00 EB 1F E8 F9 FF 73 03 FF 
 0000:1492       ENDLIN

SS:SP=274A:CACE
274A:CABE 46 02 4A 27 80 16 EE CB DE 00 FF FF 89 D2 51 3E 
274A:CACE 4A 27 9A 7B 7E 1F 8E 14 3D 19 02 00 26 19 ED 16 


mg 274a:04d2	マクロエリア
mg 274a:11cf	vz.def
mg 274a:6252	sort.def
pu 274a:b0f2		マクロ配列エリア
sp 274a:b1f0	マクロスタック

51F7:06E3	テキストスタック


数値は多少違うものがあるかもですが、マクロのワークは全て SS のセグメント
だと思います。
マクロ内のマシン語も当然そのマクロのアドレスにあるので、その中で動きます。

このマクロでは常に endlin  でエラーになっているようですが
ソースでは、

------------------ CORE.ASM
CORE.ASM 258:	public	toplin,endlin,prelin
CORE.ASM 269:;	call	endlin
CORE.ASM 277:endlin	proc
CORE.ASM 270:	call	endlin
CORE.ASM 289:endlin	endp
CORE.ASM 1149:	call	endlin
------------------ MEMO.ASM
MEMO.ASM 48:	extrn	endlin		:near
MEMO.ASM 558:	call	endlin
------------------ TEXT.ASM
TEXT.ASM 75:	extrn	endlin		:near
TEXT.ASM 1033:		call	endlin
TEXT.ASM 1635:	call	endlin
TEXT.ASM 2053:	call	endlin
TEXT.ASM 2079:	call	endlin
------------------ VIEW.ASM
VIEW.ASM 27:	extrn	endlin		:near
VIEW.ASM 808:	call	endlin
VIEW.ASM 956:	call	endlin

でも、マクロのトレースでは、常に

:z	ek],&06 &d

この終了処理の、ek], のポッブ実行直後にVTDOSがエラー表示します。


wa..13 は、VZ.INC の中ですが、DSEG.MAP がわかりやすいですね。

;--- Text record ---		;wa,wb,wo,wm,wf
26	tmax		dw	?	; text buffer end ptr

これかな。



08354/08314 BQO00549 konno Re^4: SORT.DEF(高橋版)の問題はここ?
( 1) 18/10/16 23:13 08348:10♯さんへのコメント コメント数:1

> <1行目の内容><01h>
> <2行目の内容><01h>
> ...
> <最終行の内容><01h>
> <各行の合計バイトサイズ>

すみません、わからないです。
debug のデータですか?


08355/08314 CRG00666 文太 Re^9: SORT.DEF(高橋版)の問題はここ?
( 1) 18/10/16 23:14 08352:10♯さんへのコメント

 うーん、まったく話がどこへ向かっているのか分かりません。
 が、分かる範囲で、回答させていただきますね。

>僕文太さんに言われるまでcyupatch使ってましたよ。
 すいません、vtdosの作者が、マクロを使われないとは想像していませんでした。
 それでも、マクロを積極的に使わなくても、製品版vz.defが標準だと思いますので、多くの
バグが取られているはずの高橋版の流れをくむkonno版が良いと思います。
 (余計なことですが、Vzマクロって、マシン語コードを含む含まない以前に、Vzの
一部だと思っています。^KDとか。当たり前すぎますかね。)

>sort.defは絶対安全という前提があるが故にこれを読まなくて良いかというと、
>読まないと切り分けは出来ませんですな。
 ここは、まったく分かりません。
 僕は、sort.defのユーザではないです。c:\wk\sort.defとどっかで書いたと思いますが、
konnoさんに請われて、DLしました。また絶対安全なマクロだとも思っていません。ただ、
すでにvtdos環境での、Vzの脆弱性を露呈させているのだと、思っています。

 それでも、僕が僕の環境で解決できなかった問題は、これとは別だろうと想像しています。
で、撤退しかなかった、という経緯ですが、これ、関係ありませんよね?

 この手のことは、多少遅くても、僕は個人的にpsort.exe, sortf.exe, ssort.exeに担当して
もらっています。パラグラフ・ソートは、まだ3回ぐらいしか使ったことがないのですが。

 ただ、konnoさんの狙いは、高橋版sort.defを機能するようにする、ということではないの
だろうと想像していました。Vzの弱いところを建て直す、これが狙い、そう思っていました。

>マクロ師の力を必要としてるのは他ならぬマクロユーザーなのでは?
 もうどっちも絶滅危惧種ではないのかと思います。
 ぼくは、誰にも頼らずにVzできると思ってます。仕事の道具なものですから、そうでない
と、それこそやばい、ということになります。そのためのWinMEなんです。

 それでも、こんなのプログラミングの論理世界とはなんの関係もないのかもしれませんが、
僕には、おそらく、めざらさん、konnoさん、としきさんが、友人として必要、なん、だろう、と、
思います。あはははは。嘘かほんとか。

 もし僕の勧めで、10#さんがcyupatachから高橋版(konno版)に移られたことが問題だったの
だとしたら、すいませんでした。今からでも、戻れば宜しいのではないでしょうか。そんな風に
思いました。

 意思疎通、できてないですよね、ここ、きっと。

 すいませんが、話の展開の方向がまったく見えておりません。

 僕は何も茶化していないし、不真面目でもないつもりなのですが。たんにスキルレベルが2018年の
Vzerとしては低すぎる、ということかと。しかし、これは、僕の人格の一部なので、した選択の
結果なので、本人も諦めております。ご迷惑をお掛けしております。m(__)m



08356/08314 CRG00666 文太 Re^9: SORT.DEF(高橋版)の問題はここ?
( 1) 18/10/16 23:32 08352:10♯さんへのコメント コメント数:1

 しつこくて申し訳ありません。これは、僕の独り言です。
 コミュニケーションって難しいですね。

 全体に、10#さんの独り言だな、と思いました。ですから、この前の僕の投稿みたいに
色々書くことはなかったのだろうと。

>マクロ師の力を必要としてるのは他ならぬマクロユーザーなのでは?
 きっとここだけでしょう。
 僕個人に関していえば、あるいはsort.def(高橋版)に関していえば、純粋なユーザは
いないように思っております。

 レス不要ですよ。


08357/08314 GST01234 10♯ Re^5: SORT.DEF(高橋版)の問題はここ?
( 1) 18/10/16 23:43 08354:konnoさんへのコメント

> すみません、わからないです。
> debug のデータですか?

バックアップの二番目のマシン語の部分のファイル出力がこの形式で出力してるようです、
という覚え書きです。



08358/08314 GST01234 10♯ Re^10: SORT.DEF(高橋版)の問題はここ?
( 1) 18/10/17 00:16 08356:文太さんへのコメント

まあ最早誰もマクロ師を必要とはしていないでしょう。
僕はこのマクロを読むことが出来ないので、マクロ師がいればな、とは思います。


08359/08314 GST01234 10♯ Re^6: SORT.DEF(高橋版)の問題はここ?
( 1) 18/10/17 00:21 08353:konnoさんへのコメント

なるほど。
僕もちょっと見てみた限りではそれらワークのアドレスに問題が無さそうだってことは理解出来ました。
あと、バックアップ部分のマシン語の挙動も大体は把握出来ました。
となると、バックアップのマクロのどこかにトリガーがあるということまでは推測できますね。

08360/08314 BQO00549 konno Re^7: SORT.DEF(高橋版)の問題はここ?
( 1) 18/10/17 01:40 08350:10♯さんへのコメント コメント数:2

> c.mos氏はこのdseg内のオフセットを保証しているとは思いますが、
> 僕のvzでは例えばpcは0111hになってたりとかします。

う、VZK だと1バイトずれていますね。何故だかわからないです。
VZEXもここは同じようにずれていますが、他のワークもずれているようで
動かないマクロがあるようです。

> こういったことは改版の時点で厳密な管理が無いとズレていくものだと思うのですが、
> マクロの中の、特にマシン語が直接参照するdsegのアドレスには問題無いのでしょうか?

相対アドレスで参照するものは大丈夫ですが、私が私家版で使っていた版は
vp がずれてしまっていて、カレンダーマクロで誤動作して気が付いた次第です。

マシン語が直接参照するdsegのアドレスは、絶対アドレスなので、ポインタが
ずれたら即誤動作するので致命的な問題になります。

SORT.DEF もマシン語が直接参照しているようですね。ちょっと読めてないですが
どこかで壊れて、マクロのポップがトリガーになって落ちているように見えますね。
ポップで、sp のポインタが2ずれるんですが、どうもおかしい気がします。

> あと、VTDOSにはEMSを禁止するオプションもあります。
> これはVZにもありますが、問題切り分けには使えます。

ありがとうございます。必要に応じて使わせてもらいます。



08361/08314 CRG00666 文太 Re^8: SORT.DEF(高橋版)の問題はここ?
( 1) 18/10/17 08:29 08360:konnoさんへのコメント コメント数:3

「めざら資源」セグマップ
スタックセグメント概略
絶対アドレス	相対アドレス	データ内容
0000		wseg
0110		pc

10#さんwrote:
> c.mos氏はこのdseg内のオフセットを保証しているとは思いますが、
> 僕のvzでは例えばpcは0111hになってたりとかします。

文太wrote:
>めざらさんのセグマップで「絶対アドレス」と書かれてますよね。pcが0111hなのは、
>10#さんのところでも僕のところでも、同じはずです。
 0110hと0111hの差について語られていたとは、気づいておりませんでした。
 konno版もc.mosオリジナルと同じです、と信じていて、そう伝えたつもりでおりました。
ここで、僕は、完全に間違えていました。m(__)m

konnoさんwrote:
>う、VZK だと1バイトずれていますね。何故だかわからないです。


 そ、そういうことか、、、。これで話が【少し】ずれたんだ、、、。

 手元には、7個くらいpcを使うマクロがありました。

c:\def\filter2.def      400:        &Sm(m,pc+292,46)	;push all double user vars
c:\def\popn.def      161::M	pc[=c,pd[=d,pg[=g,pn[=m,pq[=q,pu[=u,pv[=v,px[=h,pz[=e,pw[=w,pr=pa,
c:\def\sheriff.def      113:	&So(pm,"$$pc") (r)? p=pc, ? p=pm,
c:\def\sonota.def     1071:        &Sm(pq..149,pc+292,46)          ;push all double user vars
c:\def\stkhelp.def     1182:    } ?bx=pc,
c:\def\stkmenut.def       32:	(ks&1)??{ &b(5) >04 }			;pc..57 = ks
c:\def\tkdate.def       12:    &11 &Sc(pc,ps)          ;;  pc="1994年12月31日",

 もっとも別にこれに大きな問題はありませんよね、pcをpcとして使っている限り。
 マシン語の中で、直値としてみたら、いろいろやばいだろうな、とは思いますが。

 意見も何もありません。
 が、戻るなら戻ったほうが気持ちもいいし、「めざら資源」とも整合するのですが。(^^;
 過去の無用なくび木なのでしょうか? メリットは? (^^;
 sort.defのことは僕には実害がありません。が、こっちは、ちょっと、、、。実害は、今は、ない
はずですが、、、。作家の考え方次第なのでしょう。
 できたら、.docに入れて欲しいとは思います。


08362/08314 GST01234 10♯ Re^8: SORT.DEF(高橋版)の問題はここ?
( 1) 18/10/17 09:46 08360:konnoさんへのコメント コメント数:1

>         org 100h
> entry:      jmps    entry1          ; -16
> vzversion:  db  "VZ1.60t ",0,EOF    ; -14       ;##k07
> entry1:     jmp init            ; -5
>         dw  0           ; -2

オリジナルは entry1 の jmp init がショートジャンプのようですが、
kVZではニアジャンプになってますね。
sort.defはpc相対を使っていないのでこれはシロだと思いますけど。


08363/08314 GST01234 10♯ Re^9: SORT.DEF(高橋版)の問題はここ?
( 1) 18/10/17 10:02 08361:文太さんへのコメント コメント数:1

本来0110hから始まるpcが0111hにずれてる事に対して、
本来0120hから始まるワークはずれていませんね。
これはpc相対で16バイト目以降に問題があると思われます。
上のgrepではfilter2とsonotaが該当するようですが。


08364/08314 CRG00666 文太 Re^10: SORT.DEF(高橋版)の問題はここ?
( 1) 18/10/17 14:23 08363:10♯さんへのコメント コメント数:1

 10#さん、本当にありがとうございます。m(__)m m(__)m
 顔面蒼白、これ以上になく僕の顔は今、まっ白でしょう。
 頭の中に色はつかないけど、まっ白だと感じています。
 冗談をいえば、脳梗塞で脳が死んだ人のように、まっ黒なのかもしれません。
 熊に出会ってしまった人のように、髪の毛は、逆立ってます。

 いい歳した大人が、この程度のことで人生がひっくり返ったみたいに、
動揺しても始まらないので、ちょっと落ち着いて考えます。
 現実的にはそういう訳にもいかないのですが、旅に出たほうがいいな、
と感じています。

 とはいえ、vtdosとは本質的に関係がありません。
 もっと大きいのかもしれない。
 いや、大したことではないはず、です。


08365/08314 CRG00666 文太 Re^11: SORT.DEF(高橋版)の問題はここ?
( 1) 18/10/17 16:24 08364:文太さんへのコメント コメント数:1

 いちいち顔面蒼白とかしないように。いちいち逆毛とか立てないように。
 けっこう立ち直り、はやかった。
 たしかに、「pc+xx」はやばいようですね。

Ygrep -w "pc" c:\def
c:\def\chgenv.def      200:;	&Sm(pc+60,cp+2,20) &Sm(pc+174,cp+22,176)
c:\def\lxclnd.def      107:	&Sm(pc+292,pq..149,46)		;pop all double user vars
				;こっちはイディオムですからねぇ。これは書き戻しの場面でしょうね。

 もう一般ユーザが存在しない(konnoさんにとってはいるのかな)ご時勢ですし、、、。
 誰も気がつかないんですよね、、、。

konno, 
0110h: 00 56 5A 00 00 00 00 00-00 00 25 00 00 00 00 00  ・VZ・・・・・・・%・・・・・ 
0120h: 00 00 00 00 00 00 40 00-00 80 00 01 00 10 50 00  ・・・・・・@・・・・・・・P・ 

takahasi,
0110h: 56 5A 54 00 00 00 00 00-00 25 00 00 00 00 00 00  VZT・・・・・・%・・・・・・ 
0120h: 00 00 00 00 00 00 40 00-00 80 00 01 00 10 50 00  ・・・・・・@・・・・・・・P・ 

 しばらく高橋版にします。マシンの台数が多いので、入れ替えが終わるのがいつに
なるのか分かりませんが。この大混乱は、もっとも苦手とするところなのです。
 このマシンは入れ替えた、って、一覧表をつくるの、、、。
 それでも、紆余曲折ありながらも、前進ですよ。

 10#さん、ありがとうございました。


08366/08314 CRG00666 文太 基点ポインタ(?)の絶対アドレス
( 1) 18/10/17 17:20 08365:文太さんへのコメント

  他は問題ないようです。これぐらいはできるな、と。

		konno
0000	wseg
0110	pc	0111h *
028E	pq	028Eh
	dseg
03EC	pn	03ECh
0442	fg	0442h
04D2	mg	04D2h
05B9	pv	05B9h
062A	vp	062Ah



08367/08314 BQO00549 konno Re^9: SORT.DEF(高橋版)の問題はここ?
( 1) 18/10/17 18:49 08361:文太さんへのコメント コメント数:1

>  手元には、7個くらいpcを使うマクロがありました。
> 
> c:\def\filter2.def      400:        &Sm(m,pc+292,46)	;push all double user vars
> c:\def\popn.def      161::M	pc[=c,pd[=d,pg[=g,pn[=m,pq[=q,pu[=u,pv[=v,px[=h,pz[=e,pw[=w,pr=pa,
> c:\def\sheriff.def      113:	&So(pm,"$$pc") (r)? p=pc, ? p=pm,
> c:\def\sonota.def     1071:        &Sm(pq..149,pc+292,46)          ;push all double user vars
> c:\def\stkhelp.def     1182:    } ?bx=pc,
> c:\def\stkmenut.def       32:	(ks&1)??{ &b(5) >04 }			;pc..57 = ks
> c:\def\tkdate.def       12:    &11 &Sc(pc,ps)          ;;  pc="1994年12月31日",

う、結構あるもんですね。
早急に対処したいと思います。ご迷惑おかけしました。



08368/08314 BQO00549 konno VZk の pc ズレ問題
( 1) 18/10/17 19:10 08362:10♯さんへのコメント

> >         org 100h
> > entry:      jmps    entry1          ; -16
> > vzversion:  db  "VZ1.60t ",0,EOF    ; -14       ;##k07
> > entry1:     jmp init            ; -5
> >         dw  0           ; -2
> 
> オリジナルは entry1 の jmp init がショートジャンプのようですが、
> kVZではニアジャンプになってますね。
> sort.defはpc相対を使っていないのでこれはシロだと思いますけど。


そうか、すっかり忘れていましたが、これで思い出しました。

		org	100h
entry:		jmps	entry1
;vzversion:	db	"VZ1.60t ",0,EOF	;##k07
vzversion:	db	"VZ1.60t",0,EOF		;##k07t1-2 pc=110h
entry1:		jmp	init

こう修正して、pc が一致しました。ここの長さを変えたら駄目だったんですね。
VZEX もこうなっていて、以前、ダニー版ベースの VZk8 を弄っている時に
一度これをやってしまって、直したんですが、その後 VZk7 に戻った時に
ここを修正するのを忘れていたようです。

取りあえず、公開しているものは、修正版をアップします。



08369/08369 BQO00549 konno VZk 公開版の pc ズレ修正・差し替え
( 1) 18/10/17 20:15 コメント数:1

#8350 で、10#さんの指摘により、VZk のコード領域の内部ワーク pc が
1バイトずれていたのが発覚しました。
原因は
;vzversion:	db	"VZ1.60t ",0,EOF	;##k07
vzversion:	db	"VZ1.60t",0,EOF		;##k07t1-2 pc=110h
ここでした。

取りあえず、公開しているものは、修正版をアップするということで

VZk07T1(2010-03-01)を、VZk07T01.LZH として、VZの部屋に差し替えアップしました。

・コード領域の内部ワーク pc が1バイトずれていたのを修正、差し替え(2018-10-17)


旧版とはサイズは一緒です。1バイト差は自動調整されるようです。
バイナリの比較で29bytes 違いがあります。



08370/08314 BQO00549 konno Re^10: pc ズレ、やばいかも
( 1) 18/10/17 20:37 08367:konnoさんへのコメント

> う、結構あるもんですね。
> 早急に対処したいと思います。ご迷惑おかけしました。

コード領域の内部ワーク pc の1バイトずれで、値を比較してみました。

	VZo	VZk修正	VZk旧
pc	110h	110h	111h
pc+292	234h	234h	235h
pc..57	0	0	B900h

修正版は問題ないようですが、旧版は、変な値になっていますね。

> > c:\def\filter2.def      400:        &Sm(m,pc+292,46)	;push all double user vars
pc+292 は、ここですかね。
246	sysvar		dw	VARCNT dup(0)	; A,B,C ... system variables

> > c:\def\stkmenut.def       32:	(ks&1)??{ &b(5) >04 }			;pc..57 = ks
pc..57 は、これですね。
114	sftkey		dw	0		; ks key shift status

うう、結構やばいかも。



08371/08369 BQO00549 konno Re: VZk 公開版の pc ズレ修正・差し替え
( 1) 18/10/17 21:46 08369:konnoさんへのコメント

VZk07T3(2015-12-11)を、VZk07T03.LZH として、VZの部屋に差し替えアップしました。

・コード領域の内部ワーク pc が1バイトずれていたのを修正、差し替え(2018-10-17)


旧版とはサイズは一緒です。1バイト差は自動調整されるようです。
バイナリの比較で29bytes 違いがあります。

後はソースと一致しないものが多いので、時間がかかりそうです。
要望があれば優先的に対応します。


08372/08314 GST01234 10♯ Re^9: SORT.DEF(高橋版)の問題はここ?
( 1) 18/10/18 06:04 08361:文太さんへのコメント コメント数:1

余談ですけど、近頃僕は「信じる」という行為は控えるようにしてます。
これは、思い込みに繋がり、そこから仮に「正義」などに繋がれば、
酷い結果になる原因にもなります。
歴史からの教訓ですかね。

08373/08314 CRG00666 文太 Vz文化
( 1) 18/10/18 13:15 08372:10♯さんへのコメント コメント数:1

 人生にはみっつの坂がある。のぼりざか。くだりざか。まさか。


 口承文化と活字文化の落差を、またしても感じさせてくれました。
 活字は先読みできる。口承では完全に話者のペースになれる。それで、
うまくやると洗脳できる。
 理解したからといって、実践できるわけでもないですが。


 信念をもたないのが僕の信念だ。「外」はないようですね。


 Vz文化にはこんな言い伝えもあります。
 「ニーモニックが読めるからといってc.mosさんのソースを読めるわけでは
ないのと同様、Vzマクロのシンボルその他を暗記したからって、m.gannさん
のマクロが読めるわけではない」
 高橋さんのマクロでは、(きっと)プロのプログラマ的に正統だろうと思いますが、
それでも、m.gannさんが目標だったのも(きっと)あって、Vzの癖をとことん
知り尽くした上でのプログラミング・スタイルなのでしょう。
 Vzの「内部ワーク」の利用は当然ですが。
 知ったかぶりではなく想像です。

 sort.defでは、「癖」でも「裏技」でもないでしょうが、テクニックが駆使
されているようです。かなりのスキルレベルで、読解の行為に深いコミットメント
のあるマクロ師でなければ、読めないか、読もうとしないか、かと思いました。
 僕レベルだと、おお、とほんの一部分で、テクニックを学ばせてもらえる程度
でした。sort.exeではいけませんか? と思うような奴には無理ですね。
 (いつかME環境で使ってみようとは思っていますが。フィールドでなくカラム
でソートは、、、。sortfはオプション指定がいつも難しくて、、、。)

 「内部ワーク」。めざらさんがあのように素晴らしく纏めてくださってますが、
あれが明らかになるのに、10年くらいに及ぶ、多くのVzerたちの苦闘が
ありました。文字どおりの血と汗と涙の結晶。
 最終的に発表したのは高橋さん。でも、高橋版Vzも「セグマップ」も、
高橋さんがきっと50人くらいのマクロ師、マクロイド、マニアック・ユーザに囲まれ
ていて、その価値を理解してくれる人たちがいたからこそ、生まれたのだろうと思います。
 あんなこと、誰も、一人ではやれないと思う。
 めざら資源で、一人であれを纏め直した、めざらさん。僕はあの作品に感動します。



08374/08314 GST01234 10♯ Re: Vz文化
( 1) 18/10/18 14:42 08373:文太さんへのコメント

ネットワークの世界に「口承文化」ってないですよねw

08375/08375 BQO00549 konno VTDOS+VZ で #N、#P でのエラー
( 1) 18/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窓では、マクロエラーがあっても落ちません。
この辺に何かありそうな気がするのですが。



08376/08375 GST01234 10♯ Re: VTDOS+VZ で #N、#P でのエラー
( 1) 18/10/18 21:54 08375:konnoさんへのコメント コメント数:1

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

08377/08375 CRG00666 文太 Re: VTDOS+VZ で #N、#P でのエラー
( 1) 18/10/18 22:03 08375: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



08378/08375 BQO00549 konno Re^2: VTDOS+VZ で #N、#P でのエラー
( 1) 18/10/18 22:20 08376: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 が無いのに
気が付かなかったのです。

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



08379/08375 BQO00549 konno Re^2: VTDOS+VZ で #N、#P でのエラー
( 1) 18/10/18 22:47 08377:文太さんへのコメント コメント数:1

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

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

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

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

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



08380/08375 CRG00666 文太 Re^3: VTDOS+VZ で #N、#P でのエラー
( 1) 18/10/19 00:13 08379:konnoさんへのコメント コメント数:1

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

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


08381/08375 CRG00666 文太 Re^4: VTDOS+VZ で #N、#P でのエラー
( 1) 18/10/19 00:35 08380:文太さんへのコメント コメント数:1

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

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


08382/08375 CRG00666 文太 vz.com, s>0の問題みたい
( 1) 18/10/19 00:55 08381:文太さんへのコメント コメント数:1

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

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

&z("expand") >*

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




08383/08375 CRG00666 文太 痩せたVz、太ったVz
( 1) 18/10/19 01:26 08382:文太さんへのコメント

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

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


08384/08375 BQO00549 konno Re^3: VTDOS+VZ で #N、#P でのエラー
( 1) 18/10/19 02:18 08378:konnoさんへのコメント コメント数:1

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

1 "!Abort" /

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

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


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



08385/08375 CRG00666 文太 Re^4: VTDOS+VZ で #N、#P でのエラー
( 1) 18/10/19 11:05 08384:konnoさんへのコメント

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

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

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

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