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

一括表示


  VZ1.6のバグが直った? - konno 22/09/14-01:09 No.10291
 ┣ Re: VZ1.6のバグが直った? - konno 22/09/16-00:50 No.10292
 ┃┃┣ Libretto を復活させ検証してみた - konno 22/09/17-01:56 No.10293
 ┃ ┗ BL1024*3 は危険、使用禁止に - konno 22/09/20-22:44 No.10297
 ┃ ┗ Re: BL1024*3 は危険、使用禁止に - としき 22/09/20-23:28 No.10298
 ┃  ┗ Re^2: BL1024*3 は危険、使用禁止に - konno 22/09/21-02:33 No.10299
 ┣ VZ1.6のバグ修正版検証中 - konno 22/09/28-21:26 No.10303
 ┣ Bl3072 の大穴が塞がったかも - konno 22/10/11-21:59 No.10322
 ┃ ┗ Re: Bl3072 の大穴が塞がったかも - konno 22/10/12-22:17 No.10323
 ┃ ┗ Re^2: Bl3072 の大穴が塞がったかも - としき 22/10/13-13:25 No.10324
 ┃  ┗ Re^3: Bl3072 の大穴が塞がったかも - konno 22/10/13-20:47 No.10327
 ┃   ┗ Re^4: Bl3072 の大穴が塞がったかも - としき 22/10/16-14:27 No.10340
 ┃    ┗ Re^5: Bl3072 の大穴が塞がったかも - konno 22/10/16-22:46 No.10341
 ┗ 公開版VZの修正ができました。 - konno 22/10/15-02:03 No.10334
  ┗ Re: 公開版VZの修正ができました。 - konno 22/11/10-00:44 No.10379
   ┗ Re^2: 公開版VZの修正ができました。 - 文太 22/11/10-01:08 No.10381
    ┗ Re^3: 公開版VZの修正ができました。 - konno 22/11/10-19:52 No.10382

(10291) 10291VZ1.6のバグが直った?  投稿者:konno   2022/09/14(水) 01:09
   コメント数 4

野ざらし言#5053 に書いた記事ですが転載します。


[ESC]I のバグがVZ1.57a で出ないので、ソースを見比べていました。
そうしたら、気になる箇所があったので、Vn のマーカーを入れてみました。

 text.asm 1.57a 1484行目

seekb_x:
	pushf
	add	ax,[bp].ttop		; ##1.5
	popf
	call	qclose


text.asm 1.6k07t01 1884行目

seekb_x:
	pushf
	add	ax,[bp].ttop		; ##1.5
	cmp	ax,[bp].tend
_if ae
	mov	ax,[bp].tend
	dec	ax
	mov	byte ptr [bp].atrtxt1,1 ;★; Vnマーカー追加
_endif
	popf
	call	qclose


VTDOSの結果は、Bl2048 では NG で、Vn0 反応なし
念のため、Bl8192 を試したら NG で、Vn1 反応あり

おお、と思ってここのルーチンを 1.5 と同じにしてみたら
なんと、VZ1.6では Bl8192 は全て NG だったのが OK になりました!!
MS-DOS Player や DOSVAXJ3 では、Bl1024〜Bl8192 OK
VTDOS では、Bl4096〜Bl8192 OK

ただし、Bl1024*3 だけは、1.57a を含む全てのVZ、環境で誤動作します。
正常時に比べてファイルサイズが大きくなるし、VZが壊れる可能性も。
VTDOS では 'REP MOVSW 命令ラップアラウンド' エラーでVZが落ちます。
これは別のバグ発見か?

現在色々検証中です。

# シン・ゴジラのエネルギー源を突き止めたくらいに興奮しました!!

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

(10291) 10292Re: VZ1.6のバグが直った?  投稿者:konno   2022/09/16(金) 00:50
    10291 番 konno さんへのコメント    コメント数 2

VZの標準マクロ、[ESC]I ファイルの挿入で発覚したバグについて
今回の修正と新たなバグ? について色々検証した結果、どうも今回の修正は
たまたま一部のエリアで正常になっただけのような気がしてきました。

まず、VTDOS MS-DOS Player DOSVAXJ3 での全てのVZで共通するのは
EK- でも EK+ でも
BL1024*3 の時 NG になり、ファイルが大きくなるということです。
今まで EK+ ならバグは出ないと思っていましたが、どうもこのエリアに地雷があるようです。

それでも今回の修正で BL8192 の常用環境で改善されたのなら少し前進できたのかも。
VTDOS では、XM1 EM12 くらいにすれば一番安定して使えると思います。


参考までに、PC98エミュの NP21 の結果も載せます。NP2 は文字化けあり、NP2のバグ?
EK- VZk07t01 VZo VZk07v(今回の修正したもの)
BL1024*1〜BL1024*3 OK
BL1024*4〜BL1024*6 NG ファイルが小さくなる
BL1024*7〜BL1024*8 OK

EK+
BL1024*1〜BL1024*3 OK
BL1024*4〜BL1024*6 NG ファイルが大きくなる (VZk07vのみファイルが小さくなる)
BL1024*7〜BL1024*8 OK

VZ1.57a
EK- でも EK+ でも
BL1024*3 の時のみ NG ファイルが大きくなる


DOSV版と異常の出る範囲が違うのは、ファイルやバッファのサイズが関係しているのか?
PC98版をもし使う機会があるなら、BL1024*4〜BL1024*6 は避けた方がよさそうです。
1.57 を使う人はもういないと思いますが。(^^;

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

(10291) 10293Libretto を復活させ検証してみた  投稿者:konno   2022/09/17(土) 01:56
    10292 番 konno さんへのコメント

検証用にWinMEノートが使えないか、腐海をあさって見ました。
ほとんどのノートPCは液晶が駄目になっていましたが Libretto が起動できました。
仕様は下記のサイトから
https://dynabook.com/pc/catalog/libretto/010507l1/spec.htm

> Libretto L1/060TNCMモデル
> Transmeta Crusoe プロセッサ TM5600 600MHz
> メモリ 	標準/最大 	128MB/256MB(PC100対応、SDRAMうち16MBはシステムで使用)
> 内部ディスプレイ 	10型FLサイドライト付き低温ポリシリコンワイドTFT液晶(※1)1,280×600ドット:1,677万色
> ハードディスク	 	10GB(Ultra ATA対応 全領域がFAT32で設定(Cドライブ1パーティションで設定)。
> 外形寸法(突起部含まず) 	268mm(幅)×167.2mm(奥行)×20.5(最薄部)/29.3mm(高さ)
> 質量 	約1.1Kg(バッテリパック装着時)

さらに、Wikipediaから
> Libretto L1
>     2001年5月18日発売。技術の粋を集めた旧シリーズとは異なり「実用的で低価格なモバイルノート」を標榜。
>     当時としては珍しい「ワイドSXGA」横1280ドット×縦600ドットの10インチ低温ポリシリコンTFT液晶を採用。
>     Windows XPの発売を控えていた事もありWindows Meをプリインストールした。

IBMのWin2000ノートが液晶の四隅が滲んでいるのに、Libretto は綺麗なままです。
最初はハードディスクが回らなかったので、叩いたら回るようになりました。
ファンの音が煩くて使わなくなっていたんですが、まだまだ使えそうです。


さて、本題ですが、検証の結果は、MS-DOS PlayerやDOSVAXJ3 と同じでした。
以上。(^^;

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

(10291) 10297BL1024*3 は危険、使用禁止に  投稿者:konno   2022/09/20(火) 22:44
    10292 番 konno さんへのコメント    コメント数 1

> まず、VTDOS MS-DOS Player DOSVAXJ3 での全てのVZで共通するのは
> EK- でも EK+ でも
> BL1024*3 の時 NG になり、ファイルが大きくなるということです。
> 今まで EK+ ならバグは出ないと思っていましたが、どうもこのエリアに地雷があるようです。

これをトレースすると、最初の #i ブロック挿入 でおかしくなっています。
ファイルオープン直後 ^QC ^QR をやっておけば、一見正常処理できたように見えます。
ところが、ファイルの比較で常に同じ所で文字化けします。全てのVZで同じ現象です。

0007.cgi ログNO.2418の行で 3781bytes ありますが
後半の「横流ししてもらえないかな」の途中で文字化けします。
3700bytes目の「ら」が

横流ししても82
えないかな

このように、$82 と $0a の改行になってしまうのです。
BL1024*3 は、3072 なので、この値が関係ありそうな気もします。
VZ1.57a も含むおそらく全てのVZで同じ現象になります。

さらに驚くことに、BL1024*3 にして、0007.cgi をオープンして
ログNO.2418の行を検索すると、上と同じように文字化けしていました。
VZ1.57a も含むおそらく全てのVZで同じ現象になります。

汚れていたのは、BL1024*3 だったのです。
BL1024*3 は使用禁止にするしかないですね。
これで使っている人はいないと思いますが。
ちなみに、PC98エミュでは同じ現象にはならないのですが、以下略。(^^;

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

(10291) 10298Re: BL1024*3 は危険、使用禁止に  投稿者:としき   2022/09/20(火) 23:28
参照先:http://toshiki.la.coocan.jp/
    10297 番 konno さんへのコメント    コメント数 1

また新しい事実が見つかった感じ。

> BL1024*3 は使用禁止にするしかないですね。

ここで気になるのは、Bl2048のとき。
2048バイトを超える行において、2048バイト目が文字化けするのか否か。

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

(10291) 10299Re^2: BL1024*3 は危険、使用禁止に  投稿者:konno   2022/09/21(水) 02:33
    10298 番 としき さんへのコメント

> ここで気になるのは、Bl2048のとき。
> 2048バイトを超える行において、2048バイト目が文字化けするのか否か。

BL1024*1 でも BL1024*2 でも問題は出ていないので、文字化けもないと思われます。
文字化け位置までのファイルサイズは 135114bytes
1024*16=16384 EMS 1ページ
16384*8=131072
135114-131072=4042
うーむ、関連は無いか。
恐らく何かの境界になっているのでしょうが、わからないですね。

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

(10291) 10303VZ1.6のバグ修正版検証中  投稿者:konno   2022/09/28(水) 21:26
    10291 番 konno さんへのコメント

c.mosさんが1.6でルーチンを追加したからには何か意味があるはずです。
結果的にバグが出たのはルーチンが不完全だったのかも。
私にはまったくわからないですが、ADD 命令でオーバーフローの可能性は考えられます。
その対策の追加ルーチンだとしたら、違和感を感じますね。

普通は ADC とか、JC で分岐させるのにそれをしない理由はわかりませんが
とりあえず JNC 追加で1.6のルーチンを復活させてみました。

Vn のマーカーも入れましたが、NGファイルのテストでも Vn に引っ掛かりません。
なので、オーバーフローしたらマクロトレース状態で止まるルーチンも追加しました。

seekb_x:
	pushf
	add	ax,[bp].ttop		; ##1.57
	jnc	seekb_9			;##k 220923 Bl8192対策?
	add	byte ptr [bp].atrtxt1,1 ;★;; オーバーフローなら Vn1+
	cmp	ax,[bp].tend		;##1.6 ttopとtendアドレスを比較
_if ae					; ttopが上だったら
	mov	ax,[bp].tend		; ax(ttop)にtendを代入
	dec	ax			; アドレスを一つずらす
	add	byte ptr [bp].atrtxt1,10 ;★;; 1.6の修正ルーチン実行で Vn10+
_endif					;
	push	ax				;★トレースONルーチン
	mov	al,1				;
	xchg	cs:stopf,al			;トレースモードに
	pop	ax				;
seekb_9:				;
	popf
	call	qclose
	popm	<di,si,cx,bx>
	ret
seektext endp


この状態でVZを普通に使ってみて様子をみています。
今のところ引っ掛かりませんがね。

ちなみに、このルーチンを公開版 VZk07t01 に追加すると常駐で動かないの。(;_;)
私の私家版常用環境では動くのに。(^^;
やれやれ、どうしたものか。

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

(10291) 10322Bl3072 の大穴が塞がったかも  投稿者:konno   2022/10/11(火) 21:59
    10291 番 konno さんへのコメント    コメント数 1

Bl3072 では 3700bytes を超えるところで改行が入っていました。
ソースに改行を挿入するところがあるはずだと当たりをつけて
「,LF」で検索すると、それらしいところが TEXT.ASM にありました。

fread	proc
中略 410行目
	cmp	si,di
	jne	read3
	mov	byte ptr [si-1],LF
  _break
read3:	cmp	byte ptr [si-1],LF
_until e
	clz
	ret
read9:	stz
read_x:	ret


ここの
	mov	byte ptr [si-1],LF
があやしいと思い、色々試したところ 

	cmp	si,di
	jne	read3
	stc					;★##k 221011 キャリーをセット
	jmps	read9x				;★ ゼロフラグをクリアしてリターン
;	mov	byte ptr [si-1],LF		;★ Bl3072 の時 3700bytesで強制改行(実行しない)
  _break
read3:	cmp	byte ptr [si-1],LF
_until e
read9x:	clz					;★ ゼロフラグをクリアしてリターン
	ret
read9:	stz
read_x:	ret


このように変更したら、Bl3072 で改行文字化けが無くなりました。
大穴と思っていたところが塞がったのです。
もちろんこの変更で他の所に穴が開いた可能性もあります。
しばらく Bl3072 で運用してみようと思います。


あと、CORE.ASM の 276行目

endlin	proc
	pushm	<cx,di,es>
	movseg	es,ds
	mov	di,si
;	mov	cx,-1			;★ VTDOS でラップアラウンドエラーの原因?
	mov	cx,3000h		;★##k 221009 ラインバッファ+アルファ
	mov	al,LF
  repne	scasb

このようにしたら、Bl3072 で起きていた VTDOS でのラップアラウンドエラーが無くなりました。
ここが原因だったのでしょうか?


これで Bl8192 と Bl3072 の蟲の居所がわかりましたが
まだ他にもポインタズレという蟲が残っているようです。

 0007.CGI (170335bytes) を後ろから削っていって
 66882bytes にしたテストファイル
 66882.CGI (66882bytes) に
 0007.CG (132553bytes) を挿入するテストでは
ポインタズレによる行の入れ替えが起こっています。
今回の修正で、他のVZよりは改善したようですが。


# 深淵の大穴は無限に続くのか?

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

(10291) 10323Re: Bl3072 の大穴が塞がったかも  投稿者:konno   2022/10/12(水) 22:17
    10322 番 konno さんへのコメント    コメント数 1

間違った情報を揚げてしまいました。m(__)m


> これで Bl8192 と Bl3072 の蟲の居所がわかりましたが
> まだ他にもポインタズレという蟲が残っているようです。
> 
>  0007.CGI (170335bytes) を後ろから削っていって
>  66882bytes にしたテストファイル
>  66882.CGI (66882bytes) に
>  0007.CG (132553bytes) を挿入するテストでは
> ポインタズレによる行の入れ替えが起こっています。

このテストファイル、作成時点で間違えて行が入れ替わっていました。(>_<)
ズレて蟲が湧いていたのは私の頭でした。(;_;)
このテストファイルのことは忘れてください。m(__)m

結論を言うと、ポインタズレも無くなっていました。
[ESC]i 関連のバグは全て無くなったように見えます。

> あと、CORE.ASM の 276行目
> 
> endlin	proc
> 	pushm	<cx,di,es>
> 	movseg	es,ds
> 	mov	di,si
> ;	mov	cx,-1			;★ VTDOS でラップアラウンドエラーの原因?
> 	mov	cx,3000h		;★##k 221009 ラインバッファ+アルファ
> 	mov	al,LF
>   repne	scasb
> 
> このようにしたら、Bl3072 で起きていた VTDOS でのラップアラウンドエラーが無くなりました。

このルーチンも元に戻しても問題無くなりました。
バグのせいでエラーになっていたようです。(VTDOSのチェック凄い!)
他の環境ではたまたま問題が顕在化しなかったのかもしれませんね。
このルーチンは他からも呼ばれているので、3000h とかは危ないかもしれません。

ということで、あとは運用試験で問題が出ないか様子を見るだけとなりました。


# このまま問題が出ませんように(祈)

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

(10291) 10324Re^2: Bl3072 の大穴が塞がったかも  投稿者:としき   2022/10/13(木) 13:25
参照先:http://toshiki.la.coocan.jp/
    10323 番 konno さんへのコメント    コメント数 1

> [ESC]i 関連のバグは全て無くなったように見えます。

これは期待できます。
次はテストバージョンのリリースですね。高橋さんやDANNYさんのように。
ところで、今回の書き換えで、実行ファイルのサイズは増えるんですよね?
いや、もしファイルサイズが変わらないとか減るとかいうのであれば、それこそ
バイナリエディタなりを使って、製品版Vzに手作業でパッチを当てることもできる
な、と妄想したもので。
      - No.10324 -    このTreeへ    コメント元:10323 へ [リストへもどる] soft

(10291) 10327Re^3: Bl3072 の大穴が塞がったかも  投稿者:konno   2022/10/13(木) 20:47
    10324 番 としき さんへのコメント    コメント数 1

> ところで、今回の書き換えで、実行ファイルのサイズは増えるんですよね?
> いや、もしファイルサイズが変わらないとか減るとかいうのであれば、それこそ
> バイナリエディタなりを使って、製品版Vzに手作業でパッチを当てることもできる
> な、と妄想したもので。

ファイルサイズは増えると思うのでバイナリパッチは無理でしょうね。
でも、Bl3072 の修正箇所だけならもしかしたら・・・・

そうだ! 公開版にそこだけの修正でどうなるか試してみようかな。
良いヒントをありがとうございます。

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

(10291) 10340Re^4: Bl3072 の大穴が塞がったかも  投稿者:としき   2022/10/16(日) 14:27
参照先:http://toshiki.la.coocan.jp/
    10327 番 konno さんへのコメント    コメント数 1

> そうだ! 公開版にそこだけの修正でどうなるか試してみようかな。

もし、1.60に、そこだけの修正を当てるパッチというのが作れるのであれば、それ、
私も欲しい。うちで試してみて、状況がどう変わるか見てみたいです。

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

(10291) 10341Re^5: Bl3072 の大穴が塞がったかも  投稿者:konno   2022/10/16(日) 22:46
    10340 番 としき さんへのコメント

> もし、1.60に、そこだけの修正を当てるパッチというのが作れるのであれば、それ、
> 私も欲しい。うちで試してみて、状況がどう変わるか見てみたいです。

先日試したときは正常だったはずなんですが、Windowsの更新後は異常になってしまいました。
Windowsの更新が影響しているのでしょうか、メモリ管理とかディスク管理とか環境変数とか。

ということで、現在は常用している私家版のみ正常動作しているように見える状況です。
どこが違うのかさっぱりわかりません。(>_<)
なので、パッチは無理そうです。

メモリのキャッシュとかが影響していたりして・・・

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

(10291) 10334公開版VZの修正ができました。  投稿者:konno   2022/10/15(土) 02:03
    10291 番 konno さんへのコメント    コメント数 1

#10303> ちなみに、このルーチンを公開版 VZk07t01 に追加すると常駐で動かないの。(;_;)
> 私の私家版常用環境では動くのに。(^^;

と書いていましたが、弄りすぎて原型がわからなくなっていたので
元に戻そうとしましたが戻せない。(>_<)
バイナリの比較で一致するまで散々苦労しました。
やっぱり公開版のフォルダは保存しておかないとなぁ、と。(何回目だ)

やっと元に戻ったので、Bl3072対応の修正だけしてみましたが効果なし。
Bl8192対応の修正もして、こちらは直ったのですが、Bl3072 は駄目です。

ラップアラウンドエラーが、MEMO.asm の memmove のルーチンの934行目
	rep	movsw				;VTDOS ERR
で出ているので、そこを読んでいる所を片っ端から調べました。
そうしたら、やっとわかりました。

OPEN.ASM 2139行目の
add_logtbl	proc
    中略 2177行目
		sub	cx,si
		jc	addlog9			;★ ##k 221014 Bl3072 対策2
		call	memmove			;※ ここの rep movsw でエラーになる
		add	di,cx
		lea	si,[bp].path
	_endif
		call	strcpy
		inc	di
		mov	si,di
		mov	ax,[bp].lnumb
		call	set_logtbl
		clr	al
		stosb
addlog9:	popm	<es,ds>
		ret
add_logtbl	endp

このように、memmove の直前に キャリー分岐を入れたら直りました。\(^^)/ ヤッタ-
常用している私家版では先の2か所の修正だけで直ったので、謎が残りますが。

色々試してみて問題ないようならテスト版としてアップしようと思います。

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

(10291) 10379Re: 公開版VZの修正ができました。  投稿者:konno   2022/11/10(木) 00:44
    10334 番 konno さんへのコメント    コメント数 1

VTDOS のエラーは #i のルーチンで起こっているように見えます。
今回はその中からエラー回避でき、テストデータで問題が出ない箇所を見つけました。

MEMO.ASM 855行目あたり

txtmov1	proc
	push	es
	movseg	es,ds
	mov	cx,[bp].tend
	sub	cx,si
	jc	txtm19			;★##k 221108 VTDOSエラー回避
	call	memmove			;VTDOS err?
	add	cx,di
	mov	[bp].tend,cx		; update tend
txtm19:	pop	es			;
	ret
txtmov1	endp

この★印を追加することで Bl1024*3 でもエラーで落ちなくなりました。
Bl1024*3 の時は内容が壊れますが、この追加があれば他の修正がいらないようです。
非常駐だと Bl1024*3 でも正常処理されます。謎です。違いは何なのだろう。

完全ではありませんがこれと Bl8192 の修正をしたテスト版VZを揚げてみようと思います。

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

(10291) 10381Re^2: 公開版VZの修正ができました。  投稿者:文太   2022/11/10(木) 01:08
    10379 番 konno さんへのコメント    コメント数 1

konnoさま(さま付けかよ)

 お疲れ様です。

>完全ではありませんがこれと Bl8192 の修正をしたテスト版VZを揚げてみようと思います。

 テスト版を是非。ただ、ベースになった版も明記ください。じゃないと長期にわたって
使用し、バグ、出る? 出ない? とはできないからです。
 もっとも安定したヴァージョンをベースにしてくれると嬉しいです。それは、どの版?

--- my vz.def ---
Bl8192			;line buf (256..(Bt*1024/8))
-----------------

 これは、日本語を使う身としては、さすがに譲れませんから。日常業務において。

 テストだけしてみて欲しいというのであれば、曖昧でもいいですから、こういう場合はどう?
と指示してくださると嬉しいです。しばらくテスターになる気持ち(ほい?)はありますよ。


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

(10291) 10382Re^3: 公開版VZの修正ができました。  投稿者:konno   2022/11/10(木) 19:52
    10381 番 文太 さんへのコメント

>  テスト版を是非。ただ、ベースになった版も明記ください。じゃないと長期にわたって
> 使用し、バグ、出る? 出ない? とはできないからです。
>  もっとも安定したヴァージョンをベースにしてくれると嬉しいです。それは、どの版?

ベースは VZK07T01 です。過去記事で
#10257:Re^2: すれ違いと待ち伏せ  投稿者:文太   2022/08/24(水) 

>  僕は、Vzk k07t01 という版を使っているようです。うーん、このキー増強とか
> だけ、k07t01 に入れたいな、とか思っています。

こう書かれていたので、VZK07T01 が良いのかなと思いました。
それで確認のためにVZの部屋を見てみたら、げげ、VZK07T01.LZH が公開停止になっている!!
検索してみると
#8590: VZk07t01 公開停止 & VZk07t 公開版の差し替え 投稿者: konno   2018/11/16(金)

> #8369 で公開したVZk07T1 (2018/10/17) は、バグが有ったので、公開停止しました。
> 使用されている人はすぐに使用中止願います。
> 代わりに、VZk07t 公開版の pc ズレ修正・差し替え版をアップしました。
> こちらは問題ないと思います。

こう書いていました。その理由は #8591> DOSモバでSORT.DEF(高橋版)を試してみました。
> VZO、VZT、は問題なく動作しました。が
> VZK07t1 は、起動BATで常駐した時は、異常になります。
> 
> 調べてみたら、アセンブルでポカミスしていました。
> この版はすぐに公開停止しましたが、使用している人はすぐ使用中止願います。
> ご迷惑おかけして申し訳ありません。

ということなんですが、どうも文太さんとshadowさんは、K07T01 をお使いのようで。
#08611 の文太さんの書き込みでは

> 2018/10/17  19:11            62,184 vz.com	(k07t01)	;最新−1(前の版)

この日付とサイズの版が良いということですよね。
私はこのころ話がすれ違っているのに気が付いていなかったようです。
こちらの方が問題ないということであれば、再公開しようと思います。
ソースも公開すれば違いとか確認できますね。

>  テストだけしてみて欲しいというのであれば、曖昧でもいいですから、こういう場合はどう?
> と指示してくださると嬉しいです。しばらくテスターになる気持ち(ほい?)はありますよ。

ファイルが壊れる可能性はありますが、テストしていただいて問題点がわかればうれしいです。
よろしくお願いいたします。

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