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

  vzk07v6 UPしました - konno 23/02/28-23:49 No.10586
  ┣ Re: vzk07v6 ソースも UP - konno 23/03/01-00:32 No.10587
  ┃┣ WinNT系のコマンドライン問題解決の方法 - konno 23/03/01-01:03 No.10588
  ┃┃┗ Re: WinNT系のコマンドライン問題解決の方法 - konno 23/04/08-01:47 No.10758
  ┃┗ Re^2: vzk07v6 ソースも UP - shadow 23/03/01-09:14 No.10589
  ┃ ┗ Re^3: vzk07v6 ソースも UP - konno 23/03/01-14:49 No.10590
  ┃  ┗ Re^4: vzk07v6 ソースも UP - shadow 23/03/01-17:24 No.10591
  ┃   ┣ Re^5: vzk07v6 ソースも UP - shadow 23/03/01-17:47 No.10592
  ┃   ┃┗ Re^6: vzk07v6 ソースも UP - konno 23/03/02-23:31 No.10599
  ┃   ┗ Re^5: vzk07v6 ソース駄目でした。m(__)m - konno 23/03/01-21:15 No.10593
  ┣ K07v6 ソース再アップ - konno 23/03/02-17:46 No.10594
  ┃┗ Re: K07v6 ソース再アップ - shadow 23/03/02-22:13 No.10597
  ┣ Re: vzk07v6 UPしました - めざら 23/03/02-20:17 No.10595
  ┃┗ Re^2: vzk07v6 UPしました - konno 23/03/02-21:31 No.10596
  ┃ ┗ Re^3: vzk07v6 UPしました - めざら 23/03/02-23:00 No.10598
  ┣ Re: vzk07v6 UPしました - めざら 23/03/03-16:18 No.10600
  ┃┗ Re^2: vzk07v6 Rf- にバグ - konno 23/03/03-21:41 No.10602
  ┃ ┗ Re^3: vzk07v6 Rf- にバグ - めざら 23/03/04-10:33 No.10606
  ┃  ┗ Re^4: vzk07v6 Rf- にバグ - konno 23/03/05-01:29 No.10612
  ┃   ┗ Re^5: vzk07v6 Rf- バグ直ったかも - konno 23/03/13-23:42 No.10623
  ┣ vzk07v6h UP - konno 23/03/15-00:21 No.10624
  ┃┣ Re: vzk07v6h UP - めざら 23/03/15-09:36 No.10625
  ┃┃┗ Re^2: vzk07v6h UP - konno 23/03/15-16:53 No.10627
  ┃┃ ┗ Re^3: vzk07v6h UP - めざら 23/03/16-08:15 No.10629
  ┃┃  ┗ Re^4: vzk07v6h UP - konno 23/03/17-01:23 No.10630
  ┃┣ Re: vzk07v6h UP - shadow 23/03/15-15:48 No.10626
  ┃┃┗ Re^2: vzk07v6h ソース差し替え - konno 23/03/15-17:16 No.10628
  ┃┃ ┗ Re^3: vzk07v6h ソース差し替え - shadow 23/03/17-12:45 No.10631
  ┃┃  ┗ Re^4: vzk07v6h ソース差し替え - konno 23/03/17-18:12 No.10633
  ┃┗ vzk07v6h バグあり、使用中止してください - konno 23/03/22-17:36 No.10690
  ┃ ┗ Re: vzk07v6h バグあり、使用中止してください - めざら 23/03/24-13:53 No.10695
  ┃  ┗ Re^2: vzk07v6h バグあり、使用中止してください - konno 23/03/24-18:28 No.10696
  ┗ Re: vzk07v6 UPしました - めざら 23/03/17-22:05 No.10637
   ┣ Re^2: vzk07v6 UPしました - 文太 23/03/18-01:38 No.10640
   ┗ Re^2: vzk07v6 のバグ? - konno 23/03/18-02:09 No.10642
    ┗ VTDOSのEMS環境は避けた方がいいです。 - konno 23/03/18-16:24 No.10649
     ┣ Re: VTDOSのEMS環境は避けた方がいいです。 - konno 23/03/18-21:30 No.10652
     ┃┗ Re^2: VTDOSのEMS環境は避けた方がいいです。 - 文太 23/03/19-15:56 No.10665
     ┃ ┗ Re^3: VTDOSのEMS環境は避けた方がいいです。 - konno 23/03/20-00:41 No.10669
     ┃  ┗ Re^4: VTDOSのEMS環境は避けた方がいいです。 - 文太 23/03/20-01:52 No.10671
     ┃   ┣ TPAEXT=1 - 文太 23/03/20-12:16 No.10675
     ┃   ┗ inst.asm - 文太 23/03/22-01:29 No.10689
     ┃    ┗ Re: inst.asm - konno 23/03/22-22:32 No.10692
     ┣ Re: VTDOSのEMS環境は避けた方がいいです。 - めざら 23/03/18-21:34 No.10653
     ┃┗ Re^2: VTDOSのEMS環境は避けた方がいいです。 - konno 23/03/18-23:41 No.10654
     ┃ ┗ VTDOSのEMS環境は更なる検証が必要 - konno 23/03/20-01:39 No.10670
     ┃  ┣ Re: VTDOSのEMS環境は更なる検証が必要 - としき 23/03/20-01:56 No.10672
     ┃  ┃┗ Re^2: VTDOSのEMS環境は更なる検証が必要 - konno 23/03/20-13:42 No.10676
     ┃  ┗ Re: VTDOSのEMS環境は更なる検証が必要 - めざら 23/03/20-10:35 No.10674
     ┃   ┗ Re^2: VTDOSのEMS環境は更なる検証が必要 - konno 23/03/20-14:41 No.10677
     ┃    ┗ Re^3: VTDOSのEMS環境は更なる検証が必要 - めざら 23/03/20-22:34 No.10678
     ┃     ┗ Re^4: VTDOSのEMS環境は更なる検証が必要 - konno 23/03/21-01:22 No.10680
     ┃      ┗ Re^5: VTDOSのEMS環境は更なる検証が必要 - めざら 23/03/21-13:51 No.10685
     ┃       ┗ Re^6: VTDOSのEMS環境は更なる検証が必要 - konno 23/03/21-21:23 No.10686
     ┗ Re: VTDOSのEMS環境は避けた方がいいです。 - 文太 23/03/18-23:43 No.10655
      ┣ ファイル中身の破損 - 文太 23/03/19-16:00 No.10666
      ┃┗ Re: ファイル中身の破損 - 文太 23/03/22-01:14 No.10688
      ┃ ┣ Re^2: スワップとEMSとBT - konno 23/03/22-22:26 No.10691
      ┃ ┗ Re^2: ファイル中身の破損 - 文太 23/03/23-00:37 No.10693
      ┗ Re^2: VTDOSのEMS環境は避けた方がいいです。 - konno 23/03/20-00:38 No.10667
       ┗ Re^3: VTDOSのEMS環境は避けた方がいいです。 - 文太 23/03/20-02:05 No.10673

(10586) 10586vzk07v6 UPしました  投稿者:konno   2023/02/28(火) 23:49
   コメント数 6

長らくお待たせしましたが、vzk07v6 UPしました

k07v6 (2023-02-28)
 ・k07t5 までの機能は全部取り込んであると思います。
 ・Rf+ DOS窓のファイラーで#R 編集モードで[ESC]P [ESC]S ロングファイル名変更となる(大文字小文字区別する)
    バッファの制限により、パスの長さ約80文字以上ではSFNとなる。
 ・Sl ステータスライン表示オプション変更 0:time 1:free 2:LFN View open 3:sl1+sl2
  sl2 ならステータスラインでロング名表示  (Win9x、WinXP、MS-DOS Playrは sl2は指定しないこと)
  ※ この機能は VTDOS と DOSVAXJ3(lfn_space=true) の場合に正常動作します。
 ・WinNT系のDOS窓コマンドラインの安定化 (検証中)
 ・[ESC]i ファイル挿入時のVZの不具合を修正してみた (検証中)
  VTDOS でのラップアラウンドエラーを回避しています。
  ※BL1024*3 だとファイル内容が壊れます。(全てのVZで起こるバグなのでこの設定は危険)
   詳細は掲示板を読んでください。不具合を見つけたら掲示板に報告願います

   高橋版VZに対する自己解凍差分になっています。
  バグ等あるかと思いますので、ご使用は自己責任で。

VZの部屋にあります。

      - No.10586 -    このTreeへ           [リストへもどる] soft


(10586) 10587Re: vzk07v6 ソースも UP  投稿者:konno   2023/03/01(水) 00:32
    10586 番 konno さんへのコメント    コメント数 2

ソースの差分も UPしました。
差分の取り方を忘れてしまって、後回しになってしまいました。(^^;

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


(10586) 10588WinNT系のコマンドライン問題解決の方法  投稿者:konno   2023/03/01(水) 01:03
    10587 番 konno さんへのコメント    コメント数 1

#10581 からの話題ですが

> これを見て閃きました。command.com をフックさせなければいいのではないかと。
> FreeCOM と DOSVAXJ3 の環境では、zp はゼロになります。フック出来ていないのです。
> それなのに問題なく動作しているので、WinNT系でも同じくフックさせなければどうなる?
> 
> で、やってみました。
> 正しい位置を検索するのは難しいですが、わざと失敗させるのなら簡単です。(^^;

実際のソースでは

	mov	bx,cs:tpafreep		; MAIN.ASM 318:GDATA tpafreep, dw, 0 ; ZP
	tst	bx
	jnz	alloc8
	mov	di,0600h
;	mov	di,0380h		;0600h ##k07vt2b
	mov	cx,400h			;300h 1.60 ; win95
	cmp	byte ptr cs:os_win,5	; ##k 230225  WinNT系DOS窓なら ZP を 0 に 
	je	winnt			;
	cmp	ah,5			; ##16
	jae	alloc1
;	mov	bx,0465h
;	cmp	ah,5			; ##156.96  ##157.xx  DOS 5.0
;	je	alloc8
	pop	es
	push	es
	mov	di,0200h
;	mov	cx,500h ;100h		;##k07f
winnt:	mov	cx,100h			;##k07v6c


コメントの多さが試行錯誤を物語っていますが、このルーチンの肝はここです。

	cmp	byte ptr cs:os_win,5	; ##k 230225  WinNT系DOS窓なら ZP を 0 に 

os_win とは、VZkで追加したオプション ow で、この数値が 5 なら WinNT系の DOS5 です。
VTDOS なら、AH に 1、AL に DOSのメジャーバージョン(DOS6.2なら 6 )となります。

Win98ME		ow:8h	MSDOS 8.0
Win2000		ow:5h	DOS 5.0
WinXP		ow:5h	DOS 5.0
VTDOS		ow:106h	MSDOS 6.2
MS-DOS Player	ow:7h	FreeCOM 7.0
DOSVAXJ3	ow:0	DOS 7.0 相当?

どうやら DOSVAXJ3 は、アイドル推し(コール)してないようですね。(^^;
CPU負荷が他のエミュより若干高く見えるのは関係あるかしらん。

 ax1680h  INT2fh  で判定しているもので。(^^;

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


(10586) 10758Re: WinNT系のコマンドライン問題解決の方法  投稿者:konno   2023/04/08(土) 01:47
    10588 番 konno さんへのコメント

#10588 の続きです。
記事で書き忘れていたのですが、ソースを見なおしていて思い出しました。
先のソースは前半で、後半の処理ルーチンが漏れていました。

dos.asm 1249行あたり
	mov	ax,cs
	cmp	byte ptr cs:os_win,5	; ##k 230225  NT系コマンドライン不具合対策
	je	winnt5			; ##k 
	tstw	es:[mcb_psp]		; ## この2行が		2010-2-10
	jz	chkmcb9			; ## 不要と思われる	by 10#
winnt5:	cmp	es:[mcb_psp],ax
chkmcb9:pop	es
	ret
checkmcb endp

ソースを公開した後にコメントを追加しているもので、見落としていたのです。(^^;
WinNT系なら2行をスキップするように変更したのですが、その2行に 10#さんのコメントが。(^^;
当時の記事を引用します。

-----------------------------------------------------------
#4999: Re^5: VTDOS v1.22 で分割画面で異常 投稿者: 10#   2010/02/10(水) 00:59

F_REALLOCが未割り当て領域エラーを返した場合の処理は省略されている模様。
検査用のローカルサブルーチンcheckmcbをレビュー。

該当箇所・DOS.ASM 1250付近
> checkmcb proc
>         push    ax
>         dec     ax
>         mov     es,ax
>         mov     al,es:[mcb_id]
>         cmp     al,'M'
> _ifn e
>         cmp     al,'Z'
>         jne     chkmcb9
> _endif
>         mov     ax,cs
>         tstw    es:[mcb_psp]	; ## この2行が
>         jz      chkmcb9	; ## 不要と思われる
>         cmp     es:[mcb_psp],ax
> chkmcb9:pop     es
>         ret
> checkmcb endp

呼び出し仕様「割り当て済みチェック」に対して、
「未割り当てを含む有効なMCBチェック」であることが判明。
この論理ではexpandfarが空き領域に対してF_REALLOCを
呼び出しうるため、不具合であると仮定。
問題箇所をコメントアウトしてVZをリビルド。

パッチ済みのVZで追試を行いました。
結果、SW3の時に画面分割を行っている場合は再現しましたが、
それ以外の場合は改善されている様子です。

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

このように、2010年当時に10#さんは既にVZの不具合部分を特定していたようなのです。
私はそれを忘れていて、たまたまWinNT系対策のためにそこをスキップさせたのでした。
恐らくそこの2行をコメントにしても問題ないどころか改善されていたかもしれないと思われます。

やっぱりプロのプログラマーは凄いですね。
10#さんはじめ、みなさまに感謝です。m(__)m

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


(10586) 10589Re^2: vzk07v6 ソースも UP  投稿者:shadow   2023/03/01(水) 09:14
    10587 番 konno さんへのコメント    コメント数 1

お疲れ様です。
ソースは高橋版への差分でしょうか?
確認していただければ幸いです。
      - No.10589 -    このTreeへ    コメント元:10587 へ [リストへもどる] soft


(10586) 10590Re^3: vzk07v6 ソースも UP  投稿者:konno   2023/03/01(水) 14:49
    10589 番 shadow さんへのコメント    コメント数 1

> ソースは高橋版への差分でしょうか?

はい、ソースも高橋版への差分です。
ソースを別フォルダにコピーして、カレントにして、そこに 差分.com を置いて実行です。

久しぶりというか、色々忘れているので、問題あれば教えてください。

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


(10586) 10591Re^4: vzk07v6 ソースも UP  投稿者:shadow   2023/03/01(水) 17:24
    10590 番 konno さんへのコメント    コメント数 2

実行した結果を貼り付けますね。
正しい差分が作成できてないと思われます。

C>K07V6_S.COM
WSP self update 1.50 amaproワキチ

xscr.asm 完了!
block.inc 完了!
sprintf.inc 完了!
std.inc 完了!
vz.inc 完了!

1999/05/29  14:20             7,097 xscr.asm
1991/12/16  01:57             1,460 block.inc
2004/05/29  11:21             5,476 sprintf.inc
2023/02/11  04:18             8,962 std.inc
2023/02/28  22:33            19,582 vz.inc

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


(10586) 10592Re^5: vzk07v6 ソースも UP  投稿者:shadow   2023/03/01(水) 17:47
    10591 番 shadow さんへのコメント    コメント数 1

UPされている圧縮ファイルのサイズが小さいですねぇ。

3,406 K07V6_S.LZH
      - No.10592 -    このTreeへ    コメント元:10591 へ [リストへもどる] soft


(10586) 10599Re^6: vzk07v6 ソースも UP  投稿者:konno   2023/03/02(木) 23:31
    10592 番 shadow さんへのコメント

> UPされている圧縮ファイルのサイズが小さいですねぇ。
> 3,406 K07V6_S.LZH

これには参りました。(>_<)
最初はVZKが悪いのかと疑いましたが、高橋版でも同じでした。
次に VTDOS とかエミュの環境を変えたり色々変えてみても駄目で。
wsp.com の実行結果が

VTDOS|C:\VZ\UP>WSP -A c:\vz\vz16\T03K2\view.asm c:\vz\K07v6\view.asm K07v6s
K07v6s.WUP に差分データを結合します.

0.....10.....20.....30.....40.....50.....60.....70.....80.....90....100(%)
=======================*******=*======**==============**===*===========  完了

VTDOS|C:\VZ\UP>WSP -A c:\vz\vz16\T03K2\block.inc c:\vz\K07v6\block.inc K07v6s

ファイルが存在しないか,ファイルの入出力にエラーが発生しました.

VTDOS|C:\VZ\UP>WSP -A c:\vz\vz16\T03K2\sprintf.inc c:\vz\K07v6\sprintf.inc K07v6s
K07v6s.WUP を作成します.


どうもここのエラーで新規作成に戻っているようです。
ファイル内容か実行ファイルが壊れているかもと疑いましたがシロでした。
さて、この後私の取った行動はどれでしょう。

 1.問題が解決するまで寝ないで頑張った。
> 2.色々頑張ったが解決できなくて、諦めて寝た。
 3.解決できなくて絶望し、窓を開けてノートPCを思い切りエイっと・・・


さて、翌日になって、wsp のドックを読んだら

> 作成する差分ファイルの大きさはいくら大きくても結構ですが、結合する差分データは60KB以内でなければなりません。

・・・もしかして、差分ファイルが60kを超えてエラーになっている?
だって、前回の k07t01 の差分ファイルは
 36,197  k07t01s.com
まだまだ余裕があったのに、今回の修正でそんなに変わったというのか。

それで、差分ファイルを2つに分けてやって、やっと出来ました。

2023/03/02  16:40    53,125 K07v6s1.COM
2023/03/02  16:41    19,451 k07v6s2.com

この2つを合計すると、73728bytes (クラスタ)。こんなにあるとは・・・・


# 思えば遠くへ来たもんだ・・・・

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


(10586) 10593Re^5: vzk07v6 ソース駄目でした。m(__)m  投稿者:konno   2023/03/01(水) 21:15
    10591 番 shadow さんへのコメント

> 実行した結果を貼り付けますね。
> 正しい差分が作成できてないと思われます。

ああ、すみません、全く確認していませんでした。m(__)m
とりあえずあがっているのは削除します。

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


(10586) 10594K07v6 ソース再アップ  投稿者:konno   2023/03/02(木) 17:46
    10586 番 konno さんへのコメント    コメント数 1

K07v6 ソースの差分を再アップしました。
差分作成が上手くいかず、時間がかかってしまいました。(^^;

K07v6_s.lzh を解凍すると

K07v6s1.com    53,125 
k07v6s2.com    19,451 

この2つの自己差分ファイルになります。
新規フォルダを作成し、高橋版最終 T03K2 のソースを全てコピーし
そこにこの2つの自己差分ファイルを入れて、カレントにし、実行します。

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


(10586) 10597Re: K07v6 ソース再アップ  投稿者:shadow   2023/03/02(木) 22:13
    10594 番 konno さんへのコメント

お疲れ様です。
ソース差分当てれました。
このソースから62,768 vzibmj.comもできました。
有難うございました。
      - No.10597 -    このTreeへ    コメント元:10594 へ [リストへもどる] soft


(10586) 10595Re: vzk07v6 UPしました  投稿者:めざら   2023/03/02(木) 20:17
参照先:http://mezala.la.coocan.jp/
    10586 番 konno さんへのコメント    コメント数 1

更新を有難うございます。
高橋版(VZIBMJ.COM 1999-12-21 60,888bytes)への差分ですよね。

差分が当たらないなぁ……何か勘違いしてるのかも。
      - No.10595 -    このTreeへ    コメント元:10586 へ [リストへもどる] soft


(10586) 10596Re^2: vzk07v6 UPしました  投稿者:konno   2023/03/02(木) 21:31
    10595 番 めざら さんへのコメント    コメント数 1

> 更新を有難うございます。
> 高橋版(VZIBMJ.COM 1999-12-21 60,888bytes)への差分ですよね。

はい、そうです。T03K2 です。

> 差分が当たらないなぁ……何か勘違いしてるのかも。

うちでは問題なく出来ました。VTDOS + VZK07v6 の環境です。
高橋版VZ と差分ファイルを同じフォルダに置いて、カレントにして、差分.com を実行です。
2023/02/28  22:34    62,768 vzibmj.com
が出来ます。

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


(10586) 10598Re^3: vzk07v6 UPしました  投稿者:めざら   2023/03/02(木) 23:00
参照先:http://mezala.la.coocan.jp/
    10596 番 konno さんへのコメント

カレントにしていませんでした(^o^;

62,768bytes 2023-02-28 22:34 の VZIBMJ.COM がめでたく出来ました。
お騒がせ致しました。m(_'_)m

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


(10586) 10600Re: vzk07v6 UPしました  投稿者:めざら   2023/03/03(金) 16:18
参照先:http://mezala.la.coocan.jp/
    10586 番 konno さんへのコメント    コメント数 1

試用レポートです。

SL 起動後にも変更可能なのですね。+1 +2 とも正常に動作しています。

RF こちらも起動後に変更可能。#75#82 とも正常な動作を確認しました。

気づいたことがあります。
Rf- のとき,長いファイル名のテキスト…例えば「wforum(000).css」…を開くと,ステータスラインには長いファイル名で表示されます。そして,#82 で…例えば「wforum(000).csss」…長いファイル名でリネームすると,「WFORUM(000).CSSS」のようにすべて大文字になります。こののち #75 で保存すると短いファイル名が長いファイル名側に影響せず,すべて大文字の長いファイル名で保存されます。(短いファイル名は WFORUM~1.CSS と相対的名称になります)

こういう現象は想定内でしたか?
(こうして欲しいとか,こうあらねばならぬ…ということでなく,単なる興味です)

あと,OT 新設の関係で SL は廃止されたと以前アナウンスされたと思いますが,復活 SL と OT の関係はどのように考えればよいでしょうか。マクロキーみたいな後優先とか便利な仕組みはないと思いますので,念のために伺いたいと思いました。

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


(10586) 10602Re^2: vzk07v6 Rf- にバグ  投稿者:konno   2023/03/03(金) 21:41
    10600 番 めざら さんへのコメント    コメント数 1

> Rf- のとき,長いファイル名のテキスト…例えば「wforum(000).css」…を開くと,ステータスラインには長いファイル名で表示されます。そして,#82 で…例えば「wforum(000).csss」…長いファイル名でリネームすると,「WFORUM(000).CSSS」のようにすべて大文字になります。こののち #75 で保存すると短いファイル名が長いファイル名側に影響せず,すべて大文字の長いファイル名で保存されます。(短いファイル名は WFORUM~1.CSS と相対的名称になります)

これは不味いですね、元々 Rf+ は、SFNでも大文字小文字を区別したいから作ったのです。
ロング名なら、Rf- でも大文字小文字を区別しないといけませんね。バグです。
これは直します。
バグ報告ありがとうございました。m(__)m


> あと,OT 新設の関係で SL は廃止されたと以前アナウンスされたと思いますが,復活 SL と OT の関係はどのように考えればよいでしょうか。マクロキーみたいな後優先とか便利な仕組みはないと思いますので,念のために伺いたいと思いました。

え、えーと、OT は無くなっていますね。(^^;
k07o-k07q と k08o-k08q まではありますが、それ以降は廃止したようです。(^^;
説明書きに残ったままでした。申し訳ない。m(__)m

SL も OT 廃止に伴って復活したということです。
元の高橋版ではフラグだったのを、変数に変えています。

説明書の VZK.TXT も、VZK.DOC に変えて更新しますのでしばしお待ちを。m(__)m

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


(10586) 10606Re^3: vzk07v6 Rf- にバグ  投稿者:めざら   2023/03/04(土) 10:33
参照先:http://mezala.la.coocan.jp/
    10602 番 konno さんへのコメント    コメント数 1

> 元々 Rf+ は、SFNでも大文字小文字を区別したいから作ったのです。

 「SFNの長さに納まるLFN」と解釈してよいでしょうか。

 konnoさんご自身としては「バグ」という認識なのですね。
 「仕様」としても影響はないと思ったのですが,そのような認識であれば,敢えて報告しておいてよかったです。(いつもろくにレポートできていないので)

> ロング名なら、Rf- でも大文字小文字を区別しないといけませんね。バグです。

 ここはちょっとわかりませんでした。
 デフォルトなら環境依存でよいのではないですか?
 VTDOS環境でLFNがなんとなく通ってしまうという仕様の延長線上ですよね。
 (環境が関係ないのなら別ですけど……)

> え、えーと、OT は無くなっていますね。(^^;

 あ,あら(^^; 意外な展開……

> 元の高橋版ではフラグだったのを、変数に変えています。

 Rf は konnno さんの独自拡張ですよね。高橋版の LF と混同しやすいけれど。

 自分なりの解釈で版の詳細を追記しました。↓ 錯誤の有無をご確認ください。
 http://mezala.la.coocan.jp/vz/history/verdetail.html#k07v6

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


(10586) 10612Re^4: vzk07v6 Rf- にバグ  投稿者:konno   2023/03/05(日) 01:29
    10606 番 めざら さんへのコメント    コメント数 1

>  「SFNの長さに納まるLFN」と解釈してよいでしょうか。

まあそんな感じのような・・・いやいや
●RF+ : SFNファイラー( LF- )でも LFN リネーム対応、SFNでも大文字小文字区別
これが仕様だったはず。(^^;

>  konnoさんご自身としては「バグ」という認識なのですね。
>  「仕様」としても影響はないと思ったのですが,そのような認識であれば,敢えて報告しておいてよかったです。(いつもろくにレポートできていないので)

いや、ロング名が大文字に勝手に変換されたら困りますよね。
SFNの時は大文字小文字を区別する感覚が無かったかもですが。
私が考えていた仕様としては

VZT.DOC
●LF+ : LFN 対応ファイラー
●ファイラーコマンド #N #R #D は lf+ 時のみ LFN になります

VZK.DOC
●RF+ : SFNファイラー( LF- )でも LFN リネーム対応、SFNでも大文字小文字区別

●SL : ステータスライン表示オプション
    0:time 1:free 2:ロングファイル名でオープン、表示 3:sl1+sl2
    編集モードで [ESC]P [ESC]S がロング名(大文字小文字区別)になる。
    ※ Win9x、WinXP、MS-DOS Playrは sl2は対応していないので指定しない。
    ※ この機能は VTDOS と DOSVAXJ3(lfn_space=true) のみ対応。

元々は、RF フラグだけでステータスライン表示も兼ねていたのを無理やり分離したので
実際使ってみると、RF+ だけでもステータスラインがLFN表示になりますね。まあいいか。
MS-DOS Playr でも出来そうな気がして弄ってみたんですが、どうも無理っぽいです。
とりあえず MS-DOS Playr は諦めて修正版をアップしようかな。

> > ロング名なら、Rf- でも大文字小文字を区別しないといけませんね。バグです。
>
>  ここはちょっとわかりませんでした。
>  デフォルトなら環境依存でよいのではないですか?

上に書いたように、ロング名は、"Windows98ME” のように大文字小文字を使い分ける
のが普通でメリットでもあるので、 ここは勝手に変えたら駄目ですよね。

>  あ,あら(^^; 意外な展開……

いい加減で本当に申し訳ないです。

>  自分なりの解釈で版の詳細を追記しました。↓ 錯誤の有無をご確認ください。
>  http://mezala.la.coocan.jp/vz/history/verdetail.html#k07v6

えーとですね

> Rf:長いファイル名への対応を拡張し,編集モードで #75(#S:ファイルのセーブ) #82(ファイル名の変更) コマンドに対応.

RF はファイラーだけで、編集モードでは使えないという仕様だと思っていたのですが、今はあやふやになっています。(^^;
とりあえず、あやふや版をアップするかな。(゚゜)☆\(--#)バキッ

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


(10586) 10623Re^5: vzk07v6 Rf- バグ直ったかも  投稿者:konno   2023/03/13(月) 23:42
    10612 番 konno さんへのコメント

> RF はファイラーだけで、編集モードでは使えないという仕様だと思っていたのですが、今はあやふやになっています。(^^;
> とりあえず、あやふや版をアップするかな。(゚゜)☆\(--#)バキッ

とりあえず、あやふや版をアップするかな、と思っていたんですが
編集モードでスペース入りの LFNリネームに対応したら、今度は Tra_TAG.def が動かない。(>_<)
試行錯誤しているうちにぐちゃぐちゃになってわけわかになってしまいました。(;_;)

変更履歴をきちんとやっていなかったので、基本に帰って(何度目?)履歴ごとの違いを一覧にしました。
それで気が付いたのは、編集モードでスペース入りLFNリネームと Tra_TAG.def は、相容れない動作だったと。
なんてこった。(T_T)

しかたがないので、OPEN.asm #82 のルーチンにフラグを入れてやっと両立出来ました。(^^;
あとは、SL の動作が合わないのを、text.asm を入れ替えたら直ったので、これで完成か。
中身は継ぎはぎでわけわかですが、やれやれです。(^^;

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


(10586) 10624vzk07v6h UP  投稿者:konno   2023/03/15(水) 00:21
    10586 番 konno さんへのコメント    コメント数 3

vzk07v6h UPしました。

k07v6 (2023-02-28〜03-14)
 ・k07t5 までの機能は全部取り込んであると思います。
 ・Rf+ DOS窓SFNファイラーでも #R でロングファイル名変更(大文字小文字区別)
    バッファの制限により、パスの長さ約80文字以上ではSFNとなる。
 ・Sl ステータスライン表示オプション変更 0:time 1:free 2:LFN View open 3:sl1+sl2
  sl2 ならステータスラインでロング名表示 (Win9x、WinXP、MS-DOS Playrは sl2は指定しない)
 ・編集モード [ESC]P [ESC]S でロングファイル名変更(大文字小文字区別)
  ※ この機能は VTDOS と DOSVAXJ3(lfn_space=true) の場合に正常動作します。
 ・WinNT系のDOS窓コマンドラインの安定化 (検証中)
 ・[ESC]i ファイル挿入時のVZの不具合を修正してみた (検証中)
  VTDOS でのラップアラウンドエラーを回避しています。
  ※BL1024*3 だとファイル内容が壊れます。(全てのVZで起こるバグなのでこの設定は危険)
   詳細は掲示板を読んでください。不具合を見つけたら掲示板に報告願います

 ダウンロード  vzk07v6h.lzh ver1.60k07v6h (2023-03-14版 再アップ) new!
    ソース 2023-03-14 再アップ  K07V6Hs.lzh new!

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


(10586) 10625Re: vzk07v6h UP  投稿者:めざら   2023/03/15(水) 09:36
参照先:http://mezala.la.coocan.jp/
    10624 番 konno さんへのコメント    コメント数 1

お疲れ様です。早速試用したところ,下記のようになっています。
(まだ SL だけの確認だけですが…)

> ・Sl ステータスライン表示オプション変更 0:time 1:free 2:LFN View open 3:sl1+sl2

現状では,常に 2 が立っているように見えます。
また,0と1が上記と逆転しています。(これは本来望ましい仕様かとは思いますが)
2 のときは free+LFN で,3 のときは time+LFN なので1が(矛盾なく)立っています。

製品版は free なので,0 free +1 time +2 LFN表示 というのがしっくりきますが。
(高橋版は「作成者の趣味」で異論を受け付けず 0 time ですけどね)
      - No.10625 -    このTreeへ    コメント元:10624 へ [リストへもどる] soft


(10586) 10627Re^2: vzk07v6h UP  投稿者:konno   2023/03/15(水) 16:53
    10625 番 めざら さんへのコメント    コメント数 1

> 現状では,常に 2 が立っているように見えます。

え、そうですか? 私の環境では、SLが 0,1 では、ショート名でオープン表示されていると思うのですが。

> また,0と1が上記と逆転しています。(これは本来望ましい仕様かとは思いますが)
> 2 のときは free+LFN で,3 のときは time+LFN なので1が(矛盾なく)立っています。
> 製品版は free なので,0 free +1 time +2 LFN表示 というのがしっくりきますが。
> (高橋版は「作成者の趣味」で異論を受け付けず 0 time ですけどね)

げげ、0と1を高橋版と入れ替えていたみたいです。すっかり忘れていました。(^^;
では、オプションの意味を

・Sl ステータスライン表示オプション変更 0:free 1:time 2:LFN View open 3:sl1+sl2

こう変えてしまってもいいでしょうか。(^^;
でもオリジナルと高橋版と私家版で表示がコロコロ変わるのは混乱しそう。(^^;

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


(10586) 10629Re^3: vzk07v6h UP  投稿者:めざら   2023/03/16(木) 08:15
参照先:http://mezala.la.coocan.jp/
    10627 番 konno さんへのコメント    コメント数 1

あれ?…と思って開き直して初めてオプションの意味を理解しました。
オプションの値を変更して #] を実行したから書き換わるというものではないと。
ごめんなさい。えらいカン違いしていました。(^o^ゞ

> ・Sl ステータスライン表示オプション変更 0:free 1:time 2:LFN View open 3:sl1+sl2
> こう変えてしまってもいいでしょうか。(^^;

ご随意にお願いします。だって,SL は kVZ で追加されたオプションですから。
(こちらもカン違いしていましたが,高橋版は time 固定でしたね)
わたしとしては,感覚としてしっくりくるので大歓迎です。
konno さんが混乱しなければ良いのではないかと思います。
      - No.10629 -    このTreeへ    コメント元:10627 へ [リストへもどる] soft


(10586) 10630Re^4: vzk07v6h UP  投稿者:konno   2023/03/17(金) 01:23
    10629 番 めざら さんへのコメント

> あれ?…と思って開き直して初めてオプションの意味を理解しました。
> オプションの値を変更して #] を実行したから書き換わるというものではないと。

オープン時にロング名でオープンなので、そういうことです。

> > ・Sl ステータスライン表示オプション変更 0:free 1:time 2:LFN View open 3:sl1+sl2
> > こう変えてしまってもいいでしょうか。(^^;
>
> ご随意にお願いします。だって,SL は kVZ で追加されたオプションですから。
> (こちらもカン違いしていましたが,高橋版は time 固定でしたね)

げげげ、SLは自分が作ったオプションでしたか、私は2重に勘違いしていました! m(__)m

> わたしとしては,感覚としてしっくりくるので大歓迎です。
> konno さんが混乱しなければ良いのではないかと思います。

ではこのままということでよろしくです。(^^;

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


(10586) 10626Re: vzk07v6h UP  投稿者:shadow   2023/03/15(水) 15:48
    10624 番 konno さんへのコメント    コメント数 1

ご苦労様です。

VZK07V6H.COM の差分を当てて出来たのは62,870 vzibmj.com でした。
ソースから出来たのは 62,854 vzibmj.com でした。
3月4日から3月14日版へのアップデートで変更されてるのは次のファイルでした。
2023/03/05  20:59             6,402 char.asm
2023/03/13  22:54            63,753 filer.asm
2023/03/11  23:50             8,932 filer2.asm
2023/03/13  22:20            36,737 open.asm

> あとは、SL の動作が合わないのを、text.asm を入れ替えたら直ったので、これで完成か。
text.asmは変更されていると思ってたけど日付は違うけど内容は同じでした。

何かが違うようです。
      - No.10626 -    このTreeへ    コメント元:10624 へ [リストへもどる] pre


(10586) 10628Re^2: vzk07v6h ソース差し替え  投稿者:konno   2023/03/15(水) 17:16
    10626 番 shadow さんへのコメント    コメント数 1

> VZK07V6H.COM の差分を当てて出来たのは62,870 vzibmj.com でした。
> ソースから出来たのは 62,854 vzibmj.com でした。

ああ、またポカをやっていました。(>_<)
類似のフォルダがいくつもあるので古い方を使ってしまっていました。
申し訳ないです。m(__)m

2023/03/15  16:31            50,394 K07V6Hs.lzh
ソース 2023-03-15 再再アップ(^^;
しましたので差し替えてください。m(__)m


# やばい! SL2 を設定していないと上書きセーブでも大文字になってしまうのか。(>_<)
  うう、一度やったらもう止められなくなってしまう、、、中毒症状がぁ、、、

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


(10586) 10631Re^3: vzk07v6h ソース差し替え  投稿者:shadow   2023/03/17(金) 12:45
    10628 番 konno さんへのコメント    コメント数 1

> ソース 2023-03-15 再再アップ(^^;
> しましたので差し替えてください。m(__)m
有難うございます、頂きました。

> # やばい! SL2 を設定していないと上書きセーブでも大文字になってしまうのか。(>_<)
>   うう、一度やったらもう止められなくなってしまう、、、中毒症状がぁ、、、
私的には最初の版でもOKです。
      - No.10631 -    このTreeへ    コメント元:10628 へ [リストへもどる] soft


(10586) 10633Re^4: vzk07v6h ソース差し替え  投稿者:konno   2023/03/17(金) 18:12
    10631 番 shadow さんへのコメント

> 私的には最初の版でもOKです。

最初の版は、ロング名で表示は出来ていますが、[ESC]P でファイル名を変更すると
全部大文字になってしまうので使い物になりません。
今の版でも誤動作するマクロがあるかもしれませんので、気が付いたらご報告願います。

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


(10586) 10690vzk07v6h バグあり、使用中止してください  投稿者:konno   2023/03/22(水) 17:36
    10624 番 konno さんへのコメント    コメント数 1

vzk07v6h バグがありました。

EMSのみで BL1024 の時、MS-DOS Player や DOSVAXJ3 でも不具合が出ました。
他のVZでは、MS-DOS Player や DOSVAXJ3 では不具合が出ません。
vzk07v6h のバグでした。

公開を停止しますので、使用も中止してください。
確認不足でした。
ご迷惑をおかけして申し訳ありません。
      - No.10690 -    このTreeへ    コメント元:10624 へ [リストへもどる] soft


(10586) 10695Re: vzk07v6h バグあり、使用中止してください  投稿者:めざら   2023/03/24(金) 13:53
参照先:http://mezala.la.coocan.jp/
    10690 番 konno さんへのコメント    コメント数 1

vzk07v6h は既に公開停止とのことですが,追加情報です。

実は発生条件が今ひとつ確定できていなくて,安易に報告しにくいのですが,
ヒストリバッファが壊れるという現象が起きています。(07t02では発生しない)

■ひとつの再現例
自分の似非GREP(http://mezala.la.coocan.jp/vz/workshop/msearch.html#esegrep)で,
【R._ラジオ小劇場】あるいは【R..ラジオ小劇場】などと検索文字列を入力し実行すると
入力した検索文字列が【R-/ラジオ小劇場】のような変な化け方をします。
ps をそのまますり替えずに使っているのでバッファのアドレス等の問題ではありません。
ただし,マクロでなく手元で RX+ として #F 窓に上記の文字列を入力しても化けません。
トレースすると,化けるタイミングとしては,入力窓を閉じた直後に既に化けていました。
少し前の版 k07v6d でも,【R訃ラジオ小劇場】と似たような化け方をしました。

この現象は,vzk07t02 や vzt では発生しないので,07v* で新入りのバグのようです。

マクロでヒストリバッファを使ったときだけ化けるというのは初めての経験なので,
再現条件が特定のマクロだけという心許ない状況ですが,とにかくご報告まで。
撤回版としても,以降の版に引きずるとまずいので,ともかく報告に及びました。

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


(10586) 10696Re^2: vzk07v6h バグあり、使用中止してください  投稿者:konno   2023/03/24(金) 18:28
    10695 番 めざら さんへのコメント

> 実は発生条件が今ひとつ確定できていなくて,安易に報告しにくいのですが,
> ヒストリバッファが壊れるという現象が起きています。(07t02では発生しない)

う、そうなんですか、バグバグで申し訳ないです。m(__)m

> 自分の似非GREP(http://mezala.la.coocan.jp/vz/workshop/msearch.html#esegrep)で,
> 【R._ラジオ小劇場】あるいは【R..ラジオ小劇場】などと検索文字列を入力し実行すると
> 入力した検索文字列が【R-/ラジオ小劇場】のような変な化け方をします。
> ps をそのまますり替えずに使っているのでバッファのアドレス等の問題ではありません。
> ただし,マクロでなく手元で RX+ として #F 窓に上記の文字列を入力しても化けません。
> トレースすると,化けるタイミングとしては,入力窓を閉じた直後に既に化けていました。
> 少し前の版 k07v6d でも,【R訃ラジオ小劇場】と似たような化け方をしました。

これは詳細ですね、非常に参考になります。ありがたいです。

> この現象は,vzk07t02 や vzt では発生しないので,07v* で新入りのバグのようです。
> マクロでヒストリバッファを使ったときだけ化けるというのは初めての経験なので,
> 再現条件が特定のマクロだけという心許ない状況ですが,とにかくご報告まで。
> 撤回版としても,以降の版に引きずるとまずいので,ともかく報告に及びました。

ご指摘が無ければ気が付かずにずっとバグ入りのままだったと思います。
教えてくださり、ありがとうございました。

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


(10586) 10637Re: vzk07v6 UPしました  投稿者:めざら   2023/03/17(金) 22:05
参照先:http://mezala.la.coocan.jp/
    10586 番 konno さんへのコメント    コメント数 2

VTDOS 環境ですが,300KB ほどの比較的大きなファイルをちょうど今編集していて,
clppst.exe+clppst.def による [ESC]I 様態(*)の作業を行って気が付きましたが,
ラップアラウンドエラーが出る状況になっています。テンポラリファイルエラーも
出ました。現在の版の k07v6h と 前の版の k07v6d で発生を確認しました。

ファイルは 300KB 弱ですが,2,100行強,長い行もありますが,割に普通です。

k07t5 に差し替えると,上記のラップアラウンドエラーは発生しなくなりました。
現在の作業はこの版で乗り切ろうと思います。
k07t5 でもテンポラリファイルエラーが出やすいサイズなので,分割作業かしら。

(*)clppst.def は巨大ブロックコピー機能を使っています。

お手元でのテストが必要なら,当該ファイルのコピーをお渡しできます。

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


(10586) 10640Re^2: vzk07v6 UPしました  投稿者:文太   2023/03/18(土) 01:38
    10637 番 めざら さんへのコメント

めざらさん

>出ました。現在の版の k07v6h と 前の版の k07v6d で発生を確認しました。
>ファイルは 300KB 弱ですが,2,100行強,長い行もありますが,割に普通です。
>k07t5 に差し替えると,上記のラップアラウンドエラーは発生しなくなりました。

 ありがとうございます!
 違う話だと思うけど、僕も、それに近いことに悩まされています。


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


(10586) 10642Re^2: vzk07v6 のバグ?  投稿者:konno   2023/03/18(土) 02:09
    10637 番 めざら さんへのコメント    コメント数 1

> VTDOS 環境ですが,300KB ほどの比較的大きなファイルをちょうど今編集していて,
> clppst.exe+clppst.def による [ESC]I 様態(*)の作業を行って気が付きましたが,
> ラップアラウンドエラーが出る状況になっています。テンポラリファイルエラーも
> 出ました。現在の版の k07v6h と 前の版の k07v6d で発生を確認しました。
> ファイルは 300KB 弱ですが,2,100行強,長い行もありますが,割に普通です。

出ましたか、これは再現して調べたいです。

> k07t5 に差し替えると,上記のラップアラウンドエラーは発生しなくなりました。

げげ、今の版は暫定版なので仕方がないですが、k07t5 って結構前のだっけ?

> (*)clppst.def は巨大ブロックコピー機能を使っています。
> お手元でのテストが必要なら,当該ファイルのコピーをお渡しできます。

是非お願いします。メールででも。m(__)m
バグの絞り込みが出来るかもしれません。
再現手順も詳しくお願いします。

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


(10586) 10649VTDOSのEMS環境は避けた方がいいです。  投稿者:konno   2023/03/18(土) 16:24
    10642 番 konno さんへのコメント    コメント数 3

めざらさんからテストデータをメールでいただきました。
ありがとうございます。

> > VTDOS 環境ですが,300KB ほどの比較的大きなファイルをちょうど今編集していて,
> > clppst.exe+clppst.def による [ESC]I 様態(*)の作業を行って気が付きましたが,
> > ラップアラウンドエラーが出る状況になっています。テンポラリファイルエラーも
> > 出ました。現在の版の k07v6h と 前の版の k07v6d で発生を確認しました。

VTDOSのEMS環境ではデータが壊れるのを確認しました。他のVZも同様でした。
ラップアラウンドエラーやテンポラリファイルエラーは出ていません。
VTDOS.CFG の設定で
SCASB_MODE=1
にしているのも影響しているかもしれません。

試しに EMS環境で
SCASB_MODE=0
にしてみましたがラップアラウンドエラーやテンポラリファイルエラーは出ませんでした。
ファイル内容は壊れます。

> > k07t5 に差し替えると,上記のラップアラウンドエラーは発生しなくなりました。

これは環境による差異と思われます。
VTDOSで EMSを使わない XMS環境ではデータが正常に処理出来ました。他のVZも同様です。
VTDOSで EMSも XMSも使わない環境でもデータが正常に処理出来ました。他のVZも同様。

やはり、VTDOSには、EMSのバグがあるように思われます。
めざらさんは、EMSメインの設定なのではないでしょうか。

VTDOS には、メモリ拡張オプションがいくつかありますが、これも動作不良の原因の可能性があります。
私は何度か不具合を経験して、拡張オプションを全て止めました。
作者様も使っていないそうです。(^^;

私の今のVZ環境をだしておきます。

---------- option.lst --------------------- 2023/03/18 (Sat) 13:56 --------
 DOSV  VZt  VZk  z+  St-  vw+  zk-
 
 Bt64     Bf5632   Bo32768  EM128    XM16384  Bm380    Ba4      Hs256
 Hf256    Hx128    Ha92     Hw128    Bl8192   Bc1024   Bu256    Bv256
 
 SW2   TC12  WD0   We134 PG0   RS3   Ta8   Tb4   Ci4   Co2   WL1
 LC35  VM0   CA52  Sr39  Qt1   Qc20  Qw0   RM0
 
 Dl-  Dc+  Dt+  De+  Ds+  Db-  Dn-  Du+  Df+  Dp-  Dh+  Dg+  Dr+  Dj+  Dv+
  
 Ei+  Es+  Ez-  Eb+  Eu-  Et+  Eh-  Ew-  Ec+  Ex-  En-  Ev+  Ek-  Ea-  RO-
 Ej-  Eo-  El-
 
 RX-  ZH-  Sx+  Se+  Sd+  Sk-  Sy-  YN-  Sn-  Sq-  FP+  FR+  FK+  FQ+  Sz-
 
 Sc-  Nd+  Vb+  Sv-  Tv+  YM-  CH-  Hp-  Hp-  lf-  Is-  Da+  Nf+
 Ce0      ml + mc*  Ys$09  Yo$0E  Yr$0B
---------- End of option.lst ----------------------------------------------


他でも書いていますが、VTDOS+VZでは
XM1
EM12
などとするのが安全です。
EM0 でもメモリを食うものの、VZのスワップも無くなるのでより安全かもしれません。

めざらさんのデータを使って、10#さんに VTDOSのEMSがVZで不具合が出る件を報告してもいいですか。
さすがにここまで不具合事例が出ては、10#さんに対応をお願いした方がいいと考えます。
対応してくれるかどうかはわかりませんが。

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


(10586) 10652Re: VTDOSのEMS環境は避けた方がいいです。  投稿者:konno   2023/03/18(土) 21:30
    10649 番 konno さんへのコメント    コメント数 1

> VTDOS には、メモリ拡張オプションがいくつかありますが、これも動作不良の原因の可能性があります。
> 私は何度か不具合を経験して、拡張オプションを全て止めました。
> 作者様も使っていないそうです。(^^;

過去ログを見たら、これは2014年ごろで、2018年ごろの #8006 の10#さんの発言

> 最近はXMSもEMSもフルでVTDOSもTPAEXT=1で使ってます。

XMSもEMSもフルで指定した場合、VZは XMS を優先に使用します。XMSを使い切るまで EMSは使われません。
この環境なら安定するはずですね。(^^;
メモリ拡張オプションの不具合も、もしかしたら EMSが原因だったりして。

ということで、今の私のVTDOS.CFG は
TPAEXT=1
TPALOW=1
を復活させました。VZの起動バッチには
$XSET vzsym=NOQ  VTDOS
を仕込み、vz.def には

#if VTDOS	; VTDOS
XM1
EM0
SW1
#nedif

こうしてEMSを使わず XMS だけにしてコード領域のスワップを止めました。
それでも VMAP では

09CB <--    1  222080  vzibmj 1.60v -z /vz.def    00 1B 21 29 3F
4004-E7FE   1  688032  <free>

これだけメモリが空いています。余裕ですね。

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


(10586) 10665Re^2: VTDOSのEMS環境は避けた方がいいです。  投稿者:文太   2023/03/19(日) 15:56
    10652 番 konno さんへのコメント    コメント数 1

konnoさん

 とりあえず、これでしばらく様子をみます。

#if VT		;VTDOS
XM1
EM0
#endif		;#10652 by konno, #nedif になってますよ。

 主たる作業場を、やはり WinME に戻すことにもしました。


>vz -z
XMSを最大 16384 KB使用します


173E <--    1  223520  vz 1.60t -z                00 1B 21 29 3F
4DD1-9FFE   1  336592  <free>	;少ねえぞ。

----- EMS ver4.0 (frame: C000h) -----       ----- XMS ver2.00 -----
handle pages   size  name                   HMA used: 63 KB by DOS
------ ----- ------  --------               EMB free: 32767 KB
     1     2    32k  for Vwx!	;これも本当は少し気になるのだけど。

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


(10586) 10669Re^3: VTDOSのEMS環境は避けた方がいいです。  投稿者:konno   2023/03/20(月) 00:41
    10665 番 文太 さんへのコメント    コメント数 1

> #endif		;#10652 by konno, #nedif になってますよ。

げげ、何処かで打ち間違えて、そのままコピーして使っていました。(>_<)
直そうとしたら、"#eedif" にしちゃってるし。(^^;
そういえば、わなまさんは "#ifend" とやっていたような。
5文字なら通るみたいに言っていたような気がします。(^^;

> 173E <--    1  223520  vz 1.60t -z                00 1B 21 29 3F
> 4DD1-9FFE   1  336592  <free>	;少ねえぞ。

10#さんも
> > 最近はXMSもEMSもフルでVTDOSもTPAEXT=1で使ってます。
こう言っているので、TPAEXT=1 を設定すれば良いと思います。

>      1     2    32k  for Vwx!	;これも本当は少し気になるのだけど。

これも TPAEXT=1 を設定すれば余裕ですよ。(^_^)

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


(10586) 10671Re^4: VTDOSのEMS環境は避けた方がいいです。  投稿者:文太   2023/03/20(月) 01:52
    10669 番 konno さんへのコメント    コメント数 2

konnoさん

 色々とありがとうございます。

>そういえば、わなまさんは "#ifend" とやっていたような。
>5文字なら通るみたいに言っていたような気がします。(^^;
 僕の記憶では、cmos版では文字数、高橋版以降でちゃんと文字チェック
だったと思います。ソースでご確認ください。

>これも TPAEXT=1 を設定すれば余裕ですよ。(^_^)
 うーん、vtdos.cfgですね、設定してみました。それを止めたうっすらと
した記憶が、、、。
 もう、この場所は、あくまで実験なのだ、何が起こるか分からないのだ、という
覚悟です。

 思ったのですが、10#さんは、やっぱりマクロを使わない人だったのだと
思う。だから、「そんな使い方、あるわけないだろう」というvtdosの設計に
なっている、、、。
 ま、EMSが主題なわけですが。ただ、テンポラリーファイルが絡んじゃう
からなぁ。
 16MBまで行けるVzでも、1MBのテキストもきっと編集したことないの
でしょう。プログラマなら、ふつう。常識的な使い方。

 で、10#さんは、そんなVzのどこに魅力を感じたのだろう?
 macro.asm, expr.asm が、Vzの本丸だと、現在、思い込んでいます。
 そうでなければ、mifesでも秀丸でもいいんじゃないの?
 そもそもDOSにこだわる必要があるの???

 R・ダンカンの名著とされる「_Advanced MS-DOS Programming_のお世話になった」
と言ってたから、DOSの深みにはまっちゃったのかな? 若気のいたり。
Win98時代。NT/2000 の姿がちらりちらりな時代。


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


(10586) 10675TPAEXT=1  投稿者:文太   2023/03/20(月) 12:16
    10671 番 文太 さんへのコメント

--- vtdos.cfg ---
DISKFREE=K
USECMD=1
UMB=1
SCASB_MODE=1
TPAEXT=1
-----------------

173E <--    1  223520  vz 1.60t -z                00 1B 21 29 3F
4DD1-E7FE   1  631504  <free>

----- EMS ver4.0 (frame: E800h) -----       ----- XMS ver2.00 -----
handle pages   size  name                   HMA used: 63 KB by DOS
------ ----- ------  --------               EMB free: 32767 KB
     1     2    32k  for Vwx!
  free  2046 32736k

 こんな感じになりました。m(__)m
 怖いのは怖いけど。

 皆で同じ環境をつくって調査する、ということなら、データ等お送り
ください。clppest.exe(def) の話は、まったくついて行けておりませんが。


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


(10586) 10689inst.asm  投稿者:文太   2023/03/22(水) 01:29
    10671 番 文太 さんへのコメント    コメント数 1


>>そういえば、わなまさんは "#ifend" とやっていたような。"
>>5文字なら通るみたいに言っていたような気がします。(^^;"
> 僕の記憶では、cmos版では文字数、高橋版以降でちゃんと文字チェック
>だったと思います。ソースでご確認ください。

 高橋版では、「ブロック IF 文」のネストができます。
 cmos版では、テーブルを置いて、確かに文字数で分岐させています。
 ちょんと読みきれたわけではありませんが、inst.asm の両者を読み比べると
「高橋さん、やっぱ、読みきってるわ」と思うと思います。全面書き換えだった。
 あそこにデータ入れて処理した c.mosさんにも、感じいったけど。すごい発想。


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


(10586) 10692Re: inst.asm  投稿者:konno   2023/03/22(水) 22:32
    10689 番 文太 さんへのコメント

>  高橋版では、「ブロック IF 文」のネストができます。
>  cmos版では、テーブルを置いて、確かに文字数で分岐させています。
>  ちょんと読みきれたわけではありませんが、inst.asm の両者を読み比べると
> 「高橋さん、やっぱ、読みきってるわ」と思うと思います。全面書き換えだった。
>  あそこにデータ入れて処理した c.mosさんにも、感じいったけど。すごい発想。

文太さん、ソースで確認してくれたのですね、ありがとうございます。
私はこれからふかい海に潜ってソナーで敵の蟲を探しに行きます。
無事に浮上出来るかわかりません。(^^;

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


(10586) 10653Re: VTDOSのEMS環境は避けた方がいいです。  投稿者:めざら   2023/03/18(土) 21:34
参照先:http://mezala.la.coocan.jp/
    10649 番 konno さんへのコメント    コメント数 1

EMS 関連ですかぁ……
メモリだと対処のしようがないですもんねぇ。

手元で,そのあたりの設定をいじって試してみたところ,
-EM0 -XM1 を指定した状態で割に安定しているように見えます。
ありがとうございます。

なお,あのデータは昨日既に公開済にしているものなので,問題ありません。
オープンドキュメントって個人情報入っているのかな?
まぁ,レジストしてるわけだし…
      - No.10653 -    このTreeへ    コメント元:10649 へ [リストへもどる] soft


(10586) 10654Re^2: VTDOSのEMS環境は避けた方がいいです。  投稿者:konno   2023/03/18(土) 23:41
    10653 番 めざら さんへのコメント    コメント数 1

> 手元で,そのあたりの設定をいじって試してみたところ,
> -EM0 -XM1 を指定した状態で割に安定しているように見えます。

XMSで問題なく動いているならやっぱり EMS 絡みだったのでしょうね。

私はODSデータを LibreOffice で読んで、全選択でコピーして ClpPst.def で新規ファイルに貼り付けました。
それを、TSV データとテキスト比較マクロで比較して完全一致を確認しました。
もう一つ、新規ファイルを開いて、[ESC]I で TSVデータを挿入して、元のデータと比較して完全一致を確認しました。

EMS環境では、複数のVZで確認し、全てデータが不一致になりました。
VZのコード領域っぽい文字列が混ざるので、EMSのスワップ自体が危険と感じました。

ずっと使ってきて今頃こういう事例が出てくるのは、ブロック移動関連のルーチンが怪しいのかも。
ClpPst.def では EK+ のようなので、EK では無いのか、[ESC]I との共通点は #B #y #i あたり?

> なお,あのデータは昨日既に公開済にしているものなので,問題ありません。

ありがとうございます。公開データなら問題なさそうですね。
では 10#さんにメールしてみますね。

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


(10586) 10670VTDOSのEMS環境は更なる検証が必要  投稿者:konno   2023/03/20(月) 01:39
    10654 番 konno さんへのコメント    コメント数 2

> ありがとうございます。公開データなら問題なさそうですね。
> では 10#さんにメールしてみますね。

10#さんにメールして、お返事をもらえました。
確認してもらったのですが、予想外の結果でした。

> まず、僕の環境でXMSのみ、EMSのみの環境でテストしてみましたが、
> EMSでは正常に貼り付ける事が出来ました。
> XMSの場合ではマクロが正常に終了せず、CLPPST.TMPがVZに残った
> 状態で中断しました。
> 続いてclppst.defによる貼り付けでは無く、メモ帳に貼り付けて保存した
> ファイルを[ESC]Iで挿入した場合正常に保存されました。

私のテストでも、EMS環境で、BT32 などの場合は正常に処理されたようでした。
めざらさんのデータだけでは検証には不十分なようです。

としきさん
検証のためには、としきさんの生ログデータが最適だと思います。
10#さんにメールで送ってもかまわないでしょうか。

検証用のスレッドを立てたいと思います。

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


(10586) 10672Re: VTDOSのEMS環境は更なる検証が必要  投稿者:としき   2023/03/20(月) 01:56
参照先:http://toshiki.la.coocan.jp/
    10670 番 konno さんへのコメント    コメント数 1

> 検証のためには、としきさんの生ログデータが最適だと思います。
> 10#さんにメールで送ってもかまわないでしょうか。

かまいません。
機微な部分は改竄済みですし、それ以外は公開されている情報ですから。

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


(10586) 10676Re^2: VTDOSのEMS環境は更なる検証が必要  投稿者:konno   2023/03/20(月) 13:42
    10672 番 としき さんへのコメント

> > 検証のためには、としきさんの生ログデータが最適だと思います。
> > 10#さんにメールで送ってもかまわないでしょうか。
> かまいません。
> 機微な部分は改竄済みですし、それ以外は公開されている情報ですから。

ありがとうございます。
これから再現手順とか色々纏めてメールで送ります。
昨日は気力が尽きてしまったもので。(^^;

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


(10586) 10674Re: VTDOSのEMS環境は更なる検証が必要  投稿者:めざら   2023/03/20(月) 10:35
参照先:http://mezala.la.coocan.jp/
    10670 番 konno さんへのコメント    コメント数 1

予想外ですね……まるで逆(EMS ・ XMS)とは思いもよりませんでした。
とくに clppst.def 異常終了で clppst.tmp が残ったままという現象は,
わたしのところでは EM1・XM0 のときに発生します。(ここ正反対)

環境って,そんなに違うのですかね。TPAEXT=1 は一貫して設定していますし,
BT は(かつての LX 以外は)昔からずっと 64(最大)でした。

ふつうに使えるかどうかわかりませんが,
個々の環境.DEF をインクルードして,環境の共有をすることを提案します。

方法としては,(非常駐バッチで起動することが前提になってしまいますが)
個々の環境の値を - あじゃ - さんの opt_lst.def で出力したものを
(tVZ dVZ kVZ で追加されたオプションを追加する必要があるかも)
マクロファイルに加工して保存したファイルを各人が準備・共有。
バッチを一度終了して,VZ +m.def -bm20000 のようにして起動してテスト。
(bm の空きが 1000 くらいあれば bm の指定は不要かと思います)

いかがでしょう。

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


(10586) 10677Re^2: VTDOSのEMS環境は更なる検証が必要  投稿者:konno   2023/03/20(月) 14:41
    10674 番 めざら さんへのコメント    コメント数 1

> 予想外ですね……まるで逆(EMS ・ XMS)とは思いもよりませんでした。
> とくに clppst.def 異常終了で clppst.tmp が残ったままという現象は,
> わたしのところでは EM1・XM0 のときに発生します。(ここ正反対)

私もビックリしました。
やはり再現条件は揃えないと駄目なんですね。
めざらさんのデータでは
VZT 高橋版で BT64 BL8192 SW0 で常用DEFで ClpPst.def 方式で実行したら、正常でした。
同じ条件で、[ESC]I マクロでは内容破壊、サイズが小さくなりました。
BT32 にして、[ESC]I マクロでは正常に処理出来ました。

これでは特定は難しいですね。
としきさんのデータは今まで色々検証してきているので、プロが見れば特定できる可能性があると思います。

> ふつうに使えるかどうかわかりませんが,
> 個々の環境.DEF をインクルードして,環境の共有をすることを提案します。

これはいいですね。
とりあえずは、オリジナルのVZ.DEFを、DS+ と変更し、VZO.DEF として送ります。
DS+ でファイルサイズが表示されるので、比較するまでもなくテキスト破壊がわかります。
オリジナルは、BT64 BL2048 SW3 で、[ESC]I マクロでは内容破壊、サイズが小さくなります。

BL128 〜 2048 の範囲では、VTDOS+EMS環境だけが異常になります。
SW0 BT32 でも異常になりました。

VZ /vzo  で起動します。(VZは各種VZを指定可)

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


(10586) 10678Re^3: VTDOSのEMS環境は更なる検証が必要  投稿者:めざら   2023/03/20(月) 22:34
参照先:http://mezala.la.coocan.jp/
    10677 番 konno さんへのコメント    コメント数 1

> VZ /vzo  で起動します。(VZは各種VZを指定可)

それでもよいのですけれど,わたしが言いたかったのは,

= m
* O
Bt64
Bf64
Bo32
EM0
XM1
SW3
RM0
;; 以下,省略。
*

みたいなファイルをそれぞれの環境で作って共有すれば,
どこに問題があるのかを解明するヒントになるんじゃないかなと。

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


(10586) 10680Re^4: VTDOSのEMS環境は更なる検証が必要  投稿者:konno   2023/03/21(火) 01:22
    10678 番 めざら さんへのコメント    コメント数 1

> みたいなファイルをそれぞれの環境で作って共有すれば,
> どこに問題があるのかを解明するヒントになるんじゃないかなと。

なるほど、オプションリストのメモリ関連だけを DEF 形式にするようなものですね。
各自の常用環境で問題が出れば、直ぐにオプションがわかって試せますね。
そういう情報はドシドシあげてほしいですね。

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


(10586) 10685Re^5: VTDOSのEMS環境は更なる検証が必要  投稿者:めざら   2023/03/21(火) 13:51
参照先:http://mezala.la.coocan.jp/
    10680 番 konno さんへのコメント    コメント数 1

> なるほど、オプションリストのメモリ関連だけを DEF 形式にするようなものですね。

セクション * Option にあるもの全部です。メモリ関連だけではありません。
      - No.10685 -    このTreeへ    コメント元:10680 へ [リストへもどる] soft


(10586) 10686Re^6: VTDOSのEMS環境は更なる検証が必要  投稿者:konno   2023/03/21(火) 21:23
    10685 番 めざら さんへのコメント

> > なるほど、オプションリストのメモリ関連だけを DEF 形式にするようなものですね。
> セクション * Option にあるもの全部です。メモリ関連だけではありません。

げげ、そうなると何ページかに渡ることになりますね。
大きなデータは、テスト掲示板のほうにお願いします。
#test75 のように、#test に発言番号を続けるとリンクできますので。

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


(10586) 10655Re: VTDOSのEMS環境は避けた方がいいです。  投稿者:文太   2023/03/18(土) 23:43
    10649 番 konno さんへのコメント    コメント数 2

konnoさん、あるいは、めざらさん

 ありがとうございます。どうもそれっぽいぞ、という気がしています。

 で、そのデータ(ファイル)の壊れ方というのを、簡単に説明して
いただけませんか。

 僕のところで、4,5回起こったのは、vtdos窓が落ちる、というのでは
なく、まさしく「ファイルが壊れる」だったのです。
 こちらでの壊れ方は、ファイルの途中が抜ける、あらぬところのファイルが
変な箇所に挿入される、ファイル末が消失する。こんな感じなのですが。
 文字化けとかバイナリを見てるみたいな気持ちの悪い画面はない。

 僕のところは、比較的大きなファイルです。

masttasm.txt 1,897,832 2023-03-17 16:35

 たとえば、こんなの。1MB以上かその近辺ぐらいのサイズです。

 で、上のようなファイルで、ちまちま文字化けその他を退治してるときに
ファイルに壊れられると、「ほんと嫌になっちゃう」なので、それで例の

c:\0etxt\
c:\0etxt2\

 とバックアップフォルダを作ることにしていたのです。

 違う話でしょうかね?
 EMSかぁ。ありがたいんだけどなぁ。ないとほんと困るのだけど。

 じつは、僕はこれが vtdos 環境のみで起こるのかどうか、よく分かりません
でした。WinMEで起こったことがない、と思う自信はなかった。
 他のミスオペレーションによるファイル破壊の可能性もありましたから。可能性
というより、実際にそれはあったと思う。

 ただ思い出していたのは、niftyの過去ログを壮絶に整理していたとき(切った
貼ったの連続。nifsort もビシバシ=スワップありコマンドライン。awkで1記事
1ファイルにするとかもした=1200個ファイルのアウトプット)、こんなこと、
起こらなかったよ、ということ。

 とりあえず、vtdos環境では、konnoさん設定でいってみます。
 やだよ、ファイル壊れるの。



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


(10586) 10666ファイル中身の破損  投稿者:文太   2023/03/19(日) 16:00
    10655 番 文太 さんへのコメント    コメント数 1

 なぜそんなファイルの壊れ方に気づけるのか?
 質問にお答えします。

 編集処理をしてファイルサイズがどかっと変化したら、まず気づきます
(そのためのバックアップ)。

 もっと細かい場合を、現在作成中の_MASTERING TURBO ASSMBLER_ のetext 
をサンプルに具体的に説明します。etextは、以下のような体裁になっています。


=============== SAMPLE STARTS =================

---------------------	★タイトルページ

     MASTERING TURBO ASSMBLER, Second Edition
     by Tom Swan, SAMS PUBLISHING
     Copyright 1995 by Tom Swan

---------------------	★目次

Contents		;目次は大事です。全体が掴めます。Windows Program-
			;ming も OOP も、ほぼ必要ありませんから。

Part I Programming with Assembly Language
1  Introduction
Learning Assembly Language				4	;ページ数
Advantages of Assembly Language				7	;いちおう重要

<skip>

Index							870

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

---------------------[End of Page 3]--------------------	★本文始まり
4							;オリジナル・ページ
							;番号が上にある場合
Learning Assembly Language 				;もある。

I remember when I discovered assembly language. The nearest I've come to
experiencing the same elation was the day I first balanced a two-wheeler,
wiggling my way down our street, my father's thumb no longer snagging my
belt, my fear of falling melting like bee's wax in the sun.
<skip>

---------------------[End of Page 4]--------------------	★本文続く

<skip, skip, skip>

869								★890pages
---------------------[End of Page 869]---------------------	★の本
								★索引
Index

Symbols
, (commas), macro parameters, 303 				;キーワードと
! (exclamation point), macro string characters, 307 		;ページ数
% (percent sign), expression evaluate operator, 306 		;いちおう重要
%NOLIST command, 331 

870
---------------------[End of Page 870]---------------------	★索引続く

<Index, skip, skip, skip>

Z
zero (string instructions), 138

890
---------------------[End of Page 890]---------------------	★書籍終わり

=============== SAMPLE ENDS =================


(0)
etextの全体像(構造的骨格)は上のとおり。

(1)
890
---------------------[End of Page 890]---------------------
 は、OCRソフトが自動でつけるページフッタ。
 上の行の890が、オリジナル書籍に入っていたページ番号。
 これは完成形。ページ番号は化けたり、スペースが入っていたり色々ある。
 ページフッタは、中身以外は機械のように正確に付く。

(2)
---------------------[End of Page 3]--------------------	★本文始まり
4
 のように、オリジナル・ページ番号がページの上、前ページフッタの次行に
置かれていることもある。

(3)
 この [End of Page X] は、最初、現実を反映していないのが普通。Prefaceとかで、
xxiii のようなローマ数字が使われるから。OCRは、pdfの1ページから番号を振る
 このズレは、手作業あるいは、order.def by mikome で直します。
 現在位置がすぐさま確認できないと、オリジナルpdfとの照合が困難になるから。
 この照合は、いっぱい必要です。プログラム・リストや表、図は、そもそも
データ的に崩れているのが普通。
 目次、索引のページ数データ(ふつう健全)が「いちおう重要」なのも、この
ページフッタと整合させたいから。キーワードですぐ飛べない場合もある。

(4)
 (3)の作業が正確に終了したら、「890」の行は削除。要らない情報は、できる
かぎり掃除して除去する。もちろん、「890」と「End of Page 890」が正確に一致
していることを確認してから。

(5)
 しかし編集作業中、いろいろ起こる。だから、>cgrep "End of Page" through filter.def
は、頻繁に行う。>cgrep -A1 -B1 "End of Page" (ページフッタ前後行も) も頻繁。

 とうぜん
---------------------[End of Page 1]--------------------
---------------------[End of Page 2]--------------------
---------------------[End of Page 3]--------------------
 なんてのが、永遠と続く結果が得られる。
                 ^ ここにカーソルをおいて、numchk.defもする。

(6)ガーン!

 Page 123 - Page 134 が消失してる!
 Page 231 - Page 239 が Page 155 の前に来てる!
 作業前は、健全だったのに!


 なんで素直にpdfで書籍を書籍として読み、本質であるアセンブラのお勉強に
励まないのですか? pdfは、WinMEでさえ読みづらく、DOSではまったく
読めないからです。検索もジャンプもうまくいかない場合が多い。
 あと、あと、あと、テキスト・フェチだからです。機械を使っている
=使われているというのが、快感だから。


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


(10586) 10688Re: ファイル中身の破損  投稿者:文太   2023/03/22(水) 01:14
    10666 番 文太 さんへのコメント    コメント数 2

 別にとりわけ意図も希望もなく、説明を分かりやすく書き直しておきます。
 1MBのファイルがある。1000本のページフッタが中に入っている。
「ページ番号つき」フッタには、Page 1 から Page 1000 まで番号がつく。
 だいたい1KB ごとに番号のついた線が入っているということ。

 そして、

《1MB file》
------------------------
------------------------
AAA
------------------------
------------------------
BBB
------------------------
------------------------
CCC
------------------------
ZZZ
------------------------

↓

《1MB file》
------------------------
------------------------
AAA
------------------------
CCC				;移動
------------------------
------------------------
BBB
------------------------
------------------------
				;消失


 vtdos環境で、上のようなことが起こったらしい。起こったのは事実ですが。
 EMS を使い、スワップをさせないVz設定で起こった。
 「Vz内部のラップアラウンド?」と書いたのは、行番号がワード値を
超えていたから filter.defがバグった? と思ったから。超えていませんでした。
 WinMEで、同じような処理をかなりやりましたが、何も起こらないみたい。
 気のせいかもしれません。−−−20回はバックアップファイルとの照合を
しました。

 それで、めざらさんのところで発現したのと(clppest.exe & clppest.defがらみ)
と同じ原因? と思ったのでした。
 たぶん原因は違うだろうと考えています。残念ながら、何かのオペレーション・
ミスだったのだろうと考えています。ただ、vtdos環境では、この作業はもう
しません。(嫌われそうですが)WinMEだと、VzとDOSが速いんです。

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


(10586) 10691Re^2: スワップとEMSとBT  投稿者:konno   2023/03/22(水) 22:26
    10688 番 文太 さんへのコメント

>  vtdos環境で、上のようなことが起こったらしい。起こったのは事実ですが。
>  EMS を使い、スワップをさせないVz設定で起こった。

VZのスワップ機能ってどういう動作だっけ? 私はキチンと把握していませんでした。
VZ1.6のマニュアルP158を見ると
コマンドラインでコマンド実行時にメモリを空けるためにVZの使用メモリの一部をEMSなどに退避させることみたいですね。

EMS環境では、SW0 でもEMSはテキストのテンポラリファイルとして使用されます。
EMS のWikipediaによると

>   "EMSマネージャ"を通じてメモリ空間の取得・開放、バンク切り換え等を行う。
>   16KBytes単位でバンク切替を行い、これをページと呼ぶ。
>   8086でアクセス可能な1Mbytesの範囲内に"ページフレーム"区画を設ける。
>   ページフレームは、ほとんどの場合4ページ = 64Kバイト(バージョン4.0)の連続した領域。
>   EMSマネージャは、要求のあったページをページフレームに出現させる。
>   そのため、各種操作は隠蔽され、ユーザは気にする必要が無い。
>   対応するメモリ総量は32Mバイト(2048ページ)まで。
>   主な版として3.2, Enhanced EMS 3.2, 4.0がある。4.0では特にWindows 2.x向けの拡張を行った。

つまり、64k を超えるテキストは、EMSメモリに展開され、16k〜64kの物理メモリとの間で常にメモリ転送されていると。
VZの BT は、16〜64 まででしたね、私はこれで、BT が物理メモリの窓の大きさなのだということに気が付きました。(^^;
例のバグバグVZは、BT32以下にすると駄目みたいです、いつも BT64 で使っていたので気が付きませんでした。
このVZは蟲探しの良い教材になりそうですね。(゚゜)☆\(--#)バキッ

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


(10586) 10693Re^2: ファイル中身の破損  投稿者:文太   2023/03/23(木) 00:37
    10688 番 文太 さんへのコメント

いちおうkonnoさん宛なのですが、ここに補足説明。

>vtdos環境で、上のようなことが起こったらしい。起こったのは事実ですが。
 ったく、訳が分からない書き方をするな。
 うーん、今振り返ってみても、本当にVTDOSが原因なのかは分かりません。
 WinMEでは起こっていないと思うけど。
 僕はここ1〜2か月、五月雨にしかVzでテキスト編集とかしてませんでした。
 入力主体(論文を書く、翻訳をする、プログラムを書く)だとガシガシ、
コマンドを連発で繰り出したりしませんよね(主にWinME 真剣環境)。ちまちま
キー入力。
 連発はetext作成なんて場面での「編集」のときです。これがね、記憶曖昧
なんだなぁ。

 でも、だいたいその期間に(疲れてるとき)、Win7=VTDOSで、この現象に
気がついた。
 VTDOSが原因か分からないけど、VTDOS環境で起きた可能性は高いです。
 対象が、でかいファイルであること。

> EMS を使い、スワップをさせないVz設定で起こった。
 これはママです。
 ただし、ビッグニュース! これはVzk 最新版でなく、k07t01という相当古い
版で起こりました。ですから、今回のめざらさん発見のパターンとは原因が違う
ことが想像されています(注)。kVz の版を変えても、きっと起こる。原因が何
にしろ。僕の場合は。

> 「Vz内部のラップアラウンド?」と書いたのは、行番号がワード値を
>超えていたから filter.defがバグった? と思ったから。超えていませんでした。

 これワケワカだ、という人がいるかもしれないので。
 ふつうのfilter.defの使い方は、filterです >filter <a.txt >b.txt。
 ただし、ブロックしてシフト起動すると元ファイルの該当部分を直接書き換えます。
こういうことができるマクロです。で、その部分に引っかかったのかなぁ、と少し
思った。これ、ガシガシやってますから。
 というわけで、まだ、このラインを(vz.com or filter.defが原因)、捨てては
いません。

 とにかく、うーん、ゆっくり行きましょう!
 失敗しなければ成功しない。失敗しつづける覚悟。老人に必要なのはこれです!
いつか勝利の雄たけびをあげるために。大谷のように、ダルビッシュのように。
(彼らは老人でないけど)誰にむかって言ってんだ。自らを鼓舞しております。
 cmosさんだって、泣きたいときあったはずですよ。

 しかし、95年あたりのYushiさんデビューの頃、テキスト構造体が明らかに
されていた頃(上村さん主導)のログをちら読みしましたが、このエディタ、ほんと
深い! 知らない変数、たくさん! 演算子の優先順位(評価の順番と仕組み)とか
テキスト表示の仕組みとか(by Emmett)もあったし。たしかにテキスト構造体に
(すら)ワケワカなの、けっこうありますよね。
 それでも、読んでたら、「あ、これ、できるようになりたい。どんなマクロに
すればいい?」とか、しっかり思いつく!

 死ぬまでVz! こればっか。

(注)大事でもなんでもないのですが。EMSが原因だったら(テンポラリーファイル
の破壊)、めざらさんのと同根、となり、VTDOSが原因となるのかな、VTDOSではEMSは
最小限に、とかなるのかと思いました。が、10#さんが「XMSだと起こるけど???」
と回答してくれたあたりで、もう何が何だか、、、となりました。


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


(10586) 10667Re^2: VTDOSのEMS環境は避けた方がいいです。  投稿者:konno   2023/03/20(月) 00:38
    10655 番 文太 さんへのコメント    コメント数 1

>  で、そのデータ(ファイル)の壊れ方というのを、簡単に説明して
> いただけませんか。

入れ違いに成りましたが、#10654 の説明でよろしいでしょうか。

>  じつは、僕はこれが vtdos 環境のみで起こるのかどうか、よく分かりません
> でした。WinMEで起こったことがない、と思う自信はなかった。
>  他のミスオペレーションによるファイル破壊の可能性もありましたから。可能性
> というより、実際にそれはあったと思う。

VZのバグも、[ESC]I マクロで新たに発覚しましたね。
EK- #B で、CP ズレなどが起きることがある。
BL3072 あたりでは致命的なエラー  BL8192 あたりで CP ズレ?

そして、BL1024 あたりで、VTDOSのEMS環境だけ、内容が壊れる。
これがおそらくVTDOSのEMSのバグではないかと疑われたのです。

>  とりあえず、vtdos環境では、konnoさん設定でいってみます。
>  やだよ、ファイル壊れるの。

それが良いと思います。

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


(10586) 10673Re^3: VTDOSのEMS環境は避けた方がいいです。  投稿者:文太   2023/03/20(月) 02:05
    10667 番 konno さんへのコメント

konnoさん

>入れ違いに成りましたが、#10654 の説明でよろしいでしょうか。

 よろしいとは言えませんが、これ、違う話だ、と思っています。
 僕にスワップは関係ないし、Vzのコード領域がデータと混ざることは
ないです。この辺を確認したくて、#10666で、あんなに長々書いたのですね。

 うーん、filter.defで、Vz内部ラップアラウンドが起こっているか、
置換処理(テキストバッファくずれ?)なのかなぁ?
 とりあえず、WinMEできっちり見定めます。見定められなかったら、幸運。

 vtdosでのEMSかXMSか、どうかどうか、なんとかしてください。
 m(__)m


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