問題の切り分けのため、新スレにします。＞文太さん,ALL
#8307 で書いたんですが

> 関連の記事が、#6580 あたりにありますが、必ず落ちるマクロとして
> 1997/10/06  23:03             8,273 SORT.DEF （高橋版）があります。
> これで、同じく高橋さんの
> 1998/08/23  21:18            18,312 dseg.map
> をファイル先頭から最後までブロックしてマクロ起動し
> メニューが出たらそのまま Enter すると、ソートされます。
> Esc で終了すると、VTDOSが'REP MOVSB 命令ラップアラウンド' で落ちます。

これは、どうも違う原因で落ちているようなので、皆さんのお知恵をいただきたく
 関連の記事、#6580 の一部を貼り付けます。


SORT.DEF（高橋版）はやっぱり落ちますね。調べてみたところ、
メニューを抜けた時のファイルクローズ処理で落ちているようです。
マクロの最後のサブルーチンです。

06:	; close
	(u)??.
	(u<0)?{&s id[,&#T(u) #C u-,&#T(-0]) &d.}
	bx=u,ax$3E00,&i($21) dx=pq..149,ax$4100,&i($21) u-,   ; ★

ここをコメントにすると、編集ファイルを閉じた時に落ちます。

;	F_CLOSE		equ	3Eh		; Close a File Handle
;	F_DELETE	equ	41h		; Delete a Directory Entry

ここではこの2つのDOSコールを読んでいますが、おそらく
VTDOSはF_CLOSEのタイミングでエラーメッセージを出しているのでしょう。
エラーメッセージ自体はまったく同じです。


あらためて、検証してみるためにトレースしてみると

	(u)??.
	&t 					;★ここからトレース
	(u<0)?{&s id[,&#T(u) #C u-,&#T(-0]) &d.}
　　　　　　　　　　　　　　　　　 ^^^^^^^
この、&#T のところで落ちました。
以前試したときはここは通ったと思ったので、タイミングの問題か？

それで、&t の後に、.（ピリオド）を入れて、終了させたところ
テキストはソートされていましたが、F3 テキストの切り替えで見ると
全く同じパスが二つ並んでいました。げげげ

裏のテキストが変更前のテキストだろうと思い、カーソルで選択したら
VTDOSがエラーで落ちました。


この問題を回避するには、マクロのどこを修正すればいいか、皆様のお知恵を
拝借したく存じます。
作業用のパス名を変えれば良さそうな気がするんだけど、読めないの(;_;)

> 　はい。２回やって（１回目も再起動していました）、２個の同じログが残っています。

うーむ、SCASB_MODE=1　でエラーが出るとすると、初めての事例となりそうです。
#8307 にも書きましたが、SCASB_MODE=1 では落ちたことがないのです。

> 　残されたコード列は、もちろん２つが同一で、前回、僕が10#さんに解析してもらった
> （Ｖｚソースをkonnoさんに見てもらった）ものとは、違いました。

私の環境ではこんな感じです。

2018-10-12 19:13:04 VZIBMJ(17DE) 17DE:149A 'REPNE SCASB 命令ラップアラウンド'

AX=000A BX=CADA CX=FFF4 DX=0100 SI=0001 DI=0001 BP=CADA DS=4364 ES=4364 FLAGS=0646

CS:IP=17DE:149A
17DE:148A 46 C3 51 57 06 1E 07 8B FE B9 FF FF B0 0A F2 AE 
17DE:149A 8B F7 07 5F 59 C3 B2 00 EB 1F E8 F9 FF 73 03 FF 

SS:SP=271D:C7F6
271D:C7E6 33 00 3C 1B 1A C8 08 C5 02 00 00 00 B8 91 64 43 
271D:C7F6 1D 27 13 7A 7E 1F 88 14 36 19 02 00 1F 19 E6 16 

-u 17DE:148A
17DE:148A 46            INC	SI                                 
17DE:148B C3            RET	                                   
17DE:148C 51            PUSH	CX                                 
17DE:148D 57            PUSH	DI                                 
17DE:148E 06            PUSH	ES                                 
17DE:148F 1E            PUSH	DS                                 
17DE:1490 07            POP	ES                                 
17DE:1491 8BFE          MOV	DI,SI                              
17DE:1493 B9FFFF        MOV	CX,FFFF                            
17DE:1496 B00A          MOV	AL,0A                              
17DE:1498 F2            REPNZ	                                   
17DE:1499 AE		SCASB	 		;★		   
17DE:149A 8BF7          MOV	SI,DI                              
17DE:149C 07            POP	ES                                 
17DE:149D 5F            POP	DI                                 
17DE:149E 59            POP	CX                                 
17DE:149F C3            RET	                                   
17DE:14A0 B200          MOV	DL,00                              
17DE:14A2 EB1F          JMP	14C3                               
17DE:14A4 E8F9FF        CALL	14A0                               
17DE:14A7 7303          JNB	14AC                               
17DE:14A9 FF460A        INC	WORD PTR [BP+0A]                   
-q

これは、VZ.MAP では

 0000:1490       ENDLIN

このへんですね。これは、CORE.ASM の
;--- Scan line start ptr  ---
endlin	proc
	pushm	<cx,di,es>
	movseg	es,ds
	mov	di,si
	mov	cx,-1
	mov	al,LF
  repne	scasb				;★
	mov	si,di
	popm	<es,di,cx>
	ret
endlin	endp


想像ですが、どこかでメモリかレジスタやフラグの状態がおかしくなって
scasb や、movsb movsw などに来ると、エラーチェックに引っかかって
落ちてしまうのではないかと。

SCASB_MODE=0　での実験でも、ソートしたテキストをセーブはできたのですが
その後 VTDOS が落ちました。
解決の道は遠いかもしれないですね。

> mapファイルとロードアドレスの4バイトのズレはなんなんでしょうね？

あう、すみません、急いでいたのでつい別のバージョンのものを参照して
しまいました。

K07T1
 0000:148C       ENDLIN

こちらが該当のアドレスだと思います。

K07T4
 0000:1490       ENDLIN

こっちのほうが手近にあったもので、つい。(^^;
どうせソースにアドレスは無いと思って。(^^;;

プロの前でごまかしは効きませんね。m(__)m

このマクロ、私にもぜんぜん読めませんがね。

> 	(u<0)?{&s id[,&#T(u) #C u-,&#T(-0]) &d.}
> 　　　　　　　　　　　　　　　　　 ^^^^^^^
> この、&#T のところで落ちました。

１つめの&#Tは通るのですよね。
ここで２つめの&#Tに、保存しておいた id の値を使っていると思うのですが
スタックではなく別の変数に退避させておいたらどうなるでしょうか。
あと、あまり関係あるとは思いませんが、+512のバックアップオプションの
有無で挙動が変わったりとかします？

> １つめの&#Tは通るのですよね。
> ここで２つめの&#Tに、保存しておいた id の値を使っていると思うのですが
> スタックではなく別の変数に退避させておいたらどうなるでしょうか。

読めてないので、改造はまだ無理ですが、ヒントはもらえました。

> あと、あまり関係あるとは思いませんが、+512のバックアップオプションの
> 有無で挙動が変わったりとかします？

これはオプションだったのですか。
説明も読んでなかったもので。

	o32+64+512, ;(ec)?o|=2,		;options

ここの、o の数値を変更すれば動作が変わるんですね。

		; +512	Back Up

これを追っかければ何をしているかわかるかな。

> 読めてないので、改造はまだ無理ですが、ヒントはもらえました。

確かに、読まないと、どの変数があいているかわかりませんね。
でも、いざとなったら、２文字の変数を使ってしまう、とか。

> 	(u<0)?{&s id[,&#T(u) #C u-,&#T(-0]) &d.}
　　　　　　　　　　　↓
> 	(u<0)?{&s dd=id,&#T(u) #C u-,&#T(dd) &d.}

こんな感じ、かな。

> 説明も読んでなかったもので。

大丈夫、私はこのマクロ、使った記憶すらない。
でも、メインマシンのVzディレクトリに解凍してあったんだよなぁ。
うん、PC-98のころは使ったことがあったかもしれない。

dd=id, &#T(-dd)
or
dd=-id, &#T(dd)
ではないかしら。

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

;#O "c:\1.txt" #m a=-id,	;存在すること
#O "c:\1.txt" #m a=id,		;存在すること
#O "c:\2.txt" #m		;同

&#T(-a)

*

c:\wk\sort.def 131
03:	;--- sort ---
	ax..3=dd,

今、上から変数だけ書きだしてます。
あと５分くらいで終了の予定です。

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（高橋版）の問題は解決してしまうかも。

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

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

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

ここで、プッシュ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をコピーしてたりとかしますね。
率直に言ってコワイ。

＊字句、修正しました

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

　僕は、自分が逃げたとはいえ、Ｖｚの脆弱性や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

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

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

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


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

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

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

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

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

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

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


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

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

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

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

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


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

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

「めざら資源」セグマップ
スタックセグメント概略
絶対アドレス	相対アドレス	データ内容
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バイトずれていますね。何故だかわからないです。


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

　手元には、７個くらい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="１９９４年１２月３１日",

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

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

　いちいち顔面蒼白とかしないように。いちいち逆毛とか立てないように。
　けっこう立ち直り、はやかった。
　たしかに、「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#さん、ありがとうございました。

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

		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

> 　手元には、７個くらい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="１９９４年１２月３１日",

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

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

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

	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

うう、結構やばいかも。

>         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          ; -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 に戻った時に
ここを修正するのを忘れていたようです。

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

> マシン語コードの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

これかな。

> 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だけを変えているように見えますから、
> いつかどこかで止まるような気はします。

なるほど、止まるまでに６４K回ループしてしまうんですね。（違うと思う）

ツリーが伸びすぎたので、ここにコメントしますが

VTDOSでSORT.DEF（高橋版）の、ラインバッファが変？

04:	; back up
&t	(o&512)??. (u)?.
	(wf..0)??>f
	i=id,pf[=pr,
	&m("%d %d %d",bl,kp,k)		;★ bl=8192   kp=-7072 k=-25387
	bl[=kp-k,
	&m("%d %d %d",bl,kp,k)		;★ bl=18315  kp=-7072 k=-25387
	#N #P #m (r<0||wa..13+v<bl+v) bl],pf],?{

このように、bl を表示させてみると、コメントに書いたように
 bl=18315 に拡大していますが、bl の最大は確か 8192 バイトだったかと。

この数字だと、バッファが溢れて暴走しませんか？
ソート対象データは、DSEG.MAP です。