一括表示

　どうでもいいことです。
　どっかで聞いたことがあるような気がするなぁ、という記憶だったので、見つけたら
ちょっとだけ嬉しくなってしまい……。
　よくこんなことについての記憶の断片が、この脳みその中に残っていたもんだなぁ、
と。

c:\vzsrc\cmos\dos.asm 1095

;--- Allocate TPA --- (Transient Program Area == conventional memory)
	public	allocTPA	;上は僕が入れたメモなのかもしれません。
				;c.mosさんにこんなメモが必要か？　と。
;--- Free TPA ---
	public	freeTPA

;--- Get TPA top seg ptr ---
	TPAptr	proc

> それを受けて榊原さんが
> 
> > 　これだけ詳しく書いてもらえると、とってもヒントになります。ちゃんとバグ
> > が見つかって、手元のソースでは直しました。
> 
> 恐らく高橋版では直しているのではと思います。

最近のソースを確認してみたら、CORE.ASM の中に

;--- Check block ---
chktblk	proc

  _if z
	add	ax,[bp].ttop		; ##1.5
    	jc	chkt1			;#s16		
	mov	dx,ax
	add	dx,[bp].bofs
    	jc	chkt1			;#s16		
	cmp	dx,cx
	je	noblk
	jb	chkt_a
  _else
chkt1:	mov	ax,0FFFFh
	mov	dx,ax
  _endif


こんなコメントがありました。
#s16 は、高橋さんが榊原版VZ.COM を解析した変更点だと思います。

 jc	chkt1			;#s16		
は、オリジナルVZでは無いので、榊原さんが追加したのだと思います。

 add の加算命令は、8000hを超えるとキャリーオーバーになってマイナスになります。
 jc はキャリーフラグで分岐するので、分岐先で補正するようにしたと思われます。
 
ここが該当のルーチンかはわからないですが。(^^;


＃　文太さんもお元気そうでなによりです。

core.asm

　お遊びです。ご存知のとおり、深いところに行く（行ける）予定も願望もありません。
　誰かの何かのちょっとした刺激になったりすれば、幸いです。

　以下は、core.asm上で、「\x ^;--- [A-Z]」の検索文字列をグレップしたものです。
多謝＞grep.def by Sakakibara.

　主なプロシージャ（お仕事単位）を拾っているつもりです。
　何が心臓に（最初の地点に）入ってるのだろう？　それだけです。ただ、心臓だけではなく
dos.asmとかdisp.asmとかあるので（基本＝心臓）、これだけ見てもワケワカだよな、という
感想でしたが。

;--- Do Tab ---				；c.mosさん的には、タブ処理は最初に
					；片付けたい処理？
;--- Load to Line buffer ---		；ラインバッファ、エディタの（Ｖｚの）基本
;--- Save from Line buffer ---		；テキストバッファに戻す？
;--- Close Line buffer ---
;--- Scan line start ptr  ---		；はて？
					；編集中のファイルの行先頭をいちいち確定保存？
					；どのバッファにカーソルがあるか、かなぁ？
;--- Scan field start ptr ---		；フィールドってなんだ？
;--- Scan field start ptr ---
;--- Redraw screen ---			；表示が基本。でないと見えない（動いてない場合）
;--- Display one line ---		；高速の秘訣、らしい
;--- Check block ---			；ブロック操作も基本なのか。
;--- Display full screen ---		；表示。おお、下半分は分割されていたのか
;--- Display lower screen ---
;--- Set home/bottom line number ---	；行数管理（20行とか25行とか、vtextとかありますね）
;--- Clear message line ---		；メッセージラインも大事（21行目、26行目？）
;--- Set location(x,y) from cursor point ---	；カーソルのcpから？
;--- Set edit point from location(x,y) ---	；cpに対してedit point
;--- Adjust by cp ---			；何を調整するのだろう？
;--- Adjust by field ---		；フィールドってなんだ？
;--- Set line top/end ptr ---		；行単位が基本
;--- Set bend ---			；bend=ラインバッファ end
;--- Set home ptr ---
;--- H screen adjust ---		；表示
;--- V screen adjust ---
;--- Vertical scroll ---		；カーソル移動（↓↑）でcpも表示も変わるよね。

　ぜんぜん足りないはず。main.asm, text.asm, dos.asm, disp.asm, ledit.asmと、同時に
構想されてなければ、MS-DOSエディタとして動くはずがないですね。

　いえ、タブはいいとして、ブロック処理がここに……。ブロックの処理も１行単位で行って、
高速でラインバッファの入れ替えがされてるから？

　しかし、こうやってみると、美しいソースだ、とは思う。
　ここまで美しくきっちり書かないと、複雑すぎて、動くものにならなかったのだろう。

　たぶん、表示を絡めた行のことでしょう。
　誰かに言われそうな気がしたので。
　でも、もう先はございません。

-----------------------------------------------
@WD @Wd @wd @fldsz 
各種モード
　WD  *   デフォルトの表示カラム数
　  (80)  <2〜250>  fldsz
　  全テキストで共通
  > We  編集中のテキストの表示カラム数
-----------------------------------------------
-----------------------------------------------
@WE @We @we @fsiz @wa.57 
各種モード
　We  *   編集中のテキストの表示カラム数
　  ($WD)  <2〜250>  fsiz  wa.57
　  編集テキスト変数
　  初期値は WD に設定される
  > WD  デフォルトの表示カラム数
-----------------------------------------------
　※fldszもfsizもfield sizeの略だと思われますが、fsizって、
　　覚えてられるの？　szとsiz。他にもこのペア、あるのかな？

　なるほど、それでタブ処理がcore.asmに入っていたのか。core.asmは
かわいいです。行編集（Ｖｚのコアな仕事）の出し入れ、表示が、ひととおり
小さく入ってる。
　より細かくは、ledit.asmへどうぞ。

　で、main.asmは？　coreとmainはどういう関係？　main.asm、見た瞬間、
頭痛と吐き気がどばっと襲ってきました。
　編集にいたるまでの起動で、vz.defは読みこむは（とうぜん、各種バッファ
サイズなどが設定できる）、テンポラリーファイルの管理はあるは……。
　ほとんど狂気。作者は天才。すげえ記憶力と集中力だったのだろう。
　「人間が書いたものです。読めないはずがありません」
　「いえ、ふつう読めないと思います」

　何年かぶりに、FGALDCのログをグレップしました。みんな、すごいです。
　青春をかけた人たち。

konnoさん、すいませんね、いつものように暴走してしまって。
　ああ、また孤独な独り遊びをしてしまった。
　いえ、konnoさんなら、経験的に知っているだろうと思ったのです。

c:\vzsrc\cmos101
macro.asm  22,836  1989-06-30  10:01
c:\vzsrc\cmos (v1.6の)
macro.asm  42,233  2018-09-27  02:16	；タイムスタンプいんちき
					；４年前に何をしたのだろう？

　オリジナルディスクに、v1.01のソースも入っていたんですかね？
たぶん、そうでしょうね。

　ＥＺからＶｚになったとき、すでにmacro.asmはあった。
　Ｖｚは、最初っから、完成品として発表されたのでしょう。商品化された
のだしね。「マクロのないエディタなんて」という意図で。きっとプログラマ
としての意地と自尊心もあったでしょう。あっぱれ。しかし、おそらく、
旧８用オンリー。

　＆Ｓ系関数とかイベントマクロとかマクロバッファのセグメント移動とか
（他はもうほとんど思い出せない）、v1.6でマクロ機能が相当強化されたのは
噂で知ってます。でも、僕が有難がるような「切った貼ったのエディタマクロ」は、
きっと、v.1.01でも書けたのだろう。
　しかし、初版から最終版までで、倍弱の太り方。全国のユーザから支持され、
マクロ師たちもいっぱいいたわけで、そうなりますかね。

　僕は、もちろんv.1.6からのユーザなので、経験としては、それ以前の
ことはいっさい知らないのですが。

　なんの整理にも情報の修正にもならないと思いますが。

> #4791 Ek-（追試３） 文太 2022/06/19(Sun) 01:07

　おそらく僕は上のあたりで、不具合再現に初めて成功（！）したはずなのですが、
それ以来、一貫して以下のエスキ・デフファイル（＋僕の常用環境、つまり製品版
の使用なし）で実験し結果を報告してきました。常用vz.defでは、ek+ だった
ものですから、あっちこっちでそれを修正すると戻すのが大変になる（ekについて
は忘れることにする）というやり方をしてきました。


org_esci.def  464  2022-06-23  00:41

=== Macrotmp by B ===;c.mos版エスキ
* M
8 @I "I カーソル位置へ挿入"
	?. (mr==$80)?{ &m(36) . }
	ek[-,			;追加

（マクロ本体略）

:Z	&m("") ek], .		;追加
*

　ただいま修羅場な時期なので、その後、この方面の実験はまったくやって
おりませんが、テストをそこそこ集中的にやっていたときには、各種報告のとおり、
かなり安定して（不規則性や不条理性を含む）、不具合は発生してくれていました。

　ek+, で不具合には出会っていないということなのですが、何か別の条件が入ると、
ek+, でも起こるのですかね？　ここ、追求・追試の意志はまったくありませんけれど。

　これから大きな発見と展開がなければ、まあ、これでお終いかな、という感触
でおります。

　最後に、0007.cgi + 0007.cg での、ＥＫ（＃Ｂ）の有効範囲（？）をみてみたい
と思います。オリジナル 0007.cgiと、その１５、１６、１７、１８、１９、２０行目まで
のファイルの計７つが対象。これらに 0007.cg を挿入する。
　ＥＫ＋の場合とＥＫ−の場合の２通り。つまり、１４回の実験。(^^;

　もちろん、２０行目までのファイルは１５から１９行の部分も含みます。でも、
出たり出なかったりするのですよねぇ、これが。不条理。

　ＥＫ＋でも不具合が出てくれると、原因がＥＫ（＃Ｂ）以外にもあるのだろう、
くらいになるのかな、という仮説、空想。

【結果】--- やばい
		EK-	EK+
0007.cgi	NG	OK
15.txt		OK	OK
16.txt		OK	OK
17.txt		OK	OK
18.txt		OK	OK
19.txt		OK	OK
20.txt		OK	OK


【道具＆前準備】

--- 1.bat ---
REM get n-line files (15-20)

sed32 -e "15q"	0007.cgi > 15.org
sed32 -e "16q"	0007.cgi > 16.org
sed32 -e "17q"	0007.cgi > 17.org
sed32 -e "18q"	0007.cgi > 18.org
sed32 -e "19q"	0007.cgi > 19.org
sed32 -e "20q"	0007.cgi > 20.org
-------------

> copy & save & ren *.org *.txt

--- 2.bat ---
REM record line length 1 ; Use after ESCI macro

gawk -f line_len.awk 15.txt > 15.len
gawk -f line_len.awk 16.txt > 16.len
gawk -f line_len.awk 17.txt > 17.len
gawk -f line_len.awk 18.txt > 18.len
gawk -f line_len.awk 19.txt > 19.len
gawk -f line_len.awk 20.txt > 20.len
-------------

--- 3.bat ---
REM get the correct answer file	

cat 0007.cg 15.txt > 15.ans
cat 0007.cg 16.txt > 16.ans
cat 0007.cg 17.txt > 17.ans
cat 0007.cg 18.txt > 18.ans
cat 0007.cg 19.txt > 19.ans
cat 0007.cg 20.txt > 20.ans
-------------

--- 4.bat ---
REM record line length 2 ; Use on ANS file

gawk -f line_len.awk 15.ans > 15a.len
gawk -f line_len.awk 16.ans > 16a.len
gawk -f line_len.awk 17.ans > 17a.len
gawk -f line_len.awk 18.ans > 18a.len
gawk -f line_len.awk 19.ans > 19a.len
gawk -f line_len.awk 20.ans > 20a.len
-------------

--- line_len.awk ---
{ printf("%d	%d\n",NR,(length($0))) }
--------------------

--- 5.bat ---
REM get the difference 1

diff 15.ans 15.txt > 15.dif
diff 16.ans 16.txt > 16.dif
diff 17.ans 17.txt > 17.dif
diff 18.ans 18.txt > 18.dif
diff 19.ans 19.txt > 19.dif
diff 20.ans 20.txt > 20.dif
-------------

--- 6.bat ---
REM get the difference 2 (comp line length if necessary)

diff 15.len 15a.len > 15_.dif
diff 16.len 16a.len > 16_.dif
diff 17.len 17a.len > 17_.dif
diff 18.len 18a.len > 18_.dif
diff 19.len 19a.len > 19_.dif
diff 20.len 20a.len > 20_.dif
-------------


>dir		;最終的な場面。あああううう、いつもの不具合が出ない〜。
		;いままでと違ったのは、WinMEで（こっちのほうがＶｚは楽）
		;根性をふりしぼってやった点。だってぇ、やる気にならないんだもの。
		;はい、実験失敗ということでした。

0007-I   CGI       302,888  22-06-18  23:00 0007-I.CGI
0007     CG        132,553  22-06-18  23:00 0007.CG
MEMO     TXT         2,554  22-07-27  17:37 MEMO.TXT
ORG_ESCI DEF           464  22-07-27  17:39 ORG_ESCI.DEF
3        BAT           210  22-07-27  16:40 3.BAT
4        BAT           280  22-07-27  16:49 4.BAT
5        BAT           202  22-07-27  17:06 5.bat
15       TXT       175,047  22-07-27  17:39 15.txt
15       ANS       175,047  22-07-27  17:32 15.ans
16       TXT       178,491  22-07-27  17:39 16.txt
16       ANS       178,491  22-07-27  17:32 16.ans
17       TXT       180,127  22-07-27  17:39 17.txt
17       ANS       180,127  22-07-27  17:32 17.ans
18       TXT       181,699  22-07-27  17:40 18.txt
18       ANS       181,699  22-07-27  17:32 18.ans
19       TXT       184,399  22-07-27  17:40 19.txt
19       ANS       184,399  22-07-27  17:32 19.ans
20       TXT       185,410  22-07-27  17:40 20.txt
20       ANS       185,410  22-07-27  17:32 20.ans
15       DIF             0  22-07-27  17:40 15.dif
16       DIF             0  22-07-27  17:40 16.dif
17       DIF             0  22-07-27  17:40 17.dif
18       DIF             0  22-07-27  17:40 18.dif
19       DIF             0  22-07-27  17:40 19.dif
20       DIF             0  22-07-27  17:40 20.dif

直接的には#4888に対するレスのようなものです。
あちらは私の常用環境に対するものなので、製品版の環境での追試を兼ねて、
今後どのようなことをやっていこうか、という宣言のようなものです。
要は、網羅的というか絨毯爆撃というか。
すなわち、結果は表形式にまとめられるだろう、ということです。
以下は、今回改めて追試した結果ですが、結論的には、私の常用環境における
ものとの差異は発生しませんでした。
なお、結果は異常挿入、正常挿入、１バイトずれのそれぞれ略称となっています。


先に開いて   あとから挿入 ファイル
いたファイル するファイル サイズ   Bl
                                   6144 8191 8192 cf.   8193 16384
0007.CGI     0007.CG      132553             異常 #4609
170335       00070033.CG   73620             正常 #4888
             00070034.CG   75539             １バ #4888
             0007-024.CG   72650             正常 #4888
             0007-023.CG   75267             １バ #4888
                                             
0010.CGI     0007.CG      132553             異常 #4780
27981        00070034.CG   75539             正常 #4888
             00070035.CG   77436             １バ #4888
             0007-005.CG  116642             正常 #4888
             0007-004.CG  119396             １バ #4888
                                             
0010-2.CGI   0007.CG      132553             異常 #4840
27932        00070034.CG   75539             正常 
             00070035.CG   77436             １バ
             0007-024.CG   72650             正常 
             0007-023.CG   75267             正常 
             0007-005.CG  116642             正常 
             0007-004.CG  119396             １バ 
                                             
0010-1.CGI   0007.CG      132553             正常 #4840
27931

0011.CGI     0007.CG      132553             異常 #4883
27933        00070034.CG   75539             正常 #4888
             00070035.CG   77436             １バ #4888
             0007-005.CG  116642             正常 #4888
             0007-004.CG  119396             １バ #4888


明日は台風で篭城する羽目になりそうだから、この表の穴埋めがたっぷりできそうです。
 

> 明日は台風で篭城する羽目になりそうだから、

篭城はしていたのですが。

> この表の穴埋めがたっぷりできそうです。

さすがに、これだけにかまけているわけにも行かず。
とはいえ、一通り表を埋めることはできました。

さて、結果一覧を出す前に。
今回、手順としては、#4712と同じシーケンスです。
すなわち、CMD.EXEからcommand.comを起動し、それから製品版Vzを起動（常駐）という
手順を踏みました。めざらさんのようにコマンドラインオプションでBlを指定しても
よかったのですが、そうすると私の場合、うっかりオプション指定ミスというのを
やらかす恐れがあるので、いちいち.defファイルを書き換えています。
また.defファイル書き換え後に少なくとも１回、コンソールファイルから[ESC]@でBlの
値を表示させて、書き換えた値が反映されていることを確認しています。
なぜ、こんなことをくどくどと書いたかというと。
うちのWinXPの場合、CMD.EXEから直接Vzを起動すると、EMSが取れません。だけど、
command.comからVzを起動するとEMSが取れます。今回、何回も起動させているうちに
手順を誤ったことがあって、それで気がつきました。
そして、今回の一連の実験では手順を統一するという意味もあって、全て#4712と同じ
手順、すなわちcommand.com経由、つまりEMSが取れる環境で行っています。

ということで、以下、結果です。

先に開いて   あとから挿入 ファイル
いたファイル するファイル サイズ   Bl
                                   6144  8191  8192  8193  16384
0007.CGI     0007.CG      132553   異常  異常  異常  異常  正常
170335       00070033.CG   73620   １バ  正常  正常  正常  正常
             00070034.CG   75539   １バ  １バ  １バ  １バ  正常
             0007-024.CG   72650   １バ  正常  正常  正常  正常
             0007-023.CG   75267   １バ  １バ  １バ  １バ  正常
                          
0010.CGI     0007.CG      132553   正常  異常  異常  異常  異常
27981        00070034.CG   75539   正常  正常  正常  正常  正常
             00070035.CG   77436   正常  １バ  １バ  １バ  正常
             0007-005.CG  116642   正常  正常  正常  正常  １バ
             0007-004.CG  119396   正常  １バ  １バ  １バ  １バ
                          
0010-1.CGI   0007.CG      132553   正常  正常  正常  異常  異常
27931                                                            
                                                                 
0010-2.CGI   0007.CG      132553   正常  正常  異常  異常  異常
27932        00070034.CG   75539   正常  正常  正常  正常  正常
             00070035.CG   77436   正常  正常  １バ  １バ  正常
             0007-024.CG   72650   正常  正常  正常  正常  正常
             0007-023.CG   75267   正常  正常  正常  正常  正常
             0007-005.CG  116642   正常  正常  正常  正常  １バ
             0007-004.CG  119396   正常  １バ  １バ  １バ  １バ
                          
0011.CGI     0007.CG      132553   正常  異常  異常  異常  異常
27933        00070034.CG   75539   正常  正常  正常  正常  正常
             00070035.CG   77436   正常  １バ  １バ  １バ  正常
             0007-005.CG  116642   正常  正常  正常  正常  １バ
             0007-004.CG  119396   正常  １バ  １バ  １バ  １バ

なお、この表はExcelで作ってテキストで出力したあと、整形するに当たりsaki...さん
のcols.defを使わせていただいております。


なんというか、なかなか面白い結果となりました。
特に面白いと思ったのは、あとから0007.CGファイルを読み込ませるとき、先に開いて
いたファイルのサイズとBlの値によって、きれいに挙動が変化する部分。すなわち、
以下のところですね。

先に開いていた　 Blの値
ファイルのサイズ 8191  8192  8193  
27931バイト　　　正常　正常　異常
27932バイト　　　正常　異常　異常
27933バイト　　　異常　異常　異常

また、Blを16384まで大きくすれば常に正常挿入になるかと思ったけどそうはならない、
という部分もなかなか興味深いところ。


今回の結果が完全にランダムなら、もはや追跡不可ということであきらめようかとも思い
ましたが、なかなか論理的な挙動を示しているようなので、もう少し追い込んでみたいと
思います。が、さて、どうしたものか。
とりあえず、あとから読み込ませるほうのファイルをいじるときりがなくなるので、
当面は先に開いておくほう、すなわち.cgiファイルとBlの値だけをいじって少し遊んで
みたいと思います。
 

ちょっと間が空いてしまいました。

> なかなか論理的な挙動を示しているようなので、もう少し追い込んでみたい

> 当面は先に開いておくほう、すなわち.cgiファイルとBlの値だけをいじって少し遊んで

遊んでみました。
とりあえず、前回の結果の再掲。

> なんというか、なかなか面白い結果となりました。
> 特に面白いと思ったのは、あとから0007.CGファイルを読み込ませるとき、先に開いて
> いたファイルのサイズとBlの値によって、きれいに挙動が変化する部分。すなわち、
> 以下のところですね。
> 
> 先に開いていた　 Blの値
> ファイルのサイズ 8191  8192  8193  
> 27931バイト　　　正常　正常　異常
> 27932バイト　　　正常　異常　異常
> 27933バイト　　　異常　異常　異常

これの続きを試してみました。

先に開いていた　 Blの値
ファイルのサイズ 8190  8191  8192  8193  8194
27930バイト                        正常  異常
27931バイト　　　      正常　正常　異常
27932バイト　　　      正常　異常　異常
27933バイト　　　正常  異常　異常　異常
27934バイト      異常

おぉ、なんと美しい。
ただ、konnoさんの報告から、Blをある程度減らすと、170KBほどある元の0007.CGIでも
ＯＫになってしまうらしい。
つまり、どこかに何らかの不連続点があるらしい。
まずはこの不連続点を追跡してみたいと思います。
 

残念ながら，こちらの環境では状況に変化はありませんでした。

 Bt64     Bf4096   Bo32768  EM1010   XM0      Bm4108   Ba2      Hs256
 Hf256    Hx128    Ha64     Hw64     Bl2048   Bc1024   Bu64     Bv1024


ところで，今回知ったのが，コマンドラインでの拡張子無指定実行での挙動とか。
以前，VTDOS のウィンドウ内で一度 VZ を終了して，
VZO.COM/VZO.DEF に改名した製品版 VZ を起動する VZO.BAT を実行し
製品版環境における実験をしていた……と思っていたところ……
C\VZ>VZO の実行では VZO.BAT でなく VZO.COM が起動されるということに
突然気づいてしまった。。。　えー？！　そうだったけ？？

起動時のファイル名入力窓の下に「EMSを最大1024…」と表示され，
「-EM1010」を書き加えた VZO.BAT を実行していないことに気づいた。

……と思ったけれど，先に起動していた個人用 VZ を終了したときには
既に VWX とか常駐しているわけだから，単純に VZO.COM 実行でいいはず。

……なんだ，VZO.BAT を書き換える必要なんてなかったんだ。…なんて
朝からボケボケです。。。朝だからか。。。
そもそも VZO.BAT なんて，どうして作ったのだろう。要らんのに……

ちゃんちゃん。
…というわけで再度ケチロンを。
EM1010 でも，当方の環境ではブロックの入れ替え（もっと激しいけど）は
製品版環境においては依然として発生しています。
なお，自分の常用環境（1.60t03k k07t1）では発生しません。

テンポラリファイル管理？

黒本　p.77 より

-------------------------------------------------------------------------
■テンポラリファイル
　64KBを超える（黒本、字が間違ってる）大きなファイルを編集する場合は、
メモリには64KB しか読み込まず、その前後を「テンポラリファイル」に出力します。
　Ver1.6では、EMS、XMS、TMPを、一元的に合計16MBまで管理できます。従来
EMSは2MBまでした確保できませんでしたからより大きなファイルを高速に編集
できます。ただし（略）

　編集テキストのテンポラリファイルは、
　　XMS -> EMS -> TMP
の順番で使用します。ＴＭＰディレクトリに作成されるファイルは「VZTEMP.$$$」
というただ１つのファイルです。
-------------------------------------------------------------------------

　高橋版以降、「ただ１つのファイル」ではないですよね。窓ごと？

　僕が前にこの件で言及したときには、手元に黒本がありませんでした。
　で、そのとき考えたのは、テンプファイルをＥＭＳに作る？　という点でした。
ディスクとメモリは管理の仕方が違うだろう、ＥＭＳにテンプファイルが作れるのか？
と。でも、そうは書いていない。「VZTEMP.$$$」は「ＴＭＰディレクトリ」を使う
ときのみなんだろう。XMS,EMS,TMPと全部使って１つのテンプファイルとかは
あり得ないんだろう（想像）。完全に「一元的」ではないのだろう。
　ほんとにシームレスに、連続で、「一元的に」やれるのかなぁ？　試さないけど。
　しかし、メモリに載った部分の「前後」って。どんな管理をしてるのだろう？
　64KBを超すファイルを５つ読み込んだら、どうなるんだろう？　それでも、VZTEMP.$$$
は１つなの？　きっとそうなんだろう。かなり特殊な処理なんでしょうね？？？

　分からない、分からない、と言ってるだけです。
　ほんとDOSの基本からおさらいしています。if errorlevel 253 goto ...
これがマスターできるのに、２時間！　意外に資料がないんですよねぇ。『MS-DOS
エンサイコロピディア』を最初からあたればよかった。

　僕は選択的です。けっきょく一生（残りわずか）ＤＯＳでいくのでしょうが、
そこでは選択的でなければ、ぜったいムリ、と悟りました。雑草取りも大変だし。
とほほ。
　あ、ちなみに、興味がおありではないと思いますが（現実的に）、世界には、
やっぱり今もＤＯＳ（MS-DOSだけではないけど、それが中心）にこだわり続けている人が
けっこういます。もちろん、レベルは超高いのですが。ＰＣの黄金時代だったんでしょうね。
アマチュアが趣味で手をだせるＯＳの時代だった。Google のなにやらグループを覗きました。
かつてはYahooにグループがあって、そこではsedについて教えてもらってました。すいません、
英語の世界です。
　今時フロッピーをニョゴニョゴいわせているのは、世界では、僕だけではありません
でした。ちょっと安心しました。


追伸：あまりちゃんと管理していないのですが、僕は VTDOS@Win7 では、なぜか、
ＥＭＳ　最大　80 　ページだそうです。どうせそんなに大きなファイルを編集
しないじゃん、せめて、これぐらいのところで安定してくださいよ！（祈り）　
というところだったのだろうと思います。
　そういえば、最近、落ちてないと思う。そこそこ使ってますけどね？
　というか、ここ３か月ぐらい、むちゃくちゃ使っています。コマンドラインには
あまり降りてないかな。コマンドラインがしがしなのは、WinMEでのことなので
しょう。

追伸２：当然ですが、僕はMS-DOS 6.20 の環境で、ＤＯＳの実験を主にしています。
VTDOSには、Ｖｚを【使う】という意味ではすごく大きな問題はないと思いますが
（あるのかな？）、ＤＯＳを使うという意味では、違うな、と思う場面が多々
ありました。masm 6.00 がＦＤからインストールできないとか。「なんでsetup.exe
が仕事しないんだ？」ではなく、「またダメなの？」でした。

> つまり、どこかに何らかの不連続点があるらしい。
> まずはこの不連続点を追跡してみたいと思います。

追跡してみました。

> 先に開いていた　 Blの値
> ファイルのサイズ 8190  8191  8192  8193  8194
> 27930バイト                        正常  異常
> 27931バイト　　　      正常　正常　異常
> 27932バイト　　　      正常　異常　異常
> 27933バイト　　　正常  異常　異常　異常
> 27934バイト      異常

> ただ、konnoさんの報告から、Blをある程度減らすと、170KBほどある元の0007.CGIでも
> ＯＫになってしまうらしい。


これらの状況から、当初、以下のような結果が出ると予想しました。


先に開いていた　Blの値　　　　　　　　　｜→　ここから先は未定義領域
ファイルサイズ　........................8192........................
↓　　　　　　　　　　　　　　　　　　　　　　　* 　　　　　　　　　
増　　　　　　　　　　　　　　　　　　　　　　* 　　　　　　　　　　
加　　　　　　　　　　正常領域　　　　　　　* 　　　　　　　　　　　
　　　　　　　　　　　　　　　　　　　　　* 　　　　　　　　　　　　
　　27931 　　　　　　　　　　　　　　　* 　　　　　　　　　　　　　
　　　　　　　　　　　　　　　　　　　* 　　　　　　　　　　　　　　
　　　　　　　　　　　　　　　　　　* 　　　　　　　　　　　　　　　
　　　　　　　　　　　　　　　　　* 　　　　　　　　　　　　　　　　
　　　　　　　　　　　　　　　　* 　　　　　　　　　　　　　　　　　
　　　　　　　　　　　　　　　* 　　　　　　　　　　　　　　　　　　
　　　　　　　　　　　　　　* 　　　　　　　　　　　　　　　　　　　
　　　　　　　　　　　　　* 　　　　　　　　　　　　　　　　　　　　
　　　　　　　　　　　　　* 　　　　　異常領域　　　　　　　　　　　
　　　　　　　　　　　　　* 　　　　　　　　　　　　　　　　　　　　
　　　　　　　　　　　　　* 　　　　　　　　　　　　　　　　　　　　
　　　　　　　　　　　　　* 　　　　　　　　　　　　　　　　　　　　
　　　　　　　　　　　　　* 　　　　　　　　　　　　　　　　　　　　
　　　　　　　　　　　　　* 　　　　　　　　　　　　　　　　　　　　

そこで、まず、Blの値、および先に開いていたファイルサイズをそれぞれ2KBずらして
網を張ってみました。結果。

先に開いていた　 Blの値
ファイルサイズ　 6142  6143  6144  6145  6146
29978バイト　　　異常　　　　　　　　　　異常
29979バイト　　　　　　　　　　　　　　　　　
29980バイト　　　　　　　　　　　　　　　　　
29981バイト　　　　　　　　　　　　　　　　　
29982バイト　　　異常　　　　　　　　　　異常

おや、これはいささか想定外。
だって、Blをへらしたのだから、上記の図の境界線、または正常領域に入っている、
と思っていたのですよ。
そこでBl6144のときに、どこまでファイルサイズを小さくすれば正常挿入となるか
追いかけて見ました。すると、29404バイトのファイルなら、正常挿入となりました。
次に、29404バイト前後のファイルでBlの値を様々に変えて試しました。
結果。

先に開いていた　 Blの値
ファイルサイズ　 6142  6143  6144  6145  6146
29403バイト　　　　　　　　　　　　正常　正常
29404バイト　　　正常　正常　正常　正常　正常
29405バイト　　　異常　異常　異常　異常　異常
29406バイト　　　異常　異常　異常　異常　　　
29407バイト　　　　　　　　　異常　　　　　　

あらま。これも想定外。
そして、この横一線のスレッショルドと、上記のBl8192付近の斜めの線が交わる、
Bl6720付近における、Blの値とファイルサイズを変化させたときの実験結果が以下。

先に開いていた　 Blの値
ファイルサイズ　 6717  6718  6719  6720  6721  6722
29401バイト　　　　　　　　　　　　　　　　　　正常
29402バイト　　　　　　正常　　　　　　　正常　異常
29403バイト　　　　　　正常　正常　正常　異常　　　
29404バイト　　　正常　正常　正常　異常　　　　　　
29405バイト　　　異常　異常　異常　　　　　　　　　
29406バイト　　　　　　異常　　　　　　　　　　異常

おぉう、なんてことだ。
すなわち、結果としては、以下のようになります。

先に開いていた　Blの値　　　　　　　　　｜→　ここから先は未定義領域
ファイルサイズ　.............6720.......8192........................
↓　　　　　　　　　　　　　　　　　　　　　　　* 　　　　　　　　　
増　　　　　　　　　　　　　　　　　　　　　　* 　　　　　　　　　　
加　　　　　　　　　　正常領域　　　　　　　* 　　　　　　　　　　　
　　　　　　　　　　　　　　　　　　　　　* 　　　　　　　　　　　　
　　27931 　　　　　　　　　　　　　　　* 　　　　　　　　　　　　　
　　　　　　　　　　　　　　　　　　　* 　　　　異常領域　　　　　　
　　　　　　　　　　　　　　　　　　* 　　　　　　　　　　　　　　　
　　　　　　　　　　　　　　　　　* 　　　　　　　　　　　　　　　　
　　　　　　　　　　　　　　　　* 　　　　　　　　　　　　　　　　　
　　29404 　　***************** 　　　　　　　　　　　　　　　　　　
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　


−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−


なるほど、そういうことですか。
ただし、これは、うちの環境での結果。
すなわち、WinXPのcommand.com、Vz1.60製品版の.comと.def、EM246 XM0での結果です。
この環境が変われば、変曲点は変わることでしょう。

この結果から推測できること。
Blが増加することにより、先に開いていたファイルの、正常挿入可能なファイルサイズ
は減少することがわかりました。これはおそらく、Blが増えることで、Blの後ろにある
何かのバッファが圧迫されるとか境界を越えることで、ブロック挿入時の1バイトずれが
発生するのではないか、と思われます。
私にはバッファの並び順はわかりませんが、何がどう並んでいるかがわかれば、追跡
するべき項目は絞られるような気がしてます。確か、めざら資源のどこかのページに
バッファの配置順があったような気もしますので、探してみたいと思います。
 

　う、美しい。感動的だ。

　どこかにたどり着けることを、心よりお祈り申し上げております。

　ラインバッファの後ろに何があるか？　これは分かりそうな気がする。気がするだけ
かもしれないけど。テキストバッファのようにＥＭＳに行ったりはしないような、気が、
す、る、、、。ＸＭＳにも行かない気がする。
　気にしておきます。少ししたら調べてみようとしてみたいと思います。
　もちろん、今までの２０年以上のＶｚ人生で、調べたりしたことは一度もないのですが。

　憂鬱な木曜日でした。
　でも、秋だ！　コオロギが鳴いている。

Cseg map : 2022/09/23_00:57:22

    0 1 2 3 4 5 6 7 8 9 A B C D E F 
0   SSSSSSSSSSSSSSSFFFFFFFFFFFFFiiii    S システム領域
1   iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii    F ファンクションキー表示文字列
2   iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii    i 内部マクロバッファ
3   iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii    o 外部マクロバッファ
4   iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii    A エイリアス文字列
5   iiiiiiiiiiiiiiiiiiiooooooooooooo    s 文字列バッファ
6   oooooooooooooooooooooooooooooooo    p 作業ファイル名ポインタ
7   oooooooooooooooooooooooooooooooo    U カットバッファ
8   oooooooooooooooooooooooooooooooo    d 表示文字列展開バッファ
9   oooAAsssssssssssssssssssssssssss    F ファイラーワーク構造体
A   ppppppppppppppppppUUUUUUUUUUdddd    O オプション初期化時参照表
B   ddFFFOOOOOOOOOOOOOOOOOOOOOOOOOOO    T テキストワーク
C   OOOOOOOOOOOOOOOTTTTTTTTTTTTTTTTT    & &z用テキストワーク
D   TTTTTTTTTT&&LLLLLLLLLLLLLLLLLLLL    L ラインバッファ（wm+228）
E   LLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLL    - 緩衝領域以降
F   LLLLLLLLLLLL--------------------
    0 1 2 3 4 5 6 7 8 9 A B C D E F 

[ESC]@
wm+228: -10814 54722 D5C2h

>vmap
1728 <--    2  212016  vz 1.60t -z                00 1B 21 29 3F

1728:D5C2

　これより下をdumpしてみたら、何か分かるのでしょうか？　分からないの
でしょうか？

　「緩衝領域以降」って何でしょう？

--- vzibmj.map ---
 0000:D329       csrchr
 0000:D32C       disptext
 0000:D652       dosheight
 0000:D726       getdosloc
-------------------
　これはどの版だか分からないけど、vzibmj.comをアセンブルしたときの
map ファイル。

　これで少し、、、とか思ったけど、com ファイルなのに、segmentをごにゃ
ごにゃしている（たぶんassemblerとかdosとかを騙してる）Ｖｚとしては、
これじゃ、どうにもなりませんか。

　うん、dump。しても分からないのだろうなぁ。

めざらさーん！

　す、す、す、素晴らしい！　そういえば、ありましたね、この労作。有用に使えた
ことはないのですが。

>wm+228	ラインバッファ（実質的先頭はwm+230）
　ここだけ、とりあえず、引っかかっていました。230!

　さて、それでは、僕も、独自にこいつを検証してみたいと思います。
　csegmap.defというか、その結果がうまく読めないから。
　時間、かかりまーす。
　しかたがない。やる。
　さっきやりはじめたら、vtdos、落ちてくれるし。30分の努力がパー。泣けました。
　でも、やる。
　これのためにアセンブラの勉強をしとるんじゃい。

　で、呼称ですが、高橋さんがスタックセグメントって呼んでたんでしょうか？
　何て呼びばいいのか分からないのですが、スタックって、後ろから入れるもの、
というか、プッシュ・ポップな構造ですよね。で、なんでそう呼ばれるの？　
とは思いました。

　完全なにわか知識ですが、ある種のアセンブラ（ＤＯＳプログラミング）の
入門書では、.comファイルではなく.exeファイルをつくります。たぶんこっちの
ほうが「普通」だからでしょう。セグメントが別々なわけです。
　code, data, stack, extraの４つ。で、「push, popはするものだし、別の
プログラムが使うこともあるから、とにかくstackには必要と思われる３倍くらい
のデータ領域を設定しておきなさい」とか書かれています。
　スタックは、もちろん、「First in, Last out」なもの。某書では、５０枚の皿を
縦に積み重ねる、レストランのスプリング付きワゴン（棚＝スタック）で説明して
いました。「最初に入れたものが取り出せるのは最後な構造」と。（注）

　そうそう。
　スタックバッファ。あるいは「マクロ用配列・スタック領域」、この単語が昨晩
でてきませんでした。テキストスタックじゃないからね。
　テキストスタックは、僕には魔界。それこそ、異セグですよね。

--------------------------------------------------
@BU @Bu @bu @ubufsz @pc..121 
メモリ／バッファサイズ
　Bu pc..121 マクロ用配列・スタック領域
  のサイズ
　  (64)[byte]  <64〜>  ubufsz
　  pu, スタックで両側から使用する
　  256 程度にはしておきたい
　    <---- Bu ---->
　   ｜ このサイズ ｜  pu..0 などで上から使用
　   pu→        ←sp  プッシュ・ポップで下から使用
--------------------------------------------------

　で、僕にとっての最大の謎は、たしかにコピーなんでしょうが
（0690　　ここまでセグメントvzのコピー）、
そんなことをして、どうＤＯＳとうまくやれるのか、ということ。vz.COMです。
　常駐すると、いろんなことを自分でやらなければならないけれど（ＤＯＳに任せられない、
ＤＯＳが許してくれない）、かなり勝手が（自由が）できるものらしいのですが。

　Ezは分かりませんが、1.01からＶｚは常駐してました！　（ジャンプしすぎかもしれ
ませんが）そして、蛇足というか釈迦説でしょうが、Vz 1.6は、ほんとすごいみたい。
c.mosさん、その後はいい加減だったかもしれないけど（燃え尽きた）、本気で徹底的に
勝負してたんですよ。see 黒本、p.12-13.
　きっとどうしても頭にうかぶWindowsの影と戦いながら。

（注）では、.comファイルで、以下のようなお決まりのやり方をしたら、push/popしたとき
に使われるはずのスタックセグメント的なものはどう自動で作られるのか？　assembler の 
"warning: no stack segment" の意味は分かったけど、ぜったい.comファイルの中にスタック
セグメント的領域はあるはずだと思うんですよねぇ？？？

CODE	SEGMENT
	ASSUME	DS:CODE,CS:CODE,SS:CODE

　そして、many vz....asms の、assume ds:nothing の謎。いつか解けるのだろうか？

　まったく無根拠な想像です。

　code seg (vz seg)　　　　copy →　　code seg (vz seg) + data seg 
　dos的にcode segment してる 　|　　　　　　　　(pq..112/mh;マクロバッファ先頭以降)
　のはこっち。　　　　　　　 　|　　　vz内部（本体）で管理されてるのがこっち。
　　　　　　　　　　　　　 　　|
　こちらをc.mosさんは　　　　　|　　　こちらをc.mosさんは
　「コードセグメント」　　　 　|　　　「データセグメント」
  と呼び　　　　　　　　　　 　|　　　と呼んだ。

  これで、これら「セグメント」の分離が行われ、Vz 1.6で、マクロバッファが大きくなれた。
  前提は、コピーされる部分は本物より小さく、それは（きっと）マクロにとって必要な部分
であるということ。

　妄想です。しかし、やがて誤りだったと気づくことになっても、仮説は思い浮かんでしまう
ものなのです。それのない真空状態には耐えられない、もの、らしい、です。


-----
Ygrep "tmpbuf4" c:\vzsrc\cmos
c:\vzsrc\cmos\main.asm      438:GDATA tmpbuf4,	dw,	TMPSZ

Ygrep "tmpbuf3" c:\vzsrc\cmos
c:\vzsrc\cmos\filer.asm      106:	extrn	tmpbuf3		:word
c:\vzsrc\cmos\filer.asm     2909:	mov	dx,tmpbuf3

Ygrep "tmpbuf2" c:\vzsrc\cmos
c:\vzsrc\cmos\alias.asm       39:	extrn	tmpbuf2		:word	
c:\vzsrc\cmos\alias.asm      491:	mov	di,tmpbuf2

Ygrep "tmpbuf" c:\vzsrc\cmos
c:\vzsrc\cmos\alias.asm       38:	extrn	tmpbuf		:word	
c:\vzsrc\cmos\alias.asm      434:	mov	di,tmpbuf
-----

　おお、ほんとうに、tmpbuf4は定義だけされていて、使われていない。
　ありがとうございます！

　ふと思ったのは（超妄想です）、最後のあき、スタックとして使われているのかも。
「スタックセグメント」が正しいのかもしれないですね。

だから？

　だから？　と言われるかもしれないし、思われることでしょう。
　僕自身も、だから、何かわかったの？　と自分自身に問いたい。

（１）
Ygrep -w -j "ss" c:\vzsrc\157cmos	; -word -ignore case
c:\vzsrc\157cmos\core.asm      129:blod5:	mov	[bp].lbseg,ss		; ##1.5

（２）
Ygrep "lbseg" c:\vzsrc\cmos
c:\vzsrc\cmos\core.asm      129:blod5:	mov	[bp].lbseg,ss		; ##1.5
c:\vzsrc\cmos\vz.inc      846:lbseg		dw	?		; line buffer seg

　ソースをガシガシ読んでいたS.Kinさんが間違えるはずないよな、と思ったのです。
　で、Vz 1.57のソースを「スタックセグメント」（ss, セグメント・レジスタ変数＠CPU レベル）
で、グレップしたのが（１）。
　そう、スタッグセグメントが使われている。（注）

　（２）Vz 1.6ではどうなった？　lbsegはそのまま？　そのままです。そして、やはり「ss」
が使われている。スタックセグメント！

　このソースレベルのセグメント管理については、いぜん、１ミリの進歩もなく、まったく分からない。
『MASM 擬似命令ハンドブック』（ナツメ）で、segment ends, group などみても、よく分かんない、です。

　はっきりしたのは、【あれ】を「スタックセグメント」と呼ぶのは、ほぼ正しいらしい、ということ。
視点によりけり、視座によりけり、ではありますが。
　で、その後、思い出したのは、たしか高橋さんは、あれを"dseg.map"と呼んでたなぁ、ということ。

　あと、にわか勉強によれば、code seg, data seg, extra seg はいくつあってもいい。リンカーにちゃんと
仕事をしてもらえれば。ただし、stack segmentは、必ず１つでなくちゃいけないし、そこに領域は
確保されなくちゃいけない、ということ。.exeモデルの話。cpuレベルで、push/popで使われるので。
（Ｖｚマクロで、ps[, とやったら例の場所＝マクロ・スタック／スタック・バッファにデータが保存
されるように）。でも、明示的でなくとも、.comでも、同じことになっていないわけないだろうと想像
しています。４つのセグ全部で64KB以内でなくてはならない、というのが、comモデルの制限。

　（妄想：しかし、ラインバッファをスタックセグメントにとったからといって、別にFirst in, Last out
な形で扱わなくちゃいけないのかなぁ？　そうなんだろう、みたいな気がするんだけど、、、。
　しかし、ラインバッファがいちおう１つのセグメントをなすように設計されているとしても、ラインバッファ
って、１行だよねぇ、、、。）
　


（注）僕は、.comにしろ、.exeにしろ、４つのセグメント及びセグメント変数がどう使われるのか
ほぼ分かっていません。ＤＯＳレベル。そのうち分かる、、、と、いいな。


　はい、誰にもどんな反応のしようもない、空想と妄想の世界でした。
　もちろん、上の話が、Vz macroからアクセスできる、kz, dz, vz (code_seg)とは違うレベルの
話だという認識はあります。


追記：しつこくて、ぐちゃぐちゃで、申し訳ありません。

C:\>Ygrep "lbseg" c:\vzsrc\cmos
c:\vzsrc\cmos\core.asm      129:blod5:	mov	[bp].lbseg,ss		; ##1.5
c:\vzsrc\cmos\core.asm      240:	mov	[bp].lbseg,ax
c:\vzsrc\cmos\core.asm      652:	mov	ds,[bp].lbseg
c:\vzsrc\cmos\core.asm      701:	mov	ds,[bp].lbseg
c:\vzsrc\cmos\core.asm      823:	mov	ds,[bp].lbseg
c:\vzsrc\cmos\core.asm      858:	movseg	ds,[bp].lbseg
c:\vzsrc\cmos\core.asm     1174:	movseg	ds,[bp].lbseg
c:\vzsrc\cmos\gets.asm      177:	mov	[bp].lbseg,ss
c:\vzsrc\cmos\ledit.asm      103:	mov	ds,[bp].lbseg
c:\vzsrc\cmos\ledit.asm      320:	mov	ds,[bp].lbseg
c:\vzsrc\cmos\macro.asm     2124:	mov	ds,[bp].lbseg
c:\vzsrc\cmos\main.asm     1834:	mov	[bp].lbseg,ax
c:\vzsrc\cmos\memo.asm     1137:	add	[bp].lbseg,ax
c:\vzsrc\cmos\string.asm     1045:	mov	ds,[bp].lbseg
c:\vzsrc\cmos\string.asm     1106:		mov	ds,[bp].lbseg
c:\vzsrc\cmos\view.asm     1135:	movseg	ds,[bp].lbseg
c:\vzsrc\cmos\vz.inc      846:lbseg		dw	?		; line buffer seg

　これが全部です。Vz 1.6に出てくる「lbseg」。
　最初のころ（夏前ぐらい？）、僕が久しぶりに顔を出したとき、konnoさんの「お誘い」（！）で
覗いたのが、core.asm。「Ｖｚのコアって何？」と開けてみた。Ｖｚのコアとは、ラインエディット
のことでした。だから、そこで、名前の由来どおり、ｓｓ値がlbsegに入れられるのは、まあ、なんとなく
筋がとおってそう。でも、そのあと、だいたい、「ds」の中です。

　僕の妄想的仮説は、やはりVz seg copy＋マクロアクセス可能データの、めざらさんが「スタッグ
セグメント・マップ」と呼んでるところこそが、Vz 1.6で分離された「データセグメント」だ
ということ。当たり前みたいだ。でも、dseg.mapでした。「スタ・セグ・マップ」が間違っていると
言いたいわけじゃないですよ。謂れと根拠がちゃんとあったのですから。

　「３章で解説した  COM モデルのプログラムでは特にスタック領域について注意
をはらいませんでした。これは COM モデルのプログラムでは、MS-DOS が自動的に
スタック領域を割り当ててくれるからです」
　『はじめて読むＭＡＳＭ』　p.130。

　（章タイトルは、「スタックセグメントの定義」ですから、「スタック領域」
の「領域」に深い意味はありません。スタックセグメントのことです。上の続きが、
「しかし EXE モデルでは、、、」となるわけです）

　SS (Stack Segment Register) って、なんかあまり見ません。 Ｖｚで 
assume ss: code とかもしてません。すると、逆にいけないのかも。
　ほんとに、何も定義しなくても、mov [bp].lbseg, ss なんてしていいみたいです。

　スタックセグメントは、とにかくある、自動的に存在する、セグメント・レジスタに
ついても自動設定ということですね。蛇足ですが、mov ds,cs はダメです。このために
movseg マクロが、std.inc で定義されているはずです。

-------------------------
【変数定義の一部】 in VZ.INC
bbtm		dw	?		; screen bottom ptr (in buffer)
lbseg		dw	?		; line buffer seg
inbuf		db	?		;
　※たんなる２バイトの変数です。以下の連中と扱いがぜんぜん違う、と思う。


【comモデルだから、けっきょくcode segmentの一部になるのだけど、内輪での分類として
　以下のように（擬似）「セグメント」は定義される】in VZ.INC

cgroup	group	_work,_data,_base,_code,_exec,_hard,_init,_tail

wseg	macro
_work	segment
	endm

endws	macro
_work	ends
	endm

etc, etc, etc ....
-------------------------

　結局のところ、 ＣＰＵがそうみなし、そう操作する COM におけるスタッグ
セグメント（完全ＤＯＳ管理）を、Ｖｚはいいように使っているだけだろう、
というのが、僕の結論的想像でした。

　ただ、「自動」ったって、サイズという大きな問題があるでしょう、とも思う。
　決まってるんでしょうね。今のところ、このサイズを知らせてくれる情報は見
つからないのですが。かなーりたったころ（３年後）、ああ、あのサイズって
そう決まってたんですか、とかなるのかしらん。
　c.mosさんは、もちろん、これを知っている。

　ほんと、いいように、Ｖｚはスタッグセグメントを一時的「作業領域」として
使っているように見えました。

　というわけで、つまらないことにこだわって申し訳ないのですが、S.Kin さん
の一行にもかかわらず、あのマップを「スタックセグメント・マップ」と
いうのは、あまり正確ではないのかもしれません。
　「データセグメント・マップ」で、c.mos さんも高橋さんも文句はないと思います。
　すると、csegmap.defも、dsegmap.defのほうがいいのかもしれません。

　僕には、konnoさんのご希望には添えないようでした。
　手元の、大昔に宮田さんがご恵贈くださったマニュアルは、「Version1.5」と
表紙にあり、今回入手した版は、以下です。

==============================================================================
	ＶZ Editor Version 1.56  Copyright (C) 1989 by c.mos
			ＲＥＡＤＭＥ．ＤＯＣ
==============================================================================

readme.doc  59,344  1990-12-07  01:56
vz.com      46,580  1990-12-07  01:56 (NEC 98)

　マニュアル（水色本）は明らかに市販品、たぶん、上のファイルも市販品なのだと思う
（こまごまオンラインで ver up があったんでしょうね）。
　整合したのだろうと思っています。（\usはなし、ただし\ibmはあり）

　僕は、個人的には、vz.asms (総称)とか vz.com に関してすごいコレクターになりたい
という希望は持っていません。今回は、ああ、そう展開したんだ、という偶然です。
NEC98機は手放したし、98エミュレータを動かす予定もないので。

　c.mos版、高橋版、konno版のソースで、勝負する、という所存。
　May the source be with you!

　ただ、BasicとかPascalとかCとか?ASMとかを（abandonwares）、このところコレクション
しているので（古書やもぐらソースを含め）、ヴィンテージとかついてやたら高くなければ、
必要なものが必要な人のところに届くという超法規的な姿勢もいいんじゃないかな、と思って
います。
　もうこれらに市場価値はないので、そんなバカみたいに法律（著作権）に縛られなくても、
いいんじゃないか、という感じでいます。
　僕らは趣味でやってるだけなのです。誰の商売の邪魔をするつもりはありません、とか。

　文学屋なので、作家はくえれば、作品の市場価値とか関係ないし、という世界に生きている人
なのです。
　「なぜか金が少し余っている。そうか、お前はお金が足りないのか。なのに、こんなにすげえ
文章で俺を感動させてくれたわけか。じゃ、お金でいいなら、持っていってくれよ」みたいな感覚
で生きています。

　FlaboとかFdeviceとかFgalel(?)とか、ねこさんが活躍していた（S.Kinさんがねこさんのお世話
になった？）アセンブラ系のniftyログとかライブラリ資産とかは、欲しいなぁ、と思っています。
とりわけ正規表現系のアセンブラないしＣのソース。
　高度なアセンブラ本には、ちゃんと「マッチング」という章があったりするのですが。
　nifty終末期に、もっと積極的にコレクションしておくべきだったなぁ、とは思ってます。

　もう日本語はどうでもいいや、という姿勢（konnoさんの若かりし頃の姿勢？）になってますので、
英語文献だけでいいや、と思っているのです。
　日本語化は、そのあと、自分でやる！　ウソです。
　面倒くせえ、２バイト文字。SJIS。

　１０年ぶりにDOS/V系の欲しかったものが、手に入りました。あとはハードの問題だけ（決定的
に重い）。鯖さんあたりの話です。

> 先に開いていた　 Blの値
> ファイルサイズ　 6717  6718  6719  6720  6721  6722
> 29401バイト　　　　　　　　　　　　　　　　　　正常
> 29402バイト　　　　　　正常　　　　　　　正常　異常
> 29403バイト　　　　　　正常　正常　正常　異常　　　
> 29404バイト　　　正常　正常　正常　異常　　　　　　
> 29405バイト　　　異常　異常　異常　　　　　　　　　
> 29406バイト　　　　　　異常　　　　　　　　　　異常

これは素晴らしい！　見事です。

ファイルサイズ 29404 は EMS 2ページ分ですね。
16k=32768
でもこのサイズではテンポラリは作られるのかな？
32768 は、$8000 正負の反転のバグがありそうですね。

> ただし、これは、うちの環境での結果。
> すなわち、WinXPのcommand.com、Vz1.60製品版の.comと.def、EM246 XM0での結果です。
> この環境が変われば、変曲点は変わることでしょう。

とりあえず、簡単にできるところということで、EM0だけ変えてみた結果。

先に開いていた　 Blの値
ファイルサイズ　 6717  6718  6719  6720  6721  6722
29401バイト　　　　　　　　　　　　　　　　　　正常
29402バイト　　　　　　　　　　　　　　　正常　異常
29403バイト　　　　　　　　　　　　正常　異常　　　
29404バイト　　　正常　正常　正常　異常　　　　　　
29405バイト　　　異常　異常　異常　　　　　　　　　
29406バイト　　　　　　　　　　　　　　　　　　　　

少なくともうちの環境においては、EMSの値には影響されない模様。


> 私にはバッファの並び順はわかりませんが、何がどう並んでいるかがわかれば、追跡
> するべき項目は絞られるような気がしてます。確か、めざら資源のどこかのページに
> バッファの配置順があったような気もしますので、探してみたいと思います。

文太さんにご教示いただいた、緩衝領域。
なんだろう、これ。どういうことなのか。
異セグというか、後ろのほうから前のほうに攻めてくる何かがあるのでしょうか。
いや、だって、緩衝という言葉からイメージするのは、車のエアバッグとか、梱包用の
プチプチとか。
 

ここにつけます。

> 先に開いていた　Blの値　　　　　　　　　｜→　ここから先は未定義領域
> ファイルサイズ　.............6720.......8192........................
> ↓　　　　　　　　　　　　　　　　　　　　　　　* 　　　　　　　　　
> 増　　　　　　　　　　　　　　　　　　　　　　* 　　　　　　　　　　
> 加　　　　　　　　　　正常領域　　　　　　　* 　　　　　　　　　　　
> 　　　　　　　　　　　　　　　　　　　　　* 　　　　　　　　　　　　
> 　　27931 　　　　　　　　　　　　　　　* 　　　　　　　　　　　　　
> 　　　　　　　　　　　　　　　　　　　* 　　　　異常領域　　　　　　
> 　　　　　　　　　　　　　　　　　　* 　　　　　　　　　　　　　　　
> 　　　　　　　　　　　　　　　　　* 　　　　　　　　　　　　　　　　
> 　　　　　　　　　　　　　　　　* 　　　　　　　　　　　　　　　　　
> 　　29404 　　***************** 　　　　　　　　　　　　　　　　　　
> 　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　
> 　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　
> 
> 
> −−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−


Blの大きいほう、未定義なんだから何が起こってもおかしくない、というのは頭では
分かっています。とはいえ、好奇心には勝てず。ついつい、追及してしまいました。
結果。

先に開いていた　 Blの値
ファイルサイズ　 9985  9986  9987  9988  9989
26134バイト　　　正常　　　　　　　　　　正常
26135バイト　　　　　　　　　　　　　　　　　
26136バイト　　　　　　　　　正常　正常　正常
26137バイト　　　　　　正常　異常　異常　異常　　
26138バイト　　　正常　異常　　　　　　　　　
26139バイト　　　異常　　　　　　　　　　異常

ほほう。
つまり、上記の図に加筆すると、以下のようになります。


先に開いていた　Blの値　　　　　　　　　｜→　ここから先は未定義領域
ファイルサイズ　.............6720.......8192......9987...............


　　26136 　　　　　　　　　　　　　　　　　　　　　************** 　　　　　　　　　　　　
　　　　　　　　　　　　　　　　　　　　　　　　　* 　　　　　　　　　　　　
↓　　　　　　　　　　　　　　　　　　　　　　　* 　　　　　　　　　
増　　　　　　　　　　　　　　　　　　　　　　* 　　　　　　　　　　
加　　　　　　　　　　正常領域　　　　　　　* 　　　　　　　　　　　
　　27931 　　　　　　　　　　　　　　　　* 　　　　　　　　　　　　
　　　　　　　　　　　　　　　　　　　　* 　　　　　　　　　　　　　
　　　　　　　　　　　　　　　　　　　* 　　　　異常領域　　　　　　
　　　　　　　　　　　　　　　　　　* 　　　　　　　　　　　　　　　
　　　　　　　　　　　　　　　　　* 　　　　　　　　　　　　　　　　
　　　　　　　　　　　　　　　　* 　　　　　　　　　　　　　　　　　
　　29404 　　***************** 　　　　　　　　　　　　　　　　　　
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　
−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−

こんな感じですね。
うぅん、斜めの部分は約3200バイト。
これは一体何を表しているのか。
また、#4840あたりで「異常挿入を起こす最小のファイルサイズ」などというものに
言及していますが、これがまさに、Blと異常挿入を起こすファイルサイズの相関関係
を表しているものだといえると思います。
あとは、Btを変えるとこのグラフがどう変わるかというのも興味がありますが、
さすがにそれを試す元気はない。

う〜ん、他に何か面白い実験はあるかなぁ。
 

としきさん、またまた興味深い実験を。(^^;

> 先に開いていた　 Blの値
> ファイルサイズ　 9985  9986  9987  9988  9989
> 26134バイト　　　正常　　　　　　　　　　正常
> 26135バイト　　　　　　　　　　　　　　　　　
> 26136バイト　　　　　　　　　正常　正常　正常
> 26137バイト　　　　　　正常　異常　異常　異常　　

これに触発されて、Bl8192 の時の境界を探してみました。

27931バイト　正常
27932バイト　異常

この値も環境によって変わらないような気がします。
バグ修正のヒントになりそうですが、さっぱりわからない。(>_<)


余談ですが、境界が交わる点を探すのは大変ですね。
昔二つの交点を探すのに方程式がわからなくて二分法のプログラムを
ポケコンに入れて探したのを思い出しました。(^^;

> う〜ん、他に何か面白い実験はあるかなぁ。

さして面白くもありませんが。
確認しておきたいことを見つけてしまいました。

> 先に開いていた　Blの値　　　　　　　　　｜→　ここから先は未定義領域
> ファイルサイズ　.............6720.......8192......9987...............
> 
> 
> 　　26136 　　　　　　　　　　　　　　　　　　　　　************** 　　　　　　　　　　　　
> 　　　　　　　　　　　　　　　　　　　　　　　　　* 　　　　　　　　　　　　
> ↓　　　　　　　　　　　　　　　　　　　　　　　* 　　　　　　　　　
> 増　　　　　　　　　　　　　　　　　　　　　　* 　　　　　　　　　　
> 加　　　　　　　　　　正常領域　　　　　　　* 　　　　　　　　　　　
> 　　27931 　　　　　　　　　　　　　　　　* 　　　　　　　　　　　　
> 　　　　　　　　　　　　　　　　　　　　* 　　　　　　　　　　　　　
> 　　　　　　　　　　　　　　　　　　　* 　　　　異常領域　　　　　　
> 　　　　　　　　　　　　　　　　　　* 　　　　　　　　　　　　　　　
> 　　　　　　　　　　　　　　　　　* 　　　　　　　　　　　　　　　　
> 　　　　　　　　　　　　　　　　* 　　　　　　　　　　　　　　　　　
> 　　29404 　　***************** 　　　　　　　　　　　　　　　　　　
> 　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　
> 　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　
> 　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　
> 　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　
> −−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
> 
> こんな感じですね。
> うぅん、斜めの部分は約3200バイト。

先に開いているファイルのサイズ調整は、ファイルを後ろから削って行っています。
ところが、このときの最終行、思いっきり長い論理行なんですね。
なにせこの行、4000バイト以上ある。
つまり、この斜めの部分というのは、一番上も下も同じ論理行の中で、前のほうか
後ろのほうか、ということになっているわけです。
そのため、もしやこの論理行が妖しいのでは、と考えました。
この可能性を確かめるため、この行頭が2632から始まる行、大体16行目くらいにある
わけなのですが、こいつを２行目に挿入してみました。もし本当にこの行が問題で
あるのなら、たった２行のファイルでも異常挿入が発生するはず。
結果。
やっぱりBl8192のときは27931バイトのところに境界がある。
また、Bl9987バイトあたりから横一線になりそう。
具体的な結果は以下のとおり。

先に開いていた　 Blの値
ファイルサイズ　 8190  8191  8192  8193  8194
27930バイト　　　　　　　　　　　　　　　　　
27931バイト　　　　　　　　　正常　　　　　　
27932バイト　　　　　　　　　異常　　　　　　
27933バイト　　　　　　　　　異常　　　　　　
27934バイト　　　　　　　　　　　　　　　　　

先に開いていた　 Blの値
ファイルサイズ　 9985  9986  9987  9988  9989
26134バイト　　　　　　　　　　　　　　　　　
26135バイト　　　　　　　　　　　　　　　　　
26136バイト　　　　　　正常　正常　正常　　　
26137バイト　　　　　　正常　異常　異常　　　
26138バイト　　　　　　異常　　　　　　　　　
26139バイト　　　　　　　　　　　　　　　　　


読みが外れたか。
ただ、この実験では、行数も異なったファイルにもかかわらず同じ結果になっている。
これもまた興味深い。
さらに、行の入れ替えを行う前の元のファイルでは、最終行の4000バイトあまりの行を
削っていっている一方で、行入れ替えを行ったファイルでは、その行がそのまま丸ごと
全く削られずに含まれているにもかかわらず、境界の値に変化はない模様。面白い。
一体、何のルーチンが計数ミスを行っているんだろう。