#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  で判定しているもので。(^^;

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

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

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

K07v6_s.lzh を解凍すると

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

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

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

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

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

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

> 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 （クラスタ）。こんなにあるとは・・・・


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

ご苦労様です。

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は変更されていると思ってたけど日付は違うけど内容は同じでした。

何かが違うようです。

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

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

> > 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>

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

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でさえ読みづらく、ＤＯＳではまったく
読めないからです。検索もジャンプもうまくいかない場合が多い。
　あと、あと、あと、テキスト・フェチだからです。機械を使っている
＝使われているというのが、快感だから。

> #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 を設定すれば余裕ですよ。(^_^)

--- 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) の話は、まったくついて行けておりませんが。

現状の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つの不具合が起こっている可能性もあるかもです。

今回の問題が見つかったきっかけは、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だと、ＶｚとＤＯＳが速いんです。

> 　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は蟲探しの良い教材になりそうですね。(ﾟ゜)☆＼(--#)ﾊﾞｷｯ

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

　ＳＶＣのログです。

>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は、似たようなことをしてたわけですよ。

> >　◎「カーソル位置へ挿入」マクロで、挿入するファイルの最後の行長が 
> >    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の亡者ですから。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

*

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

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

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

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

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

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

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

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

;(2)

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

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

*


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

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

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

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

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

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

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

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


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

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

<cut>

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

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

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

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

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

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

ふと思いついて

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

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

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

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

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

VTDOS.TXTより引用

■ホットキー

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

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

これですね。

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

何故だろう。謎だ。

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

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

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

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

shadowさん、めざらさん、

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

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

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

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

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

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

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

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


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

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

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

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

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

*

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


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

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

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

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

shadowさん

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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



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

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

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



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

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

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



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

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

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

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

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

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

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

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

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

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

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


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


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

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

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

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


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

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

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表示はあるのですから。

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

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

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

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


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

#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