[HOME]  [リストへもどる]
一括表示

  VTDOS 1.19 環境依存の不具合を確認済みです。慎重にご使用下さい。 - 10# 10/01/18-21:20 No.4879
    ┣ プラグインが必要? - 文太 10/01/18-22:15 No.4881
    ┃┗ Re: プラグインが必要? - 10# 10/01/19-01:52 No.4884
    ┃ ┣ Re^2: プラグインが必要? - 文太 10/01/19-10:10 No.4885
    ┗ VTDOS1.19で圧縮ソフト関連 - konno 10/01/20-00:03 No.4890
     ┗ Re: VTDOS1.19で圧縮ソフト関連 - 10# 10/01/20-02:04 No.4892
      ┣ VTDOSインストチェック - 文太 10/01/20-14:17 No.4893
      ┃┣ Re: VTDOSインストチェック - 10# 10/01/21-00:10 No.4894
      ┃┃┣ Re^2: VTDOSインストチェック - 文太 10/01/21-12:26 No.4898
      ┃┃┃┗ クリップボード送信 - 文太 10/01/21-12:28 No.4900
      ┃┃┃ ┣ GET CLIPBOARD DATA SIZE - 文太 10/01/21-17:58 No.4901
      ┃┃┃ ┃┗ ディスク空き容量の取得 - 文太 10/01/21-17:59 No.4902
      ┃┃┃ ┃ ┗ Re: ディスク空き容量の取得 - 10# 10/01/21-23:48 No.4905
      ┃┃┃ ┃  ┣ Re^2: ディスク空き容量の取得 - 文太 10/01/22-01:22 No.4908
      ┃┃┃ ┣ Re: クリップボード送信 - 10# 10/01/21-23:44 No.4904
      ┃┃┃ ┃┗ Re^2: クリップボード送信 - 文太 10/01/22-01:14 No.4906
      ┃┃┃ ┃ ┗ Re^3: クリップボード送信 - 10# 10/01/22-23:37 No.4909
      ┃┃┃ ┃  ┣ Re^4: クリップボード送信 - 文太 10/01/23-01:35 No.4911
      ┃┃┃ ┃  ┗ Re^4: クリップボード送信 - 文太 10/01/23-21:23 No.4914
      ┗ Re^2: VTDOS1.19で圧縮ソフト関連 - konno 10/01/21-00:25 No.4895
       ┣ rename copy - 文太 10/01/21-01:07 No.4896
       ┣ Re^3: VTDOS1.19で圧縮ソフト関連 - 10# 10/01/21-01:12 No.4897
       ┃┣ rename copy - 文太 10/01/21-12:27 No.4899
       ┃┣ Re^4: VTDOS1.19で圧縮ソフト関連 - konno 10/01/22-01:17 No.4907
       ┃┃┗ Re^5: VTDOS1.19で圧縮ソフト関連 - 10# 10/01/22-23:45 No.4910
       ┃┃ ┣ Re^6: VTDOS1.19で圧縮ソフト関連 - 10# 10/01/23-02:12 No.4912
       ┃┃ ┗ 昔話 - としき 10/01/23-11:20 No.4913
       ┃┗ Re^4: VTDOS1.19で圧縮ソフト関連 - としき 10/01/24-18:58 No.4916
       ┗ Re^3: VTDOS1.19で圧縮ソフト関連 - 10# 10/01/21-23:34 No.4903

(4879) 4879VTDOS 1.19 環境依存の不具合を確認済みです。慎重にご使用下さい。  投稿者:10#   2010/01/18(月) 21:20
参照先:http://vtdos.web.fc2.com
   コメント数 2

動作環境によりPKLITE1.03で圧縮されたプログラムが動作しない不具合は
解消していないので、1/16のお知らせ内容により処置をお願いします。
現象が発現した場合かなりきわどい画面表示になりますが、
落ち着いて運用を停止して下さい。
また、この現象が発現する環境である場合はかなり高確立で発生するものと
思われます。(作者の場合100%でした)
よろしくお願いします。

変更点は以下の通りです。
Int 2F/AX=7476h/BX=0002h ディスク空き容量の取得
PUSH imm8/IMUL r,rm,imm8命令不具合修正
Int2f/17h Clipboard API 追加
      - No.4879 -    このTreeへ              [リストへもどる ] soft

(4879) 4881プラグインが必要?  投稿者:文太   2010/01/18(月) 22:15
    4879 番 10# さんへのコメント    コメント数 1

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) .			;1が返るみたい…

51 ^F "set IME"

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

*

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

(4879) 4884Re: プラグインが必要?  投稿者:10#   2010/01/19(火) 01:52
参照先:http://vtdos.web.fc2.com
    4881 番 文太 さんへのコメント    コメント数 1

補足します。
Int2f/AX=7476/BX=0003|0004はAPIが予約されているだけで、
VTDOSには現在何の実装も存在しません。
将来的に可能かどうかも不明です。
あるいは、相応のプラグインがどこかから供給されれば可能かも知れません。

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

(4879) 4885Re^2: プラグインが必要?  投稿者:文太   2010/01/19(火) 10:10
    4884 番 10# さんへのコメント

10#さん

>Int2f/AX=7476/BX=0003|0004はAPIが予約されているだけで、
>VTDOSには現在何の実装も存在しません。

 了解しました。リリース・ノートのほうにはなかったので、そうかな、と。
 壁は高く険しい道のようですね。どうか頑張って下さい。

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

(4879) 4890VTDOS1.19で圧縮ソフト関連  投稿者:konno   2010/01/20(水) 00:03
    4879 番 10# さんへのコメント    コメント数 1

10#さん、現在1.19使用中です。

LHAのエラーも無くなり、落ちなくなりました。ありがとうございます。
MCBエラーになっていたのもそのエラーがらみだったのかなぁ。

あと、DIET が非互換の項目に入ってますが、もしかして私の書き込みのせい?
私は、DIETは問題ないと書いたつもりなんですが、他で問題あったのかな。

PKLITEは使って無いと思ってましたが、WGREP で検索したら・・・

VTDOS|C:\UT\VTDOS119>WGREP -t -i -k vcb "PKLITE" *.*
------------------ FILMTN.EXE
!PKLITE Copr. 1990-91 PKWARE Inc. All Rights Reserved
------------------ FMCUST.EXE
!PKLITE Copr. 1990-91 PKWARE Inc. All Rights Reserved
------------------ ISCMP.EXE
ISCMP.EXE 1:PKLITE Copr. 1990 PKWARE Inc. All Rights Reserved
------------------ PHATCODE.EXE
PHATCODE.EXE 1:PKlite(R) Copr. 1990-1996 PKWA・nc. All Rights Reservev
------------------ PKUNZIP.EXE
PKLITE Copr. 1990-92 PKWARE Inc. All Rights Reserved

こんなにありました。(^^; ほとんどはJ3100時代のプログラムですが、
PHATCODE.EXE は、EMSMagic のものですね。日付が新しいから問題なし?


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

(4879) 4892Re: VTDOS1.19で圧縮ソフト関連  投稿者:10#   2010/01/20(水) 02:04
参照先:http://vtdos.web.fc2.com
    4890 番 konno さんへのコメント    コメント数 2

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

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

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

(4879) 4893VTDOSインストチェック  投稿者:文太   2010/01/20(水) 14:17
    4892 番 10# さんへのコメント    コメント数 1

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


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

(4879) 4894Re: VTDOSインストチェック  投稿者:10#   2010/01/21(木) 00:10
参照先:http://vtdos.web.fc2.com
    4893 番 文太 さんへのコメント    コメント数 1

ご指摘ありがとうございます。
Ver.1.20で対応しました。
      - No.4894 -    このTreeへ    コメント元:4893 へ    [リストへもどる ] soft

(4879) 4898Re^2: VTDOSインストチェック  投稿者:文太   2010/01/21(木) 12:26
    4894 番 10# さんへのコメント    コメント数 1

10#さん

>Ver.1.20で対応しました。
 了解しました。リリースを少し待ってくださると、もしかして良いかな(どち
らでも構いませんが)。クリップボード・ファンクションに気になる部分がある
ような気がしています。クリップボード送りで1文字、欠けませんか?「VTDOS
ver」と「ディスク・サイズ取得」は問題ありませんでした。 後者では、やはり
「,」を入れてもらったほうがいいですね。 ちょっとだけ考えてうんざりしてし
まった。

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

(4879) 4900クリップボード送信  投稿者:文太   2010/01/21(木) 12:28
    4898 番 文太 さんへのコメント    コメント数 2

 1文字欠ける?

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

*

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

(4879) 4901GET CLIPBOARD DATA SIZE  投稿者:文太   2010/01/21(木) 17:58
    4900 番 文太 さんへのコメント    コメント数 1

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

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

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

(4879) 4902ディスク空き容量の取得  投稿者:文太   2010/01/21(木) 17:59
    4901 番 文太 さんへのコメント    コメント数 1

 起動ドライブ(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。検算:C電卓@ベクタ】※MCalc.def by Emmett スゴイ!
>chkdsk
      4096 バイト : アロケーション ユニット サイズ
  15531456 個     : 利用可能アロケーション ユニット
4096 * 15531456 = 63,616,843,776


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

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

(4879) 4905Re: ディスク空き容量の取得  投稿者:10#   2010/01/21(木) 23:48
参照先:http://vtdos.web.fc2.com
    4902 番 文太 さんへのコメント    コメント数 1

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

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

(4879) 4908Re^2: ディスク空き容量の取得  投稿者:文太   2010/01/22(金) 01:22
    4905 番 10# さんへのコメント

10#さん

 何度もすいません。

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

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

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

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

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

(4879) 4904Re: クリップボード送信  投稿者:10#   2010/01/21(木) 23:44
参照先:http://vtdos.web.fc2.com
    4900 番 文太 さんへのコメント    コメント数 1

Win32のクリップボードの仕様として、
文字列(CF_TEXT)は最後にヌル文字を含むこととなっていまして、
VTDOSは基本的には16bitプロセスか渡されたパラメータを
極力そのままWin32に渡す方針を取っているので、
パラメータエラーが起こっているということになります。
Windows(あるいはクリップボードを読むプログラム)が文字列を
バッファサイズにクリップして最後にヌル文字を追加しているものと思われます。
WinOldApが実際にどういう挙動をしているのかは、
Interrupt Jump Tableからは読みとれませんので、
慣習的にどうなっているか?ということだと思うのですが、
現時点でDOSのクリップボードアプリケーションはどういう呼び出し方をしていますか?
VTDOSがある種のお節介をするべきところですか?

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

(4879) 4906Re^2: クリップボード送信  投稿者:文太   2010/01/22(金) 01:14
    4904 番 10# さんへのコメント    コメント数 1

10#さん

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

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

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

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

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

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

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

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

 このためにそこまでする必要はないと思いますが、これらの所在です。
 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

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

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

(4879) 4909Re^3: クリップボード送信  投稿者:10#   2010/01/22(金) 23:37
参照先:http://vtdos.web.fc2.com
    4906 番 文太 さんへのコメント    コメント数 2

現状jenga.defはヌル文字を付けていないということでいいですか?
であればWinOldApに倣ってヌル文字補完になります。
clppstはWin32なので、今回VTDOSは無関係でした。
Ver.1.21からの対応になります。


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

(4879) 4911Re^4: クリップボード送信  投稿者:文太   2010/01/23(土) 01:35
    4909 番 10# さんへのコメント

10#さん

 すいませんが、簡単に。明日(今日)もお仕事です。(゚゚;

>現状jenga.defはヌル文字を付けていないということでいいですか?
>であればWinOldApに倣ってヌル文字補完になります。

 思うに、他の人から意見が出ることはないのではないかと思うので、10# さん
が「こうあるべき」というところで決めてしまって良いと思います。
 基本的に、clppstのお陰で、とりわけこの界隈では(たぶん一般に?)実に
マイナーな地位に貶められているファンクションのお話ですので(XPで効かな
いのですから、当たり前)。

 ただ、jenga.def は WinME では、ネイティブなそのファンクションコールを
使って、1文字欠けを起こさず、VTDOS ではそれが起こる、という点はお伝えし
たいと思いました。

 昨晩はVTDOS 対処法に先走り、VTDOS の仕様に意見するという姿勢がありませ
んでした(今もあまりないのですが)。
 先ほどもう少し見きわめようと少々もがいたのですが、実験に失敗してしまい
ました。デバックコードを入れなければならないのはどうして?(独り言)
 明日(今日ですね)の夜にレスできればします。サイズの取得の話も同じ話で
すよね。こちらもヌル抜きのサイズの方が良いような気がしています…。

 ヌルは、ファンクションが付加するのではないだろうか? というのが実験趣
旨です。
 jenga.def はヌルを付けず、拡張ファンクションにただ任せているだけ、とい
うのが、僕の前提です。クリップボードのデータ管理構造がまったく分かってい
ません。


追伸:pklite攻略(回避?)、おめでとうございます。すごい執念ですね。脱帽
です。m(__)m
 すいません、おやすみなさい。

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

(4879) 4914Re^4: クリップボード送信  投稿者:文太   2010/01/23(土) 21:23
    4909 番 10# さんへのコメント

#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

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

(4879) 4895Re^2: VTDOS1.19で圧縮ソフト関連  投稿者:konno   2010/01/21(木) 00:25
    4892 番 10# さんへのコメント    コメント数 3

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コマンドとかはエミュレーションなんでしょうか。

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

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

(4879) 4896rename copy  投稿者:文太   2010/01/21(木) 01:07
    4895 番 konno さんへのコメント

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

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です。

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

(4879) 4897Re^3: VTDOS1.19で圧縮ソフト関連  投稿者:10#   2010/01/21(木) 01:12
参照先:http://vtdos.web.fc2.com
    4895 番 konno さんへのコメント    コメント数 3

>>konnoさん

dietは1.45fで動作確認出来ませんでした。
これもpkliteと同様に、環境依存する問題ですね。
実行ファイル圧縮は障害の影響が大きくかつ切り分けが困難で、
一見原因不明でパニックが起きやすいので、確証無しに互換認定はしにくいです。

copyコマンドの問題は僕の環境でも発生しました。
不思議なことに YYY.TXT が存在する場合は正常に動作します。
このとき上書き確認を行うので、YYY.TXTの存在可否には問題が無いんですよね。
ファイル作成系のAPIかな?てとこです。
copyコマンド自体は普通にファイルの内容を読み書きしているだけなので、
エミュレーションといえばエミュレーションです。
差し支えなければUSECMD=1の指定をお勧めします。

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

(4879) 4899rename copy  投稿者:文太   2010/01/21(木) 12:27
    4897 番 10# さんへのコメント

--- 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
 と設定しましょう。もちろん、昨晩はこの状態でした。

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

(4879) 4907Re^4: VTDOS1.19で圧縮ソフト関連  投稿者:konno   2010/01/22(金) 01:17
    4897 番 10# さんへのコメント    コメント数 1

> dietは1.45fで動作確認出来ませんでした。
> これもpkliteと同様に、環境依存する問題ですね。

そういえば、DIET.EXE自身もDIETされてるそうなので、起動できないのはそのせいかも。
DIET.EXEは解凍できないようです。環境によって動作が違うのは、自己展開でOSとか
CPUのメモリ管理と矛盾が出ちゃうんでしょうかねぇ。

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

これはCOMMAND.COMを使用しないときの指定かと思ってました。
USECMD=1を指定するようにします。

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

(4879) 4910Re^5: VTDOS1.19で圧縮ソフト関連  投稿者:10#   2010/01/22(金) 23:45
参照先:http://vtdos.web.fc2.com
    4907 番 konno さんへのコメント    コメント数 2

pkliteの問題の原因は解明出来ました。
HMAがあって、TPAが広い場合に発生するpkliteの不具合で、
DOS5でHMAが普及しだした当時は割に有名だったようです。
pkliteは後期の2.01も行儀よくないようで、ストリング命令で
セグメントラップアラウンドが発生します。
(これを許容しないマイナーなプロセッサもあるらしい)
VTDOSは便宜上セグメントラップアラウンドはサポートしていません。
Ver.1.21からの対応です。
      - No.4910 -    このTreeへ    コメント元:4907 へ    [リストへもどる ] soft

(4879) 4912Re^6: VTDOS1.19で圧縮ソフト関連  投稿者:10#   2010/01/23(土) 02:12
参照先:http://vtdos.web.fc2.com
    4910 番 10# さんへのコメント

自己レスです。
前回のPKLITE後期バージョンの話は僕の勘違いでした。
恥ずかしいのでVer.1.22ですぐ修正。

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

(4879) 4913昔話  投稿者:としき   2010/01/23(土) 11:20
参照先:http://www.hinocatv.ne.jp/~toshiki/
    4910 番 10# さんへのコメント

> HMAがあって、TPAが広い場合に発生するpkliteの不具合で、
> DOS5でHMAが普及しだした当時は割に有名だったようです。

思い出した。
多くのソフトがDOS5対応版を出すことによって、この話は収束していきました。
だけど、当時、386以降の石を使っているマシンでDOS3で無理やりUMBやHMAを作る
フリーウェアがあって、それを使うことによってあのアプリが動かなくなっただ
の、これもダメだのといった話が多数ありました。DOS3を使い続けている人たち
は、DOS5対応版にバージョンアップするという意識がなかったからですね。
この場合、それまではDOS3で正常に動いていたことから、アプリ側ではなくて、
HMAを作るツールのほうにサポートを求めようとする傾向があって、そのツールを
サポートしているニフティの会議室は大賑わいでした。

#4807で言及した、私がMSCDEXにパッチを当てたのも、まさにこの問題に引っかか
ったからでした。DOS3用のMSCDEXが、DOS3を使っているにもかかわらず、正しく
ないDOSのバージョンである、というメッセージを返してきたのです。
当時の私は今以上に技術力がなく、なにせUMBとHMAを間違えるほどでしたから、
根本原因の究明まではできず、仕方なく、MSCDEXのバージョンチェックルーチン
にパッチを当てて逃げるしかなかったのでした。

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

(4879) 4916Re^4: VTDOS1.19で圧縮ソフト関連  投稿者:としき   2010/01/24(日) 18:58
参照先:http://www.hinocatv.ne.jp/~toshiki/
    4897 番 10# さんへのコメント

> 差し支えなければ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が
エラーを返してくることがあって、それを知らずにはまったこともあったなぁ。
      - No.4916 -    このTreeへ    コメント元:4897 へ    [リストへもどる ] pre

(4879) 4903Re^3: VTDOS1.19で圧縮ソフト関連  投稿者:10#   2010/01/21(木) 23:34
参照先:http://vtdos.web.fc2.com
    4895 番 konno さんへのコメント

command.com はcopyコマンド実行時に送り側も受け側も
Int 21/AX=6C00h EXTENDED OPEN/CREATE
APIでファイルをオープンする際に、
DX = 101h で呼び出してるんですが、
このオプションが非公開機能なんですね。
Interrupt Jump Table では(reserved)となっています。
で、試しに動作や戻り値を試行錯誤してみたんですが、
うまく行きませんでした。
確証が持てないのでこれは現状維持にしたいと思います。
差し支えなければ USECMD=1 でお願いします。

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