長らくお待たせしましたが、vzk07v6 UPしました

k07v6 （2023-02-28）
　・k07t5 までの機能は全部取り込んであると思います。
　・Rf+ DOS窓のファイラーで#R 編集モードで[ESC]P [ESC]S ロングファイル名変更となる（大文字小文字区別する）
　　　　バッファの制限により、パスの長さ約80文字以上ではSFNとなる。
　・Sl　ステータスライン表示オプション変更　0:time　1:free　2:LFN View open　3:sl1+sl2
　　sl2 ならステータスラインでロング名表示　 (Win9x、WinXP、MS-DOS Playrは sl2は指定しないこと)
　　※ この機能は VTDOS と DOSVAXJ3(lfn_space=true) の場合に正常動作します。
　・WinNT系のDOS窓コマンドラインの安定化 (検証中)
　・[ESC]i ファイル挿入時のVZの不具合を修正してみた (検証中)
　　VTDOS でのラップアラウンドエラーを回避しています。
　　※BL1024*3 だとファイル内容が壊れます。（全てのVZで起こるバグなのでこの設定は危険）
　　　詳細は掲示板を読んでください。不具合を見つけたら掲示板に報告願います

　　 高橋版VZに対する自己解凍差分になっています。
　　バグ等あるかと思いますので、ご使用は自己責任で。

VZの部屋にあります。

ソースの差分も UPしました。
差分の取り方を忘れてしまって、後回しになってしまいました。(^^;

#10581 からの話題ですが

> これを見て閃きました。command.com をフックさせなければいいのではないかと。
> FreeCOM と DOSVAXJ3 の環境では、zp はゼロになります。フック出来ていないのです。
> それなのに問題なく動作しているので、WinNT系でも同じくフックさせなければどうなる？
> 
> で、やってみました。
> 正しい位置を検索するのは難しいですが、わざと失敗させるのなら簡単です。(^^;

実際のソースでは

	mov	bx,cs:tpafreep		; MAIN.ASM 318:GDATA tpafreep, dw, 0 ; ZP
	tst	bx
	jnz	alloc8
	mov	di,0600h
;	mov	di,0380h		;0600h ##k07vt2b
	mov	cx,400h			;300h 1.60 ; win95
	cmp	byte ptr cs:os_win,5	; ##k 230225  WinNT系DOS窓なら ZP を 0 に 
	je	winnt			;
	cmp	ah,5			; ##16
	jae	alloc1
;	mov	bx,0465h
;	cmp	ah,5			; ##156.96  ##157.xx  DOS 5.0
;	je	alloc8
	pop	es
	push	es
	mov	di,0200h
;	mov	cx,500h ;100h		;##k07f
winnt:	mov	cx,100h			;##k07v6c


コメントの多さが試行錯誤を物語っていますが、このルーチンの肝はここです。

	cmp	byte ptr cs:os_win,5	; ##k 230225  WinNT系DOS窓なら ZP を 0 に 

os_win とは、VZkで追加したオプション ow で、この数値が 5 なら WinNT系の DOS5 です。
VTDOS なら、AH に 1、AL に DOSのメジャーバージョン（DOS6.2なら 6 ）となります。

Win98ME		ow:8h	MSDOS 8.0
Win2000		ow:5h	DOS 5.0
WinXP		ow:5h	DOS 5.0
VTDOS		ow:106h	MSDOS 6.2
MS-DOS Player	ow:7h	FreeCOM 7.0
DOSVAXJ3	ow:0	DOS 7.0 相当?

どうやら DOSVAXJ3 は、アイドル推し（コール）してないようですね。(^^;
CPU負荷が他のエミュより若干高く見えるのは関係あるかしらん。

 ax1680h  INT2fh  で判定しているもので。(^^;

お疲れ様です。
ソースは高橋版への差分でしょうか？
確認していただければ幸いです。

> ソースは高橋版への差分でしょうか？

はい、ソースも高橋版への差分です。
ソースを別フォルダにコピーして、カレントにして、そこに 差分.com を置いて実行です。

久しぶりというか、色々忘れているので、問題あれば教えてください。

実行した結果を貼り付けますね。
正しい差分が作成できてないと思われます。

C>K07V6_S.COM
WSP self update 1.50 amaproワキチ

xscr.asm 完了!
block.inc 完了!
sprintf.inc 完了!
std.inc 完了!
vz.inc 完了!

1999/05/29  14:20             7,097 xscr.asm
1991/12/16  01:57             1,460 block.inc
2004/05/29  11:21             5,476 sprintf.inc
2023/02/11  04:18             8,962 std.inc
2023/02/28  22:33            19,582 vz.inc

UPされている圧縮ファイルのサイズが小さいですねぇ。

3,406 K07V6_S.LZH

> 実行した結果を貼り付けますね。
> 正しい差分が作成できてないと思われます。

ああ、すみません、全く確認していませんでした。m(__)m
とりあえずあがっているのは削除します。

K07v6 ソースの差分を再アップしました。
差分作成が上手くいかず、時間がかかってしまいました。(^^;

K07v6_s.lzh を解凍すると

K07v6s1.com    53,125 
k07v6s2.com    19,451 

この2つの自己差分ファイルになります。
新規フォルダを作成し、高橋版最終 T03K2 のソースを全てコピーし
そこにこの2つの自己差分ファイルを入れて、カレントにし、実行します。

更新を有難うございます。
高橋版（VZIBMJ.COM 1999-12-21 60,888bytes）への差分ですよね。

差分が当たらないなぁ……何か勘違いしてるのかも。

> 更新を有難うございます。
> 高橋版（VZIBMJ.COM 1999-12-21 60,888bytes）への差分ですよね。

はい、そうです。T03K2 です。

> 差分が当たらないなぁ……何か勘違いしてるのかも。

うちでは問題なく出来ました。VTDOS + VZK07v6 の環境です。
高橋版VZ と差分ファイルを同じフォルダに置いて、カレントにして、差分.com を実行です。
2023/02/28  22:34    62,768 vzibmj.com
が出来ます。

お疲れ様です。
ソース差分当てれました。
このソースから62,768 vzibmj.comもできました。
有難うございました。

カレントにしていませんでした(^o^;

62,768bytes 2023-02-28 22:34 の VZIBMJ.COM がめでたく出来ました。
お騒がせ致しました。m(_'_)m

> UPされている圧縮ファイルのサイズが小さいですねぇ。
> 3,406 K07V6_S.LZH

これには参りました。(>_<)
最初はVZKが悪いのかと疑いましたが、高橋版でも同じでした。
次に VTDOS とかエミュの環境を変えたり色々変えてみても駄目で。
wsp.com の実行結果が

VTDOS|C:\VZ\UP>WSP -A c:\vz\vz16\T03K2\view.asm c:\vz\K07v6\view.asm K07v6s
K07v6s.WUP に差分データを結合します.

0.....10.....20.....30.....40.....50.....60.....70.....80.....90....100(%)
=======================*******=*======**==============**===*===========  完了

VTDOS|C:\VZ\UP>WSP -A c:\vz\vz16\T03K2\block.inc c:\vz\K07v6\block.inc K07v6s

ファイルが存在しないか，ファイルの入出力にエラーが発生しました.

VTDOS|C:\VZ\UP>WSP -A c:\vz\vz16\T03K2\sprintf.inc c:\vz\K07v6\sprintf.inc K07v6s
K07v6s.WUP を作成します.


どうもここのエラーで新規作成に戻っているようです。
ファイル内容か実行ファイルが壊れているかもと疑いましたがシロでした。
さて、この後私の取った行動はどれでしょう。

　１．問題が解決するまで寝ないで頑張った。
> ２．色々頑張ったが解決できなくて、諦めて寝た。
　３．解決できなくて絶望し、窓を開けてノートPCを思い切りエイっと・・・


さて、翌日になって、wsp のドックを読んだら

> 作成する差分ファイルの大きさはいくら大きくても結構ですが、結合する差分データは60ＫＢ以内でなければなりません。

・・・もしかして、差分ファイルが60kを超えてエラーになっている？
だって、前回の k07t01 の差分ファイルは
 36,197  k07t01s.com
まだまだ余裕があったのに、今回の修正でそんなに変わったというのか。

それで、差分ファイルを2つに分けてやって、やっと出来ました。

2023/03/02  16:40    53,125 K07v6s1.COM
2023/03/02  16:41    19,451 k07v6s2.com

この２つを合計すると、73728bytes （クラスタ）。こんなにあるとは・・・・


＃　思えば遠くへ来たもんだ・・・・

試用レポートです。

SL　起動後にも変更可能なのですね。+1 +2 とも正常に動作しています。

RF　こちらも起動後に変更可能。#75，#82 とも正常な動作を確認しました。

気づいたことがあります。
Rf- のとき，長いファイル名のテキスト…例えば「wforum(000).css」…を開くと，ステータスラインには長いファイル名で表示されます。そして，#82 で…例えば「wforum(000).csss」…長いファイル名でリネームすると，「WFORUM(000).CSSS」のようにすべて大文字になります。こののち #75 で保存すると短いファイル名が長いファイル名側に影響せず，すべて大文字の長いファイル名で保存されます。（短いファイル名は WFORUM~1.CSS と相対的名称になります）

こういう現象は想定内でしたか？
（こうして欲しいとか，こうあらねばならぬ…ということでなく，単なる興味です）

あと，OT 新設の関係で SL は廃止されたと以前アナウンスされたと思いますが，復活 SL と OT の関係はどのように考えればよいでしょうか。マクロキーみたいな後優先とか便利な仕組みはないと思いますので，念のために伺いたいと思いました。

> Rf- のとき，長いファイル名のテキスト…例えば「wforum(000).css」…を開くと，ステータスラインには長いファイル名で表示されます。そして，#82 で…例えば「wforum(000).csss」…長いファイル名でリネームすると，「WFORUM(000).CSSS」のようにすべて大文字になります。こののち #75 で保存すると短いファイル名が長いファイル名側に影響せず，すべて大文字の長いファイル名で保存されます。（短いファイル名は WFORUM~1.CSS と相対的名称になります）

これは不味いですね、元々 Rf+ は、SFNでも大文字小文字を区別したいから作ったのです。
ロング名なら、Rf- でも大文字小文字を区別しないといけませんね。バグです。
これは直します。
バグ報告ありがとうございました。m(__)m


> あと，OT 新設の関係で SL は廃止されたと以前アナウンスされたと思いますが，復活 SL と OT の関係はどのように考えればよいでしょうか。マクロキーみたいな後優先とか便利な仕組みはないと思いますので，念のために伺いたいと思いました。

え、えーと、OT は無くなっていますね。(^^;
k07o-k07q と k08o-k08q まではありますが、それ以降は廃止したようです。(^^;
説明書きに残ったままでした。申し訳ない。m(__)m

SL も OT 廃止に伴って復活したということです。
元の高橋版ではフラグだったのを、変数に変えています。

説明書の VZK.TXT も、VZK.DOC に変えて更新しますのでしばしお待ちを。m(__)m

> 元々 Rf+ は、SFNでも大文字小文字を区別したいから作ったのです。

　「SFNの長さに納まるLFN」と解釈してよいでしょうか。

　konnoさんご自身としては「バグ」という認識なのですね。
　「仕様」としても影響はないと思ったのですが，そのような認識であれば，敢えて報告しておいてよかったです。（いつもろくにレポートできていないので）

> ロング名なら、Rf- でも大文字小文字を区別しないといけませんね。バグです。

　ここはちょっとわかりませんでした。
　デフォルトなら環境依存でよいのではないですか？
　VTDOS環境でLFNがなんとなく通ってしまうという仕様の延長線上ですよね。
　（環境が関係ないのなら別ですけど……）

> え、えーと、OT は無くなっていますね。(^^;

　あ，あら(^^;　意外な展開……

> 元の高橋版ではフラグだったのを、変数に変えています。

　Rf は konnno さんの独自拡張ですよね。高橋版の LF と混同しやすいけれど。

　自分なりの解釈で版の詳細を追記しました。↓　錯誤の有無をご確認ください。
　http://mezala.la.coocan.jp/vz/history/verdetail.html#k07v6

> 　「SFNの長さに納まるLFN」と解釈してよいでしょうか。

まあそんな感じのような・・・いやいや
●RF+ : SFNファイラー（ LF- ）でも LFN リネーム対応、SFNでも大文字小文字区別
これが仕様だったはず。(^^;

> 　konnoさんご自身としては「バグ」という認識なのですね。
> 　「仕様」としても影響はないと思ったのですが，そのような認識であれば，敢えて報告しておいてよかったです。（いつもろくにレポートできていないので）

いや、ロング名が大文字に勝手に変換されたら困りますよね。
SFNの時は大文字小文字を区別する感覚が無かったかもですが。
私が考えていた仕様としては

VZT.DOC
●LF+ : LFN 対応ファイラー
●ファイラーコマンド #N #R #D は lf+ 時のみ LFN になります

VZK.DOC
●RF+ : SFNファイラー（ LF- ）でも LFN リネーム対応、SFNでも大文字小文字区別

●SL  : ステータスライン表示オプション
　　　　0:time　1:free　2:ロングファイル名でオープン、表示　3:sl1+sl2
　　　　編集モードで [ESC]P [ESC]S がロング名（大文字小文字区別）になる。
　　　　※ Win9x、WinXP、MS-DOS Playrは sl2は対応していないので指定しない。
　　　　※ この機能は VTDOS と DOSVAXJ3(lfn_space=true) のみ対応。

元々は、RF フラグだけでステータスライン表示も兼ねていたのを無理やり分離したので
実際使ってみると、RF+ だけでもステータスラインがLFN表示になりますね。まあいいか。
MS-DOS Playr でも出来そうな気がして弄ってみたんですが、どうも無理っぽいです。
とりあえず MS-DOS Playr は諦めて修正版をアップしようかな。

> > ロング名なら、Rf- でも大文字小文字を区別しないといけませんね。バグです。
> 
> 　ここはちょっとわかりませんでした。
> 　デフォルトなら環境依存でよいのではないですか？

上に書いたように、ロング名は、"Windows98ME” のように大文字小文字を使い分ける
のが普通でメリットでもあるので、 ここは勝手に変えたら駄目ですよね。

> 　あ，あら(^^;　意外な展開……

いい加減で本当に申し訳ないです。

> 　自分なりの解釈で版の詳細を追記しました。↓　錯誤の有無をご確認ください。
> 　http://mezala.la.coocan.jp/vz/history/verdetail.html#k07v6

えーとですね

> Rf：長いファイル名への対応を拡張し，編集モードで #75(#S：ファイルのセーブ) #82(ファイル名の変更) コマンドに対応．

RF はファイラーだけで、編集モードでは使えないという仕様だと思っていたのですが、今はあやふやになっています。(^^;
とりあえず、あやふや版をアップするかな。(ﾟ゜)☆＼(--#)ﾊﾞｷｯ

> RF はファイラーだけで、編集モードでは使えないという仕様だと思っていたのですが、今はあやふやになっています。(^^;
> とりあえず、あやふや版をアップするかな。(ﾟ゜)☆＼(--#)ﾊﾞｷｯ

とりあえず、あやふや版をアップするかな、と思っていたんですが
編集モードでスペース入りの LFNリネームに対応したら、今度は Tra_TAG.def が動かない。(>_<)
試行錯誤しているうちにぐちゃぐちゃになってわけわかになってしまいました。(;_;)

変更履歴をきちんとやっていなかったので、基本に帰って（何度目？）履歴ごとの違いを一覧にしました。
それで気が付いたのは、編集モードでスペース入りLFNリネームと Tra_TAG.def は、相容れない動作だったと。
なんてこった。(T_T)

しかたがないので、OPEN.asm #82 のルーチンにフラグを入れてやっと両立出来ました。(^^;
あとは、SL の動作が合わないのを、text.asm を入れ替えたら直ったので、これで完成か。
中身は継ぎはぎでわけわかですが、やれやれです。(^^;

vzk07v6h UPしました。

k07v6 （2023-02-28〜03-14）
　・k07t5 までの機能は全部取り込んであると思います。
　・Rf+ DOS窓SFNファイラーでも #R でロングファイル名変更（大文字小文字区別）
　　　　バッファの制限により、パスの長さ約80文字以上ではSFNとなる。
　・Sl　ステータスライン表示オプション変更　0:time　1:free　2:LFN View open　3:sl1+sl2
　　sl2 ならステータスラインでロング名表示　(Win9x、WinXP、MS-DOS Playrは sl2は指定しない)
　・編集モード [ESC]P [ESC]S でロングファイル名変更（大文字小文字区別）
　　※ この機能は VTDOS と DOSVAXJ3(lfn_space=true) の場合に正常動作します。
　・WinNT系のDOS窓コマンドラインの安定化 (検証中)
　・[ESC]i ファイル挿入時のVZの不具合を修正してみた (検証中)
　　VTDOS でのラップアラウンドエラーを回避しています。
　　※BL1024*3 だとファイル内容が壊れます。（全てのVZで起こるバグなのでこの設定は危険）
　　　詳細は掲示板を読んでください。不具合を見つけたら掲示板に報告願います

　ダウンロード　 vzk07v6h.lzh ver1.60k07v6h （2023-03-14版 再アップ） new!
　　　　ソース　2023-03-14 再アップ　 K07V6Hs.lzh new!

お疲れ様です。早速試用したところ，下記のようになっています。
（まだ SL だけの確認だけですが…）

> ・Sl　ステータスライン表示オプション変更　0:time　1:free　2:LFN View open　3:sl1+sl2

現状では，常に 2 が立っているように見えます。
また，0と1が上記と逆転しています。（これは本来望ましい仕様かとは思いますが）
2 のときは free＋LFN で，3 のときは time＋LFN なので1が（矛盾なく）立っています。

製品版は free なので，0 free　+1 time　+2 LFN表示 というのがしっくりきますが。 
（高橋版は「作成者の趣味」で異論を受け付けず 0 time ですけどね）

ご苦労様です。

VZK07V6H.COM の差分を当てて出来たのは62,870 vzibmj.com でした。
ソースから出来たのは 62,854 vzibmj.com でした。
3月4日から3月14日版へのアップデートで変更されてるのは次のファイルでした。
2023/03/05  20:59             6,402 char.asm
2023/03/13  22:54            63,753 filer.asm
2023/03/11  23:50             8,932 filer2.asm
2023/03/13  22:20            36,737 open.asm

> あとは、SL の動作が合わないのを、text.asm を入れ替えたら直ったので、これで完成か。
text.asmは変更されていると思ってたけど日付は違うけど内容は同じでした。

何かが違うようです。

> 現状では，常に 2 が立っているように見えます。

え、そうですか？　私の環境では、SLが ０，１ では、ショート名でオープン表示されていると思うのですが。

> また，0と1が上記と逆転しています。（これは本来望ましい仕様かとは思いますが）
> 2 のときは free＋LFN で，3 のときは time＋LFN なので1が（矛盾なく）立っています。
> 製品版は free なので，0 free　+1 time　+2 LFN表示 というのがしっくりきますが。 
> （高橋版は「作成者の趣味」で異論を受け付けず 0 time ですけどね）

げげ、０と１を高橋版と入れ替えていたみたいです。すっかり忘れていました。(^^;
では、オプションの意味を

・Sl　ステータスライン表示オプション変更　0:free　1:time　2:LFN View open　3:sl1+sl2

こう変えてしまってもいいでしょうか。(^^;
でもオリジナルと高橋版と私家版で表示がコロコロ変わるのは混乱しそう。(^^;

> VZK07V6H.COM の差分を当てて出来たのは62,870 vzibmj.com でした。
> ソースから出来たのは 62,854 vzibmj.com でした。

ああ、またポカをやっていました。(>_<)
類似のフォルダがいくつもあるので古い方を使ってしまっていました。
申し訳ないです。m(__)m

2023/03/15  16:31            50,394 K07V6Hs.lzh
ソース　2023-03-15 再再アップ(^^;
しましたので差し替えてください。m(__)m


＃　やばい！ SL2 を設定していないと上書きセーブでも大文字になってしまうのか。(>_<)
　　うう、一度やったらもう止められなくなってしまう、、、中毒症状がぁ、、、

あれ？…と思って開き直して初めてオプションの意味を理解しました。
オプションの値を変更して #] を実行したから書き換わるというものではないと。
ごめんなさい。えらいカン違いしていました。(^o^ゞ

> ・Sl　ステータスライン表示オプション変更　0:free　1:time　2:LFN View open　3:sl1+sl2
> こう変えてしまってもいいでしょうか。(^^;

ご随意にお願いします。だって，SL は kVZ で追加されたオプションですから。
（こちらもカン違いしていましたが，高橋版は time 固定でしたね）
わたしとしては，感覚としてしっくりくるので大歓迎です。
konno さんが混乱しなければ良いのではないかと思います。

> あれ？…と思って開き直して初めてオプションの意味を理解しました。
> オプションの値を変更して #] を実行したから書き換わるというものではないと。

オープン時にロング名でオープンなので、そういうことです。

> > ・Sl　ステータスライン表示オプション変更　0:free　1:time　2:LFN View open　3:sl1+sl2
> > こう変えてしまってもいいでしょうか。(^^;
> 
> ご随意にお願いします。だって，SL は kVZ で追加されたオプションですから。
> （こちらもカン違いしていましたが，高橋版は time 固定でしたね）

げげげ、SLは自分が作ったオプションでしたか、私は2重に勘違いしていました！　m(__)m

> わたしとしては，感覚としてしっくりくるので大歓迎です。
> konno さんが混乱しなければ良いのではないかと思います。

ではこのままということでよろしくです。(^^;

> ソース　2023-03-15 再再アップ(^^;
> しましたので差し替えてください。m(__)m
有難うございます、頂きました。
 
> ＃　やばい！ SL2 を設定していないと上書きセーブでも大文字になってしまうのか。(>_<)
> 　　うう、一度やったらもう止められなくなってしまう、、、中毒症状がぁ、、、
私的には最初の版でもOKです。

> 私的には最初の版でもOKです。

最初の版は、ロング名で表示は出来ていますが、[ESC]P でファイル名を変更すると
全部大文字になってしまうので使い物になりません。
今の版でも誤動作するマクロがあるかもしれませんので、気が付いたらご報告願います。

VTDOS 環境ですが，300KB ほどの比較的大きなファイルをちょうど今編集していて，
clppst.exe＋clppst.def による [ESC]I 様態(*)の作業を行って気が付きましたが，
ラップアラウンドエラーが出る状況になっています。テンポラリファイルエラーも
出ました。現在の版の k07v6h と 前の版の k07v6d で発生を確認しました。

ファイルは 300KB 弱ですが，2,100行強，長い行もありますが，割に普通です。

k07t5 に差し替えると，上記のラップアラウンドエラーは発生しなくなりました。
現在の作業はこの版で乗り切ろうと思います。
k07t5 でもテンポラリファイルエラーが出やすいサイズなので，分割作業かしら。

(*)clppst.def は巨大ブロックコピー機能を使っています。

お手元でのテストが必要なら，当該ファイルのコピーをお渡しできます。

めざらさん

>出ました。現在の版の k07v6h と 前の版の k07v6d で発生を確認しました。
>ファイルは 300KB 弱ですが，2,100行強，長い行もありますが，割に普通です。
>k07t5 に差し替えると，上記のラップアラウンドエラーは発生しなくなりました。

　ありがとうございます！
　違う話だと思うけど、僕も、それに近いことに悩まされています。

> VTDOS 環境ですが，300KB ほどの比較的大きなファイルをちょうど今編集していて，
> clppst.exe＋clppst.def による [ESC]I 様態(*)の作業を行って気が付きましたが，
> ラップアラウンドエラーが出る状況になっています。テンポラリファイルエラーも
> 出ました。現在の版の k07v6h と 前の版の k07v6d で発生を確認しました。
> ファイルは 300KB 弱ですが，2,100行強，長い行もありますが，割に普通です。

出ましたか、これは再現して調べたいです。

> k07t5 に差し替えると，上記のラップアラウンドエラーは発生しなくなりました。

げげ、今の版は暫定版なので仕方がないですが、k07t5 って結構前のだっけ？

> (*)clppst.def は巨大ブロックコピー機能を使っています。
> お手元でのテストが必要なら，当該ファイルのコピーをお渡しできます。

是非お願いします。メールででも。m(__)m
バグの絞り込みが出来るかもしれません。
再現手順も詳しくお願いします。

めざらさんからテストデータをメールでいただきました。
ありがとうございます。

> > VTDOS 環境ですが，300KB ほどの比較的大きなファイルをちょうど今編集していて，
> > clppst.exe＋clppst.def による [ESC]I 様態(*)の作業を行って気が付きましたが，
> > ラップアラウンドエラーが出る状況になっています。テンポラリファイルエラーも
> > 出ました。現在の版の k07v6h と 前の版の k07v6d で発生を確認しました。

VTDOSのEMS環境ではデータが壊れるのを確認しました。他のVZも同様でした。
ラップアラウンドエラーやテンポラリファイルエラーは出ていません。
VTDOS.CFG の設定で
SCASB_MODE=1
にしているのも影響しているかもしれません。

試しに EMS環境で
SCASB_MODE=0
にしてみましたがラップアラウンドエラーやテンポラリファイルエラーは出ませんでした。
ファイル内容は壊れます。

> > k07t5 に差し替えると，上記のラップアラウンドエラーは発生しなくなりました。

これは環境による差異と思われます。
VTDOSで EMSを使わない XMS環境ではデータが正常に処理出来ました。他のVZも同様です。
VTDOSで EMSも XMSも使わない環境でもデータが正常に処理出来ました。他のVZも同様。

やはり、VTDOSには、EMSのバグがあるように思われます。
めざらさんは、EMSメインの設定なのではないでしょうか。

VTDOS には、メモリ拡張オプションがいくつかありますが、これも動作不良の原因の可能性があります。
私は何度か不具合を経験して、拡張オプションを全て止めました。
作者様も使っていないそうです。(^^;

私の今のVZ環境をだしておきます。

---------- option.lst --------------------- 2023/03/18 (Sat) 13:56 --------
 DOSV  VZt  VZk  z+  St-  vw+  zk-
 
 Bt64     Bf5632   Bo32768  EM128    XM16384  Bm380    Ba4      Hs256
 Hf256    Hx128    Ha92     Hw128    Bl8192   Bc1024   Bu256    Bv256
 
 SW2   TC12  WD0   We134 PG0   RS3   Ta8   Tb4   Ci4   Co2   WL1
 LC35  VM0   CA52  Sr39  Qt1   Qc20  Qw0   RM0
 
 Dl-  Dc+  Dt+  De+  Ds+  Db-  Dn-  Du+  Df+  Dp-  Dh+  Dg+  Dr+  Dj+  Dv+
  
 Ei+  Es+  Ez-  Eb+  Eu-  Et+  Eh-  Ew-  Ec+  Ex-  En-  Ev+  Ek-  Ea-  RO-
 Ej-  Eo-  El-
 
 RX-  ZH-  Sx+  Se+  Sd+  Sk-  Sy-  YN-  Sn-  Sq-  FP+  FR+  FK+  FQ+  Sz-
 
 Sc-  Nd+  Vb+  Sv-  Tv+  YM-  CH-  Hp-  Hp-  lf-  Is-  Da+  Nf+
 Ce0      ml + mc*  Ys$09  Yo$0E  Yr$0B
---------- End of option.lst ----------------------------------------------


他でも書いていますが、VTDOS+VZでは
XM1
EM12
などとするのが安全です。
EM0 でもメモリを食うものの、VZのスワップも無くなるのでより安全かもしれません。

めざらさんのデータを使って、10＃さんに VTDOSのEMSがVZで不具合が出る件を報告してもいいですか。
さすがにここまで不具合事例が出ては、10＃さんに対応をお願いした方がいいと考えます。
対応してくれるかどうかはわかりませんが。

> VTDOS には、メモリ拡張オプションがいくつかありますが、これも動作不良の原因の可能性があります。
> 私は何度か不具合を経験して、拡張オプションを全て止めました。
> 作者様も使っていないそうです。(^^;

過去ログを見たら、これは2014年ごろで、2018年ごろの #8006 の10＃さんの発言

> 最近はXMSもEMSもフルでVTDOSもTPAEXT=1で使ってます。

XMSもEMSもフルで指定した場合、VZは XMS を優先に使用します。XMSを使い切るまで EMSは使われません。
この環境なら安定するはずですね。(^^;
メモリ拡張オプションの不具合も、もしかしたら EMSが原因だったりして。

ということで、今の私のVTDOS.CFG は
TPAEXT=1
TPALOW=1
を復活させました。VZの起動バッチには
$XSET vzsym=NOQ  VTDOS
を仕込み、vz.def には

#if VTDOS	; VTDOS
XM1
EM0
SW1
#nedif

こうしてEMSを使わず XMS だけにしてコード領域のスワップを止めました。
それでも VMAP では

09CB <--    1  222080  vzibmj 1.60v -z /vz.def    00 1B 21 29 3F
4004-E7FE   1  688032  <free>

これだけメモリが空いています。余裕ですね。

EMS 関連ですかぁ……
メモリだと対処のしようがないですもんねぇ。

手元で，そのあたりの設定をいじって試してみたところ，
-EM0 -XM1 を指定した状態で割に安定しているように見えます。
ありがとうございます。

なお，あのデータは昨日既に公開済にしているものなので，問題ありません。
オープンドキュメントって個人情報入っているのかな？
まぁ，レジストしてるわけだし…

> 手元で，そのあたりの設定をいじって試してみたところ，
> -EM0 -XM1 を指定した状態で割に安定しているように見えます。

XMSで問題なく動いているならやっぱり EMS 絡みだったのでしょうね。

私はODSデータを LibreOffice で読んで、全選択でコピーして  ClpPst.def で新規ファイルに貼り付けました。
それを、TSV データとテキスト比較マクロで比較して完全一致を確認しました。
もう一つ、新規ファイルを開いて、[ESC]I で TSVデータを挿入して、元のデータと比較して完全一致を確認しました。

EMS環境では、複数のVZで確認し、全てデータが不一致になりました。
VZのコード領域っぽい文字列が混ざるので、EMSのスワップ自体が危険と感じました。

ずっと使ってきて今頃こういう事例が出てくるのは、ブロック移動関連のルーチンが怪しいのかも。
 ClpPst.def では EK+ のようなので、EK では無いのか、[ESC]I との共通点は #B #y #i あたり？ 

> なお，あのデータは昨日既に公開済にしているものなので，問題ありません。

ありがとうございます。公開データなら問題なさそうですね。
では 10＃さんにメールしてみますね。

konnoさん、あるいは、めざらさん

　ありがとうございます。どうもそれっぽいぞ、という気がしています。

　で、そのデータ（ファイル）の壊れ方というのを、簡単に説明して
いただけませんか。

　僕のところで、４，５回起こったのは、vtdos窓が落ちる、というのでは
なく、まさしく「ファイルが壊れる」だったのです。
　こちらでの壊れ方は、ファイルの途中が抜ける、あらぬところのファイルが
変な箇所に挿入される、ファイル末が消失する。こんな感じなのですが。
　文字化けとかバイナリを見てるみたいな気持ちの悪い画面はない。

　僕のところは、比較的大きなファイルです。

masttasm.txt  1,897,832  2023-03-17  16:35

　たとえば、こんなの。１ＭＢ以上かその近辺ぐらいのサイズです。

　で、上のようなファイルで、ちまちま文字化けその他を退治してるときに
ファイルに壊れられると、「ほんと嫌になっちゃう」なので、それで例の

c:\0etxt\
c:\0etxt2\

　とバックアップフォルダを作ることにしていたのです。

　違う話でしょうかね？
　EMSかぁ。ありがたいんだけどなぁ。ないとほんと困るのだけど。

　じつは、僕はこれが vtdos 環境のみで起こるのかどうか、よく分かりません
でした。WinMEで起こったことがない、と思う自信はなかった。
　他のミスオペレーションによるファイル破壊の可能性もありましたから。可能性
というより、実際にそれはあったと思う。

　ただ思い出していたのは、niftyの過去ログを壮絶に整理していたとき（切った
貼ったの連続。nifsort もビシバシ＝スワップありコマンドライン。awkで１記事
１ファイルにするとかもした＝1200個ファイルのアウトプット）、こんなこと、
起こらなかったよ、ということ。

　とりあえず、vtdos環境では、konnoさん設定でいってみます。
　やだよ、ファイル壊れるの。

konnoさん

　とりあえず、これでしばらく様子をみます。

#if VT		;VTDOS
XM1
EM0
#endif		;#10652 by konno, #nedif になってますよ。

　主たる作業場を、やはり WinME に戻すことにもしました。


>vz -z
ＸＭＳを最大 16384 ＫＢ使用します


173E <--    1  223520  vz 1.60t -z                00 1B 21 29 3F
4DD1-9FFE   1  336592  <free>	;少ねえぞ。

----- EMS ver4.0 (frame: C000h) -----       ----- XMS ver2.00 -----
handle pages   size  name                   HMA used: 63 KB by DOS
------ ----- ------  --------               EMB free: 32767 KB
     1     2    32k  for Vwx!	;これも本当は少し気になるのだけど。

　なぜそんなファイルの壊れ方に気づけるのか？
　質問にお答えします。

　編集処理をしてファイルサイズがどかっと変化したら、まず気づきます
（そのためのバックアップ）。

　もっと細かい場合を、現在作成中の_MASTERING TURBO ASSMBLER_ のetext 
をサンプルに具体的に説明します。etextは、以下のような体裁になっています。


=============== SAMPLE STARTS =================

---------------------	★タイトルページ

     MASTERING TURBO ASSMBLER, Second Edition
     by Tom Swan, SAMS PUBLISHING
     Copyright 1995 by Tom Swan

---------------------	★目次

Contents		;目次は大事です。全体が掴めます。Windows Program-
			;ming も OOP も、ほぼ必要ありませんから。

Part I Programming with Assembly Language
1  Introduction
Learning Assembly Language				4	;ページ数
Advantages of Assembly Language				7	;いちおう重要

<skip>

Index							870

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

---------------------[End of Page 3]--------------------	★本文始まり
4							;オリジナル・ページ
							;番号が上にある場合
Learning Assembly Language 				;もある。

I remember when I discovered assembly language. The nearest I've come to
experiencing the same elation was the day I first balanced a two-wheeler,
wiggling my way down our street, my father's thumb no longer snagging my
belt, my fear of falling melting like bee's wax in the sun.
<skip>

---------------------[End of Page 4]--------------------	★本文続く

<skip, skip, skip>

869								★890pages
---------------------[End of Page 869]---------------------	★の本
								★索引
Index

Symbols
, (commas), macro parameters, 303 				;キーワードと
! (exclamation point), macro string characters, 307 		;ページ数
% (percent sign), expression evaluate operator, 306 		;いちおう重要
%NOLIST command, 331 

870
---------------------[End of Page 870]---------------------	★索引続く

<Index, skip, skip, skip>

Z
zero (string instructions), 138

890
---------------------[End of Page 890]---------------------	★書籍終わり

=============== SAMPLE ENDS =================


（０）
etextの全体像（構造的骨格）は上のとおり。

（１）
890
---------------------[End of Page 890]---------------------
　は、ＯＣＲソフトが自動でつけるページフッタ。
　上の行の890が、オリジナル書籍に入っていたページ番号。
　これは完成形。ページ番号は化けたり、スペースが入っていたり色々ある。
　ページフッタは、中身以外は機械のように正確に付く。

（２）
---------------------[End of Page 3]--------------------	★本文始まり
4
　のように、オリジナル・ページ番号がページの上、前ページフッタの次行に
置かれていることもある。

（３）
　この [End of Page X] は、最初、現実を反映していないのが普通。Prefaceとかで、
xxiii のようなローマ数字が使われるから。ＯＣＲは、pdfの１ページから番号を振る
　このズレは、手作業あるいは、order.def by mikome で直します。
　現在位置がすぐさま確認できないと、オリジナルｐｄｆとの照合が困難になるから。
　この照合は、いっぱい必要です。プログラム・リストや表、図は、そもそも
データ的に崩れているのが普通。
　目次、索引のページ数データ（ふつう健全）が「いちおう重要」なのも、この
ページフッタと整合させたいから。キーワードですぐ飛べない場合もある。

（４）
　（３）の作業が正確に終了したら、「890」の行は削除。要らない情報は、できる
かぎり掃除して除去する。もちろん、「890」と「End of Page 890」が正確に一致
していることを確認してから。

（５）
　しかし編集作業中、いろいろ起こる。だから、>cgrep "End of Page" through filter.def
は、頻繁に行う。>cgrep -A1 -B1 "End of Page" (ページフッタ前後行も) も頻繁。

　とうぜん
---------------------[End of Page 1]--------------------
---------------------[End of Page 2]--------------------
---------------------[End of Page 3]--------------------
　なんてのが、永遠と続く結果が得られる。
　　　　　　　　　　　　　　　　　^ ここにカーソルをおいて、numchk.defもする。

（６）ガーン！

　Page 123 - Page 134 が消失してる！
　Page 231 - Page 239 が Page 155 の前に来てる！
　作業前は、健全だったのに！


　なんで素直にｐｄｆで書籍を書籍として読み、本質であるアセンブラのお勉強に
励まないのですか？　ｐｄｆは、WinMEでさえ読みづらく、ＤＯＳではまったく
読めないからです。検索もジャンプもうまくいかない場合が多い。
　あと、あと、あと、テキスト・フェチだからです。機械を使っている
＝使われているというのが、快感だから。

> 　で、そのデータ（ファイル）の壊れ方というのを、簡単に説明して
> いただけませんか。

入れ違いに成りましたが、#10654 の説明でよろしいでしょうか。

> 　じつは、僕はこれが vtdos 環境のみで起こるのかどうか、よく分かりません
> でした。WinMEで起こったことがない、と思う自信はなかった。
> 　他のミスオペレーションによるファイル破壊の可能性もありましたから。可能性
> というより、実際にそれはあったと思う。

VZのバグも、[ESC]I マクロで新たに発覚しましたね。
EK- #B で、CP ズレなどが起きることがある。
BL3072 あたりでは致命的なエラー　 BL8192 あたりで CP ズレ？

そして、BL1024 あたりで、VTDOSのEMS環境だけ、内容が壊れる。
これがおそらくVTDOSのEMSのバグではないかと疑われたのです。

> 　とりあえず、vtdos環境では、konnoさん設定でいってみます。
> 　やだよ、ファイル壊れるの。

それが良いと思います。

> #endif		;#10652 by konno, #nedif になってますよ。

げげ、何処かで打ち間違えて、そのままコピーして使っていました。(>_<)
直そうとしたら、"#eedif" にしちゃってるし。(^^;
そういえば、わなまさんは "#ifend" とやっていたような。
5文字なら通るみたいに言っていたような気がします。(^^;

> 173E <--    1  223520  vz 1.60t -z                00 1B 21 29 3F
> 4DD1-9FFE   1  336592  <free>	;少ねえぞ。

10＃さんも
> > 最近はXMSもEMSもフルでVTDOSもTPAEXT=1で使ってます。
こう言っているので、TPAEXT=1 を設定すれば良いと思います。

>      1     2    32k  for Vwx!	;これも本当は少し気になるのだけど。

これも TPAEXT=1 を設定すれば余裕ですよ。(^_^)

> ありがとうございます。公開データなら問題なさそうですね。
> では 10＃さんにメールしてみますね。

10＃さんにメールして、お返事をもらえました。
確認してもらったのですが、予想外の結果でした。

> まず、僕の環境でXMSのみ、EMSのみの環境でテストしてみましたが、
> EMSでは正常に貼り付ける事が出来ました。
> XMSの場合ではマクロが正常に終了せず、CLPPST.TMPがVZに残った
> 状態で中断しました。
> 続いてclppst.defによる貼り付けでは無く、メモ帳に貼り付けて保存した
> ファイルを[ESC]Iで挿入した場合正常に保存されました。

私のテストでも、EMS環境で、BT32 などの場合は正常に処理されたようでした。
めざらさんのデータだけでは検証には不十分なようです。

としきさん
検証のためには、としきさんの生ログデータが最適だと思います。
10＃さんにメールで送ってもかまわないでしょうか。

検証用のスレッドを立てたいと思います。

konnoさん

　色々とありがとうございます。

>そういえば、わなまさんは "#ifend" とやっていたような。
>5文字なら通るみたいに言っていたような気がします。(^^;
　僕の記憶では、cmos版では文字数、高橋版以降でちゃんと文字チェック
だったと思います。ソースでご確認ください。

>これも TPAEXT=1 を設定すれば余裕ですよ。(^_^)
　うーん、vtdos.cfgですね、設定してみました。それを止めたうっすらと
した記憶が、、、。
　もう、この場所は、あくまで実験なのだ、何が起こるか分からないのだ、という
覚悟です。

　思ったのですが、10＃さんは、やっぱりマクロを使わない人だったのだと
思う。だから、「そんな使い方、あるわけないだろう」というvtdosの設計に
なっている、、、。
　ま、ＥＭＳが主題なわけですが。ただ、テンポラリーファイルが絡んじゃう
からなぁ。
　１６ＭＢまで行けるＶｚでも、１ＭＢのテキストもきっと編集したことないの
でしょう。プログラマなら、ふつう。常識的な使い方。

　で、10＃さんは、そんなＶｚのどこに魅力を感じたのだろう？
　macro.asm, expr.asm が、Ｖｚの本丸だと、現在、思い込んでいます。
　そうでなければ、mifesでも秀丸でもいいんじゃないの？
　そもそもＤＯＳにこだわる必要があるの？？？

　Ｒ・ダンカンの名著とされる「_Advanced MS-DOS Programming_のお世話になった」
と言ってたから、ＤＯＳの深みにはまっちゃったのかな？　若気のいたり。
Win98時代。NT/2000 の姿がちらりちらりな時代。

> 検証のためには、としきさんの生ログデータが最適だと思います。
> 10＃さんにメールで送ってもかまわないでしょうか。

かまいません。
機微な部分は改竄済みですし、それ以外は公開されている情報ですから。

konnoさん

>入れ違いに成りましたが、#10654 の説明でよろしいでしょうか。

　よろしいとは言えませんが、これ、違う話だ、と思っています。
　僕にスワップは関係ないし、Ｖｚのコード領域がデータと混ざることは
ないです。この辺を確認したくて、#10666で、あんなに長々書いたのですね。

　うーん、filter.defで、Ｖｚ内部ラップアラウンドが起こっているか、
置換処理（テキストバッファくずれ？）なのかなぁ？
　とりあえず、WinMEできっちり見定めます。見定められなかったら、幸運。

　vtdosでのＥＭＳかＸＭＳか、どうかどうか、なんとかしてください。
　m(__)m

予想外ですね……まるで逆（EMS ・ XMS）とは思いもよりませんでした。
とくに clppst.def 異常終了で clppst.tmp が残ったままという現象は，
わたしのところでは EM1・XM0 のときに発生します。（ここ正反対）

環境って，そんなに違うのですかね。TPAEXT=1 は一貫して設定していますし，
BT は（かつての LX 以外は）昔からずっと 64(最大)でした。

ふつうに使えるかどうかわかりませんが，
個々の環境.DEF をインクルードして，環境の共有をすることを提案します。

方法としては，（非常駐バッチで起動することが前提になってしまいますが）
個々の環境の値を - あじゃ - さんの opt_lst.def で出力したものを
（tVZ dVZ kVZ で追加されたオプションを追加する必要があるかも） 
マクロファイルに加工して保存したファイルを各人が準備・共有。
バッチを一度終了して，VZ +m.def -bm20000 のようにして起動してテスト。
（bm の空きが 1000 くらいあれば bm の指定は不要かと思います）

いかがでしょう。

--- vtdos.cfg ---
DISKFREE=K
USECMD=1
UMB=1
SCASB_MODE=1
TPAEXT=1
-----------------

173E <--    1  223520  vz 1.60t -z                00 1B 21 29 3F
4DD1-E7FE   1  631504  <free>

----- EMS ver4.0 (frame: E800h) -----       ----- XMS ver2.00 -----
handle pages   size  name                   HMA used: 63 KB by DOS
------ ----- ------  --------               EMB free: 32767 KB
     1     2    32k  for Vwx!
  free  2046 32736k

　こんな感じになりました。m(__)m
　怖いのは怖いけど。

　皆で同じ環境をつくって調査する、ということなら、データ等お送り
ください。clppest.exe(def) の話は、まったくついて行けておりませんが。

> > 検証のためには、としきさんの生ログデータが最適だと思います。
> > 10＃さんにメールで送ってもかまわないでしょうか。
> かまいません。
> 機微な部分は改竄済みですし、それ以外は公開されている情報ですから。

ありがとうございます。
これから再現手順とか色々纏めてメールで送ります。
昨日は気力が尽きてしまったもので。(^^;

> 予想外ですね……まるで逆（EMS ・ XMS）とは思いもよりませんでした。
> とくに clppst.def 異常終了で clppst.tmp が残ったままという現象は，
> わたしのところでは EM1・XM0 のときに発生します。（ここ正反対）

私もビックリしました。
やはり再現条件は揃えないと駄目なんですね。
めざらさんのデータでは
VZT 高橋版で BT64 BL8192 SW0 で常用DEFで ClpPst.def 方式で実行したら、正常でした。
同じ条件で、[ESC]I マクロでは内容破壊、サイズが小さくなりました。
BT32 にして、[ESC]I マクロでは正常に処理出来ました。

これでは特定は難しいですね。
としきさんのデータは今まで色々検証してきているので、プロが見れば特定できる可能性があると思います。

> ふつうに使えるかどうかわかりませんが，
> 個々の環境.DEF をインクルードして，環境の共有をすることを提案します。

これはいいですね。
とりあえずは、オリジナルのVZ.DEFを、DS+ と変更し、VZO.DEF として送ります。
DS+ でファイルサイズが表示されるので、比較するまでもなくテキスト破壊がわかります。
オリジナルは、BT64 BL2048 SW3 で、[ESC]I マクロでは内容破壊、サイズが小さくなります。

BL128 〜 2048 の範囲では、VTDOS+EMS環境だけが異常になります。
SW0 BT32 でも異常になりました。

VZ /vzo 　で起動します。(VZは各種VZを指定可）

> VZ /vzo 　で起動します。(VZは各種VZを指定可）

それでもよいのですけれど，わたしが言いたかったのは，

= m
* O
Bt64
Bf64
Bo32
EM0
XM1
SW3
RM0
;; 以下，省略。
*

みたいなファイルをそれぞれの環境で作って共有すれば，
どこに問題があるのかを解明するヒントになるんじゃないかなと。

> みたいなファイルをそれぞれの環境で作って共有すれば，
> どこに問題があるのかを解明するヒントになるんじゃないかなと。

なるほど、オプションリストのメモリ関連だけを DEF 形式にするようなものですね。
各自の常用環境で問題が出れば、直ぐにオプションがわかって試せますね。
そういう情報はドシドシあげてほしいですね。

VTDOS+EMS+VZでの不具合検証スレを立てました。
きっかけは #10637 の、めざらさんの不具合報告からです。

> > VTDOS 環境ですが，300KB ほどの比較的大きなファイルをちょうど今編集していて，
> > clppst.exe＋clppst.def による [ESC]I 様態(*)の作業を行って気が付きましたが，
> > ラップアラウンドエラーが出る状況になっています。テンポラリファイルエラーも
> > 出ました。現在の版の k07v6h と 前の版の k07v6d で発生を確認しました。

VTDOSのEMS環境ではデータが壊れるのを確認しました。他のVZも同様でした。
ラップアラウンドエラーやテンポラリファイルエラーは出ていません。

> > k07t5 に差し替えると，上記のラップアラウンドエラーは発生しなくなりました。

これは環境による差異と思われます。
VTDOSで EMSを使わない XMS環境ではデータが正常に処理出来ました。他のVZも同様です。
VTDOSで EMSも XMSも使わない環境でもデータが正常に処理出来ました。他のVZも同様。
つまり、テンポラリファイルのみ使用でも問題が出なかったのです。

めざらさんの環境とこのデータの関係については別に検証が必要と思われます。
それはともかく、私はVTDOS+EMS+VZでの不具合は問題と感じて、10＃さんにメールで報告してみました。
その結果は予想外でした。

> まず、僕の環境でXMSのみ、EMSのみの環境でテストしてみましたが、
> EMSでは正常に貼り付ける事が出来ました。
> XMSの場合ではマクロが正常に終了せず、CLPPST.TMPがVZに残った
> 状態で中断しました。
> 続いてclppst.defによる貼り付けでは無く、メモ帳に貼り付けて保存した
> ファイルを[ESC]Iで挿入した場合正常に保存されました。

私のテストでも、EMS環境で、BT32 などの場合は正常に処理されたようでした。
めざらさんのデータだけでは検証には不十分なようです。
それで更なる検証のために、としきさんの生ログデータを使わせてもらいました。
それについては次回以降からやります。

現状のVTDOSを安全に使用する為の設定です。
XMSもEMSもフルで指定した場合、VZは XMS を優先に使用します。XMSを使い切るまで EMSは使われません。
この環境ならまあまあ安定するはずですが、EMSを使用した場合の挙動は保証されません。
メモリ拡張オプションの不具合も、もしかしたら EMSが原因だった可能性もあります。

ということで、今の私のVTDOS.CFG は
TPAEXT=1
TPALOW=1
を復活させました。VZの起動バッチには
$XSET vzsym=NOQ  VTDOS
を仕込み、vz.def には

#if VTDOS	; VTDOS
XM1
EM0
SW1
#endif

こうしてEMSを使わず XMS だけにしてコード領域のスワップを止めました。
vwx.com も EMSを使うので、不安なら起動オプションで、Z1 にすれば良いでしょう。
それでも VMAP では

07D6 <--    1   20944  vwx 1.08b -z1 -v2 -x1 -l6
0E21 <--    1  222080  vzibmj 1.60v -sw2 -z       00 1B 21 29 3F
445A-E7FE   1  670272  <free>

これだけメモリが空いています。余裕ですね。
コンソールやファイラーでEMSを使いたいなら、EM4 は必要です。
ある程度EMSが欲しいなら、EM128 （2M）くらいならほとんど問題ないかと思います。
オリジナルVZでは、#if VTDOS が効かないので、EM128 は残してあります。

としきさんのデータは今まで色々検証してきているので、プロが見れば特定できる可能性があると思います。
みんなで共有できる共通の検証環境として、10＃さんに、としきさんのデータと VZO.DEF を送りました。

 添付ファイルは

2022/03/03 01:00 170,335 0007.cgi	オープンするファイル
2022/03/02 23:04 132,553 0007.cg	[ESC]I で挿入するファイル
2022/03/03 19:11 302,888 0007-i.cgi	正常な結果ファイル（比較用）
2023/03/20 14:45  15,980 vzo.def	オリジナルVZ.DEF  DS+ に変更

まずは、オリジナルのVZ.DEFを、DS+ と変更し、VZO.DEF とします。
DS+ でファイルサイズが表示されるので、比較するまでもなくテキスト破壊がわかります。
オリジナルは、BT64 BL2048 SW3 で、[ESC]I マクロでは内容破壊、サイズが小さくなります。

BL128 〜 2048 の範囲では、VTDOS+EMS環境だけが異常になります。
SW0 BT32 でも異常になりました。


検証手順は

VZ /vzo 　で起動します。(VZは各種VZを任意に指定）

170k の 0007.cgi をオープンする

[ESC]I で132k の 0007.cg を挿入する　ファイルサイズは、302,888 になる
この時点でファイルサイズが違っていたら内容が壊れています。

ファイルサイズが同じなら、^QR でカーソルをテキスト先頭に
302k の比較用 0007-i.cgi をオープンして、[F04] で分割して [Shift][F03] で比較する
「一致しました」というメッセージが出たら、正常です。


この検証で興味深いのは、BL の値で結果が変わることです。
BL128 〜 2048 の範囲では、VTDOS+EMS環境だけが異常になります。　※他のVZ環境では全て正常になる
BL1024*3（3072）のあたりでは、ファイルサイズが変わって致命的なエラー　※VZのバグ
BL1024*8（8192）のあたりでは、CP ズレが起こり、ブロックが入れ替わります。　※VZのバグ

もしかしたら、1か所のルーチンの不具合でこの3つの不具合が起こっている可能性もあるかもです。

> なるほど、オプションリストのメモリ関連だけを DEF 形式にするようなものですね。

セクション * Option にあるもの全部です。メモリ関連だけではありません。

> > なるほど、オプションリストのメモリ関連だけを DEF 形式にするようなものですね。
> セクション * Option にあるもの全部です。メモリ関連だけではありません。

げげ、そうなると何ページかに渡ることになりますね。
大きなデータは、テスト掲示板のほうにお願いします。
#test75 のように、#test に発言番号を続けるとリンクできますので。

今回の問題が見つかったきっかけは、1年前の野ざらし言の書き込みからでした。
関連しそうなツリーや記事のリンクを張っておきたいと思います。

野ざらし言#4609.ファイルの挿入 - としき 22/02/05-18:33 
★　全てはこのツリーから始まった。非常に長いツリーです。


野ざらし言#4700.ファイルの挿入とオプションの値 - としき 22/05/03-22:43
★　非常に長いツリーです。

野ざらし言#4753　 konno
 &t トレースでは ek-, の時 #i の挿入でカーソル位置がズレたように見えたので。

野ざらし言#4784  添付ファイルは　konno
2022/03/03 01:00 170,335 0007.cgi オープンするファイル
2022/03/02 23:04 132,553 0007.cg [ESC]I で挿入するファイル
2022/03/03 19:11 302,888 0007-i.cgi 正常な結果ファイル（比較用）

野ざらし言#4800  行ブロックズレはマクロのせい？　konno
トレースで見ると、3回目の #i のブロックペースト後が問題です。
 Ek- の時カーソル位置更新しますが、その位置が1文字ズレて改行の所になります。
本来なら行頭にくるはずなんですが、1文字ズレることがあるんですね。

野ざらし言#4835　めざら
現象から言えば，確かに #< があることで論理行が入れ替わるということになりますが，不具合の根本的な因子はそこではないと思います。
以前にもちょこと書きましたが，#< にはページングにおける KY (保存されたY位置)を更新する効果があって，ヒトの目線のズレ修正に貢献していると考えているのですが，c.mosさんとしては「美しい動作」というのが脳裏にあって #< を使っていたのではないかと想像しています。（まるきり外してるかも）

野ざらし言#4840　としき
> 異常挿入を起こす0007.cgiの冒頭からの真の最小のファイルサイズ
見つけました。
27932バイトでは異常発生、27931バイトでは正常挿入。

野ざらし言#4892  Blの指定可能な値について　めざら
bl 34452 / pq..148==$776A, pq..149==$FDFE
bl 34453 メモリが足りません.
512バイトの緩衝領域＋2バイトを前方（最上位メモリ）に確保しさえすれば，大きなラインバッファの「確保」は可能。ただし，正常に使用可能かは不明。

野ざらし言#4883　としき
上記の、異常挿入を起こす最小サイズとしては27932バイトなわけですが、元のファイルではその部分はちょうど２バイト文字の真ん中に当たります。なので、２バイト文字の区切りで１文字増やした27933バイトのファイル、これに0007.cgファイルを挿入しようとすると当然、異常挿入になります。この場合、ファイル末尾は「気」という文字です。
ところが、同様に0007.cgiファイルのこの行の「気」の文字の次に改行を入れたファイルを作り、このファイルを開きなおして0007.cgファイルを挿入しても、正常挿入。ところが、そこにさらにもう１バイト、何でもいいけど半角文字を追加して保存して開きなおし、0007.cgファイルを挿入しようとするとそれは見事に異常挿入。
不思議だ、なぜ２バイトずれる。


野ざらし言#4711.ファイル挿入(1) 1.60製品版 - めざら 22/05/07-21:13 
★　非常に長いツリーです。

野ざらし言#4934　なんというか、なかなか面白い結果となりました。　としき
特に面白いと思ったのは、あとから0007.CGファイルを読み込ませるとき、先に開いて
いたファイルのサイズとBlの値によって、きれいに挙動が変化する部分。すなわち、
以下のところですね。
先に開いていた　 Blの値
ファイルのサイズ 8191  8192  8193  
27931バイト　　　正常　正常　異常
27932バイト　　　正常　異常　異常
27933バイト　　　異常　異常　異常
また、Blを16384まで大きくすれば常に正常挿入になるかと思ったけどそうはならない、
という部分もなかなか興味深いところ。

野ざらし言#4995　これの続きを試してみました。　としき
先に開いていた　 Blの値
ファイルのサイズ 8190  8191  8192  8193  8194
27930バイト                        正常  異常
27931バイト　　　      正常　正常　異常
27932バイト　　　      正常　異常　異常
27933バイト　　　正常  異常　異常　異常
27934バイト      異常

野ざらし言#4997] EM の値で [ESC]i の挙動が変わる konno 2022/09/03(Sat) 18:24
何気なく、EM1024 を、EM12 とか小さくしてみたら [ESC]i の症状が良くなったみたいです。
それで、EMの値を変えて色々試してみました。
EM1017 を超えるとNG で、EM1010 ならほとんどのVZ環境で問題改善するようです。
今まで同じVTDOSでも私の環境で [ESC]i の挙動が良くなかった原因が分かった気がします。

★　EM1024-1017=7  16k*7=112k  つまり、XMSは112kでそれ以上はEMSが使われて異常が出たと考えられる
★　EM1024-1010=14 16k*14=224k つまり、XMSは224kでそれ以上はEMSが使われる
★　この時点で、VTDOSのEMSの挙動に気づかなかったのが悔しいです。

　別にとりわけ意図も希望もなく、説明を分かりやすく書き直しておきます。
　１ＭＢのファイルがある。１０００本のページフッタが中に入っている。
「ページ番号つき」フッタには、Page 1 から Page 1000 まで番号がつく。
　だいたい1KB ごとに番号のついた線が入っているということ。

　そして、

《1MB file》
------------------------
------------------------
AAA
------------------------
------------------------
BBB
------------------------
------------------------
CCC
------------------------
ZZZ
------------------------

↓

《1MB file》
------------------------
------------------------
AAA
------------------------
CCC				;移動
------------------------
------------------------
BBB
------------------------
------------------------
				;消失


　vtdos環境で、上のようなことが起こったらしい。起こったのは事実ですが。
　EMS を使い、スワップをさせないＶｚ設定で起こった。
　「Ｖｚ内部のラップアラウンド？」と書いたのは、行番号がワード値を
超えていたから filter.defがバグった？　と思ったから。超えていませんでした。
　WinMEで、同じような処理をかなりやりましたが、何も起こらないみたい。
　気のせいかもしれません。−−−２０回はバックアップファイルとの照合を
しました。

　それで、めざらさんのところで発現したのと（clppest.exe & clppest.defがらみ）
と同じ原因？　と思ったのでした。
　たぶん原因は違うだろうと考えています。残念ながら、何かのオペレーション・
ミスだったのだろうと考えています。ただ、vtdos環境では、この作業はもう
しません。（嫌われそうですが）WinMEだと、ＶｚとＤＯＳが速いんです。

>>そういえば、わなまさんは "#ifend" とやっていたような。"
>>5文字なら通るみたいに言っていたような気がします。(^^;"
>　僕の記憶では、cmos版では文字数、高橋版以降でちゃんと文字チェック
>だったと思います。ソースでご確認ください。

　高橋版では、「ブロック IF 文」のネストができます。
　cmos版では、テーブルを置いて、確かに文字数で分岐させています。
　ちょんと読みきれたわけではありませんが、inst.asm の両者を読み比べると
「高橋さん、やっぱ、読みきってるわ」と思うと思います。全面書き換えだった。
　あそこにデータ入れて処理した c.mosさんにも、感じいったけど。すごい発想。

vzk07v6h バグがありました。

EMSのみで BL1024 の時、MS-DOS Player や　DOSVAXJ3 でも不具合が出ました。
他のVZでは、MS-DOS Player や　DOSVAXJ3 では不具合が出ません。
vzk07v6h のバグでした。

公開を停止しますので、使用も中止してください。
確認不足でした。
ご迷惑をおかけして申し訳ありません。

> 　vtdos環境で、上のようなことが起こったらしい。起こったのは事実ですが。
> 　EMS を使い、スワップをさせないＶｚ設定で起こった。

VZのスワップ機能ってどういう動作だっけ？　私はキチンと把握していませんでした。
VZ1.6のマニュアルP158を見ると
コマンドラインでコマンド実行時にメモリを空けるためにVZの使用メモリの一部をEMSなどに退避させることみたいですね。

EMS環境では、SW0 でもEMSはテキストのテンポラリファイルとして使用されます。
EMS のWikipediaによると

>   "EMSマネージャ"を通じてメモリ空間の取得・開放、バンク切り換え等を行う。
>   16KBytes単位でバンク切替を行い、これをページと呼ぶ。
>   8086でアクセス可能な1Mbytesの範囲内に"ページフレーム"区画を設ける。
>   ページフレームは、ほとんどの場合4ページ = 64Kバイト(バージョン4.0)の連続した領域。
>   EMSマネージャは、要求のあったページをページフレームに出現させる。
>   そのため、各種操作は隠蔽され、ユーザは気にする必要が無い。
>   対応するメモリ総量は32Mバイト(2048ページ)まで。
>   主な版として3.2, Enhanced EMS 3.2, 4.0がある。4.0では特にWindows 2.x向けの拡張を行った。

つまり、64k を超えるテキストは、EMSメモリに展開され、16k〜64kの物理メモリとの間で常にメモリ転送されていると。
VZの BT は、16〜64 まででしたね、私はこれで、BT が物理メモリの窓の大きさなのだということに気が付きました。(^^;
例のバグバグVZは、BT32以下にすると駄目みたいです、いつも BT64 で使っていたので気が付きませんでした。
このVZは蟲探しの良い教材になりそうですね。(ﾟ゜)☆＼(--#)ﾊﾞｷｯ

> 　高橋版では、「ブロック IF 文」のネストができます。
> 　cmos版では、テーブルを置いて、確かに文字数で分岐させています。
> 　ちょんと読みきれたわけではありませんが、inst.asm の両者を読み比べると
> 「高橋さん、やっぱ、読みきってるわ」と思うと思います。全面書き換えだった。
> 　あそこにデータ入れて処理した c.mosさんにも、感じいったけど。すごい発想。

文太さん、ソースで確認してくれたのですね、ありがとうございます。
私はこれからふかい海に潜ってソナーで敵の蟲を探しに行きます。
無事に浮上出来るかわかりません。(^^;

いちおうkonnoさん宛なのですが、ここに補足説明。

>vtdos環境で、上のようなことが起こったらしい。起こったのは事実ですが。
　ったく、訳が分からない書き方をするな。
　うーん、今振り返ってみても、本当にVTDOSが原因なのかは分かりません。
　WinMEでは起こっていないと思うけど。
　僕はここ１〜２か月、五月雨にしかＶｚでテキスト編集とかしてませんでした。
　入力主体（論文を書く、翻訳をする、プログラムを書く）だとガシガシ、
コマンドを連発で繰り出したりしませんよね（主にWinME 真剣環境）。ちまちま
キー入力。
　連発はetext作成なんて場面での「編集」のときです。これがね、記憶曖昧
なんだなぁ。

　でも、だいたいその期間に（疲れてるとき）、Win7=VTDOSで、この現象に
気がついた。
　VTDOSが原因か分からないけど、VTDOS環境で起きた可能性は高いです。
　対象が、でかいファイルであること。

>　EMS を使い、スワップをさせないＶｚ設定で起こった。
　これはママです。
　ただし、ビッグニュース！　これはVzk 最新版でなく、k07t01という相当古い
版で起こりました。ですから、今回のめざらさん発見のパターンとは原因が違う
ことが想像されています（注）。kVz の版を変えても、きっと起こる。原因が何
にしろ。僕の場合は。

>　「Ｖｚ内部のラップアラウンド？」と書いたのは、行番号がワード値を
>超えていたから filter.defがバグった？　と思ったから。超えていませんでした。

　これワケワカだ、という人がいるかもしれないので。
　ふつうのfilter.defの使い方は、filterです　>filter <a.txt >b.txt。
　ただし、ブロックしてシフト起動すると元ファイルの該当部分を直接書き換えます。
こういうことができるマクロです。で、その部分に引っかかったのかなぁ、と少し
思った。これ、ガシガシやってますから。
　というわけで、まだ、このラインを（vz.com or filter.defが原因）、捨てては
いません。

　とにかく、うーん、ゆっくり行きましょう！
　失敗しなければ成功しない。失敗しつづける覚悟。老人に必要なのはこれです！
いつか勝利の雄たけびをあげるために。大谷のように、ダルビッシュのように。
（彼らは老人でないけど）誰にむかって言ってんだ。自らを鼓舞しております。
　cmosさんだって、泣きたいときあったはずですよ。

　しかし、９５年あたりのYushiさんデビューの頃、テキスト構造体が明らかに
されていた頃（上村さん主導）のログをちら読みしましたが、このエディタ、ほんと
深い！　知らない変数、たくさん！　演算子の優先順位（評価の順番と仕組み）とか
テキスト表示の仕組みとか（by Emmett）もあったし。たしかにテキスト構造体に
（すら）ワケワカなの、けっこうありますよね。
　それでも、読んでたら、「あ、これ、できるようになりたい。どんなマクロに
すればいい？」とか、しっかり思いつく！

　死ぬまでＶｚ！　こればっか。

（注）大事でもなんでもないのですが。ＥＭＳが原因だったら（テンポラリーファイル
の破壊）、めざらさんのと同根、となり、VTDOSが原因となるのかな、VTDOSではEMSは
最小限に、とかなるのかと思いました。が、10#さんが「ＸＭＳだと起こるけど？？？」
と回答してくれたあたりで、もう何が何だか、、、となりました。

　我々（僕以外の我々）が追っていたものとは関係ないだろうと思います。
　ま、しっかし、偉いなぁ、皆さま

　ＳＶＣのログです。

>03472/03472 xxxxxxxx  tanosan          ちょっとしたバグなど（やや長文）
>( 2)   94/01/05 15:48
>
>　◎「カーソル位置へ挿入」マクロで、挿入するファイルの最後の行長が 
>    wd の整数倍で、末尾に改行がないとき（つまり、#_ でジャンプした
>    先が ct==0 && lh!=0 のとき）、その行が読み込まれません。次の修
>    正でＯＫ。
> 
>	#b #_ (ct)?{ #> #m #x }
>         ↓  #x は不要
>	#b #_ (ct|lh)?{ #> #m }

　もちろん偶然です。グレップすらしていません。
　[ESC]I って、ほんと色々あったのねぇ。上村さんのinsfile.defを『強化書』
の頃から（たぶん）、使っているから、えー、そういうのあったんだ、程度の認識
なのですが。

　ただ、filter.defは、似たようなことをしてたわけですよ。

vzk07v6h は既に公開停止とのことですが，追加情報です。

実は発生条件が今ひとつ確定できていなくて，安易に報告しにくいのですが，
ヒストリバッファが壊れるという現象が起きています。（07t02では発生しない）

■ひとつの再現例
自分の似非GREP（http://mezala.la.coocan.jp/vz/workshop/msearch.html#esegrep）で，
【R._ラジオ小劇場】あるいは【R..ラジオ小劇場】などと検索文字列を入力し実行すると
入力した検索文字列が【R-/ラジオ小劇場】のような変な化け方をします。
ps をそのまますり替えずに使っているのでバッファのアドレス等の問題ではありません。
ただし，マクロでなく手元で RX+ として #F 窓に上記の文字列を入力しても化けません。
トレースすると，化けるタイミングとしては，入力窓を閉じた直後に既に化けていました。
少し前の版 k07v6d でも，【R訃ラジオ小劇場】と似たような化け方をしました。

この現象は，vzk07t02 や vzt では発生しないので，07v* で新入りのバグのようです。

マクロでヒストリバッファを使ったときだけ化けるというのは初めての経験なので，
再現条件が特定のマクロだけという心許ない状況ですが，とにかくご報告まで。
撤回版としても，以降の版に引きずるとまずいので，ともかく報告に及びました。

> 実は発生条件が今ひとつ確定できていなくて，安易に報告しにくいのですが，
> ヒストリバッファが壊れるという現象が起きています。（07t02では発生しない）

う、そうなんですか、バグバグで申し訳ないです。m(__)m

> 自分の似非GREP（http://mezala.la.coocan.jp/vz/workshop/msearch.html#esegrep）で，
> 【R._ラジオ小劇場】あるいは【R..ラジオ小劇場】などと検索文字列を入力し実行すると
> 入力した検索文字列が【R-/ラジオ小劇場】のような変な化け方をします。
> ps をそのまますり替えずに使っているのでバッファのアドレス等の問題ではありません。
> ただし，マクロでなく手元で RX+ として #F 窓に上記の文字列を入力しても化けません。
> トレースすると，化けるタイミングとしては，入力窓を閉じた直後に既に化けていました。
> 少し前の版 k07v6d でも，【R訃ラジオ小劇場】と似たような化け方をしました。

これは詳細ですね、非常に参考になります。ありがたいです。

> この現象は，vzk07t02 や vzt では発生しないので，07v* で新入りのバグのようです。
> マクロでヒストリバッファを使ったときだけ化けるというのは初めての経験なので，
> 再現条件が特定のマクロだけという心許ない状況ですが，とにかくご報告まで。
> 撤回版としても，以降の版に引きずるとまずいので，ともかく報告に及びました。

ご指摘が無ければ気が付かずにずっとバグ入りのままだったと思います。
教えてくださり、ありがとうございました。

> >　◎「カーソル位置へ挿入」マクロで、挿入するファイルの最後の行長が 
> >    wd の整数倍で、末尾に改行がないとき（つまり、#_ でジャンプした
> >    先が ct==0 && lh!=0 のとき）、その行が読み込まれません。次の修
> >    正でＯＫ。
> > 
> >	#b #_ (ct)?{ #> #m #x }
> >         ↓  #x は不要
> >	#b #_ (ct|lh)?{ #> #m }

こ、これは・・・
確か、[ESC]i マクロの不具合の件で、野ざらし言に書き込んでいたと思います。
「#x は不要」で検索したら、過去ログにありました。
野ざらし言#4612 から、野ざらし言#4617 で 2022/02/13 の発言で

> この元ネタを探してみたんですが見つけられませんでした。
> 私の思い込みで勝手に変えちゃったのかもしれません。
> T.Tanomura さん、不確かなもので名前を挙げてしまいすみませんでした。m(__)m

探せなくて、こう書いていたんですが、SVC でしたか・・・
この会議室は、バグ報告の宝庫ですねぇ、この発言だけでも他に
-------------------------------------------------------------------
　◎FD からの子プロ起動時に !Open がトレースモードに入る現象ですが、
    必ず、!Open の最初のキーワードを実行し、２番目のキーワードの実
    行に入るところでトレースモードになるようです。1.6 の標準 DEF で
    は「?ts=」で止まります。こうした事情から考えられる原因はありま
    せんか？
 
　◎常駐-解放-常駐を行うと、解放したはずの VZ が居座っていることが
    あります（再現条件不明）。これは VZ 側の問題でしょうか、それと
    も用法に問題があるのでしょうか？
 
　　　2536 <--    1   96800  vz 1.60  -em30 -z
　　　3CD9 <--    1    3840  vz 1.60  -em30 -z          06 21 29
　　　3DCA-A000   1  402272  <free>
 
　◎ファイル名入力窓で、すでにファイル名＋スペースを入力した状態で
    ヒストリーをさかのぼると、「->17EE」のようなものまで単独で再現
    されてしまいます。
 
　○ファイル名入力窓のための仕様だと思いますが、カーソルの直前がス
    ペースのとき、文字列ヒストリー中のすべての文字列が再現されてし
    まいます。コマンドラインも文字列入力窓も共通。この動作を、ファ
    イル名入力窓に限定することはむずかしいですか？
 
　○Ds+ で表示される文字コードが、^M で 0D0Ah になります。ちなみに、
    0ah のときは問題ありません。
 
　○^M が[EOF]に‘吸収’されてしまいます。例えば、ファイルを新規に
    開いて「123^M456」と入力しても「123456[EOF]」としか表示されず、
    ファイルには「123456^M」のように順序が狂った形でセーブされてし
    まいます。
-------------------------------------------------------------------
 これだけあるんだもの。(^^;

>  ◎常駐-解放-常駐を行うと、解放したはずの VZ が居座っていることが
>    あります（再現条件不明）。これは VZ 側の問題でしょうか、それと
>    も用法に問題があるのでしょうか？

この現象、最近 MS-DOS Player + FreeCOM 環境で起こっています。VZの版は関係ないかも。
普通、常駐解除すると、プロンプトカーソルがアンダーラインのようになるのに、そうならない時があるのです。
その時に一度 [ESC] を押すと、^[ と出て、常駐解除出来たのかと思いますがもう一度 [ESC] を押すと、VZの入力窓が出るのです。
割り込みベクタの書き戻しとかが上手くいってないのかなぁ。

> 　ただ、filter.defは、似たようなことをしてたわけですよ。

同じかわかりませんが、手持ちの filter.def にはこんなルーチンがありますね。

10:	; overwrite
	(fb)? {
		ek[+,
		#W xc[, #y
		#W #^ #< #i #b #_ #y #^ #<
		#W #b #i r], (r==-1)? #B
		ek],
		(0)

なんだか　[ESC]i マクロによく似ていますね。
#B も使っているし、もしかして xc[, を　r], に戻してその値で #B 使っている？
確か、xc もバグがあったような。
これは怪しいですね。どうでしょ　＞めざらさん

　はい、そうなんです、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の亡者ですから。

> 確か、xc もバグがあったような。
> これは怪しいですね。どうでしょ　＞めざらさん

怪しいというわけではないのかと…。xc の件は，バグと言うより仕様だと思いますが，
マニュアルに警告が書いてないのでバグ扱いが妥当かもしれませんけどね。
（一応，cp と tblkp とあるけれど，それだけだとソース読める人とかが対象）

なお，filter.def マニュアルには，「64KBをこえる大きなブロックは扱えません。」と
明記してあるので，ローカル 10: のルーチンが巨大ブロックに対応していなくても
それは仕様であってバグではありません。もちろん VZ のバグとの関係もありません。

#i の戻り値を xc の値で上書きしているのは，その振る舞いを見越しているわけで，
これまた VZ マクロらしい無駄のない動作だと思います。

・ブロック処理は，下から上に向かったブロック(xc==-1)の方が速度的に有利
・その場合でも処理後のカーソル位置をテキスト末尾に移動
…という感じかなぁ…
そのへんは，改造するほど入れ込んでいる文太さんに聞いた方が的確かと。

　特に何も聞かれてないと思いますが。
　何もできない、ほぼ何も考えられない（知識が足りない）という感じですが。

　（１）原因は、vtdosか、vz.comか、filter.defか。？？？　どれも可能性あり。
　（２）＞filter.def マニュアルには，「64KBをこえる大きなブロックは扱えません」
とあり、
　これは、xcの件。しかし64KBを超えるファイルでテンポラリーファイルとかテキスト
バッファが絡んだら？　これは、きっとvz.comがらみの事柄。
　（３）こういう場合、経験とか実体験とか統計的に無意味だろうと思いますが、
それでもいまのところWinMEでは経験していない（と思う）。

　とにかく、(1)としきログ、(2)clppestがらみ、(3)filter.def文太がらみ
では、(3)に圧倒的に発現条件についての情報が足りません。再現できません。
　さらに、この３つがどれだけ重なった、関係した事態なのかも分からない、、、。

　新しい情報みたいにみえて、misleading な事柄でした、おそらく。

　他意はないですが、いちおうお伝えしておくと、（僕の読解力のせいだろうと
思うのですが）、(2)について、僕は何の話だかまったく分かっていません。

> 　とにかく、(1)としきログ、(2)clppstがらみ、(3)filter.def文太がらみ

> (2)について、僕は何の話だかまったく分かっていません。

ごめんなさい。不具合の発生したファイルを提供したので，細かな手順などはすべて
端折ってしまいましたから，わたしと konno さん以外は見えなくて当然です。

せっかくだから補足しますと，自分のコンテンツで「ラジオドラマ資源」なるものが
ありまして，これの一年単位の番組基本情報ページがあるわけです。1950年代は
わりとラジオドラマの放送が多くて，それなりのサイズのテキストになります。
先日のファイルが 300KB 弱で，2,100行強，ラインバッファを超える1行はありません。
この一年分のデータは，スプレッドシートで複写した TSV で，クリップボードに転送。
このとき手作業でファイルに落とすことなく，愛用の clppst を使って貼り付けます。
そして，貼り付けたタイミングでエラーが発生したわけです。300KB 弱ありますから，
当然，巨大ブロックを挿入する [ESC]I と同様のマクロコードが clppst.def にあります。

具体的に，上記の手順でした。
再現条件は EMSを使用，clppst.def 実行，64KBを超えるテキスト，です。
としきファイルと異なるのは，ラインバッファを超える行がないこと。たぶんそのくらい。
（↑ これ，ウソです。としき兄のご指摘（#10703）がありました。）

> としきファイルと異なるのは，ラインバッファを超える行がないこと。

めざらさんの提供されたファイルの一番長い行って、何バイトくらいですか？
私の提供したファイルでは、確か7000バイトに満たないくらいだったはず。
そして私の場合、Blは8192に設定してあって、ラインバッファを越えていないはず
なのに異常動作が発生したという認識です。
この辺、何か私の認識誤りか確認ミスがあったかな。
いまになってそういったことが発覚したとなると、かなり困ったことです。

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

わたしのファイルだと，急拵えしたこんなマクロで 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 の時も実行させる必要もなさそう
ですから）。

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

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

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

みなさん BL8192 でお使いのようですね。
過去の [ESC]i マクロでとしきデータの行長は BL8192 以下でしたが、CPズレでブロックが入れ替わったという記憶が。
EK- で #B を繰り返し使うと CP ズレが起こることがある、と私は感じました。
今は BL8192 でも安心できない気がするので、検証を続けているのです。
バグが特定できれば回避して運用するのは可能だと思うので、みなさんの情報が頼りです。

VTDOS BBS で、10＃さんからのお知らせがありました。

> 原因が判明したので遠からず修正可能です。
> リリースまでもう少し頂きます。

うれしいです。＼(^^)／ ﾔｯﾀ-
ありがとうございます。
気長にお待ちしています。

みなさまにお願いがあります．掲題のとおりの検証です．
各人の環境で以下の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 番マクロ、シフトに問題あり。よって前発言の調査となりました。

see #10541 
　いえいえ、
>VTDOS Version 1.53 Copyright (C) 2009-2017 by 10#  Build[Sep  5 2017]

　最新版でした。バーアップしたんだった。
　で、新版が来ると。ＥＭＳがフィックスされて、もしかしたら、ほぼ１年越し
の問題が解決されるかもしれないと。イエイ！　そしてまたまた新しい問題が
見つかると。ふにゃ。

konnoさん

　情報、ありがとうございます。
　ただ、古いですね。32KB 近辺のバグは除去されていると思しいです。
　で、マーク４バイトＸ２で対策しようかとも思っているのですが、昨晩
深みにはまってしまい、、、。
　僕以外気にしてない、そして、本当の原因はここじゃない、というあたりで
逃避行動に出ています。

　とにかく、情報多謝です。当たり前でしょうけれど、ロングの比較は、
高橋版（榊原版）から、符号なしに統一されフィックスされているはずです。

　すべてのテストを正常にパスしました。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を優先にするオプションとかあったかなぁ。

konnoさん

　以下は、普通に行きますか？

=== Macrotmp by B ===;
* M

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

*

> 　ただ、古いですね。32KB 近辺のバグは除去されていると思しいです。

高橋さんが直してくれてたんですか、ありがたいですね。
あとは、#B を繰り返し使うと CP がズレたりするのではないかと私は疑っています。
#B を使わないようにマクロを修正できれば安心できるのですが。

> 　で、マーク４バイトＸ２で対策しようかとも思っているのですが、昨晩
> 深みにはまってしまい、、、。

すみません、余計なことを言ってしまったようで・・・

> 　以下は、普通に行きますか？
> 36 ^C "" ?. k=ks&1, (k)?{ &m("shift") } ?{ &m("non-shift") } .
> 36 ^E "" ?. k=ks&1, (k)?{ &m("shift") } ?{ &m("non-shift") } .

はい、VTDOSで普通に表示されます。
文太さんのところでも問題ないですよね？
やはりカッコに入れると上手く動かないんですかね。

STKHLP にありました。

>　※常にその時点のキーの状態を示すため、SHIFT 押下げで動作を
>　  変更するマクロでは、最初に k=ks&1 のように保存しておく。

やはりこのほうが確実ということでしょうね。

konnoさん

　あっちの結果報告を待っています。m(__)m
　ちょっとビックリしたので。

（xc について）
>高橋さんが直してくれてたんですか、ありがたいですね。

（ロング関数について）
--- vzt.doc ---
  ◎榊原版Ｖｚより移植
●&Lc・&Id のバグ修正。また、全ての long 演算を符号なしに統一しました。
---------------
　少なくともこっちは、榊原さんですね。
　xc については、32KBは初耳で（現象確認できず）、64KBは、めざらさんが
仰っていたとおり、「仕様」でしょう。対策法も確立してるし。
　高橋さんのvzt.docには記載なし。

>あとは、#B を繰り返し使うと CP がズレたりするのではないかと私は疑っています。
　マクロイドとしては、これは困るんですよねぇ。2023年になって、まだこんな
ことを言ってる、、、。としきさん事例ですよね。あれは何なんだろう？

>#B を使わないようにマクロを修正できれば安心できるのですが。
　それは、たぶん、ほぼムリ。本質からずれますが、僕は、ブロックを下からした
ことなんてほぼないのです。すると、ほぼ自動的に、#B する。

>> 　で、マーク４バイトＸ２で対策しようかとも思っているのですが、
>すみません、余計なことを言ってしまったようで・・・

　いえいえ、konnoさんにしては珍しく、他人（ひと）のお尻を叩いている。
　はい、叩かれてるなぁ、という自覚はあります。
　が、暇をみつけて、他のマクロをやってます、、、。オレ、かなり頭が悪いらしい
という自覚がふつふつ。場合分けができない！

konnoさん

>文太さんのところでも問題ないですよね？
　あります！

>やはりカッコに入れると上手く動かないんですかね。
　k に保存してもダメです。

　あいかわらず、^\E では、秀丸です！
　まいったぁぁぁぁ。

　僕のところでは（vtdos環境）、^\C と ^\E だけなので、それを避ければ
いいのですが。何だか、奇妙な制限のつく環境になってるなぁ。

> シフトチェックは変数を介したほうが確実とどこかで見たような気が。

うーん，でも，押しっぱなしなのに ks が変わらないとしたら変ですよね。
右シフトとか左シフトとかも何かあるのかなぁ……


to Filer の方は，版とは関係がなさそうで，いよいよ闇の中です。
確かに外部マクロに切り出すと問題がなかったりするのに，
内部マクロとして記述すると「動かない」ではなく「変な動き」。

記述の場所を変えてみるとかしてみるか……
ありえないとは思いつつも，前後の改行コードが変だったりして。

きゃー！　うちも [Shift][Ctrl]E でコンソールファイルみたいなテキストファイルが
notepad(メモ帳)でオープンされたし。うわー，コマンドラインでやったことが全部ある。
ぜんぶ見えてるの，恥ずかしー。(笑)
これ VTDOS の隠しコマンドか何かでしょうかね。

^C は両方とも non-shift だと思ったら，直前のメッセージがそのままっぽいです。
k=ks&1, &t としてみたら，トレースにも入らないです。つまり，無効キー。
^E も同様にしてみたら，やはりトレースする前に例のテキストオープン。

> これ 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さん、私はそこまで気が回りませんでした。
私の VTDOS.CFG は
NO_BACKLOG=1
このように、バックログ機能を無効にしていたので気が付かなかったのですね。(^^;

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

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

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

shadowさん、めざらさん、

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

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

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

　ゴミ・シリーズ、お気に入りみたい。

>「カレント」を編集画面で確認するのか？

--- vz.def ---
* T テキストウィンドウ
"Open File: <$pd> [Now $wc]",76
--------------

　と設定してあると、ファイル・オープン窓の上に見えますね。
　#O で、リターンでやっぱりそのままファイラに行っちゃいそうですけど。
カレントを調節するために。ぐるぐる、ぐるぐる。

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

VTDOS での値ですか？

> = ksmiru.def =

これいいですね。
　　　　　　　　無入力　左シフト　右シフト
VTDOS　　　　　 32　　　35　　　　35
MS-DOS Player　　0　　　 3　　　　 1
DOSVAXJ3　　　　32　　　35　　　　33
Win98ME DOS窓 　32　　　35　　　　33

私の環境ではこうなりました。
これは、純DOS と Win窓環境の違いでしょうか。
VTDOS だけ左右が同じなんですね。仕様なのでしょうか。
実用上問題は無いですが、気になりますね。

そういえば、VTDOS環境になってから、(ks&3)? が上手く動かなくて、変数に代入するようになったような。
VTDOSは、(KS&3)? ではシフトチェックの値取得が上手くいかない時があるのでしょうか。

この辺、ダメもとで 10＃さんにメールしてみようかな。

[ESC]i マクロの検証では、EK- で BL3072 の時は、全ての環境で NG になりました。
EK+ で BL3072 の時の挙動を確認したら、10＃さんの環境が再現出来たようです。

VTDOS+高橋版VZで EMS環境で EK+, BL3072 の時、正常処理されました。
[F02]の後の比較マクロで6か所相違が出ます。修正VZでは一致します。
これは、XMS環境でも同じでした。

オリジナルVZでは、EMS環境でも XMS環境でもラップアラウンドエラーで、VZが落ちます。

MS-DOS Player と DOSVAXJ3 では、EMS環境でも XMS環境でも NG になりました。
試した全てのVZでファイルサイズが増える同じ壊れ方でした。

EK+ で BL3072 の時 VTDOS だけが正常処理されるとは、ビックリです！ (ﾟﾟ;)


＃　このあたりに時空の歪みの境界があるのでしょうか。(@.@)

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

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

　　　　　無入力　左シフト　右シフト
VTDOS　　 0 　　　3　　　　 3
所期の値　0　　　 3　　　　 1

> この辺、ダメもとで 10＃さんにメールしてみようかな。

ホットキーの事例もあることだし，まずは皆さまのコメントを待ちましょうか。(笑)

> 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$からのキーイベントで、シフト状態もこれから生成しています。
>これはキューイングされたイベントなのでリアルタイムなシフト状態という訳ではありませんが、
>概ねリアルタイムな物となります。
>このキーイベントの仕様としてシフトだけが何故か左右の区別がありません。
>この仕様に則った場合、コンソールでの貼り付けが利用可能になります。
>貼り付けをサポートするのもこの仕様を採用する理由ですが、貼り付けの仕様上、
>シフト状態がリアルタイムな物である事を保証するものではありません。

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

　無意味な報告ですが。WinAPI の仕様。うーん、この手のことまで
処理してくれるＡＰＩがあるものなんだ、、、。

　　　　　無入力　左シフト　右シフト
VTDOS　　　0 　　　3　　　　 3
WinME　　　0　　　 3　　　　 1

　でした。上はめざらさんのほぼ丸写しですが、実験はちゃんとしてます。

ファイル名に = が入っていると変な現象が起こります。
例えば
windowsで abc=.txt のファイルを作成
VTDOS で dir すると
abc=.txt 問題なし
vzを起動しfilerで見ると
abc_~1.txt
上記の表示になります。
Rename と ロングファイル名表示は問題ありません。
ショートファイル名で = の箇所が _~1 の表示になります。
全てのVZで同じことがおきます。
皆さんの環境ではどうなんでしょうか？

> 　無意味な報告ですが。WinAPI の仕様。うーん、この手のことまで
> 処理してくれるＡＰＩがあるものなんだ、、、。

必ずしもDOSコールの上位互換ではないというところが、痛しかゆしですよね。(^^;

> 　　　　　無入力　左シフト　右シフト
> VTDOS　　　0 　　　3　　　　 3
> WinME　　　0　　　 3　　　　 1
> 　でした。上はめざらさんのほぼ丸写しですが、実験はちゃんとしてます。

確認頂きありがとうございます。やはり同じですね。

> ファイル名に = が入っていると変な現象が起こります。

'=' は、ショートファイル名に使えない文字なのではないでしょうか。
純DOSエミュのNP2 で試すと、無効なパス名と怒られます。

これだけでは何なので、ネットで検索すると
http://elm-chan.org/docs/fat.html#lfn
こちらのサイトから引用すると
-----------------------------------------------------------
短いファイル名
短いファイル名では、8バイトまでのボディとオプションのドット(.)+3バイトまでの拡張子に制限される、いわゆる8.3形式のファイル名が使用できます。
パス名のトータル長は、3バイトのドライブ文字 + 64バイトのパス + 12バイトのファイル名の合計79バイトとなります。
ファイル名を構成する文字は、ASCII英数と一部のASCII記号$%'-_@~`!(){}^#&および拡張文字(非ASCII文字)の任意の組み合わせが可能です。

長いファイル名
LFNでは、255文字までのファイル名が使用可能です。
使用可能な文字は、SFNで使用可能な文字全てに+,;=[]が加わっています。
ドットはファイル名の中にいくつでも含めることができ、スペースもファイル名の任意の位置に挿入することができます。
ただし、ファイル名の末尾に来るドットやスペースは無効で、API入力の段階で除去・無視されます。
ファイル名の先頭に来るドットやスペースは有効ですが、UIによっては(たとえばWindowsコモンダイアログ)これらのファイル名を入力できません。
LFNエントリには、大文字変換は行わずに入力のままの形のUnicode(UTF-16)文字列として格納されます。
-----------------------------------------------------------
このように書いていました。

各種DOSエミュでは、'=' があるとロング名として扱っていると思われます。

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）

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

konnoさん

　深追いしてもしょうがない話ですが。

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

　というのを見ると、そのＡＰＩ、Ｃ＋＋か何かで書きなおせるん
だろうな、とか空想しました。
　MSDOSPlayer, DOSVAXJ3 の作者さんも、そのＡＰＩを使ってますよね、
きっと。
　それより、上の調査、ありがとうございました。VTDOSしか使わない
にしても、他のエミュとの比較は有効ですね。自分ではしないのだけど、、、。
たしゃぁ〜　m(__)m

小文字で abc だからかな？と思い，エクスプローラで大文字の ABCD=.txt を作り，
確認したところ，ABCD_~1.TXT と表示された。あ，拡張子が小文字だった，と思って，
同様に ABCDE=.TXT を作ったところが，やはり ABCDE_~1.TXT と表示された。

という状況となりました。
これは，すごく古い vzk（例えば vzk5 とか）で同様になりますね。

「=」の制限は，cmd.exe にあるくらいで，ファイル名としては制限ないようです。

色々調べていただき有難うございます。

> 使用可能な文字は、SFNで使用可能な文字全てに+,;=[]が加わっています。
私が調べた使用可能な文字はLFNの方だったようです。
早とちりしていました。

> 　でも、なんでまた、そのような冒険を？
> 　ほんとに必要なのですか？
と聞かれれば必要じゃないです。
興味本位です。

ブラウザで調べた情報をコピペしてエディターで一時保存しています。
保存するときに１行目がファイル名になるのでそのまま保存しているのですよ。
たまたま=が含まれていたのです。
清書のためVZで開くときに気づいたのでした。

> 「=」の制限は，cmd.exe にあるくらいで，ファイル名としては制限ないようです。
VTDOS.CFG設定のUSECMD=0|1
 ビルトインコマンドの実行にCMD.EXEを利用します。とありました。
USECMD=0 に設定すると
VZの新規ファイル作成で abc=.txt を作ると
dirでもABC_~1.TXTと表示されました。
エミュレーターの仕様であることがわかったので良しです。

shadowさん

　すばらしいですね！
　うん、LFN <-> SFN の話でなく、その情報管理システム。
　ワードですよね、１行目がとりあえずのファイル名になるの。
　そして、「一時保存」と「清書」のシステム。
　いやあ、何度も同じこと、グーグル先生にお聞きしておりますなぁ、という
場面はたしかにあり、どんどん消失してゆく記憶力にもかかわらず、道具立てで
解決にのぞむ根性にかけておりました。
　がんばります！

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


--- （１）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

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

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

そうですね。要するに，文太さんがおっしゃるとおり，空白入りファイル名と同様に
コマンドラインでは引用符で括らないとダメという話でしたね。直接の関係なし。

事故？

皆さん盛り上がっていますね。
私もまとめ的に、エミュ三種の盛り合わせを。(^^;
各種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 では新規作成できません。

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


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

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

>事故？

 (1)　昨晩のテストに間違いが含まれていた。
 (2)　削除されためざらさん宛のレスに「cmd.exe、変？」「たしかに変ですね」
　　　というのが含まれていた。

　そんな事故でした。

>私もまとめ的に、エミュ三種の盛り合わせを。(^^;
　あはははは。得意技！

>ショート名なのに "=" 表示になっています。
>これは、作者様に、別件でメールしました。
　僕は「仕様」でもいいんじゃない？　と思いました。エミュ作家も
ほんと大変ですよね。
　僭越ですが、「konno組には仲間がいます」アピールにはなりますかね。
　ならんか？！

> >私もまとめ的に、エミュ三種の盛り合わせを。(^^;
> 　あはははは。得意技！

これはマジな話、このエミュ三種で問題なくVZが動かないと滅茶苦茶悔しいから。(^^;

> 　僕は「仕様」でもいいんじゃない？　と思いました。エミュ作家も
> ほんと大変ですよね。

私なら仕様にして逃げたかもですが、プロはその辺妥協せずキッチリやりますからねぇ。(^^;

> 　僭越ですが、「konno組には仲間がいます」アピールにはなりますかね。

これは大いに感じています。この1年の間でVZだけでも
としきさんは、[ESC]i マクロの問題提起し、それがきっかけで VZのバグをあぶり出せましたし
めざらさんは、同様の問題を ClpPst.def で提起し、それがきっかけで 10＃さんにメール出来ましたし
文太さんは、「zp ってなに？」という問題提起し、それがきっかけで WinNT系の問題解決出来たかもだし
shadowさんは、ファイル名の "=" の問題提起し、それがきっかけで DOSVAXJ3の挙動が発見出来ましたし
よくこれだけ問題発見出来たものですね。(^^;

これらはいずれも私一人では解決できないことばかりでした。
みなさんの問題提起と沢山の検証のおかげで化学反応が起きたようです。
私はみなさんに導かれてか、引っ張られてか、やっとこさ先に進むことが出来たように思います。
何ミリかもしれませんが。

　ムダに長文になりました。

>>私もまとめ的に、エミュ三種の盛り合わせを。(^^;
>これはマジな話、このエミュ三種で問題なくVZが動かないと滅茶苦茶悔しいから。(^^;
　「滅茶苦茶」に実感がこもってますね。いいです！
　助かってます！

>私なら仕様にして逃げたかもですが、プロはその辺妥協せずキッチリやりますからねぇ。(^^;
　あ、勝手に決めてる、、、。

>文太さんは、「zp ってなに？」という問題提起し、それがきっかけで WinNT系の
>問題解決出来たかもだし
　えーと、うーんと、、、。それはよかった、とにかく。
　ではありがたく、クレジットだけいただいておきます。スワップさせなければ、
不安定ではないような気もしますが。
　ただ疑問は、なぜそんなものに変数名を与えて外に出したのだろう？　という
こと。マクロから状況を見るため？　書き換えに失敗したら落ちると思うんですけどね？
そうでもないのかな？

　そういえば、数日前に思ったのですが、vtdos自体は、最近おちていません。
　なんだろう？　最新版にしたのがよかったのか？　vtdos.cfgがうまくはまったのか？
　あんまり使ってないからかなぁ？　(｡oﾟ)☆＼ﾊﾞｷ

>これらはいずれも私一人では解決できないことばかりでした。
　とはいえ、最後の（最初と途中もかもしれないけど）一押しはkonnoさんです！
　元に戻って。でも、エミュ作家だって、ユーザさんから反応がときにはあって
嬉しいものなのかもしれませんね。作って公開したら、やっぱ使って欲しいでしょうし。

>何ミリかもしれませんが。
　マジな話。
　体調に不安をかかえ（思い過ごしだろう）、残り時間のことをけっこうよく
考えています。そして、幸福とは何か、と。青年みたいに。
　で、出た結論は、自分の成長です。進化です。これ以上の、これ以外の幸福はない
な、と。ですから、１ミリでも２ミリでも前進は前進。幸福です。

　しっかし、1993年（僕のばあい）に発売になったエディタに2023年になって、
その環境を含め、まだこだわっている人たち、、、。あ、今年の12/6、３０周年！
　幸せな人たちだ。モノを大事にする人たちだ。
　でも、天才の作品なんだもの、しょうがないじゃん。

　富士通 biblo WinMEノートのcmos電池が切れ始め、本格的にバラして交換する
しかないぞ、と算段をしています。デスクトップはその点、簡単。

　その後。SFNでファイルに「=」を「仕様」としてエミュレータが許すという
ことについて、つらつらと考えています。やっぱダメですね。作者は直すでしょう。
だって、そのファイル、SFNしか扱えない環境（ＤＯＳですね）では、、、どうなる
のでしょう？　たとえばUSBメモリにコピーされたそのファイルをＤＯＳで開こうと
したら。かなりナイスな発見だったかもしれませんね。
　純ＤＯＳな環境をお持ちの方が、世間にどれだけいるか分かりませんが。
　もっともエミュ作る人は、持ってそうですね。

konnoさん

　えと、簡単なテストだと思うので、やってみていただけますか。
　まだ、つらつらしてるのです。
　清十郎のチュートリアルをざっとまた眺めてみたのですが、SFNとLFNの関係
というものがよく分からなくて。

>　その後。SFNでファイルに「=」を「仕様」としてエミュレータが許すという
>ことについて、つらつらと考えています。やっぱダメですね。作者は直すでしょう。

　この辺りの件なのですが、DOSVAXJ3で、「a=b.txt」を作る。
　vtdosのファイラで、lf+ で、このファイルを見てみる。
　こんな実験です。

　いちおう混濁したまま書いてみると、
「a=b.txt」はLFN、これのSFNが「a_b~1.txt」（エイリアス）。これが正規の仕様。
　vtdos（LFN対応）で、「a=b.txt」を作れば、上の関係のまま表示される。
　「a=b.txt」がSFNとして作られたら、どうなる？

　こんな感じです。「a=b.txt」がSFN扱いだと、LFNも同じものになると思う。
でも、「a=b.txt」(SFN)なんてのは、DOSVAXJ3以外では許されないと思う。

　どうなりますでしょうか？　「ファイルがない」「ファイルが見えない」「存在が
確認できない」なのかなぁ、と思っているのですが。

> 　この辺りの件なのですが、DOSVAXJ3で、「a=b.txt」を作る。
> 　vtdosのファイラで、lf+ で、このファイルを見てみる。
> 　こんな実験です。

#10747 で konno さんは言いました。

> ファイル名に "=" を使うと、他のエミュではロング名として作成されますが、
> DOSVAXJ3 では新規作成できません。

 　「a=b.txt」がSFNとして作られたら、どうなる？
> 　こんな感じです。「a=b.txt」がSFN扱いだと、LFNも同じものになると思う。
> でも、「a=b.txt」(SFN)なんてのは、DOSVAXJ3以外では許されないと思う。

#10736 で konno さんは言いました。

> '=' は、ショートファイル名に使えない文字なのではないでしょうか。
> 純DOSエミュのNP2 で試すと、無効なパス名と怒られます。

DOSVAXJ3 で '=' をショートファイル名に使おうとすると、これと同じになるということです。
おかわりいただけたでしょうか。

DIR でショート名に "=" が表示されたのは、バグだと思われます。

#10751
> 　その後。SFNでファイルに「=」を「仕様」としてエミュレータが許すという
> ことについて、つらつらと考えています。やっぱダメですね。作者は直すでしょう。
> だって、そのファイル、SFNしか扱えない環境（ＤＯＳですね）では、、、どうなる
> のでしょう？　たとえばUSBメモリにコピーされたそのファイルをＤＯＳで開こうと
> したら。かなりナイスな発見だったかもしれませんね。

ここでは、なるほどなぁ、と思いました。(^^;


＃　もうおなかいっぱい。(^^;

konnoさん

　すいません、すっかり混乱しました。

--- 引用です ---
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 では新規作成できません。
----------------

　DOSVAXJ3は、少なくとも F_Create において純ＤＯＳなんですね。
　だから作れない。
　上の表示自体がおかしいんですね。
　なんか迷宮に入ってしまいました。純ＤＯＳでは、「+,;=[]」はファイル名に
使えない。最初の定義どおりですね。
　作者さんは、ぜったい直しますね。右のLFN表示はあるのですから。

konnoさん

　ちょうど入れ違いました。

>DIR でショート名に "=" が表示されたのは、バグだと思われます。

　はい、賛成です！

>＃　もうおなかいっぱい。(^^;

　すいませんです。お手数をおかけしました。

> 　DOSVAXJ3は、少なくとも F_Create において純ＤＯＳなんですね。
> 　だから作れない。
> 　上の表示自体がおかしいんですね。

だいたい合っていると思います。
あらためて確認してみたら、DOSVAXJ3 で新規作成は
DOSV=.TXT	NG
"DOSV=.TXT"	NG
'DOSV=.TXT'	NG
DOSVAXJ3=1.TXT	NG
1234567890.txt	OK	LFN作成成功

どうやら文字コードの範囲の問題のように思います。「+,;=[]」は全てダメみたいです。
修正版はもうすぐアイドルになって登場すると期待しています。(^^ゞ

#10755
どうやらおかわりはなしだったようで。(^^;


＃　最近は少食なので、一杯で充分なのです。(^^;

DOSVAXJ3 が build JP230403　(2023/4/3) に更新されました。

サイトから引用します。
-----------------------------------------------------------
build JP230403　(2023/4/3)

・ int 21h ax=7160h で末尾に \ があるパス名が渡された場合、返されるパス名の末尾に \ が付いていなかったのを修正しました。
・ int 21h ax=7160h cl=00h で返されるパス名が "" で囲われていたのを修正しました。
・ DOS の標準入力で Raw mode が設定できるように修正しました。
・ DOS の標準入力のキー入力待ち時に int 28h を呼び出すように修正し、int 28h, int 2fh ax=1680h といったアイドル割り込みで HLT を実行し CPU 使用率を下げるように修正しました。
・ ロングファイルネーム有効時に +,;=[] が入った名前のファイルやディレクトリが使用できなかったのを修正しました。
・ Windows 上で x64 ビルドを追加し、64bit 版の実行ファイルを提供開始しました。
・ このバージョンから Windows 版は Visual Stdio 2022 でビルドしています。

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

作者様からメールでお知らせ頂き、気が付きました。
サイトは見ていたのですが、更新ボタンを押すまで更新されなくて気が付きませんでした。(^^;

簡単な動作確認をしましたが、ばっちりです。
32ビット版と64ビット版は DLL が違うので別フォルダにするのですね。(^^;
dosboxj.conf の設定で

cycles= auto 50000 100% limit 100000

くらいが一番スムーズですが、特に64ビット版はサクサクで最高です。！！ ＼(^^)／ やったぁ

あと、設定の追加として、[dos] セクションで

lfn_space=true
idle=true

を追加しています。

個人的に一番嬉しかったのは、アイドル対応です。＼(^^)／ ﾔｯﾀ-
スピードアップと負荷低減を両立出来ました。＼(^^)／ ﾔｯﾀ-

色々対応いただき、本当に感謝です。m(__)m

#10588 の続きです。
記事で書き忘れていたのですが、ソースを見なおしていて思い出しました。
先のソースは前半で、後半の処理ルーチンが漏れていました。

dos.asm 1249行あたり
	mov	ax,cs
	cmp	byte ptr cs:os_win,5	; ##k 230225  NT系コマンドライン不具合対策
	je	winnt5			; ##k 
	tstw	es:[mcb_psp]		; ## この２行が		2010-2-10
	jz	chkmcb9			; ## 不要と思われる	by 10#
winnt5:	cmp	es:[mcb_psp],ax
chkmcb9:pop	es
	ret
checkmcb endp

ソースを公開した後にコメントを追加しているもので、見落としていたのです。(^^;
WinNT系なら2行をスキップするように変更したのですが、その2行に 10＃さんのコメントが。(^^;
当時の記事を引用します。

-----------------------------------------------------------
#4999： Re^5: VTDOS v1.22 で分割画面で異常 投稿者： 10# 　 2010/02/10(水) 00:59

F_REALLOCが未割り当て領域エラーを返した場合の処理は省略されている模様。
検査用のローカルサブルーチンcheckmcbをレビュー。

該当箇所・DOS.ASM 1250付近
> checkmcb proc
>         push    ax
>         dec     ax
>         mov     es,ax
>         mov     al,es:[mcb_id]
>         cmp     al,'M'
> _ifn e
>         cmp     al,'Z'
>         jne     chkmcb9
> _endif
>         mov     ax,cs
>         tstw    es:[mcb_psp]	; ## この２行が
>         jz      chkmcb9	; ## 不要と思われる
>         cmp     es:[mcb_psp],ax
> chkmcb9:pop     es
>         ret
> checkmcb endp

呼び出し仕様「割り当て済みチェック」に対して、
「未割り当てを含む有効なMCBチェック」であることが判明。
この論理ではexpandfarが空き領域に対してF_REALLOCを
呼び出しうるため、不具合であると仮定。
問題箇所をコメントアウトしてVZをリビルド。

パッチ済みのVZで追試を行いました。
結果、SW3の時に画面分割を行っている場合は再現しましたが、
それ以外の場合は改善されている様子です。

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

このように、2010年当時に10#さんは既にVZの不具合部分を特定していたようなのです。
私はそれを忘れていて、たまたまWinNT系対策のためにそこをスキップさせたのでした。
恐らくそこの2行をコメントにしても問題ないどころか改善されていたかもしれないと思われます。

やっぱりプロのプログラマーは凄いですね。
10#さんはじめ、みなさまに感謝です。m(__)m

DOSVAXJ3 が使いやすくなったので、複数の画面サイズを活かして、表示行数切替えマクロを作りました。

80 ^KL "表示行数切替え" 
#if AXJ3	; DOSVAXJ3
;  (s==2 && oy==28)? { &00 .}			;コマンドラインでsxga24の29行→VGAの25行
  (s==2 && oy==43)? { &00 .}			;コマンドラインでsxga24の29行→VGAの25行
  (s==2 && oy<=24)?{ &01 .}  			;コマンドラインでvgaの25行→VTの37行
  (s==2 && oy==36)?{ &02 .}  			;コマンドラインでVTの37行→VT2の44行
;  (s==2 && vp.6==122)?{ &03 .}  		;コマンドラインでVT2の44行→VT3の44行
;  (s==2 && vp.6==154)?{ &04 .}  		;コマンドラインでVT3の44行→VT4の29行
;  (s==0 && oy==28)?{ #E &00 wd80,#[ we80,&d .}		;編集モードでsxga24の29行→vgaの25行
  (s==0 && oy==43)?{ #E &00 wd80,#[ we80,&d .}		;編集モードでsxga24の29行→vgaの25行
  (s==0 && oy<=24)?{#E &01 wd100,#[ we100,&d .}		;編集モードでvgaの25行→VTの37行
  (s==0 && oy==36)?{#E &02 wd128,#[ we128,&d .}		;編集モードでVTの37行→VT2の44行
;  (s==0 && vp.6==122)?{#E &03 wd160,#[ we160,&d .}	;編集モードでVT2の44行→VT3の44行
;  (s==0 && vp.6==154)?{#E &04 wd106,#[ we106,&d .}	;編集モードでVT3の44行→VT4の29行
  (oy==43)?{ #E &00 #[ wd80, .}				;sxga24の29行→Vvgaの25行
  (oy==28)?{ #E &00 #[ wd80, .}				;sxga24の29行→Vvgaの25行
  (oy<=24)?{#E &01 #[ wd100, .}				;vgaの25行→VTの37行
  (oy==36)?{#E &02 #[ wd128, .}				;VTの37行→VT2の44行
;  (vp.6==122)?{#E &03 #[ wd160, .}			;VT2の44行→VT3の44行
;  (vp.6==154)?{#E &04 #[ wd106, .}			;VT3の44行→VT4の29行
  .
00:	&?("chev jp") #m oy24,			; vga     解像度  640× 480  文字  80×25
01:	&?("chev vt") #m oy36,			; svga    解像度  800× 600  文字 100×37
02:	&?("chev vt2") #m oy43,			; xga     解像度 1024× 768  文字 128×48(44)
;03:	&?("chev vt3") #m oy43,			; sxga    解像度 1280×1024  文字 160×64(44)
;04:	&?("chev vt4") #m oy28,			; sxga24  解像度 1280×1024  文字 106×42(29)
#endif


これで起動のたびに 80×25行と100×37行と128×44行をトグルします。
編集モードでは、WE の編集幅が変わらないので、コマンドラインで実行が良いです。
128×48行では、実画面を下にはみ出るので、KVZのオプション OY43 指定して、行数44行にしています。
KVZのオプション OY は、DOSのローメモリの行数を書き換えているだけなので、行数-1 を指定します。

DOSのローメモリの行数を書き換えるなら外部コマンドを作れば良さそうですが、ちょっと待って。
マクロのコメントに、VT3 とか VT4 がありますね、これは・・・

＃　これはシャー専用機専用で、ザクには使えないとかなんとか・・・

＃　そうしているうちに、下半身の無いジオングが完成したとかなんとか。
＃　（使わなない）足なんて飾りですよ。偉い人にはわからんのです。（謎）


ちなみに、DOSVAXJ3 の画面モードには
sxga    解像度 1280×1024  文字 160×64(44)
がありますが、試してみたら、VZの表示が異常になりました。(>_<)
これは過去ログ検索すると

#4761： Re: VZK07t （VTDOSに捧ぐ） 投稿者： shadow 　 2010/01/04(月) 20:34

> > 　・V-TEXTでlf+の時ロングファイルネームを画面幅一杯に表示。
> > 　　縦は50行以上だと異常になりますね。

> あじゃさんに、50行越えは、オプション lc で最大行数を指定する必要があると教えていただきました。
> これを指定すると、最下行のFEPの予約ができないので、私は50行以下で使うことにしました。


そうでした、50行超えの時は、LC で指定する必要があるんでしたね、気を付けなくては。(^^;

VTDOS1.54 が更新されました。
VTDOSBBS から引用します。

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

 Version 1.54 リリースノート - 10♯　　　2023/04/08 (Sat) 20:07:38

EMSの不具合を修正しました。
これにより、VZ Editorで主に大きなファイルを扱うときに発生する問題が緩和されるようです。

また、8.3形式ファイルを作成していないNTFSに対する限定的な対応を行いました。

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

早速テストデータを高橋版VZのEMS環境で試してみましたが、全て正常でした。
VZのバグはそのままです。
私の修正版ではVZのバグも出ませんでした。（BL3702を除く）

これで、EMSメインの環境に戻して運用してみます。
SW3 でも安定するかな。

あと、CKWV9P も更新されました。最近のWin10のエラー対応のパッチのようです。

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

DOSVAXJ3 のキー入力関連なのですが
VZマクロの起動キーとしてよく使う ^\ (Ctrl+\) が効きません。
どうも、^] (Ctrl+]) のコードで起動するようです。 
BIOSコードを見てみました。

キーコード　VTDOS　　DOSVAXJ3
------------------------------
^\ (|\)　　　7D1C　　-
^^ (^) 　　　0D00　　-
^@ (@) 　　　1AFF　　1A1B
^[ ([) 　　　1B1B　　1B1D
^] (]) 　　　2B1D　　2B1C (^\)
^_ (_\ろ)　　731C　　-
^[F04〜12] 　6100〜　-
@[F10〜12] 　7100〜　-

このように、特定のコードが無かったり違っていたりしています。
dosboxj.conf の設定は
keyboardlayout = jp
yen           = false
となっていて、
yen           = true
としても変わらないようです。

Ctrl+[F01] でキーコードを変えられるかもしれないですが、まだ出来ていないです。
対応したキーマップがあればいいのかと思って他のDOSBOXから持ってきましたが変わらないようです。

システムの関係で出来ないのであれば諦めますが、駄目もとでメールしてみました。
そうしたらすぐにお返事が来ました。

>　調査してみますが、キー入力は使用している SDL というライブラリが
>日本語キーボードを考慮に入れてない関係で処理がややこしいことになっ
>ており、少々時間がかかると思います。

やはりDOSBOXは元が外国製なので出来なくてもしかたがないですね。
調べて頂けるだけでもありがたいです。

>　なお、dosboxj.conf の yen は FONTX2 フォントファイルの文字コード
>0x5c のデータを 0x7f と入れ替えるというオプションで、キー入力とは関
>係ありません。

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

別件ですが、画面の行数が可変に出来そうです。
行数を減らすのはすぐに出来たみたいですが、増やすのも出来るかもしれないです。
これが出来たらますます使いやすくなりますね。＼(^^)／ ﾔｯﾀ-


＃　ジオングに足が生えるのか　(^^;

DOSVAXJ3 が build JP230414　(2023/4/14)に更新されました。

サイトから引用します。
-----------------------------------------------------------
build JP230414　(2023/4/14)

・ 日本語キーボードで、一部のキーが Ctrl との組み合わせで入力ができなかったり、入力ができてもキーコードが正しくなかったのを修正しました。
・ V-Text のモードを 4 つまで指定可能としました。それに伴い dosboxj.conf の [dosbox] vtext は vtext1 に名称変更しています。
・ V-Text で行数を指定できるようにしました。上限はありますが、本来の行数より大きな値も指定可能です。
・ Linux も 16 ドットフォントは東雲フォントを使用するように変更しました。

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

#10761：DOSVAXJ3 のキー入力関連など
で書いたキーは、システムで予約済み以外は対応されています。＼(^^)／ ﾔｯﾀ-
予約済みの一部のキーは Ctrl+F1 の mapper でキー割り当てを変更出来ます。

V-Text のモードを 4 つまで指定可能となったのもうれしいです。＼(^^)／ ﾔｯﾀ-
コマンドラインで chev vt4 などとして簡単に画面サイズを変えられるので
大画面でも小さなDOS窓を表示させて参照するとか、結構使いそうです。

作者様に感謝です。m(__)m

地道な試用報告が報われるというのは，とてもいい関係性だと思いますね．
真摯なユーザがいるから作者様もモチベーションを保てる面があるのでしょう．

DOSBOX系も，もう少し速度が出るといいのですけどね。
裏で色々環境の読み込みとか時間がかかることは理解できるのですが，
それぞれの環境で使うものを一時ファイルに書き出しておいて次回はそれをロードする…
なんてことは難しいのかなぁ…って環境は様々だから一筋縄ではいかないのでしょうね．

ところで……
konnoさんは DOSVAXJ3 では V-text を使っていますか？　……変な言い方なのかな……
要するにフォントファイルを用意して拡張ウィンドウにしていますかということです．
一連の発言を見ると44行とか128桁とかあるので，たぶんそうなのでしょうけど，
速度はどうなのかなぁと思って．

昔の非力なマシンで V-text すると，フォントドライバーによるかとは思いますが
ひどく画面の書き換えが遅かったじゃないですか．そのへん体感はどうでしょう．

自分で試せば？ということではありますが，慣れた環境にどっぷり漬かっていると，
フォントファイルを引っ張り出してくるとかちょっと面倒になっちゃって(^_^;

> 地道な試用報告が報われるというのは，とてもいい関係性だと思いますね．
> 真摯なユーザがいるから作者様もモチベーションを保てる面があるのでしょう．

なるほど、私も人が困っているのを見ると何とかしてやりたいとつい思っちゃうんですよね。

> DOSBOX系も，もう少し速度が出るといいのですけどね。
> 裏で色々環境の読み込みとか時間がかかることは理解できるのですが，

最新の DOSVAXJ3 64ビット版は速いですよ。VTDOS と遜色ないくらいでしょうか。
dosboxj.conf の [cpu] セクションで
[cpu] 
cycles= auto 50000 100% limit 100000

これを入れてみてください。
cycles    = max
が一番速くなると思ったのですが、KVZ環境では max の設定ではタイムラグが出てもたつきを感じました。
ベストな設定値は、それぞれの環境で色々微調整すれば良いと思います。

> それぞれの環境で使うものを一時ファイルに書き出しておいて次回はそれをロードする…
> なんてことは難しいのかなぁ…って環境は様々だから一筋縄ではいかないのでしょうね．

何に時間が掛かるのでしょうか。
フルエミュレーションなので動作速度の限界はあるでしょうが、私が試した範囲では VTDOS と遜色ないと感じました。

> konnoさんは DOSVAXJ3 では V-text を使っていますか？　……変な言い方なのかな……
> 要するにフォントファイルを用意して拡張ウィンドウにしていますかということです．

フォントファイルは別に用意していません。
DOSVAXJ3 は、小さいフォントと大きい24ドットを内蔵していて、24ドットフォントだとちょっと大きいので
[dosbox] セクションで

jfontuse20    = true

これで 24ドットフォントを 20ドットフォントにしています。
実質3種類の大きさのフォントが使えることになります。

> 自分で試せば？ということではありますが，慣れた環境にどっぷり漬かっていると，
> フォントファイルを引っ張り出してくるとかちょっと面倒になっちゃって(^_^;

上記のようにフォントファイルなどは何もいらないので簡単に試せますよ。
めざらさんは 旧版の DOSVAXJ3 は動かしていると思うので、その [autoexec]セクションの内容はそのまま使えます。
ちょうど私の使用例を張り付けようと思っていたので、次の記事でデフォルトから変更追加した部分を貼り付けます。

あ、そうそう、64ビット版は私は、DOSVAXJ3.64 というフォルダにしています。
64ビット版はDLLとかも違うので別のフォルダにしないといけないので。
拡張子を使ったのはショート名でも読めるというのが理由です。(^^;

DOSVAXJ3を簡単に試すための dosboxj.conf の設定例です。
私の使用例を、以下にデフォルトから変更追加した部分を貼り付けます。

dosboxj.conf

[sdl]
windowresolution  = 1336x768
# 私の画面サイズ　これを入れると画面をはみ出す行サイズでもフルスクリーンモードが使えるかも

[dosbox]
#jfontname     = ＭＳ 明朝
jfontname     = MS ゴシック
#jfontuse20    = false
jfontuse20    = true
#               vga     解像度  640× 480  文字  80×30 (44行なら画面をはみ出さない)
vtext1        = vga,44
#               svga    解像度  800× 600  文字 100×37 
vtext2        = xga,44
#               xga     解像度 1024× 768  文字 128×48 (44)
vtext3        = sxga,44
#               sxga    解像度 1280×1024  文字 160×64 (44)
vtext4        = sxga24,29
#               sxga24  解像度 1280×1024  文字 106×42 (29) 24ドットフォント
#               xga24   解像度 1024× 768  文字  85×32 (29) 24ドットフォント
#fepcontrol    = both
#fepcontrol    = ias
fepcontrol    = mskanji

[cpu]
#cycles    = auto
#cycles    = max
cycles= auto 50000 100% limit 100000

[dos]
#automount      = true
automount      = auto
#autoreload     = all
autoreload     = cmd
lfn_space=true
#lfn_space=true	#230214 スペース入りのロング名でもオープン
#idle=false
idle=true

[autoexec]
mount c c:\
mount d d:\
C:
cd vz
path=c:\ut;%path%;
set vzdef=c:\vz\vz.def
set tmp=c:\tmp
set ASM=m
set VZBAK=.\bak
set vzsym=AXJ3
vwx -z2 -v2 -x1 -l4096
TAGLIGHT.EXE /v stay
chev vt2
#vt=sxga 1280*1024 160*64
#vt2=sxga24 1280*1024 106*42
vz -z 

おおー，cpu cycle 設定をいじったら，めざましく快適になりました．
多少入力のタイミングとずれを感じるので，自分の環境で最適な値になるよう
調整してみたいと思います。ありがとうございました．m(_'_)m

あと，最新版でいろいろ改善していただいたみたいで，旧版よりずっといいですね．

速度もそうなのですが，実は以前からフォントの設定に悩んでいまして，
なんとか VL Gothic できれいに表示できないかなぁと思っていましたが，
この速度が出るのなら，もう MS Gothic でもいいや(笑)と思ったりもします．

わたしもそろそろ「極楽VZ環境」のWindows編を加筆しようかな．
ずいぶん長いこと放置しているので……

軟式さんにファイルコピー先の日付がコピーした時点に変わることを報告しました。
これは修正していただけることになりました。
この時に他に気がついた点は無いか質問があったので次の二点について返信しました。
１　LFNのファイル名が全角文字の時SFNが正しくない件
２　Vz高橋版以降のファイラーにおけるLFNの識別記号+がファイル名に半角小文字が含まれるとSFNでも+マークが付く件

軟式さんの回答はつぎのとおりです。
１についてはJP230216 以前では大丈夫なので、見直して修正します。
２については次のやり取りをしました。
> > 半角小文字は SFN にはないので LFN 扱いになっていると思います。
> 仕様であれば対応不要です。

なお、軟式さんからは次の返信を頂いたので要望すれば対応して頂けるようです。
　+ をつけるかどうかは Vz の LFN 処理で判定していると思います。
　どのように判定しているかがわかれば対応は可能と思います。

不具合修正版が公開されたので報告します。
ファイルコピー先の日時修正についてはメール文を引用します。
>　ファイルコピーの日時ですが、いまのところ imgmount でマウントしたド
>ライブでは日時情報は反映されず現在日時になってしまいますのでご注意く
>ださい。
>　mount で親 OS のフォルダをマウントしたドライブ間であればコピー先に
>日時情報は反映されます。
細かい気付きは他にもあるのですがどこまで要望するか思案してます。
軟式さんの迅速な対応に感謝しています。

> 軟式さんにファイルコピー先の日付がコピーした時点に変わることを報告しました。

ああ、ほんとだ！　気づきませんでした。(^^;;

> ２　Vz高橋版以降のファイラーにおけるLFNの識別記号+がファイル名に半角小文字が含まれるとSFNでも+マークが付く件
> > > 半角小文字は SFN にはないので LFN 扱いになっていると思います。
> > 仕様であれば対応不要です。

これは VTDOS と MS-DOS Player では半角小文字で8文字以下なら +マーク付かないですね。
今まで気にしていませんでした。(^^;

> なお、軟式さんからは次の返信を頂いたので要望すれば対応して頂けるようです。
> 　+ をつけるかどうかは Vz の LFN 処理で判定していると思います。
> 　どのように判定しているかがわかれば対応は可能と思います。

えーと、filer.asm の中で
dumplfn	proc　の2887行あたりから

	pushm	<es,dx,di>
	mov	dx,si
	call	cvtlfn
	mov	si,di
	movseg	ds,es
	popm	<di,dx,es>
IFDEF US
	call	putspc
ENDIF
	mov	al,SPC
	tstb	[si].lfn_aliasname		;★ このあたり？
_ifn z
;	mov	al,'+'				; ##k07f
;	tstb	cs:lfnmark			; サイズを減らすために変更
;  _ifn z					;
	mov	al,cs:lfnmark
;  _endif					;
_endif
	call	putc
	add	si,lfn_name
	call	strlen


★マークの所で判定していると思うのですが、私には読めていないので。(^^;;

> 不具合修正版が公開されたので報告します。

新版が出ていたのですね、頂きました。

> >　mount で親 OS のフォルダをマウントしたドライブ間であればコピー先に
> >日時情報は反映されます。

試してみましたが、コピーすると現在の日時になります。
また、LFN が SFN になるようです。

mount c c:\
mount d d:\
これですよね。
shadowさんのところでは正常にコピー出来ていますか？

なんとなく分かったような気がします。

> 	tstb	[si].lfn_aliasname		;★ このあたり？

これは恐らくショート名があるかないかのチェックかと。
例えば、LFNの DIR /X では

DIR /X 

2023/03/15  17:21               435              T.DEF
2023/03/18  12:59           299,443              tsv2
2023/03/20  13:53           299,579              TSVBT64
2023/03/18  12:00           299,579              tsv_E4
2023/03/18  12:02           299,579              tsv_EMS
2023/03/18  13:20           299,579 TSV_T_~1     TSV_T_XMS
2023/03/30  15:36                 0 VT_~1.TXT    VT=.txt
2023/04/03  21:50                 0 VTDOS_~1     VTDOS=
2023/02/28  22:34            62,768              vzibmj.co
2023/02/28  23:03            11,429              vzk07v6.com

このように、SFN の時は ショート名の欄が空白になります。
小文字でも SFN と認識しています。

つまり、エリアスショート名がある時に "+" マークを入れていると思われます。

> shadowさんのところでは正常にコピー出来ていますか？
copyコマンドのコピーでは日付情報は反映されています。
LFNも問題ありません。
ただzcopy等のソフトを使うとコピーした時点の日時になります。

有難うございます。
コピーの日時情報の件と合わせてこの情報を基に対応可能か要望してみます。

コピー先の日時の件は調査していただけることになりました。
+マークの問題個所は推定されたようです。
修正版は早くて今週末になるとの返信を頂きました。

> コピー先の日時の件は調査していただけることになりました。
> +マークの問題個所は推定されたようです。

迅速な対応ありがとうございます。
私の情報がお役に立てたならうれしいです。

> 修正版は早くて今週末になるとの返信を頂きました。

私一人だとチェック漏れが多かったので、shadowさんの対応に感謝です。
他にも気づいたことがあるとは流石です。
作者様に報告しておけば、より良いものが出来るかもしれませんし。
私も思い切ってメールを出して良かったと思います。(^_^)

※　マクロ差し替えました。(^^;

DOSVAXJ3 と VTDOS 用の表示行数切替えマクロです。
私のノートPCの 1336*768 に合わせた個人仕様になっています。
各自の環境に合わせてカスタマイズしてください。(^^;

#if 文で DOSVAXJ3 と VTDOS 用に分けているので、高橋版以降専用です。
DOSVAXJ3用は、前回から最新版の機能に合わせて調整しています。
VTDOS用は、説明の前にまずマクロを見てください。(^^;


80 ^KL "表示行数切替え"		;2024-04-21 v0.34
#if AXJ3	; DOSVAXJ3
  (s!=2)? >h			;コマンドライン
  (vp.26==106)? { &00 .}		;VT4の106*29行→VGAの25行
  (vp.26==80 && lc<=25)? { &01 .} 	;VGAの80*25行→VTの80*44行
  (vp.26==80  )?{ &02 .}  		;VTの80*44行→VT2の128*44行
  (vp.26==128)?{ &03 .}  		;VT2の128*44行→VT3の160*44行
  (vp.26==160)?{ &04 .}  		;VT3の160*44行→VT4の106*29行
:h	(s!=0)?.		;編集モード
  (vp.26==106)?{#E &00 w[=80, &09 .}	;VT4の106*29行→vgaの80*25行
  (vp.26==80&&lc<=25)?{#E &01 w[=80, &09 .} ;25行→80*44行
  (vp.26==80)?{#E &02 w[=128, &09 .}	;VTの80*44行→VT2の128*44行
  (vp.26==128)?{#E &03 w[=160, &09 .}	;VT2の44行→VT3の44行
  (vp.26==160)?{#E &04 w[=106, &09 .}	;VT3の44行→VT4の29行
  .
00:	&?("chev jp") #m 		; vga     640x 480 文字  80×25
01:	&?("chev vt") #m 		; svga    800x 600 文字 100×37
02:	&?("chev vt2") #m 		; xga    1024x 768 文字 128×48(44)
03:	&?("chev vt3") #m 		; sxga   1280x1024 文字 160×64(44)
04:	&?("chev vt4") #m 		; sxga24 1280x1024 文字 106×42(29)
#endif

#if VTDOS	; VTDOS
  (s!=2)? >h			;コマンドライン
  (vp.26>136)? { &00 .}			;136*35行→80*25行
  (vp.26==80 && lc<=25)? { &01 .}	;80*25行→80*35行
  (vp.26==80  )?{ &02 .}		;80*35行→110*26行
  (vp.26==110 )?{ &03 .}		;110*26行→136*35行
  (vp.26==136)?{ &04 .}			;136*35行→168*35行
:h	(s!=0)?.		;編集モード
  (vp.26>136)?{#E &00 w[=80, &09  .}	;136*35行→80*25行
  (vp.26==80&&lc<=25)?{#E &01 w[=80, &09 .} ;25行→80*35行
  (vp.26==80)?{#E &02 w[=110, &09 .}	;80*35行→110*26行
  (vp.26==110)?{#E &03 w[=136, &09 .}	;110*26行→136*35行
  (vp.26==136)?{#E &04 w[=168, &09 .}	;136*35行→168*39行
  .
00:	&?("$width 80 25") #m		; 80×25
01:	&?("$width 80 35") #m		; 80×35
02:	&?("$width 110 26") #m		; 110×26  font27
03:	&?("$width 136 35") #m		; 136×35  font22
04:	&?("$width 168 39") #m		; 168×39  font18
#endif

#if 98
	#66 .
;#else
;	&z("lxdspd") >*
#endif
	.
09: #[ we=w, (wb)?{wb.55=w, wb.56=lc-2, wb.57=lc-3,} ;裏テキストの桁,行数調整
    wa.55=w,  wa.56=lc-2, wa.57=lc-3, w], &d	     ;表テキストの桁,行数調整
	


このように、コマンドラインと編集画面で使えるようになっています。
今回の目玉は編集画面の桁、行数の完全対応です。
wa.55 〜 wa.57 を合わせることでアンダーラインカーソルも含めて正常な状態に出来ました。

マクロでポインタの数値を書き変える時に、タイミングなのか、変わらない事があるように見えました。
マクロ文の間にスペースを入れたら解消したので、CPUが速すぎるのでしょうかね。(^^;
メモリの書き換えをするマクロはこの辺の動作確認した方が安心ですね。

VTDOSは、単体で起動すると、プロパティでフォントサイズを変更できます。
それを活かして、各フォントサイズで画面いっぱいに表示出来るよう設定しました。
コメント欄の font18, font22, font27 がそのサイズに合わせた設定です。
画面をはみ出しても気にせずトグルすれば 80*25 に戻ります。(^^;

※ VTDOSでは、$width などのコマンドで同じ桁、行数で2度実行すると固まってしまうのでご注意。

何度も差し替えてもう大丈夫か、(^^;  と思ったら、何かおかしい？

  (vp.26==80  )?{ &00  &02 .}		;80*35行→110*26行

ここで画面の状態が何かおかしいのです。よく見ると（最近目が悪いので）
80*35行→110*26行になっているはずなのに、80*26行になっていました。
しかも VTDOSの画面は、80*35 のまま残っています。

$width コマンド単体で試してみました。

$width 80 35　　の後で
$width 110 26　 を実行すると、上記の現象になります。

具体的には、80*26 のDOS画面になっていて、VTDOS窓自体は 80*35 のままです。
VZの VP.26 の画面幅は 110  LC の行数は 26 になっています。なんで？

色々試してみると、どうやら $width コマンドのバグのようです。
幅の数値が増えて、行の数値が減る値で $width コマンドを実行すると画面幅が変わらないようです。
ということで、VTDOS用の修正をしました。

#if VTDOS	; VTDOS
  (s!=2)? >h			;コマンドライン
  (vp.26>136)? { &00 .}			;136*35行→80*25行
  (vp.26==80 && lc<=25)? { &01 .}	;80*25行→80*35行
  (vp.26==80  )?{ &00  &02 .}		;80*35行→110*26行   ★ bug?
  (vp.26==110 )?{ &03 .}		;110*26行→136*35行
  (vp.26==136)?{ &04 .}			;136*35行→168*35行
:h	(s!=0)?.		;編集モード
  (vp.26>136)?{#E &00 w[=80, &09  .}	;136*35行→80*25行
  (vp.26==80 && lc<=25)?{#E &01 w[=80, &09 .} ;25行→80*35行
  (vp.26==80)?{#E &00  &02 w[=110, &09 .} ;80*35行→110*26行  ★ bug?
  (vp.26==110)?{#E &03 w[=136, &09 .}	;110*26行→136*35行
  (vp.26==136)?{#E &04 w[=168, &09 .}	;136*35行→168*39行
  .
00:	&?("$width 80 25") #m		; 80×25
01:	&?("$width 80 35") #m		; 80×35
02:	&?("$width 110 26") #m		; 110×26  font27
03:	&?("$width 136 35") #m		; 136×35  font22
04:	&?("$width 168 39 %c",$0a") 	; 168×39  font18
#endif


このように、いったん &00 (80*25) を呼んでから &02 (110*26) を呼ぶようにしました。
この件は 10♯さんに報告しようと思います。

VTDOSでは、$width コマンドを実行するたびに「画面サイズを変更しました。」というメッセージが出ます。
何度も画面書換を繰り返すとメッセージが連続して鬱陶しいので、Fコールを試しました。
マクロは、ローカルマクロのみ差し替えです。

	;Int 2F/AX=7476h/BX=0005h 画面サイズの変更
00:	dx=$5019, >05			; 80*25
01:	dx=$5023, >05			; 80*35
02:	dx=$6E1A, >05			; 110*26
03:	dx=$8823, >05			; 136*35
04:	dx=$A827, >05			; 136*35

05:	ax=$7476, bx=$0005, &i($2F) 
	(s)?>06
06:	(z)??&?(" ") #m
#endif


どうやら Fコールも $width と同じバグがあるようなので、メインルーチンは同じです。
Fコールの後に改行を入れているのは、入れないと画面サイズの一部が更新されないからです。
これは、VZがコマンドラインでマクロを実行する時、画面サイズ変更を想定していないためと思われます。
そのために改行を実行するのですが、非常駐の時は子プロセスに行ってしまうのでスペースを追加しています。

とりあえずこれでほぼ完全な画面切り替えが出来たと思います。(^^;

とんでもないです。
必要最小限の修正依頼のメールを出したのですが気づきの質問を受けたので
まあ良いかと思っていた個所も要望したしだいです。
> 私も思い切ってメールを出して良かったと思います。(^_^)
私もそう思いました。 

VTDOS単体だとプロパティのレガシコンソールを使用するに設定しても
枠線が乱れるので使用していなかったのですが試しに立ち上げるとなぜ
か問題なく表示されるようになっていました。
でもプロパティを弄るとフォント設定が外れて元の設定に戻すのに苦労
していたので有難いです。
でも
04:	&?("$width 168 39 %c",$0a") 	; 168×39  font18
は前の版の
> 04:	&?("$width 168 39") #m		; 168×39  font18
に戻さないと上手く動かないです。
DOSVAXJ3の方はうちでは変化しないです。

> 必要最小限の修正依頼のメールを出したのですが気づきの質問を受けたので
> まあ良いかと思っていた個所も要望したしだいです。

こういうことってありますよね。
私もちょっと気になっていたことがあったのですが、いざ要望を出そうと思ったら思い出せなくて。(^^;
過去に何か書いていたように思ったので過去ログ検索してやっと思い出したという。(^^;;
やっぱり私は備忘録をこまめに書いておかないと全部忘れてしまいそうです。(^^;;; ﾔﾊﾞｲﾖ!
あとは書いている途中でもマメにセーブすることかな。（テストやうっかりで藻屑は数知れず）

> > 私も思い切ってメールを出して良かったと思います。(^_^)
> 私もそう思いました。 

コミュニケーションって難しいので失言で後悔したことも多いですが
言わないで後悔するくらいなら駄目もとでも言った方が良いと思える今日この頃です。

> VTDOS単体だとプロパティのレガシコンソールを使用するに設定しても
> 枠線が乱れるので使用していなかったのですが試しに立ち上げるとなぜ
> か問題なく表示されるようになっていました。

OSの更新のせいか、こういうことが結構ありましたね。

> でもプロパティを弄るとフォント設定が外れて元の設定に戻すのに苦労
> していたので有難いです。

お役に立てたならうれしいです。

> 04:	&?("$width 168 39 %c",$0a") 	; 168×39  font18
> は前の版の
> > 04:	&?("$width 168 39") #m		; 168×39  font18
> に戻さないと上手く動かないです。

すみません、改行の痕跡も消せないかと試行錯誤していたもので。(^^;
ていうか、完全におかしなことをやっていましたね、申し訳ない。m(__)m

> DOSVAXJ3の方はうちでは変化しないです。

これは画面サイズが変わらないということですね。
(vp.26==80)? のように完全一致でのチェックでは嵌ることがありますね。
順にトグルさせているので、不等号でチェックしたほうが良さそうですね。

追記

※環境変数 VZSYM=AXJ3 は設定されていますか。
#if AXJ3	; DOSVAXJ3 

VTDOSでは動いているなら指定はしているのかな？
最初の版で、VP.6 を使っていましたが、VP.26 が良いです。
うーん、あとは、現在の VP.26 をチェックしてみるとか？

> ※環境変数 VZSYM=AXJ3 は設定されていますか。
> #if AXJ3	; DOSVAXJ3 
設定済みです。
> 最初の版で、VP.6 を使っていましたが、VP.26 が良いです。
最初の版で変更できなかったのは高橋版にLFN対応のパッチを当てたVZを使用していたためでした。VZK07S05で変更できました。
いろんな版のVZでDOSVAXJ3を検証していたので混乱していました。
> うーん、あとは、現在の VP.26 をチェックしてみるとか？
この版はもう少し弄ってみます。

> 最初の版で変更できなかったのは高橋版にLFN対応のパッチを当てたVZを使用していたためでした。VZK07S05で変更できました。

どうも DOSVAXJ3 や VTDOS で VP.26 の値で条件分岐が上手くいかない事があるように思います。
64ビットOSとか CPUやメモリ速度の影響とかも疑ったりしています。
ちょっと変えるだけで動かなくなったりするので、要注意ですね。

なので、条件分岐を変えたりして今は安定した動作をしています。
最新版のマクロをアップしますので、それを試してみてください。

> この版はもう少し弄ってみます。

何か気が付いたことがありましたら教えてもらえるとありがたいです。

表示行数切替えマクロ v0.5 です。

=== ^kl.def ===
DOSVAXJ3 と VTDOS 用の表示行数切替えマクロです。
各自の環境に合わせてカスタマイズしてください。(^^;

・#if 文で DOSVAXJ3 と VTDOS 用に分けているので、高橋版以降専用です。
・コマンドラインと編集画面で使えるようになっています。
・シフト実行で、未更新の画面パラメータを合わせます。
　単独で切り替えコマンドを使った時やコンソール画面で合っていない時に使います。
・VTDOSの切り替えはコンソールのゴミが出ないようにしたので複雑になっています。


*m

80 ^KL "表示行数切替え"		;2024-04-24  v0.5

#if 98
	#66 .
;#else
;	&z("lxdspd") >*
#endif
	(s==1 || s>2)?.			;窓モードなら終了
	k=ks&1, (k==1)?{w[=vp.26, &09 .};シフト実行で表テキストの設定調整
	cx0, &s
#if AXJ3	; DOSVAXJ3	※環境変数 VZSYM=AXJ3 を指定
  (vp.26==106)?{&08 &00 &09 .}		;VT4の106*29行→vgaの80*25行
  (vp.26==80&&lc<=25)?{&08 &01 &09 .}	;80*25行→80*44行
  (vp.26==80)?{&08 &02 &09 .}		;VTの80*44行→VT2の128*44行
  (vp.26<=128)?{&08 &03 &09 .}		;VT2の128*44行→VT3の160*44行
  (vp.26>128)?{&08 &04 &09 .}		;VT3の160*44行→VT4の106*29行
  .
00:	&?("chev jp >nul") #m w[=80,	; vga     640x 480 文字  80×25
01:	&?("chev vt >nul") #m w[=80,	; svga    800x 600 文字 100×37
02:	&?("chev vt2 >nul") #m w[=128,	; xga    1024x 768 文字 128×48(44)
03:	&?("chev vt3 >nul") #m w[=160,	; sxga   1280x1024 文字 160×64(44)
04:	&?("chev vt4 >nul") #m w[=106,	; sxga24 1280x1024 文字 106×42(29)
#endif

#if VTDOS	; VTDOS		※環境変数 VZSYM=VTDOS を指定
  (vp.26>136)?{&08 &00 &09 .}		;136*35行→80*25行
  (vp.26==80 && lc<=25)?{&08 &01 &09 .}	;25行→80*35行
  (vp.26<110)? { cx1, &08 &02 &09 .}	;80*35行→110*26行	※ Win32 bug
  (vp.26<=110)?{&08 &03 &09 .}		;110*26行→136*35行
  (vp.26<=136)?{&08 &04 &09 .}		;136*35行→168*39行
  .	;Int 2F/AX=7476h/BX=0005h 画面サイズの変更
00:	w[=80, dx=$5019, &05		; 80*25
01:	w[=80, dx=$5023, >05		; 80*35
02:	&00 cx0, w110, dx=$6E1A, >05	; 110*26	※ Win32 bug
03:	w[=136, dx=$8823, >05		; 136*35
04:	w[=168, dx=$A827, >05		; 136*35
05:	ax=$7476, bx=$0005, &i($2F)	; Int 2F/AX=7476h/BX=0005h 
	(cx==0)?{(wa==0)? &?("%c",$0a)}	; #m の代わりに LF で改行しない
#endif
08:	(s!=2)? #E			;コマンドラインに
09:	(wa)?? { (s==2)?{		;編集テキストが無ければ
	ep[-, #[ #[ ep], w], .} }	;[ESC]2回で整えて終了
	(s==2)? {ep[-, #[ ep], } 	;編集モードに(シフト実行時はスルー)
	&10 (wb)?{&s #W &10 #W } w], &d ;表／裏テキストの桁,行数調整
10:	we=w, wa.55=w,  wa.56=lc-2, wa.57=lc-3, wv=w>>1, wh=lc>>1,

*

23-04-24 v0.5	VTDOSでの切り替えでコンソールのゴミが出ないように
23-04-22 v0.41	wv wh の画面分割パラメータ合わせた
23-04-21 v0.4	VTDOSのFコール版
23-04-21 v0.35	VTDOSのWin32バグ発覚、修正版
23-04-21 v0.34	wa.55 〜 wa.57 合わせアンダーラインカーソルも正常に
23-04-20 v0.2	VTDOS用も作ってみた。
23-04-08 v0.1	DOSVAXJ3用にとりあえず作ってみた。

 DOSVAXJ3とVTDOS共に切替えできるようになりました。
ところでDOSVAXJ3の編集画面で何度か切替えてカーソル↓
でスクロールした後カーソル↑すると表示が四角い枠状に
消える現象がおこりました。
何かキー入力すると消えていた箇所は正常に表示されます。
konnoさんのところではおこらないですか？

>  DOSVAXJ3とVTDOS共に切替えできるようになりました。

無事に動いたようでほっとしました。

> ところでDOSVAXJ3の編集画面で何度か切替えてカーソル↓
> でスクロールした後カーソル↑すると表示が四角い枠状に
> 消える現象がおこりました。
> 何かキー入力すると消えていた箇所は正常に表示されます。
> konnoさんのところではおこらないですか？

なんかカーソルの残骸みたいな感じのものが出ました。
128桁の時 1桁目に
160桁の時 66桁目に
160桁で一度 [ESC]E でコマンドラインに降りて戻ると 131桁目に
VRAMに何かゴミが書き込まれるんですかね？
shadowさんのところも同じような現象ですか？

CHEV コマンドを使わなくても出るようです。
どうも、xga と sxga の画面で出るようですね。
#    xga     解像度 1024× 768  文字 128×48 (44)
#    sxga    解像度 1280×1024  文字 160×64 (44)

DOSVAXJ3 が怪しいと感じたので過去のヴァージョンを見てみました。

2022/04/08  18:05         2,642,432 dosboxj.exe		現象が出ない
2023/01/23  17:33         2,643,456 dosboxj2.exe	これ以降現象が出る。

どうも、DOSVAXJ3 の問題のように思えます。
shadowさんのところで同じようになりますか？
同じなら、軟式さんに報告してみます。
引き続き検証してみます。

うちでは編集画面で160桁に切替えた後80桁*25行に変更
（大きい画面から小さい画面に変更）。
そして50行程度カーソルを下に移動＾X（DOWN）。
その後カーソルを^E（UP）で1行目に移動すると表示される文字が矩形ブロックで
切取ったように文字が消えています。
何かのキーを入力すると再表示されます。
とりあえずメールで画像も送りますね。
konnoさんの現象は検証してみます。

shadowさん
メールに返信してしまいました。(^^;

>うちでは編集画面で160桁に切替えた後80桁*25行に変更
>（大きい画面から小さい画面に変更）。
>そして50行程度カーソルを下に移動＾X（DOWN）。
>その後カーソルを^E（UP）で1行目に移動すると表示される文字が矩形ブロックで
>切取ったように文字が消えています。
>何かのキーを入力すると再表示されます。

うちでは再現しないです。
マクロ実行後だけおかしくなるのですか？
これはマクロを変更しているのですか？
そうであれば変更のソースを見てみたいです。

>とりあえずメールで画像も送りますね。

画像を見ると、cycles= auto 3000  くらいにしているのでしょうか。
うちではこれだと遅くてパラパラめくれるように動きます。

cycles= auto 50000 100% limit 100000

一度この設定で試してみてください。

konnoさん
お世話になっております。

>なんかカーソルの残骸みたいな感じのものが出ました。
うちでは出ないです。

>これはマクロを変更しているのですか？
VZを製品版に変更し改めてKL.DEF v0.5を掲示板からコピペして環境変数
に関する箇所はコメントにして試しました。
cycles= auto 50000 100% limit 100000に変更しました。
編集画面で160桁から80桁*25行に変更後に先の現象と違う現象となりました。
説明するより画像を見るのがわかりやすいので後ほど画像添付しメールします。
キー入力では正常になりませんでした。
根本は同じように思います。

動作条件は下記のとおりです。
DOSVAXJ3　230417版
windows 11 Home
バージョン　22H2
OSビルド 22621.1555

shadowさん,原因がわかったかもしれません。

> >なんかカーソルの残骸みたいな感じのものが出ました。
> うちでは出ないです。

CPUのスピードや 64ビットOSの特性が関係しているのではないかと感じています。
この件はまた別に検証を続けたいと思います。

> VZを製品版に変更し改めてKL.DEF v0.5を掲示板からコピペして環境変数
> に関する箇所はコメントにして試しました。

製品版はまた違う挙動があるようで、これも検証継続ですね。

> cycles= auto 50000 100% limit 100000に変更しました。
> 編集画面で160桁から80桁*25行に変更後に先の現象と違う現象となりました。
> 説明するより画像を見るのがわかりやすいので後ほど画像添付しメールします。
> キー入力では正常になりませんでした。
> 根本は同じように思います。

原因が分かったと思います。 cycles は関係ないと思われます。
もしかして、dosboxj.conf で VT4 を設定していないのではないですか。

VT4 を設定せずに、CHEV VT4 を実行すると、入力したコマンドが消えます。
そして、80*30 の VGA画面になるようです。
これは今のDOSVAXJ3の仕様かもしれません。

^KL マクロを 160桁画面で実行すると、CHEV VT4 で 80*30 になり、桁行数のパラメータが合わずに同じ現象が出ます。
恐らくshadowさんの現象もこれではないですか。

この場合、^KL マクロをシフト実行すると、桁行数のパラメータを合わせて正常になるはずです。
そのためのシフト機能です。(^^;

アンダーラインカーソルを表示していると状態が分かりやすいと思います。
しかし、問題はそれだけではないように感じました。

マクロを手直ししてみましたが、どうも思ったように動きません。
ポインタやメモリの書換が上手くいかないことがあるようです。
スペースを1つ2つ入れると正常に動作するので、メモリの書換と読み込みのタイミングが合わないのではと思いました。
それで、CPUのスピードや 64ビットOSの特性が関係しているのではないかと感じたのです。
軟式さんに報告してみます。

次の記事で、手直ししたマクロをUPします。

表示行数切替えマクロ v0.52 差し替え版
DOSVAXJ3 用です。
&d を入れたらタイミング調整出来たようです。


=== ^kld.def ===

*m

80 ^KL "表示行数切替え"		;2024-04-26  v0.52

  (s==1 || s>2)?.			;窓モードなら終了
  k=ks&1, (k==1)?{w[,   w=vp.26, &09 .} ;シフト実行で表テキストの設定調整
  cx0,  ; &s
;#if AXJ3	; DOSVAXJ3	※環境変数 VZSYM=AXJ3 を指定
  (vp.26==106)?{&08 &00 &09 .}		;VT4の106*29行→vgaの80*25行
  (vp.26==80&&lc<=25)?{&08 &01 &09 .}	;80*25行→80*44行
  (vp.26==80)?{&08 &02 &09 .}		;VTの80*44行→VT2の128*44行
  (vp.26<=128)?{&08 &03        &09 .}	;VT2の128*44行→VT3の160*44行
  (vp.26>128)?{&08 &04         &09 .}	;VT3の160*44行→VT4の106*29行
  .
00:  &?("chev jp >nul") #m &d w[,   w=vp.26,	; vga     640x 480 文字  80×25
01:  &?("chev vt >nul") #m &d w[,   w=vp.26,	; svga    800x 600 文字 100×37
02:  &?("chev vt2 >nul") #m &d w[,   w=vp.26,	; xga    1024x 768 文字 128×48(44)
03:  &?("chev vt3 >nul") #m &d w[,   w=160,	; sxga   1280x1024 文字 160×64(44)
04:  &?("chev vt4 >nul") #m &d w[,   w=vp.26,	; sxga24 1280x1024 文字 106×42(29)
;#endif

08:     (s!=2)? #E			;コマンドラインに
09:     (wa)?? { (s==2)?{		;編集テキストが無ければ
        ep[-,   #[   #[   ep], w], .} }	;[ESC]2回で整えて終了
        (s==2)? {ep[-,   #[   ep], } 	;編集モードに(シフト実行時はスルー)
        &10 (wb)?{&s #W &10 #W } w], &d ;表／裏テキストの桁,行数調整
10:     we=w,    wa.55=w,  wa.56=lc-2, wa.57=lc-3, wv=w>>1, wh=lc>>1, kx=lx,

*

23-04-26 v0.52	DOSVAXJ3での切り替えの不具合に対応
23-04-24 v0.5	VTDOSでの切り替えでコンソールのゴミが出ないように
23-04-22 v0.41	wv wh の画面分割パラメータ合わせた
23-04-21 v0.4	VTDOSのFコール版
23-04-21 v0.35	VTDOSのWin32バグ発覚、修正版
23-04-21 v0.34	wa.55 〜 wa.57 合わせアンダーラインカーソルも正常に
23-04-20 v0.2	VTDOS用も作ってみた。
23-04-08 v0.1	DOSVAXJ3用にとりあえず作ってみた。

> なんかカーソルの残骸みたいな感じのものが出ました。

これの原因がわかりました。

DOSVAXJ3の編集画面でカーソル↓で送っていくと、27行以降でカーソル位置が漢字だと
1行目のどこかにその漢字の片割れが表示されます。
そのままカーソル↓で送っていくと、カーソル位置が漢字の所でその漢字の片割れが等間隔で表示されます。
xga  128桁画面では32行目以降で
sxga 160桁画面では26行目以降で現象が出ます。
表示だけで実害はありません。

2022/04/08  18:05   2,642,432 dosboxj.exe   現象が出ない
2023/01/23  17:33   2,643,456 dosboxj.exe   これ以降現象が出る。

他と合わせて軟式さんに報告してみました。

> 表示行数切替えマクロ v0.52 差し替え版
対症療法で落ち着いたようなので自分用に変更しようと思います。

> 他と合わせて軟式さんに報告してみました。
ありがとうございます。
現象を相手様に伝えるのはなかなか難しく、奥深い内容になると私には無理なのでkonnoさんに感謝です。
そしてDOSVAXJ3がより安定し、VTDOSもアップデートされたのでVZはまだまだ使えそうです。
あっ、私が修正依頼した件は修正テスト版で直っているのでやがて正式版が出ると思います。

> 対症療法で落ち着いたようなので自分用に変更しようと思います。

あれからさらに変えてみました。このほうが安定すると思います。

00:  w[, w=vp.26, &?("chev jp >nul") #m &07	; vga     640x 480   80*25
01:  w[, w=vp.26, &?("chev vt >nul") #m &07	; svga    800x 600  100*37
02:  w[, w=vp.26, &?("chev vt2 >nul") #m &07	; xga    1024x 768  128*48(44)
03:  w[, w=vp.26, &?("chev vt3 >nul") #m &07	; sxga   1280x1024  160*64(44)
04:  w[, w=vp.26, &?("chev vt4 >nul") #m &07	; sxga24 1280x1024  106*42(29)
;#endif
07:     &d (w==vp.26)?? &w(10) w=vp.26,	;32ビットコマンドはウエイトが必要


色々いい加減な推測をしていましたが、32ビットコマンドは別プロセスで動くと何処かで見たような。
なのでVZは待たずに次の命令に進んでしまうのでこういうことになるのでしょう。

32ビットコマンドはウエイトが必要ということで、&w(10) を入れました。
&w(50) として画面切り替えトグルすれば、効いているのがわかります。
80*25 → 80*44　など、画面の書換面積が少ない時は、&w() をスキップしています。

> 現象を相手様に伝えるのはなかなか難しく、奥深い内容になると私には無理なのでkonnoさんに感謝です。

私もボケのせいか色々いい加減なことを言って、いつ見放されてもおかしくない気がしています。(^^;;

> そしてDOSVAXJ3がより安定し、VTDOSもアップデートされたのでVZはまだまだ使えそうです。

最近の怒涛のアップデートにこちらが追いつかないほどですね。(^^;
うれしい悲鳴です。(^_^)

> あっ、私が修正依頼した件は修正テスト版で直っているのでやがて正式版が出ると思います。

やはり気が付いたことをマメに報告するのが吉ですね。

VTDOS1.55 と CKWV11 が更新されました。

VTDOS バージョン1.55 の変更点は
-----------------------------------------------------------------------------
$width 拡張ビルトインコマンドでサイズ変更が行われなかった時に正常に動作しない
不具合を修正しました。

vtdos.cfgのSHELL,BILING,TMPで環境変数を参照出来るようにしました。
%vtdos_dir%を参照することで、VTDOS起動時のパスを参照出来るようになります。
これにより、USBメモリー等任意のドライブへのインストールを行い易くなります。
また、ckwv連動時に衝突するオプションを無効化しました。

ckwv使用時の画面リサイズをVZに対応するオプション(VZ_RESIZE,VZ_REDRAW)を
追加しました。
リサイズの状態を取得するAPI(Int 2F/AX=7476h/BX=000Bh)を追加しました。

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

最近画面切り替えマクロに嵌っているので嬉しい更新です。(^_^)
個人的にはこの
> $width w h	画面サイズを幅 w 桁、h 行に変更します。
> 	※画面サイズは最大255*255、最小80*6、VRAM_MAXが上限
画面の最小行数が6行までになったのがうれしいです。
GPD Poket などの超小型PC では18行以下になるので、ありがたいです。


CKWV11　の更新内容は 
-------------------------------------------------
Rev 11	2023/4/24
特定条件下でリサイズが正常に行われない不具合修正
-------------------------------------------------

マウスでリサイズすると VZの設定と合わなくなる場合がありますね。
10♯さんに リサイズパッチのソースをいただきました。
ありがとうございます。
これからいろいろ弄ってみたいと思います。

> > 	※画面サイズは最大255*255、最小80*6、VRAM_MAXが上限

Vz純正のgame.defがきちんと動くか、確認するべきでしょうね。
あとは、samegame.defとか。

> Vz純正のgame.defがきちんと動くか、確認するべきでしょうね。

思わず確認してしまいました。(^^;
ああ、時間を潰してしまった・・・
もちろん完璧に動きましたよ。

> あとは、samegame.defとか。

げげ、なぜか、DEFだけあるけど動かし方がわからない。
思わず軟体から拾ってきて動作確認してしまいました。(^^;
ああ、ダメだ・・・これは・・・・
時間がいくらあっても足りなくなるぅ・・・　(^^;
途中でストップしましたが、問題なく動くようです。
一番の問題は、癖になりそうなのが怖い！　(^^;

>> > 	※画面サイズは最大255*255、最小80*6、VRAM_MAXが上限"
> > Vz純正のgame.defがきちんと動くか、確認するべきでしょうね。

> もちろん完璧に動きましたよ。

さすがc.mosさん、80*6でも動くゲームマクロをきっちり作るなんて。
私にはとてもまねできません。

としきさん、konnoさん

　少しお久しぶりです。
　なるほど、そういうことなのね。鮫亀なの？　やったことない。あまり肩肘はらずに
遊んじゃおうよ、なんて気分なので、ＧＷのどっかでやってみますね。
　とりあえず、25x80なＤＯＳ機で。
　ああ、ボロボロじゃぁ。レポレッロ＠『ドン・ジョバンニ』バイ・モーツァルトなんて
のに、ひたすら癒しを求めている日々。
　休むぞ、遊ぶぞ、トマトの植え付けするぞ。

　あ、vtdosの更新もします。

> さすがc.mosさん、80*6でも動くゲームマクロをきっちり作るなんて。
> 私にはとてもまねできません。

げげ、そういう意味でしたか、流石に80*25以下は想定外ですね。(^^;
80*6 は我ながらちょっとやりすぎたかなぁと思いましたが、
編集画面で1行表示は出来るので何か使い道があるかなと。(^^;

ただ、テトリスマクロがそのまま普通の速度で動くのは感動しました。
1993/12/06  02:00             2,916 GAME.DEF
何も改変していない、そのまんまですよ。
80*18行までは普通に動きました。逆に行数を増やしても伸びないですね。
桁を80以上にしても正常に動作するので VTEXTも考慮しているのですね。

サメガメも凄いですね。
80*22行までは正常に動きましたが、桁を80以上にすると画面が乱れてVZが落ちます。(^^;

物はついで、shotsame.def も軟体から落としてみました。
これはVTEXTでも正常に動作するので、縦の行を目いっぱい
伸ばして、ブロックが落ちてくるのを遅らせられます。
とろいの木馬並みの私にはこれでも厳しい！

> 　なるほど、そういうことなのね。鮫亀なの？　やったことない。あまり肩肘はらずに
> 遊んじゃおうよ、なんて気分なので、ＧＷのどっかでやってみますね。

ＧＷの暇つぶしにはいいかもしれないですね。
鮫亀って、same game から来ているのかなと思いました。
Wikipediaから引用すると
-----------------------------------------------------------
さめがめは、コンピュータゲームの一種である。 名前の由来は、ゲームタイトル「SAME GAME(セイムゲーム)」の英語表記を日本語ローマ字読みしたもの（#歴史を参照）。
-----------------------------------------------------------

合っているようですが、セイムの意味が分かっていません。
same セイム で検索すると
-----------------------------------------------------------
SAME（セイム）は、Society（社会）、Arithmetic（算数）、Mathematics（数学）、Education（教育）の4つの頭文字をつないだ言葉です。 sameは日本語で「同じ」と訳し、複数の対象が同様であるということ以外に、１つの対象に対して同一であるという意味があります。
-----------------------------------------------------------

どうもこの「同じ」という意味が、同じものを消していくゲームっぽいかな。

> 　休むぞ、遊ぶぞ、トマトの植え付けするぞ。

遊ぶぃゼットも良いですね。(^^;

> 　あ、vtdosの更新もします。

新しいVTDOSは快調です。(^_^)

> げげ、そういう意味でしたか、流石に80*25以下は想定外ですね。(^^;

それ以外の意味はありません、というのはウソですが。
要は、デバッグというのはこうやる、というような話に繋がるわけでして。

学生時代、懇意の先輩のいる研究室に入り浸っていました。
その先輩たちが数人で、いわゆる同人ゲームを作っていたんです。
私はテスターという名目で、そのゲームで遊ばせてもらっていたんですがね。
想定外の操作ばかりするもので、メインにプログラムを担当していた先輩から、
「何でそんな操作をするんだよ！（ぷんぷん）」
と愚痴られるハメに。
そうでなきゃテスターとは言えんでしょ、という正論を盾に、ひたすら遊ばせて
いただいていました。
どうやら私、昔から、コーディングよりはデバッグとかテストとかの方に適性が
あるのかもしれない。

> 要は、デバッグというのはこうやる、というような話に繋がるわけでして。
> 
> 私はテスターという名目で、そのゲームで遊ばせてもらっていたんですがね。
> 想定外の操作ばかりするもので、メインにプログラムを担当していた先輩から、
> 「何でそんな操作をするんだよ！（ぷんぷん）」
> と愚痴られるハメに。

なるほど、想定外の操作は私もよくやるのですが、デバッグになっていたのね。(^^;

> どうやら私、昔から、コーディングよりはデバッグとかテストとかの方に適性が
> あるのかもしれない。

としきさんは全体を見ながら隅々まで気を配るみたいなイメージなのでその通りに思えます。
私は動作確認の時は問題の所だけをチェックして、はいＯＫ! とやりがちなので
いざ使ってみるとバグバグだったということを日々実感しています。(^^;;

> > なんかカーソルの残骸みたいな感じのものが出ました。
> これの原因がわかりました。
> 他と合わせて軟式さんに報告してみました。

軟式さんからメールが来て、この件は修正されたようです。

>　echo off の改行と、xga, sxga でのゴミが出る件については修正しました。

お忙しいなか対応いただいてありがたいです。

ところで、別件で気が付いたことも報告していました。
画面切り替えマクロで、^KL の起動キーで連続実行すると
[Ctrl] キーを押しっぱなしにしていても、2度目の実行時には無視されて
編集画面に "KL" の文字が入って、マクロは実行されません。
他のマクロではこういうことは無いようです。
CHEV JP (80*25) と CHEV VT（VGA80*30) の間の切り替えでは問題ないですが
その他の画面サイズでは [Ctrl] キーが効かなくなるようです。
&w() でウエイトを長くしても変わりません。

この件も調べてもらいました。

> 　画面描画周りは SDL というライブラリを使用しているのですが、描画
> 領域のサイズが変更になった場合、現在押されているキーを全て離した
> というメッセージを出す処理が入っています。
> 　DOSVAXJ3 の場合 SDL 側も IME 対応の専用版を使用しているので対応
> する事は可能ではあるのですが、SDL の基本的な初期化処理の部分ですの
> で、この動作を変更するのは問題がありそうです。
> 　すみませんが、現状のままという事でご了承ください。

ということで、画面切り替え時の仕様のようです。
気を付けて使っていても、うっかりテキストに文字を書き込んでしまうことはありそうです。
画面切り替えマクロの起動キーを @[F11] にすれば連続で押し続けても
カーソルが動くだけなので、これで使うようにしてみます。

DOSVAXJ3 (2023/5/1)版が更新されました。
更新内容を引用します。
-----------------------------------------------------------------------
DOSVAXJ3 build JP230501 (2023/5/1)
・64bit 版で [cpu] core=dynamic を指定すると落ちていたのを修正しました。
・int 21h ax=5701h のファイル日時設定が有効になるよう修正しました。
・FAT イメージファイルの場合でもファイルコピーの日時情報がコピー先ファイルに反映されるよう修正しました。
・8 文字以下のファイル名でも小文字だった場合はロングファイルネームを生成してしまっていたのを修正しました。
・DOS/V 日本語モードの場合、int 10h ax=1100h〜1114h の処理は実行しないよう修正しました。
・echo off 状態の場合、Vz のコンソール取り込みでコマンドの改行が入らなかったのを修正しました。
・CHEV で V-Text に切り替えた際のメッセージに画面の文字設定を表示するよう修正しました。
・V-Text が XGA, SXGA 設定の場合 Vz の編集画面にゴミが出る事があったのを修正しました。
・DOS/V 日本語モードでイメージファイルからブートした際に画面が乱れていたのを修正しました。
・CD-ROM とその他のイメージファイルを imgmount した際にファイルコピーで固まっていたのを修正しました。
-----------------------------------------------------------------------
報告した事のほとんどが修正されていますが、マクロ起動キーの件だけはそのままです。

> 画面切り替えマクロで、^KL の起動キーで連続実行すると
> [Ctrl] キーを押しっぱなしにしていても、2度目の実行時には無視されて
> 編集画面に "KL" の文字が入って、マクロは実行されません。

これは画面切り替え時の仕様のようなのでしかたがありませんね。
そうはいっても、うっかりテキストに文字を書き込んでしまうことはありそうなので
画面切り替えマクロの起動キーを @[F11] などにするのが良さそうです。

ともあれ年度替わりの忙しい時期に更新していただき、感謝です。

konnoさん、お世話になりました。
ファイルコピーの日時修正に関する軟式さんからのメールを転記します。
>　なお、OS のディレクトリを mount したドライブ上のファイルの日時情報
>を FD や FILMTN 等で変更する事はできません。
>　これは DOS と Windows の日時情報更新ファンクションの条件の違いのた
>め修正はできません。ただし imgmount したドライブ上のファイルの日時情
>報は変更できます。

> ファイルコピーの日時修正に関する軟式さんからのメールを転記します。
> >　なお、OS のディレクトリを mount したドライブ上のファイルの日時情報
> >を FD や FILMTN 等で変更する事はできません。
> >　これは DOS と Windows の日時情報更新ファンクションの条件の違いのた
> >め修正はできません。

これは Win32APIを使っていると思われる他のDOSエミュでも同じですね。
#10314：エミュレータでは DOSの日付操作が効かない？ 　投稿者：konno 　 2022/10/04
この辺で話題にしていました。

ところが、MS-DOS Player だけは違うみたいで。
#10346：MSDOS player は日時キープできました 　投稿者：konno 　 2022/10/19
> touch と BUPDATE は同じ環境に依存していると仮定して
> 純DOS　　　　 日時キープされる
> WinDOS窓　　　日時キープされる
> MSDOS player　日時キープされる
> VTDOS　　　　 現在日時になる
> DOSVAXJ3　　　現在日時になる

こういう結果になりましたので、MS-DOS Player は Win32API を使わずに自前でやっているのかも。

> ただし imgmount したドライブ上のファイルの日時情報は変更できます。

これは NP2 などと同じで、フルエミュレーションなのかなと思います。
違っていたらごめんなさい。

DOSVAXJ3，どんどんブラッシュアップしていますね。素晴らしいです。

VTDOS の方も，[ALT]キーで Windows の警告音が鳴る不具合（CKWV のですが）が
修正されて，他にも色々悩みのタネが解消してゆくのでとても嬉しいです。

> DOSVAXJ3，どんどんブラッシュアップしていますね。素晴らしいです。

問題点を特定して修正する速さ正確さは流石プロですね。レベチです！

> VTDOS の方も，[ALT]キーで Windows の警告音が鳴る不具合（CKWV のですが）が
> 修正されて，他にも色々悩みのタネが解消してゆくのでとても嬉しいです。

そういえば、CKWV の私家版も手を付けようと思ったのですが、ヘッダーファイルを開いたら
何故か EUC モードになってしまって、私家版VZにまだバグがあったかと焦りました。

色々調べた結果、VZ.DEF の !Open の記述の順番に問題が有ることが判明しました。(>_<)
散々VZのソースばかり見てて実はマクロだったとは、低レベルにもほどがあるという。(^^;;

そろそろ私家版VZもアップしようかな。（デバッグは皆にやってもらう他力本願式 (^^;;）

> そろそろ私家版VZもアップしようかな。（デバッグは皆にやってもらう他力本願式 (^^;;）
デバッグに協力できるかわかりませんがアップしてください。
うちはエミュレーターのみの試用になります。

> デバッグに協力できるかわかりませんがアップしてください。
> うちはエミュレーターのみの試用になります。

それでは、暫定版ですが、アップしてみます。

・・・と思ったら直前でバグが発覚しました！

しばしお待ちください。m(__)m

> それでは、暫定版ですが、アップしてみます。
> ・・・と思ったら直前でバグが発覚しました！

このバグは意外と根が深く、3月23日の版まで遡って、memo.asm を差し替えたら直ったようです。
と思ったら VZ.DEF が壊れるバグが発覚しました。色々調べてみたら VZ.DEF のサイズが
34,527bytes になっていて、32k を超えていて、これかと思ってサイズを減らしました。(^^;

memo.asm は関係なかったかと思い、元に戻したら、またバグが出たのです。
差し替えた memo.asm は、jcxz を追加した方で、こちらだと正常になるのでした。
うーん、よくわからないけど、これでアップするかぁ。(^^;

私家版VZk07v6i 更新しました。
バグバグで再々アップです。(^^;

k07v6i （2023-02-28〜05-09）バグにより差替え
　・k07t5 までの機能は全部取り込んであると思います。
　・Rf+ DOS窓SFNファイラーでも #R でロングファイル名変更（大文字小文字区別）
　　　　バッファの制限により、パスの長さ約80文字以上ではSFNとなる。
　・Sl　ステータスライン表示オプション変更　0:free　＋1:time　＋2:LFN View open
　　sl2 ならステータスラインでロング名表示　(Win9x、WinXP、MS-DOS Playrは sl2は指定しない)
　・編集モード [ESC]P [ESC]S でロングファイル名変更（大文字小文字区別）
　　※ この機能は VTDOS と DOSVAXJ3(lfn_space=true) の場合に正常動作します。
　・WinNT系のDOS窓コマンドラインの安定化 (検証中)
　・[ESC]i ファイル挿入時のVZの不具合を修正してみた (検証中)
　　※BL1024*3 だとファイル内容が壊れます。（全てのVZで起こるバグなのでこの設定は危険）
　　　
不具合を見つけたら掲示板に報告願います

　ダウンロード　 VZK07V6i.lzh ver1.60k07v6i （2023-05-09版 再再アップ） new!
　　　　ソース　2023-05-09 　50,382bytes　 再再アップ(^^;　 K07V6is.lzh new!


ドキュメント　VZK.DOC　2023-03-04 new!


追記

SLオプションの表記の間違いを直しました。

＃　げげ、SL弄ったままセーブしてまた大文字になっちまった〜 (>_<)

> 　・Sl　ステータスライン表示オプション変更　0:time　1:free　2:LFN View open　3:sl1+sl2

　ここは仕様が先祖帰りしたわけではなくて，
・Sl　ステータスライン表示オプション変更　0:free　＋1:time　＋2:LFN View open
……と，先の撤回版と同じですね？

長いファイル名は，大文字小文字きちんと表示されているようです。

ひとつだけ上の関係で気になったのが，例えば VZ.COM というファイル名（当然，
実行ファイルですね）を改名して「VZ.COM_k07v6d」などとした場合なのですが，
短いファイル名は「VZ[xxxx]~1.COM」となって，ファイラーでの表示は依然として
実行ファイル扱い（表示属性が）になりますが，これは Windows の仕様でしょうか。
そもそもな話で混ぜ返すみたいで申し訳ないですが，参考までに教えてください。

> > 　・Sl　ステータスライン表示オプション変更　0:time　1:free　2:LFN View open　3:sl1+sl2
> 　ここは仕様が先祖帰りしたわけではなくて，
> ・Sl　ステータスライン表示オプション変更　0:free　＋1:time　＋2:LFN View open
> ……と，先の撤回版と同じですね？

あう、間違えたままでした〜　(>_<)
ご指摘ありがとうございます。表記を直します。m(__)m

> ひとつだけ上の関係で気になったのが，例えば VZ.COM というファイル名（当然，
> 実行ファイルですね）を改名して「VZ.COM_k07v6d」などとした場合なのですが，
> 短いファイル名は「VZ[xxxx]~1.COM」となって，ファイラーでの表示は依然として
> 実行ファイル扱い（表示属性が）になりますが，これは Windows の仕様でしょうか。

ファイラーの表示はVZの管理下なので、DOSの仕様の範囲内だと思います。
VZは、表示属性はショート名で判断しているはずです。
拡張子が .com 以外に変わらなければ実行ファイルと判断するでしょう。

> VZは、表示属性はショート名で判断しているはずです。

なるほど。わかりました。DOSエミュ環境では，4文字以上の拡張子は3文字に丸められ，
その3文字（…のうち先頭2文字）で VZ は *E に設定された表示属性に従って表示する。
……って感じかな。
折を見て，純DOS環境やXPモード（等のNTVDM）で確認してみたいと思います。
ありがとうございました。

検証をお願いします。＞みなさま

うちで出ている症状ですが，[ESC]I 系のマクロ，または自作の Umenu.def において，
小さなテキスト（一行に満たないような）を挿入すると，
・直後にヌルが大量に出力される
・あるいは，直前にオープンしていたファイルが続けて挿入される
……という現象が出ています。これは初めての経験です。

opt_lst.def を実行したら，VTDOS から警告あり，VZが落ちました。
VZ(185E) 185E:09EA 'REP MOVSW 命令ラップアラウンド'

ちょっと厳しい状況です。

opt_lst.def を実行すると落ちてしまうので，細かいリストは出せませんが，
メモリ関係だと，XMS 最大 16384KB使用（xm1），em0，bt64，sw3，bm30000，bl8132，
……という値で起動しています。

> うちで出ている症状ですが，[ESC]I 系のマクロ，または自作の Umenu.def において，
> 小さなテキスト（一行に満たないような）を挿入すると，
> ・直後にヌルが大量に出力される
> ・あるいは，直前にオープンしていたファイルが続けて挿入される
> ……という現象が出ています。これは初めての経験です。

すみません、まだバグバグだったようです。m(__)m

うちでも小さいファイルの EOF 上でエンターや文字追加などすると別領域のテキストが挿入されました。
公開停止して調べてみます。

> 小さいファイルの EOF 上でエンターや文字追加などすると別領域のテキストが挿入

これ，挙げていませんでしたが，わたしの手元でも事例がありました。
よろしくお願いします。

> > 小さいファイルの EOF 上でエンターや文字追加などすると別領域のテキストが挿入
> これ，挙げていませんでしたが，わたしの手元でも事例がありました。

すみません、これは以前発覚して直したと思っていたバグでした。
どうやって直したか忘れてしまって時間が掛かってしまいました。（アルツじゃ〜）
過去記事で書いたと思ったのをやっと検索出来ました。(^^;

#10558： Re^4: DOSVAXJ3で開けないファイル 投稿者： konno 　 2023/02/16
>> "確定申"フォルダを作ったら、"確定・"になってしまい、その中の"確定申"ファイルを開いたら
>> "・"が $1A になって、中身がマクロのテキストに繋がってしまいました。
> これは、[ESC]i 不具合修正で混入したVZKのバグだったようです。
> 開いたテキストの末尾で文字を挿入すると発生していました。

これと同じバグだと思います。
それで、バグのないソースがもうわからなくなってしまったので 、(^^;

#10624：vzk07v6h UP 　投稿者：konno 　 2023/03/15
 
この時公開したソースからやり直しました。
これのバグを修正したら、良くなったようです。
しばらく運用して問題なければこれをアップしようと思います。

私家版VZk07v6j 更新しました。


k07v6j （2023-02-28〜05-19）
　・k07t5 までの機能は全部取り込んであると思います。
　・Rf+ DOS窓SFNファイラーでも #R でロングファイル名変更（大文字小文字区別）
　　　　バッファの制限により、パスの長さ約80文字以上ではSFNとなる。
　・Sl　ステータスライン表示オプション変更　0:free　＋1:time　＋2:LFN View open
　　sl2 ならステータスラインでロング名表示　(Win9x、WinXP、MS-DOS Playrは sl2は指定しない)
　・編集モード [ESC]P [ESC]S でロングファイル名変更（大文字小文字区別）
　　※ この機能は VTDOS と DOSVAXJ3(lfn_space=true) の場合に正常動作します。
　・WinNT系のDOS窓コマンドラインの安定化 (検証中)
　・[ESC]i ファイル挿入時のVZの不具合を修正してみた (検証中)
　　※BL1024*3 だとファイル内容が壊れます。（全てのVZで起こるバグなのでこの設定は危険）
　　　詳細は掲示板を読んでください。不具合を見つけたら掲示板に報告願います

　ダウンロード　 vzk07v6j.lzh ver1.60k07v6j （2023-05-19版 ） new!
　　　　ソース　2023-05-19 　50,468bytes　 K07V6js.lzh new!

更新，お疲れ様です．
日常の定型的なルーチンをあれこれ行ってみましたが，今のところ異常はありません．
（このところ，あまり大きなファイルはいじらないようにしているので，ハードなことはしていませんが）

何か「これやってみて」とかあったら仰ってください．
LXが復活したので，純DOS環境レポートも可能です．

> 日常の定型的なルーチンをあれこれ行ってみましたが，今のところ異常はありません．
> （このところ，あまり大きなファイルはいじらないようにしているので，ハードなことはしていませんが）

確認頂きありがとうございます。
私の普段の運用だけでは問題無いように思えるので、他の人の環境での検証が必要です。
今度こそバグが無くなっていますように。(-人-) 

> 何か「これやってみて」とかあったら仰ってください．
> LXが復活したので，純DOS環境レポートも可能です．

色々弄っているので、純DOS環境で問題ないかが気になります。
何か気づくことがありましたらよろしくお願いします。

去年発覚したVZの大きなバグ、BL1024*3(3072)のバグの検証です。
#10682. VTDOS+EMS+VZでの不具合検証 のツリーでも話題にしましたが
VTDOSのEMSのバグが直ったので、VZのバグとして新スレッドにしました。

基本的に、[ESC]I マクロと、としきさんのテストデータで検証しています。
・BL1024*8(8192) 近辺で実行すると、CPズレが起こり、テキスト内容が壊れる。
・BL1024*3(3072) 近辺では、テキスト内容が壊れ、サイズも増減し、ラップアラウンドエラーになります。
・BL1024*2(2048)以下の時、比較で一致しても直後に[F02]窓替えで再比較すると文字化けが出る(BL以下の行にLF？)

で、最近気が付いたのは、BT32 だとBL1024*3(3072) で正常に処理されるのです。

vzk
BL1024*3(3072)　BT59以下正常　BT60以上は異常

vzt
BL1024*3(3072)　BT59以下正常　BT60以上は異常　※ BLの長さを超える行で文字化け？
BL1024*8(8192)　BT64  CPズレ
BL1024*8(8192)　BT59以下  CPズレ無し
BL1024*9(9216)　BT64  CPズレ無し

これは面白いですね。
Emmett さんが BT32 を好んでいた（ように見えた）理由とも繋がっていたりして。

> vzk
> BL1024*3(3072)　BT59以下正常　BT60以上は異常
検証中なのは承知の上で、VZ1.6各版共通のバグだと思うのでもし、tVZに[ESC]i 関連だけのソース修正パッチを作れるのであればほしいです。

> Emmett さんが BT32 を好んでいた（ように見えた）理由とも繋がっていたりして。
うちのオプションがなぜBT32変更されているのか考えてみました。
以前LXLOADERを使っておりbf_plus.docを見ていじった名残だったのでした。

> 検証中なのは承知の上で、VZ1.6各版共通のバグだと思うのでもし、tVZに[ESC]i 関連だけのソース修正パッチを作れるのであればほしいです。

なるほど、tVZ で同じパッチが有効であれば検証も一歩前進出来るかもですね。
どうせやるなら、LFNパッチも付加した方がいいですか、簡単なので。

> > Emmett さんが BT32 を好んでいた（ように見えた）理由とも繋がっていたりして。
> うちのオプションがなぜBT32変更されているのか考えてみました。
> 以前LXLOADERを使っておりbf_plus.docを見ていじった名残だったのでした。

bf_plus.doc を読んでみました。
マクロの読み込みバッファを32k確保するための BT32 なんですね。関係なかったか。(^^;
この問題は、高橋版で対処されているようです。

TEXT.ASM  11行目
Z_TBSIZE	equ	MIN_TBSIZE * 2	; ##t  800h  &z() 時、最低 32KB 確保

コメントは私が追加したものです。

> なるほど、tVZ で同じパッチが有効であれば検証も一歩前進出来るかもですね。
> どうせやるなら、LFNパッチも付加した方がいいですか、簡単なので。
確かにLFNはある方が便利ですね。
LFNパッチ付加でお願いします。

> 確かにLFNはある方が便利ですね。
> LFNパッチ付加でお願いします。

LFNパッチ付加でやってみました。
テスト環境では問題なく動作しました。
明日にでもアップしようと思います。

高橋版VZ用に [ESC]I バグ対策パッチ 検証テスト版アップしました。
「自作、改作アプリの放置部屋」 に置きました。

・全てのVZにおいて VZ標準の [ESC]I マクロと、としきさんのテストデータで起こるバグ
　　BL1024*8(8192) 近辺で実行すると、CPズレが起こり、テキスト内容が壊れる
　　BL1024*3(3072) 近辺では、テキスト内容が壊れ、サイズも増減し、ラップアラウンドエラーになります
　　BL1024*2(2048)以下の時、比較で一致しても直後に[F02]窓替えで再比較すると文字化けが出る(BL以下の行にLF？)
　これらのバグを対策してみたkVZ最新版のパッチを高橋版VZに適応してみました。現在検証中です。
・ついでに NT系でのLFN対応パッチも付加しました。

高橋版VZに対する自己解凍差分になっています。

ダウンロード　VZt-p.lzh　サイズ 4953bytes　 23-06-01 new!

ソース　VZt-ps.lzh　サイズ 1,864bytes　 23-06-01 new!

・ソースの変更点
　　TEXT.ASM　　[ESC]I BL3072 BL8192 BUG対策（検証中）
　　KEYIBM.ASM　MASM6でもアセンブルできるように変更
　　FILER2.ASM　LFNパッチ
　　MEMO.ASM　　VTDOSエラー回避

　動作保証はでき無いので実行は自己責任で。

konnoさん（and shadowさん）

　いいですね、このプロジェクトと方向性！
　僕も参戦したいのですが、まだちょっとヘロヘロなんです。どうしてこう次々あるのか。
どうしてこう簡単に疲れてしまうのか。
　雨でお野菜さんたちの状態も気になるし、、、。

　今日、Win11の新品マシンを作り始めました。まーぶるの６万円ぐらいのマシン。データ
保存、バックアップ用のＨＤを入れなくちゃ、、、。
　Win7なSSDが壊れて２週間。プリンタ（必須）がおかしくなって３か月。ついでに
ＭＥ機も不調！
　そこらじゅう故障だらけ。ＣＤプレーヤまで修理に出した、、、。
　とほほ。

　とにかく、興味深く見守らせていただいておりますので、頑張ってくださいね。
　あのテキストバッファ＆ラインバッファとＥＭＳその他の根本的バグ（怖くて大きな
ファイルをいじる気になれない）は、ほんと挙動を見定めさせていただきたいとは
思っています。
　としきさん、やっぱ本物です。多謝。

　本格的に別のエディタに移る気はやっぱりないので、生きろ！　Ｖｚ。生かせ！
自分たちの手で。なんて気持ちはまだまだもってます。

　Win11機にしたら、ＩＭＥの挙動がとっても変わってますね、スマホみたい？
なんだこりゃ？

　いろんなことの整備にまだまだ時間がかかると思いますが、必ず戻りますので、
がんばってくださいね！　お願いしたいような気持ちでおります。

　でも、お仕事関係のゴールは見えました！　失業保険もらうぞ、みたく。
　まだまだちょっと時間がかかるのですが。選択定年制です！
　すぐじゃなくて、先ですけどね。

> 　今日、Win11の新品マシンを作り始めました。まーぶるの６万円ぐらいのマシン。

あ〜、私もそろそろWin11を考えなくては。
最近のWinって、ＯＳ単体で売っているのかな。そういうこともわからなくなった。
今浦島、って感じ。

> 　Win11機にしたら、ＩＭＥの挙動がとっても変わってますね、スマホみたい？

これ、プロパティいじって何とかならないのかな？
数ヶ月前に職場で新しく配布されたノートＰＣもＩＭＥの挙動になじめなくて、
何ヶ所かプロパティをいじってやっと何とか我慢できるくらいに持ってきた。
予測変換とか、私は使わないんでね。

>> 　Win11機にしたら、ＩＭＥの挙動がとっても変わってますね、スマホみたい？"
>これ、プロパティいじって何とかならないのかな？
　「設定」の中に入って、「予測変換」オフにしたら、できました！
　ざっと眺めてみると、うーん、複雑に進化しておりますなぁ。
　もう辞書の管理とかすっかりしなくなってるしなぁ、、、。老後はこのあたりから
ちまちま攻めます。

>何ヶ所かプロパティをいじってやっと何とか我慢できるくらいに持ってきた。
　必要なんでしょうね、これ。よく分からんのいっぱい。
　とりあえず、Win11で、Vzが使えてます。昨晩メニューで文字化けをみたけど
（Ｆ０１の連打のとき）、とりわけ問題なくいってるみたいです。
　もちろん、VTDOS & CKWV さまさま。m(__)m

　これから、データのたぐいをごっそりコピーです。VZLOGとか。８ＧＢぐらいの
DDWIN用辞書データは昨晩やりました。DDWIN、健康。よろしい。

　マシン設定初期のデフォ、CapLock<->Ctrl，ESC<->全半のレジストリでの入れ替え
は従来どおりでいけました。よかった、よかった。
　Win11なのかマシンなのか、起動がはやくてよいです。

　CPUは、こんな感じのマシン。
Intel(R) Xeon(R) E-2124G CPU @ 3.40GHz   3.41 GHz
　32GBのラムですと。はぁ。純ＤＯＳって、１パーティション２ＧＢ、全部で８ＧＢ
のＨＤまでしか管理できないはずなのですが。比較するな！

　しかし、IMEがまだまだ色々と邪魔してくれる、、、。うう、「無変換」キーが
IMEに取られる、、、。「なし」にできないみたい、、、。

　ＯＳの単体売り。僕も欲しい気もするけど、気力ないかなぁ。そのあとのドライバ
探しとか考えると、いっかなぁ、なんて感じです。ＨＤコピーでずっと済ませてきてる。

　すいません、「高橋版Ｖｚからの検証」プロジェクトにまだまだちっとも
貢献できそうにありません。ぼちぼち、、、いかせてください。

> 　いいですね、このプロジェクトと方向性！

そうですね、最新の私家版はまだ安定しているかわからないし・・・
安定版と思われる版にもパッチ版出してみようかしら。

> 　僕も参戦したいのですが、まだちょっとヘロヘロなんです。どうしてこう次々あるのか。
> どうしてこう簡単に疲れてしまうのか。

文太さんはあれこれ抱えすぎなのでしょうね、一休みも無駄にはならないと思います。

> 　雨でお野菜さんたちの状態も気になるし、、、。

凄い雨でしたね。畑とかの被害も凄そうで、また野菜が値上がりしそうですね。

> 　今日、Win11の新品マシンを作り始めました。まーぶるの６万円ぐらいのマシン。データ
> 保存、バックアップ用のＨＤを入れなくちゃ、、、。

おめでとうございます！　Win11 での VZ 動作報告も期待してます。(^_^)

> 　Win7なSSDが壊れて２週間。プリンタ（必須）がおかしくなって３か月。ついでに
> ＭＥ機も不調！
> 　そこらじゅう故障だらけ。ＣＤプレーヤまで修理に出した、、、。
> 　とほほ。

うちもSSD 2年で壊れたし、PCのトラブルで入れ替えも最近頻繁なので、仕方がないところはありますよね。

> 　本格的に別のエディタに移る気はやっぱりないので、生きろ！　Ｖｚ。生かせ！
> 自分たちの手で。なんて気持ちはまだまだもってます。

ほんとそうですね。もし私一人だけならもうとっくに更新もしてなかったでしょう。
DOSエミュ作者様がたもユーザーがいるからモチベーションを保っておられると思います。

> 　Win11機にしたら、ＩＭＥの挙動がとっても変わってますね、スマホみたい？
> なんだこりゃ？

予測変換ですか？　スマホに慣れた人にはいいのかもしれませんね。

> 　でも、お仕事関係のゴールは見えました！　失業保険もらうぞ、みたく。
> 　まだまだちょっと時間がかかるのですが。選択定年制です！
> 　すぐじゃなくて、先ですけどね。

私も定年に近づいたとき同じような心境だったと思います。
セカンドライフをどう描くか考えるようになりましたね。

　そうかぁ、まだWin11な人というのは少ないのかな？
　では少しだけ。

　まず前段。Win7なマシンをどれくらい使ったのか記録も記憶もないのですが、
たぶん、ＸＰ→７→１１な展開なはずなので、かなり長かった。ＨＤ３台と
ＳＳＤ１台にブートディスクコピーをして、ずっとそのまま使い続けてきた。
きっと１０年以上。
　な、長い。データディスクも、そこそこ全ディスクコピーして使ってきました。

　注意点は、ＳＳＤ（ブートディスク）は割とサドンデス的に死ぬ、ということ。
Ｃドライブのデータは、割と定期的に全バックアップをデータドライブＨＤ（Ｄ：）
にしてきたのだけど、今回は運が悪くて苦労しました。
　ＯＳが起動できなくなったから、いわばマシン全体が死んだ状態になった。
　その古いマシンの詳細な検証はいまだできず。

　ＨＤの場合には、「あ、やばそうだな。コピー＆交換」とか思う余裕があった。
ＳＳＤではなかった。ご注意を。ＳＳＤの寿命は２年くらいだったと思う。
コロナがあったりしたし（オンライン授業）、YouTube & Netflix とかあったから
たぶん、けっこうな時間、使われたのだとは思うけど。

　もちろんその後、ＵＳＢ接続のＨＤケースにブートＳＳＤをくっつけて、最新
データファイル群を救出することはできました。

　そうそう、これは古すぎる話っぽいですが、古いマシンの古いマザーボードには
ＨＤが２ＴＢまで、という壁がありました。この新しいのでは３ＴＢＨＤが認識
できるのか、この実験は、これからです。


　さて、Win11。ＩＭＥを「従来のにする」に設定しました。そして、画面右下
（名前なんだっけ？）の「あ」を右クリックで、「プロパティ」−「詳細設定」−
「編集操作」−「キー設定」−「変更」から、従来のように１キー１キー好きなように
カスタマイズできます。ここで「無変換」キーの右の奴らを全部削除。これで、
「無変換」キーをＩＭＥから解放できます。僕のばあいは、exmenuのキー。

Nf+			;DosVで[NFER]を[無変換]と読みかえ
　これが効く。

　なんですが、ckwvなのかvtdosなのか？　２バイト文字（日本語）がメニュー内で
化けます。テキスト上でも化けます。

　ふむ、「無変換」を無内容にしても、ＩＭＥが立っているとキーを取られるみたい。
exmenuに届かないぞ。
　さて、どうしたものか、、、？

　Win11だと、きっと皆困ると思う。それまで、メニュー内の日本語は排除して
生きるのかなぁ。

　こんな状態です。


　うーん、いっぱい抱え込んじゃう人なのかなぁ。
　今日は、雨があがったので、ひたすらだらだら、_Who Killed Classical Music?_
というかなり暗い本をずっと読んでます。癒しタイムです。

　ネットワーク上のＩＤとかパスワードが全部飛んでしまっている状態なので、
ＰＣ触るのが億劫です。いちいち全部調べて打ち込みなおしなのです。
　Win7マシンのＯＳ、いっぱい記憶してくれてたのねぇ、、、。とほほ。

> 　そうかぁ、まだWin11な人というのは少ないのかな？

Win10と異なり，少し古めのハードには導入できなくなりましたからね。8世代以降？

うちは，作業用（基本的にバッチを走らせるだけ）の端末にWin11を導入してみたところ，
そのインターフェースの酷い改悪に辟易してしまい，他の常用マシンはギリギリまで
導入しないつもりでいます。
そのうちWin10ライクなインターフェース（タスクバー，スタートメニュー，コンテキスト
メニューの使い勝手）にする設定またはフリーウェアが出てくるでしょう。


■メニューなどの文字化け

「レガシーコンソールを使用する」設定が無効になっていませんか？
#8667 を参照してみてください。


■「無変換」→[NFER]

Win-IMEだと，かな入力モードでなくても取られちゃいますね。うちの環境でも同様です。
わたしは Google-IME を常用しているので気付きませんでした。
Google-IME なら，かな入力（「あ」の状態）でも無変換が[NFER]として通ります。

自分がずっと Google-IME を愛用している理由は，固有名詞（人名）に強いということも
あるのですが，キーカスタマイズがかなり自由であること，keymap をテキストで出力でき
他の環境に即座にインポートできることです。もう手放せない。……と思っていましたが，
最近，記号の候補が変に変わってしまったり，環境依存文字が優先候補で表示されたりして
ちょっと困惑中。 

> 　さて、Win11。ＩＭＥを「従来のにする」に設定しました。そして、画面右下
> （名前なんだっけ？）の「あ」を右クリックで、「プロパティ」−「詳細設定」−
> 「編集操作」−「キー設定」−「変更」から、従来のように１キー１キー好きなように
> カスタマイズできます。ここで「無変換」キーの右の奴らを全部削除。これで、
> 「無変換」キーをＩＭＥから解放できます。僕のばあいは、exmenuのキー。

これは Win10 でもほぼ同じではないかと思います。私もやりました。
と思ったら、「無変換」キーが効かなくなっていますね。(^^;
壊れた前のノートPCでやっていたのだったか・・・またやり直しました。

> Nf+			;DosVで[NFER]を[無変換]と読みかえ
> 　これが効く。
> 　なんですが、ckwvなのかvtdosなのか？　２バイト文字（日本語）がメニュー内で
> 化けます。テキスト上でも化けます。

この症状は無いですね。２バイト文字（日本語）が全部化けるのですかね？

> 　ふむ、「無変換」を無内容にしても、ＩＭＥが立っているとキーを取られるみたい。
> exmenuに届かないぞ。

これは同じですね、気になったので各種エミュで確認してみました。

VTDOS		IME OFF IME ON	SCAN
[無変換]	〇	ｘ	AB00
\[無変換]	〇	ｘ	AC00
^[無変換]	〇	ｘ	AD00
@[無変換]	〇	〇	AE00

ALT+だけは IME ON でも OK なのが面白いですね。

MS-DOS Player	IME OFF IME ON	SCAN
[無変換]	ｘ	ｘ	7B00
\[無変換]	ｘ	ｘ	7B00
^[無変換]	ｘ	ｘ	7B00
@[無変換]	ｘ	ｘ	7B00

全滅です。SCANコードは 全て 7B00 で、これは仮想キーコード？
もちろんマクロキーとしても使えません。

DOSVAXJ3	IME OFF IME ON	SCAN
[無変換]	〇	〇	-
\[無変換]	〇	〇	-
^[無変換]	〇	〇	-
@[無変換]	〇	〇	-

全てマクロ起動キーとして使えます。が、SCANコードは出ていない？
何故マクロキーとして使えるの？？？

NP2		FEP OFF FEP ON	SCAN
[NFER]		ｘ	ｘ	5100
\[NFER]		ｘ	ｘ	A100
^[NFER]		ｘ	ｘ	9D00
@[NFER]		ｘ	ｘ	5100

あれぇ？？？　PC-98 と何が違うんだろう？

CKWV 私家改造版 CKWV111 を VZの部屋にアップしました。
今回は変更したソースも同梱しています。

　10#さんの改造されたCKWVをちょっと改造
　・マウスホイールの送出コードにシフト系が残るのを修正したつもり
　・オリジナルはマウス右クリックでペーストだが、シフトを押しながら右クリックに変更
　・Ckw*touchsc: yes　オプション追加、有効時、マウスの左クリックで何もしない タッチパネル用
　※動作保証は出来ないので、ご使用は自己責任で

2023-06-07
　・10#さんの最新 CKWV11 に私の改造を追加
　ダウンロード 変更ソース付き　ckwv111.zip 127kb（2023-06-07版） new!

私の欲しいものリストを揚げてみます。

１．とらじ氏作 TAGLIGHT.EXE のソース
　　VZをカラフルにしてくれる超便利な常駐ソフトです。
　　現状バッファなどいくつか制限があるので改造したいのですが
　　ソ−スレベルでないと改造は無理そうなのです。


２．PCDOS6.3V初期版に対応させるVZのパッチソース
　　PCDOS6.3V初期版はVZ常駐で起動できなかったのを対応させたVZパッチがあったと思います。
　　
README.TXT --  PC DOS 2000 日本語版 ご使用上の注意事項  より
3.4.6  Vz エディター
  --------------------
　Vzエディターの常駐モードでESCキーが効かない場合、VzエディターにPC DOS 
  J7.0/V用のパッチを当てている可能性があります。元のVzエディターをお使い
  ください。

このパッチ版VZのソースか、VZ本体が欲しいです。
今のDOSエミュでも、command.com によってはVZの起動がうまくないものがあります。
その原因を突き止める参考になると考えています。

とらじさんは，すっぱりと過去を切り捨てたのではないかと思われるわけで，おそらく
過去のリソースは残されていないでしょうね．天才的なセンスがあったのに残念です．

pascal か Delphi で書いていることは確実なので，逆コンパイルしてみてはいかがかと．
所謂リバースエンジニアリングと言われるアレですが，元がフリーウェアですから
道義的にどうこうということもないのではないかと思います．

以前，とらじさんが clppst を破棄しようとしていたときに，再配布の許可をくれなきゃ
逆コンパイルしてクローン作る覚悟と伝えたところ，許可された経緯がありました．

一応 facebook で繋がってはいるので，聞いてみるだけはできると思いますが，
おそらくきっと絶対に「捨てたので残っていない」と言われることでしょう．

> とらじさんは，すっぱりと過去を切り捨てたのではないかと思われるわけで，おそらく
> 過去のリソースは残されていないでしょうね．天才的なセンスがあったのに残念です．

以前そのような話を聞いた気がします。
とらじさんはニフティのメンバーサイトを開設してそこに置いていたように思うので
誰かしらソースを落として保存している人がいるのではないかという一縷の望みに賭けたのです。

> pascal か Delphi で書いていることは確実なので，逆コンパイルしてみてはいかがかと．
> 所謂リバースエンジニアリングと言われるアレですが，元がフリーウェアですから
> 道義的にどうこうということもないのではないかと思います．

逆コンパイラの話は以前調べたことがあるのですが、中途半端で終わっていました。
また調べてみます。

> 以前，とらじさんが clppst を破棄しようとしていたときに，再配布の許可をくれなきゃ
> 逆コンパイルしてクローン作る覚悟と伝えたところ，許可された経緯がありました．

「逆コンパイルしてクローン作る」おお、出来るということですか。(ﾟ゜)☆＼(--#)ﾊﾞｷｯ
いや、そのキーワードが意味不明に思えたので。(^^;
あ、わかった、ソースを解読して別の物を作るということですか。(^^;
私にもそれくらいのスキルがあれば・・・
clppst.exe のソースを見てみましたが、まったくわかりませんでした。(>_<)

> 一応 facebook で繋がってはいるので，聞いてみるだけはできると思いますが，
> おそらくきっと絶対に「捨てたので残っていない」と言われることでしょう．

繋がっているのであれば、一度聞いてみてくれませんでしょうか。駄目もとで。m(__)m
当時は初期のリブレット使いだったので、もう動かないでしょうが、データはどうでしょう。
Win98時代ですものね。

CKWV111 の変更に漏れがありました。

・マウスでリサイズの時最小行数を10行に（VTDOSの指定可能行数は6行）V11.1

CKWV11 では、マウスでリサイズを解禁されました。
実際にやってみると、VTDOSの指定可能な6行まで一気に行を減らすことができます。
これは私の想定外で、数字指定ならいいのですが、マウスで6行になるのは流石にまずい気がしました。

そこで、CKWVでマウスでリサイズの時は、最小10行までになるように CKWV を変更しました。
10行くらいならリサイズしても問題が出ることはほぼ無いだろうという考えです。
この行数は、オプションで変更することも可能だと思うので要望があれば考えます。(^^;

CKWV にはまだまだいろんな可能性を感じますね。

CKWV マウスでリサイズ時はVZはコマンドラインでないと表示が異常になります。
その時にVZを正常化するマクロを作りました。

本当は CKWV のリサイズ時にVZに特定のキーを送れるのでそのマクロの
起動キーにしようとしたのですがうまくキーが遅れていないようです。
10♯さんのVZソースも導入してみましたがまだうまく動作出来ていないです。
メニューモードのときに問題が出るのは10♯さんのコードを導入すれば解決しそうですが。

とりあえず当分は、このマクロは表示の正常化用とすることにします。
画面サイズを変更したときに表示以上になった時もこのマクロで正常化できると思います。

=== resize.def ===

*m
;80 @R "表示行数切替え"		;2024-04-26  v0.52
80 ^\ "表示行数切替え"		;2024-04-26  v0.52
	(s>=3)?.			;窓モードなら終了
	(s==1)?.			;窓モードなら終了
	&s sx[-, 			; コンソール取り込み停止
	dx0, &08 w[, &00 w=vp.26,	; コマンド実行
 	&09 sx], &d .			; wa wb テキストの設定調整

00:	bx0, cx0,			; bx:桁 cx:行 ローメモリから取得
	&i("$(50,06,33,C0,8E,C0,26,8A,1E,4A,04,26,8A,0E,84,04,07,58,C3)")
	ax0,cx++,(lc!=cx)?{lc=cx,ax1,}
	(vp.26!=bx)?{vp.26=bx, ax1,}
08:     (s!=2)? { dx1,#E}		;コマンドラインに
	&?("ver >nul") #m &w(1)		;コマンド実行
09:     (wa)?? { (s==2)?{		;編集テキストが無ければ
        ep[-, #[ #[ ep], w], sx], .} }	;[ESC]2回で整えて終了
        (dx==1)? {ep[-, #[ ep], } 	;編集モードに(シフト実行時はスルー)
        &10 (wb)?{&s #W &10 #W } w], &d ;表／裏テキストの桁,行数調整
10: w=vp.26, we=w, wa.55=w, wa.56=lc-2, wa.57=lc-3, wv=w>>1, wh=lc>>1, kx=lx,
*

DOSVAXJ3 が更新されていました。
更新内容は

----------------------------------------------
build JP230707　(2023/7/7)

    Windows 版で IME ON 時のカーソルキー等の処理を修正しました。
    Windows 版で int 21h ah=43h のファイル属性の取得・設定が正常動作するように修正しました。
    Windows 版で mount されたドライブ上のファイルを読み込みモードで開いた場合でも日時変更可能となるよう修正しました。
    Linux、macOS 版でショートファイル名の生成がうまくいっていなかったのを修正しました。

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

IMEの変更部分はちょっとわからないですが
TOUCH などの日時変更も出来るようになったのでうれしいです。

作者様に感謝です。

暑中お見舞い申し上げます。

いやあ、暑いですね。(^^;;
エアコンをガンガン効かせたいけど、電気代も跳ね上がって懐だけ寒いです。(;_;)
そんなわけで、今年は工夫して省エネもしてみようと思います。

温水便座のヒーターはたぶん60Wくらい使っていると思います。
梅雨時も暑かったのでヒーターのSW を切ってみました。
座る時、ヒヤッとするので、まだ切るのは早かったようです。

そこで、ボリュームをランプが付くギリギリにしてみました。
これならヒヤッとはしないので、これで暫く使っていました。

そして、愈々猛暑になったので、SW を完全に切ってみました。
おお、ヒヤッとしない。(^^;

わずかの省エネですが、これからはこれで行こうと思います。(^_^)

うちは馬蹄形タオル地の便座カバーをかけています．
ヒーターのプラグを差すのは真冬だけですね．
しょっちゅう洗う必要はありますが，洗濯は毎日ですからついでみたいなもの．
（毎日干すのはかみさんだから大きな顔はできないですけど……）

わたしはクーラーや扇風機の風が苦手なのですが，ここは家族優先です．
この暑さでエアコンを使わないわけにはいかないですから．

> うちは馬蹄形タオル地の便座カバーをかけています．

同じく、便座カバーを使用しています。
以前は、一年中便座カバーだけでいられたものが、最近では冬はヒーターが必要と
感じるようになりました。年をとったんだと思います。

クーラーは決して苦手ではないのですが、温度差が苦手でして。
職場のように、どこも同じ温度なら２２度でも２６度でも大丈夫なんですがね。
自宅の場合、居室以外、つまり廊下とかトイレは冷房がありません。
そういうところが例えば３８度とかあると、居室が２８度でも体にこたえる。
こういう場合、冷房は設定可能な最大の３０度にしています。
体調重視なわけですが、結果的にある程度の省エネになっています。
とはいえ、この温度では熱中症になる可能性があるわけなので、水分補給は意識的
に行っています。

> うちは馬蹄形タオル地の便座カバーをかけています．
> ヒーターのプラグを差すのは真冬だけですね．
> しょっちゅう洗う必要はありますが，洗濯は毎日ですからついでみたいなもの．
> （毎日干すのはかみさんだから大きな顔はできないですけど……）

便座カバーは以前使っていました。
洗濯するにも他の物と一緒には出来ないから面倒ですよね。
うちも炊事洗濯はお任せなので（干し方にもこだわりがあるらしい）(^^;

百均の張り付け式便座カバーも試しましたが、今は使っていないようです。
洗って繰り返し使えるようですが、やはり面倒な面があるのかもです。

> わたしはクーラーや扇風機の風が苦手なのですが，ここは家族優先です．
> この暑さでエアコンを使わないわけにはいかないですから．

寝るときは、布団が暑いと熟睡出来ないのでエアコン付けっぱなしにしてますね。
私も冷たい風が苦手な方なので、フリースを着ることもあります。(^^;;

エアコンの風を弱にするのが省エネと思っている人がいるようですが
強にしたほうが部屋全体が早く冷えて省エネになるらしいです。
なので、寝る時も「静か」の上の「弱」にしています。

> 自宅の場合、居室以外、つまり廊下とかトイレは冷房がありません。
> そういうところが例えば３８度とかあると、居室が２８度でも体にこたえる。
> こういう場合、冷房は設定可能な最大の３０度にしています。

これはありますね、でも30度って、エアコンが強力すぎるのかな。
実はうちのリビングは猫のために開けっ放しにしているんです。
だから廊下との温度差はあまりないのだけれど、エアコンには負荷がかかりますね。
ドアを閉めれば省エネにはなるけれど、今はこのままいきそうです。

猛暑の時はエアコンも効きにくくなります。
そんな時は、雨戸を閉めるとだいぶ違います。

リビングの雨戸は一枚分閉めると眩しさ対策にもなり、良い感じです。
窓ガラスから熱気が入ってくるのでしょうね。
使っていない部屋なら全部閉めてもいいでしょう。
夏場はもうこのまま閉めっぱなしで行こうと思っています。

出窓のカーテンとかも工夫すればもっと遮熱出来るかな・・・

猛暑の時は電気ポットの周辺も暑いと言うので、電気ポットを止めてみました。
私はお茶が好きなので毎日何杯も飲むのですが、今年は水茶を試してみました。
奥様はコーヒー派なのですが、紙パックのアイスコーヒーに切り替えました。

お茶は90度のお湯を湯冷ましに入れて急須に注いで1分ほど蒸らして飲んでいますが
水茶なら水を入れて5分くらい置けば飲めると聞いてやってみました。
ホットの方が味わいがある気がしますがまあ何とか飲めますね。

私はカップ麺も好きで、たまに一人で食べているのですが、電気ポットが無いと不便です。
夏の間はやかんで沸かしてやるしかないですね。面倒です。(;_;)
電気代とガス代とどっちが省エネかはわからないですね。

省エネなら、魔法瓶タイプの電気ポットにすればいいのですが、デザインや色がいまいちで。(^^;

そうだ！　電気ポットの周りに断熱材かプチプチを巻いたらどうだろう・・・
何か良い素材とかありませんかね。

> これはありますね、でも30度って、エアコンが強力すぎるのかな。

そんなことはありません。
部屋の温度計、百均のものなんで精度はあまり当てになりませんが、一応、室温も
３０度になっています。

> 実はうちのリビングは猫のために開けっ放しにしているんです。

ネコドア付きのドアに変えましょう。
冷暖房共に、かなりの省エネになりそうです。

カーテンのように屋内で遮熱するより、雨戸も含め、窓の外で遮熱するのが好ましい
といわれていますよね。よしずとかすだれとか。

> リビングの雨戸は一枚分閉めると眩しさ対策にもなり、良い感じです。

まぶしさ対策も兼ねて、発泡緩衝材、いわゆるプチプチを窓に張る、というのは
いかがでしょうか。もともと冬場の断熱対策に有効という話を聞いたことがあるの
ですが、冬に効果があるのなら夏にだって効果があると思います。

単純にエネルギーを熱に変える場合、電気が一番効率が悪い、というのが定説。
もちろん、精密な温度制御だとかタイマーだとかを使う場合は電気を使うしかない
のですが、うちではそんな必要はないので、私は使うたびにガスで湯沸しすること
にしました。保温性能の高い魔法瓶があれば生活様式が変わるかもしれませんが、
わざわざ買うほどの事もないので。

> お茶は90度のお湯を湯冷ましに入れて急須に注いで1分ほど蒸らして飲んでいますが

本格的というか、私が小学校の家庭科で習った正式な入れ方です。
そんな方法、お客様が来たときにしかしたことがない。

水茶ですが、何年も前にNHKで紹介されていたので試したことがあります。
そのとき、私はおいしいと思ったのですが、ちょっと時間がかかりすぎて。
氷水を使うのですが、時間を覚えていない。１５分だったか２時間だったか。
ネットで探せばすぐに見つかりそう。

> そうだ！　電気ポットの周りに断熱材かプチプチを巻いたらどうだろう・・・
> 何か良い素材とかありませんかね。

簡単な方法なら、そのまま段ボール箱の中に入れる。
これなら段ボールの隅に電気コードが通る穴を開けるだけ。
ちょっと凝った人なら、二重段ボールにする。
段ボールと段ボールの隙間にはスポンジか何か。
安全性を極限まで気にする人なら、グラスウールかロックウール。
以前、炊飯器を分解したときに、中で使われていたのがその手の無機系ウール。
こいつらなら１０００度程度の熱にも耐えられるはずなんで、電気ポットを直に
覆っても大丈夫なはず。でかいホームセンターなら扱いがあるでしょう。
ただ、電気ポットの熱漏れって、どの方向からなんだろう。
もし、側面ではなく上面から熱が漏れるというのであれば、側面だけ覆ってもあまり
意味がない気がする。この場合、やっぱり箱詰めしかないような。

熱波回避ネタ２題

　ご無沙汰です。
　もう色々で色々で、クッタクタ。ボロボロです。そして、もちろん、超暑い。
　さて、お題の（節電にはあまりなりそうにないけど）この酷暑をやりすごす
ネタ２つ。１つは経験あり、１つは経験なし。

　（１）首を冷やす−−経験あり。
　小さな（４センチＸ６センチ）の保冷剤を冷凍庫で凍らせる。バンダナで
首に巻く。保冷剤は、後方うなじあたりに間接的に接する。かなりの効果です。
水やりでどうしても外にでなければならないとき、僕は必ずやってます。
　エアコンの室内でも、もちろん効果あります。「冷た！」とはなりません。

　（２）寝室の湿度を取る−−経験なし。
　２リットルぐらいのペットボトルに水を入れて、冷凍庫で凍らせる。寝る前に
空の洗面器にそれを入れておく。ボトルが汗をかき、それが洗面器にたまり、除湿
効果があるそうな。ＴＶ（ユーチューブかも）で、どっかの主婦様（節電女王みたい
な人）が、「効果あるんです！　安眠できますよ」と力説していた。僕は、あまり
やるとは思わないけど。それでなくとも寝室（書斎）が腐海３になりかけてるのに、
ごちゃごちゃさせたくないですからねぇ。冷凍庫もそんなに広くないし。


　どうでもいいこと。今日、学期末試験だったのですね。５０人の学生が真剣に
テストを受けてました。エアコンの効いた教室から窓の外をふと見ると、
この熱地獄の中、シャベルで土を掘ったり石を移動させたりしてる方々がおりました。
キャンパス内で現在、新校舎建築の工事、準備が進んでいるのです。学生にも思わず
こぼしてしまったのですが、「俺たちって、そんなに偉いんだっけ」と思ってしまった。
　この暑さのなか、僕なら１時間ともたずに熱中症になるだろうと思いました。
　ホワイトカラーってちょっとずるいのかも……。

　「自虐すきだねぇ、文太さん」あるいは「それ、格好をつけてるつもりなの？」
とか言われそう（思われそう）だから、先回り。
　でも、ほんと、そう思ったのだもの。

　さあ、しょうがない、水やりです。

> 部屋の温度計、百均のものなんで精度はあまり当てになりませんが、一応、室温も
> ３０度になっています。

うちのリビングの温度計を見てみたら、28度でした。これでも涼しく感じますね。

> > 実はうちのリビングは猫のために開けっ放しにしているんです。
> ネコドア付きのドアに変えましょう。
> 冷暖房共に、かなりの省エネになりそうです。

それはわかっていますが、話し合ってこうなったのです。
実は、リビングのドアは廊下側を塞ぐドアに改造してあるのです。
もちろんいつでもリビング側を閉めることも出来ます。
全ては猫対策のためです。(^^;

> カーテンのように屋内で遮熱するより、雨戸も含め、窓の外で遮熱するのが好ましい
> といわれていますよね。よしずとかすだれとか。

それで思い出しましたが、エアコンの室外機にすだれで日陰を作るのもありましたね。
とりあえず室外機の上に板を置いてちょっと日陰を作ってみました。

> まぶしさ対策も兼ねて、発泡緩衝材、いわゆるプチプチを窓に張る、というのは
> いかがでしょうか。もともと冬場の断熱対策に有効という話を聞いたことがあるの
> ですが、冬に効果があるのなら夏にだって効果があると思います。

プチプチは寝室の窓に張ったことがありますが、剥がれたのでそのままですね。(^^;
ああ、なんて怠惰なわたし・・・

> 　（１）首を冷やす−−経験あり。

もう１０年ぐらい前に、水で冷やすタイプの、チョーカーではないな、これは一体
なんていうんだろう、ネックストラップでもない、吸水性のある布製の帯をもらい
ました。何回か使ったのですが、あまり涼しく感じなくて、どこかにしまいこんで
あります。
最近、通販で、保冷剤入りなのかな、冷蔵庫で冷やすタイプですが、結露しないと
いう製品を見かけました。どういう仕組みで結露しないようになっているのか、
そういう構造的なほうに非常に興味があります。

> 　（２）寝室の湿度を取る−−経験なし。
> 　２リットルぐらいのペットボトルに水を入れて、冷凍庫で凍らせる。寝る前に

これ、私も話には聞いたことがあります。
ただ、うちも冷凍庫に余裕がないこともあって、試したことはありません。
それに、これ、閉鎖環境にはいいかもしれませんが、開放環境だと、外部からいくら
でも湿気が入ってくるため、全く意味がないような気がする。
ついでにいうと、必要になるエネルギーを考えると、全く省エネにはならないはず。
つまり、電気を電池に充電して持ち運ぶのと同様、冷熱を氷の形にして持ち運んで
いるだけ、ということ。そして、電池を充電する場合にいくらかのロスが発生する
のと同様、わずかなのか多いにかはわかりませんが、いくらかのエネルギーのロス
は発生するはず。もちろん、電池と同様、持ち運べることによるメリットは大きい
かもしれませんが。
ちなみに私、風が強すぎさえしなければ、扇風機の風の直撃を受けても熟睡できる、
というか、逆に風が当たらなければ暑くて寝ていられないと思う。


> キャンパス内で現在、新校舎建築の工事、準備が進んでいるのです。学生にも思わず
> こぼしてしまったのですが、「俺たちって、そんなに偉いんだっけ」と思ってしまっ

文太さんが疲れているのか、私が暑さのせいで壊れかけているのか。
なぜというに、なぜ文太さんが、自分たちを偉いと思ったのかがよくわからない。
この辺は私の個人的な経験のせいかも。
昔、まだ私がNTTに勤めていたころ、とあるデータセンターで配線工事をしました。
何人もで作業をしていたのですが、一番の下っ端である私の持ち場はサーバ室の冷房
の吹き出し口の前。
先輩方の多くは暑い屋外で、１日の仕事が終わってから私のことをうらやましがって
いましたが、こちらは凍死する思いでした。いや、マジで。

> 単純にエネルギーを熱に変える場合、電気が一番効率が悪い、というのが定説。

それは聞いたことがありますが、ガスで湯を沸かすと結構周りが暑くなりますね。
換気扇もかける必要があるし、部屋の冷気が逃げてしまいます。
やっぱり電気ポットをなんとかしたいですね。

> 氷水を使うのですが、時間を覚えていない。１５分だったか２時間だったか。

東京のおいしい水道水をそのまま注げば5分で済むと思いますよ。
氷水は時間が掛かるでしょう。今頃の水道水は20度くらいあると思うし。
氷は後で入れればいいと思います。

> 簡単な方法なら、そのまま段ボール箱の中に入れる。
> これなら段ボールの隅に電気コードが通る穴を開けるだけ。
> ちょっと凝った人なら、二重段ボールにする。
> 段ボールと段ボールの隙間にはスポンジか何か。

うーん、面白いですが、中が見えないのがちょっと・・・
移動もするので嵩張るのもまずいですね。

> もし、側面ではなく上面から熱が漏れるというのであれば、側面だけ覆ってもあまり
> 意味がない気がする。この場合、やっぱり箱詰めしかないような。

上は蒸気穴があるので塞げません。
とりあえずプチプチで試してみようかな。

> 　（１）首を冷やす−−経験あり。

首を冷やすのは効果があると言いますね。
以前冷感バンダナみたいなのを水で濡らして巻いたこともありました。

> 　（２）寝室の湿度を取る−−経験なし。

寝る時エアコン付けっぱなしなら湿度も取れそうですよね。
安眠できる効果があるのかどなたか経験談でもあれば・・・

> 　この暑さのなか、僕なら１時間ともたずに熱中症になるだろうと思いました。
> 　さあ、しょうがない、水やりです。

外でちょっと何かやろうとしても日差しの強烈さでまいってしまいますね。
麦わら帽子が欲しくなりました。(^^;

そっか、電気ポット、移動することもあるのですね。
うちで電気ポットを使っていた時はテーブルの上が定位置だったんですよ。
移動可なら、冷房を使っていない部屋で湯を沸かす、というのは冗談ですが、人に
よっては、あるいは場合によっては、それが最適解、ということがありうるのが怖い
ところ。

> 上は蒸気穴があるので塞げません。
> とりあえずプチプチで試してみようかな。

確認しておきたいのが、側面の温度。
手で触れないほど熱くなる、ということであれば、効果は高いと思いますが、別の
心配も。それは、あのプチプチの耐熱性能。８０度くらいで融けるとは思いません
が、融けてからでは手遅れかも。その場合、新聞紙を三重とか五重に巻いて、その
上からプチプチを巻く、という手もありそう。
逆に、手で触っても室温と変わらない、ということであれば、側面からの放熱はない
わけですから、手間やコストをかけてもムダ。やっぱり上面を何とかしましょう、
ということになる。例えば、蒸気穴の部分だけ切り欠けを作った段ボール箱、とか。

>ネックストラップ （みたいなのについて）
>通販で、保冷剤入りなのかな、冷蔵庫で冷やすタイプです
　うん、こんな感じ。結露についてはよくわからないけど、バンダナ
みたいなプリミティブでないのが商品化されていると、奥さまが言ってました。
でも、２千円とかするときいて、バンダナでいいよ、となってます。

>２リットルぐらいのペットボトルに水を入れて、冷凍庫で凍らせる。寝る前に置く。"
>閉鎖環境にはいいかもしれませんが、
　はい、エアコンを使える部屋で夜も窓を閉めて寝る都会タイプ仕様ですね。
　そういう雰囲気の家だった。
　ただその主婦様、全体に筋金入りっぽい人でしたから、いちおう全部計算して
ということだったと思います。必要なところではお金も電気もかける、と。
　でも、たしか４人家族一戸建てで、電気代が月５千円以下だったと思う。
　住居環境（たぶん都心）って、さまざまですからね。
　僕も昨晩、窓を２０センチ開けて寝ました。やっぱこれよ、と比較的安眠。

>文太さんが疲れているのか、私が暑さのせいで壊れかけているのか。
>なぜというに、なぜ文太さんが、自分たちを偉いと思ったのかがよくわからない。
　「偉い」より「ずるい」ですよ。
　その風景がねぇ。テストは１列おきに整然と並ぶ。そこでカリカリカリ。
かなり涼しげなわけですよ。エアコンの部屋で「暑いねぇ」とか言いながら。
　あのコントラストが、、、。

>冷感バンダナみたいなのを水で濡らして巻いたこともありました。
　これ、いいんじゃないですか。

>寝る時エアコン付けっぱなしなら湿度も取れそうですよね。
　エアコン消してから、というのがその方のやり方だったと思う。

>安眠できる効果があるのかどなたか経験談でもあれば・・・
　これがネック。心が安定していて心配がなければ、そして適度に
身体を使っていれば、寝れる、、、はず。寝ろ、寝れない、寝ろ、
寝れない。

>外でちょっと何かやろうとしても日差しの強烈さでまいってしまいますね。
>麦わら帽子が欲しくなりました。(^^;

　麦わら帽子。ルックス的にもこれですね。僕は会津の農民が使って
いたような、観光地みやげの竹製傘（帽子タイプ）をどっかに持って
いたはずなのですが。髪の毛がないと頭が熱い、、、。

> 確認しておきたいのが、側面の温度。
> 手で触れないほど熱くなる、ということであれば、効果は高いと思いますが、別の
> 心配も。それは、あのプチプチの耐熱性能。８０度くらいで融けるとは思いません
> が、融けてからでは手遅れかも。

側面がそんなに熱くなるボットがあるか知りませんが、これでも保温性の高い機種なので
側面はほんのり温かい程度です。
ただお湯が少ないと暑くなるというので、ヒーターのある底面が熱くなるのでしょうね。

> 例えば、蒸気穴の部分だけ切り欠けを作った段ボール箱、とか。

段ボール箱、好きですねぇ。(^^;
側面をプチプチで囲う話を奥様にしましたら、却下されました。(;_;)
それなら魔法瓶ポットが良いという話になって、1.5Lのポットを買いました。
どうしてこうなった？　(^^;

> >冷感バンダナみたいなのを水で濡らして巻いたこともありました。
> 　これ、いいんじゃないですか。

実際はハチマキみたいな帯で、ハチマキのように額に巻いたような気がします。
額ではあまり効果を感じなかったのか、すぐ使わなくなったような。(^^;
首に巻くタイプは奥様が使っているようです。

> >寝る時エアコン付けっぱなしなら湿度も取れそうですよね。
> 　エアコン消してから、というのがその方のやり方だったと思う。

げげ、エアコン消すのは試したくないですぅ。(>_<)

> 側面はほんのり温かい程度です。

うぅん、それだと側面にプチプチをまいたところで、効果は限られると予想されます。

> ヒーターのある底面が熱くなる

これも、本当に正しいのか確認するべきかと。
つまり、持ち上げて、今まで置いてあった場所を触って熱いかどうか。
仮に、そこもほんのり温かい程度であれば、上面を何とかしましょう、ということに
なる。
だけど

> どうしてこうなった？　(^^;

やっぱりこれが一番正しい選択肢のような気がする。
確実に効果がありそうですもの。
逆に、効果があるかどうかわからない対策に手間やコストを投じることに合理性や
正当性があるとはどうしても思えない。
もちろん、その手のことって大概楽しいことなので、合理性などを度外視するという
のはアリですが、でも、例えば、はがれたプチプチをそのままにしておくような人に
とって、はたしてそれは本当に楽しいことなのかどうかという、いささかの疑問が
わいてくるのは毎日が暑いせいだからかもしれません。

> それなら魔法瓶ポットが良いという話になって、1.5Lのポットを買いました。

これが一番だと思います．
わたしもカップ麺好きで，ときどきこっそり食べてますが，湯を沸かしたことはありません．
朝沸かした湯をサーモスの魔法瓶に入れてアレコレ使います．
余った湯は湯ざましとして使います．
魔法瓶は二台あって，一方は朝沸かした茶（季節ごとに烏龍茶，麦茶入替え）．
近ごろはティファールの「瞬間」湯沸かし器の出番がないですね．
電源つなぎっぱなしのポットは使ったことがありません．
真空断熱ポットの出現以来，魔法瓶の性能はすごく高いのですよね．

頻繁にコーヒーか紅茶を淹れるという人でなければ，電気ポットは要らないかな．

> それで思い出しましたが、エアコンの室外機にすだれで日陰を作るのもありましたね。
> とりあえず室外機の上に板を置いてちょっと日陰を作ってみました。

この関係をさまよっていたら見つけてしまったものが、貼るだけ簡単な断熱シート、
というやつなんですが、取り扱っているのが、下着メーカーのセシール。
ちょっとびっくり。
最新のいろいろな科学がつまっているのかな。

> > ヒーターのある底面が熱くなる
> これも、本当に正しいのか確認するべきかと。
> つまり、持ち上げて、今まで置いてあった場所を触って熱いかどうか。
> 仮に、そこもほんのり温かい程度であれば、上面を何とかしましょう、ということになる。

今は確認できませんが、お湯が少ない時は側面が熱かったと思います。
熱源は底面ですが、お湯が少ない時上部の空間が熱くなるのが伝わるのかなぁ？

> 逆に、効果があるかどうかわからない対策に手間やコストを投じることに合理性や
> 正当性があるとはどうしても思えない。

プチプチを巻くことで側面の放射熱は確実に減らせると思うので合理性はあると思います。

> もちろん、その手のことって大概楽しいことなので、合理性などを度外視するという
> のはアリですが、でも、例えば、はがれたプチプチをそのままにしておくような人に
> とって、はたしてそれは本当に楽しいことなのかどうかという、いささかの疑問が
> わいてくるのは毎日が暑いせいだからかもしれません。

毎日暑いのでプチプチ巻くのもだるいなぁと思っていたのでその意味では良かったかも。(^^;

> > それなら魔法瓶ポットが良いという話になって、1.5Lのポットを買いました。
> これが一番だと思います．
> わたしもカップ麺好きで，ときどきこっそり食べてますが，湯を沸かしたことはありません．
> 朝沸かした湯をサーモスの魔法瓶に入れてアレコレ使います．
> 余った湯は湯ざましとして使います．

みなさん魔法瓶派なのですね。

> 魔法瓶は二台あって，一方は朝沸かした茶（季節ごとに烏龍茶，麦茶入替え）．

そういえば私も会社には魔法瓶のお茶を持って行ってましたね。
家ではその都度入れればいいのですが、お出かけ時は検討してみようかしら。

> 近ごろはティファールの「瞬間」湯沸かし器の出番がないですね．

これも何度も検討したことはあるんですが・・・
私はやかんで湯を沸かすのは面倒で苦手なのです。(^^;

> 真空断熱ポットの出現以来，魔法瓶の性能はすごく高いのですよね．

＃　奥様は魔法使い、じゃなくて魔法瓶使いだったのです！
　　私の魔法瓶スキルはレベル１なので到底かなわないのです。(^^;

誤解がありそうなのでここだけ。

> みなさん魔法瓶派なのですね。

私の場合、電気ポットよりは魔法瓶、であることは間違いありません。
でも、どちらかというと、私の場合、ガスでその都度派、です。

> ＃　奥様は魔法使い、じゃなくて魔法瓶使いだったのです！

奥様と旦那様は、ごく普通の二人、ですか？
なんとなく、多方面から異議が発せられそうな気がします。

> この関係をさまよっていたら見つけてしまったものが、貼るだけ簡単な断熱シート、
> というやつなんですが、取り扱っているのが、下着メーカーのセシール。
> ちょっとびっくり。
> 最新のいろいろな科学がつまっているのかな。

何社かで同様の商品が出ているようですね。
以前テレビで、輸送トラック（保冷車・冷凍車）の庫内の温度上昇を抑えるために開発されたシールを見たことがあります。
シールを張ったトラックの側面を触ると、炎天下でもヒヤッとしているというので感心しました。
その技術を応用しているのでしょうね。
効果が高そうなので検討する価値はありますね。

＃　このシールを電気ポットの側面に張れば・・・ (ﾟ゜)☆＼(--#)ﾊﾞｷｯ

> 私の場合、電気ポットよりは魔法瓶、であることは間違いありません。
> でも、どちらかというと、私の場合、ガスでその都度派、です。

なるほど、ガスでその都度派、というのもありましたね。

> > ＃　奥様は魔法使い、じゃなくて魔法瓶使いだったのです！
> 奥様と旦那様は、ごく普通の二人、ですか？
> なんとなく、多方面から異議が発せられそうな気がします。

もちろんごく普通の二人ですよ。(^^;
ごく普通の二人がごく普通に結婚してごく普通の家庭を築く。
でも実は奥様は魔法瓶使いだったのです！
それ以来、魔法瓶の力で仕事も捗り、無事にやってこれました。

＃　魔法瓶の国からやってきた、ちょっとおちゃめな奥様は〜〜♪
　　魔法瓶の力で家中がお湯と笑いであふれるの〜〜♪

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

マクロバッファのオフセットアドレス $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)
ともに同様の振る舞いでした。

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

もっとテストしてから報告しろという見方もあるかと思いますが，
ともかく現象面から発現の有無を見てもらうのが手っ取り早いかと思い
お願いする次第です。

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

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

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

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

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

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

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

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

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

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

ということで、

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

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

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

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

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

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

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

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

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

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

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

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

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

これは、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 をメールでいただけないでしょうか。

再現できないということでしたので，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 で見てもこの周辺は異常が見つからなかったです。

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

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

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

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


＃　じょじょに奇妙な冒険は続くのか・・・
　　ハッ！　スタンドに攻撃されている！？　(ﾟ゜)☆＼(--#)ﾊﾞｷｯ

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

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

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

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

謎ですねぇ……

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

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

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

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

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

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

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

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

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

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

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

あ，製品版サンプルDEFにでっかい自前バッファを配置して，本当に1箇所なのか
検証してみるってのも一歩かな。それなら簡単だし。

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

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

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

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

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

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

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

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

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

残念、これは関係なかったですか。
でも 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バイト のはずが 500バイト増えてるとは、位置が悪いのかなぁ？

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

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

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

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

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

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


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

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

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

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

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

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

それはともかく，ですが

ばふつあで，その中黒に合わせて [UP]（コード表示）してみてください．
本当に中黒（8145h）なのか，未定義コード（例えば 8259h など）なのか確認できます．
未定義コードが中黒で表示されるフォントの場合がある（結構多い）と思われるので，
そこはきっちり確認した方がよいかと思います．

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

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

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

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


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

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

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

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

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

> もっとも最近は [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 以外に書換えが発生していないか確認してみようと思います．

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

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

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

他に検証方法を思いつかないなぁ……

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

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

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

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

ぷっ・・・　思わず笑ってしまいました。(ﾟ゜)☆＼(--#)ﾊﾞｷｯ
いや、冗談抜きで上手いですね。(^^;

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

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

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

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

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

手元の VZ.DEF は一通り眺めたのですが，自己書換えするようなコードないんですよ．

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

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


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

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

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

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

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


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

わたしもどうなっているのかわかりません．
他の人の環境では何が起こるかわかりませんね，楽しい！(笑)