[HOME]  [全部表示 会議室風]  [全部表示 保存用]  [HOME]  [リストへもどる] [リストへもどる]

一括表示


  VZ環境いいんかい - konno 13/03/31-04:47 No.6270
 ┗ Re: VZ環境いいんかい - 文太 13/04/10-00:03 No.6271
  ┗ Re^2: VZ環境いいんかい - 文太 13/04/11-08:58 No.6274
   ┗ vz_env.def v05 - konno 13/04/11-22:51 No.6276
    ┣ Re: vz_env.def v05 - 文太 13/04/12-00:43 No.6277
    ┃ ┗ cf バグってましたm(__)m - konno 13/04/15-23:36 No.6279
    ┃ ┣ Re: cf バグってましたm(__)m - 文太 13/04/16-23:46 No.6280
    ┃ ┃┃┣ Re^2: cf バグってましたm(__)m - 文太 13/04/16-23:51 No.6281
    ┃ ┃┃┗ Re^3: cf バグってましたm(__)m - 文太 13/04/17-10:29 No.6282
    ┃ ┃ ┗ Re^2: cf バグってましたm(__)m - konno 13/04/17-23:48 No.6290
    ┃ ┃ ┣ Re^3: cf バグってましたm(__)m - 文太 13/04/18-01:48 No.6291
    ┃ ┃ ┃ ┗ 優先順位 - 文太 13/04/18-02:22 No.6292
    ┃ ┃ ┗ よく分からない判定法の真偽の判定 - 文太 13/04/18-10:44 No.6293
    ┃ ┃  ┗ 高橋版の歴史(データ) - 文太 13/04/18-12:22 No.6294
    ┃ ┃   ┗ 高橋さんデータへの追記 - 文太 13/04/18-12:31 No.6295
    ┃ ┃    ┣ 高橋さんの実験 - 文太 13/04/18-18:45 No.6296
    ┃ ┃    ┃ ┗ Re: 高橋さんの実験 - konno 13/04/19-01:44 No.6297
    ┃ ┃    ┃ ┗ Re^2: 高橋さんの実験 - 文太 13/04/19-22:49 No.6298
    ┃ ┃    ┃ ┃ ┗ 71A0_INT21 について(まとめ) - 文太 13/04/19-22:50 No.6299
    ┃ ┃    ┃ ┃ ┣ 冗談 - 文太 13/04/19-23:40 No.6301
    ┃ ┃    ┃ ┃ ┗ Re: 71A0_INT21 について(まとめ) - konno 13/04/20-00:56 No.6302
    ┃ ┃    ┃ ┃  ┣ Re^2: 71A0_INT21 について(まとめ) - 文太 13/04/20-02:12 No.6303
    ┃ ┃    ┃ ┃  ┃ ┗ Re^3: 71A0_INT21 について(まとめ) - としき 13/04/20-13:24 No.6304
    ┃ ┃    ┃ ┃  ┃ ┗ Re^4: 71A0_INT21 について(まとめ) - 文太 13/04/20-15:20 No.6306
    ┃ ┃    ┃ ┃  ┃ ┃ ┗ Re^5: 71A0_INT21 について(まとめ) - としき 13/04/20-19:24 No.6308
    ┃ ┃    ┃ ┃  ┃ ┃ ┗ Re^6: 71A0_INT21 について(まとめ) - 文太 13/04/21-00:37 No.6309
    ┃ ┃    ┃ ┃  ┃ ┃  ┣ 修正 - 文太 13/04/23-15:39 No.6320
    ┃ ┃    ┃ ┃  ┃ ┃  ┗ LFNアダプタの効果 - 文太 13/04/23-16:08 No.6322
    ┃ ┃    ┃ ┃  ┗ Re^2: 71A0_INT21 について(まとめ) - 文太 13/04/20-15:21 No.6307
    ┃ ┃    ┃ ┃   ┗ Re^3: 71A0_INT21 について(まとめ) - konno 13/04/21-00:46 No.6311
    ┃ ┃    ┃ ┃    ┣ Re^4: 71A0_INT21 について(まとめ) - 文太 13/04/21-15:23 No.6314
    ┃ ┃    ┃ ┃    ┃ ┗ Re^5: 71A0_INT21 について(まとめ) - konno 13/04/22-00:51 No.6316
    ┃ ┃    ┃ ┃    ┃ ┗ Re^6: 71A0_INT21 について(まとめ) - 文太 13/04/22-01:27 No.6318
    ┃ ┃    ┃ ┃    ┃  ┗ まとめ3 - 文太 13/04/23-15:50 No.6321
    ┃ ┃    ┃ ┃    ┃   ┗ Re: まとめ3 - konno 13/04/24-00:00 No.6323
    ┃ ┃    ┃ ┃    ┃    ┗ Re^2: まとめ3 - 文太 13/04/24-10:14 No.6326
    ┃ ┃    ┃ ┃    ┃     ┗ Re^3: まとめ3 - 文太 13/04/25-00:16 No.6327
    ┃ ┃    ┃ ┃    ┃      ┗ まとめ4 - 文太 13/04/25-13:06 No.6329
    ┃ ┃    ┃ ┃    ┃       ┗ Re: まとめ4 - konno 13/04/26-01:17 No.6331
    ┃ ┃    ┃ ┃    ┃        ┗ Re^2: まとめ4 - 文太 13/04/26-10:34 No.6332
    ┃ ┃    ┃ ┃    ┃         ┣ Re^3: まとめ4 - 文太 13/04/26-23:22 No.6333
    ┃ ┃    ┃ ┃    ┃         ┗ Re^3: まとめ4 - konno 13/04/28-00:52 No.6335
    ┃ ┃    ┃ ┃    ┃          ┗ Re^4: まとめ4 - 文太 13/04/28-01:35 No.6336
    ┃ ┃    ┃ ┃    ┃           ┗ まとめ5 - 文太 13/04/28-12:56 No.6337
    ┃ ┃    ┃ ┃    ┃            ┗ Re: まとめ5 - konno 13/04/29-00:13 No.6339
    ┃ ┃    ┃ ┃    ┃             ┗ Re^2: まとめ5 - 文太 13/04/29-21:09 No.6340
    ┃ ┃    ┃ ┃    ┃              ┗ Re^3: まとめ5 - konno 13/04/29-23:02 No.6341
    ┃ ┃    ┃ ┃    ┃               ┗ Re^4: まとめ5 - konno 13/04/29-23:40 No.6342
    ┃ ┃    ┃ ┃    ┃                ┗ Re^5: まとめ5 - 文太 13/04/30-01:16 No.6344
    ┃ ┃    ┃ ┃    ┃                 ┗ Re^6: まとめ5 - 文太 13/04/30-14:10 No.6345
    ┃ ┃    ┃ ┃    ┃                  ┗ 拡張ファンク57xxの返り値 - 文太 13/04/30-23:33 No.6346
    ┃ ┃    ┃ ┃    ┃                   ┗ Re: 拡張ファンク57xxの返り値 - konno 13/05/01-01:25 No.6348
    ┃ ┃    ┃ ┃    ┃                    ┗ Re^2: 拡張ファンク57xxの返り値 - 文太 13/05/01-01:37 No.6349
    ┃ ┃    ┃ ┃    ┃                     ┗ Re^3: 拡張ファンク57xxの返り値 - 文太 13/05/01-03:10 No.6350
    ┃ ┃    ┃ ┃    ┃                      ┗ Re^4: 拡張ファンク57xxの返り値 - konno 13/05/01-23:41 No.6352
    ┃ ┃    ┃ ┃    ┃                       ┣ Re^5: 拡張ファンク57xxの返り値 - 文太 13/05/02-12:26 No.6354
    ┃ ┃    ┃ ┃    ┃                       ┃ ┗ Re^6: 拡張ファンク57xxの返り値 - konno 13/05/02-23:23 No.6358
    ┃ ┃    ┃ ┃    ┃                       ┗ Re^5: 拡張ファンク57xxの返り値 - 10♯ 13/05/02-21:53 No.6355
    ┃ ┃    ┃ ┃    ┃                        ┣ Re^6: 拡張ファンク57xxの返り値 - としき 13/05/02-22:02 No.6356
    ┃ ┃    ┃ ┃    ┃                        ┗ VZとプラットフォームの環境 - konno 13/05/03-00:07 No.6359
    ┃ ┃    ┃ ┃    ┗ Re^4: 71A0_INT21 について(まとめ) - としき 13/04/21-22:37 No.6315
    ┃ ┃    ┃ ┃     ┗ Re^5: 71A0_INT21 について(まとめ) - konno 13/04/22-01:05 No.6317
    ┃ ┃    ┃ ┃      ┗ Re^6: 71A0_INT21 について(まとめ) - としき 13/04/23-09:41 No.6319
    ┃ ┃    ┗ Re: 高橋さんデータへの追記 - konno 13/04/19-23:23 No.6300
    ┃ ┃     ┗ Niftyの思い出 - 文太 13/04/20-15:19 No.6305
    ┃ ┃      ┣ 昔話にすらならない - 文太 13/04/21-00:39 No.6310
    ┃ ┃      ┗ VTDOS+CKWVのIME制御 - konno 13/04/21-01:59 No.6312
    ┃ ┃       ┗ Re: VTDOS+CKWVのIME制御 - 文太 13/04/21-15:22 No.6313
    ┃ ┗ Re: cf バグってましたm(__)m - 文太 13/04/17-12:30 No.6283
    ┃  ┗ まとめ(LFN vol) - 文太 13/04/17-12:42 No.6284
    ┃   ┗ 追記: - 文太 13/04/17-14:21 No.6285
    ┃    ┗ 追記2 - 文太 13/04/17-14:40 No.6286
    ┃     ┗ 脱線 - 文太 13/04/17-15:03 No.6287
    ┃      ┗ 脱線から戻る(tVzとkVz) - 文太 13/04/17-15:40 No.6288
    ┗ Re: vz_env.def v05 - 文太 13/04/17-20:17 No.6289

(6270) 6270VZ環境いいんかい  投稿者:konno   2013/03/31(日) 04:47
   コメント数 2

最近は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のほうがわかりやすいけどね。


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

      - No.6270 -    このTreeへ           [リストへもどる] pre

(6270) 6271Re: VZ環境いいんかい  投稿者:文太   2013/04/10(水) 00:03
    6270 番 konno さんへのコメント    コメント数 1

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 に限らず、拡張ファンクションコール一般だと
> 生DOSでは CY が変化しません。 DOSモードだと CY が立ちます。
> で、どっちも ax$7100 が返ります。
> 生DOSと拡張ファンクションコールを合わせて使うのには
> ↓の方法がMSから推奨されてます。 
>
>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:

      - No.6271 -    このTreeへ    コメント元:6270 へ [リストへもどる] pre

(6270) 6274Re^2: VZ環境いいんかい  投稿者:文太   2013/04/11(木) 08:58
    6271 番 文太 さんへのコメント    コメント数 1

 このほうがいいですね。

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+,

      - No.6274 -    このTreeへ    コメント元:6271 へ [リストへもどる] pre

(6270) 6276vz_env.def v05  投稿者:konno   2013/04/11(木) 22:51
    6274 番 文太 さんへのコメント    コメント数 2

文太さん、どうも。

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

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

=== 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

      - No.6276 -    このTreeへ    コメント元:6274 へ [リストへもどる] pre

(6270) 6277Re: vz_env.def v05  投稿者:文太   2013/04/12(金) 00:43
    6276 番 konno さんへのコメント    コメント数 1

konnoさん

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

 LFN判定のところに問題があったということなんですよね、すいません、古代文字を
読ませてしまったようで。m(__)m

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

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

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

 ええ、pspがそうなるんですか。PC-DOSとMS-DOSってどう違うんだろう?
 idleは効かないんですかぁ……。強力なマシンパワーで問題にならないんでし
ょうかね。

 僕も Windows 7を意識していますので、10# さんの VTDOS におねだり攻撃で
きるのかなぁ、と少し思っています。とりあえず、最後のXP機であと2年をタ
ヌキ算用しながら(また買ったXP機)て、そっちを見つめてます。 秀丸とワード
2000(VBA)で、まいったな、というか、げ、意外に面白い、なんて感じでいます。

 Windows というOSを本当に毛嫌いしてきたんだなぁ、と思う今日この頃です。
 とはいえ、Vzは永遠に不滅です。僕的には、2ストロークキーがこれほど快
適とは、知りませんでした。
 それより、マシン同士を繋げないと。
 これ、 10年ぶりくらいに復活した WinME,「とべ」なんてマシンで書いてま
す。 やっぱり、これだな、とか。とはいえ、ワードの Web モードなんてのも推敲
にはなかなかのものなんですが。ワード(Windows 標準)は僕にとっての完全な
外国語、古代文字でした。

^N (新規ファイル)、^O(ファイルオープン)、^Z(コマンドリピート)、^Y(リピート
やり直し)。げげげ、全然違うだろうが、とか。
 MS系、意外にキーがカスタマイズできない……。
 どうしよう……。


      - No.6277 -    このTreeへ    コメント元:6276 へ [リストへもどる] soft

(6270) 6279cf バグってましたm(__)m  投稿者:konno   2013/04/15(月) 23:36
    6277 番 文太 さんへのコメント    コメント数 2

>  嬉しいです。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系だったか。


      - No.6279 -    このTreeへ    コメント元:6277 へ [リストへもどる] pre

(6270) 6280Re: cf バグってましたm(__)m  投稿者:文太   2013/04/16(火) 23:46
    6279 番 konno さんへのコメント    コメント数 2

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 になりました。ここってなにやってるんだっけ?

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

#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+ 。
;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 に限らず、拡張ファンクションコール一般だと
> 生DOSでは CY が変化しません。 DOSモードだと CY (キャリー、CFのこと)
>が立ちます。
> で、どっちも ax$7100 が返ります。
 (エラーでどっちもax$7100を返すなら、CFあるいはrを見る必要さえないのかも。
でもMSがまずCFを見ろといってるのだから、(ax==$7100 || r)?が素直なんでしょう)


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

 PSP、了解です。(^^;

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

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


      - No.6280 -    このTreeへ    コメント元:6279 へ [リストへもどる] pre

(6270) 6281Re^2: cf バグってましたm(__)m  投稿者:文太   2013/04/16(火) 23:51
    6280 番 文太 さんへのコメント    コメント数 1

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

 ここでいう「command.com」が生ドス(MS-DOS 6.2Vとか)だから、ちょっと色々
と錯綜する可能性はあるでしょう、という意味です。

      - No.6281 -    このTreeへ    コメント元:6280 へ [リストへもどる] soft

(6270) 6282Re^3: cf バグってましたm(__)m  投稿者:文太   2013/04/17(水) 10:29
    6281 番 文太 さんへのコメント

整理

konnoさん

 分かりやすくポイントだけあげると以下のはずです。

 ・cf==0は、LFN OKの意味。キャリー立たず、だから。
 ・71A0hのファンクションコールでは、ax, dx, di, cxのパラミータが必要。
 ・生ドスでは、71A0hの結果、CFが立たず、(ax==$7100)? の判定式が必要。

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

 Win7+VTDOSの環境での71A0hでの結果については分かりませんが、command.com
は、関係ないですね。ファンクションコールを担当するのは、io.sysかNTDVMです
ね。ただ、NTDVMのファンクションコールもあてにならない場合があったから、
VTDOSが肩代わりしている場面もあったように記憶しています。ぜんぜん、分かっ
てませんが。

      - No.6282 -    このTreeへ    コメント元:6281 へ [リストへもどる] soft

(6270) 6290Re^2: cf バグってましたm(__)m  投稿者:konno   2013/04/17(水) 23:48
    6280 番 文太 さんへのコメント    コメント数 2

文太さん、怒涛の書き込みに圧倒されてますが、今日は飲み会で今帰ったところです。

>  いえ、ちゃんとしてれば、cf==0, つまり、キャリーフラグ・オフとなるはずです。
>  cf==0は、LFN OKの意味です。

文太さんの言いたかったことは理解したつもりです。
そのうえで、私の考えを伝えたいと思います。

>  ファンクションコールのパラミータが足りてないんです。
>  つまり、rにLFN OK or NGの結果が返りません。

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

>  なぜキャリーが立つのかは謎です。どっかの無関係なrのせい?

私にとってはココが一番大事なところだったのです。
なぜとか謎はどうでもいい、高橋版の判定方法の再現が目的のマクロなんですから。

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

私も過去ログを確認しました。
高橋さんは検証できる環境を持っておらず、とらじさんの情報をもとにVZのソースに
LFN判定を追加したので、おっしゃる通り両方を見て判定していますね。

でも、とらじさんの言うMS推奨の判定法はパラメータがあったのか無かったのか
過去ログを読んだだけでは私にはどっちと断言できません。
そして、高橋さんはパラメータなしの判定法を選択しました。
その結果として、NT系ではcfが立ってLFNモードが使えなかった。

という背景があるので、私は高橋版にならった判定法にしてます。

      - No.6290 -    このTreeへ    コメント元:6280 へ [リストへもどる] soft

(6270) 6291Re^3: cf バグってましたm(__)m  投稿者:文太   2013/04/18(木) 01:48
    6290 番 konno さんへのコメント    コメント数 1

konnoさん

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


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

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

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

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

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

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

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

 はい。

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

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

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

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

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 の正しいLFN判定マクロは、素XP(VTDOS でなく)の
高橋版、konno 版で正しい判定をするんですよね。
 僕は、あのマクロがちゃんと機能するように確かめることだけをしたかったの
です。 だって、最初ヴァージョンでは意味不明な AX が返っていたし、ver 05
では、 変数CとLが意味不明な(win9x と winNT の違いを見る???)処理を
してたみたいだし……。

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

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

      - No.6291 -    このTreeへ    コメント元:6290 へ [リストへもどる] pre

(6270) 6292優先順位  投稿者:文太   2013/04/18(木) 02:22
    6291 番 文太 さんへのコメント

優先順位

 すっかり訳が分からなくなってしまったので、自分の頭の整理のために書いて
おきますね。

 (1)僕は最新OSでのVzを諦めた。日本語入力と編集が必要だから。秀丸
と Windows ランチャとファイラでやりくりしていこうと決めた。
 (2)あと2年XPで、あとはスタンドアロンなMEで、必要箇所を限定して
Vzしていこうと。だって、そのためにずっと準備してきたのだもの。
 (3) きっとすごく面倒で本気の仕事のとき(grep とか sed とか awk とか
とVzの連係の事務仕事)、細々とVzしていくつもりだった。
 (4) キビキビした Vz on VTDOS でも、はやりIMEの制御が効かない環境
だったら、 MS-IME と秀丸のほうがましだろう、と思っていた。 原稿書き自体
(考える作業)には、実はマクロがそれほど大切ではない。
 (5)WinME での原稿書きの作業では、ファンクションコールも何も要らない。
FEP は制御できるし、インターネットはないし、新しくて古めなソフトについて
の研究もほとんどいらない。LANがあればファイル管理の意味で最高。
 (6)Win7 以降は世間とのおつき合いで、やれ、ツイッターだ Facebook だ、
メールだ、 YouTube だ , RSS だ、というのはマウスでやれば、ふつうにやり過
ごせる。

 うん、やっぱり、こんな感じなんですよね。
 高橋版 vz.com って、どこにあるんだろう? モバの純Dos用Vzだって、
konno 版ですよぉ。LFNもアイドルも効かないのに。

 福島菊次郎さんは写真家でした。でも歳のせいで目が駄目になり、文章で、見
たものと写したものを語ることにした。使っているのはフロッピーベースのワー
プロ。朝起きると、ワープロの前で手を合わせる。今日もちょんと動いてくれよ
な、と。

 Vzとなら、俺にもやれるんじゃないか、と思ってます。いちばん大事な場面
なんだし。


      - No.6292 -    このTreeへ    コメント元:6291 へ [リストへもどる] soft

(6270) 6293よく分からない判定法の真偽の判定  投稿者:文太   2013/04/18(木) 10:44
    6290 番 konno さんへのコメント    コメント数 1

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

=== 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 は不定になると思うので、そのときの状
況によりけりで中身が決まっていると思うから、このテストに意味があるのか、
僕にはよく分からない。マクロの場合、マクロが動き出す時点で、Vzが初期化し、
全部ゼロにクリアされてるものなのかな……。

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


konno, k07t
takahashi, t03k

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

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

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


      - No.6293 -    このTreeへ    コメント元:6290 へ [リストへもどる] pre

(6270) 6294高橋版の歴史(データ)  投稿者:文太   2013/04/18(木) 12:22
    6293 番 文太 さんへのコメント    コメント数 1

高橋版の歴史(データ)

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

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

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

 さて、NTの話はどこでしょう?
 ほぼ間違いなくVztの開発は、DC15階で議論されたはずですが……。
 (この辺、「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+ での検索・置換。漢字の2バイト目対策

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 -% "開晒"」
      - No.6294 -    このTreeへ    コメント元:6293 へ [リストへもどる] pre

(6270) 6295高橋さんデータへの追記  投稿者:文太   2013/04/18(木) 12:31
    6294 番 文太 さんへのコメント    コメント数 2

高橋さんデータへの追記

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

やしきの板塀#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
 (この最後の日付でも、僕はまだDCデビューしてないはず。)


      - No.6295 -    このTreeへ    コメント元:6294 へ [リストへもどる] pre

(6270) 6296高橋さんの実験  投稿者:文太   2013/04/18(木) 18:45
    6295 番 文太 さんへのコメント    コメント数 1

高橋さんの実験

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

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

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

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

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


 余計な蛇足:10#の過去の発言や、先日のWinUpdateでのEMS不具合(どうな
ったんだろう、あれは、その後?)を読んで、経験してみて思うのは、Dos窓
環境みたいなところにも、ホストOSの変化は、けっこう出るみたいで、NTVDM.exe
自体が更新されなくても、ホストOSや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)

*

      - No.6296 -    このTreeへ    コメント元:6295 へ [リストへもどる] pre

(6270) 6297Re: 高橋さんの実験  投稿者:konno   2013/04/19(金) 01:44
    6296 番 文太 さんへのコメント    コメント数 1

文太さん、全体像はおおむね合っていそうですね。

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

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

>  もちろん、 時系列からいって、Vzt にはすでに Win9x 用ルーチンが入ってい
> てLFNができる状態だったはずです。WinNT では、それらに引っかかって駄目
> だったのではないでしょうか。

そうですね、NTではそもそもLFNの拡張ファンクションコールが無かったから
テストマクロで期待した結果が出なかったことで、原因究明をあきらめたと。

私は今となっては調べる気もないです。Win9x用ルーチンが高橋さんの手抜きか
当時のMSの正式な推奨だったのか。

      - No.6297 -    このTreeへ    コメント元:6296 へ [リストへもどる] soft

(6270) 6298Re^2: 高橋さんの実験  投稿者:文太   2013/04/19(金) 22:49
    6297 番 konno さんへのコメント    コメント数 1

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

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

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

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


      - No.6298 -    このTreeへ    コメント元:6297 へ [リストへもどる] pre

(6270) 629971A0_INT21 について(まとめ)  投稿者:文太   2013/04/19(金) 22:50
    6298 番 文太 さんへのコメント    コメント数 2

71A0_INT21 について(まとめ)

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

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

 結論1:将来どうなるか分からないけど(あるの? 将来)、konno さんが高
橋版にした処理は正しい。おかげでXPでLFNが扱えるようになった。

 結論2:高橋さんはコーディングは、高橋版の開発時点では天才的だった。い
いのかよ、と思うやり方。しかし、目的だけを考えれば、あれで足りた。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 カーネル(エミュレ
ータ含む)によって反応、処理が違う。このファンクションの場合、けっこう酷い。
拡張ファンクションなんて、どれもそんなものなのかな。詳細は下の表で。
 しかし(功を奏したのだけど)、エラーならちゃんと一貫してキャリーを立てろ
よなぁ、とも思う。

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

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

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

 しかし、XPの登場で、困ったことになった。ドライブ名すら設定されてない
のに、AXは変だけど、XPはちゃんとキャリーを返すのです。やはりNT系は
駄目なのか……。じゃ、 このキャリーチェックを外してしまえばいい、と
konno さんは考えた(勘かもしれないけど)。外した。うまくいった。目出度し。
2つあったチェックを1つにしてしまったのです。だって元来、MS-DOSだけが
それに引っかかれば良いチェックだったのですから(NT除外)。
 つまり、XPでは完全スルーなのです。でも、いいの。XPならLFNできて
当たり前なんだから。LFNしかないとも言えるOSです。

 因みにNTは、7100h を返してしまいます(くらと談)。LFNの仕様が違っ
たのか、LFNアダプタの仕様が違ったのか、NT内エミュレータが馬鹿だった
のか。Win2K については実験していないので分かりませんが、チェックをゆるめ
た konno 版ならLFNできたような記憶もあります。 ただし、ネットの情報で
は、NTと同じく2000も、7100h を返してしまう。つまり、これが本当なら
konno 版さえLFN表示をできないことになる。そんな報告もあったようです。
 (ということは、理屈だけだけど、Win2KでどうしてもLFN付きVzが使い
たくて、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 版は
試してませんが、このファンクションコールはVzの版の影響を受けず、そのま
ま結果を出してくれます。Vzにおけるファンクションコールとはそういうもの。

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

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

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

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


XP: di返るときあり ^QF (#F)で見て、入ってるよ@XP。
(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 エラー検出法はAXのみ
(2)AX=7100h CF=0

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

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

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


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

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

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


      - No.6299 -    このTreeへ    コメント元:6298 へ [リストへもどる] pre

(6270) 6301冗談  投稿者:文太   2013/04/19(金) 23:40
    6299 番 文太 さんへのコメント

冗談

 「vz.com をですね、起動ドライブのルートにおくこと」というルールを作る
と、compath (pz) で、Vz 内部で "c:\" という文字列を加工なしで得られます。
 セグメントさえ読めたら、余計なバッファを作らず使わず、例のファンクショ
ンが4つのパラミータとともに使えます。あ、ゴミ捨てバッファも必要ですね。
 いえ、何となく思いついてしまったものですから。
 以下の流れです。

> マシンによって対象ドライブを選ばなくてはならない。compath からどっかの
>バッファにコピーして削除して(di="c:\vz\" は駄目なので)と思ったけど、で
>きませーん。di を捨てるためのゴミ捨てバッファも探さなくちゃいけない……。
>セグメントが分からないと、デバックコードが入れられないと、何もできません。


      - No.6301 -    このTreeへ    コメント元:6299 へ [リストへもどる] soft

(6270) 6302Re: 71A0_INT21 について(まとめ)  投稿者:konno   2013/04/20(土) 00:56
    6299 番 文太 さんへのコメント    コメント数 2

>  高橋法はパラミータをAXだけセットして、コールする。そして、キャリーフ
> ラグとAXに 7100h が返ったかどうかを両方チェックする。 どっちかがエラー
> を通知したら、MS-DOS だ、と判断。

これ、正確にはWinかDOSかの判定ではなくて、LFNが使用できるかできないかなので。
DOSでもLFNアダプタを入れればLFN可の判定になります。

>  (むちゃくちゃとはいえ、やはり世界中で、Cでパスカルで、使われていた。)

うーん、これを読んで、やはり高橋さんの方法はLFN判定の標準的な方法だったと
確信しました。(判定法として)

>  つまり、XPでは完全スルーなのです。でも、いいの。XPならLFNできて
> 当たり前なんだから。LFNしかないとも言えるOSです。

XPのDOS窓で非常駐VZのコマンドラインではデフォではLFNを使えないようです。
過去のDOSツールとの互換性の為なんでしょうか。よくわからない仕様です。

>  因みにNTは、7100h を返してしまいます(くらと談)。LFNの仕様が違っ
> たのか、LFNアダプタの仕様が違ったのか、NT内エミュレータが馬鹿だった
> のか。

うーん、文太さん、過去ログななめ読みなんでしょうか。(^^;
NTのDOSにはLFNファンクションが存在しなかったのです。
だから7100h を返してしまっていたのです。NETの検索でLFNアダプタの存在を
知ったからLFNアダプタの力でLFN対応にできたのです。

> NTと同じく2000も、7100h を返してしまう。つまり、これが本当なら
> konno 版さえLFN表示をできないことになる。そんな報告もあったようです。

これは初耳です。初期の2Kだったのでしょうかねぇ。

>  (ということは、理屈だけだけど、Win2KでどうしてもLFN付きVzが使い
> たくて、Win2K環境でしか使わない、つまりMS-DOSでは使わないvz.comでよいのな
> ら、あのチェックルーチンを全部殺してアセンブルすればできる。

あのう、うちのWin2kではLFN使えてますよ。M.Miyataさんも使えていたし、
使えないという話は私は聞いたことがないです。
そして、もしも7100hが返る環境なら、VZで何をやってもLFNは使えないでしょう。

> MS-DOS除外があのルーチンの意味なので。
ここはLFNの環境判定ですってば。(^^;

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

これが高橋版でAXしか指定しなかった理由でしょう。
LFNかどうかを判定するのに存在しないドライブにアクセスしてしまっては
無用なトラブルのもとになるだけですからね。
だから、この手抜きに見える判定法はMSが用意した仕様だと思います。

      - No.6302 -    このTreeへ    コメント元:6299 へ [リストへもどる] soft

(6270) 6303Re^2: 71A0_INT21 について(まとめ)  投稿者:文太   2013/04/20(土) 02:12
    6302 番 konno さんへのコメント    コメント数 1

konnoさん

>DOSでもLFNアダプタを入れればLFN可の判定になります。

 これは僕も考えていました。しかし、例外的でしょう、ここでは。
 そこまで原理的に考えなくて良いと判断しました。LFNアダプタを必要と
している、使っている人はいないでしょう、今? としきさん、かな。

>>  (むちゃくちゃとはいえ、やはり世界中で、Cでパスカルで、使われていた。)
>うーん、これを読んで、やはり高橋さんの方法はLFN判定の標準的な方法だったと
>確信しました。(判定法として)

 すいません、自分で書きながら曖昧な書き方をしてるな、と思っていました。
だから、この文を基準に「確信」しないでほしいのです。あのファンクションを
DOSとWIN環境の差異の判別に使うのはCもパスカルも同じです。ただ、3つ
のパラミータを除外するという方法が、標準的手法だとは僕は確認していません。
 興味がおありでしたら、確認していただけると助かります。

>>  つまり、XPでは完全スルーなのです。でも、いいの。XPならLFNできて
>> 当たり前なんだから。LFNしかないとも言えるOSです。
>XPのDOS窓で非常駐VZのコマンドラインではデフォではLFNを使えないようです。
>過去のDOSツールとの互換性の為なんでしょうか。よくわからない仕様です。

 試してみますので、もう少し情報をいただけますか。
 ここに一番に注目したし、注意を引かれました。実際的な不具合の可能性です
から。
 konno版を使い、どういう風にLFNが使えないのでしょうか。
 Vz経由のLFNの話なので、非常駐でファイルが1枚あいた状態でコマンド
ラインのおりて、どうすると、LFNが使えないと感じられる場面があるのか
分からないんです。

>>  因みにNTは、7100h を返してしまいます(くらと談)。LFNの仕様が違っ
>> たのか、LFNアダプタの仕様が違ったのか、NT内エミュレータが馬鹿だった
>うーん、文太さん、過去ログななめ読みなんでしょうか。(^^;

 はい。ななめどころか縦に読んでいます。

>> NTと同じく2000も、7100h を返してしまう。つまり、これが本当なら
>> konno 版さえLFN表示をできないことになる。そんな報告もあったようです。
>これは初耳です。初期の2Kだったのでしょうかねぇ。

 曖昧でちゃらんぽらんな書き方ですね、すいません。
 ネットで、「Win2Kが7100h を返してしまう」と読みました。ななめ読みです。
僕も経験も見聞もありませんでした。
 すいませんが、それでもこれは重要ではないので、スルーしてください。

>あのう、うちのWin2kではLFN使えてますよ。M.Miyataさんも使えていたし、
>使えないという話は私は聞いたことがないです。

 上と同じくスルーしてください。

>> MS-DOS除外があのルーチンの意味なので。
>ここはLFNの環境判定ですってば。(^^;

>DOSでもLFNアダプタを入れればLFN可の判定になります。
 と同じ意味ですよね。特殊な例外かと考えていました。

 「LFNの環境判定」というのは、LFNDOSとかDOSLFNというような
としきさんが得意な分野の、やっぱり特殊と思えるLFNアダプタの話を除けば、
純ドスかWinかの判定のためのルーチンですよね。もちろん、アダプタの入った
特殊環境にも適応できるようであったほうがいい。でも、たとえば高橋さんがあれら
のルーチンを組み込んだとき、それは想定されていませんでしたよね。


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

>これが高橋版でAXしか指定しなかった理由でしょう。
>LFNかどうかを判定するのに存在しないドライブにアクセスしてしまっては
>無用なトラブルのもとになるだけですからね。

 正直にいうと、そこまでちゃんと高橋さんが読めていたのか僕には分かりません。
 しかし、どっちでもいいというのが僕の結論です。ラッキーだったのだと。
 そして、その「ラック」の意味を我々はここで確認しようとしてるのんじゃない
んですかね。ちがうのかな。

>だから、この手抜きに見える判定法はMSが用意した仕様だと思います。

 いえ、MSはそんなことを考えていたとは僕には思えません。だったら、もっと
ちゃんと一貫性のある実装を、各OSでしてしたと思う。
 これは、上の「やはり世界中で、Cでパスカルで、使われていた」という部分に
引きづられているように思います。僕の言葉にひっぱられたように思えます。
 僕の言葉に惑わされないでください、お願いします。
 でも、これもどっちでもいいことだと僕は考えています。


(繰り返しですが)
>XPのDOS窓で非常駐VZのコマンドラインではデフォではLFNを使えないようです。

 ここだけ、条件をいただけますか。「デフォ」の意味が分かりません。XPで
LFNアダプタの話はないでしょうし……。
 command.comのことなのか、とも思えますが。
 ここにkonnoさんの釈然としない気持ちがあるんでしょう?

      - No.6303 -    このTreeへ    コメント元:6302 へ [リストへもどる] soft

(6270) 6304Re^3: 71A0_INT21 について(まとめ)  投稿者:としき   2013/04/20(土) 13:24
参照先:http://www1.hinocatv.ne.jp/toshiki/
    6303 番 文太 さんへのコメント    コメント数 1

#6299のまとめですが、よくまとまってますね。
#6302のkonnoさんのレスと併せて読む必要がありますが。

>  そこまで原理的に考えなくて良いと判断しました。LFNアダプタを必要と
> している、使っている人はいないでしょう、今? としきさん、かな。

私、今でも時々はDOS上でLFNを扱うこともあります。
でも、以前に比べて大幅に頻度は下がりました。
だって、生DOSで使いたくなる場合というのはWinなOSのマシンとのデータの授受
を行う場合です。でも、生DOSではUSBメモリが使えませんから、FDDかMO、または
メモリカード経由のときだけなのです。すると今度は、Winなマシンでそういった
メディアを使うことが難しいといった理由からデータのやり取りの頻度が著しく
落ちてしまったのですよ。

> >うーん、これを読んで、やはり高橋さんの方法はLFN判定の標準的な方法だったと
> >確信しました。(判定法として)
> DOSとWIN環境の差異の判別に使うのはCもパスカルも同じです。ただ、3つ
> のパラミータを除外するという方法が、標準的手法だとは僕は確認していません。

標準というのがデファクトとしてという意味ならkonnoさんの表現も一理あるかも
しれません。でも、MSが提示していたかどうかという意味であれば、文太さんの
考え方のほうに一票入れさせていただきます。

>  Vz経由のLFNの話なので、非常駐でファイルが1枚あいた状態でコマンド
> ラインのおりて、どうすると、LFNが使えないと感じられる場面があるのか
> 分からないんです。

コマンドラインに降りて、dir[RET]と叩くだけです。
Vzからのアクセスでは問題なくLFNが使えている模様。
konnoさんのおっしゃっているように、過去のDOSツールとの互換性の問題なんで
しょうかね。

> >これは初耳です。初期の2Kだったのでしょうかねぇ。
>  すいませんが、それでもこれは重要ではないので、スルーしてください。

実質的に、該当するユーザがほとんどいないであろうという意味で重要でないと
いう点には同意します。でも、例えば、プログラムを作る側が、できるだけ多く
の環境で正常に動くものを作りたい、と考えた場合、これはとてつもなく重要に
なってきます。
ちなみに、私の経験でも、Win2kではVzでLFNが使えていました。

> 純ドスかWinかの判定のためのルーチンですよね。もちろん、アダプタの入った
> 特殊環境にも適応できるようであったほうがいい。でも、たとえば高橋さんがあれら
> のルーチンを組み込んだとき、それは想定されていませんでしたよね。

ここは、私、konnoさんのほうに一票。
Winで使うという意味であれば、ちゅ〜パッチでもそこそこ使えていたのです。
だけど、きちんとLFNに対応させたい、というのが高橋さんの意図だったと考えて
います。

> >> の使い方をする場合(コメントアウトなし)、FDDにアクセスします。"b:\"
> >> とかするとMEの場合、マシンが落ちます。 モバで "c:\" とすると("a:\" で
> >> なければいけない)、システムがぐちゃぐちゃになります。
> >これが高橋版でAXしか指定しなかった理由でしょう。
> >LFNかどうかを判定するのに存在しないドライブにアクセスしてしまっては
> >無用なトラブルのもとになるだけですからね。

ドライブの存在確認の方法もありますがね。
コードが膨らむからなぁ。高橋さんは嫌うだろうなぁ。
ところで、MEでも、USBフロッピーなんかをつないできちんとBドライブを設けて
やれば、マシンが落ちないですむのですよね?
      - No.6304 -    このTreeへ    コメント元:6303 へ [リストへもどる] soft

(6270) 6306Re^4: 71A0_INT21 について(まとめ)  投稿者:文太   2013/04/20(土) 15:20
    6304 番 としき さんへのコメント    コメント数 1

としきさん、

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

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

>高橋さんの方法はLFN判定の標準的な方法だった(konnoさん)
> DOSとWIN環境の差異の判別に使うのはCもパスカルも同じです。ただ、3つ
> のパラミータを除外するという方法が、標準的手法だとは僕は確認していません。
(文太)

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

 1つのパラミータ指定法という意味ですか? いちおう1パラメータ法のコー
ドをネットで探したのですが、見つかりませんでした。一昨日ぐらいまでは、別
のファンクションでやれなのかなぁ、と考えていた。
 ブラウンリストの 71A0h 部分をじいっと見たのですが、ヒントのかけらもあ
りませんでした。
 『Windows9xのDosの秘密』の著者吉野さんが、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

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

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

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

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

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

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

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

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

 美風呂ぐらい古いマシンだとUSB・FDはBドライブには入りませんが
(F:だった)、もちろん、マシンは落ちませんでした。

      - No.6306 -    このTreeへ    コメント元:6304 へ [リストへもどる] pre

(6270) 6308Re^5: 71A0_INT21 について(まとめ)  投稿者:としき   2013/04/20(土) 19:24
参照先:http://www1.hinocatv.ne.jp/toshiki/
    6306 番 文太 さんへのコメント    コメント数 1

>  これは現実的にそういうものなんですよね。だから、MS-DOSから無線ラン。
>  試してるでしょうけど、USBに生ドスからのアクセスは可能な場合がありますよ。

生DOSからネットワーク接続は、ごく普通に行っていますね。
日常的に生DOSを操作していない現状ではありますが、もしも、日常的に生DOSを
操作することになれば、毎日のように行うことでしょう。
なお、私が生DOSで扱っているマシンにはUSBポートがありません。
だって、古いPC-98ですから。
USBポートのあるAT互換機はいくつもありますが、残念ながら、それ用のDOS/Vは
版権を保有しておりません。
あ、PC-98でも、コンパクトフラッシュ等のメモリカードならアクセス可能です。
でもって、USBなカードリーダライタも持っていますので、そういうものを使って
データ交換はできております。

>  なるほど。これ、おいしいじゃないですか。素晴らしい仕様。
>  上の昔風のほうが見やすいと思うけど。何で順番を変えるんだ>MS

やっぱり、長い名前対応でしょう。
ファイル名が最終フィールドなら、長い名前を最後まで表示しても、表示の崩壊
を最小限にとどめられますから。
      - No.6308 -    このTreeへ    コメント元:6306 へ [リストへもどる] soft

(6270) 6309Re^6: 71A0_INT21 について(まとめ)  投稿者:文太   2013/04/21(日) 00:37
    6308 番 としき さんへのコメント    コメント数 2

としきさん

>だって、古いPC-98ですから。

 これは想定外。そうか、そうか、これが仕事場から資料ファイルを持ってくる
落ち着き先の生ドス機か。
 うん、データ移動でやれることは限られているでしょうね。

 あ、旧8のドス機でも、アダプタさえ入れば、LFNのファイルが無事格納
できるわけですね。LFN対応ドス用エディタなら(Vzのこと)、LFNを
壊さずに編集できるわけですね。RCP16のLFN対応版をリクエストしてましたっけ。
でも、考えてみたら、いろいろときつい環境だ。すいません、笑ってます。
 やるねぇ、ほんとに。

 お気づきかもしれませんが、うん、あのドライブを指定してドライブごとに
確認するという、例のファンクションの意味がどうも実感できなくて。
 NECのDos5くらいのマシンでも、LFNアダプタが入れば、普通にLFN
のファイルが格納できるのですよね。純粋なる好奇心からの単純な質問です。
宜しければお教えください。
 すると、モバにもLFNファイルか。よく分かんない……。モバでロング・
ファイラ? オアポケに入ってるの? LFNアダプタ?
 こうなると、DOS/Winの判定と、LFN/nonLFNの判定は、まったく違ったものに
思えてくる……。納得。

 なんだか笑いが抑えられない……。す、すげえなぁ、と。

 いえ、なんか昔のNS/Rだったっけ、自分が所有していたDos用NECノ
ートにLFNファイルがSFNファイルと同居するというのがうまくイメージで
きませんで。うん、でも、フロッピーでは平気でできてるのに当たり前だと思っ
てるなぁ……。
 じゃあなんで、そもそもドライブ指定が必要なんでしょう? システムというか
OS(+LFNアダプタ)が対応してれば済むような気がするのだけど。

 なんだか、少ーし、LANの話に似てきた。

>生DOSからネットワーク接続は、ごく普通に行っていますね。

 としきさんなら当然でしょう。でも無線じゃないよね。いえ、ノートにケーブル
を付けたり外したりが、現実的に面倒そうで。
 無線でも有線でも、できたことないのだけど。

>なお、私が生DOSで扱っているマシンにはUSBポートがありません。
 ち、致命的。し、失礼しました。(笑)

>残念ながら、それ用のDOS/Vは版権を保有しておりません。
 メールのほうがいい内容ですが、1つあげましょうか。僕はライセンスを3つ
持っていることになってます。Dos6.2V。2つ以上は意味がないと思うけど。
 昔、マニュアルを3セットもっていたもの。ライセンスを証明するため、みた
いなつもりで。誰に証明するんだ?!
 マシンとともに大昔、情報処理演習室からもらったもの。たしか 600MB HD の
マシンで、Windows95 が動いたり動かなかったりしました。CPU その他は記憶に
ないです。当時、気になったスペックはHDの大きさだけだった。

 そういえば、VTDOS のデビュー初期に、どの command.com かで騒ぎがありま
したねぇ。

>>  上の昔風のほうが見やすいと思うけど。何で順番を変えるんだ>MS
>やっぱり、長い名前対応でしょう。

 そっか、考えつかなかった。多謝。高橋さんもファイラのレイアウトで悩んで
いて、とらじさんが長すぎたら画面の右端で最後を切ればいいと提案し、採用! 
と言ってました。現在のVzファイラも右側にLFNファイル名だった。滅多に
見ないのですが。

 ふと思い立ち、使えるようになってやるぞいと思っているWindows用ファイラ
3種を確認しました。afx, dyna, dfなのですが(どれもお勧め)、テキストベース
の基本アイコンのない2画面ファイラ(玄人キーボード派用)。どれも、cmd.exe
方式でなく、command.com方式だった。それで、一目みて、深い安心感を覚えたん
ですね。左端にファイル名で長いのは切ってある。
 あと、ランチャは、craftlaunch。もうすぐMoonlightを追い出すことになるで
しょう。
 しかし、どれも開発末期に近そう……。craftlaunchは、Win7/64bit対応版に
なってる模様。でも、どれもWin9x用のヴァージョンもあった。
 頑固者あるいは怠け者な私。

      - No.6309 -    このTreeへ    コメント元:6308 へ [リストへもどる] soft

(6270) 6320修正  投稿者:文太   2013/04/23(火) 15:39
    6309 番 文太 さんへのコメント


> お気づきかもしれませんが、うん、あのドライブを指定してドライブごとに
>確認するという、例のファンクションの意味がどうも実感できなくて。

 ちがうよ、文太くん。質問というか疑問の持ち方が、逆立ちしてしまってます。
 LFN可不可のチェックだけするファンクションは存在しないのです。LFN
的作業をする過程でなされるチェックなのです。
 ディスクを対象にしない 70xx のファンクションはないのじゃない? LFN
関連のファンクションなんだから。

      - No.6320 -    このTreeへ    コメント元:6309 へ [リストへもどる] soft

(6270) 6322LFNアダプタの効果  投稿者:文太   2013/04/23(火) 16:08
    6309 番 文太 さんへのコメント


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

      - No.6322 -    このTreeへ    コメント元:6309 へ [リストへもどる] pre

(6270) 6307Re^2: 71A0_INT21 について(まとめ)  投稿者:文太   2013/04/20(土) 15:21
    6302 番 konno さんへのコメント    コメント数 1

konnoさん、

 総じて、実際上の不具合がないのだからいいじゃないか、という気分でいます。

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

 パラミータ1つで機能してきたんだからいいじゃないか、とやっぱり逃げ腰で
思ってます。
 パラミータ1つの高橋法と同じようなのをCとパスカルで探したつもりなので
すが、−−少なくともこのファンクションを使ったコードの一部があったような
記憶だった−−見つかりませんでした。
 そして、純ドス環境であのルーチンは使われないはずなので(LFNDOS除く)、
チェックが2つから1つにしてあったって問題ないとも。 たとえ、LFNDOS 的な
環境でも問題ないでしょう? テストしないと何ともでしょうけれど。


 以下、モゴモゴ。

 ドライブを指定して機能するファンクションであるということは、複数ドライ
ブでLFN可能・不可能な状態、システムがありうる、ということですよね。
ネットワークか……。
 ただ、 Vzerの Windows 環境だと、そんなのあり得ない(無理をすれば、
MS-DOS と Windows のデュアルブート? 両方 FAT16)。ずっとあり得るのは
複数の違ったマシンで、LFN環境が違うということ。LX(LFN不可)と
WinXP(LFN可)で同じ vz.com を使う場合。

 ただ問題の在処に僕が気がつき始めたのは、VTDOS で高橋版にLFNを可能に
してくれっぽいことを konno さんが 10# さんに訊いてときなんです。訊ねてい
るのを僕が読んだとき、が正確。
 でも、いちおう我々のこのファンクションについての理解が大雑把に合ってい
るとして、 高橋版がXP/7/8でLFNできる VTDOS が製作されても(1つ
のパラミータでもきっとキャリーを立てない)、その高橋版はアイドルができず、
あんまり意味がないのじゃないですか。

 もっと正確につっこんでしまうと、 このパラミータ1か4か問題を konno さ
んは、10# さんに解決あるいは解説してほしかったのかな、と考えています。
 ただ、ずうずうしいというか、恥知らずというか、無礼というか何なんですが、
僕が konno さんのスキルレベルにあったら、4つのパラミータを入れた Vz を
アセンブルして、理由を説明して(たぶん)、としきさんとめざらさんにテスト
をお願いしちゃっていたと思うけど。あるは私家秘蔵版としてしばらく自分で試
してみる……。

 話が前後しますが、今や僕はこれが大事(おおごと)ではまったくない、と確
信し納得しています。まず、僕には(多くのVzerにとっても、たぶん)LFNは
それほど重要ではない。代替手段はいくらでもある。次に MS-DOS 環境では、ほ
とんどLFN的コマンドは発行されない(間違って発行されることがない)。最
後に、チェックルーチンを緩めたからXPでLFNできているので、そもそも
LFNできる環境なんだから、チェックがなくてもいい。これぐらいです。
「そこまで原理的に戻らなくたって」という僕の発言の理由です。


 思い出したのですが、konno さんは、このNT系LFN実現の方法と有効性に
関して、いつも「よく判らない」と口を濁して回答してましたよね。新しいとこ
ろでは、あじゃさんにそう答えていました。この個別の例はきっと記憶にないで
しょうけれど。でも、これが何となく座りが悪い、不安を覚えていた理由でもあ
るんですよ。実際、konno さんも座りの悪い思いをしてるんだろうな、と僕が思
った理由です。

 こうこうこういう訳で「よく判らない」と言ってしまえばよかったのに、と少
し思っています。が、ここにきて、「判らなさ」の輪郭は理解できました。僕に
とっては収穫だったと思っています。不安はありません。ありがたいことだと思
っています。


      - No.6307 -    このTreeへ    コメント元:6302 へ [リストへもどる] soft

(6270) 6311Re^3: 71A0_INT21 について(まとめ)  投稿者:konno   2013/04/21(日) 00:46
    6307 番 文太 さんへのコメント    コメント数 2

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

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


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

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

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

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

;"""""""""""""""""""""""""""""""""""""""
; 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の仕様だからです。

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

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

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

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

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

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

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

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

      - No.6311 -    このTreeへ    コメント元:6307 へ [リストへもどる] pre

(6270) 6314Re^4: 71A0_INT21 について(まとめ)  投稿者:文太   2013/04/21(日) 15:23
    6311 番 konno さんへのコメント    コメント数 1

konnoさん

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

 よかったです。僕も遅ればせながら、精一杯の確認をして、ちょっとだけ勉強して、
安心しました。

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

 なるほど。ダウンレベル(down levelですが)も了解です。

>ついでに、「いきちがいのぷろぐらむあ」さん

 面白い。まったくヒットしてませんでした。VTDOSに注意が行ってないからなん
でしょう。
 古いマシンネタも楽しいですね。

>dos環境がLFN対応しているかどうかを判別する
>ax=71a7h; int 21h (win32なファイル時間をdosファイル時間に変換する
>LFN用システムコール)を実行してみて、エラーがax=0x7100になるかどうか

 これを考えていたのです。71A0って、標準だとI/Oアクセスしちゃいますよね。

>>  もっと正確につっこんでしまうと、 このパラミータ1か4か問題を konno さ
>> んは、10# さんに解決あるいは解説してほしかったのかな、と考えています。
>なぜそう思うのかが理解できませんね。私の発言は、95/98とXPで違いがあるので
>TVZ用に(つまり95仕様に)対応する気が無いか聞いてみただけです。

 失礼なのですが、質問があります。
 なぜ、TVZ用が必要だと思うのでしょう? KVZはTVZの進化形なのに。
 KVZで「95仕様」になっていないのですか? エラーチェックを緩めて95仕様に
もなってると思っていたのですが。
 「95/98とXPで違いがある」のですが、それを吸収したのが、KVZではない
んでしょうか?
 簡単にご説明いただければ幸いです。

 あと、MS-DOSの仕様ですが、95/98とXPとふらふらしまくりましたよね。
 ま、世間的に問題にならないのと、MSとしても、そんなことにつき合って
られない、というところなんだろうとは思いますけれど。レガシーだしエミュレータ
だし。

      - No.6314 -    このTreeへ    コメント元:6311 へ [リストへもどる] soft

(6270) 6316Re^5: 71A0_INT21 について(まとめ)  投稿者:konno   2013/04/22(月) 00:51
    6314 番 文太 さんへのコメント    コメント数 1

>  これを考えていたのです。71A0って、標準だとI/Oアクセスしちゃいますよね。

ファイル操作関連なら皆そうでしょう。まして71xxはロングファイルネームがらみ。
システム側はパラメータが不正でないかのチェックはしてるから、不正だったら
キャリーが返るでしょう。その場合はi/oアクセスはしないで戻る。

これがDOSの仕様ですが、95でcfが立たないのは判定用に使うための例外か。
もし、偶然でもパラメータが通ったらi/oアクセスが起こる。
だから、判定の為だけなら無害な番号を使うのでしょう。想像ですが。

>  なぜ、TVZ用が必要だと思うのでしょう? KVZはTVZの進化形なのに。

もちろん私には必要ありません。使いたいという人がいるかもしれないと思っただけです。

>  KVZで「95仕様」になっていないのですか? エラーチェックを緩めて95仕様に
> もなってると思っていたのですが。

分かりきっている質問をなぜするのかがわからなかったんですが、忘れていると言う事?
TVZは95仕様。KVZは95+NT系仕様。で答えになっていると思うんですが。

私はいろいろよく忘れるのでしょっちゅう再履修です。文太さんもですかぁ。(^^;

      - No.6316 -    このTreeへ    コメント元:6314 へ [リストへもどる] soft

(6270) 6318Re^6: 71A0_INT21 について(まとめ)  投稿者:文太   2013/04/22(月) 01:27
    6316 番 konno さんへのコメント    コメント数 1

konnoさん

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

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

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

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

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

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

追記

清十郎さん資料、741行目付近
mov cx,5
lea dx,[di].VI_RootName
MSDOS 71a0h ;ボリューム情報の取得

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


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

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 が例。前後の繋がり不明。ないと思う。

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

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


      - No.6318 -    このTreeへ    コメント元:6316 へ [リストへもどる] pre

(6270) 6321まとめ3  投稿者:文太   2013/04/23(火) 15:50
    6318 番 文太 さんへのコメント    コメント数 1



;--- 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


 パラミータは4つでなく3つでOKでした。上が最大限の裏技なのかもしれ
ません。

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

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

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

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

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

      - No.6321 -    このTreeへ    コメント元:6318 へ [リストへもどる] pre

(6270) 6323Re: まとめ3  投稿者:konno   2013/04/24(水) 00:00
    6321 番 文太 さんへのコメント    コメント数 1

>  パラミータは4つでなく3つでOKでした。上が最大限の裏技なのかもしれ
> ません。

ああ、ついにソースが白日の下に。(^^;
私のいいかげんさがばれてしまいましたね。すみませんでした。m(__)m

>  いえ、すいません、もともとの konno さんのマクロがバグってました。 高橋
> 法は3つのパラミータで cx ゼロです。文字列を返させない。これで機能するこ
> は確認したのでしょう。

文太さんのマクロのcxをゼロにしても、cf0 になるみたいですが、何か間違えてます?
NT系でcf0ならTVZがLFNできると思うんですがねぇ。
ここまできたら、XPでTVZがLFNできない真相を文太さんにあばいてもらいたいですね。


# (資料を)ひかぬ!! こぴぬ!! かえりちみぬ!!

      - No.6323 -    このTreeへ    コメント元:6321 へ [リストへもどる] soft

(6270) 6326Re^2: まとめ3  投稿者:文太   2013/04/24(水) 10:14
    6323 番 konno さんへのコメント    コメント数 1

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できない真相を文太さんにあばいてもらいたいですね。

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

      - No.6326 -    このTreeへ    コメント元:6323 へ [リストへもどる] pre

(6270) 6327Re^3: まとめ3  投稿者:文太   2013/04/25(木) 00:16
    6326 番 文太 さんへのコメント    コメント数 1

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

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

      - No.6327 -    このTreeへ    コメント元:6326 へ [リストへもどる] pre

(6270) 6329まとめ4  投稿者:文太   2013/04/25(木) 13:06
    6327 番 文太 さんへのコメント    コメント数 1


=== Macrotmp by B ===;
高橋版(T)とkonno版(K)の違いを見る:なぜkonno版はNT系でLFNが可能なのか。
前提:このマクロがどの版のVz上で使われるかは問題にならない。
 オリジナルc.mos版上でも、同じ結果を出す。マクロの中のファンクションコール
 とそのVzがLFNに対応しているかは別の話。
  :キャリーは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)

*

---------------------------------------------------------------------------
(おまけ)

高橋版LFN関係(資料)

 ちゃんと集中してればすぐ調べられるはずなのだけど、すぐ忘れるので。
 ダウンレベルが話題になったついでです。
 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


      - No.6329 -    このTreeへ    コメント元:6327 へ [リストへもどる] pre

(6270) 6331Re: まとめ4  投稿者:konno   2013/04/26(金) 01:17
    6329 番 文太 さんへのコメント    コメント数 1

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

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

> 高橋版(T)とkonno版(K)の違いを見る:なぜkonno版はNT系でLFNが可能なのか。

と言いながら、高橋版の判定部分がコメントになっていますね。(^^;
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


      - No.6331 -    このTreeへ    コメント元:6329 へ [リストへもどる] pre

(6270) 6332Re^2: まとめ4  投稿者:文太   2013/04/26(金) 10:34
    6331 番 konno さんへのコメント    コメント数 2

konnoさん

>文太さん、確認用のマクロをありがとうございます。
 というわけで、少し思い出していただけたようで何よりでした。
 だから、VTDOSが高橋版に対応する必要はあまりないでしょう? 
 考え方によりけりですけれど。

      - No.6332 -    このTreeへ    コメント元:6331 へ [リストへもどる] soft

(6270) 6333Re^3: まとめ4  投稿者:文太   2013/04/26(金) 23:22
    6332 番 文太 さんへのコメント

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

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

;--- 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:

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

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


      - No.6333 -    このTreeへ    コメント元:6332 へ [リストへもどる] pre

(6270) 6335Re^3: まとめ4  投稿者:konno   2013/04/28(日) 00:52
    6332 番 文太 さんへのコメント    コメント数 1

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

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

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

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

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

=== 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を抜き出した。

*

      - No.6335 -    このTreeへ    コメント元:6332 へ [リストへもどる] pre

(6270) 6336Re^4: まとめ4  投稿者:文太   2013/04/28(日) 01:35
    6335 番 konno さんへのコメント    コメント数 1

konnoさん

>もう毎日が再履修みたいになってますね。(^^;
 す、すいません。Vzを愛するがゆえということでお許しください。m(__)m

>> だから、VTDOSが高橋版に対応する必要はあまりないでしょう? 
>改造作者としては動作検証用に起動するだけですから、
 いいですよ、konno版が現在のVzなんですから。申し上げましたとおり、
いくら高橋さんを尊敬してるといっても、今は、僕は、あらゆる箇所でkonno版に
なっていますので、そうでないと困ります。

>ということで、tVZ仕様準拠のvz_env.def v06です。
 了解。表示系を一部書き換えさせていただきました。結果は以下です。

 by vz_env.def v06

XP:
psp=VZ mcb=Z Ver=5.0 LFN=1 ax00EAh cf1 idle=1

ME:
psp=VZ mcb=Z Ver=8.0 LFN=1 ax0200h cf0 idle=1

 納得のいく結果でした。ネイティブなXPとMEです。EmsMagic環境だと、
mcb=M となっても健康ですよね。あまり試していないので、不安がなくはない
ですが>EmsMagic。万能じゃないです。
 しかし、XP環境がこうも違っているなんて、知りませんでした。
ME最高です! って、まいったなぁ。

 おやすみなさい。m(_'B'_)m


      - No.6336 -    このTreeへ    コメント元:6335 へ [リストへもどる] soft

(6270) 6337まとめ5  投稿者:文太   2013/04/28(日) 12:56
    6336 番 文太 さんへのコメント    コメント数 1

konnoさん(というより将来の自分へ)

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

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

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

 このマクロはVzが置かれる環境を示します。どの版のVz上でこのマクロが
実行されているかは関係ありません。このマクロが示す環境において、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は、Vzが置かれている環境以上に、konno
版での使用可能不可能を示しています。

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

 「環境」に2つの意味があるわけです。Vzがおかれる環境(dos, 9x, NT, VTDOS)
と、環境の一部であろうVzの版。

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

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


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

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

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

 最後の○×は、状態を正しく伝えているかの適不適。しかし、どれも仕様と言え
そう。この環境に、Vzのほうが合わせるしかない。konno版は合ってます。
      - No.6337 -    このTreeへ    コメント元:6336 へ [リストへもどる] pre

(6270) 6339Re: まとめ5  投稿者:konno   2013/04/29(月) 00:13
    6337 番 文太 さんへのコメント    コメント数 1

> 生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

      - No.6339 -    このTreeへ    コメント元:6337 へ [リストへもどる] pre

(6270) 6340Re^2: まとめ5  投稿者:文太   2013/04/29(月) 21:09
    6339 番 konno さんへのコメント    コメント数 1

konnoさん

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

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

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

=== Macrotmp by B ===;
INT 21の欠番ファンクションの結果を見る。
 ・XPではキャリーが立ち、4行目で昇天しました。
 ・DOSでもキャリーが立つこととがあり、4行目で昇天しました。
* 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 美風呂で試したところ(ドス・モード)、1台だけですが、キャリーが
立ち、7100h が返るという模範生のような振る舞いでした。ただ、美風呂は過去
の経緯をみても、模範生的な場合が多いようです。

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

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

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


      - No.6340 -    このTreeへ    コメント元:6339 へ [リストへもどる] pre

(6270) 6341Re^3: まとめ5  投稿者:konno   2013/04/29(月) 23:02
    6340 番 文太 さんへのコメント    コメント数 1

>  仕様じゃないようです。そんなに頑強には作られていない模様。だって、ファ
> ンクションコールに入門したころ、マシンが落ちませんでした? 僕はどういう
> 間違いだったか分かりませんが(ret なしのマシン語プログラムとか)、落とし
> まくりました。XPに感謝したものです。何かの記憶違いでしょう。

うーん、文太さん、私の言いたいことが全然伝わってないようですね。私は、
>生DOSでAXに未登録の番号を入れて呼ぶとAXはそのまま、あるいは特定の番号が返る。
>その場合はキャリーは立たない。というのがDOSの仕様だと思います。
と言いました。

文太さんの上の文章ではマシン語の例を言ってますね。ファンクションコールとは違う。

>  キャリーが立つ場合もあるようでした。
>  以下のような実験結果でした。

えーと、全部は多すぎるので、一部だけ。(^^;

> 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

これらの番号はDOSで予約登録済みの物ですね。なので、axだけで呼んだ結果は
それぞれの番号での処理によります。なかには落ちる場合もあるでしょう。
ブラウンリストに載っています。
INT 21 4300 - DOS 2+ - GET FILE ATTRIBUTES
INT 21 4400 - DOS 2+ - IOCTL - GET DEVICE INFORMATION
INT 21 5700 - DOS 2+ - GET FILE'S DATE AND TIME
INT 21 5D00 - DOS 3.1+ internal - SERVER FUNCTION CALL

> ax=$4400, &i($21) &?("CF=%d AX=%04xh",r,ax) #m

これ、&? を &m に変えたら、cf0 でしたよ。

ブラウンリストに載っていない、7400h、7800h、7900hなどは、ax がそのまま返り
cf0 でした。Win7DOS窓で。

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

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

>  Win98 美風呂で試したところ(ドス・モード)、1台だけですが、キャリーが
> 立ち、7100h が返るという模範生のような振る舞いでした。

これ、&mでも、cf1 になりますか?

      - No.6341 -    このTreeへ    コメント元:6340 へ [リストへもどる] soft

(6270) 6342Re^4: まとめ5  投稿者:konno   2013/04/29(月) 23:40
    6341 番 konno さんへのコメント    コメント数 1

> > ax=$4400, &i($21) &?("CF=%d AX=%04xh",r,ax) #m
> これ、&? を &m に変えたら、cf0 でしたよ。

すみません、これ、&? でも同じでしたね。

ax=$4400  CF=0 AX=80D3h
ax=$5700  CF=0 AX=5700h

Win7DOS窓ではこうなりました。
もしかしたらXPと違うところがあるかもしれませんね。
VTDOSもエミュレータなので、違いがあるようです。

やっぱりこういうテストは実機が無いとだめですね。

      - No.6342 -    このTreeへ    コメント元:6341 へ [リストへもどる] soft

(6270) 6344Re^5: まとめ5  投稿者:文太   2013/04/30(火) 01:16
    6342 番 konno さんへのコメント    コメント数 1

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の仕様
に準じてる、ということですね。
 すると、キャリーを立ててしまうXPが、相当過去を無視してる、ということに
なりますか。


      - No.6344 -    このTreeへ    コメント元:6342 へ [リストへもどる] pre

(6270) 6345Re^6: まとめ5  投稿者:文太   2013/04/30(火) 14:10
    6344 番 文太 さんへのコメント    コメント数 1

konnoさん

=== Macrotmp by B ===;
未登録番号のファンクションのキャリーとAXを見る。
* 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

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

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

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

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


      - No.6345 -    このTreeへ    コメント元:6344 へ [リストへもどる] pre

(6270) 6346拡張ファンク57xxの返り値  投稿者:文太   2013/04/30(火) 23:33
    6345 番 文太 さんへのコメント    コメント数 1

拡張ファンク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

 上の総合的な印象は、XPとDosがそれぞれの流儀で正しそう。MEと
98は、どうして半分で割れるのよ、という感じ。

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

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

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

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

      - No.6346 -    このTreeへ    コメント元:6345 へ [リストへもどる] pre

(6270) 6348Re: 拡張ファンク57xxの返り値  投稿者:konno   2013/05/01(水) 01:25
    6346 番 文太 さんへのコメント    コメント数 1

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

> 未登録番号のファンクションのキャリーとAXを見る。
> 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の未使用番号です。
当然返り値も振る舞いも違ってきます。

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

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

>  上の総合的な印象は、XPとDosがそれぞれの流儀で正しそう。MEと
> 98は、どうして半分で割れるのよ、という感じ。
>  MS-DOSでキャリーが立たず、5700hなんてのが返るのを期待していました。

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

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

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

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

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

      - No.6348 -    このTreeへ    コメント元:6346 へ [リストへもどる] pre

(6270) 6349Re^2: 拡張ファンク57xxの返り値  投稿者:文太   2013/05/01(水) 01:37
    6348 番 konno さんへのコメント    コメント数 1

konnoさん

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

 ありがとうございました。おそらく納得できると思います。願わくば理解も
できるのではないかと思っております。
 大変勉強になりました。m(__)m


      - No.6349 -    このTreeへ    コメント元:6348 へ [リストへもどる] soft

(6270) 6350Re^3: 拡張ファンク57xxの返り値  投稿者:文太   2013/05/01(水) 03:10
    6349 番 文太 さんへのコメント    コメント数 1

=== Macrotmp by B ===;
未登録と思われるファンクションをコールして、
キャリーが立たず、AXを見るテスト。
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の仕様だと思います。

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

 良きGWを。

      - No.6350 -    このTreeへ    コメント元:6349 へ [リストへもどる] pre

(6270) 6352Re^4: 拡張ファンク57xxの返り値  投稿者:konno   2013/05/01(水) 23:41
    6350 番 文太 さんへのコメント    コメント数 2

> 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レジスタに入る2桁、00h〜FFh です。
下2桁の、alレジスタの番号は、補助番号ということです。
4桁のものは、一つの機能(番号)のグループと考えた方がいいでしょう。
4桁だから拡張と言うわけではありません。

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

      - No.6352 -    このTreeへ    コメント元:6350 へ [リストへもどる] pre

(6270) 6354Re^5: 拡張ファンク57xxの返り値  投稿者:文太   2013/05/02(木) 12:26
    6352 番 konno さんへのコメント    コメント数 1

konnoさん

 大変に丁寧なご説明、ありがとうございました。

>私の説明はそんなにわかりにくいのかなぁ。

 いえ、本気をだせば、大丈夫です。明晰でとても分かりやすい説明でした。
 滅多に本気をださないような気もしますけれど。説明に関して。(^^;

 ではでは。
 お疲れさまでした。m(__)m

      - No.6354 -    このTreeへ    コメント元:6352 へ [リストへもどる] soft

(6270) 6358Re^6: 拡張ファンク57xxの返り値  投稿者:konno   2013/05/02(木) 23:23
    6354 番 文太 さんへのコメント

文太さん

>  滅多に本気をださないような気もしますけれど。説明に関して。(^^;

読み返してみると、確かに手抜きな説明でしたね。。(^^;
文太さんのレベルならこのくらいは分かっているだろう、という思い込みがあって
何処で引っ掛っているか気が付いていなかったというか、気が回らなかったというか。

基本的に説明が下手なのは自覚しているつもりなので、もっと省みるように心掛けます。

      - No.6358 -    このTreeへ    コメント元:6354 へ [リストへもどる] soft

(6270) 6355Re^5: 拡張ファンク57xxの返り値  投稿者:10♯   2013/05/02(木) 21:53
    6352 番 konno さんへのコメント    コメント数 2

konnoさん、みなさんおじゃまします。

久しぶりに覗いてみたら何やら盛り上がってますね(^−^)

LFNAPIの有無判定に似た事例はDOSの時代は多々ありましたね。
EMSだったらキャラクターデバイスがあるか、とか、
XMSだったらint2Fのプロトコルだったりとか。
CPUの判定とかもかなり泥臭い方法が確立されていました。

LFNAPIは既に多岐に分岐した各DOS互換環境上で、それぞれの裁量で漸次的に
実装されて、ある種の混乱を来した末に、DOS自体の需要が激減したため、
判定方法は確立していないようですね。
そもそも出自自体がDOSを葬り去るためのものだったりします。

これは正確な自動判別を目標とした場合、おそらくプラットフォームの正確な判定が
必要になると思われます。
int21/71を突くだけでは不可能でしょう。
rcpでは環境変数なども判断材料にしていたようです。


日本語DOSではこれをさらに極端にしたような事例として、FEPの判別方法がありました。
最終的に実装された FEPCTRL というフレームワークは千行以上のC言語で実装されて、
37種類のFEPを判別していますが、NTVDMの時代になってさらに非互換性問題が
発生したようです。
標準化が為されないことが如何にアホらしい事かを端的に物語ってる気もします(^^;)


で、「VZ環境いいんかい」というのは面白いネタですね。
おそらく、DOS環境の標準化の必要性が何故か今ここに存在していて、
それをおぼろげながら感しているのがkonnoさんでないですか?(それは言い過ぎ?)
僕もおぼろげながら、あるといいけど無理だろうな、と感じています。
結局「標準」とは動態保守される必要があって、需要無しには調整圧力が無いですよね。

仮に、DOSアプリのオーソリティーの各々が今なおアクティブで、何故かこの場に
登場してたりしたら、それなりに面白いな、と妄想したりはします(^-^;)



蛇足です。

int21の未定義APIは基本的にMSが予約してて、幾つかの挙動が想定されます。

1.機能が無く、エラーが返る。
2.機能が無く、エラーも返らない。
3.非公開(アンドキュメンテッド)機能がある。

将来的に仕様が変更される可能性があるため、行儀の良いプログラムは基本的に
呼び出しません。
今となってはさすがに「将来的な予約」とか「行儀の良い」とか、合理性ないですけどね。

TSRなど、プロセス間の通信には仕様が明確化されてたint2fが慣用されていましたね。

      - No.6355 -    このTreeへ    コメント元:6352 へ [リストへもどる] soft

(6270) 6356Re^6: 拡張ファンク57xxの返り値  投稿者:としき   2013/05/02(木) 22:02
参照先:http://www1.hinocatv.ne.jp/toshiki/
    6355 番 10♯ さんへのコメント

> rcpでは環境変数なども判断材料にしていたようです。

そうだ、思い出した。
rcpは環境変数で判断していたので、古いDOS+LFNADPでも長いファイル名が扱え
て便利だったんですよ。
そういえば、何かリクエストしてそのままになっていたような気もするけれど、
普段はzcopyしか使わないもので、何をリクエストしたかすら忘れてしまった。

      - No.6356 -    このTreeへ    コメント元:6355 へ [リストへもどる] soft

(6270) 6359VZとプラットフォームの環境  投稿者:konno   2013/05/03(金) 00:07
    6355 番 10♯ さんへのコメント

10#さん、どうもです。

> EMSだったらキャラクターデバイスがあるか、とか、

これが今結構深刻なんですよね。EMSmagicではATOK8が認識しないとか。

> そもそも出自自体がDOSを葬り去るためのものだったりします。

そうかもしれませんね。でも、NTで未実装だったのが、2k以降実装されたので
VZなどが生き残ってこれたとも言えます。
変化に対応できたのは、極少数の事例かもしれませんが。

> rcpでは環境変数なども判断材料にしていたようです。

そういえば、XPなどは環境変数を大量に使ってますね。VTDOSも複数使用しているので
環境変数領域があふれていそうですね。
Win7のDOS窓でもパスが途切れていたので見直しました。
%PATH% を使うとおかしくなるので、必要なものだけ指定するようにしました。

> 37種類のFEPを判別していますが、NTVDMの時代になってさらに非互換性問題が
> 発生したようです。

FEPも今問題なんです。VTDOSのIME制御も私のスキル(検証)不足でバグがあるし
DOSBOXとかいろいろなプラットフォームで問題解決していない状況です。

> おそらく、DOS環境の標準化の必要性が何故か今ここに存在していて、
> それをおぼろげながら感しているのがkonnoさんでないですか?(それは言い過ぎ?)

標準化というより、いろんな環境でVZが動くけど、非互換部分で問題があるので
問題点を明らかにして、問題解決へのヒントが得られれば、と思ったのです。

> 仮に、DOSアプリのオーソリティーの各々が今なおアクティブで、何故かこの場に
> 登場してたりしたら、それなりに面白いな、と妄想したりはします(^-^;)

私も思っていますが、ここは辺境の地ですからねぇ。(^^;

> TSRなど、プロセス間の通信には仕様が明確化されてたint2fが慣用されていましたね。

VWX.COM や TAGLIGHT.EXE なども使用していますね。ソースが無いのが残念ですが。
私もそのうちこれでTSR作りたいです。

      - No.6359 -    このTreeへ    コメント元:6355 へ [リストへもどる] soft

(6270) 6315Re^4: 71A0_INT21 について(まとめ)  投稿者:としき   2013/04/21(日) 22:37
参照先:http://www1.hinocatv.ne.jp/toshiki/
    6311 番 konno さんへのコメント    コメント数 1

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

あ〜、そういえばそうだった。
自作フリーウェアのFCDELにも、がんばって搭載したなぁ。
え〜と、バージョンアップ履歴によると、1999-01-10にリリースした版から搭載
している模様。
なお、使っているのは7160hのみです。


> ついでに、「いきちがいのぷろぐらむあ」さんの
> 「2009-12-24[木] mg.exe LFN対応」

おや、mg.exeって、新しいバージョンが出てたんだ。
正式版というか、LFNに対応していない最新版は、実行ファイルのタイムスタンプ
が1999-08-10の0.99なのね。
私の手元にあるのは1996-02-18の0.99でした。
これ、DOS汎用の画像形式コンバータなんで、重宝させてもらっています。
当然のごとく、オアポケ3にも入っています。
      - No.6315 -    このTreeへ    コメント元:6311 へ [リストへもどる] soft

(6270) 6317Re^5: 71A0_INT21 について(まとめ)  投稿者:konno   2013/04/22(月) 01:05
    6315 番 としき さんへのコメント    コメント数 1

> なお、使っているのは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 とみて間違いないですね。

      - No.6317 -    このTreeへ    コメント元:6315 へ [リストへもどる] pre

(6270) 6319Re^6: 71A0_INT21 について(まとめ)  投稿者:としき   2013/04/23(火) 09:41
参照先:http://www1.hinocatv.ne.jp/toshiki/
    6317 番 konno さんへのコメント

> > なお、使っているのは7160hのみです。
> おお、そんな番号をお使いでしたか。番号の選択理由は個人の好みなのかな。

いやいや、違います。必要だったからこの番号を使っています。
もともと、60hを使っていたのです。
それを長い名前に対応させるために7160hが必要になったのです。
だから、プログラムの構成も、思いっきりダウンレベルな形で、OSがLFN非対応
なら旧来の60hをそのまま呼ぶようになっています。
      - No.6319 -    このTreeへ    コメント元:6317 へ [リストへもどる] soft

(6270) 6300Re: 高橋さんデータへの追記  投稿者:konno   2013/04/19(金) 23:23
    6295 番 文太 さんへのコメント    コメント数 1

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

めざら資源の軟体マクロ一覧で見ると
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デビューしてないはず。)

そうでしたっけ? 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    Libretto(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    メビウス(ME)で EMS を設定する
(14) 03/01/05 23:10 07725へのコメント

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

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

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

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

      - No.6300 -    このTreeへ    コメント元:6295 へ [リストへもどる] pre

(6270) 6305Niftyの思い出  投稿者:文太   2013/04/20(土) 15:19
    6300 番 konno さんへのコメント    コメント数 2

konnoさん、

DC 14階 #07770
>でがらしさん こんにちは
>先日コジマ電器のパソコンコーナーでシャープのメビウス(ME)を
>見て、でがらしさんの事を思い出し、すこしいじってみました。
>確かにそのままでは EMS は無かったので、メモ帳で system.iniを
>開き、 [386Enh] セクションに、

 こ、こんな頃からこんなに面倒見のよいことを。歩く親切みたいな人ですね。
 このあとも、同じようなのが、またあった。す、すごい。人格者。
 この場面で微妙に僕はかすっているみたいですね……。

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

 どうなんだろう、僕は Nifty を1年くらいロムったのかなぁ。 別に深い意味
はなかったはずですが、登場(00/07/13)の頃、意を決して、暑い夏、半日がか
りで ishから、高橋完成版にアップデートした記憶があります。
 ニフマネでファイルの管理もわからず(ログがバイナリなんだもの)、通信用
Win95マシンから旧8にフロッピーでファイル群を移して、ishの解凍、パッチあ
て。あのとき使ったフロッピーはまだ存在し管理されています。珍しく、あそこ
にある、と言えます。

 その前に、DOS/V 環境で FEP 制御が効かず、榊原版にして制御に成功し、ひれ
ふした記憶はありますね。VTDOS での「FEP(IME)制御不可」に異様に抵抗を示し
ているのは、あのときのトラウマゆえ、という気もします。
 やっぱり、FEP or IME を制御できないVzは嫌です。 制御できないときのスト
レスは、えらく記憶鮮明なんです。

      - No.6305 -    このTreeへ    コメント元:6300 へ [リストへもどる] soft

(6270) 6310昔話にすらならない  投稿者:文太   2013/04/21(日) 00:39
    6305 番 文太 さんへのコメント

konnoさん

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

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

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

 今や、何をやっていたか分かるもんね。
 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 だけで判断してみた

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


      - No.6310 -    このTreeへ    コメント元:6305 へ [リストへもどる] pre

(6270) 6312VTDOS+CKWVのIME制御  投稿者:konno   2013/04/21(日) 01:59
    6305 番 文太 さんへのコメント    コメント数 1

>  こ、こんな頃からこんなに面倒見のよいことを。歩く親切みたいな人ですね。

いやあ、今ではすっかり足腰も弱って、へたり込んでますね。(^^;
私は基本的には興味のあることにしか気が向かないので、たまたま気が向いたのかも。

>  やっぱり、FEP or IME を制御できないVzは嫌です。 制御できないときのスト
> レスは、えらく記憶鮮明なんです。

今のVTDOS+CKWVではkVZでIME制御できてますよ。
ただ、現状では私の実装がバグっていて、制御が不完全です。
文太さんとかに動作チェックしてもらえれば、どこが違っているか、問題点が
わかるとおもうんですがねぇ。
今の私では問題点がわからないし、調べる気力がちょっとだいぶ足りないのです。

      - No.6312 -    このTreeへ    コメント元:6305 へ [リストへもどる] soft

(6270) 6313Re: VTDOS+CKWVのIME制御  投稿者:文太   2013/04/21(日) 15:22
    6312 番 konno さんへのコメント

konnoさん

(でがらしマシンのために出張の件)
>>  こ、こんな頃からこんなに面倒見のよいことを。歩く親切みたいな人ですね。
>いやあ、今ではすっかり足腰も弱って、へたり込んでますね。(^^;

 ご謙遜と比喩なのだと思いますが、どうか歩き回ってお体をお大事になさって
ください。やっぱり、人間は歩くべき動物みたい。自戒です。

>今のVTDOS+CKWVではkVZでIME制御できてますよ。
>ただ、現状では私の実装がバグっていて、制御が不完全です。
>文太さんとかに動作チェックしてもらえれば、どこが違っているか、問題点が
>わかるとおもうんですがねぇ。
>今の私では問題点がわからないし、調べる気力がちょっとだいぶ足りないのです。

 気力を振り絞って頑張られて下さい。
 さきほど、VTDOS.txt を読ませていただきました。このあいだのことみたいな
のに、 もう3年以上も前のこと? いやあ、大変なことに 10# さんは手をつけ
てしまったんだなぁ、と思い、それに合わせて Vz を調教するなんて、これまた
konno さんも大変だぁ、と。
 「VTDOS+CKWV での kVZ による IME 制御」、着手されているとのこと朗報で
す。VTDOS デビューが3年前だとすると、僕が Win7 に行かざるを得ないのも、
もうすぐのことでしょう。その折には、(大したことができないのは分かり切っ
ていますが)テスタとして協力させていただきます。お手数をお掛けするだけか
とも思いますが。
 それでも、気力を振り絞りすぎてもまずいのかもしれないので、ご無理をなさ
らないでくださいね。そもそもテスター勢力は多くも強くもないし、わからない
けど、IME制御って、すごく大変そうですから。

 秀丸とかと比べてみて、どれほどVzがしてくれてくれていたことが「当たり前」
みたいでありながら、「ありがたいことなのか」考えてみます。
 ファイラ関係の操作性という意味では、けっこうそうかぁ、と思う場面があり
ました。でも、Vzファイラでキーボードマクロが使えるのはありがたいです。
Windowsファイラでできるのあるかなぁ。無理、無茶かなぁ。


      - No.6313 -    このTreeへ    コメント元:6312 へ [リストへもどる] soft

(6270) 6283Re: cf バグってましたm(__)m  投稿者:文太   2013/04/17(水) 12:30
    6279 番 konno さんへのコメント    コメント数 1

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

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 系とNT系の区別はつかないですよね。知
れるのは、LFN が可能かどうかですよね。
 「LFN=1 cf1」の元の変数lとcは、同じことをレポートさせてますよね。 そ
のつもりで、

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

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

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

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

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

      - No.6283 -    このTreeへ    コメント元:6279 へ [リストへもどる] pre

(6270) 6284まとめ(LFN vol)  投稿者:文太   2013/04/17(水) 12:42
    6283 番 文太 さんへのコメント    コメント数 1

=== 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でも問題ないでしょう?

      - No.6284 -    このTreeへ    コメント元:6283 へ [リストへもどる] pre

(6270) 6285追記:  投稿者:文太   2013/04/17(水) 14:21
    6284 番 文太 さんへのコメント    コメント数 1

追記:

 何にこだわっていたかというと、ファンクションコールは 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 のIDみたいなものと考えると、MS-DOS カーネルはハード自体の
情報も持ってるとは言える。
 興味のある方は、 「see #01394」 の部分を見てみてください。 きっと
Olivetti も Toshiba も NEC も Sanyo も、MS-DOS 自体に手を入れてはいない
のだろうけど、MS-DOS は自分が使われているハード環境を知っている。 もしか
したら、 かつてはこれらの会社(すんげえ多数)は、MS-DOS というOSを自社
用にカスタマイズしてたのかもしれないけど。

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

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

      - No.6285 -    このTreeへ    コメント元:6284 へ [リストへもどる] pre

(6270) 6286追記2  投稿者:文太   2013/04/17(水) 14:40
    6285 番 文太 さんへのコメント    コメント数 1

追記2:

 結局のところ、大混乱なのですが、確認された事実は事実として固めて
おきましょう。

konnoさんwrote:
-----
ちなみに、マクロ修正後のVTDOS(これはWin7ですよね?)
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があるとないのでは、レポートされるWin7でのMS-DOS versionが違う。

 VTDOSなしプレインなWin7では、MS-DOS5。ふつうにNT系。
 VTDOSありのWin7(commnad.comは純ドス6.20のもの)では、MS-DOS 6.20。

 つまり、VTDOS(半分MS-DOSカーネル代わり)がある場合、このMS-DOS version
のファンクションコールは、VTDOSがやっていて、外からもってきたcommand.comの
ヴァージョンを報告してるということですよね。

 (別に大切だとも思ってないのですが)、ここ、間違いないですよね >konnoさん?
 問題の在処がはっきりしたら、10#さんに訊けばいいんでしょうけど。

      - No.6286 -    このTreeへ    コメント元:6285 へ [リストへもどる] soft

(6270) 6287脱線  投稿者:文太   2013/04/17(水) 15:03
    6286 番 文太 さんへのコメント    コメント数 1

脱線

いつまでやってんだよ? ボソっ。

 最近、僕が知ったところでは、根拠は曖昧ですが、Win Vista は存在しなかっ
た、 Win 8 はインターフェイスが違いすぎて、とうぶん Win 7 がXPのように
超寿命で使われることになるのじゃないか、ということ。
 ま、Win 8 との関係は、鬼が笑う種類の話でもありましょうが。

 そして、 僕に驚きだったのは、32bit と 64bit で、けっこう大きな混乱が起
きているということ。Athlon64 は古い話だし、XP 64bit だってけっこう前か
らあったのに、64bit OS で動かないアプリが続出している模様。
(うん、うちの娘が買ったVAIOノートは64bit Win7でした。これが世間を騒がして
いる理由の一端でしょう。何も考えずにマシンを買ったら、64bit OSで、32bit
アプリが動かなくて騒ぎになった。)

 別の言い方をすると、64bit 全盛の時代がやってきたら、Win 32bit アプリは
割とあっさり切り捨てられるのかも。これは、遅かれ早かれでしょうけど。
 仮想 32bit モードがあるていど存続するのでしょうか? 

 チューチューマウスとか、 Win9x 時代からのものは、64bit 版が出ません。
64bit 環境では動きません。Win32bit 以下あるいは以前は、捨てられることに
なるのかなぁ。

 僕は、Windows 環境に慣れようといちおう努力してますが、Win9x 系ヴァージ
ョンが存在しないアプリは使わないようにしています。WinME が大切なので。こ
れが理由で、秀丸ファイラは断念。
 努力して時代に取り残されようと、またしてるみたいですが。


      - No.6287 -    このTreeへ    コメント元:6286 へ [リストへもどる] soft

(6270) 6288脱線から戻る(tVzとkVz)  投稿者:文太   2013/04/17(水) 15:40
    6287 番 文太 さんへのコメント

脱線から戻る(tVzとkVz)

 何しろ VTDOS ユーザでないので、ちらと 10# さんの掲示板を覗いて戻ってき
てしまいました。
 2013/04/15 (Mon) 00:31:02 あたりの話です。

 VTDOS は WinXP, Win 7 and 8 のNT系専用、konno 版Vz専用でいいと僕は
思いますよ。作者としては汎用を狙いたいのでしょうけど、10#さんだって、Vz
とFDが使いたい、というのが開発の動機だったわけですし、Windows以降では、
高橋版-->konno版とVzも進化してきたわけですから。
 (ちゅーぱっちは駄目じゃ、オリジナルのバグが取れてません−−いっぱいある
し、マクロ師&マクロイドはそれは解決された問題とみなしてる−− >10#さん。
もう一言付け加えると、高橋版はオリジナルから、ものすごく進化したのです。
そうしてkonno版がある)

 高橋版ですが、NT系のLFNに対応させたのは konno さんですよね。 どっ
かのチェックルーチンをバイパスすることにした。ですから、VTDOS での調整は、
LFNにしろアイドルにしろ、konno 版基準でいいと思いますよ。

 現実的に、 ハードやドライバの制約で、今時のマシンでは WinME は動かない
し、VTDOS はマシンパワーをかなり落としてVzを動かすことを考えたら、今時
のマシンとOSでは、 つまり素の NTVDM(NT Virtual Dos Machine ですね)で
は、Vzは動かない(日本語を扱えない)から、VTDOS に命を預けるというのは
当然でしょう。

 キビキビVz、powersensitiviy とかいうのがゼロなVz環境。これが安定し
てくれることを祈ってます。ishもrcp(16)も、大きな問題じゃないと思うけど。
 キャリーの話に不安が残りましたが……。LFN判定? つまり、Win or not
の判定ですか? バイパスすることに成功したのは、konnoさんですよね?

 konnoさんのWin 7環境って、32bitですよね?


      - No.6288 -    このTreeへ    コメント元:6287 へ [リストへもどる] soft

(6270) 6289Re: vz_env.def v05  投稿者:文太   2013/04/17(水) 20:17
    6276 番 konno さんへのコメント

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)、NT系(当時は NT4.0 ぐらいのはず)を高橋さんが断念したの
は、もう少しあとです。NTを使ってるユーザはまだ少なく、たぶんあまり要望も
需要もテスタもなかったのじゃないのかなぁ、と想像します。誰か一人がくいさが
っていたような記憶ですが。高橋さんも何かのテスト結果を見て、残念そうに諦め
ていたと思います。もちろん、僕は過去ログを読んだだけですよ。


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

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の両方を見よ、これがMS推奨のやり方です。LXやモバの人もいるわけで、
そのようなコードがVzerには必要なのです。

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

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


      - No.6289 -    このTreeへ    コメント元:6276 へ [リストへもどる] pre