調べていたらMCBの未チェックが原因だったようです。
#4999 で10＃さんが当時の不具合の原因を特定してくれていました。
DOS.ASM の後ろの方
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
cmp byte ptr cs:os_win,5 ; ★NTなら必ずMCBチェック
je winnt5 ;
tstw es:[mcb_psp] ; ## この２行が 2010-2-10
jz chkmcb9 ; ## 不要と思われる by 10#
winnt5: cmp es:[mcb_psp],ax ; MCB チェック
chkmcb9:pop es
ret
checkmcb endp
## が10＃さんのパッチでコメントになっています。
★ が私の入れたルーチンで、NT系DOS窓なら ## の2行を飛ばすようにしました。
今回は ★印部分を、OZ32 のオプションに変更してみました。
mov ax,cs
test byte ptr cs:opt_zpc,32 ; ##k 240917 Oz32なら MCB chek
jnz winnt5 ;
; cmp byte ptr cs:os_win,5 ; NT
; je winnt5 ;
tstw es:[mcb_psp] ; ## この２行が 2010-2-10
jz chkmcb9 ; ## 不要と思われる by 10#
試してみると、この ## の2行を飛ばすようにすると swapパッチと同じく正常になりました。
おそらくNT系のcommand.com がメモリを使っても VZは検知できないということだと思います。
だから必ずMCBチェックをするか 必ず swapすることで正常になるのだと思います。
当時の流れを見ると
2010/01/22 23:15 216,608 VTDOS.EXE VTDOS121 NG
2010-2-10 VZの問題原因究明
2010/02/21 02:29 212,512 VTDOS.EXE VTDOS122 NG
2010/03/02 19:26 244,768 VTDOS.EXE VTDOS123 OK
2010-2-10 に VZの問題原因究明出来てもすぐには解決できませんでした。
0＃さんでも問題解決にそうとう時間が掛かったのだと想像します。
この当時は私はこの話を全然理解できていなかったですね。(^^;