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

#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

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

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

これには参りました。(>_<)
最初は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 （クラスタ）。こんなにあるとは・・・・


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

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
が出来ます。

ご苦労様です。

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!	;これも本当は少し気になるのだけど。

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

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

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

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

　別にとりわけ意図も希望もなく、説明を分かりやすく書き直しておきます。
　１ＭＢのファイルがある。１０００本のページフッタが中に入っている。
「ページ番号つき」フッタには、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は蟲探しの良い教材になりそうですね。(ﾟ゜)☆＼(--#)ﾊﾞｷｯ