最近はVTDOSの更新も再開され、FreeCOMも使えるようになりましたが、
VZ、あるいはDOSのメモリ管理が？な状態が気になってきました。

そこで、VZ環境いいん会を立ち上げることにしました。
会長は私、会員は今のところ一人だけです。(^^;

手始めに、手土産代わりのマクロを。

=== vz_env.def ===

*m
80 ^\ "vz_env" 

    dz[=pn..15~-1,b=0., dz],		;mcb　ZはOK、Mは要注意
    ax$3000,&i($21) d=ax%256, e=ax/256,	;DOS ver
    ax$71a0,&i($21) l=ax,c=r,		;LFN vol
    ax$1680,&i($2f) i=ax,		;idle call
    dz[=vz,				;psp VZ起動文字列
#if tVZ
    &m("psp=%Fs  mcb=%c  Ver=%d.%d  LFN=%x cf%d  idle=%04x",8,vz-1,b,d,e,l,c,i)
#else
    &m(" mcb=%c  Ver=%d.%d  LFN=%x cf%d  idle=%04x",b,d,e,l,c,i)
#endif
    dz],				;vz-1:8 の文字列
.
*

 %Fsという高橋版の拡張書式を使っているので、psp文字列は高橋版以降のみです。
NT系のDOS窓常駐VZではここの表示がおかしい場合があり、その場合動作が不安定なことも。
VMAPの表示と同じなので、VMAPを見れば済むという話も。

 mcb がMだとそのメモリはVZの管理下にないのでコマンドラインでマクロ呼び出しなどで
メモリアロケーションエラーが出やすいかも。
まあ、MEUのほうがわかりやすいけどね。


＃会則宣言
　おれおれさぎに、あってはいけない。
　マクロはうまくつくれ。
　できる範囲で、かまわないから。

konnoさん

　私的覚え書きです。

--- LFN vol func call ---

INT 21 - Windows95 - LONG FILENAME - GET VOLUME INFORMATION
	AX = 71A0h
	DS:DX -> ASCIZ root name (e.g. "C:\")
	ES:DI -> buffer for file system name
	CX = size of ES:DI buffer
Return: CF clear if successful
	    AX destroyed (0000h and 0200h seen)
	    BX = file system flags (see #01783)
	    CX = maximum length of file name [usually 255]
	    DX = maximum length of path [usually 260]
	    ES:DI buffer filled (ASCIZ, e.g. "FAT","NTFS","CDFS")
	CF set on error
	AX = error code 7100h if function not supported <<<==== for MS-DOS★
Notes:	for the file system name buffer, 32 bytes should be sufficient; that's
	 what is used in some sample code by Walter Oney from Microsoft.
	this function accesses the disk the first time it is called
BUG:	this function returns DX=0000h for CD-ROM drives under Win95 SP1

Bitfields for long filename volume information flags:
Bit(s)	Description	(Table 01783)
 0	searches are case sensitive
 1	preserves case in directory entries
 2	uses Unicode characters in file and directory names
 3-13	reserved (0)
 14	supports DOS long filename functions
 15	volume is compressed


　これについての僕の記憶は、これのみなので。
　そのまま使わせてもらってる場合も、あったはずなのだけど。
--- from clppst.def, win or not routine ---
00:	&Sp(pr,"%sCLPPST.EXE",pi)
	&01 (r==0)? { &m("Windows95 上で実行してください") &q . }
	    (r==-1)?{ &m("CLPPST.EXE が VZDEF ディレクトリにありません") &q . }

01:	&Sc(pa,pi,3) dx=pa, di=pa+5,
	bx-, cx=50, ax=$71A0, &i($21) (ax==$7100 || r)?{ (0) . }
;★ 先回りして書くと、どうしてとらじさんがこういうaxの扱いをしているのか
;　真剣に考えるべきだったのです。この先、文太くん、ちまちましばらくもがき
;　ます。
	ax$4300, dx=pr, &i($21) (r)?{ (-1) . } (1)


--- GET FILE ATTRIBUTES func call ---
INT 21 - DOS 2+ - GET FILE ATTRIBUTES
	AX = 4300h
	DS:DX -> ASCIZ filename
Return: CF clear if successful
	    CX = file attributes (see #01420)
	    AX = CX (DR DOS 5.0)
	CF set on error
	    AX = error code (01h,02h,03h,05h) (see #01680 at AH=59h)

(Table 01680)
Values for DOS extended error code:
---DOS 2.0+ ---
 01h (1)   function number invalid
 02h (2)   file not found
 03h (3)   path not found
 05h (5)   access denied

　うーん、なんで、これ、必要なんだろう？
　分かった、CLPPST.EXEの存在確認だ。やれやれ。違うところで考え込んでるし。


　ああ、こんな遠くに。
--- IDLE func call ---
INT 2F - MS Windows, DPMI, various - RELEASE CURRENT VIRTUAL MACHINE TIME-SLICE
	AX = 1680h
Return: AL = status
	    00h if the call is supported
	    80h (unchanged) if the call is not supported
Notes:	programs can use this function in idle loops to enhance performance
	  under multitaskers; this call is supported by MS Windows 3+, DOS 5+,
	  DPMI 1.0+, and in OS/2 2.0+ for multitasking DOS applications
	  does not block the program; it just gives up the remainder of the
	  time slice, should not be used by Windows-specific programs
	  when called very often without intermediate screen output under
	  MS Windows 3.x, the VM will go into an idle-state and will not
	  receive the next slice before 8 seconds have elapsed. This time can
	  be changed in SYSTEM.INI through "IdleVMWakeUpTime=<seconds>".
	  Setting it to zero results in a long wait.
	this function has no effect under OS/2 2.10-4.0 if the DOS box has an
	  "Idle Sensitivity" setting of 100

----------------------------------------------------------------------------
　ちょっと整形。少々雑な英文みたい……。


--- vz_env.defの結果 ---
<< normal XP >>
psp=VZ  mcb=Z  Ver=5.0  LFN=> cf0  idle=1600 (meaning AL==00h, OK! bunta main)

<< normal ME >>
psp=VZ  mcb=Z  Ver=8.0  LFN=> cf0  idle=1600	(Biblo, NE6/60C)

<< EmsMagic XP >>
psp=VZ  mcb=M  Ver=5.0  LFN=> cf0  idle=1600	(Pana, Let'sNote, CF-W7)

<< EmsMagic ME >>
psp=VZ  mcb=M  Ver=8.0  LFN=> cf0  idle=1600	(IBM x31)

<< Moba 6.2 DOS >>
psp=VZ  mcb=Z  Ver=6.20  LFN=> cf1  idle=1680	(Moba)
		       not supported  not supported


　ちょっと改変しました。高橋版のみです。結果を書き出してしまいますからね。
=== vz_env.def ===
*m
80 ^\ "vz_env" 

    dz[=pn..15~-1,b=0., dz],		;mcb　ZはOK、Mは要注意
    ax$3000,&i($21) d=ax%256, e=ax/256,	;DOS ver
    ax$71a0,				;LFN vol
    &Sc(pa,pi,3) dx=pa, di=pa+5, cx=50,	;★toraji, bunta
    &i($21) (ax==$7100)? c=1,	;★CFは生ドスでは立ちません。
    ;c=r,
    ax$1680,&i($2f) i=ax,		;idle call
    dz[=vz,				;psp VZ起動文字列
    &?("psp=%Fs  mcb=%c  Ver=%d.%d  LFN=> cf%d  idle=%04x",8,vz-1,b,d,e,c,i)
    dz],			    ;★bunta
.
*

　以下のような具合だったのですねぇ。ここにたどり着くまで、実は長かったぁ。
　「キャリーが立ってないじゃないかぁ」とか。
　しかし、過去ログの偉いこと、偉いこと。

>10251/10256 PXC07042  とらじ           int21_71A0 の返値
>(15)   98/05/21 01:17  10246へのコメント
>
>　#10246　ひろみっちゃん
>
>　int21_71A0 に限らず、拡張ファンクションコール一般だと
>　生ＤＯＳでは CY が変化しません。　ＤＯＳモードだと CY が立ちます。
>　で、どっちも ax$7100 が返ります。
>　生ＤＯＳと拡張ファンクションコールを合わせて使うのには
>　↓の方法がＭＳから推奨されてます。　
>
>EX_FUNC         MACRO   func
>                LOCAL   skip0, skip1
>        stc
>        mov     ax,7100h+func
>        int     21h                     ;拡張ファンクション
>
>        jc      skip0
>        cmp     ax,7100h
>        jne     skip1
>skip0:
>        mov     ah,func
>        int     21h                     ;生ファンクション
>skip1:

　このほうがいいですね。

    ax$71a0,				;LFN vol
    &Sc(pa,pi,3) dx=pa, di=pa+5, cx=50,	;★toraji, bunta
    &i($21) (ax==$7100)? c=1,
↓
    ax$71a0,				;LFN vol
    &Sc(pa,pi,3) dx=pa, di=pa+5, cx=50,	;★toraji, bunta
    &i($21) c-, (ax==$7100 || r)? c+,

文太さん、どうも。

理解するのにだいぶ時間がかかってしまいましたが、おおむね分かったつもりです。
（最初は古代文字でも見るように全く頭に入らなかった。(^^;）

ということで、私の好みの修正版です。

=== vz_env.def v05 ===

*m
80 ^^ "vz_env2" 			;Win7のDOS窓では'\'が入力できない(>_<)

    dz[=pn..15~-1,b=0., dz],		;mcb　ZはOK、Mは要注意
    ax$3000,&i($21) d=ax%256, e=ax/256,	;DOS ver
    ax$71a0,				;LFN vol
    &Sc(pa,pi,3) dx=pa, di=pa+5, cx=50,	;★toraji, bunta
    &i($21) c-, (ax==$7100 || r)? c+,	;★CFは生DOS、Win95系では立たない
    l-,(ax!=$7100)? l+,;    	    	;lfn=1  ※ NT系ではcfが立つ
    ax$1680,&i($2f) i=ax,		;idle call
    i-,(ax!=$1680)? i+,;    	    	;idle=1
    (ks&1)?>p				;Shift起動で書き出し
    dz[=vz,				;psp VZ起動文字列 (違う時は要注意)
    &m("psp=%Fs  mcb=%c  Ver=%d.%d  LFN=%d cf%d  idle=%d",8,vz-1,b,d,e,l,c,i)
    dz], .				;★bunta
:p					;カーソル位置に書き出し
    dz[=vz,				;psp VZ起動文字列 (違う時は要注意)
    &?("psp=%Fs  mcb=%c  Ver=%d.%d  LFN=%d cf%d  idle=%d",8,vz-1,b,d,e,l,c,i)
    dz],				;★bunta
.


;v05	シフト起動でカーソル位置に書き出し、表示変更。
;v04	文太さん改2　ちょい変更
;v03	文太さん改　カーソル位置に書き出し、表示変更。
;v02	LFNとidleを追加。
;v01	vzinfo.defからMCBとPSPを抜き出した。

*

で、Win7のVTDOSでの結果。

psp=VZIBMJ  mcb=Z  Ver=6.20  LFN=1 cf0  idle=0

> 　嬉しいです。konnoさんがちゃんと作ってくれると安心。

いや、実はVTDOSで高橋版VZがLFNできないので、あれ？　と思って見たらバグってました。
いまごろ気づいても遅すぎなんですが。m(__)m

NT系ではLFNファンクションでcfが1になるはずが、cf0 と表示されてますね。

    &i($21) c-, (ax==$7100 || r)? c+,	;★CFは生DOS、Win95系では立たない

これはWin95/98用の判定文だったかなあ。ということで、

    &i($21) c=r,			;★CFは生DOS、Win95系では立たない

こう変えてみましたが、やっぱりcf0 のままです。あれえ？

・・・いろいろ試してみて、やっと原因がわかりました。

;   &Sc(pa,pi,3) dx=pa, di=pa+5, cx=50,	;★toraji, bunta

この行をコメントにしたら、cf1 になりました。ここってなにやってるんだっけ？
新版はもう少し弄ってから上げます。

> >psp=VZIBMJ  mcb=Z  Ver=6.20  LFN=1 cf0  idle=0
> 　ええ、pspがそうなるんですか。PC-DOSとMS-DOSってどう違うんだろう？

文太さんのは、VZ.COMにしているのではないんですか。そうでないとしたら
何がちがうのやら。

> 　idleは効かないんですかぁ……。強力なマシンパワーで問題にならないんでし
> ょうかね。

それが、やはりエミュレータだからか、DOS窓に比べて少し遅いのはしかたないかと。
まして、CKWV がもたつくのはしょうがないと諦めモードだった。・・・昨日までは。

おねだりが叶って、VTDOSがアイドル対応になりました。画面表示関係も最適化したのか、
DOS窓と遜色なくきびきび動くようになりました。CKWVもきびきび動くようになって、
もう、ひゃっほう状態です。＼(^^)／ 

ちなみに、マクロ修正後のVTDOS
psp=VZIBMJ  mcb=Z  Ver=6.20  LFN=1 cf1  idle=1

Win7DOS窓
psp=VZIBMJ  mcb=Z  Ver=5.0  LFN=1 cf1  idle=1

うーん、VTDOSはNT系だったか。

konnoさん

>NT系ではLFNファンクションでcfが1になるはずが、cf0 と表示されてますね。
　いえ、ちゃんとしてれば、cf==0, つまり、キャリーフラグ・オフとなるはずです。
　cf==0は、LFN OKの意味です。

#6271
--- vz_env.defの結果 ---
<< normal XP >>
psp=VZ  mcb=Z  Ver=5.0  LFN=> cf0  idle=1600 (meaning AL==00h, OK! bunta main)

<< normal ME >>
psp=VZ  mcb=Z  Ver=8.0  LFN=> cf0  idle=1600	(Biblo, NE6/60C)


#6270 これが元です。これは駄目です。
    ax$71a0,&i($21) l=ax,c=r,		;LFN vol
　ファンクションコールのパラミータが足りてないんです。
　つまり、rにLFN OK or NGの結果が返りません。元々で、lとcが変なこと
（意味不明なこと）をレポートしてたでしょう？　WinXPでオリジナルを試して
みてください。それが発端です。

　そして、もう一歩先で、生ドスではキャリーが立ちません。


    &i($21) c=r,			;★CFは生DOS、Win95系では立たない
　これでは駄目ですぅ。

>;   &Sc(pa,pi,3) dx=pa, di=pa+5, cx=50,	;★toraji, bunta
>この行をコメントにしたら、cf1 になりました。ここってなにやってるんだっけ？

　コメントアウトしちゃあ駄目です。パラミータ不足。
　なぜキャリーが立つのかは謎です。どっかの無関係なｒのせい？

#6274
    ax$71a0,				;LFN vol
    &Sc(pa,pi,3) dx=pa, di=pa+5, cx=50,	;★toraji, bunta
    &i($21) c-, (ax==$7100 || r)? c+,
　これでいいはずなんですが……。
　書き直すとこうです。

    ax$71a0,			;ax	;LFN vol
    &Sc(pa,pi,3) dx=pa, 	;dx
    di=pa+5, 			;di
    cx=50,			;cx	;★toraji, bunta
    &i($21) 
    c-, (ax==$7100 || r)? c+,		;キャリーが立つ、あるいは
    					;axに7100hが返ったら　ｃ＋　。
					;c==cf==0なら、キャリーが立っておらず
					;LFN OK.

INT 21 - Windows95 - LONG FILENAME - GET VOLUME INFORMATION
	AX = 71A0h
	DS:DX -> ASCIZ root name (e.g. "C:\")
	ES:DI -> buffer for file system name
	CX = size of ES:DI buffer
ax, dx, di, cxを与えないと、71A0hは機能しないと思います。

　とらじさんが書いているとおり、生ドスまで含めるとすると、axとCF（=r）の
両方を見る必要があるわけです。

Return: CF clear if successful
	    AX destroyed (0000h and 0200h seen)
	CF set on error
	AX = error code 7100h if function not supported <<<==== for MS-DOS★

とらじwrote:
>　int21_71A0 に限らず、拡張ファンクションコール一般だと
>　生ＤＯＳでは CY が変化しません。　ＤＯＳモードだと CY （キャリー、CFのこと）
>が立ちます。
>　で、どっちも ax$7100 が返ります。
　（エラーでどっちもax$7100を返すなら、CFあるいはrを見る必要さえないのかも。
でもＭＳがまずCFを見ろといってるのだから、(ax==$7100 || r)?が素直なんでしょう）


　ただし、 僕がＮＴ系Ｄｏｓ窓（WinXP）で見る限り、正しく機能していると思
いますが、command.com  を使い、ＮＴ系 Win7 上でエミュレータの VTDOS の中
でＶｚすると、どういう値が返るのかは分かりません。その辺に引っかかってる
のかもしれないですね……。

　PSP、了解です。(^^;

　おお、VTDOS そこまで来てくれましたかぁ。konno さんのアイドル願いが功を
奏したわけですね。ありがたや、ありがたや。
　ほんとうに、ありがとうございます。m(__)m

　やっぱり、Ｖｚが最高です。Windows 環境に馴染もうともしてるのですが。
　発見は、Vz+DOSがWin環境全体に匹敵してるということ（僕のようなテキスト
オタクには）。
　Win7マシンが来たら、すぐシェア登録します！

konnoさん

　意味なく、ブツブツしてます。でも、空想力で何とかなる話じゃないです、
明らかに。


>そのうえで、私の考えを伝えたいと思います。

　だいたい分かったような気がします。でも、最初にそれを言ってくださいよ。
このマクロは高橋版と  konno 版がＶｚ内部で採用してるＬＦＮ判定法の実験で
すって。
　VTDOS と絡んで、高橋版の判定法、konno 版の判定法を検証しようというので
すよね。

>> 　ファンクションコールのパラミータが足りてないんです。
>> 　つまり、rにLFN OK or NGの結果が返りません。
>これが文太さんの言いたかったことだと思いますが、それはつまり
>高橋版の判定が間違っていると言う事になりますね。

　僕は何かの間違いがあったのだろうとは、たしかに空想していました。
　しかしkonno版が同じであり、そして、何の問題も起こっていないとは知りません
でした。
　では、判定法自体には問題がないのじゃないのか、と考えてしまいます。

>> 　なぜキャリーが立つのかは謎です。どっかの無関係なｒのせい？
>私にとってはココが一番大事なところだったのです。
>なぜとか謎はどうでもいい、高橋版の判定方法の再現が目的のマクロなんですから。

　だから、最初にそれを言ってくれないと。
　とはいえ、僕には「dx, di, cx」がなくても判定できると高橋さんが考えた理
由は分かりません。com ファイルのあの状況では設定されてるのが前提なのかな
ぁ、と空想するぐらいです。
　言えるのは、Ｖｚマクロがあのファンクションをちゃんと機能させるだろうと
いうことです。高橋版でも（ちょっと VTDOS をおいておいて）、「dx, di, cx」
を設定したマクロなら、正しい答を出しませんでしょうか。やってなくて申し訳
ないのですけれど。

>> 　とらじさんが書いているとおり、生ドスまで含めるとすると、axとCF（=r）の
>> 両方を見る必要があるわけです。
>私も過去ログを確認しました。
>高橋さんは検証できる環境を持っておらず、とらじさんの情報をもとにVZのソースに
>LFN判定を追加したので、おっしゃる通り両方を見て判定していますね。

　はい。

>でも、とらじさんの言うMS推奨の判定法はパラメータがあったのか無かったのか
>過去ログを読んだだけでは私にはどっちと断言できません。

　僕に分からないのは、vzibmj.com があのＬＦＮ判定の場面で、「dx, di, cx」
を持ってないのかどうかです。どれも返り値用のワークバッファです。それを
利用する必要がないなら、明示的にでなくても、文脈的にここを指してると設定
されてるのが当たり前の状況なら、判定だけはできるのかな、とか。
　ま、分からないことだらけなんですけれど。

>そして、高橋さんはパラメータなしの判定法を選択しました。
>その結果として、NT系ではcfが立ってLFNモードが使えなかった。
>という背景があるので、私は高橋版にならった判定法にしてます。

　これについては、分かりません。
　がんばってください、これぐらいしか言えません。
　とはいえ、konno VZ on VTDOS on Win7で、行けてるんでしょう？
　テスタがいっぱいいる状況ではないので、きちんと検証したいものなのかな、
と思う一方で、でも僕だってもう１０年近くＸＰでＬＦＮをファイラで見てますよ。
特に問題があるように感じたことはありませんけれど……、とも伝えたい。
　よくは分からないけど、10#さん、としきさん、めざらさんは、ＬＦＮのファイル
を扱ってきたんじゃないでしょうか。

filer2.asm 423
;--- konno 8 R, filer2.asm 8371 bytes,  2003-12-15  23:40
		msdos	F_LFN_INF	;ax=71A0h	int 21h
;		jc	ng_lfn		;cf XP=1
;		jc	xp_cmp
;		clc			;clr cf

xp_cmp:		cmp	ax,7100h	; LX 
		jz	ng_lfn		; XP=007bh	lx=7100h
ok_lfn:		mov	al,TRUE		;al=1
		jmps	tstlfn7
ng_lfn:		mov	al,FALSE	;al=0
tstlfn7:	mov	cs:lfnflg,al
		tst	al


filer2.asm 423
;--- takahashi filer2.asm 8248 bytes,  2009-12-10  21:24, 嫌なタイムスタンプ
		msdos	F_LFN_INF
		jc	ng_lfn

		cmp	ax,7100h
		jz	ng_lfn
ok_lfn:		mov	al,TRUE
		jmps	tstlfn7
ng_lfn:		mov	al,FALSE	
tstlfn7:	mov	cs:lfnflg,al
		tst	al

　これもする気がなくて（だって  konno 版でいいじゃないか、と思う）申し訳
ないのですが、#6284 の正しいＬＦＮ判定マクロは、素ＸＰ（VTDOS でなく）の
高橋版、konno 版で正しい判定をするんですよね。
　僕は、あのマクロがちゃんと機能するように確かめることだけをしたかったの
です。  だって、最初ヴァージョンでは意味不明な AX が返っていたし、ver 05
では、 変数ＣとＬが意味不明な（win9x と winNT の違いを見る？？？）処理を
してたみたいだし……。

　明日、パラミータ不足な状態（高橋版と konno 版の状態らしい）での、Win9x
と WinXP の挙動を見てみます。パラミータ満足の状態でも。VTDOS の話は抜きで。

　すると、空想するに、パラミータ不足が高橋さんの誤判定の原因。
　しかし、konno版も同じくパラミータ不足。しかし機能してきた。
　不足してるのじゃなくて、暗示的に、前提的に設定されてるんじゃないのかな、
とも思う。あるいは、別のところにkonno版の勝因がある。その判定法をバイパス
します、とか？
　vz.comが正しくファンクションコールを伝えてさえくれれば、判定マクロとvz.com
は、同じようにカーネルからは見えているはずだよなぁ……。同じ結果を返す……。

よく分からない判定法の真偽の判定

=== test.def ===;
判定できるのかのテスト
* M
50 ^^ "test"

    ax$71a0,				;LFN vol
    &Sc(pa,pi,3) dx=pa, di=pa+5, cx=50,	;■コメントアウト、ココ
    &i($21) 
    l+, 				;<l> LFN flag。普通とおるもの（前提）
    (ax==$7100 || r)? l-,		;エラー時のみフラグを降ろす。
    &m("LFN=%d",l)			;l=1でオン、LFN OKの意味。

*

　これを使い■の行をコメントアウトする、 コメントアウトしないで、 konno 版、
高橋版で、WinXP と WinME で判定ができるかを試す。
　判定法が機能するなら、XPとMEなのだから、当然、「LFN=1」となることが期待
される。「LFN=0」と返ったら、判定自体ができていない、と判断するべきなんだ
ろう。XPとMEなので、LFNできるはずなのだから。
　このtest.defとvz.comを同等に扱ってよいのか、僕には分かりません。

　コメントアウトすると、 dx, di, cx は不定になると思うので、そのときの状
況によりけりで中身が決まっていると思うから、このテストに意味があるのか、
僕にはよく分からない。マクロの場合、マクロが動き出す時点で、Ｖｚが初期化し、
全部ゼロにクリアされてるものなのかな……。

　もちろん、VTDOSとは一切関係のない話です。


konno, k07t
takahashi, t03k

【コメントアウトなし】
	|  konno  | takahashi |
-------------------------------
XP	|  1      | 1         |
-------------------------------
ME	|  1	  | 1         |
-------------------------------

【コメントアウトあり】---下の結果を読み違えた結果、高橋さんがＮＴ系を
	|  konno  | takahashi |　を諦めた、というのは仮説として正しいの
-------------------------------　かもしれません。
XP	|  0 	  | 0         |　しかし、test.defがそもそも間違っている
-------------------------------　のなら、、、。
ME	|  1	  | 1         |
-------------------------------

　口だけですが、あとする価値があるように思えなくもないのは、dx, di, cxを
指定したfiler2.asmでアセンブルして、そのvz.comで【コメントアウトあり】を
XPで試す……？？？

高橋版の歴史（データ）

　ある意味では意味なく長いデータですが、お許しを。
　時間的にどの辺りで高橋さんが高橋版を開発し、多くの人が要望を出し、バク
レポをし、要望をほとんど越えて野望を皆で実現していったのか、その記録です。

　９８年の５月から９９年１２月まで。１年半以上。
　そのまえに、榊原版の逆アセ、そして自家版としての使用と、それなりに長い
自己検証の時期があったようです。

cgrep -A1 "\[Vz\] vzt" 16ish.log >kek.txt
　により抽出。ish部屋、16階ログより。その後、加工。

　さて、ＮＴの話はどこでしょう？
　ほぼ間違いなくVztの開発は、ＤＣ１５階で議論されたはずですが……。
　（この辺、「Vz Editorの歴史」−「版の詳細」にないんですね、ぐすん　＞めざらさん）

　以下で、内容メモは、かなり恣意的な抜粋です。もっといっぱいあります。
興味のある方は、オリジナル・ログにあたってください。


98/05/24    ＃01932       vzt01   #1
　　以下に欠番あり

98/06/14    ＃01962       vzt02a  #01
            ＃01963       vzt02a  #02
　　dos窓常駐（テスト）

98/08/01    ＃01989       vzt02a   ->  vzt02d  差分
　　LF+ : LFN 対応ファイラーなど

98/08/06    ＃01991       vzt02d   ->  vzt02e  差分
　　ファイラーコマンド #N #R #D は lf+ 時のみ LFNなど

98/08/30    ＃01998       vzt02e   ->  vzt02f  差分
　　裏テキストのステータスラインの色指定、モバギ &b() テスト（vb+）

98/08/31    ＃01999       vzt02f   ->  vzt02g  差分
　　&Vl &Vs は汎用変数 (a〜yy, ax〜di, r) の保存（スイッチは保存しない）

98/09/01    ＃02001       vzt02g   ->  vzt02g1 差分
　　sv+ 時、fa,fb...などのユーザースイッチを保存

98/09/08    ＃02007       vzt02g1  ->  vzt02h  差分
　　Is+ :ファイラーで「SHIFT+英字」によるインクリメントサーチ

98/09/17    ＃02015       vzt02h   ->  vzt02i  差分
　　FEP コントロールテスト

98/09/18    ＃02017       vzt02i   ->  vzt02j  差分
　　Nf+ : キーアサイン [NFER] を [無変換] キーで認識

98/09/30    ＃02025       vzt02j   ->  vzt02k  差分
　　FEP コントロールテスト

99/01/07    ＃02051       vzt03  #01
            ＃02052       vzt03  #02
            ＃02053       vzt03  #03
　　オリジナルより差分（ライブラリ版）

99/01/07    ＃02054       vzt03  ソース #01
            ＃02055       vzt03  ソース #02
　　オリジナル src.exe の解凍した、.asm .inc などからの差分

99/01/12    ＃02057       vzt03  j31
　　j31 版。オリジナルより差分

99/03/09    ＃02089       vzt03    ->  vzt03a  差分
　　Yp と Dw 追加、モバギ対応

99/03/18    ＃02101       vzt03a   ->  vzt03b  差分
　　文字列検索・置換バグフィックス、トレース窓拡張（要研究）

99/03/20    ＃02106       vzt03b   ->  vzt03c  差分
　　dos 窓で、メモアレエラー対策

99/03/21    ＃02108       vzt03c   ->  vzt03d  差分
　　文字列検索・置換バグフィックス

99/03/27    ＃02120       vzt03d   ->  vzt03e  差分
　　FEP 制御小改良、トレース窓

99/03/27    ＃02121       vzt03e   ->  vzt03e1 差分
　　FEP 制御が効いてない

99/03/28    ＃02123       vzt03e1  ->  vzt03f  差分
　　#G でテンポラリファイルエラー対策、&Sk()

99/03/30    ＃02126       vzt03f   ->  vzt03f1 差分
　　&Sk() から &Jn() へ関数名変更

99/03/31    ＃02127       vzt03f1  ->  vzt03f2 差分
　　#G でバグ、&Tz() 正式採用。

99/04/27    ＃02151       vzt03f2  ->  vzt03g  差分
　　&z() で EMS のマッピングが……、ec+ での検索・置換。漢字の２バイト目対策

99/05/04    ＃02155       vzt03g   ->  vzt03g1 差分
　　expr.asm にゴミ

99/05/18    ＃02156       vzt03g1  ->  vzt03h  差分
　　ディレクトリソート高速化

99/05/26    ＃02158       vzt03h   ->  vzt03h1 差分
　　#G にバグ

99/07/26    ＃02169       vzt03h1  ->  vzt03i  差分
　　#if (<expr>) 、&So() にバグ

99/07/27    ＃02170       vzt03a_s ->  vzt03is ソース差分

99/08/09    ＃02173       vzt03i   ->  vzt03i1 差分
　　vw-, にすると検索/置換に不具合

99/08/19    ＃02175       vzt03i1  ->  vzt03i2 差分
　　int24 内でメッセージがおかしくなっていた

99/11/30    ＃02192       vzt03i2  ->  vzt03j  差分
　　 dirchr (pq.336)、swchr (pq.337)をユーザーが設定可能に

99/12/02    ＃02195       vzt03j   ->  vzt03k  差分
　　メニューのアイテム数の自動識別機能追加、メニューの途中での #if 〜 #endif

99/12/11    ＃02198       vzt03k   ->  vzt03k1 差分
　　vzt03k のバグフィックス

99/12/21    ＃02203       vzt03k1  ->  vzt03k2 差分
　　コマンドラインの展開にバグ、「ygrep -% "開始"」->「ygrep -% "開晒"」 

高橋さんデータへの追記

　むかし似たようなことを調べたことがあったな、と。
　こんな歴史でした。すごい人でした。

やしきの板塀#01692
>01692/99999 TOS00000  文太            FMV Deskpower SII 165
>( 3)   09/12/31 13:00  01689へのコメント

【高橋さん的には、こんな時代】

sort.def 高橋版　　　　　　　　　　　　 97/10/06 23:29
vkeyc.com　　　　　　　　　　　　　　　 98/02/19 19:39
claudia.def　　　　　　　　　　　　　　 98/04/25 18:35
mz.def　　　　　　　　　　　　　　　　　98/04/26 19:10
stkmenut.def 海賊版　　　　　　　　　　 98/05/16 21:24
vzt01 #1　　　　　　　　　　　　　　　　98/05/24 19:14
vzt02a　#01　　　　　　　　　　　　　　 98/06/14 17:38
dseg.map　　　　　　　　　　　　　　　　98/09/02 19:24
cvt98c.com　　　　　　　　　　　　　　　98/10/30 19:29
vzt03 #01　　　　　　　　　　　　　　　 99/01/07 21:53
unasm.com　　　　　　　　　　　　　　　 99/01/23 18:10
JIS <-> sJIS　　　　　　　　　　　　　　99/04/10 20:12
vz で曖昧検索・置換　　　　　　　　　　 99/07/29 23:07
fuzzy v0.20　　　　　　　　　　　　　　 99/12/20 18:50
vzt03k1 -> vzt03k2 差分　　　　　　　　 99/12/21 19:45
vwx 高橋版 vwxt.com　　　　　　　　　　 00/01/06 19:56
　（この最後の日付でも、僕はまだＤＣデビューしてないはず。）

高橋さんの実験

　以下のように、高橋さん、ちゃんとパラミータを入れていましたよ。少なくとも
実験の段階では。

　要約すると、くらとさんがWinNTをお使いで、これでＮＧな結果だったのです。
　僕の想像は、WinNTからWin2K以降で、NTVDM.exeが拡張ファンクを受け入れる
ように改良された、というもの。
　うちのＸＰ機では、ＬＦＮ・ＯＫという正しい結果をレポートしてくれました。
　これで、謎の一部が解けましたでしょうか？

r=0 ax=71A0h di=NTFS	
キャリーなし、AXエラーコードなし、ファイルシステム・インフォあり、
　の正しい結果です。AXは破壊すらされていない。

　もちろん、 時系列からいって、Vzt にはすでに Win9x 用ルーチンが入ってい
てＬＦＮができる状態だったはずです。WinNT では、それらに引っかかって駄目
だったのではないでしょうか。
　うん、NTVDM.exeが改良されても、NT系はシャットアウトなコードがVztには
入っていて、konnoさんが付け加え、コメントアウトした部分のせいで、高橋版
がVTDOS on Win7でＬＦＮできないとしても、不思議ではないように思いますが。
konno版でできるのだから、いいじゃないですか。

　もし、ところがkonno版でもVTDOS環境だとＬＦＮ判定が変だ、ということなら、
それは僕の想像どころか環境の外のことになってしまいます。


　余計な蛇足：10#の過去の発言や、先日のWinUpdateでのＥＭＳ不具合（どうな
ったんだろう、あれは、その後？）を読んで、経験してみて思うのは、Ｄｏｓ窓
環境みたいなところにも、ホストＯＳの変化は、けっこう出るみたいで、NTVDM.exe
自体が更新されなくても、ホストＯＳやCMD.exeやVTDOS.exeの変化で、こういう
ところが変化することはあるみたいだ、とは思いました。filer2.asmだけに問題
じゃないだろう、ということです。

　何にも分かっちゃいないのですが。m(__)m


>12748/12751 HGD00133  高橋　洋光　　　 RE:VZ v1.6t on WinNT
>(15)   99/02/11 00:54  12725へのコメント

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

        dx"C:\",                ; ドライブ名は適当に変えて、
        ax$71A0, di=pr, di.0-, cx5, &i($21)
        &m("r=%d ax=%04xh di=%s",r,ax,di)
;        &?("r=%d ax=%04xh di=%s",r,ax,di)

*

konnoさん、決着をつけました。と思う。別アーティクルで。

>おお、キチンと、NTFSと表示されますね、DOS窓でもVTDOSでも。

        dx"C:\",                ; ドライブ名は適当に変えて、
　を
        dx"A:\",                ; ドライブ名は適当に変えて、

　にして、ＦＤＤ付きＸＰ以上マシンでやると楽しいですよ。
　そっかぁ。ＦＤにもＬＦＮファイル保存できるものなぁ、と。これが
このファンクションの本来の使い方だ、と。

71A0_INT21 について（まとめ）

　納得したのですが、ちゃんとした証明はできません。覚え書きです。

　結論０：WindowsとMS-DOS環境しかなく、MS-DOS環境だけ特定して除外すれば
よいのだから、ＬＦＮチェックは、実はものすごくゆるゆるでよい。

　結論１：将来どうなるか分からないけど（あるの？　将来）、konno さんが高
橋版にした処理は正しい。おかげでＸＰでＬＦＮが扱えるようになった。

　結論２：高橋さんはコーディングは、高橋版の開発時点では天才的だった。い
いのかよ、と思うやり方。しかし、目的だけを考えれば、あれで足りた。MS-DOS
をはじけばいいだけだったのだから。どこまで意図か、確信犯かは不明。運も良
かったんだろうと想像してます。Windows マシン持ってなかったんでしょう？



　まず、以下が71A0hの仕様。まあ、仕様というか。全然こうなっていない奴ら多数。

INT 21 - Windows95 - LONG FILENAME - GET VOLUME INFORMATION
	AX = 71A0h
	DS:DX -> ASCIZ root name (e.g. "C:\")　（注：-> はポインタの意味
	ES:DI -> buffer for file system name　　 考えれば分かるけど、リスト
	CX = size of ES:DI buffer　　　　　　　　の先頭に書いてあった。）
Return: CF clear if successful
	    AX destroyed (0000h and 0200h seen)
	    BX = file system flags (see #01783)
	    CX = maximum length of file name [usually 255]
	    DX = maximum length of path [usually 260]
	    ES:DI buffer filled (ASCIZ, e.g. "FAT","NTFS","CDFS")
	CF set on error
	AX = error code 7100h if function not supported <<<==== for MS-DOS★

　前提：ファンクションコールは、コールを受ける MS-DOS カーネル（エミュレ
ータ含む）によって反応、処理が違う。このファンクションの場合、けっこう酷い。
拡張ファンクションなんて、どれもそんなものなのかな。詳細は下の表で。
　しかし（功を奏したのだけど）、エラーならちゃんと一貫してキャリーを立てろ
よなぁ、とも思う。

　このファンクションを正しく機能させるためには、４つパラミータをセットし
なくてはいけない。
　しかし、win or not の判定では、実は、高橋法で用が足りる。 少なくとも
ＸＰ以前では、足りた。

　高橋法はパラミータをＡＸだけセットして、コールする。そして、キャリーフ
ラグとＡＸに 7100h が返ったかどうかを両方チェックする。 どっちかがエラー
を通知したら、MS-DOS だ、と判断。
　本来のファンクションコールの使用法という意味ではむちゃくちゃです。対象
ドライブが設定されていないのだから（GET VOLUME INFORMATION です）。 もち
ろん、DI は返らない（ありがたい）。 しかし、Win と MS-DOS においては、か
ろうじて、どっちの種類のＯＳであるか（本来的にはＬＦＮが効くかどうか）の
結果を知ることはできる。
　（むちゃくちゃとはいえ、やはり世界中で、Ｃでパスカルで、使われていた。）

　ＡＸに  7100h が入ればエラー扱いにし、キャリーが立ってもエラーにする高
橋法。 実際には、MS-DOS 環境において、MS-DOS6.2 カーネルの仕様でキャリー
は立たない（脱線：このカーネルは拡張ファンクが誕生する前に書かれた。だか
ら、変なコールが来たら、7100h をＡＸに返すよう予めつくってあったのでしょ
うね）。でもキャリーは立たなくても、ＡＸでひっかかってくれる。

　しかし、ＸＰの登場で、困ったことになった。ドライブ名すら設定されてない
のに、ＡＸは変だけど、ＸＰはちゃんとキャリーを返すのです。やはりＮＴ系は
駄目なのか……。じゃ、 このキャリーチェックを外してしまえばいい、と
konno さんは考えた（勘かもしれないけど）。外した。うまくいった。目出度し。
２つあったチェックを１つにしてしまったのです。だって元来、MS-DOSだけが
それに引っかかれば良いチェックだったのですから（ＮＴ除外）。
　つまり、ＸＰでは完全スルーなのです。でも、いいの。ＸＰならＬＦＮできて
当たり前なんだから。ＬＦＮしかないとも言えるＯＳです。

　因みにＮＴは、7100h を返してしまいます（くらと談）。ＬＦＮの仕様が違っ
たのか、ＬＦＮアダプタの仕様が違ったのか、ＮＴ内エミュレータが馬鹿だった
のか。Win2K については実験していないので分かりませんが、チェックをゆるめ
た konno 版ならＬＦＮできたような記憶もあります。 ただし、ネットの情報で
は、ＮＴと同じく２０００も、7100h を返してしまう。つまり、これが本当なら
konno 版さえＬＦＮ表示をできないことになる。そんな報告もあったようです。
　（ということは、理屈だけだけど、Win2KでどうしてもＬＦＮ付きＶｚが使い
たくて、Win2K環境でしか使わない、つまりMS-DOSでは使わないvz.comでよいのな
ら、あのチェックルーチンを全部殺してアセンブルすればできる。しつこいけど、
MS-DOS除外があのルーチンの意味なので。ま、そうであっても、他の罠がありそ
うだけど。）


　さて、実験マクロ。

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

	ax=$71a0,
	dx="c:\", di=ps, cx=5, 	;◆高橋仕様はこの行コメントアウト
	&i($21)
	&m(" AX=%04xh CF=%d",ax,r)
    				;AX=error code, 7100h only meaningful
    	 			;r=carry flag
*
　仕様そのままの、素直なファンクションコールです。 オリジナル c.mos 版は
試してませんが、このファンクションコールはＶｚの版の影響を受けず、そのま
ま結果を出してくれます。Ｖｚにおけるファンクションコールとはそういうもの。

　注意点は、高橋仕様で◆の行をコメントアウトするとどうなるか、というとこ
ろ。結論は、もちろん、それでも win or not の判定はできる。

　ＡＸの返り値はふつう破壊されます。決定的なところでだけ、7100h のエラー
コードが返ります。少なくともMS-DOSでは返ります。

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

フォーマット
OS:	diの処理（文字列が返るか返らないか）
	(1)◆の行なしの場合＝コメントアウト（高橋法）
	(2)◆の行ありの場合（正しいファンク記述法）


XP:  	di返るときあり　^QF (#F)で見て、入ってるよ＠ＸＰ。
	(1)AX=non7100h 	CF=1 	AXは破壊されているが、少なくとも7100hでない。
	(2)AX=non7100h	CF=0	が、CFは立ってしまう、困った-->CF checkを外せ

ME:	di返らず
	(1)AX=non7100h	CF=0　　エラーが存在しない。エラーを示す必要がない。
	(2)AX=non7100h	CF=0　　示せない。つまり、エラーチェックの存在意義が
				ない。じつは。失敗することができないのです、
				コードが間違っていてさえ。

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

DOS:	diもちろん返らず
	(1)AX=7100h	CF=0	エラー検出法はＡＸのみ
	(2)AX=7100h	CF=0

　読めましたでしょうか？　MS-DOS ではＡＸしか判断の根拠がないのです。 だ
から、これだけ残せばいい。上の３つ共通で使える vz.com では、キャリーを判
断材料に入れるわけにいかないのです。ＸＰでは、正しくキャリーが立ってしま
うから。しかし、ＸＰでもＭＥでも、そもそもこのエラーチャックの必要がない
（だってＬＦＮできるにきまってるじゃん）ので、余計な正しさは要らない、と
いうわけです。
　（ここでのＸＰにとっての正しさとは、「ＬＦＮできない」ではなく「コール
の仕方が間違ってるよ」というものでしょう。）

　僕は、 di の示す場所にＮＴＦＳ、ＦＡＴ３２、ＦＡＴなんて文字列を勝手に
書かれたらやばいじゃないか、書いていい場所を指定しないなんて野蛮じゃない
か、と思ったのですが、ファンクションに失敗したら、返せない。また高橋法の
３つパラミータはずしをしたら、ファンクション自体は失敗するけれど、エラー
コードだけは返してくれる。di はやっぱり書かれません。ココ、MS-DOSの場合の
み。

　ＭＥではファンクションに成功してさえ（パラミータ４つ）、文字列を返さな
いみたいなんだけど。これ、バグでしょう？　でも、ありがたいバグ。要らない
から。
　考えてみたら、文字列で返されてもメッセージくらいにしか使えないから、デ
バッグ用なのかしら、とも思う。


　なお、 マクロ内のドライブ指定（dx="c:\",）を、"a:\" とかにすると、本来
の使い方をする場合（コメントアウトなし）、ＦＤＤにアクセスします。"b:\"
とかするとＭＥの場合、マシンが落ちます。 モバで "c:\" とすると（"a:\" で
なければいけない）、システムがぐちゃぐちゃになります。

　これは余談ですが、高橋仕様をいつか正しくしてやろうとか一瞬思ったのです
が（できないよ）、意外に難しい。ああ、低レベル。マシンによって対象ドライ
ブを選ばなくてはならない。compath からどっかのバッファにコピーして削除し
て（di="c:\vz\" は駄目なので）と思ったけど、できませーん。di を捨てるため
のゴミ捨てバッファも探さなくちゃいけない……。セグメントが分からないと、
デバックコードが入れられないと、何もできません。
　でも何もする必要がないんです。

　言うまでもなく、ブラウンリストはＭＳの「仕様」ではありません。
　ファンクションコールのＭＳの仕様って公表されてないんですよね？？？
開発者キットみたいなのにはあるのかな？
　まあ、コールの機能の一部だけを使ったときどうなるか、なんて、仕様書に
書いてあるわけないと思うけど。

としきさん、

>生DOSではUSBメモリが使えませんから、FDDかMO、または
>メモリカード経由のときだけなのです。すると今度は、Winなマシンでそういった
>メディアを使うことが難しいといった理由からデータのやり取りの頻度が著しく
>落ちてしまったのですよ。

　これは現実的にそういうものなんですよね。だから、MS-DOSから無線ラン。
　試してるでしょうけど、ＵＳＢに生ドスからのアクセスは可能な場合がありますよ。
　うまくいく場合には、config.sysの交換とリブートでできます。2GB以下のＵＳＢ。
　512MBでも駄目な場合は駄目。マシンというかチップとの相性問題ですが。
　あ、LFNアダプタとの相性もありそうだ。USBドライバはそれほどメモリを喰ったり
はしませんけれど。

>高橋さんの方法はLFN判定の標準的な方法だった（konnoさん）
> ＤＯＳとＷＩＮ環境の差異の判別に使うのはＣもパスカルも同じです。ただ、３つ
> のパラミータを除外するという方法が、標準的手法だとは僕は確認していません。
（文太）

としきさんwrote:
>標準というのがデファクトとしてという意味ならkonnoさんの表現も一理ある

　１つのパラミータ指定法という意味ですか？　いちおう１パラメータ法のコー
ドをネットで探したのですが、見つかりませんでした。一昨日ぐらいまでは、別
のファンクションでやれなのかなぁ、と考えていた。
　ブラウンリストの  71A0h 部分をじいっと見たのですが、ヒントのかけらもあ
りませんでした。
　『Windows9xのＤｏｓの秘密』の著者吉野さんが、71A0.exeをソースとともに
公開していて、使い方のサンプルを提供していましたが、元来の使い方のサンプル
でした。

>コマンドラインに降りて、dir[RET]と叩くだけです。

（非常駐）
C:\PROGRA~1>dir

ADOBE        <DIR>     12-04-21   21:01
ALMAIL32     <DIR>     12-04-18   20:54
APSOFT       <DIR>     13-01-27    0:40
ARCHIV~1     <DIR>     12-04-18   20:47

（常駐）
C:\PROGRA~1>dir
2012/04/21  21:01    <DIR>          ADOBE
2012/04/19  14:59    <DIR>          ALMAIL32
2013/01/27  00:40    <DIR>          APSOFT
2012/04/18  20:48    <DIR>          ARCHIVERDLL

　なるほど。これ、おいしいじゃないですか。素晴らしい仕様。
　上の昔風のほうが見やすいと思うけど。何で順番を変えるんだ＞ＭＳ
　>command /cdirは知ってます、覚えています。

>ちなみに、私の経験でも、Win2kではVzでLFNが使えていました。

　はい、書き方が悪かったのですが、僕の記憶もそうでした。以下の記憶もあてに
なりませんが、 ネットのどこかで「NT と同じく Win2K も 7100h を返す」と読
んだんです。Vzerの報告ではありませんし、そういうこともあるのか、と思った
だけです。
　スルーしてください。我々に実害のない環境のことに思いを馳せても仕方あり
ませんし、そもそもその人が報告が間違っていた可能性も高いと思います。
　そのあと、ちょっと調子に乗って空想しただけです。
　Win2Kにあまりいい思い出はありませんが、最近Win2Kマニュアル・ネットワーク
編みたいな本をBookOffで次々ゲットしてます。\100なので。外れも多いけど。
　あ、ＥＭＳ問題で悪い思い出があるんだ。

>きちんとLFNに対応させたい、というのが高橋さんの意図だったと考えています。

　はい、 皆 Windows を使っていてＬＦＮな時代に突入していたので、いい加減
なやり方をしているつもりはなかったはず、という意味では、１ミリの疑いもあ
りません。ただ、ミスはあったかもしれない。すぐ発覚するだろうから、という
感じも。
　でも、嫌だ嫌だと言いながら、とらじさんと実に楽しそうにやり取りしてました。
　あ、横のものの縦読みですが。

>コードが膨らむからなぁ。高橋さんは嫌うだろうなぁ。

　これはものすごく嫌がってました。 しかし Windows が、拡張ファンクが要求
するバッファの量と比べたら……。比べても意味ないでしょうけど。

>ところで、MEでも、USBフロッピーなんかをつないできちんとＢドライブを設けて
>やれば、マシンが落ちないですむのですよね？

　美風呂ぐらい古いマシンだとＵＳＢ・ＦＤはＢドライブには入りませんが
（Ｆ：だった）、もちろん、マシンは落ちませんでした。

　　#20555 Toshiki
CF:0 ax:0000 bx:4006 				;PC-9821As(6.20) +DOSLFN --*
　和生リストに追加して眺めました。ほんとにできるんだ。(ﾟ-ﾟ)

> 　問題のネックは、パラミータが４つか１つか、１つで機能するのか、というこ
> とになりましたよね

私はパラメータ１つで機能するのを確認しているので問題とも思っていませんよ。


> 　パラミータ１つの高橋法と同じようなのをＣとパスカルで探したつもりなので
> すが、−−少なくともこのファンクションを使ったコードの一部があったような
> 記憶だった−−見つかりませんでした。

MS推奨の元ねたは清十郎さんでしたね。

「長いファイル名の基礎講座 第一回〜第九回」
http://www.vector.co.jp/soft/dl/data/prog/se044198.html

この中のLFN_TUTの320行目
----------------------------------------------------------------------
　従来のリアルモード MS-DOS のように長いファイル名をサポートしないシステム
はダウンレベルシステムと呼ばれます。Windows95 と、ダウンレベルシステムを
組み合わせて使うのに、以下のようなロジックがＭＳから推奨されています。

;"""""""""""""""""""""""""""""""""""""""
;	Down Lebel System Function
;"""""""""""""""""""""""""""""""""""""""
DLS_FUNC	MACRO	func
		LOCAL	skip0, skip1
	stc
	mov	ax,7100h+func
	int	21h			;;LFN拡張ﾌｧﾝｸｼｮﾝ

	jc	skip0
	cmp	ax,7100h
	jne	skip1
skip0:
	mov	ah,func
	int	21h			;;MS-DOS標準ﾌｧﾝｸｼｮﾝ
skip1:
ENDM

-------------------------------------------------------------
これですね。

ついでに、「いきちがいのぷろぐらむあ」さんの
「2009-12-24[木] mg.exe LFN対応」
http://www.6809.net/tenk/?cmd=calendar2b_viewer&mymsg=%E9%9B%91%E8%A8%98&date=2009-12

オプション指定せずとも dos環境がLFN対応しているかどうかを判別するように修正してみた.

 といっても、ax=71a7h; int 21h (win32なファイル時間をdosファイル時間に変換するLFN用システムコール)を実行してみて、エラーがax=0x7100になるかどうかを 見てるだけ. 
 (※I/Oアクセスが発生しないLFNシステムコールならなんでもいい)


という記事がありました。違うファンクションですが、同じ事ができます。
これがMSDOSの仕様だからです。

> 　もっと正確につっこんでしまうと、 このパラミータ１か４か問題を konno さ
> んは、10# さんに解決あるいは解説してほしかったのかな、と考えています。

なぜそう思うのかが理解できませんね。私の発言は、95/98とXPで違いがあるので
TVZ用に（つまり95仕様に）対応する気が無いか聞いてみただけです。

> 僕が  konno さんのスキルレベルにあったら、４つのパラミータを入れた Vz を
> アセンブルして、理由を説明して（たぶん）、としきさんとめざらさんにテスト
> をお願いしちゃっていたと思うけど。

テストはマクロでできるじゃないですか。どんな環境でも問題が出ないのであれば
そのままVZに入れられますよ。
私より上のレベルの人は誰もそんな無駄なことはやらないと思うけど。

> ＬＦＮできる環境なんだから、チェックがなくてもいい。これぐらいです。

これは駄目です。XPのDOS窓は混在しているからチェックがないとぐちゃぐちゃになります。

> 　思い出したのですが、konno さんは、このＮＴ系ＬＦＮ実現の方法と有効性に
> 関して、いつも「よく判らない」と口を濁して回答してましたよね。

これは私の口癖ですね。不安に感じさせていたのなら申し訳ない。

konnoさん

>システム側はパラメータが不正でないかのチェックはしてるから、不正だったら
>キャリーが返るでしょう。

　そうなりそうなものですが、ＭＳはちゃらんぽらんだった。２重に。キャリー
は結局あてにならなかったし、パラミータ不正もチェックしてなかった。
　ファンクションコールのパラミータを一部省略する技って、公認の技なんですか？

>その場合はi/oアクセスはしないで戻る。

　この部分はかなり納得できます。

>> 　なぜ、TVZ用が必要だと思うのでしょう？　KVZはTVZの進化形なのに。
>もちろん私には必要ありません。使いたいという人がいるかもしれないと
>思っただけです。

　なんでそう思うのですか？　笑い。も、もしかして、それ、再履修の僕？
　正直いって気持ちが分からないです。Ｖｚを卒業したいって感じなんです
かね。僕には、それが少しあります、はい。
　ただ、さっきちょっと変なマクロを書いたのですが、こんなカーソル飛ば
しまくりのマクロを別のエディタですらすら書けるようにはならないか、な
れたとしても相当時間かかるなぁ、と実感しました。
　#^ == GoTopofFile　英語といっても、コマンドとその記述法がスラスラ出
てこなければ、書き終えることなんかできない……。

追記

清十郎さん資料、741行目付近
	mov	cx,5
	lea	dx,[di].VI_RootName
	MSDOS	71a0h			;ﾎﾞﾘｭｰﾑ情報の取得

　ファイル検索の前処理です。ＬＦＮが可能な環境かのチェック。
　やっぱり、裏技だったんじゃないのかなぁ、という気がしてきました。
　運が良かった？
　動けば正義で、真偽の知りようのない話だとは思うのですが。いっぱい
テスターがいる、仲間がいる、というのはものすごい安心感だったでしょうね。


　また、拡張ファンクションについて真面目にちょっとでも勉強すれば、当たり
前になることなのでしょうが、ブラウンリストにこのような記述がありました。

INT 21 - Windows95 - LONG FILENAME FUNCTIONS
	AH = 71h
	AL = function
	    0Dh reset drive (see AX=710Dh)
　以下、略　だだだ、といっぱい。

Return: CF set on error
	    AX = error code (see #01680)
		7100h if function not supported
	CF clear if successful
	    other registers as for corresponding "old" DOS function
Notes:	if error 7100h is returned, the old-style function should be called
	AX=714Eh returns a "search handle" which must be passed to AX=714Fh;
	  when the search is complete, AX=71A1h must be called to terminate
	  the search
	for compatibility with DOS versions prior to v7.00, the carry flag
	  should be set on call to ensure that it is set on exit

　総論的まとめの記述で、拡張ファンクションがサポートされていなければ、AX
に 7100h が返る（7100h で検索すると、みな書いてある）。 いつでも、そうだ
そうです。

　で、Notes のところの最初が、まさしくダウンレベルの推奨されるやり方でし
ょう。
　ここでも、FindFirst が例。前後の繋がり不明。ないと思う。

　ブラウン文書、僕には文頭の大文字とピリオドの使用がないので、しばしばま
ごつくのですが、最後の２行の意味は、大事なことが書いてありそうなのに、分
かりませんでした。
　「Dos7  以前との互換性のため、終了時にキャリーが必ずセットされるよう、
ファンクションコールを呼ぶときにはキャリーフラグをオンにしておくこと」と
解釈したけど、訳が分かりません。まったくの誤訳だという確信があります。や
れやれ。

　ＡＸだけはちゃんと返ってよかったなぁ。95+NTでＶｚが動いてきたもの。多謝
です。v(^^)z　Win7/8については語るまい。

;--- from std.inc by Takahashi

msdosl 	macro	cmd,prm
	local dls,dls2
	stc			;set carry == compatibility with before 7.0
	msdos	71h,cmd
	jc	dls		;for downlevel system, necessary, but ....
	cmp	ax,7100h	;MS couldn't afford to break this 
				; for that system.
	clc			;clear carry ==
	jnz	dls2
dls:	msdos	cmd,prm
dls2:
 	endm

;--- from std.inc by Takahashi

msdos	macro	cmd,prm
if cmd lt 100h 			;less than
  ifb	<prm>
	mov	ah,cmd
  else
	movhl	ax,cmd,prm
  endif
else
	mov	ax,cmd
endif
	int	21h
	endm

;--- from filer2.asm by Takahashi: msdosl not used
;うん。全部ダウンレベルでやってしまえば簡単なんだけど・・・。
;そうも行かないだな〜。イヤンなちゃう。(DC 15, ＃10286)

		movseg	ds,ss
		mov	dx,curdir	;<dx>
		clr	cx		;<cx>
		stc			;set carry
		msdos	F_LFN_INF	;F_LFN_INF equ 71A0h (ax,dx,cx,di
		jc	ng_lfn		;! del by konno　↑required but no di!)
		cmp	ax,7100h
		jz	ng_lfn
ok_lfn:		mov	al,TRUE
		jmps	tstlfn7
ng_lfn:		mov	al,FALSE


　パラミータは４つでなく３つでＯＫでした。上が最大限の裏技なのかもしれ
ません。

konnoさんwrote:#6290
>これが文太さんの言いたかったことだと思いますが、それはつまり
>高橋版の判定が間違っていると言う事になりますね。

　いえ、すいません、もともとの konno さんのマクロがバグってました。 高橋
法は３つのパラミータで cx ゼロです。文字列を返させない。これで機能するこ
は確認したのでしょう。
　konno  さんのミスは、 結果オーライだったのですが。  古くは、DC 15, 
＃20204 からです。
　結果を和生さんが＃20543 でまとめてくれています。が、和生さんが作り使
ったマクロ（「文献に従ったマクロ」 ＝４パラミータ）も「DS:SI=root name」
でバグっていて、追加の和生情報も１パラミータと同じです。

　その条件を頭にいれて結果一覧（多謝です＞和生さん）を眺めてみてさえ、
Win95の挙動がものすごく不思議です。 それでも、どのようなエラー・ミスにせ
よ、AX=7100hをＭＳは死守してくれました。ここが壊れると、ダウンレベル・シ
ステム全体が崩壊するので、さすがにレガシーとかエミュレータとか言ってられ
ないからでしょう。拡張ファンク共通でもあり、MS-DOSはそれしか通信手段を持
たないからです。
　４パラミータの場合でも、キャリーの意味は、コールを受けるＤｏｓカーネル
によって違うみたいです。無視が一番。

　純ドスでは、もちろん71xxを含む拡張ファンクは、はなから無視です。dx="b:\",
でも落ちません。パラミータの数も関係ありません。axはもちろん要るけど。

　少し全体が見えたみたい……。

konnoさん

>文太さんのマクロのcxをゼロにしても、cf0 になるみたいですが、
>何か間違えてます？

　と思います。どのマクロでしょう？　どう改造したらいいのでしょう？

　これが正解のはずですが。

	mov	dx,curdir	;<dx>
	clr	cx		;<cx>
	msdos	F_LFN_INF	;F_LFN_INF equ 71A0h (ax,dx,cx,di

>ここまできたら、XPでTVZがLFNできない真相を文太さんにあばいてもらいたいですね。

　真相は、コードの形で１０年くらい前にkonnoさんが明らかにしていたはずですよ。
　03/07/18あたりのことだったはずですが。

#06270
ax$71a0,&i($21) l=ax,c=r,		;LFN vol

　これは高橋さんの　--- if LFN ---　を再現していません。これだけです。
　僕はこれを最初みて、「もし LFN なら」と読んで、「LFN かどうか」なんだ、
と思い、自分の英語力の拙さを恥じました。繋がってたんだ、と（この段落、ま
ず通じないだろう余談です）。
　あとは沈黙。(c) Hamlet

=== Macrotmp by B ===;
高橋版(T)とkonno版(K)の違いを見る：なぜkonno版はＮＴ系でＬＦＮが可能なのか。
前提：このマクロがどの版のＶｚ上で使われるかは問題にならない。
　オリジナルc.mos版上でも、同じ結果を出す。マクロの中のファンクションコール
　とそのＶｚがＬＦＮに対応しているかは別の話。
　　：キャリーはDOS, 9x, NTでまちまちで判定に使えない。
　　：AX=$7100のみで判定すべき（XPが主流になるまで、問題が発覚しなかった）。

* M
50 ^^ "Macrotmp"

	dx=pd, cx-,		;get volume info (vol info は要らないが)
	ax=$71A0,		; -> LFN, OK or NOT を知るために
	&i($21)			; このファンクションを使う。
	p="OK",			; この部分、(T)(K)共通。違いは以下のみ。
;	(ax==$7100 || r==1)? p="NG",	;(T)
	(ax==$7100)? p="NG",		;(K)
	&m("LFN %s",p)

*

---------------------------------------------------------------------------
（おまけ）

高橋版ＬＦＮ関係（資料）

　ちゃんと集中してればすぐ調べられるはずなのだけど、すぐ忘れるので。
　ダウンレベルが話題になったついでです。
　modoslの高橋ラベルdlsは、down level systemの意味。

>11186/11205 xxxxxxxx  高橋　洋光　　　 RE:vztx9
>(15)   98/07/18 19:20  11179へのコメント  コメント数：1

>  　vzt  の #R #K #N のファイラーコマンドは、lf のオプションに関係なく、
>  拡張ファンクションコールを発行します。拡張ファンクションコールが対応
>  してなければ、通常のファンクションコールになります。

（ダウンレベル不可だったもの）

filer2.asm      423:		msdos	F_LFN_INF
filer2.asm      452:		msdos	F_LFN_GETFULLPATH
filer2.asm      503:		msdos	F_LFN_FINDDIR	
filer2.asm      511:		msdos	F_LFN_NEXTDIR
filer2.asm      524:		msdos	F_LFN_FINDCLOSE

文太さん、確認用のマクロをありがとうございます。

私も昨日作ってたんですが、セーブしたと思ったのがされてなくて。
VTDOS135+CKWV環境なんですが、普段使ってないマクロを使ったりしてちょっと
おかしくなっていたかも。あるいは何か勘違いしていた？

> 高橋版(T)とkonno版(K)の違いを見る：なぜkonno版はＮＴ系でＬＦＮが可能なのか。

と言いながら、高橋版の判定部分がコメントになっていますね。(^^;
tVZの結果も表示するようにしてみました。

	(ax==$7100 || r==1)? t="NG",	;(T)
	(ax==$7100)? p="NG",		;(K)
	&m("LFN %s tVZ=%s",p,t)

LFN OK tVZ=NG　と表示されました。バッチリです。

> 	dx=pd, cx-,		;get volume info (vol info は要らないが)

pdがカレントDIRだったですね。すっかり忘れてるし。

> （ダウンレベル不可だったもの）

ファンクションの番号が分からないので、番号追加して見ました。

> filer2.asm      423:		msdos	F_LFN_INF         71a0h
> filer2.asm      452:		msdos	F_LFN_GETFULLPATH 7160h
> filer2.asm      503:		msdos	F_LFN_FINDDIR	714eh
> filer2.asm      511:		msdos	F_LFN_NEXTDIR     714fh
> filer2.asm      524:		msdos	F_LFN_FINDCLOSE   71a1h

　自分あてです。
　後日、僕はぜったいこの話の流れを読みとれないだろうから。
　あのマクロは、結果をメッセージすることにそれほど意味がないのです。

　高橋版、konno版の１行の違いを、ＸＰでＬＦＮの可不可を決定した
運命的な１行の違いを、そのコードを確認するための、マクロだったのです
（パラミータ３つの意味の確認も、少しありましたけれど）。
　いちおう対照表にしました。ジャンプラベルは見れば分かるので再現の
努力をしていません。

;--- Takahashi
	mov	dx,curdir	;dx=pd,
	clr	cx		;cx-,
	msdos	F_LFN_INF	;ax=$71A0, &i($21)
	jc	ng_lfn		;(r==1)?   === CARRY CHECK ===
	cmp	ax,7100h	;(ax==$7100)?
	jz	ng_lfn		;
ok_lfn:	mov	al,TRUE		;p="OK",
	jmps	tstlfn7		;
ng_lfn:	mov	al,FALSE	;p="NG",
tstlfn7:

;--- konno
	mov	dx,curdir	;dx=pd,
	clr	cx		;cx-,
	msdos	F_LFN_INF	;ax=$71A0, &i($21)
;	jc	ng_lfn		;   === NO CARRY CHECK ===
	cmp	ax,7100h	;(ax==$7100)?
	jz	ng_lfn		;
ok_lfn:	mov	al,TRUE		;p="OK",
	jmps	tstlfn7		;
ng_lfn:	mov	al,FALSE	;p="NG",
tstlfn7:

　たった１行のコメントアウトですが、これには、konno さんの素晴らしい勘の
さえと（Win98 上の高橋版でさえ、ＬＦＮができなかったことがあったはずなの
です）、きちんきちんとデータを集計した和生さんの努力が必要だったのだとも、
書いておきたいと思います。

　途中いくつもの間違いがありました。それでも最後に、Ｖｚの神様が微笑んで
くれたんだとも、僕は少し思ってます。１０年も前に。Windows でＶｚしてる以上、
ＬＦＮが見られたら、やっぱり「まだまだネイテイブ」という感覚をくれますもの。
そうでなかったら、今日、僕はこんなことを、16ビットのMS-DOS用エディタで書い
ていないでしょう。

> 　というわけで、少し思い出していただけたようで何よりでした。

もう毎日が再履修みたいになってますね。(^^;

> 　だから、VTDOSが高橋版に対応する必要はあまりないでしょう？　

改造作者としては動作検証用に起動するだけですから、LFNはあまり関係ないですがね。

ということで、tVZ仕様準拠のvz_env.def ｖ06です。

=== vz_env.def v06 ===

*m
80 ^^ "vz_env6"                         ;Win7のDOS窓では'\'が入力できない(>_<)

    dz[=pn..15~-1,b=0., dz],            ;mcb　ZはOK、Mは要注意
    ax$3000,&i($21) d=ax%256, e=ax/256, ;DOS ver
    ax$71a0,                            ;LFN vol
;   &Sc(pa,pi,3) dx=pa, di=pa+5, cx=0,  ;★toraji, bunta ※
    dx=pd, cx-,         ;get volume info (★bunta tVZ仕様)
    &i($21) c=r,a=ax,                   ;★CFは生DOS、Win95系では立たない
    l-,(ax!=$7100)? l+,;                ;lfn=1  ※ NT系ではcfが立つ
    ax$1680,&i($2f) i=ax,               ;idle call
    i-,(ax!=$1680)? i+,;                ;idle=1
    (ks&1)?>p                           ;Shift起動で書き出し
    dz[=vz,                             ;psp VZ起動文字列 (違う時は要注意)
#if tVZ
    &m("psp=%Fs  mcb=%c  Ver=%d.%d  LFN=%d ax%x cf%d  idle=%d",8,vz-1,b,d,e,l,a,c,i)
#else                                   ;tVZ以前の場合はVZ.COMの先頭
    &m("VZ=%s mcb=%c  Ver=%d.%d  LFN=%d ax%x cf%d  idle=%d",$102,b,d,e,l,a,c,i)
#endif
    dz], .
:p                                      ;カーソル位置に書き出し
    dz[=vz,                             ;psp VZ起動文字列 (違う時は要注意)
#if tVZ
    &?("psp=%Fs  mcb=%c  Ver=%d.%d  LFN=%d ax%x cf%d  idle=%d",8,vz-1,b,d,e,l,a,c,i)
#else                                   ;tVZ以前の場合はVZ.COMの先頭
    &?("VZ=%s mcb=%c  Ver=%d.%d  LFN=%d ax%x cf%d  idle=%d",$102,b,d,e,l,a,c,i)
#endif
    dz], .

;v06    文太さん改、tVZのチェック仕様を再現。
;v05    シフト起動でカーソル位置に書き出し、表示変更。
;v04    文太さん改2　ちょい変更
;v03    文太さん改　カーソル位置に書き出し、表示変更。
;v02    LFNとidleを追加。
;v01    vzinfo.defからMCBとPSPを抜き出した。

*

konnoさん（というより将来の自分へ）

>ということで、tVZ仕様準拠のvz_env.def ｖ06です。

　ふと思ったのですが（しつこくて申し訳ありません）、71A0hファンクションの
使い方という意味では、kVZのものでもあります。差異はありませんから。

　また、LFN、idle使用可能不可能の環境判定結果という意味では、kVZでの判定
結果ということを意味するはずです。
　後々、僕は分からなくなりそうなので書き添えておこうとしているだけなのです
が。

　このマクロはＶｚが置かれる環境を示します。どの版のＶｚ上でこのマクロが
実行されているかは関係ありません。このマクロが示す環境において、c.mos版、
高橋版、konno版（榊原版やちゅーぱっち版を入れてもいいです）でその環境へ
の対応・処理が違う。違いはこのマクロからは見えない。対処処理の結果という
意味での使用可能不可能は、konno版での結果です。LFN、idle。

　c.mos版 on XP での結果は以下です
（EmsMagic使用でないと、XPでは普通こうなるはず。axの値だけ違うかも）。

VZ=VZ1.60  mcb=Z  Ver=5.0  LFN=1 ax007Bh cf1  idle=1

　しかし、c.mos版で、LFNやidleが可能かといえば、そんなことはないわけです。

　そういう意味では、LFN=1、idle=1は、Ｖｚが置かれている環境以上に、konno
版での使用可能不可能を示しています。

　LFN=1 は、konno 版処理の結果です。konno 版なら使用可だけれど、高橋版
on XPでは不可です。on WinMEでは、高橋版でも表示のとおり可ですが。idle=1 
についても、お宅さまは使用可能環境にありますが（純ドス以外そうなるはず）、
それがお使いの版のＶｚで使えるか、というと、「使える」を意味する「1」は、
konno版において、という意味になります。

　「環境」に２つの意味があるわけです。Ｖｚがおかれる環境（dos, 9x, NT, VTDOS）
と、環境の一部であろうＶｚの版。

　可不可の判定は（LFN, idleの結果が、1なのか0なのか）、konno版において、
という意味なわけです。

　konnoさんにこれを伝える意味はまったくありませんが、普通にＸＰでＶｚする
なら、上の意味もあって、今時、konno版以外にありません。実験研究以外の用途
では。Vista以降でVTDOS上なら、なおさら。


　追記：キャリーについて。判定から排除するのでどうでもいいのだけど。

;★CFは生DOS、Win95系では立たない
;lfn=1  ※ NT系ではcfが立つ
　にコメント。ややこしいです。

生DOS		通常、lfnできないのだから立つべきなのに、立たない。	×
Win95系		lfnできないはずがないので、立つ可能性がない。立たない。	○
		ただし、ドス窓でなくドス・モードでは、立つ。		○
NT系		lfnできないはずがないのに、立ってしまう。立つ。		×
		ただし、NT4.0では通常lfnできないから、立つ。		○
　※しかし、lfn不可環境にアダプタを入れるとlfn可になり、立たなくなる。	○

　最後の○×は、状態を正しく伝えているかの適不適。しかし、どれも仕様と言え
そう。この環境に、Ｖｚのほうが合わせるしかない。konno版は合ってます。

> 生DOS		通常、lfnできないのだから立つべきなのに、立たない。	×

文太さん、すみません、私も混乱していたところがあり、誤解させてしまったかも。
・生DOSでAXに未登録の番号を入れて呼ぶとAXはそのまま、あるいは特定の番号が返る。
　その場合はキャリーは立たない。
というのがDOSの仕様だと思います。AX=71xxh の場合は7100hが返ると。
記憶だけで書いているので、間違っていたら突っ込みください。

> Win95系		lfnできないはずがないので、立つ可能性がない。立たない。	○

これは立たない、は正解でしょうが、私の初期の判定マクロでは立つ場合がありました。
tVZはLFNできていたと思うので、1パラメータと3パラメータの違いがここで出たのかも。

> 		ただし、ドス窓でなくドス・モードでは、立つ。		○

これは私のところの1件だけなのでなんともいえないですね。むしろこれがおかしい？

> 		ただし、NT4.0では通常lfnできないから、立つ。		○

これは、うちでも、Estさんの報告でも、cf0でしたよ。
＞ 機種         Ver       vol: AX    BX   CF  ver: AX    BX
＞-------------------------------------------+---------------
＞NT (Fujistsu) 4.0(SP4)      7100  9F28  0       0005  FF00   lfnloadなし
＞NT (Fujitsu)   4.0(SP4)     007B  9F28  1       0005  FF00   lfnloadあり

> 　※しかし、lfn不可環境にアダプタを入れるとlfn可になり、立たなくなる。	○

これは、Estさんの報告では、cf1でしたよ。（上記）

ということで、cf1 には何か別の意味があると思いますが、私は調べません。（きっぱり）
ただひとつ、Win95のDOSモードでcf1 になったのだけは理解できない、謎です。

 機種         Ver       vol: AX    BX   CF  ver: AX    BX
-------------------------------------------+---------------
95(DOS)      4.00.950       7100  FF00  1       0007  FF00

konnoさん

>> 生DOS	通常、lfnできないのだから立つべきなのに、立たない。	×
>生DOSでAXに未登録の番号を入れて呼ぶとAXはそのまま、あるいは特定の番号が返る。
>その場合はキャリーは立たない。というのがDOSの仕様だと思います。

　仕様じゃないようです。そんなに頑強には作られていない模様。だって、ファ
ンクションコールに入門したころ、マシンが落ちませんでした？　僕はどういう
間違いだったか分かりませんが（ret なしのマシン語プログラムとか）、落とし
まくりました。ＸＰに感謝したものです。何かの記憶違いでしょう。
　キャリーが立つ場合もあるようでした。

　以下のような実験結果でした。

=== Macrotmp by B ===;
INT 21の欠番ファンクションの結果を見る。
　・ＸＰではキャリーが立ち、４行目で昇天しました。
　・ＤＯＳでもキャリーが立つこととがあり、４行目で昇天しました。
* M
50 ^^ "Macrotmp"

ax=$4300, &i($21) &?("CF=%d AX=%04xh",r,ax) #m
ax=$4400, &i($21) &?("CF=%d AX=%04xh",r,ax) #m
ax=$5700, &i($21) &?("CF=%d AX=%04xh",r,ax) #m
;ax=$5D00, &i($21) &?("CF=%d AX=%04xh",r,ax) #m
; ax=$5E00, &i($21) &?("CF=%d AX=%04xh",r,ax) #m
; ax=$5F00, &i($21) &?("CF=%d AX=%04xh",r,ax) #m
; ax=$6300, &i($21) &?("CF=%d AX=%04xh",r,ax) #m
; ax=$6600, &i($21) &?("CF=%d AX=%04xh",r,ax) #m
; ax=$6C00, &i($21) &?("CF=%d AX=%04xh",r,ax) #m
; ax=$6F00, &i($21) &?("CF=%d AX=%04xh",r,ax) #m
; ax=$7400, &i($21) &?("CF=%d AX=%04xh",r,ax) #m
; ax=$7500, &i($21) &?("CF=%d AX=%04xh",r,ax) #m
; ax=$7700, &i($21) &?("CF=%d AX=%04xh",r,ax) #m
; ax=$7800, &i($21) &?("CF=%d AX=%04xh",r,ax) #m
; ax=$7900, &i($21) &?("CF=%d AX=%04xh",r,ax) #m
; ax=$7A00, &i($21) &?("CF=%d AX=%04xh",r,ax) #m
; ax=$7B00, &i($21) &?("CF=%d AX=%04xh",r,ax) #m
; ax=$7C00, &i($21) &?("CF=%d AX=%04xh",r,ax) #m
; ax=$7E00, &i($21) &?("CF=%d AX=%04xh",r,ax) #m
; ax=$8E00, &i($21) &?("CF=%d AX=%04xh",r,ax) #m

*
xp:
CF=1 AX=0003h
CF=1 AX=0006h
CF=1 AX=0006h
落ちる

dos:
CF=1 AX=0002h
CF=0 AX=C0D3h
CF=0 AX=5700h
落ちる


>AX=71xxh の場合は7100hが返ると。
　これは簡単だったのでgrepで確認しています。それでも、7200hと7300hが返る
パターンもあったと記憶しています。拡張でないかなり特殊なファンクションだった
と思いますが。

（Win98）
>> 	ただし、ドス窓でなくドス・モードでは、立つ。		○
>これは私のところの1件だけなのでなんともいえないですね。むしろこれがおかしい？

　僕は正常な反応だと思いますよ。何とも言えないですが。
　Win98 美風呂で試したところ（ドス・モード）、１台だけですが、キャリーが
立ち、7100h が返るという模範生のような振る舞いでした。ただ、美風呂は過去
の経緯をみても、模範生的な場合が多いようです。

（WinNT）
>> 	ただし、NT4.0では通常lfnできないから、立つ。		○
>これは、うちでも、Estさんの報告でも、cf0でしたよ。

　ＮＴはパスしましょう。あの実験結果の数々はどう読んでいいのか分かりませ
ん。まったく間違ってるわけでもない答が返る場合もあったようですけれど。

　僕の想像は、Win9x は、拡張ファンクションに関してネイティブだったのだか
ら、 それほど実装に一貫性が欠如していたり、MS-DOS に無配慮だったりしなか
ったろう、というものです。ＮＴ系は、エミュレータであったりアダプタが必要
だったりだったので、どうなんでしょうね？　そんな感じです。

konnoさん

>文太さんの上の文章ではマシン語の例を言ってますね。ファンクションコールとは違う。
　たしかにずれてます。失礼しました。
　で、MS-DOSの仕様ですが、たしかに仕様ですね。ないのを探したつもりだったの
ですが、甘かった。失礼しました。

=== Macrotmp by B ===;
以下の番号は、本当に欠番（未記載）ファンクションだと思う。
* M
50 ^^ "Macrotmp"

ax=$6600, &i($21) &?("CF=%d AX=%04xh",r,ax) #m
ax=$7400, &i($21) &?("CF=%d AX=%04xh",r,ax) #m
ax=$7500, &i($21) &?("CF=%d AX=%04xh",r,ax) #m
ax=$7800, &i($21) &?("CF=%d AX=%04xh",r,ax) #m
ax=$7900, &i($21) &?("CF=%d AX=%04xh",r,ax) #m
ax=$7A00, &i($21) &?("CF=%d AX=%04xh",r,ax) #m
ax=$7B00, &i($21) &?("CF=%d AX=%04xh",r,ax) #m
ax=$7C00, &i($21) &?("CF=%d AX=%04xh",r,ax) #m
ax=$7E00, &i($21) &?("CF=%d AX=%04xh",r,ax) #m

*
xp:				dos:
CF=1 AX=0001h			CF=1 AX=0001h	？
CF=0 AX=7400h			CF=0 AX=7400h
CF=0 AX=7500h			CF=0 AX=7500h
CF=0 AX=7800h			CF=0 AX=7800h
CF=0 AX=7900h			CF=0 AX=7900h
CF=0 AX=7A00h			CF=0 AX=7A00h
CF=0 AX=7B00h			CF=0 AX=7B00h
CF=0 AX=7C00h			CF=0 AX=7C00h
CF=0 AX=7E00h			CF=0 AX=7E00h

　このような結果でしたので、仕様でしょう。ありがとうございました。
　ま、何かのミスはありそうですが。AX=6600hというのがあるのかなぁ？

>これ、&? を &m に変えたら、cf0 でしたよ。
>これ、&mでも、cf1 になりますか？

　何かが変です。&?()がrを壊すのは出力後です。

=== Macrotmp by B ===;
* M
50 ^^ "Macrotmp"
r=5, &?("%d ",r) &?("%d",r)
*
5 0

>これ、ソースはないんでしょうか。71xxh で、拡張でないのはブラウンリストには
>載ってないですよね。

　微妙に話が食い違っているようですが、7200h, 7300hが返るのは以下で、拡張
ファンクションと言って良いのかな？　ブラウン・リストがソースです。
　うん、ここでも、AXが素直に返ってる。仕様ですね。(^^)/

INT 21 - Windows95 beta - LFN-FindClose
	AH = 72h
<snip>
		7200h if function not supported (e.g. under bare MS-DOS 7)
-----
INT 21 - MS-DOS 7 - DRIVE LOCKING AND FLUSHING
	AH = 73h
<snip>
	CF set on error
	    AX = error code (01h,0Fh,etc.) (see #01680)
		7300h if function not supported

--------------------------
あれ？

ax=$4400　　CF=0 AX=80D3h
ax=$5700　　CF=0 AX=5700h
　でも、これらは未記載ファンクションじゃないですよね？　&m(),&?()
の話ですよね。AXは破壊してしまっているようですが。

--------------------------
　すると、71xxの拡張ファンクションが、未実装のところで（たとえばMS-DOS）、
7100hをAXに返すのは、xx部分を丸めて、キャリーは立てないというMS-DOSの仕様
に準じてる、ということですね。
　すると、キャリーを立ててしまうＸＰが、相当過去を無視してる、ということに
なりますか。

konnoさん

=== Macrotmp by B ===;
未登録番号のファンクションのキャリーとＡＸを見る。
* M
50 ^^ "Macrotmp"

ax=$44EE, &i($21) &?("CF=%d AX=%04xh",r,ax)	;4400->44EE（未登録）
#m
ax=$57EE, &i($21) &?("CF=%d AX=%04xh",r,ax)	;5700->57EE（未登録）

*
xp:
CF=1 AX=0001h
CF=1 AX=0006h

dos:
CF=1 AX=0001h
CF=1 AX=0001h

　回りくどい話なのですが、以下のような仕様が一般的なのだとすれば、

>　すると、71xxの拡張ファンクションが、未実装のところで（たとえばMS-DOS）、
>7100hをAXに返すのは、xx部分を丸めて、キャリーは立てないというMS-DOSの仕様
>に準じてる、ということですね。

　AXに4400hと5700hが返ってくれるだろうと期待していました。あるいは、せめて、
44EEhと57EEhが返ることを（未実装だとAXはそのまま返る）。でも、一貫してそ
うなってるわけでもなさそうです。
　でも、dosでさえ、キャリーを立ててしまった。

>生DOSでAXに未登録の番号を入れて呼ぶとAXはそのまま、あるいは特定の番号が返る。
>その場合はキャリーは立たない。というのがDOSの仕様だと思います。

　「特定の番号」なのかな。
xp:
CF=1 AX=0001h		01h (1)   function number invalid
CF=1 AX=0006h		06h (6)   invalid handle  何だ？

dos:
CF=1 AX=0001h		01h (1)   function number invalid
CF=1 AX=0001h		01h (1)   function number invalid

　（dosは正しそう）

(Table 01680)
Values for DOS extended error code:
---DOS 2.0+ ---
 00h (0)   no error
 01h (1)   function number invalid
 02h (2)   file not found
 03h (3)   path not found
 04h (4)   too many open files (no handles available)
 05h (5)   access denied
 06h (6)   invalid handle
 07h (7)   memory control block destroyed
 08h (8)   insufficient memory
 09h (9)   memory block address invalid
 0Ah (10)  environment invalid (usually >32K in length)
 0Bh (11)  format invalid
 0Ch (12)  access code invalid
 0Dh (13)  data invalid
 0Eh (14)  reserved
 0Eh (14)  (PTS-DOS 6.51+, S/DOS 1.0+) fixup overflow
 0Fh (15)  invalid drive
 10h (16)  attempted to remove current directory
 11h (17)  not same device
 12h (18)  no more files

　というわけで、僕はkonnoさんの言うMS-DOSの仕様を信じます（昨晩の結果
もあるし）。ただ、未登録全部というほど一貫してはいないようですね。
　そして、71xxファンクションが、7100をAXに返すというのも、なにがしかの
仕組みがあるんだろうな、と思ってます。

　う、もう一つ実験したくなった。

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

;-- A -- 既存の拡張ファンク（ただしパラミータ不足）
ax=$7139,	;ﾃﾞｨﾚｸﾄﾘの作成
&i($21) &?("A1   CF=%d AX=%04xh",r,ax) #m

ax=$7147,	;ｶﾚﾝﾄ･ﾃﾞｨﾚｸﾄﾘの取得
&i($21) &?("A2   CF=%d AX=%04xh",r,ax) #m

ax=$71A6,	;ﾊﾝﾄﾞﾙを使用したﾌｧｲﾙ情報の取得
&i($21) &?("A3   CF=%d AX=%04xh",r,ax) #m #m

;-- B -- 既存と未登録（非在）の特殊拡張ファンク
ax=$7200,	;Win95 beta - LFN-FindClose
		;7200h if function not supported (e.g. under bare MS-DOS 7)
&i($21) &?("B1   CF=%d AX=%04xh",r,ax) #m

ax=$7201,	;未登録
&i($21) &?("B12  CF=%d AX=%04xh",r,ax) #m


ax=$7300,	;DRIVE LOCKING AND FLUSHING
		;7300h if function not supported
&i($21) &?("B2   CF=%d AX=%04xh",r,ax) #m

ax=$7301,	;未登録
&i($21) &?("B22  CF=%d AX=%04xh",r,ax) #m

*
xp:				dos:
A1   CF=1 AX=0005h		A1   CF=0 AX=7100h
A2   CF=1 AX=0003h		A2   CF=0 AX=7100h
A3   CF=1 AX=0006h		A3   CF=0 AX=7100h

B1   CF=0 AX=7200h		B1   CF=0 AX=7200h
B12  CF=0 AX=7200h		B12  CF=0 AX=7200h
B2   CF=0 AX=7300h		B2   CF=0 AX=7300h
B22  CF=0 AX=7300h		B22  CF=0 AX=7300h

　読みづらいですが、Ａが既存の拡張ファンクだけど、dos は未対応のはずのも
ので（拡張だから）、どう結果を出すのか。Ｂが特殊な拡張ファンクで、返り値
ＡＸが丸められれるのか（7201 が 7200 に、7301 が 7300 に）。

　結果。
　Ａ群は、ＸＰでキャリーが立つ（MS-DOS の「仕様」に反している）。 パラミ
ータ不足を意味しているキャリーなのかもしれない。
　Ｂ群は、 ＸＰも DOS もキャリーは返さず、ＡＸを 71xx のファンクションの
ように丸める。

　71xx, 72yy（超マイナーで既存は１通りのみ）, 73zz（超マイナーで既存は数
通りのみ）は、xx, yy, zz を丸めて、００にして返す。これは、他の場合には、
そのままかエラーコードなので、特殊。なにがしかの仕組みの存在が想像される。

　感想：全体にキャリーの意味は不明で不定。9x  系は、概ね MS-DOS の仕様ど
おり、NT 系はキャリーに関して、やはり分からん。ＡＸに 7100h を返す拡張フ
ァンクの仕様は、71xx の拡張ファンクに対して一貫していて、72xx, 73xx に関
しても、7200h, 7300h で返り値を丸める。 みたいなところを頭のどっかに入れ
ておこうと思ってます。

拡張ファンク57xxの返り値

konnoさん

　僕が何か間違っていたらご指摘ください。

>生DOSでAXに未登録の番号を入れて呼ぶとAXはそのまま、あるいは特定の番号が返る。
>その場合はキャリーは立たない。というのがDOSの仕様だと思います。

　僕はこれを MS-DOS 時代、多くの場合に当てはまった規則だったのだろうとは
信じています。昨晩の実験でも、ほぼそれに近い結果が出たし。
　ただ、拡張ファンクションコールの時代になって、たぶん、コールの種類の数の
増加とかもあって、当てはまらない場合もある規則になった、と結論しています。

　また、以下の ME, 98 の挙動に見られるように、実装が半端、という印象も持
ちました。


=== Macrotmp by B ===;
拡張ファンク57xxの返り値（エラーの場合）を見る。
* M
50 ^^ "Macrotmp"

ax=$5704, &i($21) &?("5704: CF=%d AX=%04xh",r,ax) #m
	;ﾊﾝﾄﾞﾙによる最終ｱｸｾｽ日時の取得

ax=$5705, &i($21) &?("5705: CF=%d AX=%04xh",r,ax) #m
	;ﾊﾝﾄﾞﾙによる最終ｱｸｾｽ日時の設定

ax=$5706, &i($21) &?("5706: CF=%d AX=%04xh",r,ax) #m
	;ﾊﾝﾄﾞﾙによる作成日時の取得

ax=$5707, &i($21) &?("5707: CF=%d AX=%04xh",r,ax) #m
	;ﾊﾝﾄﾞﾙによる作成日時の設定

*
xp:			dos:			me:
5704: CF=1 AX=0006h	5704: CF=1 AX=0001h	5704: CF=0 AX=5704h
5705: CF=1 AX=0006h	5705: CF=1 AX=0001h	5705: CF=0 AX=5705h
5706: CF=1 AX=0006h	5706: CF=1 AX=0001h	5706: CF=1 AX=0001h
5707: CF=1 AX=0006h	5707: CF=1 AX=0001h	5707: CF=1 AX=0001h

06h invalid handle	01h function number invalid


98:
5704: CF=0 AX=5704h
5705: CF=0 AX=5705h
5706: CF=1 AX=0001h
5707: CF=1 AX=0001h

　上の総合的な印象は、ＸＰとＤｏｓがそれぞれの流儀で正しそう。ＭＥと
９８は、どうして半分で割れるのよ、という感じ。

　MS-DOSでキャリーが立たず、5700hなんてのが返るのを期待していました。
（71xxの場合のように）。
　でも、「知らないファンクションだよ。だからキャリー立てるよ」と、いちおう
ちゃんと反応してるみたい。
　期待は裏切られっぱなし。

　ブラウンさんは、ＬＦＮ関連ファンクションの MS-DOS でのキャリーの振る舞
いについては「CF set on error」と書き（立ちませんがな）、それでも、「AX=
7100h if the function is not supported」と書いてくれて、後半部だけは正し
く、Ｄｏｓカーネル（MS-DOS からＸＰまで）も後半部は、ずっと正しく振る舞った
（この件では、キャリーは、9xで立たず、2K/XPで立ってしまった）。

　しかし、そこから期待される反応をＤｏｓカーネルが一般にするとは単純に思
わないほうが良い、という感じでいます。
　使うなら、どう振る舞うのか、確認のうえ使うこと、という感じでしょうか。

　もっとも、昨日、今日と、パラミータ不足の状態でコールしてますので、色々
と要因があるのかもしれません。そんな場合でさえ、純ドスカーネルは、鼻から
門前払いにせず、ちょっと反応してるみたいな場面もあったようです。キャリー
を立てたり、立てなかったり。ＡＸは使うたびに確認が吉みたいですね。ブラウン
先生も無謬ではないようですし。もっとも、ＮＴ系、とりわけ2K,XPは、先生の
管轄外なのでしょうけれど。

文太さん、マトレスです。

> 未登録番号のファンクションのキャリーとＡＸを見る。
> ax=$44EE, &i($21) &?("CF=%d AX=%04xh",r,ax)	;4400->44EE（未登録）
> ax=$57EE, &i($21) &?("CF=%d AX=%04xh",r,ax)	;5700->57EE（未登録）

この番号は未登録ではなく、登録された44xxh,57xxhの未使用番号です。
当然返り値も振る舞いも違ってきます。

> 　ただ、拡張ファンクションコールの時代になって、たぶん、コールの種類の数の
> 増加とかもあって、当てはまらない場合もある規則になった、と結論しています。

うーん、私にはまだ誤解があるように思えます。
ひとつには、4300ｈ、4400ｈ、5700ｈ、などは、未登録の番号ではないということ。
当然、返り値のaxはそのまま返ったりしないし、cfの意味も違います。
私はこういう趣旨で話したつもりが、全然伝わってないように見えますね。

> 　上の総合的な印象は、ＸＰとＤｏｓがそれぞれの流儀で正しそう。ＭＥと
> ９８は、どうして半分で割れるのよ、という感じ。
> 　MS-DOSでキャリーが立たず、5700hなんてのが返るのを期待していました。

ああ、なんとなく原因が分かったような気がします。
5705h〜はDOS7で拡張されていますが、未登録ではなく5700hのファンクションの
拡張という形になっています。機能追加ということですね。
なので、既存の機能と矛盾しないような返り値になるようになっているはず。
登録、未登録というのは、ah の二桁の番号のことです。

> 　ブラウンさんは、ＬＦＮ関連ファンクションの MS-DOS でのキャリーの振る舞
> いについては「CF set on error」と書き（立ちませんがな
> （この件では、キャリーは、9xで立たず、2K/XPで立ってしまった）。

ふたつめ、私はブラウンさんの記述に矛盾を感じません。
DOSで未サポートの場合はエラーにならずに、axをそのまま（71xxhの場合は7100h）返す。
これが仕様ならブラウンリストの記述と矛盾しないでしょう。
2K/XPでcfが立つのは別なエラーがあるということ。
文太さんの4パラメータのマクロではcf0だったでしょう。正しい使い方ならエラーは出ない。
判定用途ならエラーが出てもaxで判定できるなら問題なしとするのはひとつの考え方。

ということで納得できませんか。
これが間違っていると思うのであれば、納得できる資料の提示をお願いします。
想像で幾ら言っても納得はできませんよね。

&? の件は私の勘違いだったようですね。ｒ が壊れるのは、&? の後なんですね。
ずっと間違って思い込んでいました。おさわがせしました。m(__)m

=== Macrotmp by B ===;
未登録と思われるファンクションをコールして、
キャリーが立たず、ＡＸを見るテスト。
MS-DOSの仕様を確認する。

* M
50 ^^ "Macrotmp"

ax=$6600, &i($21) &?("6600  CF=%d AX=%04xh",r,ax) #m
ax=$7400, &i($21) &?("7400  CF=%d AX=%04xh",r,ax) #m
ax=$7500, &i($21) &?("7500  CF=%d AX=%04xh",r,ax) #m
ax=$7800, &i($21) &?("7800  CF=%d AX=%04xh",r,ax) #m
ax=$7900, &i($21) &?("7900  CF=%d AX=%04xh",r,ax) #m
ax=$7A00, &i($21) &?("7A00  CF=%d AX=%04xh",r,ax) #m
ax=$7B00, &i($21) &?("7B00  CF=%d AX=%04xh",r,ax) #m
ax=$7C00, &i($21) &?("7C00  CF=%d AX=%04xh",r,ax) #m
ax=$9B00, &i($21) &?("9B00  CF=%d AX=%04xh",r,ax) #m
ax=$9C00, &i($21) &?("9C00  CF=%d AX=%04xh",r,ax) #m
ax=$9D00, &i($21) &?("9D00  CF=%d AX=%04xh",r,ax) #m
ax=$9E00, &i($21) &?("9E00  CF=%d AX=%04xh",r,ax) #m
ax=$9F00, &i($21) &?("9F00  CF=%d AX=%04xh",r,ax) #m
ax=$A600, &i($21) &?("A600  CF=%d AX=%04xh",r,ax) #m
ax=$A700, &i($21) &?("A700  CF=%d AX=%04xh",r,ax) #m
ax=$A800, &i($21) &?("A800  CF=%d AX=%04xh",r,ax) #m
ax=$A900, &i($21) &?("A900  CF=%d AX=%04xh",r,ax) #m
ax=$AD00, &i($21) &?("AD00  CF=%d AX=%04xh",r,ax) #m
ax=$AE00, &i($21) &?("AE00  CF=%d AX=%04xh",r,ax) #m
ax=$B100, &i($21) &?("B100  CF=%d AX=%04xh",r,ax) #m
ax=$B200, &i($21) &?("B200  CF=%d AX=%04xh",r,ax) #m
ax=$C500, &i($21) &?("C500  CF=%d AX=%04xh",r,ax) #m
ax=$F600, &i($21) &?("F600  CF=%d AX=%04xh",r,ax) #m

*
xp:			dos:			me:
6600  CF=1 AX=0001h	6600  CF=1 AX=0001h	6600  CF=1 AX=0001h	???
7400  CF=0 AX=7400h	7400  CF=0 AX=7400h	7400  CF=0 AX=7400h
7500  CF=0 AX=7500h	7500  CF=0 AX=7500h	7500  CF=0 AX=7500h
7800  CF=0 AX=7800h	7800  CF=0 AX=7800h	7800  CF=0 AX=7800h
7900  CF=0 AX=7900h	7900  CF=0 AX=7900h	7900  CF=0 AX=7900h
7A00  CF=0 AX=7A00h	7A00  CF=0 AX=7A00h	7A00  CF=0 AX=7A00h
7B00  CF=0 AX=7B00h	7B00  CF=0 AX=7B00h	7B00  CF=0 AX=7B00h
7C00  CF=0 AX=7C00h	7C00  CF=0 AX=7C00h	7C00  CF=0 AX=7C00h
9B00  CF=0 AX=9B00h	9B00  CF=0 AX=9B00h	9B00  CF=0 AX=9B00h
9C00  CF=0 AX=9C00h	9C00  CF=0 AX=9C00h	9C00  CF=0 AX=9C00h
9D00  CF=0 AX=9D00h	9D00  CF=0 AX=9D00h	9D00  CF=0 AX=9D00h
9E00  CF=0 AX=9E00h	9E00  CF=0 AX=9E00h	9E00  CF=0 AX=9E00h
9F00  CF=0 AX=9F00h	9F00  CF=0 AX=9F00h	9F00  CF=0 AX=9F00h
A600  CF=0 AX=A600h	A600  CF=0 AX=A600h	A600  CF=0 AX=A600h
A700  CF=0 AX=A700h	A700  CF=0 AX=A700h	A700  CF=0 AX=A700h
A800  CF=0 AX=A800h	A800  CF=0 AX=A800h	A800  CF=0 AX=A800h
A900  CF=0 AX=A900h	A900  CF=0 AX=A900h	A900  CF=0 AX=A900h
AD00  CF=0 AX=AD00h	AD00  CF=0 AX=AD00h	AD00  CF=0 AX=AD00h
AE00  CF=0 AX=AE00h	AE00  CF=0 AX=AE00h	AE00  CF=0 AX=AE00h
B100  CF=0 AX=B100h	B100  CF=0 AX=B100h	B100  CF=0 AX=B100h
B200  CF=0 AX=B200h	B200  CF=0 AX=B200h	B200  CF=0 AX=B200h
C500  CF=0 AX=C500h	C500  CF=0 AX=C500h	C500  CF=0 AX=C500h
F600  CF=0 AX=F600h	F600  CF=0 AX=F600h	F600  CF=0 AX=F600h

　#06344と酷似した結果となりました。あのテストをもうちょっと網羅的に
行なったものです。

　というわけで、以下のようなMS-DOSの仕様を確認できました。

>生DOSでAXに未登録の番号を入れて呼ぶとAXはそのまま、あるいは特定の番号が返る。
>その場合はキャリーは立たない。というのがDOSの仕様だと思います。

　それほど疑っていたわけでもないのですが、検証したかったのです。
　検証のスキルや知識が足りず、面倒をかけてしまい申し訳ありませんでした。
　勉強の機会を与えてくださり、ありがとうございました。

　良きＧＷを。

> xp:			dos:			me:
> 6600  CF=1 AX=0001h	6600  CF=1 AX=0001h	6600  CF=1 AX=0001h	???

文太さん、6600hは

INT 21 6601 - DOS 3.3+ - GET GLOBAL CODE PAGE TABLE
INT 21 6602 - DOS 3.3+ - SET GLOBAL CODE PAGE TABLE

のグループですよ。登録された番号なので、そういう返り値になるのです。
cf1になるのはパラメータが不正なのでは。
私の説明はそんなにわかりにくいのかなぁ。

ファンクションコールの番号は、ahレジスタに入る２桁、00h〜FFh です。
下２桁の、alレジスタの番号は、補助番号ということです。
４桁のものは、一つの機能（番号）のグループと考えた方がいいでしょう。
４桁だから拡張と言うわけではありません。

70h以降の空番号はユーザーが独自に拡張したものも多いのでこのルールに従っていない
ものもあるかもしれません。
そもそもこの基本的なルールが決まっているからこそユーザーが好きなように拡張できる
わけです。
本気で調べたいならNETでも書籍でもあるはずなので、私はこの辺にしておきます。

> なお、使っているのは7160hのみです。

おお、そんな番号をお使いでしたか。番号の選択理由は個人の好みなのかな。
 7160 02 | ﾌﾙﾊﾟｽ名を長いﾊﾟｽ名で取得		| -

VZ_ENV.DEF の番号をいろいろ変えて試してみました。

7160h
psp=VZIBMJ  mcb=Z  Ver=6.20  LFN=1 ax7160 cf0  idle=1

71a0h
psp=VZIBMJ  mcb=Z  Ver=6.20  LFN=1 ax7B cf1  idle=1

71a7h
psp=VZIBMJ  mcb=Z  Ver=6.20  LFN=1 ax0 cf1  idle=1

としきさん使用の番号が cf0 ですね。これはなかなか。
こうして見ると返り値のAXが7100hでなければ LFN とみて間違いないですね。

> 【高橋さん的には、こんな時代】

めざら資源の軟体マクロ一覧で見ると
FONTEDIT.DEF 外字編集 fontedit.def [98] 1994/11/23 
から
VWXT 2.08A 高橋版VWX vwxt v2.08→v2.08a 2000/01/12 
まで6年間とても精力的に活動されてたんですね。vwxt開発途中で力尽きたのか・・・

私的にはさらに、
DUMP.DEF dump.def/unasm.def 1996/10/26 
これは今もお世話になっています。

QVIEW.DEF 1.20 簡易ビュー Qview.def 1.20 1996/10/20 
これは和生さんの改造版をさらに改造して使わせてもらってます。
VZとマクロはみんなで改造、進化させてここまできたのだなぁ。

> 　（この最後の日付でも、僕はまだＤＣデビューしてないはず。）

そうでしたっけ？　DCの過去ログをグレップしてみました。

07061/07065 xxxxxxxx  文太             RE:サイレントでのマクロの異常
(13)   00/07/13 13:26  06986へのコメント  コメント数：1

06964/06964 xxxxxxxx  文太             RE^2:calendar.def 21 century ediiton
(14)   00/12/14 01:03  06961へのコメント

16411/16411 xxxxxxxx  文太             RE^2:小物マクロの住所録 2000/07
(15)   00/08/04 01:44  16403へのコメント

うーん、高橋さんと入れ違いくらいなんですね。

めざらさんが　「おもしろくてパワーのある新人の登場で，13 階がにぎやかです。」
と住所録のコメントで言ってましたね。私はそれをROMっていたのでした。
ついでに私のDCデビューは

08898/09921 XXXXXXXX  H.konno　　　 Libｒetto(Me)で Vz を使う EMS編
(13)   02/01/05 23:00

08904/09921 XXXXXXXX  H.konno　　　 Libretto(Me)で dos窓を拡大する
(13)   02/01/08 22:18  08898へのコメント

07770/08074 XXXXXXXX  H.konno　　　 メビウス（ＭＥ）で EMS を設定する
(14)   03/01/05 23:10  07725へのコメント

07771/08074 xxxxxxxx  文太             RE:メビウス（ＭＥ）で EMS を設定する
(14)   03/01/06 05:56  07770へのコメント  コメント数：1

20188/20710 XXXXXXXX  H.konno　　　 vzt03k2 ｘｐ専用 lfn 対応テスト版
(15)   03/07/13 00:21                     コメント数：1

こんな感じで、ちょうど10年前に文太さんとファーストコンタクトだったんですね。
年を取ると昔話ばかりする気持ちがわかるようになったような。(^^;

※IDを伏字にしたりしてあります。

konnoさん

　自分がこんなことに関わったことがあったなんて、こ、恐い。
　な、何も覚えてなかった。

FGALDC
>20212/20710 xxxxxxxx  文太             RE:各OSの違いを知りたい
>(15)   03/07/19 23:30  20211へのコメント

　しかし、１０年間で進歩していた。「ほんとにお前わかってねぇなぁ」と過去
の自分につっこみを入れたくなる。

　今や、何をやっていたか分かるもんね。
　Win9x系のCFって、こんなにばらつきがあるんだぁ。この状態で、高橋版で、
ロング・ファイラができてたはずないですよね？？？　これだけ見ても、CFを
見るルーチンは外さざるを得ませんよね。

同所＃20210より
 機種         Ver       vol: AX    BX   CF  ver: AX    BX
-------------------------------------------+---------------
XP (VAIO)    5.1.2600       007B  0000  1       0005  FF00  
98ME(TOSIBA) 4.90.3000      0002  0000  1       0008  FF00	98SE ?
98SE(TOSIBA) 4.10.2222      0002  0000  1       0A07  FF00
98SE(DOS)　  4.10.2222      7100  0000  1       0A07  FF00
95(TOSIBA)   4.00.950       0002  0000  1       0007  FF00
95(DOS)      4.00.950       7100  FF00  1       0007  FF00
200LX        5.00           7100  0000  0       0005  FF00
J3100        5.00           7100  0000  0       0005  0000
sigmarion2   6.22(poketdos) 7100  0000  0       1606  FF00 
---- 文太さん  ----------------------------+---------------
98ME         4.90.3000      0200  4006  0			98SE ?
98           4.10.1998      0200  4006  0
95           4.00.1111      0200  4006  0
NEC98        5.00           7100  259E  0
モバギ(DOS)  6.20           7100  0000  0
-------------------------------------------+---------------

　&?( )がrを壊すのは知ってるもんね。

----------

　別文脈ですが、この頃のログを斜め読みして思ったのは、

同所＃20203　で

>高橋版では、AX と　CF 両方で見ていたのを、
>V01 では　無視した（つもり）
>V02 では、AX だけで判断してみた

　と説明していますが、あんまりここに皆さん注意を払ってないみたいで（僕に
は意味不明だったに違いない）、誰も自分では考えようとしてないんだ、という
気持ちはあったのかな、と、今さらながら思いました。申し訳ありませんでした。

しつこくて申し訳ありません。

konnoさんwrote:
-----
ちなみに、マクロ修正後のVTDOS
psp=VZIBMJ  mcb=Z  Ver=6.20  LFN=1 cf1  idle=1

Win7DOS窓
psp=VZIBMJ  mcb=Z  Ver=5.0  LFN=1 cf1  idle=1

うーん、VTDOSはNT系だったか。
-----

　まず、idle=1は、ヤッタ！　＼(^_^)／

　上の結果を出すマクロでは、Win9x 系とＮＴ系の区別はつかないですよね。知
れるのは、LFN が可能かどうかですよね。
　「LFN=1 cf1」の元の変数ｌとｃは、同じことをレポートさせてますよね。 そ
のつもりで、

    &?("psp=%Fs  mcb=%c  Ver=%d.%d  LFN=> cf%d  idle=%04x",8,vz-1,b,d,e,c,i)
        			    ;★bunta

　と変数ｌの使用を僕は止めました。

　というわけで、「LFN=1 cf1」は論理矛盾だと思うのですが。
　ＬＦＮができるというこは、キャリーが立たなかった、という意味でしょうから。

　で、Win9x系とＮＴ系の区別を見るためには、この結果を見るしかないですよね。

ax$3000,&i($21) d=ax%256, e=ax/256,	;DOS ver

　ブラウンリストから我々が必要な部分を大胆にダイジェストすると、

INT 21 - DOS 2+ - GET DOS VERSION
	AH = 30h
---DOS 5+ ---
	AL = what to return in BH
	    00h OEM number (see #01394)
Return: AL = major version number (00h if DOS 1.x)
	AH = minor version number
Notes:	the Windows NT DOS box returns version 5.00 (2K, XP, 7)
	MS-DOS 6.21 reports its version as 6.20; version 6.22 returns the correct value
	Windows95 returns version 7.00 (the underlying MS-DOS)
	Windows95 OSR2 and OSR2.5 (OPK3) return MS version 7.10 (98, 98SE, ME)

　僕が追記してる箇所あり。

　ま、こういうことですね。別にニュースじゃないと思いますけど。

5.00  NT系 --- NT, 2K, XP, 7
6.20  vanilla MS-DOS in Moba, etc
7.00  Win95 OSR1
7.10  Win95 OSR2, 98, 98SE, ME

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

    ax$71a0,				;LFN vol
    &Sc(pa,pi,3) dx=pa, di=pa+5, cx=50,
    &i($21) 
    l+, 				;<l> LFN flag。普通とおるもの（前提）
    (ax==$7100 || r)? l-,		;エラー時のみフラグを降ろす。
    &m("LFN=%d",l)			;l=1でオン、LFN OKの意味。

*
　VTDOSでも問題ないでしょう？

追記：

　何にこだわっていたかというと、ファンクションコールは MS-DOS のカーネル
の処理なんだろうけど、それは、io.sys か msdos.sys か、ということ。

　答：vanilla MS-DOSとWin9x系で違う。少なくともcommand.comは関係ない。

http://ja.wikipedia.org/wiki/MSDOS.SYS
（引用、ちょっと長め、失礼します）
　MSDOS.SYS  は、MS-DOS および Windows 9x 系で重要なシステムファイルであ
る。IO.SYS の後に動作する。MS-DOS では、MSDOS.SYS にオペレーティングシス
テム本体のコード、すなわちカーネルが含まれている。Windows  9x 系では DOS
カーネルのコードは IO.SYS に統合されており、MSDOS.SYS は設定情報が書かれ
たテキストファイルになっている。

-----

　また、DOS version を知るファンクションコールについて、ブラウンリストで
点検したのは、AX = 30h の INT 21h（get dos version）は MS-DOS のヴァージ
ョンを示すだけなのか、ということ。
　これはそうだと言っておいてよいのだろう、という結論。BH  に返される部分
まで  MS-DOS のＩＤみたいなものと考えると、MS-DOS カーネルはハード自体の
情報も持ってるとは言える。
　興味のある方は、  「see   #01394」  の部分を見てみてください。  きっと
Olivetti  も Toshiba も NEC も Sanyo も、MS-DOS 自体に手を入れてはいない
のだろうけど、MS-DOS は自分が使われているハード環境を知っている。 もしか
したら、 かつてはこれらの会社（すんげえ多数）は、MS-DOS というＯＳを自社
用にカスタマイズしてたのかもしれないけど。

（検索キーです）
	AH = 30h
---DOS 5+ ---
	AL = what to return in BH
	    00h OEM number (see #01394)

　いえ、 無謀にも、手元にないVTDOSがどこまでやっているのか、と想像してい
まして。NTDVM にお世話になりながら、足りない部分を足してるんですよね。分
からないけど。

konnoさん

　VTDOSの話の前に。
　たぶん、もう通じていると思いますが。
　どこから話がずれていたのか、混濁していたのか、今やっと確認できました。

#6271 konnoさんwrote:

=== vz_env.def v05 ===より

    &i($21) c-, (ax==$7100 || r)? c+,	;★CFは生DOS、Win95系では立たない●！！
    l-,(ax!=$7100)? l+,;    	    	;lfn=1  ※ NT系ではcfが立つ

　ここのコメントが間違ってます。キャリーが立たないのは、生ドスのみです。
　c=1=carry flag ON=LFN NG, l=1=LFN OK という具合で、cとlは反対の意味を
持ちます。両方を書き出す意味はないと思いますが。

　とらじさんと高橋さんが問題にしてたのは、 生ドスと Win98 ぐらいの関係で
（98/05/21）、ＮＴ系（当時は NT4.0  ぐらいのはず）を高橋さんが断念したの
は、もう少しあとです。ＮＴを使ってるユーザはまだ少なく、たぶんあまり要望も
需要もテスタもなかったのじゃないのかなぁ、と想像します。誰か一人がくいさが
っていたような記憶ですが。高橋さんも何かのテスト結果を見て、残念そうに諦め
ていたと思います。もちろん、僕は過去ログを読んだだけですよ。


　ブラウンリストの該当箇所は以下。

INT 21 - Windows95 - LONG FILENAME - GET VOLUME INFORMATION
	AX = 71A0h
Return: CF clear if successful
	AX destroyed (0000h and 0200h seen)　	AXの値は見てもふつう意味なし（※）
	CF set on error		AXに7100hが返っていたときだけ意味がある。
	AX = error code 7100h if function not supported <<<==== for MS-DOS★
　（※）「AXは破壊、0000hとか0200hという数字が返ったことがある模様」
　　　　程度の意味と僕は理解しています。


　繰り返しですが、生ドスとWindowsの両方に通じさせるコーディングでは、
CFとAXの両方を見よ、これがＭＳ推奨のやり方です。LXやモバの人もいるわけで、
そのようなコードがＶｚｅｒには必要なのです。

>で、Win7のVTDOSでの結果。
>psp=VZIBMJ  mcb=Z  Ver=6.20  LFN=1 cf0  idle=0

　というわけで、まだアイドル対応でなかったVTDOSでの、この結果は正しいのです。
　MS-DOSのヴァージョンだけが、純command.com適用になってるなぁ、というのが
VTDOSの特殊性なだけで。おそらく。