はい、そうなんです、filter.def。でもね、、、。

http://mezala.la.coocan.jp/vz/notes/vars.html

xc	v1.6		ブロック範囲比較変数
値	カーソル位置(cp)と選択開始位置(tblkp)との比較
-1	cp < tblkp
0	cp == tblkp
1	cp > tblkp

※比較はオフセット値で行われるため，常に正しいというわけではない。
64KBの敷居をまたぐ可能性がある時に正確な比較をするためには，
カーソル位置のロングポインタ（マークで使用）を用いる必要がある。
-------------------------------------------------------------------

　少なくともこれに引っかかったとは思えないんですよねぇ。
　そんなに運は悪くないだろうと。処理対象（範囲）が大きくない、が
より客観的で合理的な根拠ですが。
　64KB。またしてもテキストバッファの限界値。
　セグメントの境界だものね。？？？

　.com ファイルの制限、これも。

vzo.com  57,694  1993-12-06  02:00	;cmos
vz.com   62,184  2018-10-17  19:11	;konno 一杯ま近ですよ。

良い知らせと悪い知らせがあります。

10＃さんとのやりとりで私が上手く伝えられなくてどうなることかと思いましたが
再現が出来たと朗報がありました。
それとともに、新たなVZのバグが発覚したようです。

メールの返信の内容を貼り付けます。
-----------------------------------------------------------

>試験をやり直した結果再現しました。

おお、再現出来ましたか、よかったです。

>余談になりますが、僕の試験で把握出来た事をお伝えします。
>まずこの現象はEk+では再現されないようですが、この場合は前回僕がお伝えした結果になります。
>それから、試験をパスした(一致した)状態で窓替え(F2)を行ってすぐ比較を行うと相違が出ます。
>これはMS-DOS上のオリジナル版でも出ます。

試験をパスした(一致した)状態で窓替え(F2)を行ってすぐ比較を行うと相違が出るのですか。
この現象は知りませんでした。やはり検証不足だったようです。

MS-DOS Player や DOSVAXJ3 でも同じ現象になりました。
[F02]の後の比較マクロで6か所文字化けが出ますが、これは VZ のバグだと思われます。

思い当たるルーチンが有るので修正したVZで試してみました。
MS-DOS Player や DOSVAXJ3 では、文字化けが無くなり、正常になりました。
VTDOS では、やはり内容が変わっています。
10＃さんのおかげで、一歩前進出来たみたいです。ありがとうございます。

>この事を踏まえ調査を行うつもりです。

よろしくお願いいたします。
私ももっと検証を進めたいと思います。

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

ということで、調査をしていただけるのはうれしい知らせですが
比較で一致しても直後に[F02]窓替えで再比較すると文字化けが出るという新たなVZのバグが発覚しました。
これは、BL1024 か BL2048 の時だと思われるので、BLの影響で長い行の途中に改行が入るのではないかと想像しました。

過去記事の
#10322：Bl3072 の大穴が塞がったかも 　投稿者：konno 　 2022/10/11(火) 21:59 

> Bl3072 では 3700bytes を超えるところで改行が入っていました。
> ソースに改行を挿入するところがあるはずだと当たりをつけて
> 「,LF」で検索すると、それらしいところが TEXT.ASM にありました。
> 
> fread	proc
> 中略 410行目
> 	cmp	si,di
> 	jne	read3
> 	mov	byte ptr [si-1],LF
>   _break
> read3:	cmp	byte ptr [si-1],LF
> _until e
> 	clz
> 	ret
> read9:	stz
> read_x:	ret
> 
> 
> ここの
> 	mov	byte ptr [si-1],LF
> があやしいと思い、色々試したところ 
> 
> 	cmp	si,di
> 	jne	read3
> 	stc					;★##k 221011 キャリーをセット
> 	jmps	read9x				;★ ゼロフラグをクリアしてリターン
> ;	mov	byte ptr [si-1],LF		;★ Bl3072 の時 3700bytesで強制改行（実行しない）
>   _break
> read3:	cmp	byte ptr [si-1],LF
> _until e
> read9x:	clz					;★ ゼロフラグをクリアしてリターン
> 	ret
> read9:	stz
> read_x:	ret
> 
> 
> このように変更したら、Bl3072 で改行文字化けが無くなりました。

これを思い出し

	cmp	si,di
	jne	read3
	jmps	read9x				;★ ゼロフラグをクリアしてリターンへ
	mov	byte ptr [si-1],LF
  _break
read3:	cmp	byte ptr [si-1],LF
_until e
;	clz
read9x:	clz					; or	sp,sp = zf0 cf0
	ret

このようにシンプルに修正したVZでは、文字化けも無く正常処理出来ました。
今までは余計なところまで弄ってエンバグしていたようです。
正常動作するVZは、だいぶ前に戻ってしまいました。
今まで積み上げてきたものが全部崩れてしまった感じです。(^^;


＃　まるで賽の河原で石積みをしているような・・・　だって私、VZの亡者ですから。

あらら，実際のファイルで調べもしないで適当なこと言っちゃいました。
すみません．

わたしのファイルだと，急拵えしたこんなマクロで 1600バイトほどと表示されました。
1 ^\ "" ?.
	a-,
	#^ #<
 :l	; ---- main loop ----
	cp[,
	#> r=cp-0],
	(r>a)?a=r,
	#d (r)??>l
	&m("%u",a)
 :z	; ---- exit ----
	&d #] .

うちのラインバッファも 8192 取ってるので，断然余裕ですが。

　awkだとどう書くんだっけ？　と。ちゃんと忘れてました。

--- maxlen.awk ---
{ if (maxlen < length) 		# length()が推奨されているらしい
	maxlen=length 
	}
END { print maxlen }
------------------

C:\>jgawk -f maxlen.awk c:\0etxt\asm\tbook\mast_td.txt
141
　問題まったくないですね。すっかり安全志向。

　ただ、どっかでkonnoさんが、bl の値により、挙動（結果）が違う、
と書かれていたので、それの再検証からいくかな等々、いちおう真剣に
考えてはいます。BL=8192 bytes これには、実用上、問題は何もない
と思っていますが。

　タネをしこんで厨房に立ち、カレーを作り始める（時間がかかる。時間を
かけると美味しい）。そしたら、とらじさんのように、なるへそ、
そう攻めてみるか、とか思いつくのかなぁなんて思ったけど、別に何も
思いつきませんでした。カレー作りに夢中になっただけだった。
　（「どこどこ」開発中の会話より。doko2.defを相当ひさしぶりに動かした。
　　　いえいえ、キーの格納のされ方もすごいです）

　あ、こういうのゴミ発言って言うんでしたよね。

追伸でなく本題：clppst.defの件、発現条件は分かりました。10#さんからの
回答の意味も少しわかりました。多謝＞めざらさん。

xc のバグといえば、あむのさんの対策を思い出します。
CODEX.DEF で検索しましたが、BL2048 だと CODEX.DEFが起動しない！ まいった。(>_<)
BL4096 なら起動できたので、以下に引用します。(^^;

-----------------------------------------------------------
> 06847/06847 xxxxxxxx  あむの           xc にはご注意！
> (15)   97/07/10 07:56  06827へのコメント

　変数 xc にはよく知られたバグがあります。
 
    (1)  32,767 byte の前後にかかる後ブロック（注）で xc の値が 0 となる
        
        ファイル   32767      65536     65K+32767       (byte)
        +------------+----------+--- .... ---+---------- ......
                  ･========*               ･====*
                    blk                     blk
                                        （*印がカーソル位置）
 
        本来ならば xc == 1 。
        
    (2) 文字境界ブロック (mb==2) 限定のバグ
        ・ファイル先頭行にブロックがかかること。
        ・前ブロック（注）であること。
        ・カーソルカラム数がブロック終端のカラム数(wa..51)より小さい。
 
        この場合、xc の値が 0 となる。（本来はxc == -1)
        
        （例）　ファイル先頭
        +-------------------------------+
        |   *===========================|
        |======･    blk                 |
        |                               |
                    （*印がカーソル位置）
        
    （注）  前ブロック      カーソルがブロックの前の場合(xc:-1)
            後ブロック      カーソルがブロックの後の場合(xc:1)
 
　ですから、上記バグの条件にあたらないことが明確ならば、xc は有用です
が、それ以外の場合には使わない方が良いかと思います。
 
            *               *               *
 
　xcの代替手段としては、マーク機能(&#M(n))をブロック前後で使って、その
マークの値を比較するというのが一般的ですが、これまたちょっと問題を孕ん
でいます^^;。
　というのは、純正Ｖｚには、ロング整数を比較する&Lcという関数にも著名
なバグがあって、使えないのです（榊原さん版Ｖｚは修正されています）。
 
　というわけで、自力ですると、例えばこんな↓ふうになります。
　FGALPK Mes13 #02168 94/12/17 y.mikome さん ご紹介の方法に若干手抜き
したものです。
 
=Test
カーソルをブロックの前にする。
マーク＃０  wa+126 (wa..63,wa..64)
マーク＃１  wa+130 (wa..65,wa..66)
* M
89 ^\ ""
    ?.(mb)??.
    #M #B &#M(1) #B p$8000,     ;ブロック前後でマークする（位置は元に）
    (wa..64 > wa..66 || (wa..64 == wa..66 && p+wa..63 > p+wa..65) )?#B
*

ここまで　-----------------------------------------------------------
 
私は xc を使ったこともなく、よくわかっていなかったのですが
今このマクロを見ると、なんとなく読める気がします。（気の精）

＃　読める！　私にも読めるぞぉ！　ララァ

06858番の発言では
-----------------------------------------------------------

　あ、いえ、ブロックのサイズの問題ではないのです。ファイルサイズとブロ
ックの位置の問題なんです。
　百聞は一見に如かず、ということでこの↓マクロを実行して xc の値を確か
めて下さい。
 
=Test
巨大なファイル（例えばログファイル）上で実行して下さい。
* M
80 ^\ ""
    ?.mb0,&d
    &Im(wa+126,0) wa..63=$7FFF,
    #U #< #b #> #d
    &m("xc:%d",xc)
*
 
　また、幸い？なことにバグは xc==0 のときだけのようですから、その時は
実行させず、警告メッセージを出すだけにしても良いかもしれませんね（特に
今回のマクロの場合は、バグでない xc==0 の時も実行させる必要もなさそう
ですから）。

ここまで　-----------------------------------------------------------

これを踏まえて、気が向いたら調べてみたいですね。（無責任モード）

みなさまにお願いがあります．掲題のとおりの検証です．
各人の環境で以下の2点の現象が生じるかどうか教えてください．
（手元での発生条件がよくわからないのです）

(1) to Filer
60 \[CR] "" ?. #O #m	;to filer	;H_ear
コマンドライン専用コマンド #98 と操作を合わせるために v1.5 時代から使用．
このマクロを現環境で実行すると，#O #25 の動作になる．
ところが，GPD MicroPC の VTDOS 環境では所期のファイラが起動．訳がわからない．

どの版から発生しているかというと，下記のとおり．
2009/12/12　k07s5 ok
2010/01/04　k07t ok
---------------------------< ここが境界と思われるが上記のとおり確証得られず
2010/03/01　k07t01 NG　（GPD MicroPC では ok !?）
2022/11/13　k07t02 NG


(2) mp0で次検索（少し長いです．ごめんなさい）
;= ^QF.def = H_ear mp0常用者のいきなり検索・次検索
55 ^QF "" ?. k20&ks, mp[, (ks&1)?{ &j(10) }
	#F &Cr &j(-1)
	(r)?{ mp], . }
	&s (k)?#r ?#c >01
35 ^R "" ?. (ks&1)??{ #r . } c-, >00
36 ^C "" ?. (ks&1)??{ #c . } c+, >00
0:	&s mp[=2, &o(#r+c) >>
1:	(r)?{ &o(#c-(cm-35)) &b(2) } mp], &d
	(r)?{ &m(19) }
	   ?{ &m("%c",cm+'÷' ) }	; ▲▽ (59:^_)('∞':↑↓)
;------ end of ^QF.def ------

マクロ 55 は正常動作だが，35，36が動作しない．
これは VTDOS 環境で発生しており，高橋版でも同じ．

VTDOS 環境では，@A 等の [Alt]+[英字] キーでコマンド／マクロを実行すると
Windows が警告音を鳴らしてくる．この現象と同根か？

お時間よろしきときに，お試しください．＞みなさま

=== Macrotmp by B ===; vtdos & k07t01
* M

36 ^E "" ?. (ks&1)?{ &m("shift") } ?{ &m("non-shift") } .

*

　面白いマクロだった！　使い方に習熟するのに時間がかかるだろうけど。
　あまりにあまりな基本動作なので。もらっちゃおう！
　ただ、上が効きませんでした。
　わお、^D なら効く！
　これ、重大問題だ。今晩、純ＤＯＳとWinMEでやります。
　^C だけなの？

^A	OK
^B	OK
^C		NG
^D	OK
^E		NG	shift で秀丸起動！
^F	OK
^G	OK
^H	OK
^I			2 stroke key registered　問題ないと思う。
^J	OK
^K			2 stroke key registered　ふだん使ってるから。
^L	OK
^M	OK
^N			2 stroke key registered
^O			2 stroke key registered
^P	OK
^Q			2 stroke key registered
^R	OK
^S	OK
^T	OK
^U	OK
^V	OK
^W	OK
^X	OK
^Y	OK
^Z	OK

　^Cと^E がおかしい、という結果でした。Ｖｚの版の問題なのですか？
　シフト付き＾Ｃと＾Ｅを、僕はふだん使ってなかったから気づきませんでした。
　さらなる調査希望。

追記：＾Ｅですが、秀丸が何を開けたかというと、コンソールファイルと思しい。

-------------------------------------------------------------------------
VTDOS Version 1.53 Copyright (C) 2009-2017 by 10#  Build[Sep  5 2017]
　以下略
-------------------------------------------------------------------------
　こんなの。
　VTDOS 版が古いです。怠惰です。
　vtdos.exe & vz.com の両方に関わってしまってる？

　おお、ファイル名は、0f5a1dbc.txt.（秀丸を閉じようとした）
　c:\Users\xxx\AppData\Local\Temp\0f5a1dbc.txt だそうです。windows の tmp
ディレクトリですね。

=== Macrotmp by B ===; on VTDOS & k07t01
;(1)
* M

60 \[CR] "" ?. #O #m	;to filer		;H_ear, OK

;(2)

55 ^QF "" ?. k20&ks, mp[, (ks&1)?{ &j(10) }	;OK, shift IME ON OK
	#F &Cr &j(-1)
	(r)?{ mp], . }
	&s (k)?#r ?#c >01

35 ^R "" ?. (ks&1)??{ #r . } c-, >00
36 ^C "" ?. (ks&1)??{ #c . } c+, >00
0:	mp[=2, &o(#r+c) >>			;shift, str srch
1:	(r)?{ &o(#c-(cm-35)) &b(2) } mp], &d
	(r)?{ &m(19) }				;「文字列が見つかりません」
	   ?{ &m("%c",cm+'÷' ) }	; ▲▽ (59:^_)('∞':↑↓)

*


　ずいぶんと先走り、端折った書き方をしたので。少しちゃんと。

　上のマクロ 60 番に、僕の環境では問題ありませんでした。ふだん \[CR] は
デフォの #n で、これにも、上の60 番マクロにも、同機能をふだん実現する
マニュアル操作の「#O #m」も問題なし。

　55 番マクロ、問題なし。
　35 番マクロ、シフトもノンシフトも問題なし。
　36 番マクロ、シフトに問題あり。よって前発言の調査となりました。

　すべてのテストを正常にパスしました。vz.comもまったく同一のものです。
　VTDOS環境、というかもしかしたら、Win7 (OS) のなせる技でしょうか。
　もしかしたら、一部、その英語キーボード付きマシンの特殊性？

　なお、先ほど、^\E を再びやったら、今回は、164c11bc.txtをオープンした。
これってもしかして、Ｖｚが作るテンポラリーファイルでしょうか？　Windows
以降で、ファイル名をユニークにした奴？
　中身は、前回と同じく、vtdos 起動時のコンソールファイルの中身。でも
Ｖｚ起動前ですから（vtdos, vz起動バッチの順）、そんなものがＶｚの
テンポラリーファイルの「中」に書き込まれるというのは、相当に変ですね。

　なお、うちでは、.txtが「秀丸」に関連付けされているから秀丸でした。
　164c11bc.txtみたいなのをオープンせよ、という命令がＯＳに送られている
のだと思います。

　純ＤＯＳのテストは要らない、という判断です。
　konnoさんが手元で検証（確認）できたら、10# さんに報告してくれると助かり
ます。

　alt のテストは以下。ごめんなさい（謝ることはない）問題なしです。


=== Macrotmp by B ===; vtdos & k07t01
*M

36 @A "" ?. (ks&1)?{ &m("shift") } ?{ &m("non-shift") } .

<cut>

36 @Y "" ?. (ks&1)?{ &m("shift") } ?{ &m("non-shift") } .
36 @Z "" ?. (ks&1)?{ &m("shift") } ?{ &m("non-shift") } .;これだけwindowsに登録
							;されてるアプリに取られるけど
*							;正常です。ホットキー。
							;警告音、鳴りません。

　Windows 7 Professional Service Pack 1 (32 bit) がＯＳです。							

> (1) to Filer
> 60 \[CR] "" ?. #O #m	;to filer	;H_ear

これは単独のマクロにして試しましたが、私の環境では、全てファイラーが開きました。
VZの種類もEMSも関係ないように思われました。DEF のオプションとか環境変数とか？
わかりません。

> (2) mp0で次検索（少し長いです．ごめんなさい）
> ;= ^QF.def = H_ear mp0常用者のいきなり検索・次検索

これは VTDOSではシフト実行が上手くいかないようですね。MS-DOS Player などでは問題なし。

ふと思いついて

> 35 ^R "" ?. (ks&1)??{ #r . } c-, >00
> 36 ^C "" ?. (ks&1)??{ #c . } c+, >00
　　　　　　↓
35 ^R "" ?. k=ks&1, (k)??{ #r . } c-, >00
36 ^C "" ?. k=ks&1, (k)??{ #c . } c+, >00

このように、変数に入れたら、VTDOSでも上手く動きました。
思うに、最近のCPUは速すぎて、シフトチェックのタイミングが微妙なのかと。
この辺の調整は可能なのかもしれませんが、要望したほうが宜しいですかねぇ。
シフトチェックは変数を介したほうが確実とどこかで見たような気が。

> VTDOS 環境では，@A 等の [Alt]+[英字] キーでコマンド／マクロを実行すると
> Windows が警告音を鳴らしてくる．この現象と同根か？

[Alt]+[英字] キーはWindowsで予約されている場合がありますからねぇ。
DOSを優先にするオプションとかあったかなぁ。

> これ VTDOS の隠しコマンドか何かでしょうかね。

VTDOS.TXTより引用

■ホットキー

通常モード時に次のキーに機能が割り当てられています。
キーアサインはvtdos.cfgで変更できます。

Ctrl+Alt+PageUp	バックログモードへ移行
Ctrl+Alt+.	カレントディレクトリーでWindowsシェルを起動
Shift+Ctrl+C	バックログをクリップボードへコピー
Shift+Ctrl+E	バックログの内容でエディターを起動
Shift+Ctrl+F	カレントディレクトリーでファイラーを起動

これですね。

ksmiru.def 実行してみたら，うちのシフトキーは左右とも 3 だった。。。

何故だろう。謎だ。

= ksmiru.def =
* m
89 ^\ "ksを見る";システム変数 ks の変化を見る
	?.
:A	a=ks,
	(i8){pu.i--='1'-(a&1<<(7-i))!, }	;ビット表示
	&m("ks= %3d $%02x %8s",a,a,pu)
:B	(a-ks)?>A				;ks が変化したか？
	&k (r-$1B)?>B				;ESCが押されてない？
	&m("終了")
*

shadow さん，ありがとうございます！

> Shift+Ctrl+C	バックログをクリップボードへコピー
> Shift+Ctrl+E	バックログの内容でエディターを起動

これですね。全然隠しじゃなかった。
おかげでスッキリしました。　m(_'_)m

shadowさん、めざらさん、

>これですね。
　ですね！　ちゃんと.doc 読め。
　サーンクス！　ありが１０匹！
　vtdos.txt、読みまーす！

NO_BACKLOG=1
　これで、^\C & ^\E 復活。

Ctrl+Alt+.	カレントディレクトリーでWindowsシェルを起動
　これはいけるかも。"explorer here" なんですけどね。「カレント」を
編集画面で一生懸命見るのだろうか？　そんなマクロを書いたことがある記憶。
どうせファイラへ行くんだろうなぁ。

> ksmiru.def は榊原さんのナイスな小物マクロです。 

そうだったのですか、2進数の表示は凄いと思いました。読めないし。(^^;

> konno さんの環境は常に Numlock が立ってるのですね。
> もしかして，本体連動しないテンキーとか接続していたりします？
> （それか，デスクトップのフルキーボードって Numlock 立ってるのでしたっけ？）

富士通の10キー付ノートＰＣです。Numlock が無いと使えないのです。
そうか、$20  32 は、Numlock が立っていたのですね。全然気が付きませんでした。
このマクロでの数値は

STKHLP IBM版表示　VTDOS MSDOSPlayer DOSVAXJ3
  +1 :R[Shift] 　　3　　　1　　　　　1
  +3 :L[Shift] 　　3　　　3　　　　　3
  +4 : [Ctrl]  　　4　　　4　　　　　4
  +8 : [Alt]   　　8　　　8　　　　　8
  +16: [ScLk]  　　　　　　　　　　 16
  +32: [NmLk]  　 32　　　　　　　　32
  +64: [Caps]  　　　　　　　　　　 64
 +128: [Ins]　　　　　　　　　　　 128

DOSVAXJ3 の [Caps] は、1度押しでIME起動、2度目以降は [Caps]ON 表示のままになります。
他のエミュでは、IME に取られるのか、表示が出ないですね。

この KS の値は、AH02 INT16h BIOSコールの値とほぼ同じですが、シフトだけ違います。
	ax$0200,&i($16) k=ax,&m("key= %04x  %d",k,k%256)	;AH02h  shift check

STKHLP IBM版表示　VTDOS MSDOSPlayer DOSVAXJ3
  +1 :R[Shift] 　　3　　　1　　　　　1
  +3 :L[Shift] 　　3　　　2　　　　　2

これは、.vz1.5 の時の値ですね、1.6 ではvzが値を変更しているのかな。
AH12 INT16h BIOSコールは、AH02 の値とほぼ同じですが、違いもあります。

81 ^^  "keyshift?"
	?.
:a
;	ax$0200,&i($16) k=ax,&m("key= %04x  %d",k,k%256)	;AH02h  shift check
	ax$1200,&i($16) k=ax,&m("key= %04x  %d",k,k%256)	;AH12h  (enh) shift check
	&w(10)
	&k (r-$1B)?>a				;ESCが押されてない？
	&m("") &d .

*

AH12h (enh) shift check では、VTDOSで
  +16: [ScLk]  
key= 1000   0
このように、ah に 10h が入りますね。微妙な違いです。(^^;


> > この辺、ダメもとで 10＃さんにメールしてみようかな。
> 
> ホットキーの事例もあることだし，まずは皆さまのコメントを待ちましょうか。(笑)

メールしちゃいました。(^^;
やっぱり WinAPIの仕様らしいです。

>Win32Consoleの仕様を理解して貰えれば話は早いのですが、
>VTDOSはDOSコマンドとWin32コンソールコマンドをシームレスに扱う為に、
>Win32ConsoleをUIとすることが第一要件になってます。
>DOSキー入力の元はCONIN$からのキーイベントで、シフト状態もこれから生成しています。
>これはキューイングされたイベントなのでリアルタイムなシフト状態という訳ではありませんが、
>概ねリアルタイムな物となります。
>このキーイベントの仕様としてシフトだけが何故か左右の区別がありません。
>この仕様に則った場合、コンソールでの貼り付けが利用可能になります。
>貼り付けをサポートするのもこの仕様を採用する理由ですが、貼り付けの仕様上、
>シフト状態がリアルタイムな物である事を保証するものではありません。

仕様ということで、あとは直に変数に代入することで問題なく使えると思います。

shadowさん

　あはははは。「確定申告」は必要だから困るんだよ、というのは分かる。
　でも、なんでまた、そのような冒険を？
　ほんとに必要なのですか？

　とにかく、DOS 6.2V のドコモバのＶｚファイラではファイルが作れません
でした。ここのcommand.com は、「Invalid keyword」と言っていました。

　ネットでは、「それは代入の意味になっちゃうから、クゥートに入れない
とダメなの」みたいな書き込みがありました。Win LFN 環境。
　なんだろう、パソコンに意味のある記号を裸でコマンドラインには書けない
みたいなニュアンスでした。

　vtdos環境だとＶｚファイラでファイルは作れるが、仰るとおり、a_b~1.txt
になりますね。ＬＦＮ扱いなのでしょう。そしてその際、= -> _ 変換が
（見た目上？）入るのでしょうかね？
　a=b.txtを作ろうとしたときの話です。

　なお、秀丸からa=b.txtでファイル保存をしようとしたら、ちゃんと上書きを
尋ねてきました。a_b~1.txtが内部的に（？）a=b.txtと認識されているみたい
でした。

　もう迷宮入りみたいなものですが。以下、Win7 環境。

>dir a=b.txt (command.com)
  File Not Found

>dir a_b~1.txt (command.com)
2023/03/29  22:58                 5 a=b.txt

>dir a=b.txt (cmd.exe)
2023/03/29  22:58                 5 a=b.txt

>dir a_b~1.txt (cmd.exe)
2023/03/29  22:58                 5 a=b.txt

　とのことでした。（5 は 5 bytes）

　もちろん僕は詳しい仕組み（理屈）をまったく知りません。

　昨晩のテストがどうも奇妙な気がしてきたので、やり直しました。


--- （１）vtdos, usecmd=1, cmd.exe used
C:\>dir a_b~1.txt	;OK
2023/03/29  22:58                 5 a=b.txt

C:\>dir a=b.txt		;NG
ファイルが見つかりません	;でも、なんで日本語？ command.com + biling.sys
				;で、日本語メッセージなのじゃなかったか？

C:\>dir "a=b.txt"	;OK
2023/03/29  22:58                 5 a=b.txt



--- （２）vtdos, usecmd=0, cmd.exe NOT used, command.com v.6.2 used
C:\>dir a_b~1.txt	;OK
A_B~1    TXT             5 23-03-29   22:58

C:\>dir a=b.txt		;NG
無効なキーワードです. -  a=b.txt

C:\>dir "a=b.txt"	;NG
パラメータの書式が違います. -  "a=b.txt"



--- （３）「コマンドプロンプト」窓 = cmd.exe
C:\>dir a_b~1.txt	;OK
2023/03/29  22:58                 5 a=b.txt

C:\>dir a=b.txt		;NG
File Not Found

C:\>dir "a=b.txt"	;OK
2023/03/29  22:58                 5 a=b.txt



　cmd.exeが変に見えるのは、クゥオートがないせいです。

　少しだけ追記。さっき、めざらさんあてに「cmd.exe、変ですか？」という主旨の
発言をアップし、そして削除しました。
　そこに書いたもう１つの点は、ＣＵＩのコマンドラインには、（たとえば引数の
区切りに半角スペースを使うなど）、そもそも制限条件があり、その影響で、
ファイル名とその扱い（クゥオートなど）にＧＵＩにはない条件がでるのでは？
ということでした。

　全体に、上で納得しました。

追記：Ｖｚファイラでも、lf+ にすれば、ちゃんと、「a=b.txt」と
　　　表示されました。

追記２：しつこいですねぇ。usecmd=1 環境です。vtdos窓です。

C:\>dir |more
だだだ、、、 cut
2023/03/29  22:58                 5 a=b.txt
だだだ、、、 cut

　コマンドラインで【その】ファイル名を指定したりしなければ、
ふつうに出ますね。これって驚くべきことなんだっけ？　いえ、全体に
整合してると思います。

皆さん盛り上がっていますね。
私もまとめ的に、エミュ三種の盛り合わせを。(^^;
各種DOSエミュで、DIR してみました。

VTDOS　USECMD=1　VZk常駐／非常駐　MSDOS6.2  
 D:\01 のディレクトリ
2023/03/30  15:26                 0 MS=.txt
2023/03/30  15:26                 0 MSs=.txt
2023/03/30  15:36                 0 VT=.txt

VTDOS　USECMD=0　VZk常駐／非常駐　MSDOS6.2  
 Directory of D:\01
MS_~1    TXT             0 23-03-30   15:26
MSS_~1   TXT             0 23-03-30   15:26
VT_~1    TXT             0 23-03-30   15:36

※ USECMD=0 だと、ショート名になるんですね、メッセージも英語に。(^^;


MS-DOS Player　FreeCOM
 D:\01 のディレクトリ
MS_~1    TXT             0  23/03/30 15:26
MSS_~1   TXT             0  23/03/30 15:26
VT_~1    TXT             0  23/03/30 15:36


DOSVAXJ3
ディレクトリは D:\01\
MS=      TXT                  0 2023-03-30 15:26 MS=.txt
MSS=     TXT                  0 2023-03-30 15:26 MSs=.txt
VT=      TXT                  0 2023-03-30 15:36 VT=.txt
楽天01~1 TXT                 68 2023-02-19 22:51 楽天0123456789 01.txt

おや？　何か変ですね。
ショート名なのに "=" 表示になっています。

LFNでは、SFNで使用可能な文字全てに+,;=[]が加わっています。とありますが、
ファイル名に "=" を使うと、他のエミュではロング名として作成されますが、
DOSVAXJ3 では新規作成できません。

これは、作者様に、別件でメールしました。


＃　アイドル推しが増えるかもしれないの。嬉しい！！

＃　「なんてったって アイドル」　　と言えば、誰？