> ***** Memory Arena Trashed!
X8MAPでみるとEMSもVZで使ってるけどVMAPは表示なしですね。

> この時非常駐VZではプロンプトが表示されますが、常駐VZではプロンプトも表示されないのも関連があるかも。
私も報告してたのですが常駐画面の件は対応されてなかったので先ほど画像添付で再度確認依頼しました。正常、異常画像を比べてvmapの結果に気づいた次第です。

すみません、昨晩の更新で大ポカして、MCBのチェーンが壊れてました。
取り急ぎバイナリを更新しておきましたので、再ダウンロードをお願いいたします。

（今日はたまたま所要で定時で帰宅してました）

VZを非常駐の状態で[Esc]Eをすると、ちゃんと黄色いプロンプトが表示されると思います。
常駐モードのときだけ変な感じですね。
テキストVRAMのシャドウバッファに画面を書き戻した後、実画面に反映するサービスを
呼んでいないのかもしれません。後日確認してみます。

> X8MAPでみるとEMSもVZで使ってるけどVMAPは表示なしですね。

この X8MAP ってどこにあるのか検索しても出ませんでした。
仕方ないので VECTOR の一番人気のメモリマップを落としてみたら X8MAP でした。(^^;
これはいいですね、CPUの表示も出来て便利です。

VTDOS 		CPU   :  80286 
MS-DOS Player	CPU   :  [Neko Project]F:M:R=6:7:2   PenPro 以降 + 80x87
DOSVAXJ3	CPU   :  [GenuineIntel]F:M:R=4:0:2      468 以降 + 80x87

DOSVAXJ3 の 468 以降 は 486 でしょうかね。(^^;

> 私も報告してたのですが常駐画面の件は対応されてなかったので先ほど画像添付で再度確認依頼しました。正常、異常画像を比べてvmapの結果に気づいた次第です。

げげ、ダブってしまいましたね。(^^;　でもこれで対応してもらえたらありがたいです。

> すみません、昨晩の更新で大ポカして、MCBのチェーンが壊れてました。
> 取り急ぎバイナリを更新しておきましたので、再ダウンロードをお願いいたします。
> （今日はたまたま所要で定時で帰宅してました）

素早い対応ありがとうございます。いただきました。
問題無く動作しています。DOS6.2 でVZ常駐出来て嬉しいです。
本当にありがとうございました。

> テキストVRAMのシャドウバッファに画面を書き戻した後、実画面に反映するサービスを
> 呼んでいないのかもしれません。後日確認してみます。

その辺のことはわからないのでよろしくお願いいたします。

VZの問題なので、自分でもちょっと見てみました。

SCRNIBM.ASM  1367行目　DOS画面保存？　これを呼ぶ前にDOS画面クリアしているのか？
;--- Get dos/current screen ---
	public	getdosscrn
getdosscrn proc
	call	is_dossilent
	call	getgvseg
	mov	di,dosscrn
	clr	si
	call	getscrn
	ret
getdosscrn endp

SCRNIBM.ASM  1443行目　DOS画面描画？　ここか、この後でDOS画面クリアしているのか？
;--- Put dos/current screen ---
	public	putdosscrn
putdosscrn proc
	call	is_dossilent
	mov	msgon,0
	call	resetfp			; ##155.79
	mov	savef,FALSE
	call	setdosVM
	mov	si,dosscrn
	clr	di
	call	getgvseg
	call	putscrn
IFDEF DOSV
	call	vrefreshscrn		; DOSVでVRAM画面を表示させる？
ENDIF
IFNDEF J31
	call	resetpalette
ENDIF
clrfkey:
	mov	fkeymode,0
pdos9:	ret
putdosscrn endp


MAIN.ASM 1503:	call	getdosscrn
OPEN.ASM 267:	call	getdosscrn

DOS.ASM 267:	call	putdosscrn
MAIN.ASM 1564:	call	putdosscrn
OPEN.ASM 266:	call	putdosscrn


MAIN.ASM 1503:	call	getdosscrn
;--- Enter the editor ---
;<-- CY :out of memory
	public	enter_vz
enter_vz proc				; DOS画面で[Enter]押したときに呼ばれる？
	movseg	ds,ss
	movseg	es,ss
	call	check_vwx
	call	getdosscrn
	call	setdoswindow
	call	setint24
	call	getcurdir

OPEN.ASM 267:	call	getdosscrn
close1:					; 編集画面からコマンドラインに降りた時か？
	call	putdosscrn		; getdosscrn の前に呼んでいるのは何故？
	call	getdosscrn
	call	setcmdwindow
	call	setdoswindow


DOS.ASM 267:	call	putdosscrn
;--- Exec from editor ---
	public	se_command
se_command proc
	tstb	cs:cmdlinef
_ifn z
quit1:	jmp	quit_vz
_endif
	movseg	ds,ss
	call	putdosscrn
・・・・
	call	enter_vz		; この後でこれが呼ばれる？


MAIN.ASM 1564:	call	putdosscrn
;--- Quit editor ---
	public	quit_vz
quit_vz proc
	call	ld_wact
_if z
	call	clrstack		; ##100.09
	mov	gends,INVALID
	test	syssw,SW_INIOPT
  _ifn z
	call	load_iniopt
  _endif
_endif
	movseg	ds,ss
	call	write_logtbl
	call	putdosscrn		; 
	call	setfnckey
	tstb	tsrflag				; 常駐VZか？
	jmpln	z,quit_tsr
	call	setdoskey
	call	setdoscsr
	call	resetfp


こんなところでしょうか、コメントは想像で適当に付けたものです。
私にはこれ以上はわからないです。

> SCRNIBM.ASM  1367行目　DOS画面保存？　これを呼ぶ前にDOS画面クリアしているのか？

> SCRNIBM.ASM  1443行目　DOS画面描画？　ここか、この後でDOS画面クリアしているのか？

それこそ、デバッガでブレークポイントを設定してみるのが手っ取り早いかも。
ん〜、SYMDEB？
Vzマクロの&tよりも強力だと思う。使ったことないけど。

INT 10hでブレークして見てみましたが、DOS画面の復帰云々というよりも、
[ESC]Eで、黄色いプロンプトを通り過ぎて、直にCOMMAND.COMに行っている感じです。
その辺のモード遷移の問題のような気がします。

> それこそ、デバッガでブレークポイントを設定してみるのが手っ取り早いかも。
> ん〜、SYMDEB？
> Vzマクロの&tよりも強力だと思う。使ったことないけど。

私は DEBUG も SYMDEB も使いこなせないんですよ。(;_;)
かわりに putdosscrn や dispprmpt を別の場所で呼んでみたら少し発見がありました。
武田さんからレスがあったので、そちらに書いてみます。

> INT 10hでブレークして見てみましたが、DOS画面の復帰云々というよりも、
> [ESC]Eで、黄色いプロンプトを通り過ぎて、直にCOMMAND.COMに行っている感じです。
> その辺のモード遷移の問題のような気がします。

見ていただきありがとうございます。私も VZのソースを弄って VZの挙動を見てみました。
	call	dispprmpt
これをコメントにすると非常駐VZのプロンプトは出なくなりましたが常駐VZでは挙動が変わりませんでした。
どうやら常駐VZのプロンプトは command.com が出しているようです。
つまり常駐VZの場合、ここは通っていないのかも。
それでこんどは putdosscrn をあちこちに入れてみたけどどうも VRAMの内容をゲット出来てないような気がしてきました。
次はその辺を追っかけてみたいんですが、はたして出来るやら。

[ESC]Eの後、非常駐の場合はINT 21h, AH=19hや47hで現在のディレクトリを取得して、
プロンプトを表示する方向に進むのですが、
常駐したVZを呼び出した場合は、INT 21h,AH=50hで現在のプロセスIDを変更したりと、
如何にもVZを終わらせてコマンドプロンプトに戻ろうとしている感じです。

多分、以下のところでcs:cmdlinfの値によってquit_vzに飛んでるのかと。

;--- Exec from editor ---
	public	se_command
se_command proc
	tstb	cs:cmdlinef
_ifn z
quit1:	jmp	quit_vz
_endif

> 多分、以下のところでcs:cmdlinfの値によってquit_vzに飛んでるのかと。

私もそこまでは追っかけました。その先で
	call	putdosscrn
があるので、VRAMのDOS画面復帰してプロンプトも一緒に表示しているのだと思います。
ところが　MS-DOS Player ではそれが表示されないのです。
なので getdosscrn がちゃんとDOS画面を保存出来ているか、保存できてないなら何故なのかを知りたいのです。

INT 21hで表示された文字は、必ずしもVRAMに反映されていないので、
その辺が原因かもしれません。
何か対策を考えてみますが、今日からしばらく忙しくなりますので、
対応には時間がかかるかと思います。

> INT 21hで表示された文字は、必ずしもVRAMに反映されていないので、
> その辺が原因かもしれません。

なるほど、そういうこともありますか。

> 何か対策を考えてみますが、今日からしばらく忙しくなりますので、
> 対応には時間がかかるかと思います。

お忙しいところ対応していただいて申し訳ないです。
ありがとうございました。

DOS/Vなので、テキストはグラフィック画面に描画されていて、
VZのDOS画面の退避・復帰もグラフィックVRAMが対象になってるみたいですね。

MS-DOS Playerは、仮想テキストVRAMに書き込まれた内容を、INT 10h, AH=FFhで
グラフィック画面ではなくコンソールにテキストとして書き込んでいるので、
そもそも食い合わせが悪いです。

グラフィックVRAMの読み書きをコンソールの読み書きに挿げ替えるとかの手段も
無くはないと思いますが、そこまでしてまで対応する利点が少ないというか、
グラフィックVRAMの領域を廃して、その分をコンベンショナルメモリに回しているので、
それを止めるのは勿体ないというか。。。

すみません、本件はギブアップです（苦笑）

> DOS/Vなので、テキストはグラフィック画面に描画されていて、
> VZのDOS画面の退避・復帰もグラフィックVRAMが対象になってるみたいですね。

なるほど、VRAMを見れば何かわかりそうですね。
MS-DOS Player のVRAMは v.com で見ると
VRAM Address       = F800:0000 (Real VRAM)
と出るので、DUMPマクロで見てみたら、編集画面では表示されている文字が見えました。
ところがコマンドラインで見るとVRAMが全部スペースで埋まり初期化かCLS状態になっているようです。
他のDOSエミュではコマンドラインでもVRAMの文字が表示されていました。
どうやらこの違いが原因のようです。

> MS-DOS Playerは、仮想テキストVRAMに書き込まれた内容を、INT 10h, AH=FFhで
> グラフィック画面ではなくコンソールにテキストとして書き込んでいるので、
> そもそも食い合わせが悪いです。

そうなのですか、そのあたりはわからないので自分なりに考えてみました。
DOSは本来コンソールでコマンドを解釈、実行してその結果はコンソールに吐き出されるのですよね。
その文字はVRAMに書き込まれてパソコンの画面に表示されますよね。
つまりコマンドラインにいても画面に文字が表示されている時はVRAMに文字があるはずだと思います。
実際他のDOSエミュではコマンドラインでもVRAMの文字が表示されていました。
ところがMS-DOS Playerではそれがスペースで埋められているのです。
なので、もしかしたら MS-DOS Player ではコマンドが実行された時にVRAMの文字消去しているのではないかと思ったのです。
DOSVではVRAMの文字消去しても、フラッシュだかしないと画面に反映しないそうなので。

MS-DOS Player のソースをちょっと覗いてみたら、VRAMの初期化らしいところはありました。
void clear_scr_buffer(WORD attr)
これはあちこちで呼ばれているようですが、どこがコマンドラインかとか全くわかりませんでした。
全然わかってないので間違っていたらごめんなさいです。

> すみません、本件はギブアップです（苦笑）

VZはコンソール画面が使えるので問題ないです。対応していただいて感謝してます。
常駐VZでコマンドラインに降りた時にプロンプトが見えないのはちょっとだけ不便に感じます。(^^;

今思いついたのですが、VRAMの画面最下行だけ消去しないようにしたらもしかしてプロンプト表示しませんかね。
自分でコンパイル出来れば試したいところですが今の自分は色々頭が回らないもので。
色々対応していただきありがとうございました。

> なので、もしかしたら MS-DOS Player ではコマンドが実行された時にVRAMの文字消去しているのではないかと思ったのです。
> DOSVではVRAMの文字消去しても、フラッシュだかしないと画面に反映しないそうなので。
以下もその影響かな？
vz常駐後DOSコマンド実行してvz -zで常駐解除してcls後にvz非常駐起動するとvz -zだけ再描画されますね。

別件で以下の方が気になったりしてます。
内臓コマンドでDEL *.txtすると不明なエラーです．となり実行できないです。
*が認識されてない？他にもあるかもです。

何年かぶりに最新のエミュレーターでアセンブルしてみました。
Ml V6.15.8803
TLINK.EXE V3.01

VTDOS
　問題なし
DOSBOX（最新のテスト版）
 アセンブル OK
 各種メッセージが出力されない
MSDOS Player
 アセンブル OK
 DEL *.obj は不明なエラー（*が認識されてない）

MSDOS Playerは最新版をインストールした時に環境変数エラーが出たので
set、pathなどできるだけ短く必要最小限にしました。
環境のせいかもしれませんが？
アセンブル用BATでもエラーがでました。
で残ったのが不明なエラーでした。他にもあるかもしれません。

いずれもアセンブル出来るようになっていました。
作者様ありがとうございます。

訂正　DOSBOX→DOSVAXJ3

> vz常駐後DOSコマンド実行してvz -zで常駐解除してcls後にvz非常駐起動するとvz -zだけ再描画されますね。

どうも VRAM画面の最下行だけ表示が残っているように見えますね。
MS-DOS Player のソースは x64版はVC++2017でビルド出来るというので、コンパイルしてみたら出来ました。

void clear_scr_buffer(WORD attr)
{
//	for(int y = 0; y < scr_height; y++) {
	for(int y = 0; y <= scr_height; y++) {		//クリア行1行増やしても変わらない？
		for(int x = 0; x < scr_width; x++) {
//			SCR_BUF(y,x).Char.AsciiChar = ' ';	//この2行をコメントにしたら
//			SCR_BUF(y,x).Attributes = attr;		//コマンドと改行は残るようになった
		}
	}
}

このように修正してみました。
クリア行1行増やしたつもりでも変わらないようです。どこか間違っているのかも。
また、2行をコメントにしたらコマンドと改行は残るようになりました。
この辺が関係しているように思われますが、これ以上はわからないです。

> MS-DOS Playerは、仮想テキストVRAMに書き込まれた内容を、INT 10h, AH=FFhで
> グラフィック画面ではなくコンソールにテキストとして書き込んでいるので、

やはりこの辺を解明できないと駄目みたいですね。

> 別件で以下の方が気になったりしてます。
> 内臓コマンドでDEL *.txtすると不明なエラーです．となり実行できないです。
> *が認識されてない？他にもあるかもです。

うちの環境では問題無いようですが、何が違うのでしょうね。

> DOSBOX（最新のテスト版）
>  アセンブル OK
>  各種メッセージが出力されない

そういえば ML は32ビットでしたね。うちでも動きました。嬉しいです。

> MSDOS Player
>  アセンブル OK
>  DEL *.obj は不明なエラー（*が認識されてない）

うちでは Turbo Link でエラーが出ます。

Turbo Link  Version 2.0  Copyright (c) 1987, 1988 Borland International
msdos error, ax= 0006h

なので、MKMP.BATで使い分けています。
link /m /noi @vz.lnk,vz%HARD%;
rem tlink /m @vz.lnk,vz%HARD%.exe
exe2com vz%HARD%.exe vz%HARD%.com
rem --- comが出来たら以下のファイルを削除する
if exist vz%HARD%.exe del *.obj

shadowさんのは Turbo Link V3.01  でしたか、どこかにあったかしら。

取り急ぎです。

http://takeda-toshiya.my.coocan.jp/msdos/msdos_test.7z

> 取り急ぎです。
> http://takeda-toshiya.my.coocan.jp/msdos/msdos_test.7z

武田さん、ありがとうございます。試してみました。
最初テスト版に入れ替えても何も変わらないように見えましたが
DUMPマクロで VRAM ＄B800:0 を見たらそこに入っていました。

それで、CHEJ 02 を実行したら、VRAMが B8000 になって、DOS画面の履歴が表示されるようになりました。
そのあとは普通のモードでDOS画面が表示されるようになりました。＼(^^)／ ﾔｯﾀ-
最初変わらないように見えたのはメモリのキャッシュのせいかもしれませんね。
対応していただきありがとうございました。m(__)m

武田さん、試しました。
ほぼ改善されてるようです。
ありがとうございました。

konnoさん、粘り強い対応お疲れ様です。
ありがとうございました。

> >  DEL *.obj は不明なエラー（*が認識されてない）
うちでは以下のcommand.comでエラーは出ませんでした。
使い分けることにます。
FreeCOMJ 0.82 PL3 VTDOS 対応パッチ
Windows 98

> shadowさんのは Turbo Link V3.01  でしたか、どこかにあったかしら。
メールするのでしばらくお待ちください

delコマンドで問題のあるcommand.comのバージョンは何になりますでしょうか。

もしかしたらFCB周りで何かあるかもしれません。

変更内容としては、テキストVRAMの読み取り時に、現在表示されているコンソールの内容を返すようにしました。

正式なリリースはまた後日にでも。

> 変更内容としては、テキストVRAMの読み取り時に、現在表示されているコンソールの内容を返すようにしました。

武田さん、ありがとうございます。
朝は寝ぼけてたので、今別のPCで確認してみました。
MS-DOS Player は B8000h の CGA VRAM領域に書き込んでいるように見えます。
そして、VZは起動時のDOS画面のみ再描画しているように見えます。画面クリアの場合もあるようです。

v.com で見ると 
VRAM Address       = F800:0000 (Real VRAM)
この領域には文字が書き込まれていない（クリアされている？）、VZはここを見ているのではないかと思います。

CHEJ 02 　で謎のCGAモードにすると
VRAM Address       = B800:0000 (Real VRAM)
このモードでは完全にDOS画面を再描画してくれますが、日本語は化けています。

MS-DOS Player が F8000h の VRAM領域に書き込んでくれたら完璧な動作になるような気がします。

USモードでは VRAM が B8000h になると思いますが、
CHEJ US 　で USモードにすると
VRAM Address       = F800:0000 (Real VRAM)
このようになるので、この辺の調整も必要かなと感じます。
確認してもらえたらありがたいです。

まとレスになります。

> delコマンドで問題のあるcommand.comのバージョンは何になりますでしょうか。
> もしかしたらFCB周りで何かあるかもしれません。

うちの環境では

MS-DOS Version 6.20
14:27:09.19C:\VZ\K07V6O>del *.obj
不明なエラーです.

PC DOS Version J7.0/V	Revision 0
14:56:03.26C:\VZ\K07V6O>del *.obj
不明なエラーです.

MS-DOS Version 6.22
15:41:00.08C:\VZ\K07V6O>del *.obj
不明なエラーです.

これらで現象が出ます。

一方 Win95系では DIR で問題が
DIR vzibmj.com  と打っても DIR *.* と同じ動作になっているような？

Windows 95. [Version 4.00.950]
Windows 98 [Version 4.10.2222]
Windows Millennium [Version 4.90.3000]

これらで現象が出ます。

生DOS系とWin95系では コマンドラインの解釈や動作が若干違うようなので、それが関係あるかどうか。

> MS-DOS Version 6.20
> 14:27:09.19C:\VZ\K07V6O>del *.obj
> 不明なエラーです.
> 
> PC DOS Version J7.0/V	Revision 0
> 14:56:03.26C:\VZ\K07V6O>del *.obj
> 不明なエラーです.
> 
> MS-DOS Version 6.22
> 15:41:00.08C:\VZ\K07V6O>del *.obj
> 不明なエラーです.

konnoさんの結果に
PC DOS J6.30/V
を追加します。

> うちでは以下のcommand.comでエラーは出ませんでした。
> 使い分けることにます。
> FreeCOMJ 0.82 PL3 VTDOS 対応パッチ
> Windows 98

#11593 で書きましたが、Win95系では DIR で問題があるようです。

> DIR vzibmj.com  と打っても DIR *.* と同じ動作になっているような？
> 
> Windows 95. [Version 4.00.950]
> Windows 98 [Version 4.10.2222]
> Windows Millennium [Version 4.90.3000]
> 
> これらで現象が出ます。

なので現状では > FreeCOMJ 0.82 PL3 VTDOS 対応パッチ一択になるでしょうか。(^^;;

> > shadowさんのは Turbo Link V3.01  でしたか、どこかにあったかしら。
> メールするのでしばらくお待ちください

いただきました。リンクのエラーは出なくなりました。
ありがとうございます。

> もしかしたらFCB周りで何かあるかもしれません。
もしかして環境空間にも影響与えますか？
10/24版にしてから"環境空間が足りません"（このメッセージはPC DOS）と出たりでなかったりします。
MS DOS、PC DOSともにでます。

MS-DOS Version 6.22で「del *.obj」を実行すると、INT 21h, AH=13hに対して、
FCBで「????????OBJ」が渡されるようです。
なので、指定されたファイル名で削除するのではなく、このAPI内でファイル検索して、
ヒットしたファイルを削除するような実装に修正する必要がありますね。

Windows 98 [Version 4.10.2222]のCOMMAND.COMでDIRの問題は再現できませんでした。

取り急ぎその２です。
INT 21h, AH=13hにワイルドカードが渡された場合の対策を入れました。

http://takeda-toshiya.my.coocan.jp/msdos/msdos_test.7z

> 一方 Win95系では DIR で問題が
> DIR vzibmj.com  と打っても DIR *.* と同じ動作になっているような？
> 
> Windows 95. [Version 4.00.950]
> Windows 98 [Version 4.10.2222]
> Windows Millennium [Version 4.90.3000]
> 
> これらで現象が出ます。

うちのは問題ないです。
Windows 98 [Version 4.10.1998]

> MSDOS Playerは最新版をインストールした時に環境変数エラーが出たので
以下のショートカットから起動しているので
E:\msdos.exe -x -e -h -v6.2 E:\cmd\m62v\command.com /k e:\go.bat
いつの頃からか書き込まれていたbatファイルの一部をコメントにしました。
以前の版では"環境空間が足りません"は出なかったので気づきませんでした。
rem MSDOS_COMSPEC = C:\xxxxxxx.xxx
rem MSDOS_PATH = C:\xxxxx
rem MSDOS_TEMP = C:\xxxxx
これで出なくなりました。
この度の更新版でも以下の２つはremしなくても"環境空間が足りません"はでないんだ。
と言うか設定されてる。
FreeCOMJ 0.82 PL3 VTDOS 対応パッチ
Windows 98

> 取り急ぎその２です。
> INT 21h, AH=13hにワイルドカードが渡された場合の対策を入れました。
削除できるようになりました。
ありがとうございました。

まとレスです。

> Windows 98 [Version 4.10.2222]のCOMMAND.COMでDIRの問題は再現できませんでした。

うう、同じレビジョンでも違いが出るとは、何が違うのか色々やってみました。
なんか、Cドライブだけおかしいみたいです。Dドライブとかでは正常でした。
最近のシステムドライブはSFNが無いそうですが、それが関係してないでしょうか。

最新のテスト版でも Win95系command.com では
Cドライブで VZのアセンブルで MK6.BAT 実行すると 窓が消滅します。
理由はわからないですが、上に書いたことと関係あるような気もします。

>command /c dir vzibmj.com
とか
>cmd /c dir vzibmj.com
だと正常な動作になります。
とりあえず当面は Win95系は使わないようにします。

♯　なんかツリーの形が凄いことになってるなぁ。(^^;

SFNがサポートされていないドライブでの動作は、流石にちょっと難しいです。
もちろん、まったく動かない訳ではないのですが。。。


MS-DOS Player内で動的にSFNをでっちあげる仕組みを考えたこともありますが、
次に起動したときに違うSFNになると問題を起こしそうな気がして断念しました。

> SFNがサポートされていないドライブでの動作は、流石にちょっと難しいです。
> もちろん、まったく動かない訳ではないのですが。。。
> 
> MS-DOS Player内で動的にSFNをでっちあげる仕組みを考えたこともありますが、
> 次に起動したときに違うSFNになると問題を起こしそうな気がして断念しました。

問題の原因がそれかどうかもわからないので、しかたないですね。
それ以外の command.com は問題無くなったので無問題です。
ありがとうございました。

v.com でVRAMの判定がエミュ3種で違っているのが気になって、
どう判定しているのか逆汗してみました。
ソーサーでも全部は逆汗できず、SYMDEB でアセンブルした部分を張ります。

2AA1:0145 6A40           PUSH   40                            ;'@' 
2AA1:0147 07             POP    ES 
2AA1:0148 BEA603         MOV    SI,03A6                 ; 09[00]
2AA1:014B 26A04900       MOV    AL,ES:[0049]            ; Video mode
2AA1:014F 32E4           XOR    AH,AH 
2AA1:0151 8904           MOV    [SI],AX                 ; [si]=00xx  vmode
2AA1:0153 26A14A00       MOV    AX,ES:[004A]            ; 桁数
2AA1:0157 894402         MOV    [SI+02],AX              ; [si+2]= column
2AA1:015A 26A08400       MOV    AL,ES:[0084]            ; 行数 line
2AA1:015E 32E4           XOR    AH,AH 
2AA1:0160 40             INC    AX 
2AA1:0161 894404         MOV    [SI+04],AX              ; [si+4]= line+1
2AA1:0164 26A18500       MOV    AX,ES:[0085]            ; font H
2AA1:0168 894406         MOV    [SI+06],AX              ; [si+6]= font H
2AA1:016B 6800B8         PUSH   B800                    ; B800h
2AA1:016E 07             POP    ES                      ; ES=B800h
2AA1:016F 33FF           XOR    DI,DI                   ; DI=0
2AA1:0171 26833DFF       CMP    Word Ptr ES:[DI],-01    ; [B800:0]=ffffh なら ES=A000h
2AA1:0175 7508           JNZ    017F                    ; not FFFF --> 017f jump
2AA1:0177 6800A0         PUSH   A000                    ; A000h
2AA1:017A 07             POP    ES                      ; ES=A000h
2AA1:017B 83440804       ADD    Word Ptr [SI+08],+04    ; [si+8]=[si+8]+04
  017f:
2AA1:017F B4FE           MOV    AH,FE                   ; ah=FEh   擬似テキストバッファ先頭アドレス取得
2AA1:0181 CD10           int    10                      ; int 10h, 擬似テキストバッファ先頭アドレス取得
2AA1:0183 8C440A         MOV    [SI+0A],ES 
2AA1:0186 897C0C         MOV    [SI+0C],DI 
2AA1:0189 8CC0           MOV    AX,ES 
2AA1:018B 3C00           CMP    AL,00 
2AA1:018D 7404           JZ     0193 
2AA1:018F 83440E05       ADD    Word Ptr [SI+0E],+05 

2AA1:0193 BBDC02         MOV    BX,02DC 
2AA1:0196 E83800         CALL   01D1 
2AA1:0199 B8004C         MOV    AX,4C00 
2AA1:019C CD21           INT    21 


これでわかったことは、CGA VRAM B800h の先頭2バイトが 'FF FF' かどうかチェックしてるんですね。
え？　と思って、DOSVAXJ3 のコマンドラインで DUMPマクロで見たら
B800h から 8000h の間が FFh で埋まっていました。

VTDOS は B800h から 00h で埋まってる、というか、ゴミもあるので普通のメモリ領域のようです。

MS-DOS Player は B800h から 1C20h の間が 20h 17h で埋まっていました。
つまり、MS-DOS Player だけ B800h の領域をVRAMとして初期化しているということでしょうか。
これを踏まえて私の理解を纏めると

DOSVAXJ3
VRAM Mode          = APA                        ; B800h == FF FF の時
VRAM Address       = C679:0000 (Virturl VRAM)   ; 仮想VRAM と認識

VTDOS
VRAM Mode          = A/N                        ; B800h != FF FF == 00 00 の時
VRAM Address       = D000:0000 (Real VRAM)      ; リアルVRAM と認識

MS-DOS Player
VRAM Mode          = A/N                        ; B800h != FF FF == 20 17 の時
VRAM Address       = F800:0000 (Real VRAM)      ;リアルVRAM と認識し、B800h が仮想VRAMとなる？

もしもこの考えが合っているとしたら、B800h を FF,FFか 00,00 で初期化すれば うまくいきそうな気がします。
その場合、仮想VRAMは、上のチェックルーチンを見ると、 VGA A000h に設定すれば良さそうに思えます。
VTEXTは画面モードは03で、実際は 70h になっていますが、03 は本来 CGA モードだと思うので
この辺の辻褄をうまく合わせてやればいいのかなと素人考えで思いました。

武田さん、この考えどう思いますでしょうか。

MS-DOS Playerでは、CGAのテキストモード(03h)を基本としています。
B8000hがVRAMの先頭で、文字コード、アトリビュートが交互に80x25文字分続きます。
MDAもサポートしており、この場合はB0000hがVRAMの先頭となります。

ハード的にはCGA/MDAで、ただし漢字などマルチバイト文字が表示できるという、
ちょっと変な構成になっています。

VRAMの先頭がA0000hになるのはグラフィックモードの場合です。
MS-DOS Playerはコンソールアプリですので、グラフィックモードは使いません。
グラフィックVRAMはなしで、AFFFFhまではコンベンショナルメモリに回しています。

ここ最近の諸々を反映した新バージョンをリリースしました。
DEL *.OBJだけでなく、REN *.OBJ *.BINとかも出来るようになってます。

武田さん、お返事ありがとうございます。

> MS-DOS Playerでは、CGAのテキストモード(03h)を基本としています。
> B8000hがVRAMの先頭で、文字コード、アトリビュートが交互に80x25文字分続きます。
> MDAもサポートしており、この場合はB0000hがVRAMの先頭となります。
> 
> ハード的にはCGA/MDAで、ただし漢字などマルチバイト文字が表示できるという、
> ちょっと変な構成になっています。
> 
> VRAMの先頭がA0000hになるのはグラフィックモードの場合です。
> MS-DOS Playerはコンソールアプリですので、グラフィックモードは使いません。
> グラフィックVRAMはなしで、AFFFFhまではコンベンショナルメモリに回しています。

うーん、これを聞くと今回の案は難しそうですね。
やっぱり諦めます。ありがとうございました。

> ここ最近の諸々を反映した新バージョンをリリースしました。
> DEL *.OBJだけでなく、REN *.OBJ *.BINとかも出来るようになってます。

武田さん、更新ありがとうございます。

-----------------------------------------------------------
024/10/31
CGA/MDAのテキストモードのVRAM、または仮想テキストバッファを読むことで、
コンソール画面の表示内容を取得できるようにしました。
VZエディタで[ESC]Eでプロンプトに降りた時、DOS画面が復帰するようになっています。

INT 21h, AH=13h/17hで、ワイルドカードを含むファイル名をサポートしました。
FCBを使ったファイルの削除およびリネームのサービスです。
MS-DOS V6.22のCOMMAND.COMのDEL/RENコマンドで使われていました。

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

直前のレスで諦めましたとか書いたら入れ違いになったのですね。(^^;
DOS画面復帰は、CHEJ 02 の CGAモードの時でしょうか。
このモードではDOS画面の漢字文字化けは無くなりましたがVZの画面の漢字が化けます。

ともあれ諸々改善できたので嬉しいです。
ありがとうございました。

＃　今夜はハローWinのプレゼントだぁ。＼(^^)／ 

私はCHEJは特に使用していませんが、vzはint10h ah=fehで取得した仮想テキストバッファのアドレスの、f8000hを読みに来ているようです。
書き込み時も、同じアドレスに書き込んで、int10h ah=ffhで画面に反映してるのではないかと。

> 私はCHEJは特に使用していませんが、vzはint10h ah=fehで取得した仮想テキストバッファのアドレスの、f8000hを読みに来ているようです。
> 書き込み時も、同じアドレスに書き込んで、int10h ah=ffhで画面に反映してるのではないかと。

私もそう思います。
ところがコマンドラインでは f8000h がスペースで埋まり、b8000h に文字が見えるのです。
DOS画面の保存、復帰のタイミングは VZしかわからないので、VZですり替え出来ないかやってみました。
scrnibm.asm 1483行あたり

getscrn	proc
	pushm	<ds,es>
	mov	es,ax
	mov	ds,dsp.@seg

	push	ax		; ##k 241101  MS-DOS Player
	mov	ax,ds		; ds は
	cmp	ax,0f800h	; VRAM F800h か？
	jnz	mpmod		; 違うならJUMP
	cmp	cs:os_win,7	; MS-DOS Playerか？
	jnz	mpmod		; 違うならJUMP
	mov	ax,0b800h	; CGA VRAM にすり替え  'ｸ^@ｸ'  b8h (00h b8h)
	push	ax		; 'P' 50h
	pop	ds		; ds:si(ソース) --> es:di
mpmod:	pop	ax		;

IFNDEF IBM
cpyscrn:

ここにコメント行を追加して VRAMアドレスのすり替えをしたら保存・復帰が出来ました。＼(^^)／ ﾔｯﾀ-
MS-DOS Player の判定に失敗することが有るので見直して公開したいと思います。
安全対策を2重にしているので問題ないでしょう。
将来 B8000hが変わるとヤバいので、その時は VZ.COMを開いて 'ｸ^@ｸP' を検索してアドレスを書き換えます。(^^;
^@ は実際はヌル文字です。(^^;;

> ここ最近の諸々を反映した新バージョンをリリースしました。
> DEL *.OBJだけでなく、REN *.OBJ *.BINとかも出来るようになってます。
武田さん、ありがとうございます。

VZk07v6o(暫定) （2024-11-01）版を VZの部屋に置きました。

　・フォルダの階層が深いと拡張子が消えるなどまだバグあり、注意。
　・最新の MS-DOS Player で DOS画面の保存・復帰対応。
　・オプション Ow の仕様変更（MS-DOS Playerの判定のため) Ow512 以上で MS-DOS Player

　ダウンロード　 vzkv6o.lzh ver1.60k07v6o （2024-11-01版 ） new!

> VZk07v6o(暫定) （2024-11-01）版を VZの部屋に置きました。
> 
> 　・フォルダの階層が深いと拡張子が消えるなどまだバグあり、注意。
> 　・最新の MS-DOS Player で DOS画面の保存・復帰対応。
きっちり再描画できてうれしいです。
本当にありがとうございます。
ところで後学のため#11611のソースの変更箇所を教えてください。

> きっちり再描画できてうれしいです。

実現できて私が一番嬉しいです。(^_^)
以前は気にならなかったのに、気にし出したら夜も眠れず昼寝して・・φ(..; ﾊﾞｷｯ＼(--;

> ところで後学のため#11611のソースの変更箇所を教えてください。

コメントのある行を丸ごと追加しています。解説はコメントの内容でわかりますよね。
あとは MS-DOS Player の判定を main.asm でやっていますが、これが無くても問題ないですね。
仮に問題が出たとしても画面表示がおかしくなるだけなので、その場合は使用中止すればいいし。
DOSエミュ3種で動かすぶんには問題ないと思います。
他の環境で使う場合は、v.com などで VRAMアドレスを確認すれば安心です。

ということで、他のVZに移植するなら scrnibm.asm のこの個所だけ追加すればいいですね。
 MS-DOS Player の判定部分はコメントにするか削除します。

scrnibm.asm 1483行あたり

getscrn	proc
	pushm	<ds,es>
	mov	es,ax
	mov	ds,dsp.@seg

	push	ax		; ##k 241101  MS-DOS Player
	mov	ax,ds		; ds は
	cmp	ax,0f800h	; VRAM F800h か？
	jnz	mpmod0		; 違うならJUMP
;	cmp	cs:os_win,7	; MS-DOS Playerか？
;	jnz	mpmod0		; 違うならJUMP
	mov	ax,0b800h	; CGA VRAM にすり替え  'ｸ^@ｸ'  b8h (00h b8h)
	push	ax		; 'P' 50h
	pop	ds		; ds:si(ソース) --> es:di
mpmod0:	pop	ax		;

IFNDEF IBM
cpyscrn:

これでOKです。mpmod は mpmod0 に変更しました。

必要があって DIR を取ろうと思ったら、各種DOSエミュでみんな書式が違うんですね。
ちょっと比べてみました。

VTDOS	MSDOS 6.20	DIRは内蔵  LFNのみの表示
2011/02/16  20:35               616 FGAL.DEF
2004/06/21  00:46             3,104 fgaldc_14_8086.log

DOSVAXJ3		内蔵　SFNと LFN両方表示
FGAL     DEF                616 2011-02-16 20:35 FGAL.DEF
FGALDC~1 LOG              3,104 2004-06-21  0:46 fgaldc_14_8086.log

MS-DOS Player	MSDOS 6.20
FGAL     DEF           616 11/02/16   20:35
FGALDC~1 LOG         3,104 04/06/21    0:46

MS-DOS Player	FreeCom 7.00
FGAL     DEF           616  11/02/16 20:35
FGALDC~1 LOG         3,104  04/06/21  0:46

MS-DOS Player	Win95 〜 Win98ME
FGAL     DEF           616  11/02/16  20:35 FGAL.DEF
FGALDC~1 LOG         3,104  04/06/21   0:46 fgaldc_14_8086.log

今回は SFNのみの表示が欲しいので MS-DOS PlayerのDOS6.2かFreeCom かな。
と思ったら、MS-DOS Player + FreeComで dir > file とやったら、改行が 0Ah でした。(>_<)
VTDOSで確認しようとしたら > が効かないし、FreeCom ってやっぱり癖が強いようですね。

> DOSエミュ3種で動かすぶんには問題ないと思います。
> 他の環境で使う場合は、v.com などで VRAMアドレスを確認すれば安心です。
> 
> ということで、他のVZに移植するなら scrnibm.asm のこの個所だけ追加すればいいですね。
>  MS-DOS Player の判定部分はコメントにするか削除します。
先のソースでMS-DOS Player の判定部分2行をコメントにして再描画出来てたのですが念のためお願いしました。
ありがとうございました。

ひそひそ。

> 必要があって DIR を取ろうと思ったら、各種DOSエミュでみんな書式が違うんですね。
> ちょっと比べてみました。

うろ覚えで申し訳ないのですが。
VTDOSってcommand.comを差し替えられたような気がします。
もし私の記憶が確かなら、MS-DOS Playerと同じ結果が得られるようにできるのでは
ないかなぁ。
あと、DOSVAXはDOSのエミュレータではなくてマシンのエミュレータだと思い込んで
いたのですが、これは私の認識が妖しい、ないしはおかしい、かも。

> 先のソースでMS-DOS Player の判定部分2行をコメントにして再描画出来てたのですが念のためお願いしました。

shadowさんなら出来ると思ってました。
私もすんなり出来たわけではなく、武田さんとのやり取りの中で色々試行錯誤してました。
アセンブラ入門を読んでVRAMずらしの常駐プログラムを作ったけどうまくいかず。
昔作ったJ31用ソフトをパソピアや200LXなどで動かすVRAM変換常駐プログラムを流用してみたけどうまくいかず。
#11570 で getdosscrn だろうと思いましたが、そこを弄っても駄目だったので、その先の getscrn にたどり着いたのでした。

> VTDOSってcommand.comを差し替えられたような気がします。
> もし私の記憶が確かなら、MS-DOS Playerと同じ結果が得られるようにできるのでは
> ないかなぁ。

くだけた話かもですが、#11616 で書いています。
> VTDOS	MSDOS 6.20	DIRは内蔵  LFNのみの表示
DIRは VTDOS内蔵のものなのですよね、なので FreeCom の問題かどうか確認するために
> VTDOSで確認しようとしたら > が効かないし、FreeCom ってやっぱり癖が強いようですね。
VTDOSで FreeComを入れたのですが、環境領域が不足して動作が不安定みたいだったのです。
それでリダイレクトが動かなかったので確認できなかったのです。
どなたか確認できる人いませんかね。

> あと、DOSVAXはDOSのエミュレータではなくてマシンのエミュレータだと思い込んで
> いたのですが、これは私の認識が妖しい、ないしはおかしい、かも。

確かにDOSBOXベースでマシンをエミュレートしているので、PCエミュレータとなるでしょうか。
でも最近のは内蔵DOSで直接DOSエミュレート出来るので、DOSエミュというのも間違いではないかと。

対義語は「ネコにちゅ〜る」かな。

> くだけた話かもですが、#11616 で書いています。
> > VTDOS	MSDOS 6.20	DIRは内蔵  LFNのみの表示

どうやら話がすれ違っているらしい。
私、VTDOSの仕様を忘れてしまっているのですが、たしかSHELL指定ができましたよね。
なので、これを指定すればそっちのDIRが使われると思っていました。
そして、これを指定しなかった結果が#11616、と思い込んだわけです。そこで、これ
の指定でcommand.comを他のものに差し替えてみれば、というのが#11618。
だけど、

> DIRは VTDOS内蔵のものなのですよね、なので FreeCom の問題かどうか確認するために

ということは、VTDOSではSHELLを指定しても内蔵DIRが使われる、ということのよう
ですね。

どうも大変失礼しました。

> VTDOSで FreeComを入れたのですが、環境領域が不足して動作が不安定みたいだったのです。
> それでリダイレクトが動かなかったので確認できなかったのです。
> どなたか確認できる人いませんかね。
FreeComはゼロバイトのファイルを作るけどリダイレクトできないです。

> 対義語は「ネコにちゅ〜る」かな。

一瞬 ？？？ となりましたが、「猫に小判」をパロッたんですね。(^^;
共通点はどちらも鉱山から取れる、ということでタイトルに。(^^;

> どうやら話がすれ違っているらしい。
> 私、VTDOSの仕様を忘れてしまっているのですが、たしかSHELL指定ができましたよね。
> なので、これを指定すればそっちのDIRが使われると思っていました。

VTDOS.CFG を確認しましたが、USECMD=1 になっていました。どちらでも内蔵DIR が使われるようですね。
外部コマンドでもリダイレクト出来ないようなので、VTDOSと FreeCom の相性問題なのかも。

> > どなたか確認できる人いませんかね。
> FreeComはゼロバイトのファイルを作るけどリダイレクトできないです。

確認していただきありがとうございます。
あ、ほんとだ、ゼロバイトのファイルが出来てる！
やはり VTDOS+FreeCom ではリダイレクトが使えないのですね。
してみると、FreeComを使うなら MS-DOS Player がいいということになりますね。

それで思い出したのですが、私は「VTDOS リダイレクト」で掲示板の検索をしようと思っていたのでした。
うう、どんどん硬骨、じゃない、恍惚の人になりつつあるなぁ。(;_;)

検索したら、#6786で
> ２．10#さん改造のFreeCom（command.com）でVZを動かす。
> ・これはVZが常駐使用できるように改造された版なので、普通のcommand.comとして使用できます。
> ・他と違うのは、NULへのリダイレクトがエラーになる　>NUL　が使えない。
自分でこんなことを言っていました。(^^;;

また、#4794で 10＃さんが
> VTDOSではリダイレクト機能など、一部期待通りに動作しません。
と言っていますね。2010年の記事ですが、VTDOSの構造からくる仕様なのかもしれないですね。


＃　お宝は足元の鉱山を掘れば見つかるのさ。(;_;)

真珠との対比となると、こいつは外せない、というところ。

> VTDOS.CFG を確認しましたが、USECMD=1 になっていました。

古いXPマシンを引っ張り出してきて、私のところのVTDOSの設定を確認してみたら、
USECMD=1がコメントアウトしてあった。ということは、SHELLで指定している
command.comを使う、ということだと思う。
私自身の設定がこうなっていたことから、いろいろと誤解というかすれ違いが発生
したのでしょう。
ただ、なにぶん、最近いじっていないので、いくつか確認させてください。

> USECMD=1 になっていました。どちらでも内蔵DIR が使われるようですね。

この「どちらでも」というのは、SHELLを指定していようがしていまいが内蔵DIRが
使われる、という意味ですよね。違うかな。

> 外部コマンドでもリダイレクト出来ないようなので、VTDOSと FreeCom の相性問題

FreeCom以外のcommand.comを使った場合の結果はどうなるのでしょうか。
また、USECMD=1ではない場合の結果はどうなるのでしょうか。
このへん、FreeComでなければならない理由というのを、私が読み落としてしまって
いるかもしれない。あるいは、読んだけれど忘れている、という可能性も高いかも。

> 真珠との対比となると、こいつは外せない、というところ。

もはや内容とは関係ないところで暗闘している感が。(^^;
ちょうどパールを弄っていたところだったのでセーフ？ (ﾟ゜)☆＼(--#)ﾊﾞｷｯ
というか、ポケット某 って何ですか、もうわけわかです。

> 古いXPマシンを引っ張り出してきて、私のところのVTDOSの設定を確認してみたら、
> USECMD=1がコメントアウトしてあった。ということは、SHELLで指定している
> command.comを使う、ということだと思う。

え？　内蔵簡易CMD を使わないのが USECMD=1 だと思っていました。
vtdos.txt には

USECMD=0|1
  ビルトインコマンドの実行にCMD.EXEを利用します。
  デフォルトは0(利用しない）ですが、1を推奨します。

とありますね。試しに USECMD=0 で DIR したら、SFNで表示されました。げげぇ、、、
今まで LFN表示していたのは、CMD.EXE の DIRだったのか〜
どうやら私が勘違いしていたようです。すみませんでした。m(__)m

> > USECMD=1 になっていました。どちらでも内蔵DIR が使われるようですね。
> この「どちらでも」というのは、SHELLを指定していようがしていまいが内蔵DIRが
> 使われる、という意味ですよね。違うかな。

ということで、これは私の勘違いで、USECMD=1 で CMDのDIRが表示されていたようです。m(__)m
USECMD=0 で DIR したら、command.com 本来の表示になるようです。

> > 外部コマンドでもリダイレクト出来ないようなので、VTDOSと FreeCom の相性問題
> FreeCom以外のcommand.comを使った場合の結果はどうなるのでしょうか。
MSDOS6.2 ではキチンとリダイレクト出来ています。

> また、USECMD=1ではない場合の結果はどうなるのでしょうか。
これも MSDOS6.2 ではキチンとリダイレクト出来ています。

> このへん、FreeComでなければならない理由というのを、私が読み落としてしまって
> いるかもしれない。あるいは、読んだけれど忘れている、という可能性も高いかも。
元々の理由は単に DIR とした時に FreeCom の表示がちょうどよかったというだけのことでした。
そもそも DIRはオプションで表示形式は変えられるので、単にものぐさしただけだったのにこんな大事に。

> もはや内容とは関係ないところで暗闘している感が。(^^;

確かに。
お互い、一体何をやってんだか。

> というか、ポケット某 って何ですか、もうわけわかです。

そんなことを言うダーリンには黄色い電気ねずみがでんげきバリバリだっちゃ！
＃でんげきつながりやめろ


USECMDについてなんですが、うちのVTDOS1.22の vtdos.txt には

> USECMD
>   ビルトインコマンドの実行にCMD.EXEを利用します。

しか書いていないんですよ。なので、0と1のどちらがデフォルトなのかもわからない
し、どちらを指定したときにCMD.EXEを使うのかもわからない。ということで、実は

> > 古いXPマシンを引っ張り出してきて、私のところのVTDOSの設定を確認してみたら、
> > USECMD=1がコメントアウトしてあった。ということは、SHELLで指定している
> > command.comを使う、ということだと思う。

これもあてずっぽだったりする。たまたま正解だったようですが。

> > もはや内容とは関係ないところで暗闘している感が。(^^;
> 
> 確かに。
> お互い、一体何をやってんだか。
> 
> > というか、ポケット某 って何ですか、もうわけわかです。
> そんなことを言うダーリンには黄色い電気ねずみがでんげきバリバリだっちゃ！
> ＃でんげきつながりやめろ

黄色い電気ねずみで、とある小さなモンスターが浮かびました。
それで、「○○モン パール」で検索したら色々ダイヤなどもザクザク出てきました。
うーむ、私は全く見てないもので。見てるのは一見不細工な猫のような先生ものとか。(^^;

> USECMDについてなんですが、うちのVTDOS1.22の vtdos.txt には
> > USECMD
> >   ビルトインコマンドの実行にCMD.EXEを利用します。
> しか書いていないんですよ。なので、0と1のどちらがデフォルトなのかもわからない
> し、どちらを指定したときにCMD.EXEを使うのかもわからない。ということで

確かにわかりにくいかもですね、私もそれで勘違いしていた部分はあるかも。(^^;

> > > 古いXPマシンを引っ張り出してきて、私のところのVTDOSの設定を確認してみたら、
> > > USECMD=1がコメントアウトしてあった。ということは、SHELLで指定している
> > > command.comを使う、ということだと思う。
> これもあてずっぽだったりする。たまたま正解だったようですが。

おかげさまで私の勘違いがわかりました。お礼に何かプレゼン

とりあえず、もんどうも暗闘も終わったようなので、まとめというか。
絶対違うけど。

> うーむ、私は全く見てないもので。

いや、私も全く見ていないというか、タイトルを知っているだけ。

> 見てるのは一見不細工な猫のような先生ものとか。

私には「一見不細工な猫のような先生もの」というのがわけわか。
風大左衛門君の師匠のニャンコ先生は知っている。
よくタヌキに間違えられるほどに不細工な猫型ロボットも知っている。
でも、先生もので不細工な猫って知らない。
いつかそのうち、こいつのことをプレゼンしてください。

軟式さんから DOSVAXJ3 (2024/11/06)テスト版のメールをいただきました。
内容は

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

>　stdout と stderr が分離できていなかったのと、Windows アプリ側から
>カレントディレクトリのファイルを正しく認識できていなかったのを修正
>しています。テスト版は下記からダウンロードできます。
>https://www.nanshiki.co.jp/test/dosboxj_test3.zip

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

細かい修正があるようです。
CLPPST.EXE もバッチリですし、32ビットのCOPY系も動くようになり、快適です。
正式版がまちどうしいですね。
本当に感謝です。

軟式さんから DOSVAXJ3 (2024/11/07)テスト版のメールをいただきました。
内容は

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

>　さらにいろいろ見直しまして、ドライブのルートを mount しなくても
>大丈夫になりました。テスト版は下記にあります。
>https://www.nanshiki.co.jp/test/dosboxj_test4.zip

>　mount c c:\dos 等として、Windows コンソールプログラムに DOSVAXJ3
>上の C ドライブのファイルを指定して渡しても大丈夫です。
>　処理としてはコマンドラインパラメータのパスを書き換えています。

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

mount e d:\log\fgal\ として、32ビットコピーも問題なく出来ました。
これはいいですね。ますます便利になりました。
作者様に感謝です。

> 風大左衛門君の師匠のニャンコ先生は知っている。
> よくタヌキに間違えられるほどに不細工な猫型ロボットも知っている。
> でも、先生もので不細工な猫って知らない。
> いつかそのうち、こいつのことをプレゼンしてください。

わかりました。せっかくなので、鉱山から発掘した古の暗嗣、絵数化布の秘法で
プレゼンを作ってみました。答えは以下に。

#txt=anime.dat

このファイルはコントロールコードを含んでいるので右クリックで保存してください。
ファイルの拡張子を BAT に変更してカレントフォルダに置いて実行してください。

＃　大丈夫、ウイルスは含んでいません。城の地下ログからくみあげたものだから。

尚、VTDOS121 ではまともに動かないと思いますので最近のVTDOSか
DOSVAXJ3 なら問題なく結果を表示すると思います。
MS-DOS Player + FreeCOM もうまく動かないと思います。原因不明
MS-DOS Player + Win95系COM + オリジナルVZもうまく動かないと思います。BATの不具合

> わかりました。せっかくなので、鉱山から発掘した古の暗嗣、絵数化布の秘法で
> プレゼンを作ってみました。答えは以下に。

懐かしいですね、古の技術。
ただ、やはりここも方言というか、私は絵数系布の秘術といったほうがしっくりくる。
だからなんだ、という話ですが。

> ＃　大丈夫、ウイルスは含んでいません。城の地下ログからくみあげたものだから。

最近では、ウイルスそのものを含んでいないにもかかわらず感染して発病するワクチン
がある、なんていうヨタ話を平気でするような人がいっぱいいて。
なるほど、進歩しすぎた科学というのは呪いの黒魔術と大差がないのかもしれない。

それはさておき。
とりあえず、VTDOS122で表示はされました。
これは、組み込んでいるcommand.comの関係かもしれません。
うむ、タイトルだけは知っている。アニメ化もされたやつだ。

> 懐かしいですね、古の技術。
> ただ、やはりここも方言というか、私は絵数系布の秘術といったほうがしっくりくる。

一瞬「秘法」より「秘術」のほうがしっくりくるのかと思ってしまいました。(^^;
「絵数系布」のほうが発音も意味も通るので良いですね。これ、使わせてもらいます。

> > ＃　大丈夫、ウイルスは含んでいません。城の地下ログからくみあげたものだから。
> 最近では、ウイルスそのものを含んでいないにもかかわらず感染して発病するワクチン
> がある、なんていうヨタ話を平気でするような人がいっぱいいて。
> なるほど、進歩しすぎた科学というのは呪いの黒魔術と大差がないのかもしれない。

世界ではより大きな暗闇の中で暗闘が続いているとかいないとか、、と言う感じですかね？
私は暗闇は怖いので、「君子危うきに近寄らず」を徹底していきます。
変な電話やインターホンには出ないし、防犯カメラも欲しいなぁ。

＃　痛ッ、、ほら、怖くない、怯えていただけなんだよね・・・
　　って冗談じゃなく、世の中怖くなってますよねぇ、、、


> とりあえず、VTDOS122で表示はされました。
> これは、組み込んでいるcommand.comの関係かもしれません。
> うむ、タイトルだけは知っている。アニメ化もされたやつだ。

無事表示されたようで何よりです。
うちの VTDOS122 では表示出来ませんでした。あれぇ？　調べてみたら
USECMD=1
これがあると表示しないようです。VER とやっても何も表示しない。
VTDOS121 も同様でした。
うーむ、もしかして XP だと Ver も表示したりして？
Win10,11 64ビットでは色々制限がきつくなっているようですしねぇ。(-_-;)

＃　もうマクロ玉も蟲封じも効かない・・・

win11を24H2に更新したらレガシコンソールモードが削除されるって知らなかったです。
再インストール方法を昼から検索してやっと20時過ぎからインストール
オプションのオンデマンド機能としてインストールするようになってました。
その最中に四国電力管内で大規模停電約40分。通電後続きからインストールできました。
取り合えずインストール方法を残しておきます。
設定→システム→オプション→オプション機能を追加する（機能表示）
→Legacy Console Host追加
近い将来レガシコンソールモードはサポート中止なる可能性が高いですね。

> win11を24H2に更新したらレガシコンソールモードが削除されるって知らなかったです。

げげ、そうなんですか、大変だぁ！！
うちのは、Win10 22H2 で、Win11にも出来ないのでどうなることやら。

> 再インストール方法を昼から検索してやっと20時過ぎからインストール
> オプションのオンデマンド機能としてインストールするようになってました。

おお、オプションではあるのですね、ひとまずは安心しました。

> その最中に四国電力管内で大規模停電約40分。通電後続きからインストールできました。

あらま、でも最初からやり直しとかHDDクラッシュとかならなくて良かったですね。

> 取り合えずインストール方法を残しておきます。
> 設定→システム→オプション→オプション機能を追加する（機能表示）
> →Legacy Console Host追加

ありがとうございます。近いうちこれが役に立ちそうな雰囲気ですね。

> 近い将来レガシコンソールモードはサポート中止なる可能性が高いですね。

うう、そうなると VZの生き残りも厳しいですね。
VTDOSは更新があるかわからないので、使えなくなる可能性も・・・

> うう、そうなると VZの生き残りも厳しいですね。
> VTDOSは更新があるかわからないので、使えなくなる可能性も・・・
VTDOSはCKWVがあれば問題ないので更新は・・・。DOSVAXJ3は問題ないです。
MSDOS Playerは対応してくれることを期待しています。
今回の更新から「Windows Terminal」がデフォルトになったようです。
次のwindows12ではオプションからも・・・。

> VTDOSはCKWVがあれば問題ないので更新は・・・。DOSVAXJ3は問題ないです。

ということは、レガシコンソールモードが無くても問題無いということですか。
それなら安心ですね。

> MSDOS Playerは対応してくれることを期待しています。

構造が素のVTDOSに似ているように見えるので同じ問題があるのでしょうね。
CKWVが MS-DOS Player にも使えれば改善されるのでしょうかねぇ。

> 今回の更新から「Windows Terminal」がデフォルトになったようです。
> 次のwindows12ではオプションからも・・・。

えっ、Win12 が出るのですか！　って見てみたら来年後半には出るような話があるのですね。
うちのPCは WWin11 への更新も出来なさそうなので、新しいPCを買うことになりそうですね。
困ったものです。(^^; ﾜｸﾜｸ

> > その最中に四国電力管内で大規模停電約40分。

大規模停電の原因は、本州で発生した謎の極大電力消費により四国が緊急パージされたためとか。
過去には北海道の大規模長時間停電の事例もあるし、これはどこで起きてもおかしくないですね。
最低限の備えはしておいた方が良さそうですね。

ところで、「本州で発生した謎の極大電力消費」というのが気になりました。
まさか、#11627 の書き込みが原因だったりして。
> そんなことを言うダーリンには黄色い電気ねずみがでんげきバリバリだっちゃ！

というのは冗談ですが、国や謎の組織が何らかの実験をしていたという可能性はあるかも。
国家的な危機に備えたヤシマ作戦の実験に失敗してポジトロン〇が融解したとか
波動〇^Hエンジンの起動実験とか巨大レールガンの実験とか、S2機関が（きな臭い話ばっかりや）
あるいは某国がひそかに盗電をやりすぎちゃったとか、巨大人型EVA充電・・・

＃　これは全部妄想の独り言です

> 構造が素のVTDOSに似ているように見えるので同じ問題があるのでしょうね。
> CKWVが MS-DOS Player にも使えれば改善されるのでしょうかねぇ。
ckwv.txt by 10#には以下の記載がありました。
VTDOS以外のプログラムを利用することも可能です。
ckwv + MSDOS Player で本家CKWよりまともな描写でvz常駐できました。
レガシコンソールのオプション外した時の挙動は知らんけど（笑）。
現状必要性がないのでこれで終わります。

> ckwv.txt by 10#には以下の記載がありました。
> VTDOS以外のプログラムを利用することも可能です。
> ckwv + MSDOS Player で本家CKWよりまともな描写でvz常駐できました。

えっ、と思って 使っていない CKWV12の CKWV.CFG を以下のように変更して起動してみました。
Ckw*title: ckwv12/MS-DOS Player
Ckw*exec:  c:\ut\msdos.exe -e -x -v6.20 c:\ut\p\command.com /k c:\ut\vzp.bat

おお、まるで CKWV+VTDOSのような画面で起動できました。！！ ＼(^^)／ ﾔｯﾀ-
漢字キーで赤いカーソルにもなりましたが、入力に難がありました。
ALT+アルファベットに相当する文字入力でマクロが起動してしまいます。
え、お、く、などの文字が、@E @O @K になるので、IME起動中は ALT シフト状態なのかもしれません。
IME起動中もカーソルが効いて変換中文字が移動したりしてしまいますね。
うーん、ここまできたら何とかならないものでしょうかねぇ。

> レガシコンソールのオプション外した時の挙動は知らんけど（笑）。
> 現状必要性がないのでこれで終わります。

私もこれはわざわざ試したくはないですね。(^^;

> ckwv + MSDOS Player で本家CKWよりまともな描写でvz常駐できました。
私が試したCKWは古いバージョンでした。最新版では改善されていました。
最新版はckw-mod-0.9.1-mod-r6_x64.zipでGithubで公開されていました。
https://github.com/rururutan/ckw-mod/

> 私が試したCKWは古いバージョンでした。最新版では改善されていました。
> 最新版はckw-mod-0.9.1-mod-r6_x64.zipでGithubで公開されていました。
> https://github.com/rururutan/ckw-mod/

おお、ckw も更新が進んでいたのですね。
って見に行ったらソースしかないように思ったのでソースを落としてコンパイルしてみましたが
プロジェクトが無いなどでコンパイルできませんでした。(;_;)
改めてサイトを見直したら About の下に Releases 6 とあって、そこに実行ファイルがありました。＼(^^)／ ﾔｯﾀ-

早速動かしてみましたが、どうも画面サイズなどの同期がとれていない感じで
このままでは常用は無理そうです。
IMEでの漢字入力は改善されていました。

IME関連のソースとか参考にして少し弄って遊んでみたいと思います。(^^;
有用な情報ありがとうございました。

DOSVAXJ3 (2024/11/15)テスト版のメールをいただきました。
内容は

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

　さらに見直しまして、Visual C++ 製のプログラムであれば入力も可能とな
りました。clppst.exe は Delphi 製ですが入力はありませんので問題なく動
作します。

　途中で止まってしまうプログラムは Ctrl-C で強制終了できるようになりま
したのでタイムアウトによる終了はなくなりました。

　表示がでない Windows コンソールプログラムがありましたら
> set dosvaxj3=noinput
　とした後で実行してみてください。
> set dosvaxj3=setenv
　で現在設定されている環境変数を Windows コンソールプログラムに渡しま
す。PATH 等は上書きされます。ただし COMSPEC と DOSVAXJ3 は渡しません。
　両方設定する場合は set dosvaxj3=noinput,setenv となります。

　テスト版は下記にあります。
https://www.nanshiki.co.jp/test/dosboxj_test5.zip

　特に問題がなければ来週早々に正式版にする予定です。

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

ということでテスト版試してみました。
GREPなど入力系のプログラムが動くようになりました。ありがとうございます。
うれしいです。

gawk はリダイレクトでsyntax errorが出ましたが、リダイレクトしなければ動きました。

gawk "BEGIN{print mktime("""2004 09 28 20 57 00""")} >utime
gawk:                                                ^ syntax error

gawk "BEGIN{print mktime("""2004 09 28 20 57 00""")} 
1096372620

試した版は以下の日付のものです。
GAWK     EXE       446,464 05-12-23    0:24
GREP     EXE        96,256 09-02-13   17:19
YAGREP   EXE       233,472 09-03-31    2:28

grep.exe は、フォルダの再帰検索が安定しているので動いて嬉しいです。
GREP -Hnir "yagrep" *.*

yagrep.exe は、DCログの再帰検索で漏れが結構ありました。
Yagrep -r "yagrep" D:\log\fgal\DC\

この２つで比べてみてください。yagrep.exe の漏れは仕様かも。
テスト版の動作検証にご協力願います。m(__)m

konnoさん

>yagrep.exe は、DCログの再帰検索で漏れが結構ありました。

　お久です。うーん、すっかりＰＣいじりの世界からは遠のいております。
　例によって、今日も超疲労モード。

　さて、yagrep.exeですが、このようなテストには向かない道具かと思います。
　Bruce.さんが、onigsed, yagrep とも、正規表現エンジン鬼車を搭載して、
GNU sed & grep を日本語対応させて移植してくれたものなのですが、詳細は
省かせていただきますが、僕はまったく使っていない、ないし使わないことに
したツールです。限界などをみきわめられれば使えるところを使うことは可能
なのかもしれませんが、ちょっと、、、。
　対象ファイルに漏れがでる、ということですよね。僕はこれを経験して
いませんが、それ以外で、、、。うーん、考え方によってはヒットすべき
ものがヒットしていないから、あたかもそのファイルが検索されていないかの
ように見えることもあり得るのかな？

　環境を試すツールがあれですと、環境かツールか？　と沼にはまりそうな
気がします。

> 　お久です。うーん、すっかりＰＣいじりの世界からは遠のいております。
> 　例によって、今日も超疲労モード。

文太さん、お久です。お元気そうで安心しました。

> 　さて、yagrep.exeですが、このようなテストには向かない道具かと思います。
> 　Bruce.さんが、onigsed, yagrep とも、正規表現エンジン鬼車を搭載して、
> GNU sed & grep を日本語対応させて移植してくれたものなのですが、詳細は
> 省かせていただきますが、僕はまったく使っていない、ないし使わないことに
> したツールです。限界などをみきわめられれば使えるところを使うことは可能
> なのかもしれませんが、ちょっと、、、。

私が使っている grep.exe は多分 GNU GREP だと思うんですが、yagrep は GNU系だったんですね。
今回のテストはあくまで DOSVAXJ3テスト版で動作するようになった32ビットの入力系コマンドの検証なので。
grep.exe などは今までは使えなかったのです。

> 　対象ファイルに漏れがでる、ということですよね。僕はこれを経験して
> いませんが、それ以外で、、、。うーん、考え方によってはヒットすべき
> ものがヒットしていないから、あたかもそのファイルが検索されていないかの
> ように見えることもあり得るのかな？

この掲示板の過去ログで話題にしているかと思い検索したら、yagrep の癖など全部話題に出ていましたね。
#8206
> XXXX.HTM 219593: 需要予測
> だけど、この、「需要予測」 が、Yagrep だと検索引っかからないんですよ。
> 「予」が、$975C なので、「￥」$5C と認識しているのかも。
>       --ctype=SJIS              force matching in Shift-JIS mode
> このオプションを付けてもダメだったような。
#8210
> >だけど、この、「需要予測」 が、Yagrep だと検索引っかからないんですよ。
> 　再現しました。

また MS-DOS player でも yagrep.exe は動かなかったんですが、それも
#7774 GREP の動作の違い
> MS-DOS Player + yagrep
> C:\VZ\K07T5>C:\UT\YAGREP.EXE "AF"
> 'C:\UT\YAGREP.EXE"  "AF' は、内部コマンドまたは外部コマンド、
> 操作可能なプログラムまたはバッチ ファイルとして認識されていません。

この時と同じメッセージなので、やはり３２ビットの入力系コマンド対応は難しいということなのかも。

> 　環境を試すツールがあれですと、環境かツールか？　と沼にはまりそうな
> 気がします。

環境とは DOSエミュのことですよね、その違いがツールの動作に影響することは確かにありそうですね。

konnoさん

C:\BIN>dir | grep -i "grep"
1994/06/02  18:50            90,959 EGREP.EXE
2003/04/14  00:00            80,412 FGREP.EXE
1994/06/02  18:50            90,959 GREP.EXE
1999/11/11  00:00            82,944 OGREP.EXE
2009/03/31  02:28           233,472 yagrep.exe
1994/04/30  10:07            66,700 YGREP.EXE
1993/04/11  16:05            23,997 IZGREP.EXE

　３２ビットアプリと１６ビットアプリ。上の３つは３２ビット
だったのではないのかな？

https://www.vector.co.jp/soft/dos/util/se008484.html?_ga=2.40740194.1106177368.1731818139-1020062094.1731818139
　これじゃないかな？

　で、本文に戻ります。

>文太さん、お久です。お元気そうで安心しました。
　基本的には元気で健康です。ただ今年はなんだかんだと忙しくて。
　あと４か月半！

>今回のテストはあくまで DOSVAXJ3テスト版で動作するようになった32ビットの
>入力系コマンドの検証なので。
　VTDOS以外のＤＯＳエミュレータを使ってないので、よくは分からないのですが、
もしそれらがほんとの【ＤＯＳ】（16bit）エミュレータなら、特別なことを
してくれてないと、３２ビットアプリは動かないのが道理ですね。でも、rcp32.exe
とかも？

>この時と同じメッセージなので、やはり３２ビットの入力系コマンド対応は難しい
>ということなのかも。
　VTDOSが「ほにゃららホストに丸投げしてます」とかで、32/64bit 環境も意識して
作られている、ということなのでしょうか。

>> 　環境を試すツールがあれですと、環境かツールか？　と沼にはまりそうな
>> 気がします。"
>環境とは DOSエミュのことですよね、

　はい、そのつもりです。考えてみたら、ＸＰのＤＯＳ窓もＤＯＳエミュでしたね。
　rcp32.exeもclppst.exeも、ふつうに動いていた。

　yagrep.exeがテストに向かないにせよ、一部動いた、みたいな結果だったのです
よね？　謎ですが。

>DOSVAXJ3テスト版で動作するようになった32ビットの入力系コマンド
　（繰り返しですが）yagrep.exe以外の３２ビット grep でのテストがよろしい
かと。

konnoさん

C:\BIN>dir | grep -i "awk"
1993/09/25  05:51           188,444 JGAWK.EXE　　16bit
1998/08/22  22:01           142,759 MAWK32.EXE　　コレ
　　　　　　　　　　　　　　サイズからして日本語対応してなさそう

C:\BIN>dir | grep -i "sed"
1988/03/02  06:11            15,366 OLDSED.EXE　　16bit
1999/06/20  13:40            90,112 sed32.exe　　コレ
　　　　　　　　　　　　　　日本語対応してそう

　grepと同じことは、sed, awkでもできます。タイムスタンプとかファイル
サイズだけみて、上のリストはいい加減なことを言っている可能性が
あります。oldsed.exeとかは、serowさんの超古典の奴です。
　ベクタで探してみてください。

konnoさん

　まだ何か思いつくの？
　ディレクトリ再帰について。

Wild -D -R "head -7 $f >c:\wk\$x" c:\bin\asm_stdy\*.doc

　ドックを詳細に読まないと意味不明かもしれませんが、wild.doc
の冒頭に上のメモがありました。
　Siさん作の、wild.exe（16bit, 32bit 両方の版あり）の
コマンドサンプルです。

　「ファイル冒頭７行を見せろ」という命令のようです。
　-D は、Dummy で、ワイルドカードの展開の様子だけデモせよ、という
意味だったと思う。
　-R が、Recursive（再帰）の意味だったと思う。
　「c:\bin\asm_stdy\」以下の *.doc が対象ファイル。

　grep, sed, awk （その他のフィルター系ツール）は、多くの場合、
ディレクトリ再帰のオプションがありません。

　wildをかませると再帰できるよ、ということです。
　実用性を付け加えて、問題を複雑にしている、という気はしています。

> 1993/09/25  05:51           188,444 JGAWK.EXE　　16bit
> 1998/08/22  22:01           142,759 MAWK32.EXE　　コレ
> 　　　　　　　　　　　　　　サイズからして日本語対応してなさそう

うちのawkは

JGAWK    EXE       188,444 93-09-25    5:51
MAWK32   EXE       193,536 98-08-22   23:02

こうなっていますが、いずれも日本語対応しています。
って、mawk32は、なんかすげぇ微妙なバージョンの差異があるかも。

> 　grepと同じことは、sed, awkでもできます。

御意。
単に専用ツールか多機能ツールかの違いだけ。
鶏を割くのに牛刀を使って何が悪い。

としきさん

　（以下すべて、VTDOS環境です）

　多謝。ベクタにありました。ソースもありました（???.tar.gzの展開の
仕方わすれたのだけど）。

C:\WK>dir

1997/11/01  11:02            44,369 mawk.doc
1998/08/22  22:02           193,536 mawk32.exe
1996/09/18  10:23             2,524 README
1998/08/22  21:59             6,390 README.SJ

----- t.txt -----
　まだ何か思いつくの？
　ディレクトリ再帰について。
-----------------

----- t.awk -----
/ディレクトリ/{
print}
-----------------

C:\WK>mawk32.exe -f t.awk t.txt
　ディレクトリ再帰について。

>って、mawk32は、なんかすげぇ微妙なバージョンの差異があるかも。

　ファイルサイズからして、僕のmawk32.exeは、日本語対応のない
英語圏から落とした奴だったんじゃないかな。
　タイムスタンプが、え、え、え？？？　という感じだったけど。
　無事、日本語対応 mawk32 がゲットできました。多謝。
　16bit の jgawk.exeしか、ほとんど使ったことないのだけど。


蛇足：

C:\WK>mawk32 -W version（新版）
mawk 1.3.3 Nov 1996, Copyright (C) Michael D. Brennan
  Adaptation for MBCS (P. yedoensis R27) by KIMURA Koichi


C:\WK>cd c:\bin

C:\BIN>mawk32 -W version（旧版）
　VTDOSがはじいて、「アプリケーションエラー」

　おめでとう！　きっと使わないけど、使える mawk32.exe だ！

　自己レスです。

>　多謝。ベクタにありました。ソースもありました（???.tar.gzの展開の
>仕方わすれたのだけど）。

　LHMelting を使うのは久しぶりでしたが、mawk-1.3.3-mbcs.tar.gz を無事、
解凍できました。mawk のソース、あひゃひゃひゃひゃ状態。
　これを勉強する日は、ないんだろうなぁ。
　Win11 (64bit) でも、LHMelting 動きますね。

> C:\BIN>dir | grep -i "grep"

おお、パイプでこんなことが出来るんですね。勉強になりました。
てか、このパイプは VTDOS でしか使えないようですね。
DIR *grep*   		だと全ファイル表示してしまいますね。
tosfind.exe /n*grep*   	これは目的のファイルだけ表示してくれますが、下位フォルダまで表示してしまいますね。
mls.com /l *grep*	これも目的のファイルだけ表示してくれますが、DOSVAXJ3では何故か全ファイル表示してしまいます。
LS系は目的ファイルだけ表示するものと全ファイル表示するものが混在しているようです。
余談になりました。(^^;

> https://www.vector.co.jp/soft/dos/util/se008484.html?_ga=2.40740194.1106177368.1731818139-1020062094.1731818139
> 　これじゃないかな？

日付もサイズも全然違うので別物だと思います。いつどこで落としたのか思い出せないです。(^^;

> 　基本的には元気で健康です。ただ今年はなんだかんだと忙しくて。
> 　あと４か月半！

無理せず頑張ってください。

> もしそれらがほんとの【ＤＯＳ】（16bit）エミュレータなら、特別なことを
> してくれてないと、３２ビットアプリは動かないのが道理ですね。でも、rcp32.exe
> とかも？

かなり特別な処理をしてくれているようです。CLPPST.EXE がきっかけで対応してくれたのでありがたいです。
コピー系は ZCPY32.EXE が動くので rcp32.exe も大丈夫だと思います。

> 　VTDOSが「ほにゃららホストに丸投げしてます」とかで、32/64bit 環境も意識して
> 作られている、ということなのでしょうか。

結果的にパイプにも対応できているのは凄いことなんだなと改めて思いました。

> 　yagrep.exeがテストに向かないにせよ、一部動いた、みたいな結果だったのです
> よね？　謎ですが。

他のDOSエミュでも同じ結果のようなので、やはり yagrep.exe 自体の問題と思われます。

> 　（繰り返しですが）yagrep.exe以外の３２ビット grep でのテストがよろしい
> かと。

常用の grep が動いているのでおおむね問題なさそうだと思います。

DOSVAXJ3 (2024/11/18)テスト版のメールをいただきました。
内容は

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

　さらに修正して C# 等で作られた .NET コンソールプログラムでも入力
可能となっています。環境変数の設定は noinput から novc に変更しま
した。
https://www.nanshiki.co.jp/test/dosboxj_test6.zip

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

ということでさらに多くのコマンドに対応されたようです。
ありがとうございます。

また、GAWKの件でも
>> gawk "BEGIN{print mktime("""2004 09 28 20 57 00""")} >utime
>> gawk:                                                ^ syntax error
>　> の前に " が必要です。

とアドバイスをいただきました。これはVZマクロで
=utime
*m
89 ^\ "" #E "gawk $"BEGIN{print mktime($"$"$"2004 09 28 20 57 00$"$"$")} >utime" #m
*
こうなっていて、VTDOSではこれで動いていました。

89 ^\ "" #E "gawk $"BEGIN{print mktime($"$"$"2004 09 28 20 57 00$"$"$")}$" >utime" #m
こう修正したら、VTDOSでも DOSVAXJ3 でもキチンと動きました。ありがとうございます。

入力系＝対話型とすると、CMD.EXE とかでしょうか。
DOSVAXJ3 で dir *grep*  とすると、カレントの全ファイルが表示されます。
CMD
dir *grep*
とすると、grep を含むファイルだけ表示されます。
exit で戻ると VZのコンソールに結果が入っていますね。これはありがたいです。
これは MS-DOS Playerや VTDOSでも出来ましたが、VZコンソールに結果は入りませんでした。

> 　ディレクトリ再帰について。
> Wild -D -R "head -7 $f >c:\wk\$x" c:\bin\asm_stdy\*.doc

これは使ったことが無いので使い方を理解するのに時間が掛かりました。
head というコマンドが必要だったんですね。VECTORで落としましたが、type でも動きました。
が、DOSVAXJ3 では何故か動かなかったです。
MS-DOS のバージョンが違います.　とヒット数ぶん表示して終わります。
これは16ビット版と32ビット版どちらも同じエラー表示です。
内蔵のコマンドラインの解釈によるのかなとか思いました。

> 　実用性を付け加えて、問題を複雑にしている、という気はしています。
まさに動作が複雑すぎて問題の原因がわかりにくくなってしまってますね。(^^;

入力系といえば、more.exe がありましたね。Win10のもので試しました。
DOSVAXJ3最新版で試しましたが、そのままでは表示無しで終了しました。
set dosvaxj3=novc
の後で試しても同じでした。

set dosvaxj3=noinput
の後で試すと、表示が途中で止まらないで終了しました。
使ってないので困ってはいないですが、VC系のコマンドではないのかなぁ。

> > C:\BIN>dir | grep -i "grep"
> おお、パイプでこんなことが出来るんですね。勉強になりました。
> てか、このパイプは VTDOS でしか使えないようですね。

こういうパイプは BAT で同等の処理が出来るかもと思いやってみました。

dirp.bat
rem dir | grep -i "grep"
dir > c:\tmp\pipe.tmp
grep -i %1 c:\tmp\pipe.tmp

dirp grep
で、同等の結果が得られました。
パイプの記述より短くすむのと、どのDOSエミュでも動くのが利点です。
名前は dirg の方がいいかしら？
この手法は応用が利きそうですね。(^_^)

konnoさん

　うーむ、どう回答したものやら？

　おそらく一番大事なのは、
>が、DOSVAXJ3 では何故か動かなかったです。
　でしょうか。

　これは、DOSVAXJ3の作者様に報告していただくしかないでしょう。
　僕は、VTDOS以外、ＤＯＳエミュレータを知らないんです。
　VTDOSをよく知っているわけでは、まったくありませんが。

　で、元にもどっていちおう整理を試みると、なぜwild.exeが登場したかと
いうと、yagrepで「ディレクトリ再帰」が変、とkonnoさんが仰っていたから
です。
　以下の表をみてください。16bit の grep で「ディレクトリ再帰」が
オプションで可能なのは、wgrep, ygrep, jgslimだけだそうです。

			cgrep	Ggrep	akgrep	wgrep	ygrep	izgrep	dgrep	jgslim	zf
directory下再帰					-u	-r			-a

　で、grep, sed, awk にも、ふつうその機能はないけれど（多くのフィルタ系
ツールも）、wild.exeをかませると、それが可能ですよ、と実用的なことを
話に僕がまぎれこませた、ということです。

　wild.exeは、ワイルドカード展開を助けてくれる、いわばメタツールで、
ですから

Wild -D -R "head -7 $f >c:\wk\$x" c:\bin\asm_stdy\*.doc

　の"head -7 $f >c:\wk\$x"の部分は、展開されるべきワイルドカードを
含んだコマンドなのです。
　コマンドの中身が、"head -7"（ファイルの冒頭７行を表示。８行目以降は
見せるな）で、$f がワイルドカード的に展開されるべき対象ファイル名です。
　（typeだと、冒頭７行だけ、というわけにはいかないでしょう？）

　$f, $x を Siさんは「マクロ」とドックで呼んでいたと思いますが、
wildの使い方は、wild.doc を読んでもらって試してもらうのがはやいです
（必要ないでしょうけれど。必要がなければ、けっこう難解です）。

　「ディレクトリ再帰」がないツールにその機能を付加する。これがwild.exe
のお仕事であり、ここで登場してもらった理由です。


　さらに元にもどって。
　DOSVAXJ3 のテスト。これがkonnoさんの主目的ですよね？
　だとしたら、まず、VTDOSと結果を比較するのがよいのではないでしょうか？
　意図的なのかもしれないけど、僭越ながら申し上げると、割と迷走モード
っぽいような印象を受けました。

　パイプにせよ、ワイルドカードの展開にせよ。
　もっとも、ワイルドカードの展開は、外部ツールでは、そいつがすることに
なっていたと思うけど。
　dir みたいな内部コマンドだと、さて誰が展開するのでしょう？　ですが。
　command.com? あるいは、ＤＯＳエミュレータ本体？

　上のくだりでは、僕自身が迷走してますが、ま、今の僕の課題ではないので、
ご容赦ください。


　大量に本を捨てている毎日ですが（仕事おさめ）、ＤＯＳ関係本はとって
あります！　fortranとpascal関係本は、うう、どうしよう？　ですが。
　とっとく！

追伸：「引用なし」ボタン。最高です。僕はこれを愛してます。

> >が、DOSVAXJ3 では何故か動かなかったです。
> 　これは、DOSVAXJ3の作者様に報告していただくしかないでしょう。

作者様にメールしたんですが、その後に私の設定ミスが原因だったことが判明しました。(>_<)

> 余談ですが、Si氏の wild.exe というワイルドカードを付与するコマンドが動きません。
> MS-DOS のバージョンが違います.　とヒット数ぶん表示して終わります。
> これは16ビット版と32ビット版両方ありますが、どちらも同じエラー表示です。

この件ですが、私の dosboxj.conf の設定が原因でした。
非常駐VZのコマンドラインで何を入れてもエラーになるので気が付きました。
dosboxj.exe を10/11版まで戻しても変わらなかったので、dosboxj.confを見てみました。
[autoexec] セクションで

set COMSPEC=c:\ut\95\COMMAND.COM

これが入っていて、Win98ME の command.com が呼ばれていたようです。
いつ入れたのか覚えていなくて、気がつかなかったのです。
ここをコメントにしたら正常に動作しました。
お騒がせして申し訳ないです。すみませんでした。
作者様に謝罪メールしました。m(__)m


> 　で、元にもどっていちおう整理を試みると、なぜwild.exeが登場したかと
> いうと、yagrepで「ディレクトリ再帰」が変、とkonnoさんが仰っていたから
> です。
再帰というわけではなく、検索漏れが多かったのです。これは過去ログでも言っていました。

> 　以下の表をみてください。16bit の grep で「ディレクトリ再帰」が
> オプションで可能なのは、wgrep, ygrep, jgslimだけだそうです。
> 　で、grep, sed, awk にも、ふつうその機能はないけれど（多くのフィルタ系
> ツールも）、wild.exeをかませると、それが可能ですよ、と実用的なことを
> 話に僕がまぎれこませた、ということです。

grep に再帰機能が無いのが普通なのですね。知りませんでした。
私が常用している wgrep と grep(32) にはどちらにも再帰機能があったもので。
そういう意味では wild.exe のご紹介はありがたい情報でした。
wild.exe って、ワイルドカードの機能を付加してくれるだけだと思っていたもので。

> 　DOSVAXJ3 のテスト。これがkonnoさんの主目的ですよね？
> 　だとしたら、まず、VTDOSと結果を比較するのがよいのではないでしょうか？

うーん、私の書き方がよくないのかなぁ。3種のDOSエミュで比べた結果を書いているつもりなんですが。
主語が無いからかなぁ。そもそも比較無しでは変だとかわからないし。

> 　dir みたいな内部コマンドだと、さて誰が展開するのでしょう？　ですが。
> 　command.com? あるいは、ＤＯＳエミュレータ本体？
このあたりの疑問が今回の迷走に繋がっているかもですね。(^^;

> 　大量に本を捨てている毎日ですが（仕事おさめ）、ＤＯＳ関係本はとって
> あります！　fortranとpascal関係本は、うう、どうしよう？　ですが。
> 　とっとく！
やはり文系の人は本が大量にあるのですね。うちはそれほどないですが、腐海で腐ってます。(^^;

> 追伸：「引用なし」ボタン。最高です。僕はこれを愛してます。
わずかの手間の差と思いますが、そう言っていただくと嬉しいです。

konnoさん

>作者様にメールしたんですが、その後に私の設定ミスが原因
　原因が判明してよかったですよね。
　やっぱり作者様に報告したのに、自分のミスだったというのは
格好が悪いかもしれませんが、良好な関係ができていたら、「ごめん、
こっちのミス」もありでしょう。というか、僕はそればっかの人生みたい。

>[autoexec] セクションで
>set COMSPEC=c:\ut\95\COMMAND.COM

　そ、そんなディレクトリがあるんですか？！　さすが。
　Win95系のツールとかも、ここに格納されていると。

>再帰というわけではなく、検索漏れが多かったのです。

#11645
>grep.exe は、フォルダの再帰検索が安定しているので動いて嬉しいです。
>GREP -Hnir "yagrep" *.*

>yagrep.exe は、DCログの再帰検索で漏れが結構ありました。
>Yagrep -r "yagrep" D:\log\fgal\DC\

　どっちにも、-r (recursive) がはいってますけど、、、。
　「再帰検索が安定」あるいは「漏れ」では、再帰に問題があると書かれて
いるように思われるのですが。

　細かくて、すみませぬ。

　ただ、現実的にいって、yagrep.exeには、いろんな問題があると思います。
　僕はＨＤから消してしまってもいいくらいの信頼感です。
　これだけ指摘したかったのです。
　もっとも、grep に Perl5 の正規表現は、僕ですら大して欲していなかった
と思う。

　たぶんkonnoさんがお使いのgrep(32)もＧＮＵのものでしょうから、「ＧＮＵ
による拡張」ですが、ちゃんと Perl5 の正規表現が使えます。

 -P
 --perl-regexp
 matching Perl regular expressions
Interpret the pattern as a Perl regular expression.

　ま、yagrepとonigsedについては、僕のような非力＆根性なし
テスターしかいなかった、というのが不幸の原因でした。konnoさんが、Bruce.
さんと一緒だったら、きっともっと完成度の高いものになっていたでしょう。

2009/03/31  02:28           233,472 yagrep.exe

　１５年まえ。僕がテスターをしたのは、これより２年前くらいだったのかな？

> 　やっぱり作者様に報告したのに、自分のミスだったというのは
> 格好が悪いかもしれませんが、良好な関係ができていたら、「ごめん、
> こっちのミス」もありでしょう。というか、僕はそればっかの人生みたい。

私も最近メールのやり取りが増えたんですが、自爆タコミスの謝罪は多いです。(>_<)

> >set COMSPEC=c:\ut\95\COMMAND.COM
> 　そ、そんなディレクトリがあるんですか？！　さすが。
> 　Win95系のツールとかも、ここに格納されていると。

いや、command.com だけです。って今見たら Win95 のだった。いいかげんですみません。

> 　「再帰検索が安定」あるいは「漏れ」では、再帰に問題があると書かれて
> いるように思われるのですが。

再帰の時だけ漏れが増えるとかは普通考えられないと思うし、それだとワイルドもどうなのと思ってしまいます。
でも絶対ないとは言えないか・・・
#11647で
> #8206
> > XXXX.HTM 219593: 需要予測
> > だけど、この、「需要予測」 が、Yagrep だと検索引っかからないんですよ。
> > 「予」が、$975C なので、「￥」$5C と認識しているのかも。
ここでは再帰とは言っていないし。共通項は「検索漏れ」です。
思うにユニコード用のツールはSJISにも完全対応させるのは難しいのだろうと思います。
万能で完全なツールなんて無いので、それぞれの環境や使い方に合ったものを選択するのが吉かと。
私は正規表現はほとんど使わないし、それよりオア検索したいので CODEX.DEF を愛用しているんですね。

> 　たぶんkonnoさんがお使いのgrep(32)もＧＮＵのものでしょうから、「ＧＮＵ
> による拡張」ですが、ちゃんと Perl5 の正規表現が使えます。

正規表現は使えれば便利ですが、私はほとんど使ってないので、通常検索で漏れの少ないものを選んだのです。

> 　ま、yagrepとonigsedについては、僕のような非力＆根性なし
> テスターしかいなかった、というのが不幸の原因でした。konnoさんが、Bruce.
> さんと一緒だったら、きっともっと完成度の高いものになっていたでしょう。

私は正規表現もフィルター系ツールもあまり使ってないのでこの方面は文太さんの方が適任ですよね。
私が苦手なだけか。としきさんやめざらさんにも教えてもらうことが多いですからね。(^^;

konnoさん

C:\>yagrep --help
（中略）
multi-byte extention:
      --ctype=ASCII             force matching in ASCII mode
      --ctype=EUC               force matching in EUC-JP mode
      --ctype=SJIS              force matching in Shift-JIS mode
      --ctype=UTF8              force matching in UTF-8 mode

　このオプションで明示的に SJIS mode でも、うーん、な結果だったと
思います。
　とにかく、僕的なポイントは、yagrepで何かをテストすると沼です、
これだけです。

>正規表現は使えれば便利ですが、私はほとんど使ってないので、通常検索で漏れの
>少ないものを選んだのです。

　こういう時は、grep.exe を 別ディレクトリにコピーの上、fgrep.exeに
リネームしましょう。正規表現が殺されます。すると、正規表現のメタ文字を
エスケープする手間が完全に省けます。意外にメタ文字に転んだりしてます。

> 　このオプションで明示的に SJIS mode でも、うーん、な結果だったと
> 思います。

過去ログでこのような話は見たような気がします。

> 　とにかく、僕的なポイントは、yagrepで何かをテストすると沼です、
> これだけです。

Parl5の正規表現と、GNUGREPの検索エンジンの相性か何かが悪いのかもですね。SJIS関連かも。

> 　こういう時は、grep.exe を 別ディレクトリにコピーの上、fgrep.exeに
> リネームしましょう。正規表現が殺されます。すると、正規表現のメタ文字を
> エスケープする手間が完全に省けます。意外にメタ文字に転んだりしてます。

えっ、GNU系GREPにはこんな機能があるのですか。早速 OMAKE.DEFに仕込んで DCフォルダで試してみました。
まずは今まで通りで
D:\LOG\FGAL\DC>GREP -nir "yagrep.exe" *.*
No files matching: *.*

FGREPに名前を変更すると
D:\LOG\FGAL\DC>FGREP -nir "yagrep.exe" *.*
13/bak/yagrep.log:107:YAGREP.exe -i -H -n "^v\.c\.\/salon" c:\lx\log\vzlog\mixvz\mixvz91\vz901003.log >mixxx
13/bak/yagrep.log:177:> YAGREP.exe -i -H -n "^v\.c\.\/salon" c:\lx\log\vzlog\mixvz\mixvz91\vz901003.log >mixxx

更に深い階層から見つけ出してくれました。＼(^^)／ ﾔｯﾀ-
これは良いですね、これからはこれで行きます。GREP も残しておいて比較してみます。
おいしい使い方を教えてくれてありがとうございます。

konnoさん

　konnoさんが試した結果については、うまく理解できませんでした。
　頭が働いてない。

grep では、"yagrep.exe"は、「.」が何でもあり（メタキャラ）、となり
fgrepでは、"yagrep.exe"は、「.」がピリオドと解釈されるはずです。

>GREP も残しておいて比較してみます。
　残しておきましょう。

　ＧＮＵ特有だったか思い出せませんが、grepは、

grep	のままだど、basic regex (sed 相当)
egrep	とリネームすると、extended regex (vwx 相当。awk 相当)
fgrep	とリネームすると、no regex となります。

　３つ、grep.exe, egrep.exe, fgrep.exe をＨＤＤに入れておいて
損はないと思います。
　とはいえ、grep １つでも、オプションで、egrep, fgrep 相当に
振る舞えたはずだとは思いますが。

　fgrep.exe を使いたいときは、けっこう特殊だと思う。
　egrep.exe を使いたいときは、「拡張正規表現使うからな」（メタ
キャラ、＋とか）と、思うと思う。

　３つ、c:\bin ディレクトリに入れておいて、損はないと思います。