再現できないということでしたので，VZT以降のバージョンでいくつか試し，
t03k2	ok
k06v	ok
k07j	ok
k07p	ok
k07s5	ok
k07t2	ok
k07v6d	NG
K07v6h	NG
k07v6i	NG
……という結果を得ました。手元の結果を見る限り，k07v 以降ですね。

最近は VZ だけでいくつもファイルを開いて作業するということはなかったため，
拡張[F03]に割り当てた機能を使う機会がなくて気づかなかったと思われます。

同じ環境になるよう，インクルード含め一式お送りします。
VZ.DEF は実害の少ない一世代前に戻してあります。

63 [F03] ""	;Pick Text (220)	;Close, reOpen, Quit
	(s||wc<1)?.
	ss-, wl[7, #T wl],
　手元の環境では，↑の # が P に置き換えられ，実行すると左下に
PTwlとエラー表示してマクロの実行を停止します。

> 同じ環境になるよう，インクルード含め一式お送りします。
> VZ.DEF は実害の少ない一世代前に戻してあります。

メールでいただきました。ありがとうございます。
再現が上手くいかないので、マクロを丸ごと入れ替えてしまいました。(^^;
うう、非常に使いづらいですぅ。(>_<)
やっぱりVZは自分の環境が一番というか、他人のVZ環境は使えない体なのでせうか。

この結果、ほぼ同じアドレスになったのですが、入れ替わりは見つかりません。
そのかわり、別の奇妙な現象が出ています。詳細は後ほど。

> 再現できないということでしたので，VZT以降のバージョンでいくつか試し，
> k07t2	ok
> k07v6d	NG
> K07v6h	NG
> k07v6i	NG
> ……という結果を得ました。手元の結果を見る限り，k07v 以降ですね。

VZk07t02 はVZのバグ修正テスト版ですよね、それでは異常が出ないのですか。
自作、改作アプリの放置部屋にある VZT-P.COM も試してもらえるとありがたいです。

> 	ss-, wl[7, #T wl],
> 　手元の環境では，↑の # が P に置き換えられ，実行すると左下に
> PTwlとエラー表示してマクロの実行を停止します。

再現環境のインスタント窓で ＄2225 を入れると、"#Twl" が表示されました。
DUMP.DEF で見てもこの周辺は異常が見つからなかったです。

> 手元の環境だけしか現象が出ないのでは解決の緒にもならないので，
> 当面は工夫しつつ様子を見ようと思います。

一つ思い当たる所に気が付きました。
私家版は10＃さんのルーチンを導入しているのですが、LFNの一時バッファが
 260Bytes あるので、そこを tmpbuf4 で代替していました。
色々見ていると、STKHLP の記述で

> 　tmpbuf4
> 　・256 バイトのテンポラリ領域。（ラインバッファの直後）
> 　  ラインバッファあふれのチェック用領域。
> 　・&z 等のマクロ組込時以外は比較的自由に使用できる。
>   > pn..-26

こう書いてありました。
> 　・&z 等のマクロ組込時以外は比較的自由に使用できる。
マクロの組込で tmpbuf4 を使うと不具合が出る可能性があるのですね。
私は無意識に不具合を回避するようにしていたのかもしれません。

めざらさんの VZ.DEF に pn..-26 （tmpbuf4）を使う記述があったので気が付いたのです。
10＃さんのルーチンに戻した版をメールで送りますので試してみてください。

> 早速試してみたところ，書き換わるという状況は変わりませんでした．

残念、これは関係なかったですか。
でも tmpbuf4 はどこで使われるかわからないので、この方向にしようと思います。

> ただ，ちょっと不思議なのが，見かけ上（……と言うのか，マクロファイルの）は
> 書き換わる位置が変わらず，当該マクロを実行すると停止する同じ症状ですが，
> 書き換わるアドレスが変わって 2329h 付近になりました．だいぶ違う……(?_?)
> ある位置からの相対アドレスは変わっていないけれど，マクロバッファの使い方が
> 変わったということでしょうか．

書き換わる位置が変わらないということは、マクロ内での挙動なのですかね？
書き換わるアドレスが変わって 2329h 付近になったのは一時バッファの影響でしょう。

> マップで見ると，システム領域が500バイトほど
> 増えているのですね．ああ，LFN の一時バッファをそこに取ったということ？

そうなんですが、260バイト のはずが 500バイト増えてるとは、位置が悪いのかなぁ？
実行ファイルのサイズ増加分も含んでいるのかしら？

実は、10＃さんのルーチンでは、MAIN.ASM の pn.11 の後ろになっています。

11	wsplit0		db	0		; pn.11
GDATA lfntmp,	db,	<MAXPATH+1 dup(0)>  ; ## 10# mod 260 LFN maxpath

この後ろも ポインタで参照されそうだと思ったので、繋がりが切れていると思われる
 EXPR.ASM のローカルデータの後ろに置きました。
もしかしたら副作用があるかもしれませんね。

> ごめんなさい，ざっくりしたマップを見て適当に言いましたが，260バイトですね。
> 256を超えたので2区画取ったように見えてしまっただけです。

なるほど、そういうことですか、了解です。

> 手元では直前の版の mh が $E0F で，テスト版の mh が $F13 でした。
> 版によって絶対アドレスが変わるので，以後 mh+$1416 付近と言うことにします。
> 試しに念のため mh+$1416 を確認してみていただけるでしょうか。

うちの環境では、mh は $F7B でした。そのせいか、mh+$1416 に文字化けはありませんでした。
試しに $F13+$1416 を見たら "・:r(lx)?{#s(ct>" と中黒になっていて、ここは VZ.DEF の 510行目

61 ^A ""	;Line Top m.gann;[\] back str
	?. (ks&1)?{ #a :r (lx)?{ #s (ct>2+ck)?>r #d }. }
　　　　　　　　　　↑　
ここみたいです。"#a" が中黒（$8145）に文字化けしていますね。

63 [F03] ""	;Pick Text (220)	;Close, reOpen, Quit
	(s||wc<1)?.
	ss-, wl[7, #T wl],
　　　　　　　　　↑
めざらさんのここより13行手前が文字化けしているようですね。
私の環境では挙動がおかしいので他にも不具合があるようです。
これを手掛かりに調べてみます。

> もっとも最近は [ESC]^ で呼び出すことが結構多いですね．
> （高橋版ベースならインクリメントサーチのできるファイラなので楽）

そうか、 [ESC]^ でしたね、これがわからなかったのでした。アルツじゃ〜

> ばつつあのマニュアルを読んでいただければよいわけですが……

す、すみません、お手数をおかけして。m(__)m

> メッセージラインに表示されたコード範囲の一番最初（左端）に該当部分を
> 合わせるために \[←]／\[→] で 1バイトずつスライド表示して調整します．
> メッセージラインの最初にその「中黒」を持ってこられたら [UP] でコードを確認．
> [DOWN] で元に表示に戻せます．（DUMPでも分かるでしょうけど）

出来ました！　これですね。

2329h:'・=88h=136 '・'=5488h=21640=21640    ・wl],:P&p&u(r)(r)>!{(#t-c2&r)>C

中黒のコードは 5488h ですね、DUMP でも同じでした。
CTRL.DEF で $8854 は以下になりました。見た目は中黒($8145)と同じですね。
　・

> 2329h:'・=88h=136 '・'=5488h=21640=21640    ・wl],:P&p&u(r)(r)>!{(#t-c2&r)>C

#T（23h 54h）が 88h 54h になりますか…… 2バイトではなく 1バイト書換えですね．
……ということであれば，相対的な書換え位置は確定ということで OK ？
書換え位置は変わらず，ちょっとした環境の違いで異なる値になるということかな．

他の方の環境で mh+$1416 はどうなっているでしょうか．
[ESC]@ などで即席確認できますので，見ていただけるでしょうか？
konno さんも，ご自身の環境で確かめてみてください．

わたしは検証用として製品版DEFに巨大自前バッファを配置して，
mh+$1416 以外に書換えが発生していないか確認してみようと思います．

> ……ということであれば，相対的な書換え位置は確定ということで OK ？
> 書換え位置は変わらず，ちょっとした環境の違いで異なる値になるということかな．

VZ.COM の各種バージョンで試してみたら、アドレス違いのバージョンもありました。

2018/10/07  19:12            62,664 vzk75e.com		mh+$13f0=$2303
62 ^F ""	;Line End m.gann;[\] next spc
	?. (ks&1)?{ (ct<3)?#f :r #d (ct>2+ck)?>r. }
　　　　　　　　　　　　　　　　　　　　　↑
21F9: 72 23 64 28 63 74 3E 32-88 63 6B 29 3F 3E 72 2E  r#d(ct>2・k)?>r.
"+"($2B) → $88

2017/09/09  09:28            62,666 vzk7t5.com		mh+$13f2=$2305
62 ^F ""	;Line End m.gann;[\] next spc
	?. (ks&1)?{ (ct<3)?#f :r #d (ct>2+ck)?>r. }
　　　　　　　　　　　　　　　　　　　　　 ↑
2203: 2B 63 88 29 3F 3E 72 2E-7D 23 66 00 3F 18 01 FF  +c･)?>r.}#f･?･･･
"k"($6B) → $88

2017/09/06  22:39            62,644 vz-5.com		mh+$13dd=$22f0
	?. (ks&1)?{ (ct<3)?#f :r #d (ct>2+ck)?>r. }
　　　　　　　　 ↑
 21E3: 00 06 FF 00 3F 2E 28 6B-73 26 31 29 3F 88 28 63  ････?.(ks&1)?･(c
"{"($7B) → $88

基本的に VZK07T5 以降で現象が起きているようですが、アドレスが違いますね。
上記の例では、置き換わるコードの一桁目が "$B" で共通しているのが興味深いですね。
ビットの下4桁が 1011 ですね。

あと、例外もありました。

2015/11/04  00:36            62,262 vzk7t2a.com		mh+$13af=$22c2
61 ^A ""	;Line Top m.gann;[\] back str
	?. (ks&1)?{ #a :r (lx)?{ #s (ct>2+ck)?>r #d }. }
　　　　　　　　　　 ↑
21B5: 73 26 31 29 3F 7B 23 88-3A 72 28 6C 78 29 3F 7B  s&1)?{#･:r(lx)?{
"a"($61) → $88

これは中身を見てみないとなんともいえないですね。
ビットは 0001 か・・・
"#"($23) 0011 うーむ・・・

> その環境って，わたしがお送りした DEF なわけだと思いますが，
> konno さんの手元の環境では書換えは発生していないということでしょうか？

はい、めざらさんの DEF です。
私の DEF では表面上は出ていないですが、わかりません。

めざらさんの DEF では他の現象も出ました。
2017/09/09  09:23   62,666 vza.com
この版などいくつかの版では、書換は確認できません。
そのかわり、マクロモジュールの破壊が起こる場合があります。

VZ起動してファイルを読み込んで、[ESC]M でマクロモジュールメニューを出すと

┏━ Modules <free:20002/30269> ━━━━━┓
┃  ! vz.def v1.6                    6479 ┃
┃    fl.def v1.6                     569 ┃
┃    outlaw.def (v2.20)              999 ┃
┃    automenu.def                    778 ┃
┃    ex                              790 ┃
┗━━━━━━━━━━━━━━━━━━━━┛

こうなっていますが、free 表示がおかしいですね。これで
DUMP.DEF のファイルを開いて、^k^ で再カスタマイズすると

┏━ Modules <free:-9609/658> ━━━━━━┓
┃  ! vz.def v1.6                   33303 ┃
┃ E  Dump.def                       5923 ┃
┗━━━━━━━━━━━━━━━━━━━━┛

こうなります。他のモジュールが消えて free がマイナスになりました。

この free 表示には
10	"Modules <free:$BM/$x>",40,0
このシステムメニューで、変数 x を使っていますよね。

5 [ESC]M @M "Module Menu"	;Yushi  local:H･ear
	x$fdfb+bm-pn..-26,                      ; dc15#5267 m.gann
ここで変数 x を設定していると思います。
このルーチンは私も意味も分からないまま使っています。
この定数 $fdfb って何なのでしょう？


ちなみに、再カスタマイズルーチンは
56 ^K^ "Install"
	?. &#80(0)

この後ろの方にマクロを追加してみました。

80 @^ "~"	"〜" .

これでマクロサイズが少し増えたので試すと
 Modules <free:20002/30255>
となり、DUMP.DEF を ^k^ で再カスタマイズすると

┏━  Modules <free:14079/24332>  ━━━━┓
┃  ! vz.def v1.6                    6492 ┃
┃    fl.def v1.6                     569 ┃
┃    outlaw.def (v2.20)              999 ┃
┃    automenu.def                    778 ┃
┃    ex                              790 ┃
┃ E  Dump.def                       5923 ┃
┗━━━━━━━━━━━━━━━━━━━━┛

こうなって正常に出来ました。


＃　どうなっているんじゃ〜〜

> 　やったこと（泥縄、「まだやれることはある！」作戦）、大筋は理解できました。

私は素人なのでプロのようにデバッガを駆使してとか出来ませんので。(^^;

> 　詳細は分かりませんが、ファイラでもWD使うんだ。filer2.asmでなく。
> dos/vですものね。

ファイラーの窓枠の幅は、80桁固定なんですよね。WD=80 という定数を使っています。
ロングファイラー実現のためには WD をそのまま使えないので、fl_wd というローカルワークに窓幅を入れたのです。

	pushm	<ax,es>				; ##k
	clr	ax				;
	mov	es,ax				;
	mov	al,byte ptr es:[dosscrn_sx]	; ##156.123
	mov	fl_wd,al			;

fl_wd に DOSの幅の数値を入れたのですが、これだと SSセグメント（マクロバッファ）に入ったみたいなのです。

	mov	cs:fl_wd,al			;

このように、 CS: を付ければ書き込み先がコードセグメントに指定されるのでした。

> 　とんでもなく暑い夏ですが、konnoさん、、、、好きです！

わ、私には妻が・・・(ﾟ゜)☆＼(--#)ﾊﾞｷｯ
もちろんこれは冗談ですが、私も皆さんが好きです。
よかったら試してみてね。♪

暇、じゃなくて夏バテで何もやる気が起きないので、ゲームを弄ってみました。
たまたま目に入った mogura.def をやってみましたが、動作がおかしい。
KVZ以外では正常に動いているみたいなのですが、KVZのバグ？
不具合の内容は

・ステータスラインの色消しが効いていない
・終了時に WE 編集画面幅が 2 になってしまう

現象から見てプッシュポップの不具合とか？
KVZのかなり初期まで同じ現象になります。げげげ

・・・・あれ？　これってもしかして、
#if kVZ
の分岐の不具合、たぶんオープンイベントマクロの不具合？

調べてみるとやはりオープンイベントマクロの不具合でした。

1 "!Open"
#if kVZ
	Vu-,as112,ao224,ar176,
	&Sf(nm,'.') (r)?? { ts="\x ^[EOL#%(]", Ew-,Eu-, }
	p[, p=r,
	&So(".hte",p) (r)?{ Vu+,as~,ao~,ar~,ts="\x ^\0/\0",Ew+,mr128, >A }
	(ne=='LE'||ne=='TE')?{ Vu+,as~,ao~,ar~,ts="\x ^\0/\0",Ew+,mr128, >A }
#endif
	p[, p=r,
:A	p],

こんなことをやっていました。
これでは設定していない拡張子のオープン時、プッシュポップが狂ってしまいます。(>_<)
うげぇ、今までこんな状態で使っていたんだ・・・・

ということで、mogura.def のおかげでマクロのバグを発見出来ました。
ありがとうございます。m(__)m


＃　このゲーム、点数がマイナスになっちゃうので悲しい。(;_;)
　　w150, を w600, にすると間延びした感じで・・・
　　[ESC] を押してもすぐに終わらないので、改造出来ないかしら・・・

そうそう、mogura.def とは、めざらさん作のもぐらたたきゲームです。m(__)m