10#さん

　以下のような、まんまでは使えないものなのでしょうか？　m(__)m
　舞い上がってしまって…。もう一回、docを読みますぅ〜。
　念のため、MS-IME 2003 ですが…?

　うまくいった人、誰かぁ、教えてぇ。


=== Macrotmp by B ===;
Int 2F/AX=7476h/BX=0003h
IME状態の取得
Return:
AX = 0
DX = IME状態
IMEの状態を取得します
-------------------------------
Int 2F/AX=7476h/BX=0004h
IME状態の設定
Return:
AX = 0
IMEの状態を設定します

* M
50 ^A "IME state"

	AX=$7476, BX=$0003, &i($2F)	;立ってても立ってなくても
	&m("%x",dx) .			;１が返るみたい…

51 ^F "set IME"

	AX=$7476, BX=$0004, DX=1, &i($2F)	;dx=0, でも dx=1, でも
	&m("%x",ax) .				;そのまま7476hが返る？？？

*

10#さん

　一日一善（なつもり）の文太です。返り値が？

=== Macrotmp by B ===;
* M
50 ^^ "Macrotmp"
;VTDOSインストレーションチェック
	AX=$7476,
	BX=$0000,
	CX=$6F64,
	DX=$0073,
	&i($2F)
	&?("AX: %x BX: %x CX: %x DX: %x",AX,BX,CX,DX )
;-----------------------------
; result --->
; AX: 0 BX: 5476 CX: 4F44 DX: 53
;           ^^^^
;-----------------------------
	(AX==$0000 &&
	 BX==$5456 &&
	 CX==$4F44 &&
	 DX==$0053)
			?{&m("VTDOS installed")}
			?{&m("VTDOS not installed")}.

*

Int 2F/AX=7476h/BX=0000h
VTDOSインストレーションチェック
AX = 7476h
BX = 0000h
CX = 6F64h
DX = 0073h
Return:
AX = 0000h
BX = 5456h	***
CX = 4F44h
DX = 0053h

　１文字欠ける？

=== Macrotmp by B ===;
* M
50 ^^ "Macrotmp"
;	p="0123456789", 
	p="あいうえおかきくけこ", 
	&Sn(p) cx=r, si-,	;size etc  for SET func
	ax=gz, bx=p,		;ptr (ax->es)
	dx=1,			;type
	&>
	&m("finished").

0:	&i(3+$)."$
	$(50,B8,01,17,CD,2F,B8,02,17,CD,2F,07,B8,03,17,CD)$
	$(2F,B8,08,17,CD,2F,C3)$"

;	push ax
;	mov ax,1701h	;open
;	int 2Fh
;	mov ax,1702h	;clear
;	int 2Fh
;	pop es
;	mov ax,1703h	;set
;	int 2Fh
;	mov ax,1708h	;close
;	int 2Fh
;	ret

*

　どうなんでしょうか？　何が正しいのかよく分からないものですから…？

=== Macrotmp by B ===;【どうなんでしょう？】
* M
50 ^^ "Macrotmp"

	ax=$1701, &i($2F)		;open
	ax=$1704, dx=1, &i($2F)		;get size
	dx[, ax[,
	ax=$1708, &i($2F)		;close
	&m("ax:%d dx:%d",ax],dx]) 

	; resulut --> 21 bytesとレポートしてくる。せっかくですから…。
	; ヘッダか何か、付いているものなのでしょうか？
	; 因みに、WinMEでは、Noteのとおり32と答えてきます。
	; もちろん、32より20がいいと思うけど…。
*

あいうえおかきくけこ		== string in clipboard
（20 bytes）


INT 2F - MS Windows "WINOLDAP" - GET CLIPBOARD DATA SIZE
	AX = 1704h
	DX = clipboard format supported by WinOldAp (see #02723)
Return: DX:AX = size of data in bytes, including any headers
		0000h:0000h if no data in this format in the Clipboard
Note:	Windows reportedly rounds up the size of the data to a multiple of 32
	  bytes

　起動ドライブ（C:）空き容量のみ、計算が合いません。意図どおりでしょうか？
　個人的には気にしてないのですが、プログラムする側は気になるかもと。m(__)m
　念のため。別ドライブでは計算が合います。

=== Macrotmp by B ===;
* M
50 ^^ "Macrotmp"
	AX = $7476,
	BX = $0002,
	si = pa, 	;空き容量バッファ
	di = pw,	;総容量バッファ
;	dx = 0,		;カレント, C: ***★どちらも合わず
	dx = 3,		; C:          ***★
;	dx = 6,		; F:
;	dx = 26,	; Z:
	&i("$(1E,07,CD,2F,C3)")	
		;push ds
		;pop  es
		;int  2Fh
		;ret
	(r)? {&m("error") .}
	&?("空き容量: %s bytes, 総容量: %s bytes",pa,pw)
*
Int 2F/AX=7476h/BX=0002h
ディスク空き容量の取得
AX = 7476h
BX = 0002h
DL = ドライブ番号(0:カレント,1:A〜)
DS:SI = 20バイト以上の空き容量バッファ
ES:DI = 20バイト以上の総容量バッファ
ドライブの総容量・空き容量をバイト単位で十進ASCIIZ文字列で取得します。
Return:
エラーの場合
CY = 1


【マクロの結果：不思議なところのみ】
C: 空き容量:  63,616,929,792 bytes, 総容量: 77,778,214,912 bytes
                     ^^^^^^^
【手計算＝chkdsk+MCalc.def。検算：Ｃ電卓＠ベクタ】※MCalc.def by Emmett スゴイ！
>chkdsk
      4096 バイト : アロケーション ユニット サイズ
  15531456 個     : 利用可能アロケーション ユニット
4096 * 15531456 = 63,616,843,776


63,616,929,792		;VTDOS function
63,616,843,776		;手計算

10#さん

　何度もすいません。

>特にCドライブはバックグラウンドで動作しているプロセスのファイルI/O
>の影響を受けるので、空き容量を調べた直後にまた空き容量が変化している
>ようなことはあり得ると思うのですが、いかがでしょうか？

　あり得ましょう。あのテスト、何度かしたのですが、すぐファイルを使ってし
まうものですから、空き容量が変わるのです。なので、直後にやったつもりだっ
たのですが、そうか、「バックグラウンドで動作」してるものですか。ウィルス
対策ソフトとか、かな…？temp は、Ｆドライブだからな、とか思ったのですが、
そういう可能性が高いですね。Windows は何をしているのか分かりませんから。
自分の設定したマシンだろう☆＼(^^;)

63,616,929,792		;VTDOS function
63,616,843,776		;手計算
　８０キロバイトくらいか。何が使ってたんだ…？

　お手数をお掛けしました。勉強になりました。

10#さん

>VTDOSがある種のお節介をするべきところですか？

　うーん、考え込んでしまっています。他の人の意見を待ったほうが良いですね。
　僕には、分かりません。

　間違っているかもしれませんが、このファンクションを使ったマクロというの
は、たぶん、jenga.def だけだと思います（ＸＰでは効かないファンクションで
すから）。そのマクロで、この問題に最初に遭遇し、例のテストマクロで（いち
おう）確認しました。

　ああいう使い方なら、
　&Sn(p) cx=r+1,
　とすれば良いということですね。おお、ちゃんと２バイト文字を判断してる！
　誰が？

　jenga.defは
	dz[=di=kz, bx=kp-(cx=kp..-1)-3, dz],
　ですね。ここに「＋１」でいいのかな…。

　サイズの１バイトといい、全体にそういう種類の話なんじゃないかな、と想像
しておりました。
　ですので、「VTDOS ではこう」と、何というか、この種のプログラミングの作
法に従っていただくのが一番かと思います。

　まったく作法を知らない者の「経験」ですから、他の方の意見を聞いて、決め
てしまって下さい。このファンクションを使うMS-DOSアプリというのがこれから
登場することはないでしょう。Ｖｚマクロだけではないかな。マクロ師の方々や
プログラミング全般に強い方の意見に、僕は従います。というか、意見が持てま
せん。m(__)m

　Ｖｚ界でのクリップボード操作標準アプリは、clppst.def(exe)です。これはＸＰ
でも使えます。

　このためにそこまでする必要はないと思いますが、これらの所在です。
　clppstのほうは、delphiのソースもあるようです。clppstでは、そういう問題
が起こらないというか、処理されてしまっているのですね…、たぶん…。

http://homepage3.nifty.com/mezala/vz/history/maclib1.html
JENGA.DEF 1.05	テキストスタックの覗き窓 jenga.def v1.05
CLPPST.DEF 0.5C	クリップボードの読み書き CLPPST.DEF v0.5c

　そういうものというのが分かれば、「お節介」は要らないような気がしてきま
した…。

#10さん

>現状jenga.defはヌル文字を付けていないということでいいですか？
　とりわけ付けていませんでした。

>であればWinOldApに倣ってヌル文字補完になります。
　それが作法であれば、お願いいたします。
　「ヌル文字補完」が、WinMEでのこのファンクションの振る舞いであった
というように理解しました。

　お仕事で、少々お疲れモードです。残念ながら、これがしばらく続きます。
　がんばってください。


【参考】

:I	;---クリップボードへ送る---
	kp[,
	(i)? { (i) &14 }
	dz[=di=kz, bx=kp-(cx=kp..-1)-3, dz],
	&i("$(B8,01,17,CD,2F,B8,02,17,CD,2F,B8,03,17,33,D2,42)$
	$(33,F6,06,8E,C7,CD,2F,07,B8,08,17,CD,2F,C3)")
	kp], >A
	;	mov	ax,1701h	; open
	;	int	2Fh
	;
	;	mov	ax,1702h	; clear
	;	int	2Fh
	;
	;	mov	ax,1703h	; set
	;	xor	dx,dx
	;	inc	dx
	;	xor	si,si
	;	push	es
	;	mov	es,di
	;	int	2Fh
	;	pop	es
	;
	;	mov	ax,1708h	; close
	;	int	2Fh
	;	ret

10#さん

> 僕の環境ではDIET本体が起動できませんでしたので非互換認定としています。
> 従ってDIETによる圧縮バイナリーは動作確認出来ませんでしたが、

うちの環境では本体の起動も問題ないです。ただ、クラスタサイズが減らないと、
圧縮失敗になるので、最近のHDDでは、けっこう大きなEXEファイルで無いと成功
しなかったりしますね。私は、JWASMR.EXEで確認しました。
あと、32ビットプログラムも圧縮できないようです。

DIET     EXE      26,370 92-06-25    1:45　　Ver1.45f
DIET2    EXE      21,576 91-08-20    1:20　　Ver1.20

確認はVer1.45fでしましたが、1.20も起動できました。
MSDOS6.2/7.0とPCDOS7.0英語版でも動作しました。
何が違うんでしょうね。

> ディスクサイズはカンマ編集済みの方がいいですかね。

そうしてもらえると助かります。VZの書式制御は数値で無いと駄目みたいですね。


ところで、VTDOS1.19ですが、MSDOS6.2とPCDOS7.0英語版で
copy XXX.TXT YYY.TXT
のようなリネームコピーができません。File not found になります。
Win95のDOS7だと出来たようです。逆にDOS7で動かないコマンドもあったような。
copyコマンドとかはエミュレーションなんでしょうか。

ｐｓ：1.13まで遡っても同じようにDOS7はOKでDOS6.2は駄目でした。
うちの環境のせい？

　あれ、うちではできましたよ。

VTDOS|C:\VT>copy c:\aa.txt c:\bb.txt
        1 個のファイルをコピーしました。

VTDOS|C:\VT>dir c:\aa.txt
2010/01/21  01:01                 4 AA.TXT	;Vzで作ったから大文字なんだ

VTDOS|C:\VT>dir c:\bb.txt
2010/01/21  01:01                 4 bb.txt

　6.2Vのcommand.comです。

--- vtdos.cfg ---
;USECMD=1

VTDOS|C:\VT>copy c:\xxx.txt c:\yyy.txt
ファイルが見つかりません.
　再現しました。

VTDOS|C:\VT>dir c:\xxx.txt
 Volume in drive C is            snip（英語）
XXX      TXT             6 10-01-21   10:53
        1 file(s)              6 bytes
　なるほど、日本語メッセージでエミュなのか、と想像できるわけですね。

　YYY.TXTを作っておくと、
VTDOS|C:\VT>copy c:\xxx.txt c:\yyy.txt
Overwrite C:\YYY.TXT (Yes/No/All)?
        1 file(s) copied
　うむ、これは英語版command.comだ。謎。

--- vtdos.cfg ---
USECMD=1
　と設定しましょう。もちろん、昨晩はこの状態でした。

> 差し支えなければUSECMD=1の指定をお勧めします。

以下、USECMD=1を指定しなかったときの挙動。

VTDOS|C:\>copy *.bat C:\b.b
ファイルが見つかりません.

VTDOS|C:\>copy a.* C:\b.b
ファイルが見つかりません.

VTDOS|C:\>copy a.bat C:\b.*
        1 個のファイルをコピーしました.

VTDOS|C:\>copy a.bat C:\*.a
        1 個のファイルをコピーしました.

かなり面白い振る舞いではあるのですが。
このへん、私も昔、苦しんだ記憶があります。
FindFirst系のAPIで、属性の設定を間違えて、ある条件のときだけきちんと検索
できなくなってしまったという。
なんだっけ、DOSの時代には存在していなかった属性だったかな。
あるいは、0x3fと0x80の間違いだったかも。
あと、CreateFileで、ファイルの作成に成功したにもかかわらずGetLastErrorが
エラーを返してくることがあって、それを知らずにはまったこともあったなぁ。