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

一括表示


  ある現象 - めざら 23/07/26-11:10 No.10877
 ┣ Re: ある現象 - konno 23/07/26-22:43 No.10878
 ┃┃┣ Re^2: ある現象 - としき 23/07/26-22:48 No.10879
 ┃ ┗ Re^2: ある現象 - めざら 23/07/27-07:49 No.10880
 ┃ ┗ Re^3: ある現象 - konno 23/07/27-22:39 No.10881
 ┣ Re: ある現象の絞り込み - konno 23/07/29-00:21 No.10882
 ┃ ┗ Re^2: ある現象の絞り込み - めざら 23/07/29-09:42 No.10883
 ┃ ┗ Re^3: ある現象の絞り込み - konno 23/07/29-22:52 No.10884
 ┃  ┗ 別の奇妙な現象 - konno 23/07/30-00:34 No.10885
 ┃   ┗ Re: 別の奇妙な現象 - めざら 23/07/31-09:41 No.10886
 ┃    ┗ Re^2: 別の奇妙な現象 - konno 23/07/31-21:15 No.10887
 ┃     ┗ Re^3: 別の奇妙な現象 - めざら 23/08/01-07:29 No.10888
 ┃      ┗ 修正テスト版 - konno 23/08/02-22:09 No.10889
 ┃       ┗ Re: 修正テスト版 - めざら 23/08/03-17:36 No.10890
 ┃        ┗ Re^2: 修正テスト版 - konno 23/08/03-23:43 No.10891
 ┃         ┗ Re^3: 修正テスト版 - めざら 23/08/04-08:43 No.10892
 ┃          ┗ Re^4: 修正テスト版 - konno 23/08/04-20:12 No.10893
 ┃           ┗ Re^5: 修正テスト版 - めざら 23/08/04-23:49 No.10894
 ┃            ┗ Re^6: 修正テスト版 - konno 23/08/05-00:14 No.10895
 ┃             ┗ Re^7: 修正テスト版 - めざら 23/08/05-07:51 No.10896
 ┃              ┗ Re^8: 修正テスト版 - konno 23/08/05-17:08 No.10897
 ┃               ┗ Re^9: 修正テスト版 - めざら 23/08/05-23:33 No.10898
 ┃                ┗ Re^10: 修正テスト版 - konno 23/08/06-01:26 No.10899
 ┃                 ┗ k07v系におけるマクロバッファ書換え位置確定? - めざら 23/08/06-07:47 No.10900
 ┃                  ┣ k07v系の問題ではないのか? - めざら 23/08/06-10:20 No.10901
 ┃                  ┃ ┗ 結局一時しのぎで - めざら 23/08/06-11:39 No.10902
 ┃                  ┃ ┗ Re: 結局一時しのぎで - konno 23/08/06-23:49 No.10904
 ┃                  ┗ Re: k07v系におけるマクロバッファ書換え位置確定? - konno 23/08/06-23:40 No.10903
 ┃                   ┗ Re^2: k07v系におけるマクロバッファ書換え位置確定? - めざら 23/08/07-07:39 No.10905
 ┃                    ┗ Re^3: k07v系におけるマクロバッファ書換え位置確定? - konno 23/08/08-02:34 No.10906
 ┃                     ┗ Re^4: k07v系におけるマクロバッファ書換え位置確定? - めざら 23/08/08-18:24 No.10907
 ┃                      ┗ Lf+ が原因か? - konno 23/08/09-01:15 No.10908
 ┃                       ┗ Re: Lf+ が原因か? (確認しました) - めざら 23/08/09-08:20 No.10909
 ┃                        ┗ Re^2: Lf+ が原因か? (確認しました) - konno 23/08/10-01:17 No.10910
 ┗ 原因はロングファイラー - konno 23/08/16-21:18 No.10911
  ┣ Re: 原因はロングファイラー - 文太 23/08/17-00:18 No.10913
  ┃ ┗ Re^2: 原因はロングファイラー - konno 23/08/17-01:15 No.10914
  ┗ Re: 原因はロングファイラー - めざら 23/08/17-18:51 No.10915
   ┗ Re^2: 原因はロングファイラー - konno 23/08/18-01:23 No.10917

(10877) 10877ある現象  投稿者:めざら   2023/07/26(水) 11:10
参照先:http://mezala.la.coocan.jp/
   コメント数 3

自分の環境だけの問題なのかもしれないのですが,一応報告を上げておきます。

マクロバッファのオフセットアドレス $2225【付近】が書き換わる。
起動時からそのようなので「書き換わる」は正確ではないかもしれません。
実行環境によって別のコードになるものの,場所は同じ。

【経緯】(明記しない場合は VTDOS 環境)
いつの時点からは不明だが,内部マクロの実行がエラーで停止し判明。
Buftour.def でマクロバッファを確認すると,# が P になっていた。
(具体的には,#T が PT になっていたので,そこで停止した。)
同じバッチで起動する dosvaxj3 環境では,同じ場所が U になっていた。

内部マクロの順序を入れ替えると,当該マクロ(拡張[F03])は正常に動作。
しかし,一方で別のマクロが書き換わることが判明。場所は $2225 付近で同じ。
こちらは拡張^F で #f が #P に書き換わっており,実害を伴うことに。
dosvaxj3 環境では #f が #U に書き換わっていた。パターンは同じ。

K07V6J (2023-05-19)
K07V6H (2023-03-14)
ともに同様の振る舞いでした。

お手元の環境でご確認いただけるでしょうか>みなさま
(【付近】と言うのは,前後広めに確認をお願いしたいためです)
なお,手元の内部マクロに自己書換えするようなコードは見当たりません。
なので,マクロバッファへ読み込まれる時点での可能性もあるかと思います。

もっとテストしてから報告しろという見方もあるかと思いますが,
ともかく現象面から発現の有無を見てもらうのが手っ取り早いかと思い
お願いする次第です。
      - No.10877 -    このTreeへ           [リストへもどる] soft

(10877) 10878Re: ある現象  投稿者:konno   2023/07/26(水) 22:43
    10877 番 めざら さんへのコメント    コメント数 2

> マクロバッファのオフセットアドレス $2225【付近】が書き換わる。
> 起動時からそのようなので「書き換わる」は正確ではないかもしれません。
> 実行環境によって別のコードになるものの,場所は同じ。

これはヤバいですね、メインのマクロを読み込む時点でおかしくなるのでしょうか。

> 【経緯】(明記しない場合は VTDOS 環境)
> いつの時点からは不明だが,内部マクロの実行がエラーで停止し判明。
> Buftour.def でマクロバッファを確認すると,# が P になっていた。

私今アルツか暑いせいで全て忘れているような状態です。(^^;
Buftour.def でマクロバッファを確認は、どういう手順でしたっけ?

> 同じバッチで起動する dosvaxj3 環境では,同じ場所が U になっていた。

これはプラットフォームの問題ではなくVZの問題と思われますね。

> K07V6J (2023-05-19)
> K07V6H (2023-03-14)
> ともに同様の振る舞いでした。

他のVZでは問題なしということでしょうか。
マジで色々忘れているので、再現手順とか色々ご教授願います。m(__)m
他の方の情報もあればありがたいです。

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

(10877) 10879Re^2: ある現象  投稿者:としき   2023/07/26(水) 22:48
参照先:http://toshiki.la.coocan.jp/
    10878 番 konno さんへのコメント

> 私今アルツか暑いせいで全て忘れているような状態です。(^^;
> Buftour.def でマクロバッファを確認は、どういう手順でしたっけ?

同じく、確認方法がわかりません。
私の場合、忘れている、ではなく、最初から知らないと思う。
ばふつあなんて、使ったことがないかもしれない、というくらい。

ということで、

> マジで色々忘れているので、再現手順とか色々ご教授願います。m(__)m

私も同じく。
どの環境とどのバージョンなら再現しない、という報告ぐらいは上げられると
思います。

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

(10877) 10880Re^2: ある現象  投稿者:めざら   2023/07/27(木) 07:49
参照先:http://mezala.la.coocan.jp/
    10878 番 konno さんへのコメント    コメント数 1

#10878 konnoさん #10879 としきさん

ばふつあでの確認手順ですが,特定のアドレスなら割りと簡単です。

起動してメニューが表示されたら,Offset(メニューの最下部)を選択し,
入力窓で「$2200」のようにアドレスを入力すると,メッセージラインに
該当するアドレスがら64バイトのメモリを可読文字で表示します。(終了は Q )
別のウィンドウで VZ.DEF 等をオープンしておくと比較が楽でしょう。

ちなみに以下のモジュールメニューを組み込むと,ばふつあをより便利に使えます。
http://mezala.la.coocan.jp/vz/workshop/mkoban.html#mdlmenu
(ちょっと宣伝 (^^;)
      - No.10880 -    このTreeへ    コメント元:10878 へ [リストへもどる] soft

(10877) 10881Re^3: ある現象  投稿者:konno   2023/07/27(木) 22:39
    10880 番 めざら さんへのコメント

> 起動してメニューが表示されたら,Offset(メニューの最下部)を選択し,
> 入力窓で「$2200」のようにアドレスを入力すると,メッセージラインに
> 該当するアドレスがら64バイトのメモリを可読文字で表示します。(終了は Q )

ありがとうございます。
最初メニューに Offset が無いなぁと思ったら、次ページだったのですね。(^^;

ふーむ、このアドレスはインスタント窓で $2225 を入れた時の表示と同じみたいですね。
DUMP.DEF の窓で $2200 でも同じみたいです。
これから色々試してみます。

> ちなみに以下のモジュールメニューを組み込むと,ばふつあをより便利に使えます。
> http://mezala.la.coocan.jp/vz/workshop/mkoban.html#mdlmenu
> (ちょっと宣伝 (^^;)

これは機能が高度すぎて今の私には使いこなせそうもないです。(^^;
まあぼちぼちとリハビリします。(^^;

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

(10877) 10882Re: ある現象の絞り込み  投稿者:konno   2023/07/29(土) 00:21
    10877 番 めざら さんへのコメント    コメント数 1

今のところ再現とか出来ていません。
再確認ですが

> いつの時点からは不明だが,内部マクロの実行がエラーで停止し判明。

これは、VZを K07V6J (2023-05-19) に入れ替えてから出るようになったのでしょうか。
高橋版やそれ以前のKVZでは現象が出ないのでしょうか。

> Buftour.def でマクロバッファを確認すると,# が P になっていた。
> (具体的には,#T が PT になっていたので,そこで停止した。)
> 同じバッチで起動する dosvaxj3 環境では,同じ場所が U になっていた。

この現象と

> 内部マクロの順序を入れ替えると,当該マクロ(拡張[F03])は正常に動作。
> しかし,一方で別のマクロが書き換わることが判明。場所は $2225 付近で同じ。
> こちらは拡張^F で #f が #P に書き換わっており,実害を伴うことに。
> dosvaxj3 環境では #f が #U に書き換わっていた。パターンは同じ。

この現象は、ともに同じアドレスが
VTDOSは、  P に書き換わる
dosvaxj3 は、U に書き換わる

ということですね。環境の違いでアドレスか数値に違いが出るように見えますね。

現象が VZ.DEF で出ているとすれば、同じ環境で試してみたいです。
よろしければそのVZ.DEF をメールでいただけないでしょうか。

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

(10877) 10883Re^2: ある現象の絞り込み  投稿者:めざら   2023/07/29(土) 09:42
参照先:http://mezala.la.coocan.jp/
    10882 番 konno さんへのコメント    コメント数 1

再現できないということでしたので,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とエラー表示してマクロの実行を停止します。

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

(10877) 10884Re^3: ある現象の絞り込み  投稿者:konno   2023/07/29(土) 22:52
    10883 番 めざら さんへのコメント    コメント数 1

> 同じ環境になるよう,インクルード含め一式お送りします。
> 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 で見てもこの周辺は異常が見つからなかったです。

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

(10877) 10885別の奇妙な現象  投稿者:konno   2023/07/30(日) 00:34
    10884 番 konno さんへのコメント    コメント数 1

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

さて、別の奇妙な現象なのですが
めざらさんのマクロで再現環境にしたVZでは

" 2" の文字列、つまり、スペース+2 の文字列の色が暗い青になってしまうのです。
文字列の色を変えるのは、TAGLIGHT.EXE くらいです。
関連マクロは動作していないので、素のTAGLIGHT.EXE がやっている
可能性がありますが TAGLIGHT.PAT にそのような設定はしていません。
TAGLIGHT.PAT の 1文字が変わってもそういう動作になる設定はありません。

めざらさんのマクロで再現環境にしたVZでは高橋版VZでも同じ症状になりました。
VTDOSの最新環境の中で VZ.COM を入れ替えただけなので、バッチから変えればまた違うかも。
うちの環境では、メインメモリ上のどこかを書き換えているのかもしれません。


# じょじょに奇妙な冒険は続くのか・・・
  ハッ! スタンドに攻撃されている!? (゚゜)☆\(--#)バキッ

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

(10877) 10886Re: 別の奇妙な現象  投稿者:めざら   2023/07/31(月) 09:41
参照先:http://mezala.la.coocan.jp/
    10885 番 konno さんへのコメント    コメント数 1

" 2" 20h 32h ということですね。
うちでは部分的に属性が変わるという現象はないですね。まさしく謎です。
書換えの現象も見られないんですよね。同じ DEF なのに?!

> うちの環境では、メインメモリ上のどこかを書き換えているのかもしれません。

そのようにお考えになる理由を少しだけ説明していただけますか?
コンソールの設定ということですよね。

ただ,VTDOS と DOSVAXJ3 で(同一ではないが)同様の現象がみられるので,
どこを切ったらネタが出てくるのか分かるような分からないような……

謎ですねぇ……
      - No.10886 -    このTreeへ    コメント元:10885 へ [リストへもどる] soft

(10877) 10887Re^2: 別の奇妙な現象  投稿者:konno   2023/07/31(月) 21:15
    10886 番 めざら さんへのコメント    コメント数 1

> " 2" 20h 32h ということですね。

そうなりますね。もちろん検索文字列でもありません。

> 書換えの現象も見られないんですよね。同じ DEF なのに?!

書換の現象の代わりに上記の謎現象が起こったのではないかと考えています。
そうすると、メモリのどこかを壊しているのではないかと考えたわけです。

> コンソールの設定ということですよね。

TAGLIGHT.EXE の挙動と思っていましたが、VZの設定で、上記文字列が
コントロールコードとして書換られたら同じ現象になるかもですね。
そうなると、VZの中で問題が出ていることになるので、この可能性が高いかも。

> ただ,VTDOS と DOSVAXJ3 で(同一ではないが)同様の現象がみられるので,
> どこを切ったらネタが出てくるのか分かるような分からないような……

うちでは、DOSVAXJ3 では現象が表面上は見られませんでした。
また、環境を少し変えただけで VTDOS でも同じ現象は無くなりました。
その代わり、VZにまた別の変な挙動が出てきたようです。

当初 VZのバグ対策パッチが原因かと思ったので、パッチ版のテストをお願いしたのですが
パッチ版で現象が出なければ、最近の私家版VZが原因の可能性が高いと思ったのです。
今は可能性を一つ一つ絞り込んでいくしかないと思っています。

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

(10877) 10888Re^3: 別の奇妙な現象  投稿者:めざら   2023/08/01(火) 07:29
参照先:http://mezala.la.coocan.jp/
    10887 番 konno さんへのコメント    コメント数 1

当面は,書換え先(…がただの1箇所だけとの希望的仮定ですが…)のアドレスが
非ヒストリ自前バッファに当たるよう内部マクロの配置を工夫するしかないかな〜。

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

あ,製品版サンプルDEFにでっかい自前バッファを配置して,本当に1箇所なのか
検証してみるってのも一歩かな。それなら簡単だし。
      - No.10888 -    このTreeへ    コメント元:10887 へ [リストへもどる] soft

(10877) 10889修正テスト版  投稿者:konno   2023/08/02(水) 22:09
    10888 番 めざら さんへのコメント    コメント数 1

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

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

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

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

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

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

(10877) 10890Re: 修正テスト版  投稿者:めざら   2023/08/03(木) 17:36
参照先:http://mezala.la.coocan.jp/
    10889 番 konno さんへのコメント    コメント数 1

テスト版をわざわざお送りくださり,ありがとうございます.
早速試してみたところ,書き換わるという状況は変わりませんでした.

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

ある位置からの相対アドレスは変わっていないけれど,マクロバッファの使い方が
変わったということでしょうか.マップで見ると,システム領域が500バイトほど
増えているのですね.ああ,LFN の一時バッファをそこに取ったということ?

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

(10877) 10891Re^2: 修正テスト版  投稿者:konno   2023/08/03(木) 23:43
    10890 番 めざら さんへのコメント    コメント数 1

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

残念、これは関係なかったですか。
でも 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 のローカルデータの後ろに置きました。
もしかしたら副作用があるかもしれませんね。

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

(10877) 10892Re^3: 修正テスト版  投稿者:めざら   2023/08/04(金) 08:43
参照先:http://mezala.la.coocan.jp/
    10891 番 konno さんへのコメント    コメント数 1

取り急ぎ発言修正を。

> 260バイト のはずが 500バイト増えてるとは、位置が悪いのかなぁ?

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

手元では直前の版の mh が $E0F で,テスト版の mh が $F13 でした。
版によって絶対アドレスが変わるので,以後 mh+$1416 付近と言うことにします。

試しに念のため mh+$1416 を確認してみていただけるでしょうか。

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

(10877) 10893Re^4: 修正テスト版  投稿者:konno   2023/08/04(金) 20:12
    10892 番 めざら さんへのコメント    コメント数 1

> ごめんなさい,ざっくりしたマップを見て適当に言いましたが,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行手前が文字化けしているようですね。
私の環境では挙動がおかしいので他にも不具合があるようです。
これを手掛かりに調べてみます。

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

(10877) 10894Re^5: 修正テスト版  投稿者:めざら   2023/08/04(金) 23:49
参照先:http://mezala.la.coocan.jp/
    10893 番 konno さんへのコメント    コメント数 1

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

ちょっと分からないのですが,mh が $F7B になる版はどれですか? 超私家版?
mh が $F13 になるのは k07v6k(20230802) なので,さらにシステム領域が増えた版ということですか?
(めざらはカンチガイしているのか…… mh はいずれの環境でも版固有の値をとるのではないのか……)


いずれにしても,マクロバッファ書換えの症状は存在するということですね.
ただ,2バイト書き換わっているというのは新しい症状のように思います.
わたしの手元では1バイトの書換えで収まっているので,より重い症状のような……

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

(10877) 10895Re^6: 修正テスト版  投稿者:konno   2023/08/05(土) 00:14
    10894 番 めざら さんへのコメント    コメント数 1

> ちょっと分からないのですが,mh が $F7B になる版はどれですか? 超私家版?
> mh が $F13 になるのは k07v6k(20230802) なので,さらにシステム領域が増えた版ということですか?
> (めざらはカンチガイしているのか…… mh はいずれの環境でも版固有の値をとるのではないのか……)

すみません、あまりに使いずらいので自分のDEFをインクルードするために BM を変えていました。m(__)m
元のDEFにしたら、mh が $F13 になりました。
結果、mh+$1416 に文字化けが出ました。

"・wl],:P&p&u(r)("

うう、何故中黒になるのかはわかりません。
これらの結果を踏まえて調べてみます。m(__)m

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

(10877) 10896Re^7: 修正テスト版  投稿者:めざら   2023/08/05(土) 07:51
参照先:http://mezala.la.coocan.jp/
    10895 番 konno さんへのコメント    コメント数 1

そんなに言うほど使いにくいですかね〜.(笑)
基本的なキーアサインは変えていませんが,因みにどこに一番違和感が?

それはともかく,ですが

ばふつあで,その中黒に合わせて [UP](コード表示)してみてください.
本当に中黒(8145h)なのか,未定義コード(例えば 8259h など)なのか確認できます.
未定義コードが中黒で表示されるフォントの場合がある(結構多い)と思われるので,
そこはきっちり確認した方がよいかと思います.
      - No.10896 -    このTreeへ    コメント元:10895 へ [リストへもどる] soft

(10877) 10897Re^8: 修正テスト版  投稿者:konno   2023/08/05(土) 17:08
    10896 番 めざら さんへのコメント    コメント数 1

> そんなに言うほど使いにくいですかね〜.(笑)
> 基本的なキーアサインは変えていませんが,因みにどこに一番違和感が?

マクロのキーアサインが色々違うし、私は Fキーで覚えているので他人のVZはわからないのです。
めざらさんは OUTLAW派のようですが、私は EXMENU がメインなのです。
私はバフツアもわからないので DUMP.DEF を使いたいのですが、起動法がわからない。(>_<)
めざらさんのVZ.DEFの [F03] の後ろに 起動キーを書きました。(^^;

> ばふつあで,その中黒に合わせて [UP](コード表示)してみてください.
> 本当に中黒(8145h)なのか,未定義コード(例えば 8259h など)なのか確認できます.

えーと、この操作がわからないです。


VZのバグパッチ版は関係ないことはわかりました。
現在VZの版の特定の絞り込みをしています。

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

(10877) 10898Re^9: 修正テスト版  投稿者:めざら   2023/08/05(土) 23:33
参照先:http://mezala.la.coocan.jp/
    10897 番 konno さんへのコメント    コメント数 1

> めざらさんは OUTLAW派のようですが、私は EXMENU がメインなのです。

OUTLAW は記述が簡易にできるからなのですが,EXMenu はわたしもよく使いますよ.
もっとも最近は [ESC]^ で呼び出すことが結構多いですね.
(高橋版ベースならインクリメントサーチのできるファイラなので楽)
割り当てたキーアサインよりファイル名の方が直感的だったりするので.

> えーと、この操作がわからないです。

ばつつあのマニュアルを読んでいただければよいわけですが……
メッセージラインに表示されたコード範囲の一番最初(左端)に該当部分を
合わせるために \[←]/\[→] で 1バイトずつスライド表示して調整します.
メッセージラインの最初にその「中黒」を持ってこられたら [UP] でコードを確認.
[DOWN] で元に表示に戻せます.(DUMPでも分かるでしょうけど)
      - No.10898 -    このTreeへ    コメント元:10897 へ [リストへもどる] soft

(10877) 10899Re^10: 修正テスト版  投稿者:konno   2023/08/06(日) 01:26
    10898 番 めざら さんへのコメント    コメント数 1

> もっとも最近は [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)と同じですね。
 ・

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

(10877) 10900k07v系におけるマクロバッファ書換え位置確定?  投稿者:めざら   2023/08/06(日) 07:47
参照先:http://mezala.la.coocan.jp/
    10899 番 konno さんへのコメント    コメント数 2

> 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 以外に書換えが発生していないか確認してみようと思います.

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

(10877) 10901k07v系の問題ではないのか?  投稿者:めざら   2023/08/06(日) 10:20
参照先:http://mezala.la.coocan.jp/
    10900 番 めざら さんへのコメント    コメント数 1

ううう,製品版DEFで起動すると,書換えが確認できませんでした.(?_?)

以下,やってみた手順を示します.
1 製品版DEFに手を加えずに k07v6k で起動(vz/vzibmjなど)
 書換えを確認できず.(mh+$1416 は vzfl.def のマクロエリア最後の方を指す)
2 製品版DEFのBMのみ30000に書換えて同様に起動
 書換えを確認できず
3 製品版DEFのマクロエリアの最後に自前バッファを配置して起動
 44 ""
 01:"$(00,20)$[8192]"
 上記の自前バッファを,矩形ブロック呼出マクロ(43)の直後に配置
 書換えを確認できず
 周辺はすべてヌルで埋められているまま.

う〜ん...いよいよわからなくなってきた.
k07v6系の問題ではないということ??

他に検証方法を思いつかないなぁ……
      - No.10901 -    このTreeへ    コメント元:10900 へ [リストへもどる] soft

(10877) 10902結局一時しのぎで  投稿者:めざら   2023/08/06(日) 11:39
参照先:http://mezala.la.coocan.jp/
    10901 番 めざら さんへのコメント    コメント数 1

VZ.DEF の内部マクロの配置を入れ替えて,Pに書き換わる位置をずらし,
「Swap Text」のタイトルを持つマクロのタイトル文字列の p の位置に
mh+$1416 が来るように調整しました.結果→「SwaP Text」に.(笑)

あーあ,ほんとに一時しのぎだなぁ……
      - No.10902 -    このTreeへ    コメント元:10901 へ [リストへもどる] soft

(10877) 10904Re: 結局一時しのぎで  投稿者:konno   2023/08/06(日) 23:49
    10902 番 めざら さんへのコメント

> VZ.DEF の内部マクロの配置を入れ替えて,Pに書き換わる位置をずらし,
> 「Swap Text」のタイトルを持つマクロのタイトル文字列の p の位置に
> mh+$1416 が来るように調整しました.結果→「SwaP Text」に.(笑)

ぷっ・・・ 思わず笑ってしまいました。(゚゜)☆\(--#)バキッ
いや、冗談抜きで上手いですね。(^^;

> あーあ,ほんとに一時しのぎだなぁ……

私家版VZ が原因の可能性があるのでご迷惑をおかけします。m(__)m

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

(10877) 10903Re: k07v系におけるマクロバッファ書換え位置確定?  投稿者:konno   2023/08/06(日) 23:40
    10900 番 めざら さんへのコメント    コメント数 1

> ……ということであれば,相対的な書換え位置は確定ということで 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 うーむ・・・

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

(10877) 10905Re^2: k07v系におけるマクロバッファ書換え位置確定?  投稿者:めざら   2023/08/07(月) 07:39
参照先:http://mezala.la.coocan.jp/
    10903 番 konno さんへのコメント    コメント数 1

色々試していただき,ありがとうございます.

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

VZ の版が関係はするようだ(特定の版グループで発生)ということではあるけれど,
トリガーになっているのは,めざらの設定ということなのでしょうか.
それとも,いずれの環境でも発生しているけれど単に気付かないだけなのか……
謎は深まる……

手元の VZ.DEF は一通り眺めたのですが,自己書換えするようなコードないんですよ.
      - No.10905 -    このTreeへ    コメント元:10903 へ [リストへもどる] soft

(10877) 10906Re^3: k07v系におけるマクロバッファ書換え位置確定?  投稿者:konno   2023/08/08(火) 02:34
    10905 番 めざら さんへのコメント    コメント数 1

> その環境って,わたしがお送りした 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 ┃
┗━━━━━━━━━━━━━━━━━━━━┛

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


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

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

(10877) 10907Re^4: k07v系におけるマクロバッファ書換え位置確定?  投稿者:めざら   2023/08/08(火) 18:24
参照先:http://mezala.la.coocan.jp/
    10906 番 konno さんへのコメント    コメント数 1

あははは.そうなのですか……
わたしの手元では,そういうこと起こったことは一度たりともないですけどね.(笑)

> この定数 $fdfb って何なのでしょう?

BM を最大値で設定するために使用する定数です.
その数値には,そんなに厳密な意味はなくて,たぶん手作業で BM 設定値の
最大値は何になるのか実験して得た値だと思われます.(あくまで想像)

他のルーチンでは,x$fdfd+m+bm-pn..-26-2, ;限界Bmの計算(max 0-2) なんてのも.


> # どうなっているんじゃ〜〜

わたしもどうなっているのかわかりません.
他の人の環境では何が起こるかわかりませんね,楽しい!(笑)
      - No.10907 -    このTreeへ    コメント元:10906 へ [リストへもどる] soft

(10877) 10908Lf+ が原因か?  投稿者:konno   2023/08/09(水) 01:15
    10907 番 めざら さんへのコメント    コメント数 1

> BM を最大値で設定するために使用する定数です.
> その数値には,そんなに厳密な意味はなくて,たぶん手作業で BM 設定値の
> 最大値は何になるのか実験して得た値だと思われます.(あくまで想像)

これはオリジナルVZ で得た値なのですよね。他のVZではズレるとかないでしょうか。

> > # どうなっているんじゃ〜〜
> わたしもどうなっているのかわかりません.

どうも、Lf+ の場合に起こるようです。
2バイト文字の処理とかで誤動作しているのかなぁ?
私は Lf- で使っているので気が付かなかったようです。
というか、普通は Lf- で、必要な時に Lf+ にするのではと思っていました。
めざらさんの DEF では、ファイラーで "V" のトグルで LFN の切り替えしないので。(>_<)

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

(10877) 10909Re: Lf+ が原因か? (確認しました)  投稿者:めざら   2023/08/09(水) 08:20
参照先:http://mezala.la.coocan.jp/
    10908 番 konno さんへのコメント    コメント数 1

> これはオリジナルVZ で得た値なのですよね。他のVZではズレるとかないでしょうか。

それは制作者たる konno さんが一番よくご存知のことかと思いますが……
いずれにしても計算上最大値に応じて設定した BM が何らかの理由でエラーになれば,
「メモリが足りません」の場合は設定値を減らすだけのことですから.
m.gann師の vzx/vzz を使用して BM 最大値で常駐するとかなら影響は即出ますが,
計算上最大値 x はあくまでも「表示」ですから大した影響はないかと思います.

> どうも、Lf+ の場合に起こるようです。

試しに,Lf- で起動したところ症状が出ませんでしたが,起動後にファイラーを
ロングに切り替えて再度確認したら,書換え症状が発生しました.

> というか、普通は Lf- で、必要な時に Lf+ にするのではと思っていました。

わたしは高橋版での Lf 新設以降,一貫して Lf+ です.無効になっていた時期も
ありますが,konno さんが復活してくれる前から特にいじっていなかったかと.

> めざらさんの DEF では、ファイラーで "V" のトグルで LFN の切り替えしないので。(>_<)

そういえば,わたしはファイラー最上段のメニューを無視してましたね.(笑)

ロング表示の新設以降,ファイラーコマンドの #V は意味が変化しました.
旧横分割(超ショート表示)をロング表示が乗っ取ったからです.
それでもファイラー表示中に Lf を切り替えても再表示の必要があるため,
#V の繰り返しによる表示リフレッシュのために必要ではあったのですね.
それをワンキーで済ませるため,lf!, #V #V を仕込んで L で呼んでいます.
他の表示変更とも共有した再表示(#U)させるルーチンをさらに呼んでいます.

あ,脇道に逸れましたが,原因が判明したということは修正されるってことですね.
ばんざーい.\(^o^)/ (以前と Lf 関連ルーチンが異なるわけ?)

……いや,それにしても,Lf 原因ってよく分かりましたね.
常時+のわたしには永久に分からなかったな,絶対.
      - No.10909 -    このTreeへ    コメント元:10908 へ [リストへもどる] soft

(10877) 10910Re^2: Lf+ が原因か? (確認しました)  投稿者:konno   2023/08/10(木) 01:17
    10909 番 めざら さんへのコメント

> m.gann師の vzx/vzz を使用して BM 最大値で常駐するとかなら影響は即出ますが,
> 計算上最大値 x はあくまでも「表示」ですから大した影響はないかと思います.

めざらさんの DEF で vzx やってみたら、bm29991 になりました。
29991-bm-pn..-26, = 14656 = $3940
x=$3940 にすると、free 表示が 29991 になります。

> 試しに,Lf- で起動したところ症状が出ませんでしたが,起動後にファイラーを
> ロングに切り替えて再度確認したら,書換え症状が発生しました.

やはり Lf が原因なのでしょうかね。

> そういえば,わたしはファイラー最上段のメニューを無視してましたね.(笑)

そ、そんなぁ、め、めざらさ〜ん。(;_;)

> それをワンキーで済ませるため,lf!, #V #V を仕込んで L で呼んでいます.

おお、L でLFN切り替え出来ました。\(^^)/ ヤッタ-

> あ,脇道に逸れましたが,原因が判明したということは修正されるってことですね.
> ばんざーい.\(^o^)/ (以前と Lf 関連ルーチンが異なるわけ?)

い、いやぁ、修正できるかどうかは・・・ (^^;;

> ……いや,それにしても,Lf 原因ってよく分かりましたね.

オプションの違いかと思って、OPT_LST を見比べたら、LF+ に??? となったのです。(^^;

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

(10877) 10911原因はロングファイラー  投稿者:konno   2023/08/16(水) 21:18
    10877 番 めざら さんへのコメント    コメント数 2

タイトルで終わってもいいかな・・・ (゚゜)☆\(--#)バキッ

・・・というわけにもいかないので、解明のいきさつを書いてみます。(^^;

各種VZで調べると、k07s5 (2009-12-12)までは出ず、k07t (2010-01-04)以降現象が出ます。
k07t の目玉はロングファイラーなんですよね。

とりあえず、main open text inst など各種ASM を k07s5 のと入れ替えても現象は変わらず。
filer.asm を入れ替えたら現象が出なくなりました。やっぱりロングファイラーか?

ここで入れ替わる文字コードに注目しました。
めざらさんの DEF では、"P" コードは $50 = 80 WD=80
私の DEF では、    "・" コードは $88 =136 WD=136

そうです、この数字は、WD の値なのでした。
ロングファイラーのルーチンでは、WD の値をローカルワークに入れてやり取りしていました。
そのローカルワークの値をコードセグメントのつもりでスタックセグメントに書き込んでいたようです。
だから LF+ で現象が出ていたわけです。
大ポカをやらかしていました。(>_<)

めざらさん、みなさま、バグバグなVZに気づかず公開していて申し訳ございませんでした。m(__)m
めざらさんのおかげでバグに気が付きました。ありがとうございました。m(__)m

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

(10877) 10913Re: 原因はロングファイラー  投稿者:文太   2023/08/17(木) 00:18
    10911 番 konno さんへのコメント    コメント数 1

す、すごい!

konnoさん

>とりあえず、main open text inst など各種ASM を k07s5 のと入れ替えても
>現象は変わらず。filer.asm を入れ替えたら現象が出なくなりました。
>やっぱりロングファイラーか?

 やったこと(泥縄、「まだやれることはある!」作戦)、大筋は理解できました。

>ここで入れ替わる文字コードに注目しました。
>めざらさんの DEF では、"P" コードは $50 = 80 WD=80
>私の DEF では、    "・" コードは $88 =136 WD=136
>そうです、この数字は、WD の値なのでした。

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

>そのローカルワークの値をコードセグメントのつもりでスタックセグメントに
>書き込んでいたようです。

 セグメントの話は分かりませんが、仕留めたんだ。
 おめでとうございます。
 すごいです、本当にすごいです。

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


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

(10877) 10914Re^2: 原因はロングファイラー  投稿者:konno   2023/08/17(木) 01:15
    10913 番 文太 さんへのコメント

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

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

>  詳細は分かりませんが、ファイラでも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さん、、、、好きです!

わ、私には妻が・・・(゚゜)☆\(--#)バキッ
もちろんこれは冗談ですが、私も皆さんが好きです。
よかったら試してみてね。♪

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

(10877) 10915Re: 原因はロングファイラー  投稿者:めざら   2023/08/17(木) 18:51
参照先:http://mezala.la.coocan.jp/
    10911 番 konno さんへのコメント    コメント数 1

> そうです、この数字は、WD の値なのでした。

なるほど.設定が同じはずなのに VTDOS と DOSVAXJ3 で異なる値になったのは
WD の違いだったわけですね.いや,よくわかったねー!
      - No.10915 -    このTreeへ    コメント元:10911 へ [リストへもどる] soft

(10877) 10917Re^2: 原因はロングファイラー  投稿者:konno   2023/08/18(金) 01:23
    10915 番 めざら さんへのコメント

> なるほど.設定が同じはずなのに VTDOS と DOSVAXJ3 で異なる値になったのは
> WD の違いだったわけですね.いや,よくわかったねー!

なるほど、そこが違ったのですね、原因がわかってみれば納得です。
わかったのは、めざらさんが DEF環境を提供してくれて再現が出来たからですね。
"P" の文字コードとかヒントは最初からあったのですよね。

私は基礎も勉強せずに我流で今までやってきていたので、今回のようなことになったのでしょう。
最近になって基礎から勉強し直しているので少しはわかるようになったのかもしれません。(^^;
今までバグバグなVZでご迷惑をかけていて申し訳ありません。m(__)m

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