一括表示

− 野ざらし言 −

[5278] 一括リネームのテスト

めざら 2023/01/20(Fri) 15:12
http://mezala.la.coocan.jp/
フォトファイルに連番を付与するマクロのテストと備忘録です。

もともとの要求というのが,メモ代わりに撮影した写真のファイルに連番を付ける
というものです。そもそも元のファイル名が英字4文字と数字4文字なので,さらに
連番を付けるとロングファイルネームになってしまうわけで,通常の
ファンクションコールでリネームするのは危険かと思い込んでいたわけです。
それならデジカメの機種等を示す英字4文字は消してしまっておいて
連番を付ければいいかも…ということで試作し,
結果がロングになってしまう場合はどうなるのかいな…と思って実行したら,
ロングファイルネームでいけちゃったという……。

DOSのファンクションコールも長いファイル名対応なんすね……ってことで良いのか
悪いのかよくわからないんだけれど,まぁ結果オーライってことで。

ファイラーで選択したファイルを次のようにリネームします。
DIMG0764.JPG → DIMG0764_01.JPG
DIMG0765.JPG → DIMG0765_02.JPG
DIMG0766.JPG → DIMG0764_03.JPG
 … 以下,略。 …

= RnBnname.def   v0.10 = by H.ear
連番を振ったファイル名にリネーム(複数選択対応版)
ロングファイルネームでも可能なので,結果がショートに収まらなくてよい.
* mad for vz!
1 ^\ "" (s!=3)?.			;ファイラーのみ
	e=i-,				;<i>:マークファイル処理数
	(fl..5)??{			;マークしていなければ
		FM[-, ' ' FM],		;カーソル位置のファイルを選択
	}
	&Fi (r)??.			;選択ファイルの先頭へ
 :a	&Fg(pq..137,1)			;ファイル名を取得
	fv^=4, #V			;再表示
	&Sy(pq..137)			;パス名取得・解析
	(si>cx)?{ &Sc(pu,cx) }?pu.0-,	;拡張子抽出
	&Sc(pa,bx) pa.(cx-bx)-,		;ファイル名複写と拡張子切除
	&Sp(pq..134,"%s_%02d%s",pa,i+1,pu)
	dx=pq..137,			;old path / pathbuf
	di=pq..134,			;new path / tmpbuf
	ax=$5600, &i($21)		;Rename
	(r)?e++, ?i++,
	&Fn (r)?>a
	#U
	&m("success: %d file(s). / failure: %d file(s).",i,e)
*

[5279] Re: 一括リネームのテスト

文太 2023/01/21(Sat) 15:41
[5278]へのコメント
 僕も同じような課題にのぞんだことがあります。
 もうちょっと話が複雑だったので、>ren コマンドを連発するバッチファイルでしのぎました。

 で、真っ先に

>それならデジカメの機種等を示す英字4文字は消してしまっておいて
>連番を付ければいいかも…ということで試作し,

 が気になり、renのワイルドカードを使って、8.3のファイル名を4.3にしてから、、、と考えたら、どうもワイルドカードを使ったrenコマンドでは、文字数を減らせないみたい、という結論に。

>ren DIMG0764.JPG 0764.JPG
 という1個ずつの処理はもちろんできる。
 ところが、

>ren DIMG????.JPG ????.JPG
 はダメ。みたい。ワイルドカードのヒット箇所が変みたいだ。

 本題からずれて申し訳ないのですが、どうもそんな結果になってます。
 何かこのワイルドカード変だと思う。不思議な仕様、という意味ですが。
 内部的には、findfirst/nextですよねぇ? ???
 僕がどっか間違ってるのかなぁ?

[5281] Re^2: 一括リネームのテスト

めざら 2023/01/22(Sun) 16:53
[5279]へのコメント http://mezala.la.coocan.jp/
わ…ワイルドカードですって?! そういうの,dir か copy でしか使ったことないですよ…… ren で通用するとは夢にも思いませんでした。でも,通らなかったわけですよね。DOS のワイルドカードで何かできるなんて思えないけれど,再履修の必要があるでしょうか。(そんな時間はない)

バッチで ren するって,なかなか根性が要りますよね。リスト取ってゴミを除いて整形して対応表を作ってブロックペースト……気が遠くなる。それでも正規表現が使えそうだからまだしも,ですが。

実際に,何かできる「はず」なのかなぁ……


現実的には,ファイル名の共通する一部を削除してリネームするなんてのは,Emacs 風ウィンドウズエディタの xyzzy ファイラーでやっています。これは正規表現が使えるので毎日使っています。その流れで,大抵のファイル操作は xyzzy を使っていますね。VZ …と言うか実際には VZ のファイラーで使っている RCP32 なんですけど…の出番はバックアップリネームコピーとか小文字化/大文字化コピーくらいかな。現時点での用途はそういう感じです。

[5282] Re^3: 一括リネームのテスト

としき 2023/01/22(Sun) 17:52
[5281]へのコメント http://toshiki.la.coocan.jp/
> バッチで ren するって,なかなか根性が要りますよね。

この手の案件だと、私はバッチ一択ですね。
dirコマンドの結果をキーボードマクロで処理。
cols.defを使うこともある。
バッチだと何がいいって、変換前と変換後が一覧で見れるところ。
何か気がつかないミスをやらかして変換結果がおかしくても、もう一度バッチを見れば、自分が一体何をやらかしたのかがすぐわかるというのは、私にとってはわりと大きなメリット。

[5284] Re^4: 一括リネームのテスト

めざら 2023/01/22(Sun) 18:20
[5282]へのコメント http://mezala.la.coocan.jp/
バッチ一択ですか……。さすが根性の人だった。

> バッチだと何がいいって、変換前と変換後が一覧で見れるところ。

まぁ,そうですね。でも,変換はしちゃいますよね。

xyzzy ファイラのどこがいいって,変換結果を事前表示してくれて,これで実行するかどうか確認してくれるところです。そもそも変換前の正規表現にマッチしないファイルは対象にならないので,おかしなことも起こらない。

日々使っていると履歴も使えるので,定型ならその都度考える必要もなし。

radiko を録音したファイルとか,制作側の都合でやたら長いファイル名なんかになっていたりするわけですが,一括で処理できるのでとても便利。

また,動画なんかをエンコードするために ffmpeg にバッチでファイル名を渡したいとき,全角スペースなんて使ってあると(たぶんWindowsのバグで)バッチの構文が割れちゃったりするのを予防するため半角スペースに直すなんてのも,
【\(.+\) \(.+\)】 → 【\1 \2】の履歴使い。楽ちん。

わたしの一択です。

[5285] Re^3: 一括リネームのテスト

文太 2023/01/23(Mon) 01:07
[5281]へのコメント
 すいませんが、ここだけです。

>バッチで ren するって,なかなか根性が要りますよね。
>リスト取ってゴミを除いて整形して対応表を作ってブロックペースト……気が遠くなる。
>それでも正規表現が使えそうだからまだしも,ですが。

c:\vzlog\pk14>bltwr

ren PK14_924.LOG	PK14_924.LOG
ren PK14_92C.LOG	PK14_92C.LOG
ren PK14_932.LOG	PK14_932.LOG
ren PK14_939.LOG	PK14_939.LOG
ren PK14_944.LOG	PK14_944.LOG
ren PK14_94C.LOG	PK14_94C.LOG
ren PK14_953.LOG	PK14_953.LOG
ren PK14_959.LOG	PK14_959.LOG
ren PK14_961.LOG	PK14_961.LOG
ren PK14_965.LOG	PK14_965.LOG

 この形ならcols.defですね。

 かえるとかでなくて、めざらさん、アセンブラをやろう! 一緒にゆっくり生きて
くださいよ。最低あと10年はあるでしょう?

 xyzzy、おお、すげえ。とりあず導入します! その機能のためだけでも。

[5287] Re^4: 一括リネームのテスト

めざら 2023/01/23(Mon) 11:57
[5285]へのコメント http://mezala.la.coocan.jp/
>  この形ならcols.defですね。

その形式にするのに,取得したリストを加工しなければならないから,やっぱり手間かな。対応表を作る(dirのリストからファイル名以外を除去し,ファイル名を行内で二重化)→ 桁位置指定のゼロパディング連番付与マクロで番号振り → コマンド文字列付与後バッチファイルとして保存 → 実行

すごくたくさんのファイルがある時は,かなり時間の節約になるのは確かなので,ケースバイケースですかね。

>  かえるとかでなくて、めざらさん、アセンブラをやろう!
> 一緒にゆっくり生きてくださいよ。最低あと10年はあるでしょう?

いつも共に居るとは思ってますけど,アセンブラは高橋さんのJOANNE.com&def に渡すくらいのサイズが限界かなと思います。

だって,だって,とてつもなくめんどくさいんだもん!

[5290] renコマンドとワイルドカード

文太 2023/01/23(Mon) 22:37
[5279]へのコメント
 頭から残す、つまりベースファイル名の末尾からカットすることは可能なようです。

C:\WK\01>blt

0764DIMG.JPG
0765DIMG.JPG
0766DIMG.JPG

C:\WK\01>ren ????DIMG.JPG ????.JPG

C:\WK\01>blt

0764.JPG
0765.JPG
0766.JPG

 bltはゴミなしdirです。調子に乗っているのではなく、こっちのほうが
明らかに見やすいから。

 ただねぇ、こんな風に処理して短くして、有意味な情報が残ることがあるだろうか?
 やっぱ1個ずつのバッチ処理だなぁ。
 LFNをSFNに無理やりしてしまう。これは、僕はよくやります。邪魔だから。

>ren *.htm *.txt

 みたいなのは、ren + wildcard の定番です。

追記:少し意味ある? 使える? はやり削れるのは後ろから。行頭から再現されて
しまう。

C:\WK\01>blt

0764DIMG.JPG
0765DIMG.JPG
0766DIMG.JPG

C:\WK\01>ren ????????.JPG ????.JPG	;ここで、\1, \2 みたいなのが指定
					;できず、常に頭からになって
C:\WK\01>blt				;しまう。

0764.JPG
0765.JPG
0766.JPG

 使えません、と思う。こんなレアな場合があるか!

[5286] 一括リネームのテストと限界,結論

めざら 2023/01/23(Mon) 11:37
[5278]へのコメント http://mezala.la.coocan.jp/
> 結果がロングになってしまう場合はどうなるのかいな…と思って実行したら,

ちょっとだけ複数のケースを確認したところ,条件つきと判明。
DOSのファンクションコールは,中途半端に長いファイル名対応であること。

入力ファイル名 → 出力ファイル名 → 変換結果・成否
ショート → ロング → 元ファイル名+付加文字列 成功
ロング → ロング → ショート形式ファイル名+付加文字列 失敗

結局,元がショートに収まっていないと,渡される元ファイル名がショート形式であるため,例えば【ABCD00~1.IMG】が【ABCD00~1_01.IMG】になるだけ。

なので,最初にショートに納まっているファイル名に当マクロで連番を付け,その後 xyzzy ファイラで追加の定型識別子を付与するというという手順。

手作業だと96%(体感*1)の時間を占める連番付与さえマクロで自動化できれば,圧倒的な時間の節約になるから,こんなところであろうか。

*1 メモファイルのグループは最大30程度のため,100の工程が3〜4になる計算。

[5288] Re: 一括リネームのテストと限界,結論

文太 2023/01/23(Mon) 22:02
[5286]へのコメント
INT 21 - DOS 2+ - "RENAME" - RENAME FILE	★
	AH = 56h
	DS:DX -> ASCIZ filename of existing file (no wildcards, but see below)
	ES:DI -> ASCIZ new filename (no wildcards)

 上ではなくて、下では?

INT 21 - Windows95 - LONG FILENAME - RENAME FILE
	AX = 7156h
	DS:DX -> ASCIZ old file or directory name (long names allowed)
	ES:DI -> ASCIZ new name (long names allowed)


 元々少し勘違いしていましたが、rename func ではないですが、Win32では
LFN取得もできるはずです。

E:\0PROG\BOOKS\IBM>bll
IBM_Macro_Assembler_100.pdf
IBM_PC_BASIC_110_1982-05-BW.pdf
IBM_PC_DOS_200_1983-01.pdf

 しつこい。

[5294] Re^2: 一括リネームのテストと限界,結論

めざら 2023/01/24(Tue) 20:06
[5288]へのコメント http://mezala.la.coocan.jp/
> INT 21 - Windows95 - LONG FILENAME - RENAME FILE
> AX = 7156h
> DS:DX -> ASCIZ old file or directory name (long names allowed)
> ES:DI -> ASCIZ new name (long names allowed)

拡張ファンクションコールは,こっちでしたね。ありがとうございます。

ただ,VZ の &Fg() 関数を使うと,取得できるファイル名がショートなので,$7156 を使っても結果は同じになってしまうことを確認しました。

いずれにしても,出力が結果的にロングになっても通るので,目的はほぼ達成できました。とてつもなく時間の節約ができましたので結果オーライです!

[5289] Re: 一括リネームのテストと限界,結論

konno 2023/01/23(Mon) 22:08
[5286]へのコメント
> 結局,元がショートに収まっていないと,渡される元ファイル名がショート形式であるため,例えば【ABCD00~1.IMG】が【ABCD00~1_01.IMG】になるだけ。

これ、実行環境は VTDOS ですよね。
REN コマンドは、command.com の内部コマンドなので、ロング名には対応していません。
VTDOS がうまい具合にロングに変換してくれているのでしょうね。
試してみたら、最近の DOSエミュ3種は、同じようにロング変換できました。
おそらく Win95以降のDOS窓でも同じ動作だと思います。

VZマクロでは、ax=$5600 を使っているので、元がショート名しか対応しないのは当然ですね。
ロング対応するなら、ax=$7156 だったかな。未確認。(^^;

> なので,最初にショートに納まっているファイル名に当マクロで連番を付け,その後 xyzzy ファイラで追加の定型識別子を付与するというという手順。

xyzzy は非常に高機能で使いこなせれば便利そうですね。
私は全く触れていませんが。(^^;

[5291] Re^2: 一括リネームのテストと限界,結論

文太 2023/01/24(Tue) 00:06
[5289]へのコメント
>これ、実行環境は VTDOS ですよね。
 僕もこれは確認したかった。

 でも、

>REN コマンドは、command.com の内部コマンドなので、ロング名には対応していません。

 REN コマンドの話は、僕がしています。
 めざらさんのマクロはRENAME の func callしています。でも、古い、LFN対応でない奴。たぶん。

 心も体もぐちゃぐちゃな文太が、話をぐちゃぐちゃにしてる、、、。

[5296] Re^3: 一括リネームのテストと限界,結論

konno 2023/01/24(Tue) 23:48
[5291]へのコメント
> >REN コマンドは、command.com の内部コマンドなので、ロング名には対応していません。
>
>  REN コマンドの話は、僕がしています。
>  めざらさんのマクロはRENAME の func callしています。でも、古い、LFN対応でない奴。たぶん。

#5288 で先に同じような話をされていたんですね、気が付きませんでした。
#5289 の私の書き込みの6分前だったとは。(^^;

> INT 21 - Windows95 - LONG FILENAME - RENAME FILE
> AX = 7156h

やっぱり合っていたんですね、正確な情報ありがとうございます。

[5292] LFN @ vtdos

文太 2023/01/24(Tue) 07:28
[5289]へのコメント
>dir

0123456789.txt			;SFNでは、012345~1.txtと示される(注)
test.bat

>type test.bat

ren 0123456789.txt 0.txt

>test.bat

>dir

0.txt

 という結果になり、自信はないけど、DOS6 のcommand.comが仕事をしているよう
には、見えませんでした。

(注)に示した。012345~1.txt のようなSFNはNT環境では、動的(相対的)な
ものなので、それを固定的にとらえて、たとえばrenとかしないほうがよい、という
のは、僕のXP時代の教訓です。

 僕が壮大にLFN→SFNをやったのは、XP環境かME環境だったのかもしれない
と、上の結果にもかかわらず、現在考えています。

[5293] Re: LFN @ vtdos

文太 2023/01/24(Tue) 14:53
[5292]へのコメント
 昼休みの合間に、しつこく。
 できちゃうの?

>dir
a0123456789.txt		; safe LFN
b0123456789.txt		; if b0123456789 is 0123456789b ???
c0123456789.txt
d0123456789.txt
e0123456789.txt
f0123456789.txt
g0123456789.txt
h0123456789.txt
i0123456789.txt
j0123456789.txt

>type test.bat
ren a0123456789.txt	A.txt
ren b0123456789.txt	B.txt
ren c0123456789.txt	C.txt
ren d0123456789.txt	D.txt
ren e0123456789.txt	E.txt
ren f0123456789.txt	F.txt
ren g0123456789.txt	G.txt
ren h0123456789.txt	H.txt
ren i0123456789.txt	I.txt
ren j0123456789.txt	J.txt

>test.bat

>dir
A.txt
B.txt
C.txt
D.txt
E.txt
F.txt
G.txt
H.txt
I.txt
J.txt

then?

>type test2.bat
ren A.txt	a0123456789.txt
ren B.txt	b0123456789.txt
ren C.txt	c0123456789.txt
ren D.txt	d0123456789.txt
ren E.txt	e0123456789.txt
ren F.txt	f0123456789.txt
ren G.txt	g0123456789.txt
ren H.txt	h0123456789.txt
ren I.txt	i0123456789.txt
ren J.txt	j0123456789.txt

>test2.bat

>dir
a0123456789.txt
b0123456789.txt
c0123456789.txt
d0123456789.txt
e0123456789.txt
f0123456789.txt
g0123456789.txt
h0123456789.txt
i0123456789.txt
j0123456789.txt


 いちおう整理します。

 vtdosのコマンド・インタープリタはcommand.comである。
 これは、ここでは、MS-DOS 6.2Vのものである。LFNを理解するはずがない。
 ren は内部コマンドだから、MS-DOS 6.2Vのcommand.comのrenが
使われるはずである。よって、LFNのリネームは失敗が予想される。

 が、現実には、LFNが有効だった。

 はて、その心は?
 仮説:vtdosでは、command.comの内部コマンドは使われず、cmd.exeのそれが
使われる。
 ほんと?

[5298] LFN再整理(vtdos)

文太 2023/01/28(Sat) 18:28
[5293]へのコメント
 経験にてらしてみれば、別に特別なことではなかったですね。(※)
 vtdos環境で、dirしたら、どんな結果になる? そこでcommand.com 
(ver.6.20)は使われてませんね。

C:\WK\01>dir /?
  /X          このオプションは MS-DOS 形式以外のファイル名に対する短い名前を
              表示します。長い名前の前に短い名前を表示する点を除けば、
              /N オプションと同じです。短い名前がない場合は、ブランクに
              なります。

C:\WK\01>dir /X

2023/01/28  17:57                 0 012345~1.TXT 0123456789.txt

 ほら、ちゃんとLFNも両方出てる。cmd.exeですよ。で、なんのための
command.comか? DOSアプリはcmd.exeをコマンドインタプリタとしては
動けません。
 そして、command.comの内部コマンドはcmd.exeに飛ばされる。
 で、元々の話題のFコールは?

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

=== Macrotmp by B ===;
* M
50 ^^ "Macrotmp"

;	dx="c:\wk\01\01234567.txt",		;SFN ↓ rename success
;	di="c:\wk\01\0123456789.txt",		;LFN

	dx="c:\wk\01\0123456789.txt",		;LFN ↓ rename success
	di="c:\wk\01\0123456789000.txt",	;LFN

	ax=$5600, &i($21)		;Rename

*

 というわけで、LFNファンクのあるものは、やっぱり飛ばされる。★

-------------------------------------------------
INT 21 - DOS 2+ - "RENAME" - RENAME FILE
	AH = 56h
-------------------------------------------------

 は、下へ飛ばされる。下は上を含みますからね。

-------------------------------------------------
INT 21 - Windows95 - LONG FILENAME - RENAME FILE
	AX = 7156h
-------------------------------------------------


(※)経緯をおさらいすると、我々(konnoさんと僕)は、vtdosのDOS機能は
DOS ver いくつか? とか、command.comのverを dos ver F_call が返すぞ、
とかやっていたものだから、>dir のいわば自然な振る舞い(cmd.exeのそれ)の
ことを忘れてしまっていたのです。

 どうでもいいことだけど、種明かしをすると、

#5293 
>dir
a0123456789.txt		; safe LFN

 はインチキだったのです。いえ、報告内容にはインチキはありません。
ただ、ここを書いたとき、>dir の結果を写してはいなかった。でも、こうなる
のを知っていた。確かめてもいた。で、さっき眺めてて、あれ? dir も内部コマンド
なんですけど? command.comがLFNとかレポートできちゃっていいわけ? と常識を
取り戻したという次第です。

 というわけで、あったとしたら、新たな発見は、★の発見です。


追記:これも関連事項でした。そして、こういうことがすぐ連想でできないのが、
僕、文太です。

 ren コマンドも同じ話です。vtdos環境で、ren がLFNを扱えるのなら、それは
command.com の内部コマンドではないはずです。これも、cmd.exeに(と言っていい
のか分からないけど。だって、その実態はFコールですから−−Fコールの実態とは
何かを追っかけてるのが、Undocumented DOS 2nd, see int 21h の正体 = DOS
の「ヌード」みたいな実体。原書 p.266-, chap 6, "What is MS-DOS?"。Win32 system
でも、我々が気にする部分は同じ。というか同じように作られてる)飛ばされる。

 括弧の多い文章すいません。ふつう許されないと思います。難しい言葉でごまかすと
「意識の流れ」とか言います。

[5299] Re: LFN再整理(vtdos)

konno 2023/01/29(Sun) 02:17
[5298]へのコメント
>  vtdos環境で、dirしたら、どんな結果になる? そこでcommand.com
> (ver.6.20)は使われてませんね。
>  ほら、ちゃんとLFNも両方出てる。cmd.exeですよ。で、なんのための
> command.comか? DOSアプリはcmd.exeをコマンドインタプリタとしては
> 動けません。
>  そして、command.comの内部コマンドはcmd.exeに飛ばされる。

おお、これは盲点でした。
VTDOS.CFG で
USECMD=0  にしたら、
ver
MS-DOS Version 6.20

と、command.com の内部コマンドが実行されました。
なるほどねぇ。


>  で、元々の話題のFコールは?
> === Macrotmp by B ===;
>  というわけで、LFNファンクのあるものは、やっぱり飛ばされる。★
> INT 21 - DOS 2+ - "RENAME" - RENAME FILE
> AH = 56h
>  は、下へ飛ばされる。下は上を含みますからね。
> INT 21 - Windows95 - LONG FILENAME - RENAME FILE
> AX = 7156h

うーん、どうやらそれっぽい動きではありますが、もやもやする。


> 追記:これも関連事項でした。そして、こういうことがすぐ連想でできないのが、
> 僕、文太です。

うう、追記は読んでいませんでした。(^^;

>  ren コマンドも同じ話です。vtdos環境で、ren がLFNを扱えるのなら、それは
> command.com の内部コマンドではないはずです。これも、cmd.exeに(と言っていい
> のか分からないけど。だって、その実態はFコールですから−−Fコールの実態とは
> 何かを追っかけてるのが、Undocumented DOS 2nd, see int 21h の正体 = DOS
> の「ヌード」みたいな実体。原書 p.266-, chap 6, "What is MS-DOS?"。Win32 system
> でも、我々が気にする部分は同じ。というか同じように作られてる)飛ばされる。

うーん、これはどうなんだろう。違うような気がします。
ということで、Win98Me のDOS窓でそのマクロを試してみました。
結果は、ロングの処理は出来ませんでした。
LFN対応の DOS8.0 は、ロング処理をしないようです。

ということは、VTDOSの F コールは VTDOS がロングにしているということでしょう。
USECMD= の値にかかわらずロングになるからです。

[5300] Re^2: LFN再整理(vtdos)

文太 2023/01/29(Sun) 04:16
[5299]へのコメント
konnoさん

>>うう、追記は読んでいませんでした。(^^;
 時間差がありました。m(__)m

>  ren コマンドも同じ話です。vtdos環境で、ren がLFNを扱えるのなら、それは
> command.com の内部コマンドではないはずです。

 これは、vtdosの話です。

>ということで、Win98Me のDOS窓でそのマクロを試してみました。
 そのマクロが#5298のことなら、

>結果は、ロングの処理は出来ませんでした。
 当然でないですか。そのために、Win95以来の。LFN対応ファンクがあったのだから。

	ax=$5600, &i($21)		;Rename

 は、LFNを知らない、純DOSファンクですよ。

>LFN対応の DOS8.0 は、ロング処理をしないようです。

-------------------------------------------------
INT 21 - Windows95 - LONG FILENAME - RENAME FILE
	AX = 7156h
-------------------------------------------------

 での話ですか?
 だとしたら、僕はかなり混乱します。

 基本的に、vtdosのFコールの特殊事情を主題にしています。

 混乱が解け不安も解消することを祈っています。

[5304] Re^3: LFN再整理(vtdos)

konno 2023/01/29(Sun) 21:50
[5300]へのコメント
> >ということで、Win98Me のDOS窓でそのマクロを試してみました。
>  そのマクロが#5298のことなら、
> 
> >結果は、ロングの処理は出来ませんでした。
>  当然でないですか。そのために、Win95以来の。LFN対応ファンクがあったのだから。

ファンクションコールがDOSと完全互換なら、VTDOSでもロングの処理は出来ないはずです。

> 	ax=$5600, &i($21)		;Rename
>  は、LFNを知らない、純DOSファンクですよ。

そのファンクションがLFN処理出来るようになっているので、互換性がないことになります。
各種DOSエミュは示し合わせたようにロングの処理を拡張していますが
おそらく利便性のためだと思っています。


確認は、文太さんのマクロをちょっと変えてみました。

=== Macrotmp by B ===;
* M
50 ^^ "Macrotmp"

	dx="d:\01\01234567.txt",		;SFN ↓ rename success
	di="d:\01\01234567890.txt",		;LFN
	ax=$5600, &i($21)		;Rename
	a=r,

	dx="d:\01\0123456789.txt",		;LFN ↓ rename success
	di="d:\01\0123456789000.txt",	;LFN
	ax=$5600, &i($21)		;Rename
	b=r, c'NG',
	(a+b>0)??c'OK',
	&m("%d  %d  %c",a,b,c)

*


	d:\01\01234567.txt		;SFN ↓ rename success
	d:\01\0123456789.txt		;LFN ↓ rename success

この2つのテキストでチェックしました。
返り値 r のキャリーが立っていたら NG のつもりです。

[5306] vtdosのF_call

文太 2023/01/29(Sun) 23:19
[5304]へのコメント
 かなり話がすれ違っていると思うので、ここから確認です。

>確認は、文太さんのマクロをちょっと変えてみました。

 意図がまったくつかめていないということで、申し訳ないのですが、
これをvtdosでした結果、renameに成功した、ということですよね?

 はい、そうなると思います。
 で、konnoさんは、何を主張されたいのでしょう? (ToT)(゜o゜; 意図が
まったく分かってません。想像がつきません。まったく。

#5302
【実験】SFN用renameファンク、ax=$5600, &i($21) をLFNに対して実行する。
 Win9x NG
 WinXP NG
 vtdos OK

 この結果はいいんですよね?


 ゆっくりやって、あまり先回りしないほうがいいのかもしれませんが、

>ファンクションコールがDOSと完全互換なら、VTDOSでもロングの処理は
>出来ないはずです。

 「DOSと完全互換」の場合のDOSのヴァージョンは? 「Win95 は、DOS7
あたりの上のシェル」って言い方で通じますよね?

 たぶん「クリップボードの処理」(Win9x系拡張ファンク)を10#さんが
我々と付き合い出してから入れたのを覚えています。LFN系ファンクを
DOSエミュレータ作家たちが入れた、というのも分かります。実際的だから。
だとしたら、SFNファンクは入れなかったんでしょうか?
 言いたいのは、ファンクションコールって(自前部分の程度はどうあれ)
エミュレータ作家たちが入れるものでしょう、ということです。

 これと、Win32 API は(これについて僕は何も知りません)まったく別だろう
とは思ってます。

 #5305も読んでいます。まず、こっちからいきましょう。

[5307] Win32 API

文太 2023/01/30(Mon) 01:40
[5306]へのコメント

 ふと思いついてしまったし、訪ねる先が違うので、少々先回りしちゃいます。

>としきさん

 tosfind.exeって、Win32 APIでできていて、「MS-DOS システムコール」なんて
含んでいませんよね。
 僕が、ふと想像したのは、Win32 API に「MS-DOS システムコール」をごっそり
含むファンクションというか機能があったりするんじゃないだろうか、ということ
です。ない! ですか。

>言いたいのは、ファンクションコールって(自前部分の程度はどうあれ)

 って書き方をしたのは、Undocumented DOSをみれば分かるとおり、DOSを再現
できる人なんて、そうそういない、つまり、MSが提供してる、していた
「MS-DOS システムコール」ライブラリがあるんだろう、ということです。

 前にもちょっと書きましたが、10#さんが「これ(MS提供の「MS-DOS
システムコール」ライブラリ(たぶん)を使っても、エミュの実装は、超大変、
割りに合わん」と書いていた記憶があるんですね。

 こうとでも考えなくちゃ、そんなにエミュが多種誕生するわけないよな、と
か考えています。
 どうですか?

[5308] Re: Win32 API

としき 2023/01/30(Mon) 23:55
[5307]へのコメント http://toshiki.la.coocan.jp/
>  tosfind.exeって、Win32 APIでできていて、「MS-DOS システムコール」なんて
> 含んでいませんよね。

Delphiのソースリスト上では、DOSのシステムコールは使っていません。
あと、私の怪しげな知識では、Win32のEXEファイルとDOSのEXEファイルでは、ファイルの構造というか構成が違っていたはず。だから、Win32のEXEファイルでDOSのシステムコールは使えなかったような。

>  僕が、ふと想像したのは、Win32 API に「MS-DOS システムコール」をごっそり
> 含むファンクションというか機能があったりするんじゃないだろうか、ということ

機能としてはあるはずです。上位互換。
ただ、その機能を呼び出すのにInt21は使わない、ということだったはず。
例えば、DOSのシステムコールにはファイルのオープンというのがあります。
そして、Win32APIにもファイルのオープンというのがあります。
つまり、そういうことです。

[5309] エミュの土台

文太 2023/01/31(Tue) 01:16
[5308]へのコメント
 ありがとうございます。

>Delphiのソースリスト上では、DOSのシステムコールは使っていません。
 当然そうなんでしょうね。

>あと、私の怪しげな知識では、Win32のEXEファイルとDOSのEXEファイルでは、
>ファイルの構造というか構成が違っていたはず。
 ありがとうございます。
 cmd.exeは、別世界。32bit process と呼んでよいのか???(違う話では
あろう) 了解です。

>>  僕が、ふと想像したのは、Win32 API に「MS-DOS システムコール」をごっそり
>> 含むファンクションというか機能があったりするんじゃないだろうか、ということ

>機能としてはあるはずです。上位互換。
>ただ、その機能を呼び出すのにInt21は使わない、ということだったはず。

 ありがとうございます。

 ただ、本当に訊きたいのは、Win3.0/3.1時代ぐらいに(LFNファンクを含まない)
「DOSのシステムコール」ライブラリみたいなのはなかったですか? SDKみたいなの?
 これを「Win32 API」と呼んだ僕がいけないのですが、io.sysとかmsdos.sysとかを含む
DOSシステムの再構築用キット。こういうのの噂を聞いたことはありませんか?

 なかったら、エミュレータなんて不可能だろう、と空想しているわけです。
 あ、あったかな? という答えをもらって、何がどうなるものでもないのですが。

 10#さんが、LFN関連の拡張DOSファンクションコールをどうやら自前で、手で
コーディングして入れていたみたい、という記憶はあります。
 ただ、io.sysとかmsdos.sys相当物を、Win32システム用(そこにうまく
くっ付くように)に個人が作るなんてのは、「常識的に」(?)無理だろう、
と考えているわけです。

 しつこいですが、ベースはあった、しかし、LFNファンクションはそこに含まれて
いなかった(みたい)、となると、なんとなく全体が少し明るくなるな、と思っています。

[5310] Re: エミュの土台

としき 2023/02/01(Wed) 13:59
[5309]へのコメント http://toshiki.la.coocan.jp/
>  ただ、本当に訊きたいのは、Win3.0/3.1時代ぐらいに(LFNファンクを含まない)
> 「DOSのシステムコール」ライブラリみたいなのはなかったですか? SDKみたいなの?

あったはずです。
私、Win3.1の時代のプログラミングってDelphi1.0での経験しかないのですが、確かその当時、アセンブラでWindowsプログラミングという話題を聞いたこともあったような。ニフティのプログラミング関係のフォーラムでWindowsプログラミングの解説があったり、ライブラリにWindowsプログラミング用のアセンブラマクロとかがアップロードされていたり、というようなうろ覚えの記憶があります。
ベクターのライブラリに、今でも残っていたりして。
実家へ行けば、何かわかるかも。
PLUMだっけ、あれのリストとかも残っているはず。
#ずいぶん古い用語が出てきた、でもめざらさんあたりは覚えているかも

>  これを「Win32 API」と呼んだ僕がいけないのですが、io.sysとかmsdos.sysとかを含む
> DOSシステムの再構築用キット。こういうのの噂を聞いたことはありませんか?

この辺はさっぱりわかりません。
ただ、Win3.1用でWin32APIの一部を使えるようにするWin32sというものはありました。
Wikipediaに解説がありますので、読んでみてください。
文太さんの疑問の一部に引っかかれば幸いです。
一つ明確にしておくと、Win3.1まではあくまでもDOS上のアプリであったということ。
なので、Win3.1の時代もWindows上からコマンドラインを呼べましたが、それは単にチャイルドプロセスの起動であったにすぎません。そしてチャイルドプロセスの起動はDOSのファンクションコールを持って行われていました。つまり、int21。

>  ただ、io.sysとかmsdos.sys相当物を、Win32システム用(そこにうまく
> くっ付くように)に個人が作るなんてのは、「常識的に」(?)無理だろう、
> と考えているわけです。

そこらのプログラマが作るのはかなり難しいでしょう。
でも、決して無理ではない、というのが私の意見。
実は私、PC-98のCPUが386だった当時、PC-98の上で動くPC-88のエミュレータが作れないかな、と考えたことがあるのですよ。そして、プロトタイプとして、N88BASIC(86)上で動くZ80のエミュレータを途中まで作ってみたのです。結局放棄したのですが、そのときの判断として、当時の私の実力では、Z80エミュレータは何とか作れるけどPC-88のエミュレータはかなり難しい、でも無理ではない、と考えました。もちろん、BASICでは当時のPC-98でもPC-88の速度は出ないというのはありましたけど。

[5311] Re^2: エミュの土台

文太 2023/02/02(Thu) 01:29
[5310]へのコメント
 色々と教えてくださり、ありがとうございました。
 とても感謝しています。というのも、目が覚めたからです。
 「いっけね、そっちは行かない予定だったんだ」と思い出してしまいました。
 WinMEはもとより、Win3.1もWin9xもNT系も、つまらん好奇心は持つな、
というつもりでした。何ていうか恩を仇で返しているみたいですが、僕にとっての
この重要な点を、こんなにすぐ思いださせてくれる能力のある人はとしきさんしか
いません。
 本当にありがとうございます。

 と言いつつ、ちょっとだけコメント。

>私、Win3.1の時代のプログラミングってDelphi1.0での経験しかないのですが、
 僕は、Win3.1って知らないんですね。Undocumented DOS 2nd の最初4分の1が
WinMGRだったかな、の話で、完全スルー、鬼スルーしてたんですね。
 (きっとこれからも)
 YASATさんが、Win3.1に関して「あれほどワケの分からんOSはなかった」と
言っていたのが、ほぼ唯一ある記憶。

 で、ベクターを覗いてみた。DOS/Win3.1/Win95-ME/NT-11という分類。
そして中を覗いてみると、おお、別世界、100%の外国。1000%の別惑星。
火星移住計画はないのだった、とか。
 退職後は外国暮らしとかはしないんですか? と割と近い人に訊かれることが
あります。まったくない、です。日本のことを知らなすぎる。死ぬまでVz、
死ぬまでDOS。

 奥様マシンはWin11になり、プリンタは動くのにスキャナが動かんということで、
ドライバ ver up。解決。このような方面では普通の人として生きて行く所存で
あります。インターネットできないOSなんて、、、。そのマシン、CD/DVD-drive
がなかった! 次のマシンを買うときは気をつけよう。
 (これっぽっちも面白くない関連ネタ。WinMEノートを\500で買ってしまった。
FDドライブがないマシン! BIOSがWindows上からしか覗けない。なんちゅう
マシンを作るのか! Dynabook)

>ただ、Win3.1用でWin32APIの一部を使えるようにするWin32sというものはありました
>Wikipediaに解説がありますので、読んでみてください。
 後日に。m(__)m ベクターで、大カルチャーショック!
 あ、「エミュレータ」(@Win9x)というジャンルもありましたが、開けません
でした。気がついたから。

>一つ明確にしておくと、Win3.1まではあくまでもDOS上のアプリであったということ。
 僕は、Win98ともほとんど付き合いがないのですが、WinMEではムリだけど
(パッチはある)Win98って、Winが立つ前にDOSで起動できるんじゃなかったで
したっけ? 意味が違いますかね?

>>  ただ、io.sysとかmsdos.sys相当物を、Win32システム用に作るなんて
>そこらのプログラマが作るのはかなり難しいでしょう。
>でも、決して無理ではない、というのが私の意見。

 僕が、そりゃムリなんだろう、と想像した根拠は、今日は割愛。
 エミュを全部落として.docとか読んだら、さりげなく書いてあったりするのかも
しれませんが、それは、僕にとってあまり意味のある行為ではないので、
止めておきますね。

 ここまで正直に書いたら、としきさんは、教えてやったのに、と思うでしょうね。
 ごめんなさい。
 ただ、それが一番いいと結論したのです。長い目で見て。
 何しろウソがつけない。記憶力がないから。何がウソで本当か、すぐ分からなくなる
ので、とりあえず、その瞬間瞬間を正直に生きようと思っております。
 ご愛顧に感謝しております。かわいがって下さり、ありがとうございます。

[5312] Re^3: エミュの土台

としき 2023/02/02(Thu) 16:49
[5311]へのコメント http://toshiki.la.coocan.jp/
>  YASATさんが、Win3.1に関して「あれほどワケの分からんOSはなかった」と
> 言っていたのが、ほぼ唯一ある記憶。

YASATさんのそのせりふは記憶にありませんが。
あれをOSだと思うと、大いに同意できるかも。
だから、あれはDOS上のアプリだと思っています。

>  僕は、Win98ともほとんど付き合いがないのですが、WinMEではムリだけど
> (パッチはある)Win98って、Winが立つ前にDOSで起動できるんじゃなかったで
> したっけ? 意味が違いますかね?

私のあてにならない記憶では、WinMEでもGUI起動前にコマンドプロンプトを起動させることができたような気がする。一方で、標準では、Win95だってGUIが最初に上がってきていたような。

>  ここまで正直に書いたら、としきさんは、教えてやったのに、と思うでしょうね。

それは思わない。その一方で

>  僕が、そりゃムリなんだろう、と想像した根拠は、今日は割愛。

この割愛した部分は近いうちにきちんと書いてほしいな、と思う今日この頃。

>  何しろウソがつけない。記憶力がないから。何がウソで本当か、すぐ分からなくなる
> ので、とりあえず、その瞬間瞬間を正直に生きようと思っております。

私も昔に比べて、かなり記憶力が衰えました。
なので、意図せず、本当のことだと思って平気でうそをついているかも。

[5313] Re^3: エミュの土台

konno 2023/02/02(Thu) 19:32
[5311]へのコメント
>  退職後は外国暮らしとかはしないんですか? と割と近い人に訊かれることが
> あります。まったくない、です。日本のことを知らなすぎる。死ぬまでVz、
> 死ぬまでDOS。

そういえば文太さんも大台が近い歳なんですよね。
確かどこかで書いていたかと思い、「文太」「歳」であちこち検索してみました。(^^;
その結果、codexマクロで、DCの過去ログから見つけました。\(^^)/
文太さんデビュー当時にお歳を書かれていたんですね。

今は年金65歳からとか色々あるので、セカンドライフプランはそれぞれでしょうが
先におめでとうと言っておきます。(^_^)
としきさんも同世代でしたっけ?

[5314] Re^4: エミュの土台

としき 2023/02/02(Thu) 21:42
[5313]へのコメント http://toshiki.la.coocan.jp/
> 文太さんデビュー当時にお歳を書かれていたんですね。

文太さんのデビューって、私の記憶が確かなら、確か1番会議室でしたよね。
それ、確か、私は読んでいないんですよ。

> としきさんも同世代でしたっけ?

四捨五入すれば、まだ60です。

[5315] Re^5: エミュの土台

konno 2023/02/03(Fri) 00:43
[5314]へのコメント
> 文太さんのデビューって、私の記憶が確かなら、確か1番会議室でしたよね。
> それ、確か、私は読んでいないんですよ。

これは私もわかりません。
私の認識では、DC13階デビューが2000年ころだったかと。

やしきの板塀#01692で文太さん自身が
> vwx 高橋版 vwxt.com           00/01/06 19:56
>  (この最後の日付でも、僕はまだDCデビューしてないはず。)
こう書いていましたね。

それで私の掲示板の#6300
> そうでしたっけ? DCの過去ログをグレップしてみました。
> 07061/07065 xxxxxxxx 文太 RE:サイレントでのマクロの異常
> (13) 00/07/13 13:26 06986へのコメント コメント数:1

私の調べではこのころからかと。

> > としきさんも同世代でしたっけ?
> 四捨五入すれば、まだ60です。

おめでとうございます。



# こうしてV爺党の世はふけていくのであった・・・

[5317] Re^6: エミュの土台

文太 2023/02/03(Fri) 01:02
[5315]へのコメント
> 07061/07065 xxxxxxxx 文太 RE:サイレントでのマクロの異常
> (13) 00/07/13 13:26

 2000年7月。何をしてたんでしょうかねぇ? トオイメ。
 2001年8月には、初回渡米をしているはずです。そして、いきなり911。
 このあとに、YASATさんが、blogjump.def 完成版を作ってくれました。
 あの頃の部屋の風景も覚えてる。バクバク、ドキドキした。
 まず不安、でしたけど。
 和生さんにも、ハッっとすること教えてもらったな。部屋の空気、匂いを
覚えてる。

 「サイレントでのマクロの異常」またまた難しいことを。9年半後でも
これを直そうとか思ってません。
 これより、としき発見のバグですね。Vzのメモリ管理(テンポラリー
ファイル管理)だと思ってます。
 半年の経験では、DOSコマンドラインに下りると、vtdosでは落ちますね。
45回くらいは落ちましたね。下りる前にファイルセーブが習慣になっています。
WinMEなら起きないのに! (^_^メ)

[5320] Re^7: エミュの土台

めざら 2023/02/04(Sat) 14:49
[5317]へのコメント http://mezala.la.coocan.jp/
>  このあとに、YASATさんが、blogjump.def 完成版を作ってくれました。

blogjump,懐かしいですね……当時は,back-log-jump なのか bunta-log-jump なのかわからなくなるくらい文太さんの思い入れが強かったですね。(内心,各自の手元にあるログのファイル名や切り分け範囲もそれぞれなのだから,そんなに一所懸命にならなくてもなーなんて思ったりもしました。動作テストが面倒だったから。)

そういえば,YASAT さんの近況も気になります。以前は dr-dos のページに YASAT さんのコンテンツもあったりしましたが……。

……おっ! まだ有るじゃないですか…と言うか,元のページが閉鎖になったのち有志が転載されているのですね!素晴らしい!
 → http://ifs.nog.cc/drdos.at.infoseek.co.jp/jis2k/vzmacro.html
早速,他山の璧からリンクしておこう。


>  あの頃の部屋の風景も覚えてる。バクバク、ドキドキした。

それは,どなたもそうだったと思いますよ。
pk時代だったら,ある意味さらに過激な風景でした。
興奮して夜も眠れず,早起きしては電話代の節約と言い訳してました。
幼子を膝に乗せて打つキーボードはミスタイプが多く,我が子がピッとかプッとか警告音を真似してました。この頃すでに,娘の音感の良さと,倅のその異常なまでの音声模倣の不得手具合が明らかでした。娘は絶対音感を持ち,倅は幼稚園を卒園するまで言葉が出ませんでした。(今はこちらが何か言うと,にくらしいほど反論してきます。)
家族の歴史も重なります。懐かしさで,キュッとなります。(頸じゃないよ)

こういう幸せの記憶を戦争なぞで失いたくない…と思う新しい戦前の時代。

[5323] Re^7: エミュの土台

konno 2023/02/05(Sun) 20:31
[5317]へのコメント
> >> としきさんも同世代でしたっけ?"
> >四捨五入すれば、まだ60です。
>  僕のイメージでは、としきさんは、55? 鯖を数えたでしょう?

としきさんは鯖の管理者ですからね、そのへん自由自在のエージェント・スミスみたいな。
(いや全然違うか)

>  Vzソースに実際的に手を出すのには、まだ、あと9年半あります。
>  そういう約束になっています。

なにやら遠大な話ですね。10年後にVZ実行可能な環境が残っているかどうか。
ソーラパネルで何とか電力は確保しても通信はラジオだけだったりとか。
外へ出るときは防護マスクするとか、そんな環境になってたりして。(^^;

>  2001年8月には、初回渡米をしているはずです。そして、いきなり911。

なんと、危ないところだったですね、あれは衝撃的で悲惨でした。

>  これより、としき発見のバグですね。Vzのメモリ管理(テンポラリー
> ファイル管理)だと思ってます。
>  半年の経験では、DOSコマンドラインに下りると、vtdosでは落ちますね。
> 45回くらいは落ちましたね。下りる前にファイルセーブが習慣になっています。
> WinMEなら起きないのに! (^_^メ)

VTDOS上のVZでは EMS に問題が有るようです。
EMS は最小限にして、XMSをいっぱい取るのがいいようです。
メモリ拡張オプションも要注意です。
これらの対策をしても落ちるなら、特定のマクロかコマンドが絡んでいる可能性は?

まあ、私も WGREP を多用していて、たまに落ちることがありますが
対策後は以前に比べて落ちにくくなった気がします。気のせい?
# V_csrマクロを使うとよく落ちます。(;_;)

[5324] Re^8: エミュの土台

文太 2023/02/06(Mon) 03:20
[5323]へのコメント

>なにやら遠大な話ですね。10年後にVZ実行可能な環境が残っているかどうか。
 環境は、残すものです。ハードウェアってけっこうタフなものだな、というのが
割と最近の発見です。おまけでもらったフロッピーが50回つかってもまだ
大丈夫です。HDもマザーボードも。腐海整理、少しずつ開始。
\500 WinME Dynabook without FDDも。

 惑星に関してなら、アメリカと中国が馬鹿な戦争を始めないかぎり(ないです)
大丈夫、あと85年程度はもちます。

 自分の命と健康、管理できるか分からないのはこっちですよ。
 がんばりましょうね!

[5316] Re^5: エミュの土台

文太 2023/02/03(Fri) 00:46
[5314]へのコメント
>文太さんのデビューって、私の記憶が確かなら、確か1番会議室でしたよね。
 まじかよ、知りませんよ、調べる気もないですよ。

>それ、確か、私は読んでいないんですよ。
 小技きいてんだよなぁ、ったく。そ、れ、は、才能って、やつだろう。

>> としきさんも同世代でしたっけ?"
>四捨五入すれば、まだ60です。
 僕のイメージでは、としきさんは、55? 鯖を数えたでしょう?

>セカンドライフプランはそれぞれでしょうが
>先におめでとうと言っておきます。(^_^)

 いえ、ぜんぜん、めでたくないです。先が長いねぇ、とため息まじりに
決断しました。やれやれ。
 機械をやると農業に行きたくなり、農業に疲れると機械にもどりたくなります。
 両方に一生懸命になりすぎだと感じると、無目的に、物語がとても恋しくなります。
 Vzソースに実際的に手を出すのには、まだ、あと9年半あります。
 そういう約束になっています。

 konnoさんに、また、ちゃんと教わっちゃったなぁ、とは分かってますよ。
 more & ver、どうしよう? All IBM PC's & Win98/ME でちゃんと動く more!
必要性はございませんが。

 ちょっと休みますね。3月に、どうにか少しだけは復活の予定です。

追記:
 閑話休題。『DOS/Vプログラミング技法』(翔泳社、1992年10月刊)。
IBM PC の本。これのおかげで、「PC-9800 Series/DOS/V PC/J3100/AX,PS/55」
@ Vz1.6 黒本表紙、の意味がやっと分かりました。
 Vzソースみてて、邪魔なんだよね。

 さすがのノートン先生も、日本の特殊事情は説明してはくれない。もっとも
上記『技法』の広告に『IBM PC&PS/2』(ノートン共著。翻訳)がありました。

 PS/2, ISA, Micro Channel。色々あったのねぇ。

 一生、死ぬまで、青春です!!!
 枯れたい? それでは、『リバーサル・オーケストラ』を。古典音楽は老人のための
音楽。若者音楽家たちに怒られそうだ。

[5318] 追記

文太 2023/02/03(Fri) 01:16
[5316]へのコメント
追記

https://web.archive.org/web/20200328183820/https://sites.google.com/site/pcdosretro/

 で、以下の資料はまだ入手可能です。


IBM PC BIOS source code reconstruction
Information
IBM PC BIOS version history
IBM PC BIOS - all 3 versions (dated 04/24/81, 10/19/81, 10/27/82)
IBM PC XT BIOS version 1 (dated 11/08/82)
IBM PC XT BIOS version 2 (dated 01/10/86)
IBM PC XT BIOS version 3 (dated 05/09/86)
IBM PC AT BIOS version 1 (dated 01/10/84)
IBM PC AT BIOS version 2 (dated 06/10/85)
IBM PC AT BIOS version 3 (dated 11/15/85)
IBM PC XT 286 BIOS (dated 04/21/86)

Related specs and information
BIOS functions
BIOS data area
Keyboard scan code/character code combinations
List of PC interrupts
80x86 instruction reference
Official Expanded Memory Specification (EMS) documentation: version 3.2 - version 4.0
Official eXtended Memory Specification (XMS) documentation: version 2.0 - version 3.0
Official Virtual Control Program Interface (VCPI) documentation: version 1.0
Official Virtual DMA Services (VDS) documentation: version 1.0
Official DOS Protected Mode Interface (DPMI) documentation: version 0.9 - version 1.0
VESA BIOS Extension (VBE) documentation: version 1.2 - version 2.0 - version 3.0
Master Boot Record (MBR) information and code disassembly
Microsoft FAT (File Allocation Table) file system documentation
Microsoft CD-ROM Extensions (MSCDEX) documentation
Relocatable Object Module Format (OMF) documentation
Microsoft Macro Assembler (MASM) version history
Microsoft C compiler version history

 EMSやXMSのスペシフィケーションの資料がなくて、どうやってVzと付き合う
のでしょう?
 いろいろ怖いです。自分が、、、、怖いです。

http://web.archive.org/web/20080216121237/http://ourworld.compuserve.com/homepages/r_harvey/doc_book.htm
 英語で嫌かもしれませんが、こういう資料もあります。

[5319] Re: 追記

文太 2023/02/03(Fri) 12:20
[5318]へのコメント
お休み中の予定

 本物の修羅場に突入します。毎年のこと。
 ただただ事故を起こさないよう慎重に生きてゆきたいと思っています。

 お休み中、ほぼ無意味に macro.asm のハードコピーを持ち歩き、そして、
BIOS コールとはなんぞや周辺をぶらぶらしてみたいと思います。video (モノが
進化しちゃってるからねぇ)とdisk。直接Vzと関係はないと思うけど。

 後者に関して、あるんだぁ、という発見。

 以下は、NU (Norton Utilities) の BE (Batch Enhancer) の doc から。

----------------------------------------------------------------------
DISKMON (DISK MONITOR)	Enable or disable disk protection features: 
			Disk Protect and Disk Park.
	DISKMON  [/PARK]
	/PARK 		Park the disk heads on all drives. 
----------------------------------------------------------------------

 こんなことできるのね。旧8でキーボードバッファの拡大とかHDのヘッドの
退避とかあったじゃないですか(古い資料の発掘、ありがとうございました
>としきさま)。

 あ、つまり、今回も様々な刺激ときっかけををいただき、そして色々と勉強させて
いただきました。幸福の至りでございました。多謝でありまする。
 なんだ? この言葉づかいは!?

[5303] Re^2: LFN再整理(vtdos)

文太 2023/01/29(Sun) 20:03
[5299]へのコメント
>ということは、VTDOSの F コールは VTDOS がロングにしているということでしょう。
>〔F コールのばあい、コマンドラインのrenと違って〕USECMD= の値にかかわらず
>ロングになるからです。

 なるほど! と思ったのですが、うーん、もやもやする。

SFN Fcall -> LFN Fcall		;(1)「投げる」と僕は表現してきたと思う。

 上をVTDOSがする、というのが僕のイメージ。

 USECMD=0 の場合、(1)をVTDOSがしない、といういう言い方はどうでしょう?
 おなじことを言ってるのか?

 僕が想像しているのは、command.comの内部コマンドのrenであれ、Vzマクロ
からの ax=$5600, &i($21)であれ、けっきょくそれは、command.comやVzがやっている
というより、DOSカーネルがやってることでしょう? という意味なんですが。
 VTDOS環境においては、VTDOS自身がDOSカーネルである。
 はい、そう認識しています。


--- usecmd=0 in VTDOS.cfg ---
C:\>dir |more

 Volume in drive C is OS         
 Volume Serial Number is 0A1E-F410
 Directory of C:\

0            <DIR>         22-12-28   23:05
001      LOG        42,436 23-01-18    1:17
00EG     TXT         1,176 23-01-21    2:07

 おほほほ。久しぶりにみたなぁ。汚いルートは見慣れておりますが。

C:\>dir /p		; 効きます!!! た、たどり着いた!!!
iroiro
iroiro
Press any key to continue . . .

[5305] Re^3: LFN再整理(vtdos)

konno 2023/01/29(Sun) 22:28
[5303]へのコメント
> >ということは、VTDOSの F コールは VTDOS がロングにしているということでしょう。
> >〔F コールのばあい、コマンドラインのrenと違って〕USECMD= の値にかかわらず
> >ロングになるからです。
>
>  なるほど! と思ったのですが、うーん、もやもやする。

理解のしかたは人それぞれみたいですね。
私は私なりの理解で纏めてみます。

> SFN Fcall -> LFN Fcall ;(1)「投げる」と僕は表現してきたと思う。
>  上をVTDOSがする、というのが僕のイメージ。
>
>  USECMD=0 の場合、(1)をVTDOSがしない、といういう言い方はどうでしょう?
>  おなじことを言ってるのか?

ファンクションコールは、DOSでは MSDOS.SYS が担当します。
DOSエミュでは、IO.SYS も含めて自前でこれらを処理します。
command.com は、受け渡しをしているだけです。

内部コマンドは、CMD.EXE に受け渡しをしたり自前でやったり色々です。
CMD.EXE や自前の場合は、32ビットAPIなどを使うので、F コールは使いません。
コマンドの結果を何も表示しないことがありましたが、32ビット処理のままだったからかも。

DOSエミュでの内部コマンドはファンクションコールを使わないという認識です。

[5295] Re^2: 一括リネームのテストと限界,結論

めざら 2023/01/24(Tue) 20:58
[5289]へのコメント http://mezala.la.coocan.jp/
> これ、実行環境は VTDOS ですよね。

そうです。どうやら,VTDOS 環境がどっぷり16ビットDOS のそれではないらしく,そのお陰で従来版ファインクションコール AH=56h で出力結果がロングになっても,通してくれることがわかりました。自分としてはこの辺りで満足です。一番時間のかかる連番付けさえ一瞬なら,あとは xyzzy ファイラでなんとでもなりますから。

> 試してみたら、最近の DOSエミュ3種は、同じようにロング変換できました。

ここの「試し」は,マクロ? バッチのREN ?

> ロング対応するなら、ax=$7156 だったかな。未確認。(^^;

&Fg() での取得がショートのみなので,例のマクロでは対応できないです。
そもそも,ロングを正しくファイラでソートできないので,番号付の順序が変わってしまい,順序が重要な場合は使い物にならないですね。

長いファイル名を取得するとしたら,ファイラで #R #H によって削除バッファに格納するくらいしか方法がないですかねぇ……。

何か良い方法はありますか?

[5297] Re^3: 一括リネームのテストと限界,結論

konno 2023/01/25(Wed) 00:05
[5295]へのコメント
> > これ、実行環境は VTDOS ですよね。
>
> そうです。どうやら,VTDOS 環境がどっぷり16ビットDOS のそれではないらしく,そのお陰で従来版ファインクションコール AH=56h で出力結果がロングになっても,通してくれることがわかりました。自分としてはこの辺りで満足です。一番時間のかかる連番付けさえ一瞬なら,あとは xyzzy ファイラでなんとでもなりますから。

REN だけでなくマクロでも使えるというのは発見ですね。
DOSエミュの環境はいこごちがいいわけです。

> > 試してみたら、最近の DOSエミュ3種は、同じようにロング変換できました。
>
> ここの「試し」は,マクロ? バッチのREN ?

単独の REN です。
ファンクションコールは当然対応していると思いますし。

そういえば、DOSVAXJ3 は、高橋版VZでLFN表示できますね。今気が付きました。
Win95,98系APIに準拠させているのでしょうか。
VTDOSとMSDOS Player は、WinNT系準拠ということのようです。
CF の返り値だけの違いなので、NT系にするメリットってあるのかしら?

と思ったのですが、このキャリーフラグはFATシステムかNTFSシステムかの違いだったような。
謎です。


> 長いファイル名を取得するとしたら,ファイラで #R #H によって削除バッファに格納するくらいしか方法がないですかねぇ……。
>
> 何か良い方法はありますか?

う、私も基礎からやり直している最中なので、すぐには思いつきません。(^^;

[5301] 一括リネームのテストと環境の差異

めざら 2023/01/29(Sun) 10:47
[5278]へのコメント http://mezala.la.coocan.jp/
> DOSのファンクションコールも長いファイル名対応なんすね……ってことで良いのか
> 悪いのかよくわからないんだけれど,まぁ結果オーライってことで。

環境によって結果が異なるのかの確認のため,VTDOS 以外の環境でどうなるのか試してみました。…といっても,既に Win 98 se なんてありませんから,Win XP Pro v2002 sp3 のコマンドプロンプトで起動した VZ です。

VTDOS 環境では,ロング非対応のはずの ax=$5600, &i($21) で結果的にショートからロングへのリネームが出来ていましたが,はてさて……。

結果は,ax=$5600, &i($21) の実行でエラー(戻り値が偽)。

次にロング対応のファンクションコールを試しました。
該当部分を ax=$7156, &i($21) に書き換えただけのものです。

所期の結果が得られ,ABCD9999.EXT → ABCD9999_01.EXT 等への変換可能。

理由はわからないけれど,VTDOS 環境ではロングの扱いが美味しい。
…という結果オーライ。

理由はわからないけれど,結果オーライだから,ま,いいか。

[5302] Re: 一括リネームのテストと環境の差異

文太 2023/01/29(Sun) 14:13
[5301]へのコメント
 再整理ありがとうございました。
 予想どおりの結果でした。

 【実験】SFN用renameファンク、ax=$5600, &i($21) をLFNに対して実行する。

 Win9x		NG
 WinXP		NG
 vtdos		OK

>理由はわからないけれど,VTDOS 環境ではロングの扱いが美味しい。
>…という結果オーライ。

 です。たぶん、vtdos.txtが読みこなせれば、それなりの想像ははたらくのかも。

↑ このページの先頭