VTDOS|C:\VT>ver			;落ちないようです。
Microsoft Windows XP [Version 5.1.2600]

VTDOS|C:\VT>zcpy32		;やっぱ持ってなかったか
Bad command or file name

> VTDOS|C:\VT>ver			;落ちないようです。
> Microsoft Windows XP [Version 5.1.2600]

うちも、1.21ではそういう表示になるんですけどねぇ。(++;

> VTDOS|C:\VT>zcpy32		;やっぱ持ってなかったか
> Bad command or file name

あのう、RCP32 は問題ないですか。VTD_NRDR.CFG とか、VTD_CMD.CFGに登録する
必要があるのかどうか、このへんがよくわからないもので。

　子プロセス全般という感触ではないような…。

k07t メモリに常駐しました.（-zで解放）
VTDOS|C:\VT>rcp32 c:\aaa.txt c:\tmp
Reading dir(s) .....
C:\ --> C:\TMP
  AAA.txt
       1 File(s) found
       1 File(s) copied


　以下は行けるときもあるのです。

VTDOS|C:\VT>C:\DEF\CLPPST.EXE /R C:\DEF\CLPPST.TMP


　こちらはデフォルトのままで、とりわけ触ってないようです。

VTDOS|C:\VT>type vtd_nrdr.cfg
cmd.exe
cat.exe
vtdos.exe
telnet.exe
ci.exe
co.exe

VTDOS|C:\VT>type vtd_cmd.cfg

telnet.exe

* msdos.exe

mg.exe
p2enc.exe
lcc.exe


　うーん、konnoさんのレポートをみてると、どこに原因があるのかぜんぜん
分からない感じですねぇ…。マシンやdef環境とかではないのじゃないかなぁ、
とあてずっぽですが。

konnoさんの報告を元に僕の方で再現手順を絞り込みました。
(画面分割はしていません)

1. 複数ファイルを開く(ファイル数6・総サイズ約8k)
2. [ESC]Eでコマンド
3. Ms (スワップ実行)
4. [ESC]でVZ
5. ms (非スワップ実行)
6. [ESC]でVZ

この手順でバッファクラッシュが再現しました。
これを、SW2/SW3/EM/EM0でそれぞれ追試しましたが、
どの設定でも再現しました。（おそらくEMMはシロ）

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

SWAP.ASMを漁っていると F_REALLOC が出てきたので、
DOSのメモリ管理コールをログに落として追試。
VZからのシェルエスケープ終了後のスワップイン処理時に
VZによる空きメモリーに対するF_REALLOCが検出されたので、
F_REALLOCでgrep。
該当ソースはDOS.ASM/MAIN.ASM/SWAP.ASM
F_REALLOCの呼び出し状況からDOS.ASMと推定。ソースレビュー。

該当箇所・DOS.ASM 1100付近
> expandfar proc
>         mov     ax,gtops
>         tst     ax
> _ifn z
>         push    es
>         call    checkmcb
>         mov     bx,-1
>   _if e
>         msdos   F_REALLOC
>         msdos   F_REALLOC
>   _else
>         msdos   F_MALLOC
>         msdos   F_MALLOC
>         mov     gtops,ax
>   _endif
>         add     ax,bx
>         mov     gends,ax
>         pop     es
> _endif
>         ret
> expandfar endp

gtopsのMCBを検査して割り当て済みならF_REALLOC、
未割り当てならF_MALLOCを呼び出して、
コンベンショナルメモリーを最大サイズ取得している模様。
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の時に画面分割を行っている場合は再現しましたが、
それ以外の場合は改善されている様子です。

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

他のDOS環境で正常に動作する理由は不明です。
空き領域へのF_REALLOCはF_MALLOC様に動作するのか？と思い、確認したのですが、
記述が見あたりませんでした。

>    This function is used to increase or decrease the size of a memory
>    block allocated by Function 48h. ES contains the segment address of
>    the block whose size will be changed. BX contains the new size of the
>    block, in paragraphs (16-bytes units).

> This call is used to change the size of an allocated block.
> On entry, es must contain the segment address of the allocated block
> returned by the memory  allocation  function.
> Bx must contain the new size of this block in paragraphs.
> While you can almost always reduce the size of a block,
> you cannot normally increase the size of a block if other blocks
> have been allocated after the block being modified.
> Keep this in mind when using this function.

未割り当て領域へのF_REALLOCはF_MALLOCと同じ動作をするという記述を
見つけられた方はVTDOSの仕様に反映させますのでお知らせ下さい。

また、もし可能であれば、パッチ済みのVZを他のDOS環境でテストして
いただけないでしょうか？
それで問題が出なければ、正規のパッチ(?)として採用されることをお勧めします。

10#さん

> >         tstw    es:[mcb_psp]	; ## この２行が
> >         jz      chkmcb9	; ## 不要と思われる

おお、やはりVZの問題だったのですか、ソースまで特定していただいて。m(__)m

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

おお、改善されましたか、さすがプロですね。鮮やかなお手並みに脱帽です。
私は所詮素人で、こういう解析は無理なので、とても助かりました。

> また、もし可能であれば、パッチ済みのVZを他のDOS環境でテストして
> いただけないでしょうか？
> それで問題が出なければ、正規のパッチ(?)として採用されることをお勧めします。

はい、追試してみます。問題なければ、新版としてアップさせていただきます。

　#05030 10# さん

関係がありそうな記述を見つけましたが、わしには詳細はわかりません (^^;

DR-DOS System and Programmers Guide （私訳）より抜粋
http://hp.vector.co.jp/authors/VA003720/lpproj/drdos/progdoc/sysprog/chap4j.htm
------------------------------------------------------------------------
●割当メモリサイズ変更 (4Ah)
Modify Allocated Memory Blocks 	
	
入力パラメータ 	
AH 	4Ah
BX 	パラグラフ数
ES 	メモリブロックのセグメント
戻り値 	
AX 	キャリーフラグがセットされている場合、エラーコード
BX 	使用可能なメモリブロックの最大サイズ（エラー時）

メモリブロック配置を、指定のサイズに変更します。 入力時、ES は割当済み
メモリブロックのセグメントアドレスを格納し、 BX は要求するメモリブロッ
クサイズをパラグラフ（16 バイト）単位で格納します。DR-DOS は BX の内容
にしたがい、割り当て済みメモリブロックのサイズを増加、もしくは減少させ
ます。

DR-DOS が割当済みブロックのサイズを大きくできない場合、 サイズ変更可能
な最大ブロックサイズを BX に返します。キャリーフラグがセットされている
場合、エラーコード 7, 8 もしくは 9 を AX に返します。 エラーコードの定
義については Chapter 5 を参照してください。

（訳注 : BX のパラグラフ数だけ増減するのではなく、 BX のパラグラフ数そ
のものに変更する、という点に注意してください。また、Ｃ言語ライブラリの
realloc などと異なり、メモリブロックの起点は移動されません。したがって、
たとえばサイズ変更するメモリブロックの直後のメモリがすでに割り当てられ
ている場合、他の位置に空きメモリがどれだけあってもサイズ増加は失敗しま
す。） 
------------------------------------------------------------------------

Freedos 開発者のMLから抜粋
http://www.mail-archive.com/freedos-devel@lists.sourceforge.net/msg04881.html

[Freedos-devel] Kernel incompatibility between FD and MS-DOS makes QB4 cry
Michael Devore
Thu, 17 Aug 2006 19:26:13 -0700
------------------------------------------------------------------------
While testing out a users bug report, I found a terribly obscure difference 
between the way MS-DOS kernel works and FreeDOS kernel works.

（中略）

Here's the situation, running under QB 4.0.  The code is found in 
BRUN40.EXE and duplicated in the application's executable files:

1. QuickBASIC (I assume) frees a block of memory via INT 21h function 49h 
that it previously allocated.  Success in FreeDOS and MS-DOS.

2. QuickBASIC resizes a second block of memory via function 4ah with value 
0FFFFh to determine all free memory available to the block.  The function 
fails, as designed, but returns the maximum possible block size.  Success 
in both.

3. QuickBASIC resizes the second block of memory via function 4ah with the 
amount returned in last 4ah call, as expected.  Success, again.

4. QuickBASIC tries to re-free the first block of memory via function 
49h.  Tsk, tsk.  Naughty, but not too naughty under normal 
conditions.  Here MS-DOS and FreeDOS differ: while both will allow 
re-freeing the same block without error under some circumstances (which I 
don't know what they are since I'm not a kernel guy), the intervening 
resizes of the second block apparently flush out FreeDOS's memory of the 
first block, so it returns an error code.  MS-DOS still remembers that the 
block was recently valid and does not return an error code on the second free.
------------------------------------------------------------------------