一括表示

− 野ざらし言 −

[4711] ファイル挿入(1) 1.60製品版

めざら 2022/05/07(Sat) 21:13
http://mezala.la.coocan.jp/
各環境における状況をまとめてみたいと思います。
このスレッドでは,1.60製品版のcom+defで実行した状況を扱います。

Win10のckwv/VTDOS環境。常用環境で起動したVZを終了し,コマンドプロンプトからVZO.COMに改名したVZIBMJ.COM(v1.60)を実行。読み込まれる定義ファイルは,VZO.DEFに改名したVZIBMJ.DEF。

製品版.defに含まれる[ESC]Iマクロで0007.CGIの先頭に0007.CGを挿入。
挿入後のファイル冒頭から0007.CGと\[F03]で比較。

結果:不具合発生
・55行までは正常に挿入
・56行目の冒頭から相違あり
・56行目の先頭は「、ぐちゃぐちゃしていて、頭がいろんなことを考え<aa>ていて」となっており,行の途中で切断されて挿入されている。これは0007.CGの32行目のはずなので,56行目にあることからして異常。なぜこの位置なのか確認すべく先頭から検索すると32行目にマッチ。続いて56行目にマッチ。この重複した内容の56行目行末に移動すると,次の行からは文字化け。先頭に C6h 87h の2バイトがあり,3バイト目からはヌルの羅列。
・32行目と56行目のUNIX時刻は一致しており,重複していることは確かだが,どのような経緯で複写された結果かは不明。
※ここまでは,#4671で報告したものとまったく同じで再現性を確認.

同じ環境で,[ESC]Iマクロを切り出して&tを入れて実行。
一見正常に動作したように見えるが,結果は不具合発生。
・経緯の確認のためトレースすると,1回目の複写で27行まで,2回目で78行まで,3回目で80行までが挿入された。見かけ上は問題がないように見える。挿入後に[UP]でスクロールしてもパッと見は問題がないように見えるが,比較すると一致しない。0007.CGIの末尾に^QCで移動しようとすると,テンポラリファイルエラー発生。同じ環境でトレースした場合は68行目でエラー。この位置に79行目の内容がある。サイレントで実行したときと結果が異なった。

[4712] Re: ファイル挿入(1) 1.60製品版

としき 2022/05/09(Mon) 17:07
[4711]へのコメント http://toshiki.la.coocan.jp/
> 各環境における状況をまとめてみたいと思います。
> このスレッドでは,1.60製品版のcom+defで実行した状況を扱います。

可能な範囲で環境をあわせてみました。

【環境】
WinXP(32)

【事前準備】
・Dドライブに新規ディレクトリ作製
・製品版のVZIBMJ.COMとVZIBMJ.DEFをVZO.*に改名コピー
・VZFL.DEFも製品版をコピー

【手動キーロガーによる記録その1】
・CMD窓起動
・カレントをDドライブに移し新規ディレクトリにCD
・command.com起動
・VZO -z で常駐
・\[RET]でファイラーから0007.CGIオープン
・そのままファイル冒頭で[ESC]I[RET]でファイラーから0007.CGをリターン
・カーソル位置は81行め、カーソルのある行の行頭の数値は「2515」
・一見正常に挿入成功に見えるので[ESC]Sで新規ファイル名でファイル保存
・^QRでファイル先頭に移動
・[ESC]Oで0007.CGオープン
・\[F03]でファイル比較→0007.CGファイルの末尾で「相違があります」
・[F02]で元ファイルに戻ると81行2バイト目でカーソル点滅
・全ファイルを閉じてVZO常駐解除しexitを2回叩いて窓を閉じる
(挿入成功で終了)

【VZO.DEFを加工】
Bl2048をBl8192に変更

【手動キーロガーによる記録その2】
・CMD窓起動
・カレントをDドライブに移し新規ディレクトリにCD
・command.com起動
・VZO -z で常駐
・\[RET]でファイラーから0007.CGIオープン
・そのままファイル冒頭で[ESC]I[RET]でファイラーから0007.CGをリターン
・カーソル位置は80行め、カーソルのある行の行頭の数値は「2599」
・ファイルを保存せず^QRで行頭ジャンプ
・[ESC]Oで0007.CGオープン
・\[F03]でファイル比較→78行目で「相違があります」
・[F02]で窓を切り替えると、挿入された改変済みの0007.CGIのカーソル行の行頭は「2798」
・比較用にオープンした0007.CGのカーソル行の行頭は「2599」
・全ファイルを保存せずに閉じてVZO常駐解除しexitを2回叩いて窓を閉じる
(挿入失敗)

【手動キーロガーによる記録その3】(Bl8192のまま)
・CMD窓起動
・カレントをDドライブに移し新規ディレクトリにCD
・command.com起動
・VZO -z で常駐
・\[RET]でファイラーから0007.CGIオープン
・一旦^QC ^QRを実施
・そのままファイル冒頭で[ESC]I[RET]でファイラーから0007.CGをリターン
・カーソル位置は81行め、カーソルのある行の行頭の数値は「2515」
・ファイル保存せず、そのまま^QRでファイル先頭に移動
・[ESC]Oで0007.CGオープン
・\[F03]でファイル比較→0007.CGファイルの末尾で「相違があります」
・[F02]で元ファイルに戻ると81行2バイト目でカーソル点滅
・VZO常駐解除しexitを2回叩いて窓を閉じる
(挿入成功で終了)

うちとめざらさんのところでの挙動の差から考えるに、なんとなく、テンポラリファイルの関係も影響していそうな気がします。
ただ、このくらいのファイルサイズでテンポラリファイルとなると、それに影響するのは一体なんだろう。EMS?
そういえば、めざらさんのところの挙動とは関係なくて一般論的な疑問で、環境変数のTMPがない場合はカレントディレクトリが使われるはずだけど、もしTMPが指定されていて、そのディレクトリが存在していないときにはどうなるんだろう。あるいは、書き込み不可のディレクトリというか、例えばCD-ROMなんかを指定していた場合の挙動、とか。

[4713] Re^2: ファイル挿入(1) 1.60製品版

としき 2022/05/09(Mon) 21:52
[4712]へのコメント http://toshiki.la.coocan.jp/
> 可能な範囲で環境をあわせてみました。

もうひとつ、類似環境。

【環境】
WinXP(32),VTDOS1.22(ckwvなし)

以下略。
cmd+command.comのところをVTDOSに変えただけですが、結果、VZの挙動は全く変わらず。

以上、ご報告まで。

[4714] Re^3: ファイル挿入(1) 1.60製品版

konno 2022/05/11(Wed) 01:29
[4713]へのコメント
> WinXP(32),VTDOS1.22(ckwvなし)
> 以下略。
> cmd+command.comのところをVTDOSに変えただけですが、結果、VZの挙動は全く変わらず。

ええっ、VTDOS1.22 では、OK になるんですか!
私の所では、VTDOSは今まで NG だったんですよ。

それで、VTDOS1.22 を引っ張り出して、何度か試行錯誤していたら出来ました。

VTDOS122 恐らく全てのVZ共通
Bl1024*4 OK
Bl1024*5 OK

Bl がこの範囲以外では NG になります。
としきさんの場合はこれ以外でも OK ということですか。


あと、VTDOS1.53 では、エラーで落ちてしまいました。
VTDOS1.22 と何かが違うのでしょうか。
取り敢えず、メモリ関連オプションを全部コメントにしてみたら

Bl1024*4 OK
Bl1024*5 OK

OK になりました! \(^^)/ ヤッタ-
なので、今度はメモリ関連オプションを一つづつコメント外してみたら

TPAEXT=1 NG

このオプションが駄目だったようです。なので
TPALOW=1
は問題なさそうなので設定しました。

[4715] Re^4: ファイル挿入(1) 1.60製品版

としき 2022/05/11(Wed) 19:30
[4714]へのコメント http://toshiki.la.coocan.jp/
> ええっ、VTDOS1.22 では、OK になるんですか!
> 私の所では、VTDOSは今まで NG だったんですよ。

どういう設定のときにOKでNGか、ということが曖昧な表現に見えてしまうので、ここできちんとさせておきましょうか。
#4173では省略してしまっている部分を、ちょっとだけ細かく書きます。

【環境】
WinXP(32),VTDOS1.22(ckwvなし)

【事前準備】
・Dドライブに新規ディレクトリ作製
・製品版のVZIBMJ.COMとVZIBMJ.DEFをVZO.*に改名コピー
・VZFL.DEFも製品版をコピー

【手動キーロガーによる記録その1】
・VTDOS起動
・カレントをDドライブに移し新規ディレクトリにCD
・VZO -z で常駐(以下略)
(挿入成功で終了)

【VZO.DEFを加工】
Bl2048をBl8192に変更

【手動キーロガーによる記録その2】
・VTDOS起動
・カレントをDドライブに移し新規ディレクトリにCD
・VZO -z で常駐(以下略)
(挿入失敗)

【手動キーロガーによる記録その3】(Bl8192のまま)
・VTDOS起動
・カレントをDドライブに移し新規ディレクトリにCD
・VZO -z で常駐(以下略)
(挿入成功で終了)

ということで

> Bl1024*4 OK
> Bl1024*5 OK
> Bl がこの範囲以外では NG になります。
> としきさんの場合はこれ以外でも OK ということですか。

製品版.DEFの初期値であるところのBl2048ではOKでした。
ところで、konnoさんのところの自前の381kのデータって、どんなものなんでしょうか?
行数とか、一番長い行の長さとか、半角だけとか全角だけとか、どういうデータなのか教えてください。



以下、ここまでで私の思っていることのつぶやき。
私のところでは、^QC^QRとやることでテンポラリファイルエラーを回避できることが多々ありました。今回のデータでも、うちではテンポラリファイルエラーとは無縁とはいえ、同じことをすることで#Bの異常を回避することができています。また、めざらさんのところでファイルが壊れまくるというのも、明らかにテンポラリファイル関係の挙動が疑われます。
一方で、EMSやXMSの設定を変えるとテンポラリファイル関係の挙動が変わるはずだと私は思い込んでいたのですが、今回、この方面の設定を変えたことで何かが変わったという報告は少ないと感じています。その他に、テンポラリファイル関係の挙動を変えることができるオプションて、何かありましたでしょうか。
あと、私の試した多くの環境、それこそPC-98版ですら#Bの異常が発生したわけですから、対象としているテキストファイルがおかしい、ということも十分考えられるわけです。ただ、64KB以上も改行がないファイル、ということならともかく、最大行長が高々4KBにも満たないファイルで様々な異常が発生するのがよくある話だというのであれば、今までに多くの不具合報告があってもおかしくない。
ということで、堂々巡り。

[4716] Re^5: ファイル挿入(1) 1.60製品版

konno 2022/05/14(Sat) 00:40
[4715]へのコメント
> 【手動キーロガーによる記録その3】(Bl8192のまま)
> ・VTDOS起動
> ・カレントをDドライブに移し新規ディレクトリにCD
> ・VZO -z で常駐(以下略)
> (挿入成功で終了)

これって、2度目の起動では Bl8192 でも成功する、ということですか?
私の所ではまだ再現出来てないです。
でも、過去記事を見ていたら、^QC^QRとやることで正常処理できる
とあったので、やってみたら正常処理できました。私のデータでも OK です。
私は今までの実験では ^QC^QR をやっていませんでした。


今回の #B 問題は、ファイルオープン時に、^QC^QRとやることで正常処理できる
と考えていいのですかね。
だとすれば、テンポラリファイル処理の問題ということになりそうな。

VZでは #P ファイル名変更とかセーブ時にテンポラリエラーになりがちですよね。
この場合予め、^QC^QRとやることで正常処理できるなどの事例が多々あります。
もしかしたら、これらと同じ問題なのかもしれないですね。

> > としきさんの場合はこれ以外でも OK ということですか。
> 製品版.DEFの初期値であるところのBl2048ではOKでした。

そうですか。ファイルオープン時に、^QC^QRとやると正常処理できる、
ということではないのですよね。うーむ・・・


> ところで、konnoさんのところの自前の381kのデータって、どんなものなんでしょうか?
> 行数とか、一番長い行の長さとか、半角だけとか全角だけとか、どういうデータなのか教えてください。

今日のテーマの #10178:VTDOSとXP(NTVDM)の共通点?  投稿者:konno  
で書いている生ログデータです。なので半角全角混在しています。

> 今まで実験に使用した生ログファイルは
> 280,386 wf_log.cgi
> 380,844 wf_log130407.cgi
> 381,081 wf_log130408.cgi
> このうちの 381k のファイルの途中に 380k のファイルを挿入していました。

   論理行数 表示行数
381k  389行  3392行
380k  388行  3390行

一番長い行は、多分 6241バイトだと思います。

[4717] Re^6: ファイル挿入(1) 1.60製品版

としき 2022/05/14(Sat) 13:53
[4716]へのコメント http://toshiki.la.coocan.jp/
私がいろいろと省略しすぎたせいで、なんとなくkonnoさんの誤解を招いているような気がする。もちろん、konnoさんが誤解している、ということそのものが私のほうの誤解であって、konnoさんは誤解していない、というのが正解かもしれませんが、念のため、省略無しの挙動を貼り付けてみます。
一応、#4172に対する対照実験という意味合いもありますので、そちらと1手順ごとに比較していただけると幸いです。

【環境】
WinXP(32),VTDOS1.22(ckwvなし)

【事前準備】
・Dドライブに新規ディレクトリ作製
・製品版のVZIBMJ.COMとVZIBMJ.DEFをVZO.*に改名コピー
・VZFL.DEFも製品版をコピー

【手動キーロガーによる記録その1】
・VTDOS起動
・カレントをDドライブに移し新規ディレクトリにCD
・VZO -z で常駐
・\[RET]でファイラーから0007.CGIオープン
・そのままファイル冒頭で[ESC]I[RET]でファイラーから0007.CGをリターン
・カーソル位置は81行め、カーソルのある行の行頭の数値は「2515」
・一見正常に挿入成功に見えるので[ESC]Sで新規ファイル名でファイル保存
・^QRでファイル先頭に移動
・[ESC]Oで0007.CGオープン
・\[F03]でファイル比較→0007.CGファイルの末尾で「相違があります」
・[F02]で元ファイルに戻ると81行2バイト目でカーソル点滅
・全ファイルを閉じてVZO常駐解除しexitを叩いて窓を閉じる
(挿入成功で終了)

【VZO.DEFを加工】
Bl2048をBl8192に変更

【手動キーロガーによる記録その2】
・VTDOS起動
・カレントをDドライブに移し新規ディレクトリにCD
・VZO -z で常駐
・\[RET]でファイラーから0007.CGIオープン
・そのままファイル冒頭で[ESC]I[RET]でファイラーから0007.CGをリターン
・カーソル位置は80行め、カーソルのある行の行頭の数値は「2599」
・ファイルを保存せず^QRで行頭ジャンプ
・[ESC]Oで0007.CGオープン
・\[F03]でファイル比較→78行目で「相違があります」
・[F02]で窓を切り替えると、挿入された改変済みの0007.CGIのカーソル行の行頭は「2798」
・比較用にオープンした0007.CGのカーソル行の行頭は「2599」
・全ファイルを保存せずに閉じてVZO常駐解除しexitを叩いて窓を閉じる
(挿入失敗)

【手動キーロガーによる記録その3】(Bl8192のまま)
・VTDOS起動
・カレントをDドライブに移し新規ディレクトリにCD
・VZO -z で常駐
・\[RET]でファイラーから0007.CGIオープン
・一旦^QC ^QRを実施
・そのままファイル冒頭で[ESC]I[RET]でファイラーから0007.CGをリターン
・カーソル位置は81行め、カーソルのある行の行頭の数値は「2515」
・ファイル保存せず、そのまま^QRでファイル先頭に移動
・[ESC]Oで0007.CGオープン
・\[F03]でファイル比較→0007.CGファイルの末尾で「相違があります」
・[F02]で元ファイルに戻ると81行2バイト目でカーソル点滅
・VZO常駐解除しexitを叩いて窓を閉じる
(挿入成功で終了)


> 今日のテーマの #10178:VTDOSとXP(NTVDM)の共通点?  投稿者:konno  
> で書いている生ログデータです。なので半角全角混在しています。

あ、なるほど、そちらの掲示板の記載はすっかり忘れていました。
結局のところ、掲示板データということなので、データの質としては私の提供したものと同じようなものということで了解しました。
あと、一番長い行が6KB以上あるということは、私の提供したデータよりも長いわけですね。いや、もし私の提供したデータよりも最大長が短ければ、1行の最大長を短くする実験で、その長さをターゲットにして、ということを考えていたのですよ。残念というか、私のほうで独自にいろいろな値で実験するしかないですね。

[4719] Re^7: ファイル挿入(1) 1.60製品版

konno 2022/05/16(Mon) 00:52
[4717]へのコメント
としきさん、詳細な手順のおかげで理解できたようです。

> WinXP(32),VTDOS1.22(ckwvなし)
> ・製品版のVZIBMJ.COMとVZIBMJ.DEFをVZO.*に改名コピー
> (挿入成功で終了)

VTDOS1.22で、製品版のVZとVZ.DEFでは、Bl2048で挿入成功ということですね。
一旦^QC ^QRを実施しないでも、成功したということですね。
私の所では違いがありました。

VTDOS1.22で、製品版のVZと製品版VZ.DEFでは、Bl2048で挿入失敗
VTDOS1.22で、私家版のVZと常用VZ.DEFでは、Bl2048で挿入成功となりました。
VTDOS1.22では、どのVZでも、常用VZ.DEFでは、Bl2048で挿入成功となるようです。
としきさんの環境と何かが違うのでしょうね。

VTDOS1.53では、どのVZでも、どのVZ.DEFでも、Bl2048で挿入失敗となるようです。
この違いは、環境の違いなんでしょうかね、それとも・・・

[4722] Re^8: ファイル挿入(1) 1.60製品版

としき 2022/05/16(Mon) 18:41
[4719]へのコメント http://toshiki.la.coocan.jp/
> この違いは、環境の違いなんでしょうかね、それとも・・・

これまでにわかっていることというと、BlとBt、そしてテンポラリファイルと#Bに関係していそうだ、ということ。すると最終的には、ソースで#Bのルーチンを読んで、そこでどんな演算をしているか、というところを追いかける必要が出てくるのではないかと。

[4723] Re^9: ファイル挿入(1) 1.60製品版

konno 2022/05/19(Thu) 23:21
[4722]へのコメント
> これまでにわかっていることというと、BlとBt、そしてテンポラリファイルと#Bに関係していそうだ、ということ。すると最終的には、ソースで#Bのルーチンを読んで、そこでどんな演算をしているか、というところを追いかける必要が出てくるのではないかと。

ソースは何回か見ているんですが、全く分かりません。(>_<)
メモリ操作は演算と条件分岐の嵐ですから、私の苦手分野です。(^^;
せめてマクロでのバグ回避を考えるのが精一杯です。

[4718] Re^5: ファイル挿入(1) 1.60製品版

めざら 2022/05/15(Sun) 15:49
[4715]へのコメント http://mezala.la.coocan.jp/
> 今までに多くの不具合報告があってもおかしくない。

 従来は,4KBもの論理行があるファイルというのは,ほぼ存在しなかったのではないかと思います。もちろんエンジニアに属する人たちにとって,何かのログファイルというのは扱う対象にはあったとは思いますが,多くの場合はそのような方々は UNIX系ワークステーションで仕事をされており,DOS とか使ってなかったのではないでしょうか。

 一般的な論文などでは,単一の段落が 2,000文字あったら,たぶん読む気になれないですよね。表示行は縦書きだと多くて50字,横書きだと多くて40字くらいだと思いますが,まるまる1ページに相当する40〜50行も四角く活字で埋まっていたら,絶対読む気になりません。読む気にならないなんて言うと一見情緒的ですが,たぶん論文の書き方の悪い例として科学的に何か証明されているでしょう。

 一方で,ログファイルという如何にも機械が扱いやすい,ひとつのアーティクルが1論理行に詰め込まれているものを扱うようにならざるを得なかった,掲示板の管理者たる我らに特異な状況としてそれが発生した……と考えます。

 まぁ,テンポラリファイルエラーは大きなファイルを扱えば発生しやすかったというのは同じですが,あくまでもそれはメモリの扱いの問題で,論理行の長さとは異なる問題だったのではないでしょうか。

 それはそれとして,目の前に厳然と存在する不具合には,何らかのかたちで結論を出したいですよね。今後もとしきさんの提供してくれたテキストを題材にテストを重ねてゆきたいと思います。手順は踏めても環境が微妙に異なるので,なかなか絞り込めませんけどね。

[4720] Re^6: ファイル挿入(1) 1.60製品版

konno 2022/05/16(Mon) 01:06
[4718]へのコメント
>  一方で,ログファイルという如何にも機械が扱いやすい,ひとつのアーティクルが1論理行に詰め込まれているものを扱うようにならざるを得なかった,掲示板の管理者たる我らに特異な状況としてそれが発生した……と考えます。

なるほど、説得力がありますね。納得です。

>  まぁ,テンポラリファイルエラーは大きなファイルを扱えば発生しやすかったというのは同じですが,あくまでもそれはメモリの扱いの問題で,論理行の長さとは異なる問題だったのではないでしょうか。

VZで何時間も作業した結果が、テンポラリファイルエラーで失われた経験は
パワーユーザーほどあるのではないでしょうか。
その時の絶望感ときたら・・・

VZはスピード優先のためファイルオープン時に全部読み込まない仕様になっていますが
他のエデイタは、安全第一のため、一旦全部読むのが普通なのではと思います。
今はメモリもHDDもスピード、容量がけた違いになったので、全部読んでもいいと思います。

VZには、オープン時に全部読み込むオプションは無いですよね。
イベントマクロでは、最初の一つだけしか処理できなかったような。
マクロで、オープン時に全部読み込むようにするのは可能でしょうか。
今までのマクロには一切変更を加えないで可能なら嬉しいです。

[4724] イベントマクロでオープン時に^QC ^QR

konno 2022/05/19(Thu) 23:33
[4720]へのコメント
ということで
イベントマクロで、オープン時に、一旦^QC ^QRを実施させてみました。
マクロの最後に追加します。

1 "!Open"

(mr==128)?{&14 .}
&e("#]") #] ;※制約解除呪文 by Tomo
ss[+, #_ #? #^ #] ss], ;★★
.

テストデータでは手動で一旦^QC ^QRを実施するのと同じ結果になります。
これで運用していますが、今の所特に問題は出ていないようです。
こうした方が良いよという点がありましたらご教授願います。

[4725] Re: イベントマクロでオープン時に^QC ^QR

めざら 2022/05/20(Fri) 22:30
[4724]へのコメント http://mezala.la.coocan.jp/
konnoさんの環境での 14番マクロって何ですか?

[4726] Re^2: イベントマクロでオープン時に^QC ^QR

konno 2022/05/21(Sat) 02:03
[4725]へのコメント
> konnoさんの環境での 14番マクロって何ですか?

うう、全然見ていませんでした。(>_<)
確認してみたら以下のマクロがありました。

14:
#if kVZ
tm255,&d.
#else
AP0,.#E#[.
#endif
(s)?. ; 疑似ファンクション(和生時計から)

元々は時計表示をさせていたようですが、今はほとんど意味が無いですね。
なのでコメントにしてしまいました。

(mr==128)?. ;{&14 .}
&e("#]") #] ;※制約解除呪文 by Tomo
ss[+, #_ #? #^ #] ss], ;★★
.

うーむ、WGREP を使った後で VTDOS が落ちることがありました。
これが影響してるのかなぁ、もう少し様子を見てみます。

[4733] イベントマクロで^QC ^QRは封印します

konno 2022/05/28(Sat) 00:21
[4726]へのコメント
> うーむ、WGREP を使った後で VTDOS が落ちることがありました。
> これが影響してるのかなぁ、もう少し様子を見てみます。

どうもこのイベントマクロを導入してからVTDOSが頻繁に落ちるようです。
なのでこのマクロは一旦封印します。
お騒がせしました。m(__)m

[4721] Re^6: ファイル挿入(1) 1.60製品版

としき 2022/05/16(Mon) 18:34
[4718]へのコメント http://toshiki.la.coocan.jp/
konnoさんと同じく、めざらさんのご意見には納得できます。
ただ、そこで原点に立ち返るというか、何バイトまでの論理行ならVzは問題なく扱えるのかという仕様を確認しようと黒本その他を探したのですが、私には見つけることができませんでした。もちろん、1論理行の長さがテキストバッファやラインバッファを超えるようなファイルであれば正しく扱えない、ということは直感的にイメージしやすいのですが、実は1論理行が高々260バイトであっても正しく処理できない、ということだとあまりうれしくない。ま、うれしくはなくても、それが仕様として明記してあれば私の場合はあきらめられます。昔から時々話題にしている、仕様というものに対する私のこだわりとか考え方の部分の話ですから。
余談ですが、Pascalというコンピュータ言語、あれは言語仕様としては、最初から最後まで全く改行無しの非常に長いプログラムでもコンパイルできなくてはいけないらしい。もちろん、実際の実装がそうはなっていない処理系はざらにあるらしいですが。

> 目の前に厳然と存在する不具合には,何らかのかたちで結論を出したい

同感です。
とりあえず、うちでは出ないけどめざらさんのところでは頻出するテンポラリファイルエラー、どうすればお目にかかれるかと考えて、XMSとEMSを全く使わなければ出すことができるかなぁ、と思いつきました。
そのうちにこの環境を作って試してみたいと思います。

[4729] Re^5: ファイル挿入(1) 1.60製品版

としき 2022/05/24(Tue) 00:15
[4715]へのコメント http://toshiki.la.coocan.jp/
> EMSやXMSの設定を変えるとテンポラリファイル関係の挙動が変わるはず

WinXP(32)、cmd.exe です。
製品版のVZIBMJ.COMとVZIBMJ.DEFをVZO.*に改名コピーし、さらにEM0と設定しました。XM0のままなので、テンポラリファイルエラーが出るかな、と期待したのですよ。vzo -zで常駐、0007.cgiをオープン、さらにそこで0007.cgを挿入して、ありゃりゃん、正常に挿入できてしまった。ファイルを保存して、別のDOS窓で開いて、ファイル破損がないことを確認。
では、ということで、EM0のままBl8192に変更して、さらに新しくDOS窓を開いてからvzo -zで常駐、0007.cgiをオープン、さらにそこで0007.cgを挿入して、おぉっと、挿入異常発生。何じゃこりゃ。

とりあえず、いまだにテンポラリファイルエラーは見られていません。

[4730] Re^6: ファイル挿入(1) 1.60製品版

めざら 2022/05/25(Wed) 07:07
[4729]へのコメント http://mezala.la.coocan.jp/
 ふつうに考えれば,余裕のある方(大きい方)がデータの扱いが細切れにならない分,不具合の発生する危険性が減るように思いますけどね。なんだろ。

 別に転送回数が減るわけでもないのでしょうけど,少なくとも8192は2048の倍倍なので「切れ目」は一緒のはずなんですけどねぇ……。

 ラインバッファの扱いの問題よりも,ラインバッファのメモリ上の配置の問題が大きいという可能性があるのかなぁ……。

 マクロバッファが製品版のまま(8192)だと,ラインバッファが正負の境界をまたぐ問題で不具合が発生する可能性がある…というのは過去に指摘されていたところですが,こちらは関係しないのかな。

 その環境で CSEGMAP をとってみると 8000hの境界がどこにあるかわかるかと思いますけど。ただ,このところの各所環境でのテストが繰り返されてきていて,その結果からは,この問題が関係するとも思えないのですけれどねぇ……

[4732] Re^7: ファイル挿入(1) 1.60製品版

としき 2022/05/27(Fri) 17:54
[4730]へのコメント http://toshiki.la.coocan.jp/
>  その環境で CSEGMAP をとってみると

その環境というのがどの環境の事を指しているのかがよくわかりませんが。

command.comでEMS残り全部、Bl2048の場合

Cseg map : 2022/05/27_17:49:50
0 1 2 3 4 5 6 7 8 9 A B C D E F
0 @@@@@@@@@@@@@@@XXXXXXXXXXXXXXXXi
1 iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii
2 iiiiiiiooooooooooooooooooooooooo
3 oooooooooooooooooooooooooooooooo
4 oooooooXXUUUUUUUUSSSSSSSSUUUUUUU
5 UU-------@@@--------------------
6 ---------------------------:::::
7 :::::::::::::--================-
8 --------------------------------
9 --------------------------------
A --------------------------------
B --------------------------------
C --------------------------------
D --------------------------------
E --------------------------------
F --------------------------------
0 1 2 3 4 5 6 7 8 9 A B C D E F


command.comでEMS残り全部、Bl8192の場合

Cseg map : 2022/05/27_17:50:52
0 1 2 3 4 5 6 7 8 9 A B C D E F
0 @@@@@@@@@@@@@@@XXXXXXXXXXXXXXXXi
1 iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii
2 iiiiiiiooooooooooooooooooooooooo
3 oooooooooooooooooooooooooooooooo
4 oooooooXXUUUUUUUUSSSSSSSSUUUUUUU
5 UU-------@@@--------------------
6 ---------------------------:::::
7 :::::::::::::--=================
8 ================================
9 ===============-----------------
A --------------------------------
B --------------------------------
C --------------------------------
D --------------------------------
E --------------------------------
F --------------------------------
0 1 2 3 4 5 6 7 8 9 A B C D E F


VTDOS1.22でEM0、Bl2048の場合

Cseg map : 2022/05/27_17:51:41
0 1 2 3 4 5 6 7 8 9 A B C D E F
0 @@@@@@@@@@@@@@@XXXXXXXXXXXXXXXXi
1 iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii
2 iiiiiiiooooooooooooooooooooooooo
3 oooooooooooooooooooooooooooooooo
4 oooooooXXUUUUUUUUSSSSSSSSUUUUUUU
5 UU-------@@@--------------------
6 ---------------------------:::::
7 :::::::::::::--================-
8 --------------------------------
9 --------------------------------
A --------------------------------
B --------------------------------
C --------------------------------
D --------------------------------
E --------------------------------
F --------------------------------
0 1 2 3 4 5 6 7 8 9 A B C D E F


VTDOS1.22でEM0、Bl8192の場合

Cseg map : 2022/05/27_17:53:05
0 1 2 3 4 5 6 7 8 9 A B C D E F
0 @@@@@@@@@@@@@@@XXXXXXXXXXXXXXXXi
1 iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii
2 iiiiiiiooooooooooooooooooooooooo
3 oooooooooooooooooooooooooooooooo
4 oooooooXXUUUUUUUUSSSSSSSSUUUUUUU
5 UU-------@@@--------------------
6 ---------------------------:::::
7 :::::::::::::--=================
8 ================================
9 ===============-----------------
A --------------------------------
B --------------------------------
C --------------------------------
D --------------------------------
E --------------------------------
F --------------------------------
0 1 2 3 4 5 6 7 8 9 A B C D E F


めざらさんご自身の環境と比較して、ここが違う、というのはありますか?
つ〜か、なぜにうちではテンポラリファイルエラーが出ないのか。

[4734] Re^7: ファイル挿入(1) 1.60製品版

としき 2022/05/28(Sat) 17:39
[4730]へのコメント http://toshiki.la.coocan.jp/
>  マクロバッファが製品版のまま(8192)

この関係が気になったので、実験してみました。
以下、環境はWinXP、command.comです。
まずは製品版からBl4096だけ変えてみました。
結果、正常挿入。

Cseg map : 2022/05/28_17:27:08
0 1 2 3 4 5 6 7 8 9 A B C D E F
0 @@@@@@@@@@@@@@@XXXXXXXXXXXXXXXXi
1 iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii
2 iiiiiiiooooooooooooooooooooooooo
3 oooooooooooooooooooooooooooooooo
4 oooooooXXUUUUUUUUSSSSSSSSUUUUUUU
5 UU-------@@@--------------------
6 ---------------------------:::::
7 :::::::::::::--=================
8 ===============-----------------
9 --------------------------------
A --------------------------------
B --------------------------------
C --------------------------------
D --------------------------------
E --------------------------------
F --------------------------------
0 1 2 3 4 5 6 7 8 9 A B C D E F

次、Bl4096のままBm1024にしてみました。
結果、正常挿入。

Cseg map : 2022/05/28_17:32:15
0 1 2 3 4 5 6 7 8 9 A B C D E F
0 @@@@@@@@@@@@@@@XXXXXXXXXXXXXXXXi
1 iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii
2 iiiiiiiooooooooXXUUUUUUUUSSSSSSS
3 SUUUUUUUUU-------@@@------------
4 --------------------------------
5 ---::::::::::::::::::--=========
6 =======================---------
7 --------------------------------
8 --------------------------------
9 --------------------------------
A --------------------------------
B --------------------------------
C --------------------------------
D --------------------------------
E --------------------------------
F --------------------------------
0 1 2 3 4 5 6 7 8 9 A B C D E F

次、Bm1024のままBl8192にしてみました。
結果、異常挿入。

Cseg map : 2022/05/28_17:36:07
0 1 2 3 4 5 6 7 8 9 A B C D E F
0 @@@@@@@@@@@@@@@XXXXXXXXXXXXXXXXi
1 iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii
2 iiiiiiiooooooooXXUUUUUUUUSSSSSSS
3 SUUUUUUUUU-------@@@------------
4 --------------------------------
5 ---::::::::::::::::::--=========
6 ================================
7 =======================---------
8 --------------------------------
9 --------------------------------
A --------------------------------
B --------------------------------
C --------------------------------
D --------------------------------
E --------------------------------
F --------------------------------
0 1 2 3 4 5 6 7 8 9 A B C D E F

これらの結果より、ラインバッファのメモリ配置に関して、何か読み取れることってあります?

[4735] Re^8: ファイル挿入(1) 1.60製品版

めざら 2022/05/29(Sun) 19:39
[4734]へのコメント http://mezala.la.coocan.jp/
※環境は Win10 の ckwv 9改 / vtdos 1.53で,command.comは PC-DOS6.3。
 製品版のvzibmj.comとvzibmj.defをvzo.*に改名して起動.以下同じ。

■ vzo -em1 -bl2048
スタックセグメント内の各バッファの配置は同じ。
cgi のオープン後に ^QC/^QR でテンポラリファイルエラーは回避。
cg の挿入により,vtdos がハングアップ。挿入状態は確認できず。

■ vzo -em1 -bl8192
スタックセグメント内の各バッファの配置は同じ。
cgi のオープン後に ^QC/^QR でテンポラリファイルエラーは回避。
cg の挿入は正常終了。テキスト比較で相違なし。

■ vzo -em0 -bl2048
スタックセグメント内の各バッファの配置は同じ。
cgi のオープン後に ^QC/^QR でテンポラリファイルエラーは回避。
cg の挿入により,vtdos がハングアップ。挿入状態は確認できず。

■ vzo -em0 -bl8192
スタックセグメント内の各バッファの配置は同じ。
cgi のオープン後に ^QC/^QR でテンポラリファイルエラーは回避。
cg の挿入は正常終了。テキスト比較で相違なし。

ラインバッファの途中に $8000 をまたいでいるのは 8192 を指定した場合ですが,皮肉なことに 2048 のときに vtdos が落ちました。
表示されていたエラーコードは #4626 と同じです。

[4737] Re^9: ファイル挿入(1) 1.60製品版

konno 2022/05/30(Mon) 02:09
[4735]へのコメント
> ラインバッファの途中に $8000 をまたいでいるのは 8192 を指定した場合ですが,皮肉なことに 2048 のときに vtdos が落ちました。
> 表示されていたエラーコードは #4626 と同じです。

VTDOSが落ちるのは、VTDOS.CFG のオプションで

SCASB_MODE=1

これが入っていないのでは? これを入れれば落ちにくくなると思います。
VTDOS1.22 ではこのオプションが無いですが、メモリ管理の厳格化だかで
このオプションを追加したみたいです。
VZではこのオプションを入れた方がVTDOSが落ちにくいようです。

あと、私のオプションは現在

BREAK=1
USECMD=1
;TPAEXT=1
TPALOW=1
PAGEFRAME=0xEC00

こうなっていますが、めざらさんのところではどうですか。

Bl2048 のときに vtdos が落ちるのは、マクロバッファが64kをまたいでいるから?
今思ったんですが、SCASB_MODE=0 だと、64kをまたぐと落ちる仕様なのか??
この二つに関連性があるのでは? と思ってしまいました。

あ、あと、めざらさんは PC-DOS6.3 なんですね。
私は、MSDOS6.2 を使用しています。としきさんはなんでしたっけ?
DOS の違いが微妙な挙動の違いだったりして。

[4739] Re^10: ファイル挿入(1) 1.60製品版

めざら 2022/05/30(Mon) 07:54
[4737]へのコメント http://mezala.la.coocan.jp/
#4734 の最初の図のとおり……
7 :::::::::::::--=================
8 ===============-----------------
…… bl4096 のみ指定した場合に $8000 をまたぎます。
マクロバッファを30000ちかく指定したときは,マクロバッファがこの正負境界をまたぎます。(64kではありません)

メモリのより前方にあるラインバッファが正負境界をまたぐと,マクロをロードするときに一時的にラインバッファに展開するタイミングで不具合の発生する可能性があるという報告があります。通常の編集時にラインバッファが正負境界をまたいでいることが原因でテキストが破壊されるなどの不具合が発生したという報告は記憶にありませんが,念のため可能性を疑ってみました。

以下のVTDOSの設定が関連が関係するのでは?ということですが……
TPAEXT=1
SCASB_MODE=1
……これらはどういう意味なのでしょうか。
vtdos.txtを読んでもまったく理解できません。
「TPAを限界まで拡張」「セグメントラップアラウンドによる異常終了の回避」……これ,パンピーには分からない用語/概念ですね。(^_^;

[4741] Re^11: ファイル挿入(1) 1.60製品版

としき 2022/05/31(Tue) 14:33
[4739]へのコメント http://toshiki.la.coocan.jp/
> TPAEXT=1
> SCASB_MODE=1
> ……これらはどういう意味なのでしょうか。

TPAって、MS-DOS以降でも使う用語だったのかな。
かつて、8bitOSのCP/Mでは、よく使っていました。
トランジェントプログラムエリアの略で、MS-DOSでよくいうところのコンベンショナルメモリと大体同じ意味です。要するに、プログラムをロード可能な領域。
EXTっていうことで、拡張するかしないか、ということでしょう。
通常のDOSプログラムは拡張しない環境で動くことを前提に作っているはずなので、ものによっては、拡張すると動作がおかしくなるかもしれない。でも、例えば常駐プログラムとか、UMBでも動作するものなどもある。ということから、拡張してもおかしくならないものなら、使えるメモリ量が増えるとうれしい場合もあるかも。

SCASBってのは、アセンブラの文字列操作命令ですね。
文字列ってのは、列ってくらいですから長さがあります。なので文字列を、頭から処理するか尻尾から処理するか、というときに、ある方向からの処理で問題があるなら逆方向からにする、ということか、あるいは、自動で逆方向に切り替える処理が入っているけどその処理を抑止して常に一方向からにする、ということだと思います。

[4743] TPA

文太 2022/06/02(Thu) 14:32
[4741]へのコメント
 じょ、情熱的! という情緒的な感想のみです。
 そして全体の流れはほぼ理解できていませんが、ふと、調べてみて。

https://www.glamenv-septzen.net/view/633

CP/M-80の構造
メモリレイアウト(BIOS,BDOS,CCP,TPA および 0h - 100h) ★

[TPA]
| Transient Program Area
| (Free Memory for Programs)


IO.SYS, MSDOS.SYS, COMMAND.COMについて ★

CP/M  MS-DOS     機能
TPA   ユーザー領域 ユーザープログラムがロードされる

 ★が検索する際のキーワード。

 ふーん、そうなんだぁ。としきさんの言うとおりですね。
 ま、僕が捕捉(理解)できたのは、使い物にならない抽象的データ
だけですが。
 コンベンショナルメモリー(+UMB?)。

 こっちへの情熱は失われてしまっているみたい……。

[4778] Re: TPA

文太 2022/06/14(Tue) 22:21
[4743]へのコメント
 どうでもいいことです。
 どっかで聞いたことがあるような気がするなぁ、という記憶だったので、見つけたら
ちょっとだけ嬉しくなってしまい……。
 よくこんなことについての記憶の断片が、この脳みその中に残っていたもんだなぁ、
と。

c:\vzsrc\cmos\dos.asm 1095

;--- Allocate TPA --- (Transient Program Area == conventional memory)
	public	allocTPA	;上は僕が入れたメモなのかもしれません。
				;c.mosさんにこんなメモが必要か? と。
;--- Free TPA ---
	public	freeTPA

;--- Get TPA top seg ptr ---
	TPAptr	proc

[4742] Re^11: ファイル挿入(1) 1.60製品版

konno 2022/06/01(Wed) 00:24
[4739]へのコメント
> …… bl4096 のみ指定した場合に $8000 をまたぎます。
> マクロバッファを30000ちかく指定したときは,マクロバッファがこの正負境界をまたぎます。(64kではありません)

ああ、そうでしたね、うっかりしました。
fgalpkに関連発言がありました。ここに張り付けますね。

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

> 14899/14900 xxxxxxxx Emmett RE:オリジナルで読めないマクロ?
> (15) 99/11/21 00:06 14887へのコメント

 これって、&z じゃなくって、例の、ラインバッファがオフセット 8000h をまた
ぐと再カスタマイズに失敗するというバグじゃありませんの?

 製品版の vz.def は、このバグが非常に出やすい設定にたまたまなっているよう
です。で、Bm を太らせるとラインバッファが後ろに移動して直る。

 fgalpk の、
^^
》06733/06801 xxxxxxxx Masawo 再カストマイズマクロの大きさは?
》(14) 94/09/23 12:07 コメント数:1

 から始まるツリー、とりわけ

》06883/06891 xxxxxxxx m.gann バグ・オブ・ザ・再カスタマイズ
》(14) 94/09/29 21:56 06815へのコメント コメント数:1

》06903/06932 xxxxxxxx 榊原 知 RE:バグ・オブ・ザ・再カスタマイズ
》(14) 94/10/01 07:47 06883へのコメント コメント数:2

 を参照。

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

m.gann さんが言っていたのが

>  実は、この件は v1.6 開発モニタ時に c.mos さんに報告しています。しかし、
>  一笑に付された格好で無視されてしまった。

それを受けて榊原さんが

>  これだけ詳しく書いてもらえると、とってもヒントになります。ちゃんとバグ
> が見つかって、手元のソースでは直しました。

恐らく高橋版では直しているのではと思います。
で、#B のバグは、境界またぎか、ブロック操作時にカーソルポインタの
計算ミス(条件分岐?)があるのではと想像しています。


> 以下のVTDOSの設定が関連が関係するのでは?ということですが……
> TPAEXT=1
> SCASB_MODE=1
> ……これらはどういう意味なのでしょうか。
> vtdos.txtを読んでもまったく理解できません。
> 「TPAを限界まで拡張」「セグメントラップアラウンドによる異常終了の回避」……これ,パンピーには分からない用語/概念ですね。(^_^;

私もよくわからないです。(^^;
ただ、VTDOS1.53 ではこれらの設定をして初めて 1.22 と同等の安定度になるようなので。

[4744] 榊原さんの修正箇所?

konno 2022/06/04(Sat) 00:32
[4742]へのコメント
> それを受けて榊原さんが
> 
> >  これだけ詳しく書いてもらえると、とってもヒントになります。ちゃんとバグ
> > が見つかって、手元のソースでは直しました。
> 
> 恐らく高橋版では直しているのではと思います。

最近のソースを確認してみたら、CORE.ASM の中に

;--- Check block ---
chktblk	proc

  _if z
	add	ax,[bp].ttop		; ##1.5
    	jc	chkt1			;#s16		
	mov	dx,ax
	add	dx,[bp].bofs
    	jc	chkt1			;#s16		
	cmp	dx,cx
	je	noblk
	jb	chkt_a
  _else
chkt1:	mov	ax,0FFFFh
	mov	dx,ax
  _endif


こんなコメントがありました。
#s16 は、高橋さんが榊原版VZ.COM を解析した変更点だと思います。

 jc	chkt1			;#s16		
は、オリジナルVZでは無いので、榊原さんが追加したのだと思います。

 add の加算命令は、8000hを超えるとキャリーオーバーになってマイナスになります。
 jc はキャリーフラグで分岐するので、分岐先で補正するようにしたと思われます。
 
ここが該当のルーチンかはわからないですが。(^^;


# 文太さんもお元気そうでなによりです。

[4745] Re: 榊原さんの修正箇所?

文太 2022/06/04(Sat) 17:25
[4744]へのコメント
konnoさん
 お気遣い、本当にありがとうございます。

c:\vzsrc\taka2\core.asm 528

;--- Check block ---
; AH :blkm
; BX :blktop
; CX :blkend
(略)
_if z
add ax,[bp].ttop ; ##1.5
jc chkt1 ;#s16

 ほんとだ、あった。高橋さんもマメですね。す、すごい。すぐ見つける
konnoさんも、ほんとすごい。
 core.asm、生まれて初めてオープンしました。
 なぜか、\taka2なるディレクトリがある……。かつて、何かの野心が
あったのだろう……。
 coreって、これがVzの心臓部なの?
 macro.asmぐらい読みたいなぁ、なんて思ったことがある記憶です。

 ああ、「すべてが懐かしい」、とかちょっと言ってみたくなって
しまいました。このWin7 メインマシンに、\vzsrcが入っていることが、
僕自身、驚きです。

[4752] Re^2: 榊原さんの修正箇所?

konno 2022/06/09(Thu) 01:04
[4745]へのコメント
>  ほんとだ、あった。高橋さんもマメですね。す、すごい。すぐ見つける
> konnoさんも、ほんとすごい。

いやあ、#s16 は以前から目にしていたので、もしかしたらと思って
確認したら、それらしいルーチンだったのです。
でもほんとはここが該当箇所なのかはよくわからないの。

>  coreって、これがVzの心臓部なの?

コアは全ての使徒の心臓部ですからねぇ。
# VZシリーズ、完成していたのか・・・・ いや完成してません。

>  macro.asmぐらい読みたいなぁ、なんて思ったことがある記憶です。

大丈夫です、私もまだ読めてませんから。(^^;

>  ああ、「すべてが懐かしい」、とかちょっと言ってみたくなって
> しまいました。このWin7 メインマシンに、\vzsrcが入っていることが、
> 僕自身、驚きです。

今度はヤマトの艦長ですか、我々は同じ船に乗っているんですよね。
この物語はまだ終わらないかもしれません。

[4755] macro.asmとか

文太 2022/06/10(Fri) 01:04
[4752]へのコメント
konnoさん

 まだ見られてますよね?
 いや、それでも、やはり僕もVzがいまだに好きらしく。

1989/05 兵藤嘉彦:VZ Editor v1.00 (EZの前史あり)
1993/12 兵藤嘉彦:VZ Editor v1.60(c.mos最終版)

 なんて歴史なんですね(年表からお借りしました。多謝です>めざらさん)
 4年半くらい。EMSとか他機種版とか、やっぱり世の中の進歩に合わせて
いったのもある。でも短いですね。その後が(我々が)長すぎなのかも
しれませんけれど。

 簡単にお教えいただけると嬉しいという質問なのですが。
 Vzのマクロって、あとから付けた、というか、機能を中から引っ張り
出してきて、マクロコードでアクセスできるようにしたものですよね?
 これが質問です。

 経緯を簡単に説明すると、core.asmとmacro.asmの関係とか、ふと疑問に
思いまして、上の質問になったわけです。
 もっと具体的に質問しますと、Vz v1.00のときって、きっとマクロとか
なかったんですよね? いつから、macro.asmは登場したんだろう?

 マクロコードのコマンド・関数・その他って、Vzが内部で持ってる、
つまりエディタとして機能するのに必要な情報ないし計算式じゃないですか。
で、これを外からアクセスできるようにマクロインタープリタというのと
その記号体系(?)とか制御構造(コード)が後から付け加えられたん
だろうな、と。

 簡単にご回答いただけると、なんだか幸せなのですが。 m(__)m


 あ、レスがついてた。いえいえ、ご謙遜なさらずとも。konnoさんしか
読もうとした人はもういないのですから。

>コアは全ての使徒の心臓部ですからねぇ。

 あ、珍しく着いていけてます。『エヴァ』、ここ2年くらいで、全部
見ました。エッチなとこ、好きです。
 そこでそれはやばいだろう、みたいなのもあった。アスカのベッド横
シンジ。「僕はサイテーだぁ!」−−−はい、最低です。

 最終版の第三村だっけ、あの長閑な田園風景が好き。レイが田植えとか
してました。今年、バケツ稲なんてのに挑戦してます。茶碗一杯の米を
求めて。小学生がやる奴。

 戻って(笑い)、エヴァ・シリーズ。最初のころ雄たけびをあげて
使徒を食いまくっていたエヴァにも驚いたけど、復活したシリーズに
ずたずたにされて、内蔵丸出し、目玉とびだしの2号機にも参りましたね。
槍がささった姿もちょっと忘れがたい。げ、芸術。ロンギヌスの槍。
わけわからん。

>今度はヤマトの艦長ですか、我々は同じ船に乗っているんですよね。
>この物語はまだ終わらないかもしれません。

 そうですね。やっぱ楽しいですよ。Blの話とか、ラインバッファとか
あったねぇ、そういうの、なんて感じなのですが。

 やりはしないのですが、ふと、オープン・イベントだよな、それが
欲しければ、なんて考えていたりして。呪文解除ってあったなぁ、
あ、konnoさん、それそれ、とか。
 vz.defもvzfl.defも、最後に見たのは4年前くらいだろうか……。

[4756] Re: macro.asmとか

文太 2022/06/10(Fri) 10:39
[4755]へのコメント
core.asm

 お遊びです。ご存知のとおり、深いところに行く(行ける)予定も願望もありません。
 誰かの何かのちょっとした刺激になったりすれば、幸いです。

 以下は、core.asm上で、「\x ^;--- [A-Z]」の検索文字列をグレップしたものです。
多謝>grep.def by Sakakibara.

 主なプロシージャ(お仕事単位)を拾っているつもりです。
 何が心臓に(最初の地点に)入ってるのだろう? それだけです。ただ、心臓だけではなく
dos.asmとかdisp.asmとかあるので(基本=心臓)、これだけ見てもワケワカだよな、という
感想でしたが。

;--- Do Tab ---				;c.mosさん的には、タブ処理は最初に
					;片付けたい処理?
;--- Load to Line buffer ---		;ラインバッファ、エディタの(Vzの)基本
;--- Save from Line buffer ---		;テキストバッファに戻す?
;--- Close Line buffer ---
;--- Scan line start ptr  ---		;はて?
					;編集中のファイルの行先頭をいちいち確定保存?
					;どのバッファにカーソルがあるか、かなぁ?
;--- Scan field start ptr ---		;フィールドってなんだ?
;--- Scan field start ptr ---
;--- Redraw screen ---			;表示が基本。でないと見えない(動いてない場合)
;--- Display one line ---		;高速の秘訣、らしい
;--- Check block ---			;ブロック操作も基本なのか。
;--- Display full screen ---		;表示。おお、下半分は分割されていたのか
;--- Display lower screen ---
;--- Set home/bottom line number ---	;行数管理(20行とか25行とか、vtextとかありますね)
;--- Clear message line ---		;メッセージラインも大事(21行目、26行目?)
;--- Set location(x,y) from cursor point ---	;カーソルのcpから?
;--- Set edit point from location(x,y) ---	;cpに対してedit point
;--- Adjust by cp ---			;何を調整するのだろう?
;--- Adjust by field ---		;フィールドってなんだ?
;--- Set line top/end ptr ---		;行単位が基本
;--- Set bend ---			;bend=ラインバッファ end
;--- Set home ptr ---
;--- H screen adjust ---		;表示
;--- V screen adjust ---
;--- Vertical scroll ---		;カーソル移動(↓↑)でcpも表示も変わるよね。

 ぜんぜん足りないはず。main.asm, text.asm, dos.asm, disp.asm, ledit.asmと、同時に
構想されてなければ、MS-DOSエディタとして動くはずがないですね。

 いえ、タブはいいとして、ブロック処理がここに……。ブロックの処理も1行単位で行って、
高速でラインバッファの入れ替えがされてるから?

 しかし、こうやってみると、美しいソースだ、とは思う。
 ここまで美しくきっちり書かないと、複雑すぎて、動くものにならなかったのだろう。

[4757] フィールドって?

文太 2022/06/10(Fri) 22:28
[4756]へのコメント
 たぶん、表示を絡めた行のことでしょう。
 誰かに言われそうな気がしたので。
 でも、もう先はございません。

-----------------------------------------------
@WD @Wd @wd @fldsz 
各種モード
 WD  *   デフォルトの表示カラム数
   (80)  <2〜250>  fldsz
   全テキストで共通
  > We  編集中のテキストの表示カラム数
-----------------------------------------------
-----------------------------------------------
@WE @We @we @fsiz @wa.57 
各種モード
 We  *   編集中のテキストの表示カラム数
   ($WD)  <2〜250>  fsiz  wa.57
   編集テキスト変数
   初期値は WD に設定される
  > WD  デフォルトの表示カラム数
-----------------------------------------------
 ※fldszもfsizもfield sizeの略だと思われますが、fsizって、
  覚えてられるの? szとsiz。他にもこのペア、あるのかな?

 なるほど、それでタブ処理がcore.asmに入っていたのか。core.asmは
かわいいです。行編集(Vzのコアな仕事)の出し入れ、表示が、ひととおり
小さく入ってる。
 より細かくは、ledit.asmへどうぞ。

 で、main.asmは? coreとmainはどういう関係? main.asm、見た瞬間、
頭痛と吐き気がどばっと襲ってきました。
 編集にいたるまでの起動で、vz.defは読みこむは(とうぜん、各種バッファ
サイズなどが設定できる)、テンポラリーファイルの管理はあるは……。
 ほとんど狂気。作者は天才。すげえ記憶力と集中力だったのだろう。
 「人間が書いたものです。読めないはずがありません」
 「いえ、ふつう読めないと思います」

 何年かぶりに、FGALDCのログをグレップしました。みんな、すごいです。
 青春をかけた人たち。

[4758] Re: フィールドって?

めざら 2022/06/11(Sat) 09:59
[4757]へのコメント http://mezala.la.coocan.jp/
見えてる範囲(領域)て感じでしょうか。

>  青春をかけた人たち。

うちらは,さしずめ朱夏と白秋をかけた人たち。

夜も寝られないほど興奮した毎日を送った PK 時代は二,三年でした。
「青春」って異様に短い期間ですよね。
その後が長い,長過ぎる枯れた期間。
出会えたというのは幸せなことでした。
家族・朋友の次に付き合いが長いもの…有形・無形の存在。

作者とそれを支えた人たちに感謝しかありません。
(道具は何を使っても成果物は同じなのに,何がそうさせたのか……)

[4759] Re^2: フィールドって?

文太 2022/06/11(Sat) 12:45
[4758]へのコメント
めざらさん

 以下、勉強になりました。

-------------------------------------------
しゅ‐か【朱夏】 の解説
《五行思想で、赤色を夏に配するところから》夏の異称。《季 夏》

古代中国の五行思想で、「春」は「青春(せいしゅん)」、夏は「朱夏(しゅか)」、秋は「白秋(はくしゅう)」、冬を「玄冬(げんとう)」といった。これを、人生に当てはめたもの。

五行思想(ごぎょうしそう)または五行説(ごぎょうせつ)とは、古代中国に端を発する自然哲学の思想。万物は火・水・木・金・土(七曜の命令)の5種類の元素からなるという説である。
-------------------------------------------

 は、おいておいて。

 うん、僕がVzと深い仲になったのは、1995年くらいで、31歳近辺。松を使っていて、ふとノジマで買った(完全なる偶然)Vzを動かしてみようとして、ぜんぜん分らなくて、ヴィレッジセンターのサポートに電話したら、見米快行編『続VZ天國』(1994/5刊)を勧められて……。その後、上村さんの本を求めて、御茶ノ水とアキバまで行ったものなぁ。書店にVz本が、どうにかこうにか、まだ並んでいた時期。
 朱夏かなぁ?

 でも、本気はもうないと思うけど、まだ続いてますね。WinME機は買える、となったので、ジャンク(腐海)を整理して捨てていかないと。
 少しずつ、残り時間とかやっておくべきこととか、考え始めてます。
 とかいいつつ、macro.asmのプリントアウトを2年に一度くらい、退屈で死にそうな業務の合間に眺めてます。2年に一度数時間だけですが(最近は、4年に一度かな)。

[4764] テンポラリファイル

としき 2022/06/13(Mon) 01:37
[4757]へのコメント http://toshiki.la.coocan.jp/
そうか、テンポラリファイル関係はmain.asmなのか。
konnoさんは#B関係を追いかけておられるようなんで、#4749にも書きましたが、私はテンポラリファイル関係を追いかけたいな、という願望だけは抱いております。おそらく何もできないでしょうが。

>  「人間が書いたものです。読めないはずがありません」
>  「いえ、ふつう読めないと思います」

普通でない人限定かもしれませんが、現物がそこにあれば、読むことができる可能性はあるわけですよね。厳しいけれど暖かい世界、というか。
いや、実は最近、身近でそれと対極のような世界に触れてしまったもので。
ストレスたまっちゃうよ、全く。
だけど、これから当分の間はその世界とは接触がない、はず。いやぁ、助かった。

[4777] Re: テンポラリファイル

文太 2022/06/14(Tue) 21:20
[4764]へのコメント
としきさん

 あっちは何だか少し前進したみたいですね(みたいに見えた、が正確)。前にではなく横になのかもしれませんけど。カニ?
 お疲れ様です。おめでとうございます。

>そうか、テンポラリファイル関係はmain.asmなのか。
 ems.asmにも、いっぱいありそう。さすがにこれは怖くて開けられません。ledit.asmが単機能のリストで楽しそう。
 EMSにテンポラリーファイルを作るってどゆこと? と、生まれて初めて(たぶん)疑問に思いました。テンポラリーファイル(nm_vztmp="vztemp.$$$")の作られる順番ってどうなってたっけと黒本を探してます。腐海に飲み込まれた模様。あ、うちの腐海の中にも「最深部、清浄の地」があるんだろうとは思うのですが、手も足も届かないんですよ。未見。

[4760] Re: macro.asmとか

konno 2022/06/11(Sat) 23:46
[4755]へのコメント
>  あ、珍しく着いていけてます。『エヴァ』、ここ2年くらいで、全部
> 見ました。エッチなとこ、好きです。

良かった、話が通じているかちょっと不安だったので。ヽ(^^;)オイオイ

>  最終版の第三村だっけ、あの長閑な田園風景が好き。レイが田植えとか
> してました。今年、バケツ稲なんてのに挑戦してます。茶碗一杯の米を
> 求めて。小学生がやる奴。

この辺の描写はちょっと冗長で退屈に感じましたね。求めるものが違うから?
バケツ稲、面白そうですね。ロシアのせいで穀物不足の不安から私もちょっと実験を。

>  そうですね。やっぱ楽しいですよ。Blの話とか、ラインバッファとか
> あったねぇ、そういうの、なんて感じなのですが。

WinME とか、DOS7 のVZ環境をお持ちの文太さんにお願いがあります。
是非 [ESC]I の挙動を試してほしいのです。お暇なときにでも。m(__)m

[4762] Re^2: macro.asmとか

文太 2022/06/12(Sun) 00:10
[4760]へのコメント
konnoさん

 入れ違いました。そして、見事に、僕の質問はスルーしてるし。ま、ま。

>ロシアのせいで穀物不足の不安から私もちょっと実験を。
 農業新聞には、肥料が90%アップとありました。ますます、色々値上がりするのでしょうね。少々長期的に。
 お米だけ(これもきっと高くなるので、その前に)、いくらか多めに買っておいたらいかがですか。パンなどくわん、と。
 僕は、パン食、激減です。
 貯金が目減りしてるんだなぁ、とか考えてる自分がキライです。

 僕の近くには、農業系(自然農系)の人がそこそこいて、「そらみたことか」とか言ってますね。慣行農法は、やっぱり長期的にみて持続可能ではないですからね。ほんとかな?

 でも、食料もエネルギー(トラクターなど)も肥料も輸入じゃ、食糧安全保障政策に大きな欠陥があるとは言えると思いますね。
 自民党が農村に支えられていた。農村も自民党に頼った。僕ら都会人は農家の仕事を高く評価しなかった(野菜が安すぎた)。ま、ニッポン人です。パイが小さくなり、人口が減少し、円安になれば、ますます自民党が強くなるのでしょう。
 落ちるところまで落ちよ。(c)坂口安吾&宮台真司

 そして、この危機的状況で、防衛費は増えまくる。ああ。

 で、実験って何ですか?

>WinME とか、DOS7 のVZ環境をお持ちの文太さんにお願いがあります。
>是非 [ESC]I の挙動を試してほしいのです。お暇なときにでも。m(__)m

 何も考えなくていいから、このデータでこのマクロで、この処理やって、と仰ってくだされば、やりますが、あまり意味ないと思いますよ。話が高度すぎてついていけてませんから。
 VTDOSとかXPのとか、の話じゃなさそうなんだろうな、とも空想していますが。
 はい、先ほど、ちゃんとVTDOS、落ちてくれました。やっぱ落ちる。キライ。

[4763] 夜中にふと

文太 2022/06/12(Sun) 01:57
[4762]へのコメント


>VTDOSとかXPのとか、の話じゃなさそうなんだろうな、とも空想していますが。
 この環境依存だとしたら……、という発想なのですが、条件を見定めるしかなくて、VTDOSもNTVDMもDOS7も変更とかできないわけですから、

>で、#B のバグは、境界またぎか、ブロック操作時にカーソルポインタの
>計算ミス(条件分岐?)があるのではと想像しています。
 僕もこれに一票です(無責任発言、ごめんなさい)。

 vz.comの問題なら、解決の道がありうる。
 とはいえ、ほんとにvz.comの問題? って、僕には分かりようがありません。

 [ESC]I は、僕のvz.defでは
8 [ESC]I "Insfile" &88

 となっていました。あまり使うマクロですらない感じ。エスキですよね。
 不具合に遭遇してないと(どうも不具合が発現するのもけっこうレアっぽいし)、解決法か回避法かを考えるのは、僕にはムリなんですね。

 もちろん、これをきっかけにして、ということなのだとは理解してるのですが、僕には深すぎます。

[4766] Re^3: macro.asmとか

konno 2022/06/13(Mon) 01:51
[4762]へのコメント
>  入れ違いました。そして、見事に、僕の質問はスルーしてるし。ま、ま。

あ、すみません、私は作者ではないので答えられないなと思って。(^^;

>  Vzのマクロって、あとから付けた、というか、機能を中から引っ張り
> 出してきて、マクロコードでアクセスできるようにしたものですよね?

VZの前身のEZエデイタからVZに進化させるときにマクロを付加したようには見えますね。

>  マクロコードのコマンド・関数・その他って、Vzが内部で持ってる、
> つまりエディタとして機能するのに必要な情報ないし計算式じゃないですか。
> で、これを外からアクセスできるようにマクロインタープリタというのと
> その記号体系(?)とか制御構造(コード)が後から付け加えられたん
> だろうな、と。

これだけの高機能マクロですから、VZを構想した時点で概略は出来ていたのではと思います。
私もエデイタもどきを作っていたのですが、VZを見てから、色々パクらせてもらいました。(^^;

>  お米だけ(これもきっと高くなるので、その前に)、いくらか多めに買っておいたらいかがですか。パンなどくわん、と。

米は100%自給出来ているので心配はしていません。でも米だけでは飽きるのでパンや麺類も食べたいですね。
玉ねぎが高いのは参りましたね。最近少し下がってきたみたいですが。

>  でも、食料もエネルギー(トラクターなど)も肥料も輸入じゃ、食糧安全保障政策に大きな欠陥があるとは言えると思いますね。
基本である食料も自足できない政権には元々期待していませんが、どうしてこんなに駄目なんだろう。
でも以外に自給自足出来ていない国が沢山あるんですね。ビックリです。

>  で、実験って何ですか?

この話は屋敷の板塀に書こうと思っていたので、あちらに書きますね。
最近ご無沙汰なので、話のネタが無いと行きにくくて。(^^;

> >WinME とか、DOS7 のVZ環境をお持ちの文太さんにお願いがあります。
> >是非 [ESC]I の挙動を試してほしいのです。お暇なときにでも。m(__)m
>  何も考えなくていいから、このデータでこのマクロで、この処理やって、と仰ってくだされば、やりますが、あまり意味ないと思いますよ。話が高度すぎてついていけてませんから。

詳細は過去の記事にありますが、データはとしきさんにメールで送ってもらうしかないですねぇ。
WinME とか、DOS7 の安定したVZ環境での結果が知りたいのです。
同じ結果なら、それはそれで納得できます。

>  VTDOSとかXPのとか、の話じゃなさそうなんだろうな、とも空想していますが。
>  はい、先ほど、ちゃんとVTDOS、落ちてくれました。やっぱ落ちる。キライ。

VTDOSはやはり安定性では劣る感じがします。動かないマクロもあるし。
この記事をVTDOSで書いている時にPCが固まって藻屑になってしまいました。
昨日のうちに返信しようと思っていたのですが、脱力してしまいました。(;_;)

[4770] Re^4: macro.asmとか

文太 2022/06/13(Mon) 23:41
[4766]へのコメント
konnoさん

>>で、実験って何ですか?
>この話は屋敷の板塀に書こうと思っていたので、あちらに書きますね。

 お、楽しみ!

 エスキ関連について。

>詳細は過去の記事にありますが、
 これがとても追う気になれないくらい錯綜してるんです。少なくとも、僕にはそう見えています。

>WinME とか、DOS7 の安定したVZ環境での結果が知りたいのです。
>同じ結果なら、それはそれで納得できます。
 何と「同じ結果」なのかすら、わかりません。やめときましょう。
 環境増やすのに反対一票。
 不具合発生条件を確定するため変数を減らすのに賛成一票。

 なんだかソースを眺めてるのが快感になってます。
 きっかけをくれたkonnoさんに感謝。ま、べつに何かの結果が出るわけでもありませんが。頭痛も吐き気ももよおさない。

[4771] Re^4: macro.asmとか

めざら 2022/06/14(Tue) 00:16
[4766]へのコメント http://mezala.la.coocan.jp/
> VZの前身のEZエデイタからVZに進化させるときにマクロを付加したようには見えますね。

『The Computer』誌の1990年1月号(1989年12月発売)に評論家の加藤弘一氏が兵藤氏及び中村社長にインタビューした記事『Top of the project - 電脳時代のヒットメーカー』のなかで,兵藤氏が「VZは発売の直前にマクロの機能をめちゃくちゃ強化したんですが」と述べています。

また,MIFESとの競合において,(多機能なMIFESに最初から組み込まれている)複合的な機能は必要に応じて(マクロで)組み込んでいけばいい,というように機能を増やしてほしいという要望に対応してきた経緯も述べています。

> 私もエデイタもどきを作っていたのですが、

すごすぎ!
わたしも NEC98のN88-Basicを弄っていた時代に,Edlinもどきなラインエディタを作っていたことがありました。あんまり遅いので,すぐに市販のワープロソフトに乗り換えちゃいましたけど。(笑)

ラインバッファ的なメモリからファイルに書き込むときに,いちいち音を出すように組んでいたので,うるさいうるさい。(笑) なんで音なんか出した>自分

> 基本である食料も自足できない政権には元々期待していませんが、どうしてこんなに駄目なんだろう。

農林業の自給率って,そうそう上げられないのでは?
そもそも国土が狭いのに宅地ばかり増やしていたら農地は減りますね。
政党と財界が癒着して国民をとことん貧しくした結果,軍が権力を掌握するに至った過去を考えると,同じ道を辿ろうとしているのでしょうか。
「国を守れ」と声高に言う人は決して最前線には立たないし,そもそも守れと言いながら専守防衛に徹するのではなく先制攻撃にこだわろうとする。つまり外向きに力を向けようとする。兵卒の多くは「名誉の餓死」,銃後の民は雑草を煮て飢えをしのぐ。(当時よりさらに食糧自給できないのにろくに外交しない)


> VTDOSはやはり安定性では劣る感じがします。動かないマクロもあるし。

今の環境でVZが使えるだけでも有難いと思いますよ。
かなり危ないマクロを走らせてません?
エディタのマクロなんだからコマンドを基本にしないと(笑)…(斜め上目線)

[4772] Re^5: macro.asmとか

としき 2022/06/14(Tue) 13:09
[4771]へのコメント http://toshiki.la.coocan.jp/
みなさん、エディタにチャレンジされていたのですね。
私は、8bit時代には、エディタ系には全く興味はありませんでした。
また、16bit時代になって、ものすごく機能の少ないラインエディタのソースを見て、こんなに機能が少なくてもこんなに大きなソースなんだ、と恐れおののいたことはあります。結局、16bitパソコンを購入してわりとすぐに買ったのがVz1.5。

> そもそも国土が狭いのに宅地ばかり増やしていたら農地は減りますね。

私は、宅地や農地の比率がどのくらいかは知りません。
ただ、最近知ったのですが、環境省は国土の3割を保全することを目標としているとのこと。するとかつて、江戸時代までは人力で、明治以降は機械力を使って行ってきた、開拓だとか開墾という手段が実質的に封じられてしまう、と考えられます。となると、とりうる手段としては、宅地住民の密度を上げて土地を捻出する、というあたりでしょうか。食料自給率向上のために住宅高層化推進、という政策が現実味を帯びてきそうです。
というのが冗談でなくなったら怖いのですが、実際に休耕田や休眠農地を何とかするために打ち出したいくつかの政策があまり効果を上げていないのが気になるところ。土地をお持ちの農家だった方々、なぜ他人に耕させるよりは土地を遊ばせておいたほうが良いと考えるのか、これは日本人の国民性なのでしょうか。


> 当時よりさらに食糧自給できないのにろくに外交しない

ここ、重要だと思う。
例えば、日露同盟を結んで北方から食糧やエネルギーを安く豊富に輸入するというアイディア。「貧すれば鈍」かもしれず、「賢者の知恵」かもしれず。

> > VTDOSはやはり安定性では劣る感じがします。動かないマクロもあるし。
> かなり危ないマクロを走らせてません?

あぁそうか、その可能性もあるのか。
であるならば、やっぱりDOSVAX。
あれはAXのエミュレータなので、もしAXで動くマクロであれば、それがどんなに危ないマクロであろうが、DOSVAXの作者にお願いすれば改善が期待できる、はず。

[4775] Re^5: macro.asmとか

konno 2022/06/14(Tue) 20:13
[4771]へのコメント
> 『The Computer』誌の1990年1月号(1989年12月発売)に評論家の加藤弘一氏が兵藤氏及び中村社長にインタビューした記事『Top of the project - 電脳時代のヒットメーカー』のなかで,兵藤氏が「VZは発売の直前にマクロの機能をめちゃくちゃ強化したんですが」と述べています。

そうだったのですね、この発言は、EZエデイタに比べてということなんでしょうか?
VZのマクロ機能を当初の構想より大幅に強化した、と言っているようにも見えたりして。

> わたしも NEC98のN88-Basicを弄っていた時代に,Edlinもどきなラインエディタを作っていたことがありました。あんまり遅いので,すぐに市販のワープロソフトに乗り換えちゃいましたけど。(笑)

ラインエデイタはエデイタの基本、心臓部ですからね。
私も初めはラインエデイタだったのがどんどん拡張して非常に多機能になりました。
言ってみれば、多機能フルスクリーンエデイタもどきです。(^^;

8086 10MHz のPCでBASICインタープリタ(VZマクロと同じ)という環境でしたが
カーソル移動やページ送りは工夫を重ねて爆速に出来ましたよ。

> エディタのマクロなんだからコマンドを基本にしないと(笑)…(斜め上目線)

他の人も言っていますが、常駐コマンドラインでグレップを多用すると落ちやすいですね。
XPのNTVDM のころからコマンドラインの不安定さが言われていたので、同根の問題かも。

[4776] Re^6: macro.asmとか

文太 2022/06/14(Tue) 20:32
[4775]へのコメント
めざらさん

>『The Computer』誌の1990年1月号
>「VZは発売の直前にマクロの機能をめちゃくちゃ強化したんです」
>MIFESと〔違い〕「複合的な機能は必要に応じて(マクロで)組み込んでいけばいい」
(by c.mos)

 めざらさん、ありがとうございます。なんか、とんでもなく、すごく嬉しい。ライバルを意識した設計思想、すばらしいですね! 何だか神様のお言葉みたいに聞こえてきたぞぉ。
 MIFESって、見たことも触ったこともなかった。ありましたね、そういうの。
 でも、過去ログにおいてさえ、MIFESって、ほとんど話題になってなかったみたいな記憶。

 「それなら、マクロでできるでしょう」という伝説的台詞も思い出してしまった。なんだか、いまさら、ふたたび恋におちてるのかもしれません。おじさんの恋。キモイかも。
 なぜこうもかわいいのか?

 断続的ながらもこの気持ちがここまで維持できているのは、WinMEパーツの腐海に生きるという人生の展開にもかかわらず(片付ければいいだけだろうが)、幸福なことだなぁ、としみじみ感じます。調子のいいこと言うつもりもありませんが、「めざら資源」の充実した内容も、僕のこの気持ちと感慨に大きく貢献しております。深く深く感謝します。m(__)m

 なんか、かなり久しぶりにvz.comとかvz.defとかのことを考えたのに、不思議な感覚。
 しかし、ついに黒本が腐海に飲み込まれ、み、見つからん。いえいえ、そのうち、ちゃんと見つけます。

[4782] 『MIFES vs. VZ』

めざら 2022/06/18(Sat) 10:10
[4776]へのコメント http://mezala.la.coocan.jp/
MIFES は職業プログラマが主に使っていたと思われます。会社が買ってくれるから,当時からフリーソフトもあったテキストエディタに五万円も出せたのでしょう。HP200LXの日本語環境におまけで付いていたmini版しか触ったことはないですが,ソースコードの世代管理とかプロファイル管理とかしっかり組み込まれていたのでしょう(…と想像します)。

当時のパソ通層はフリーソフトを使う人が主流で,市販パッケージを扱った非ベンダー系フォーラムは少なかったでしょうから,余計に話題にのぼらなかったのではないかと想像します。MIFES使いを匂わせることがステータスだった面もあったせいで嫌われたなんてこともあったかも。プロの道具だから安定動作に定評があったことは確実だと思いますが,安定は話題にはならないです。

VZは,バグすらも魅力のひとつとして捉えられていた稀有な存在ですね。欠点も長所もたくさんあって,話題性に富んでいた。わたしが一時期よくプレイしていて各種データをまとめているゲームがあるのですが,これもバグが愛されているんです。さいきん現在主流の環境への移植版が出たのですが,愛しいバグが潰されてしまっていて,かつてのプレイ屋をガッカリさせています。関係ないけど。


VZのライバルは mule とか Emacs とかじゃなかったかしら。「環境」だから。
当時の雑誌は『対決!MIFES vs. VZ』とか煽っていたけれど,それぞれのユーザはあまりライバル意識とかしていなかった,…に一票。


> 充実した内容も、僕のこの気持ちと感慨に大きく貢献

その一言をいただけるだけで,しこしこ作った甲斐があったというものです。
ソースも読めない素人なのに背伸びした部分も多々ありますが,とにかく残したいと思ったんですね。心底,愛しているのです。こんなことを言うと,作者は苦笑を通り越して蔑まれるかもしれませんが。(なんせ「過去の仕事」)

[4788] Re: 『MIFES vs. VZ』

文太 2022/06/19(Sun) 00:12
[4782]へのコメント
めざらさん

 MIFES, 5万円ですか。エディタなのに? 松とか一太郎とか桐とかもそんな値段だった記憶。
 ま、経費だとあまり値段は関係なかったのでしょうね。そうなると逆に、自分の使っている道具に愛着はわかないのだろうなぁ。

 「安定は話題にならない」。なるほど。でも、Vzが安定しないから人気を得た、もかなり違うでしょうね。個人の作品ですし、テスターも大半が素人だったでしょうから、それはそれなりにバグとかあったでしょうけど、でも、伝聞情報で聞くところの「あの熱さ」は、不安定だからでは、ナイ ですね。激しく熱くさせるものがあったんでしょうねぇ。というか、間違いなく、あるんだな、これが。

 ユーザにライバル意識はほぼなし。なるほど。個人である作者が組織(ソフトハウス)に挑戦してたのか。5万円 vs 1万円で。
 そういえば、僕はろくに見たこともないけど、mi.defとかも標準添付でしたね。Miyataさんとかがお使いだった? プロのプログラマだったのかな? 僕は、たぶん、Miyataさんに Vz1.5のマニュアルを譲っていただいてると思う。腐海に潜行中ですが。

 『めざら資源』は、ほんとすごいですよ。PK、DCでのあのやり取りから、あれだけの情報をまとめてる。愛だ。好きなことをただただ好きだからという理由でやってるとき、それは労働でも遊びでもない何かをやってる、って感じですよね。
 久しぶりに読むと、いちいち(何度も同じことを)学んでしまってます。
 でも、やっぱりc.mosさんだって、あの集大成には、嬉しくなると思いますよ。一つの文化が生まれ、それが一部とはいえ「残ってる」んですから。
 「マクロ師列伝」は、ちょっとストップがかかっちゃったんですよねぇ。残念。

 これは別にスルーしてもらって構わない話題なのですが、めざらさんは、ソースをいい加減に眺めていい加減なことを言ったりはしない。こう誓ってるでしょうかね。「僕は眺めてますよ〜」と平気で言っちゃうのだけど。ま、言っても言わなくても、別に何の違いもないのでしょうけれど。string.asm: 検索と置換でした。何十回目かの発見でしょうか。

 「#B は追えなかった」とkonnoさんが仰ってましたが、はい、ときどき、このプロシージャ、どこまで続くんじゃいと言いたくなるところもあるんですよね。

[4794] Re: 『MIFES vs. VZ』

としき 2022/06/19(Sun) 15:20
[4782]へのコメント http://toshiki.la.coocan.jp/
> 当時のパソ通層はフリーソフトを使う人が主流

うん、まぁ、そうかもしれません。
でも、Vzに匹敵するような多機能なフリーのエディタって、あまりなかったと思います。う〜ん、SEとかいうのは使ったことがあるかなぁ。これ、画面の色設定が変えられたはず。白黒用とかアンバー用とか。あと、viのクローンはPC-98でも動いていたなぁ。
ただ、やっぱり、市販ワープロが強い状況の中で、単にテキストを打つだけなのに動作がもっさりしたワープロを使うんじゃもったいない、というのは各種パソコン雑誌でもいろいろといわれていたような記憶があります。
かといって、市販エディタはMIFESとVzとREDと、あとは何があったかなぁ。
あぁ、FINALってのがあったな。

> VZのライバルは mule とか Emacs とかじゃなかったかしら。「環境」だから。

その辺なら十分ライバルになりますね。
ただ、MIFESと同じく、それぞれのユーザーが相手をライバル視していたかはわかりません。

[4767] Re^3: macro.asmとか

としき 2022/06/13(Mon) 14:17
[4762]へのコメント http://toshiki.la.coocan.jp/
>  はい、先ほど、ちゃんとVTDOS、落ちてくれました。やっぱ落ちる。

VTDOS、落ちます?
私の使っている(使っていた)のが1.22なんて古いバージョンだからかもしれませんが、ほとんど落ちたことがないんですよ。
昔はWinXPでレジュームするようにしていたマシンを何週間もの間、毎日数時間起動していて、その間ずっとVTDOS立ち上がりっぱなしでしたが、たまに使っても落ちたことはない。当時はHTMLの編集とゲームマクロくらいしか使っていなかったので、そのせいかもしれませんが、でも、テキスト編集にもきちんと使っていたわけで、その不安定さがちょっと不思議。
ホストというか土台のOSとかの環境によるのかなぁ。
やっぱりDOSVAXのほうがいいのかな。

>  僕は、パン食、激減です。

主食の構成比率、私は今のところ、過去数年から変化なし。
そもそもが、閉店間際のスーパーで売れ残って安くなっているものを買っているので、おにぎりが売れ残っていればおにぎり、パンが残っていればパン、麺が残っていれば麺。もちろん、お財布にやさしいという面もありますが、それよりも食品廃棄物の削減に貢献できたというささやかな自己満足感のほうがモチベーションです。愛国者であるところの私としては、こんなに食糧を輸入しているくせに、こんなに廃棄されていることが許せない。

>  貯金が目減りしてるんだなぁ、とか考えてる自分がキライです。

そういうあなたに投資をお勧めしているのが、政府とかいう名の謎の秘密結社。
確かに、よその国に比べて預貯金の比率が突出して高いという事実はあるわけで、そこから無意識に同調圧力を感じているというか空気を読むというか、この辺、いかにも日本人的。
ただ、預貯金というのは金融機関にお金を預けているわけですが、そのお金を金融機関はどうしているかというと、結局のところは投資しているわけです。つまり、実態としては他人に上前をはねられながら投資をしている形なわけで、ならばそういう中間搾取を避けて個々人が自分で投資したほうがいいんじゃないの、という考えは合理的といえば合理的。

> 慣行農法は、やっぱり長期的にみて持続可能ではない

これについては私も同じ意見です。
そして、自然農法も慣行農法も、昔に比べれば進歩していると思う。
例えば「慣行農法は、やっぱり長期的にみて持続可能ではない」ということだって、進歩してきた結果わかってきたことでしょう。あるいは自然農法だって、江戸時代はおおむね自然農法だったと思うけど、そして食糧の輸入はほぼゼロだったわけだけど、それで養える日本の人口は当時の人口ぐらいなわけで、3500万人くらい?
自然農法が進歩した現在、食糧輸入が途絶えた場合、日本はどのくらいを養えるか、ということを考えるのも今の時代には必要かもしれません。おそらく、文太さんのお考えどおり、国民みんなが安くておなかいっぱいになれることでしょう。


> 食料もエネルギー(トラクターなど)も肥料も輸入じゃ、食糧安全保障政策に大きな欠陥があるとは言えると思いますね。

konnoさんもおっしゃっていますが、何でもかんでも自給率の高い国って、実はそんなにない。
ま、欠陥があるのは間違いないでしょうが、欠陥の少ない政策を取ろうとすると、国民が黙っていないとかあるのでしょう。例えば、野菜の価格が2倍、パンの価格が3倍になります、とか。
例えば文太さんのご提案として、食料もエネルギーも肥料も輸入量を減らす算段として、どのようなものをお考えですか?

[4773] Re^4: macro.asmとか

文太 2022/06/14(Tue) 14:30
[4767]へのコメント
としきさん

>でも、テキスト編集にもきちんと使っていたわけで、その不安定さがちょっと不思議。
 たまたま的要素も多いでしょうが、コマンドラインに下りてグレップしまくりとかすると、はい、来ましたね、的に簡単に落ちますよ。
 もういいのだけど。何かの呪いなのでしょうから。

>こんなに食糧を輸入しているくせに、こんなに廃棄されていることが許せない。
 はい、誰に聞いても、個人が個人の生活でそれほど食べられる物を捨てているわけではない、とすぐ気付きます。社会の形なのです。いつでも、どこでも、欲しいもの、食べたいものが買える社会構造が、大量の食品廃棄を生んでいます。この2年のコロナ禍で外食産業が半分くらいストップした。食品ロスがずいぶん減った、と新聞にありました。
 たぶん個人的食品破棄は、そもそも、この手の統計で調査・算入とかされてないんだろうな、と思いました。

>中間搾取を避けて個々人が自分で投資したほうがいいんじゃないの、という考えは合理的といえば合理的。
 合理的ですね。ただ合理が精神と魂を蝕む。僕の魂は蝕む。家計簿はつけるけど、あとは中間搾取にまかせて、忘れてたいの。もっと大事なことがあるだろう、と。

>あるいは自然農法だって、江戸時代はおおむね自然農法だったと思うけど、
 イエス&ノーかなぁ。YouTuber 瀬戸内ファームさんとかは、完全江戸派ですし。ただ、耕さないのが「自然農」だとすると、江戸時代は自然農というより有機農法でしょう。食い物ができれば、僕はどっちでもいい派なのですが。
 ただ、自然農はきっとけっこうきつい文明否定派(人為否定派)だと思うので、きっと発想は革命的で、(違うと思うけど)時代の最先端です。つまり、進歩と成長の神話から自由になっている。たぶん。

>例えば文太さんのご提案として、食料もエネルギーも肥料も輸入量を減らす算段として、どのようなものをお考えですか?

 無理して回答してみると、こんな感じ?
 食料:パスタとかパンとかカタカナのものを食べるのを減らそう。
 エネルギー:洋上風力。みなで扇風機を見直そう。
 肥料:地域ぐるみのコンポスト大作戦。システマティックに雑草も堆肥化しよう! 農家の若返り化の促進。耕作放棄地問題の解消。俺にやらせてくれ〜。ついでに政界の若返り化、促進。国会中継みたいなので、じじいたちの顔を見てると、げんなりする。

 江戸時代に帰ろう、という感じかな。
 寂しすぎなければ、ぼく一人なら、ある程度できそうな気がしてます。

[4774] Re^5: macro.asmとか

としき 2022/06/14(Tue) 15:35
[4773]へのコメント http://toshiki.la.coocan.jp/
> コマンドラインに下りてグレップしまくりとかすると、はい、来ましたね、的に簡単に落ちますよ。

あ、これ、なんか心当たりがある。
grep wgrep findの組み合わせというか実行順で、なんか頻繁に落ちたおぼろげな記憶があるような。そうか、確かに何かこの辺にはあるかもしれない。

>  たぶん個人的食品破棄は、そもそも、この手の統計で調査・算入とかされてないんだろうな、と思いました。

統計における推計・算入も大事ですが、私にとっては、目の前の捨てられようとしている、まだ食べられる食品をきちんと食べてあげることが大事。なので、週に1〜2回は閉店間際のスーパーに通うことをやめないでしょう。そして私はデブになる、早死にする宿命。

>  合理的ですね。ただ合理が精神と魂を蝕む。僕の魂は蝕む。家計簿はつけるけど、あとは中間搾取にまかせて、忘れてたいの。もっと大事なことがあるだろう、と。

家計簿をつけるということそのものが、合理を強制しているのですよ。
なので、家計簿をつけることをやめましょう。
おそらく、貯金が目減りしている、なんてことを考えることから離れることができて、自分を嫌いになることもなくなるはず。

私の場合は逆に、自分が一介の労働者のせいかもしれませんが、他人に搾取されたり他人を搾取したり、ということが、ちょっとばかり嫌い。もっと嫌いなものはいっぱいありますけどね。ピーマンとか。なので、中間搾取を避けられるものならば避けたい、という軽い思いがあります。当然、もっと大事なことはいっぱいありますが、でも、忘れてはいけない、という考え方なのですよ。この辺が、私と文太さんの大きな違いのようですね。

>  ただ、自然農はきっとけっこうきつい文明否定派(人為否定派)

ここはおそらく、私の理解の追いついていないところだと思います。
人為否定派、というキーワードで、少し理解できたかもしれません。
私の今までの考えでは、自然農って、自然を理解しないとできないことだと思っていたのですよ。なので、自然に対する理解が進歩すればするほど自然農も進歩していく、という考え方だったのです。

>  無理して回答してみると、こんな感じ?

いいですね。同意します。
もちろん、こういうことにつまらん突っ込みを入れる人も多いんですけどね。
というか、突っ込みの入れあいというのが議論というものであって、それによっていろんな考えがブラッシュアップされるのかもしれませんけど。
例えば、今、私が無理やり突っ込みを入れようとすると、どういうものが出てくるかなぁ。
この温暖化のご時勢、扇風機だけで何とかなるもんか、とかぐらい?
あるいは、農家の若返りの促進、過去にもやっているはずだけど、それがうまく行っていない原因が分析できているのか、とか。
うん、無理やり考えてこの程度。

[4781] 家計簿

文太 2022/06/18(Sat) 00:38
[4774]へのコメント
としきさん、

 ここに今さらレスをつけるというのも何ですが。
 ちょっと前に書きかけたのだけど、く、くだらんこと書いてると思ったので、手短に大事なことだけ。

>週に1〜2回は閉店間際のスーパーに通うことをやめないでしょう。そして私はデブになる、早死にする宿命。

 前半いい習慣です。でも、後半は?
 ストレス貯めるとムダに食べてしまいませんか。ムダに食料があると無意味に食べてしまいませんか。瞬間的あるいは短期的快楽(安心)を求めて。もちろん、他人のこと言えませんが、野菜作りを始めてから、栄養価の低い食事になっていて、あ、これ少し健康的。健康そうな野菜、ステキ。とかなりますよ。袋栽培近辺の方針は変わらないでしょうけれど、緑はほんとリラックスさせてくれる、ことがある、という体験談。笑っちゃう額しか使ってませんが、家庭菜園に、僕はお金かけても、どうせ黒字になるという算段があるので、理科の実験! とか楽しんじゃってますよ。
 おい、これが大事なことか。

>>合理的ですね。ただ合理が精神と魂を蝕む。
>家計簿をつけるということそのものが、合理を強制しているのですよ。

 ここがいちばん大事。最初は何いってんだか、と思いました。完全に習慣になってるんだ、習慣にしたんだ、と。この反論、無理がある。僕はあの行為がけっして好きではなかった。
 やってみます。良い習慣はなかなか身につかないが、悪い習慣はすぐつく、なんだけど。

>私の場合は逆に、自分が一介の労働者のせいかもしれませんが、他人に搾取されたり他人を搾取したり、ということが、ちょっとばかり嫌い。中間搾取を避けられるものならば避けたい。でも、忘れてはいけない、という考え方なのですよ。この辺が、私と文太さんの大きな違いのようですね。

 僕も労働者のつもりですよ。できたら仕事にそこそこ生きがいとか達成感とか求めたいけど、でも、基本的には時間をお金と交換してるんだよねと考える人です。夢中になると、まあまあ幸せなときもなくはないのだけど。
 で、中間搾取はあまり問題なるほどしてもいないし(たぶん)、大してされてもいないだろうな、というのが冷静な判断です。
 それより家計簿をつけないで、とりあえず3か月やれるか、やってみます。これが挑戦。3か月後に、どんな自分を見るだろう? あれ、やらないほうがいいぞ、やらなくても大丈夫だぞ、となったら、しめたもの。
 お金のことは、3か月間、考えない!

[4793] Re: 家計簿

としき 2022/06/19(Sun) 15:20
[4781]へのコメント http://toshiki.la.coocan.jp/
>  前半いい習慣です。でも、後半は?

捨てられそうな食品を買わずにいられない、そして買ったものは食べずにいられない、ということです。
もしかしたら文太さんにはあまり縁がないかもしれませんが、食べ物は残さず食べる、という習慣がある人ほど健康上の問題を抱えやすい、という統計的な傾向があるのだとか。

>  ストレス貯めるとムダに食べてしまいませんか。ムダに食料があると無意味に食べてしまいませんか。

この部分、前段は自覚はありませんが可能性はあります。
後段は、まさに上記で言っていることと重なりそうです。

>  やってみます。良い習慣はなかなか身につかないが、悪い習慣はすぐつく

ここはねぇ。
私が思っていることがいくつもあって。
以下、つらつらと、ひたすら話題が飛びまくりますが。
私のことなので、例によって無駄に長い文章。

まず、家計簿をつけることを再開する可能性があるのなら、やめる際にはきちんと締めるというか、そのときの残高を保存すること。そうすれば再開したときの残高との差額は容易に確認可能。また、その期間の収入額も、どうせ収入源(給与等の支払い元)の総数は多寡がしれているわけだから追跡も容易。結果、支出の費目は不明なれど、支出総額は算出可能。

次、習慣ということについて。
どんな習慣でもそうかもしれませんが、アメリカの文豪が言ったとされるジョークとして「禁煙は簡単だ」というのがあったかと。なので、その程度にはどんな習慣も簡単、とはいかないか。いや、ジョークですよ。

あと、これは私の偏見かもしれない。
自分だけがおなかいっぱい食べることを考えると、東洋思想だと餓鬼道になるのかな、洋の東西を問わず、おおむね非難の対象。これが、みんながおなかいっぱい食べることを考えると、賞賛されるかどうかは別として、それほど非難はされない。結果的に自分がおなかいっぱい食べられるのにね。
また、自分だけが金持ちになりたい、というような人も非難されるかな。スクルージ氏って、確かそんな感じだったような、知りませんが。キリスト教徒ではないのでクリスマスに縁がありませんし。さてここで、みんながお金持ちになることを考えると、例えば貯金ではなく投資しましょう、といった場合、これは非難の対象か否か。
こういうのと対比して、一部の宗教家は、他者の救済ではなく自分だけの解脱を目指して修行しているにもかかわらず賞賛の対象になることがあるわけで、これはちょっと不思議な気がする。

そして、お金に関しての考え方について。
古典落語や時代劇なんかでは、江戸時代の江戸っ子は「宵越しの銭は〜」みたいなことを言う一方で「ない袖は振れない」なんてことも言うわけで、つまり借金はよしとしない文化があったと推測することが可能。実態はわかりませんけどね。
翻って現代のアメリカ人。経済統計の中で重要視されているのが、個人与信残高。すなわち、アメリカ人が住宅ローンやクレジットカードなどでどれだけ借金をしているか、ということ。また、アメリカは伝統的に貿易は赤字だけど、これは世界中からいろんなものを買いまくっているということを意味しているわけであって、すなわち贅沢をしているということ。時々、貿易赤字を問題視するアメリカの政治家(前大統領とか)がいるけど、その問題の簡単な解決策として、贅沢をやめよう、とは決して自国民に対して言わない。

結局「入るを量って出るを制す」が重要であるなら、残高が常にプラスであれば問題がないわけで、その手段としては家計簿である必要はないはず。この辺、目的と手段の関係かも。
私自身は、小学生のころは小遣い帳をつけていました。
中学生のころかなぁ、金銭出納帳という既成のノートに乗り換えましたが、いつの間にかやめました。
大学時代、車を買うに際して、イニシャルコストは貯金で足りない分は親に出してもらいましたが、維持費は全額アルバイト収入と、月々1万円だったか3万円だったか、親からの小遣い。自宅通学生でしたからね、下宿されることに比べれば、この程度は親も出します。
ところが、大学を卒業するあたりで計算違いがあって。3月までは資金ショートは起こらない、という計算だったんですよ。でも、初任給って、4月1日に入ってくるわけではないんですよね。結果、4月第1週くらいには現金預金の合計が3000円程度にまで落ち込んでしまい、これでは同期入社の連中と飲みに行くこともできない。仕方なく親から1万円くらいだったかなぁ、借りました。もちろん、初任給でスパッと返しましたけどね。

[4761] あ、つまんない(macro.asm 登場)

文太 2022/06/11(Sat) 23:47
[4755]へのコメント
konnoさん、すいませんね、いつものように暴走してしまって。
 ああ、また孤独な独り遊びをしてしまった。
 いえ、konnoさんなら、経験的に知っているだろうと思ったのです。

c:\vzsrc\cmos101
macro.asm  22,836  1989-06-30  10:01
c:\vzsrc\cmos (v1.6の)
macro.asm  42,233  2018-09-27  02:16	;タイムスタンプいんちき
					;4年前に何をしたのだろう?

 オリジナルディスクに、v1.01のソースも入っていたんですかね?
たぶん、そうでしょうね。

 EZからVzになったとき、すでにmacro.asmはあった。
 Vzは、最初っから、完成品として発表されたのでしょう。商品化された
のだしね。「マクロのないエディタなんて」という意図で。きっとプログラマ
としての意地と自尊心もあったでしょう。あっぱれ。しかし、おそらく、
旧8用オンリー。

 &S系関数とかイベントマクロとかマクロバッファのセグメント移動とか
(他はもうほとんど思い出せない)、v1.6でマクロ機能が相当強化されたのは
噂で知ってます。でも、僕が有難がるような「切った貼ったのエディタマクロ」は、
きっと、v.1.01でも書けたのだろう。
 しかし、初版から最終版までで、倍弱の太り方。全国のユーザから支持され、
マクロ師たちもいっぱいいたわけで、そうなりますかね。

 僕は、もちろんv.1.6からのユーザなので、経験としては、それ以前の
ことはいっさい知らないのですが。

[4731] Re^6: ファイル挿入(1) 1.60製品版

としき 2022/05/27(Fri) 17:36
[4729]へのコメント http://toshiki.la.coocan.jp/
遅れましたが、VTDOS1.22での結果です。

> 製品版のVZIBMJ.COMとVZIBMJ.DEFをVZO.*に改名コピーし、さらにEM0と設定

以下略。
結果として、

> WinXP(32)、cmd.exe です。

と同じ挙動となりました。
って、また省略しすぎかな。konnoさんをはじめ各方面に誤解を招くかも。
わからないところがあればご質問ください。

ところで、もしかしたら重要かもしれない事実の開示漏れがありました。
WinXPのCMD窓からcommand.comを起動したときと違い、VTDOS1.22の場合は、自動でVWXが常駐していました。


とりあえず、いまだにテンポラリファイルエラーは見られていません。

[4843] Re^2: ファイル挿入(1) 1.60製品版

としき 2022/06/30(Thu) 01:38
[4712]へのコメント http://toshiki.la.coocan.jp/
> > 各環境における状況をまとめてみたいと思います。
> > このスレッドでは,1.60製品版のcom+defで実行した状況を扱います。

1.60製品版のcom+defで実行した状況の報告です。
おおむね、私の自分の常用環境で実行した結果と同じです。
詳細は省略。
#4700から始まるツリーをお読みください。
今回、画面キャプチャを取って海豹牧場に放流しました。
各画像の左下の部分を比較すると、私のいっている正常・異常がどういうものか、お分かりいただけると思います。

なんとなく、konnoさんのところとは同じ結果になりそうです。
他の人のところで、もし同じ結果にならないとすると、それは何か環境が違うということなんでしょうね。

[4878] Re^2: ファイル挿入(1) 1.60製品版

としき 2022/07/11(Mon) 22:48
[4712]へのコメント http://toshiki.la.coocan.jp/
一体、何が起きたのか分かりません。
実験用のWinXPの環境でのことです。
製品版1.60の実行ファイルにBl8192だけ書き換えた.defファイル、という環境に変化はありません。cmd窓からcommand.comを起動し、それからVz常駐、という手順も同じ。なのに、0007.cgiを開いたところで0007.cgを挿入したら、正常挿入になってしまった。何回試しても正常挿入。
今までにも何回か再起動はかけていますが、安定して異常挿入だったのに。
一体何が起こったのか、さっぱりわかりません。
実は、暑い季節になったので熱暴走予防に、裏蓋を外してほこりを払って、ついでにメモリ(SIMM? DIMM?)の抜き差しをして、ということをやっているのですが、もしほこりの影響があるのだとしたら、涼しい季節に事象が発生していた説明がつかない。メモリの抜き差しの影響で安定したのだとしたら、今までももっとシステム全体の挙動が不安定になっていてもいいはずだけど、そういうことはなかった。
なお、常用環境では相変わらず安定して異常挿入になっています。

[4882] Re^3: ファイル挿入(1) 1.60製品版

としき 2022/07/15(Fri) 17:39
[4878]へのコメント http://toshiki.la.coocan.jp/
> 一体、何が起きたのか分かりません。

何が起きたのか分かりました。

> 製品版1.60の実行ファイルにBl8192だけ書き換えた.defファイル

ではありませんでした。
Blのほかに、ekもプラスに書き換えていました。
普段触らないWinXPのマシンで、しかも数日触っていなくて、久しぶりに触ったときには直前に裏蓋外しなんていう、めったにやらないようなことに手を出したりしていたものですから、最後に触ったときに何かの実験で書き換えたことなんてすっかり忘れていたわけですよ。実際、何を試したかったのか、今では全く思い出せない。
ただ、#4611でめざらさんがご指摘のとおり、ekの値で挙動が変わった。
一周戻ってしまいますが、この問題を回避する一番簡単な方法は、めざらさんにご紹介いただいた挿入マクロを利用するより何より、ek+にすることではないかと思うようになってきました。
ただ、最終的にはそうするでしょうが、もう少し、すなわち本人が飽きるまでは、ek-でこの問題を追及したいな、と。

[4884] Re^4: ファイル挿入(1) 1.60製品版

めざら 2022/07/16(Sat) 14:28
[4882]へのコメント http://mezala.la.coocan.jp/
えーと,混ぜ返すようで申し訳ないですけど,わたしの環境は一貫して ek+ なのですけれど,提供ファイルでは確かに現象が発生していましたよね。

再現条件がさらにいくつかあるのかな……。

大きなファイルで論理行も長いというのは基本だけれど,そのほかにも条件がなにやら有りそうな?

「27932バイトのファイル」の謎が最も興味深い。

[4885] Re^5: ファイル挿入(1) 1.60製品版

konno 2022/07/16(Sat) 16:49
[4884]へのコメント
> えーと,混ぜ返すようで申し訳ないですけど,わたしの環境は一貫して ek+ なのですけれど,提供ファイルでは確かに現象が発生していましたよね。

げげ、Ek- でテストしてもらっているとばかり思いこんでました。(>_<)
どおりで結果に違いがあるわけですね。(^^;

> 再現条件がさらにいくつかあるのかな……。

そうかもしれませんね。
私はソースの Ek- の所だけ追っかけてましたが、見直さなくては。

> 大きなファイルで論理行も長いというのは基本だけれど,そのほかにも条件がなにやら有りそうな?
> 「27932バイトのファイル」の謎が最も興味深い。

これも頭に入れて見直してみます。

[4886] Re^6: ファイル挿入(1) 1.60製品版

めざら 2022/07/16(Sat) 20:52
[4885]へのコメント http://mezala.la.coocan.jp/
言葉足らずですみません。

このツリーにおける実験は製品版の com & def によるものです。
製品版のみならず,それ以前に,としきさんの環境ほど頻繁ではないけれど,わたしの環境でも不具合は確認していました。

[4887] Ek-, ?

文太 2022/07/20(Wed) 11:08
[4885]へのコメント
 なんの整理にも情報の修正にもならないと思いますが。

> #4791 Ek-(追試3) 文太 2022/06/19(Sun) 01:07

 おそらく僕は上のあたりで、不具合再現に初めて成功(!)したはずなのですが、
それ以来、一貫して以下のエスキ・デフファイル(+僕の常用環境、つまり製品版
の使用なし)で実験し結果を報告してきました。常用vz.defでは、ek+ だった
ものですから、あっちこっちでそれを修正すると戻すのが大変になる(ekについて
は忘れることにする)というやり方をしてきました。


org_esci.def  464  2022-06-23  00:41

=== Macrotmp by B ===;c.mos版エスキ
* M
8 @I "I カーソル位置へ挿入"
	?. (mr==$80)?{ &m(36) . }
	ek[-,			;追加

(マクロ本体略)

:Z	&m("") ek], .		;追加
*

 ただいま修羅場な時期なので、その後、この方面の実験はまったくやって
おりませんが、テストをそこそこ集中的にやっていたときには、各種報告のとおり、
かなり安定して(不規則性や不条理性を含む)、不具合は発生してくれていました。

 ek+, で不具合には出会っていないということなのですが、何か別の条件が入ると、
ek+, でも起こるのですかね? ここ、追求・追試の意志はまったくありませんけれど。

[4889] EK+, or EK- ? 15-20.txt

文太 2022/07/27(Wed) 17:55
[4887]へのコメント
 これから大きな発見と展開がなければ、まあ、これでお終いかな、という感触
でおります。

 最後に、0007.cgi + 0007.cg での、EK(#B)の有効範囲(?)をみてみたい
と思います。オリジナル 0007.cgiと、その15、16、17、18、19、20行目まで
のファイルの計7つが対象。これらに 0007.cg を挿入する。
 EK+の場合とEK−の場合の2通り。つまり、14回の実験。(^^;

 もちろん、20行目までのファイルは15から19行の部分も含みます。でも、
出たり出なかったりするのですよねぇ、これが。不条理。

 EK+でも不具合が出てくれると、原因がEK(#B)以外にもあるのだろう、
くらいになるのかな、という仮説、空想。

【結果】--- やばい
		EK-	EK+
0007.cgi	NG	OK
15.txt		OK	OK
16.txt		OK	OK
17.txt		OK	OK
18.txt		OK	OK
19.txt		OK	OK
20.txt		OK	OK


【道具&前準備】

--- 1.bat ---
REM get n-line files (15-20)

sed32 -e "15q"	0007.cgi > 15.org
sed32 -e "16q"	0007.cgi > 16.org
sed32 -e "17q"	0007.cgi > 17.org
sed32 -e "18q"	0007.cgi > 18.org
sed32 -e "19q"	0007.cgi > 19.org
sed32 -e "20q"	0007.cgi > 20.org
-------------

> copy & save & ren *.org *.txt

--- 2.bat ---
REM record line length 1 ; Use after ESCI macro

gawk -f line_len.awk 15.txt > 15.len
gawk -f line_len.awk 16.txt > 16.len
gawk -f line_len.awk 17.txt > 17.len
gawk -f line_len.awk 18.txt > 18.len
gawk -f line_len.awk 19.txt > 19.len
gawk -f line_len.awk 20.txt > 20.len
-------------

--- 3.bat ---
REM get the correct answer file	

cat 0007.cg 15.txt > 15.ans
cat 0007.cg 16.txt > 16.ans
cat 0007.cg 17.txt > 17.ans
cat 0007.cg 18.txt > 18.ans
cat 0007.cg 19.txt > 19.ans
cat 0007.cg 20.txt > 20.ans
-------------

--- 4.bat ---
REM record line length 2 ; Use on ANS file

gawk -f line_len.awk 15.ans > 15a.len
gawk -f line_len.awk 16.ans > 16a.len
gawk -f line_len.awk 17.ans > 17a.len
gawk -f line_len.awk 18.ans > 18a.len
gawk -f line_len.awk 19.ans > 19a.len
gawk -f line_len.awk 20.ans > 20a.len
-------------

--- line_len.awk ---
{ printf("%d	%d\n",NR,(length($0))) }
--------------------

--- 5.bat ---
REM get the difference 1

diff 15.ans 15.txt > 15.dif
diff 16.ans 16.txt > 16.dif
diff 17.ans 17.txt > 17.dif
diff 18.ans 18.txt > 18.dif
diff 19.ans 19.txt > 19.dif
diff 20.ans 20.txt > 20.dif
-------------

--- 6.bat ---
REM get the difference 2 (comp line length if necessary)

diff 15.len 15a.len > 15_.dif
diff 16.len 16a.len > 16_.dif
diff 17.len 17a.len > 17_.dif
diff 18.len 18a.len > 18_.dif
diff 19.len 19a.len > 19_.dif
diff 20.len 20a.len > 20_.dif
-------------


>dir		;最終的な場面。あああううう、いつもの不具合が出ない〜。
		;いままでと違ったのは、WinMEで(こっちのほうがVzは楽)
		;根性をふりしぼってやった点。だってぇ、やる気にならないんだもの。
		;はい、実験失敗ということでした。

0007-I   CGI       302,888  22-06-18  23:00 0007-I.CGI
0007     CG        132,553  22-06-18  23:00 0007.CG
MEMO     TXT         2,554  22-07-27  17:37 MEMO.TXT
ORG_ESCI DEF           464  22-07-27  17:39 ORG_ESCI.DEF
3        BAT           210  22-07-27  16:40 3.BAT
4        BAT           280  22-07-27  16:49 4.BAT
5        BAT           202  22-07-27  17:06 5.bat
15       TXT       175,047  22-07-27  17:39 15.txt
15       ANS       175,047  22-07-27  17:32 15.ans
16       TXT       178,491  22-07-27  17:39 16.txt
16       ANS       178,491  22-07-27  17:32 16.ans
17       TXT       180,127  22-07-27  17:39 17.txt
17       ANS       180,127  22-07-27  17:32 17.ans
18       TXT       181,699  22-07-27  17:40 18.txt
18       ANS       181,699  22-07-27  17:32 18.ans
19       TXT       184,399  22-07-27  17:40 19.txt
19       ANS       184,399  22-07-27  17:32 19.ans
20       TXT       185,410  22-07-27  17:40 20.txt
20       ANS       185,410  22-07-27  17:32 20.ans
15       DIF             0  22-07-27  17:40 15.dif
16       DIF             0  22-07-27  17:40 16.dif
17       DIF             0  22-07-27  17:40 17.dif
18       DIF             0  22-07-27  17:40 18.dif
19       DIF             0  22-07-27  17:40 19.dif
20       DIF             0  22-07-27  17:40 20.dif

[4920] Re^2: ファイル挿入(1) 1.60製品版

としき 2022/08/12(Fri) 19:26
[4712]へのコメント http://toshiki.la.coocan.jp/
直接的には#4888に対するレスのようなものです。
あちらは私の常用環境に対するものなので、製品版の環境での追試を兼ねて、
今後どのようなことをやっていこうか、という宣言のようなものです。
要は、網羅的というか絨毯爆撃というか。
すなわち、結果は表形式にまとめられるだろう、ということです。
以下は、今回改めて追試した結果ですが、結論的には、私の常用環境における
ものとの差異は発生しませんでした。
なお、結果は異常挿入、正常挿入、1バイトずれのそれぞれ略称となっています。


先に開いて   あとから挿入 ファイル
いたファイル するファイル サイズ   Bl
                                   6144 8191 8192 cf.   8193 16384
0007.CGI     0007.CG      132553             異常 #4609
170335       00070033.CG   73620             正常 #4888
             00070034.CG   75539             1バ #4888
             0007-024.CG   72650             正常 #4888
             0007-023.CG   75267             1バ #4888
                                             
0010.CGI     0007.CG      132553             異常 #4780
27981        00070034.CG   75539             正常 #4888
             00070035.CG   77436             1バ #4888
             0007-005.CG  116642             正常 #4888
             0007-004.CG  119396             1バ #4888
                                             
0010-2.CGI   0007.CG      132553             異常 #4840
27932        00070034.CG   75539             正常 
             00070035.CG   77436             1バ
             0007-024.CG   72650             正常 
             0007-023.CG   75267             正常 
             0007-005.CG  116642             正常 
             0007-004.CG  119396             1バ 
                                             
0010-1.CGI   0007.CG      132553             正常 #4840
27931

0011.CGI     0007.CG      132553             異常 #4883
27933        00070034.CG   75539             正常 #4888
             00070035.CG   77436             1バ #4888
             0007-005.CG  116642             正常 #4888
             0007-004.CG  119396             1バ #4888


明日は台風で篭城する羽目になりそうだから、この表の穴埋めがたっぷりできそうです。
 

[4922] Re^3: ファイル挿入(1) 1.60製品版

文太 2022/08/13(Sat) 00:39
[4920]へのコメント
としきさん

 やってるんだろうな、と思ってました。コロナ後遺症はないですか? 完治ですか?
 しかし、これには、……。
 理屈も記号も暗号もよくわかりませんが、あまり頭をつかわなくていい実験(original vz.com / vz.defは、もうダメ)があれば、きちんと指令してさえくれれば、やりますよ。Win9x 環境ならありますよ。要らないだろうけど。
 たぶん、ないよね。
 無視してるって思われるのは心外なので、意味のないこと書きました。

[4924] Re^4: ファイル挿入(1) 1.60製品版

としき 2022/08/13(Sat) 13:42
[4922]へのコメント http://toshiki.la.coocan.jp/
>  コロナ後遺症はないですか? 完治ですか?

一応、完治なんでしょう。
まだ少し咳が残っていますけどね。
会話をしたりとか、食事のときに何か粉っぽいものを吸い込んだりすると出る、というくらいですね。だから、自宅で一人パソコンに向かっているようなときには全く咳もなし。

>  理屈も記号も暗号もよくわかりません

理屈がわからない、というのは、まぁそうかもしれません。
ただ、記号や暗号というのは、逆に私にわからない。
どこがどうわからないか、ということをご指摘いただければ、解説するなりわかりやすく改善するなりいたします。

> (original vz.com / vz.defは、もうダメ)

きちんと追いかけられていませんが、なぜダメか教えていただけます?
あと、konno版Vzとoriginal .defなら可能、とか、逆にoriginal .comと文太常用.defならOK、みたいな話はあります?

[4929] Re^5: ファイル挿入(1) 1.60製品版

文太 2022/08/13(Sat) 18:24
[4924]へのコメント
としきさん

 「いちおうの完治」、おめでとうございます。
 僕の周りでも、息子をはじめ、同僚、姪などなど、けっこうかかってますね。それなりに症状が重い人もけっこういます、いました。

>ただ、記号や暗号というのは、逆に私にわからない。
 ま、あまり気にしないで。1つには話が長すぎて、経緯(全工程の中での現在地点)をおさらいできない、ということです。もちろん、研究や発見には、最初から分かっている「全工程」なんてないはずですけれど。

 根性には敬服いたしております。

>あと、konno版Vzとoriginal .defなら可能、とか、etc etc
 基本的に、文太常用com+def、VC作オリジナルcom+def(超使いづらいからキライ)@WinMEでお願いします。
 ただ、僕が把握できているのは、0007.cgi + 0007.cg だけです。これが、0008*.*になったり、0010*.*になったら、その定義をいちいち伝えてもらわなければなりません。いえ、正直いうと、伝えてほしくはないですね。ごめんなさい。

 #4783から#4792あたりでも、ああ、ここまで細かに情報をもらわなければやれないことを自分はやってる。それ、知ってたのに。嫌だなぁ、と思ってました。復習しろ? 大変すぎますよぉ。

 もちろん、このプロジェクト、としきさんが好きなだけやればいいと、僕は思っています。
 諦めても「よく頑張ったねぇ」と思うだけ。
 でも、基点は、「#4609 ファイルの挿入 2022/02/05(Sat)」 ですよね。半年まえ?
 このスレッドを初めてみたとき、こんなにたくさん読めない〜と思いましたよ。ごめん、今も読んでないけど。

[4931] Re^6: ファイル挿入(1) 1.60製品版

としき 2022/08/13(Sat) 19:14
[4929]へのコメント http://toshiki.la.coocan.jp/
>  ま、あまり気にしないで。1つには話が長すぎて、経緯(全工程の中での現在地点)をおさらいできない、

ん、まぁ、気持ちはわかるというか。
だからあまりそういう粘着性の低い人には関係してほしくなかったりしました。
時間を無駄にしてしまうだけですからね。

>  これが、0008*.*になったり、0010*.*になったら、その定義をいちいち伝えてもらわなければなりません。いえ、正直いうと、伝えてほしくはないですね。ごめんなさい。

ん、まぁ、気持ちはわかるというか。
ちなみに、#4920の表のcf.の欄に書いてある発言を読むと、挿入しようとしているファイルの定義がざっくりわかるかもしれませんが、読みたくなければ読まないでください。

[4934] Re^3: ファイル挿入(1) 1.60製品版

としき 2022/08/14(Sun) 00:16
[4920]へのコメント http://toshiki.la.coocan.jp/
> 明日は台風で篭城する羽目になりそうだから、

篭城はしていたのですが。

> この表の穴埋めがたっぷりできそうです。

さすがに、これだけにかまけているわけにも行かず。
とはいえ、一通り表を埋めることはできました。

さて、結果一覧を出す前に。
今回、手順としては、#4712と同じシーケンスです。
すなわち、CMD.EXEからcommand.comを起動し、それから製品版Vzを起動(常駐)という
手順を踏みました。めざらさんのようにコマンドラインオプションでBlを指定しても
よかったのですが、そうすると私の場合、うっかりオプション指定ミスというのを
やらかす恐れがあるので、いちいち.defファイルを書き換えています。
また.defファイル書き換え後に少なくとも1回、コンソールファイルから[ESC]@でBlの
値を表示させて、書き換えた値が反映されていることを確認しています。
なぜ、こんなことをくどくどと書いたかというと。
うちのWinXPの場合、CMD.EXEから直接Vzを起動すると、EMSが取れません。だけど、
command.comからVzを起動するとEMSが取れます。今回、何回も起動させているうちに
手順を誤ったことがあって、それで気がつきました。
そして、今回の一連の実験では手順を統一するという意味もあって、全て#4712と同じ
手順、すなわちcommand.com経由、つまりEMSが取れる環境で行っています。

ということで、以下、結果です。

先に開いて   あとから挿入 ファイル
いたファイル するファイル サイズ   Bl
                                   6144  8191  8192  8193  16384
0007.CGI     0007.CG      132553   異常  異常  異常  異常  正常
170335       00070033.CG   73620   1バ  正常  正常  正常  正常
             00070034.CG   75539   1バ  1バ  1バ  1バ  正常
             0007-024.CG   72650   1バ  正常  正常  正常  正常
             0007-023.CG   75267   1バ  1バ  1バ  1バ  正常
                          
0010.CGI     0007.CG      132553   正常  異常  異常  異常  異常
27981        00070034.CG   75539   正常  正常  正常  正常  正常
             00070035.CG   77436   正常  1バ  1バ  1バ  正常
             0007-005.CG  116642   正常  正常  正常  正常  1バ
             0007-004.CG  119396   正常  1バ  1バ  1バ  1バ
                          
0010-1.CGI   0007.CG      132553   正常  正常  正常  異常  異常
27931                                                            
                                                                 
0010-2.CGI   0007.CG      132553   正常  正常  異常  異常  異常
27932        00070034.CG   75539   正常  正常  正常  正常  正常
             00070035.CG   77436   正常  正常  1バ  1バ  正常
             0007-024.CG   72650   正常  正常  正常  正常  正常
             0007-023.CG   75267   正常  正常  正常  正常  正常
             0007-005.CG  116642   正常  正常  正常  正常  1バ
             0007-004.CG  119396   正常  1バ  1バ  1バ  1バ
                          
0011.CGI     0007.CG      132553   正常  異常  異常  異常  異常
27933        00070034.CG   75539   正常  正常  正常  正常  正常
             00070035.CG   77436   正常  1バ  1バ  1バ  正常
             0007-005.CG  116642   正常  正常  正常  正常  1バ
             0007-004.CG  119396   正常  1バ  1バ  1バ  1バ

なお、この表はExcelで作ってテキストで出力したあと、整形するに当たりsaki...さん
のcols.defを使わせていただいております。


なんというか、なかなか面白い結果となりました。
特に面白いと思ったのは、あとから0007.CGファイルを読み込ませるとき、先に開いて
いたファイルのサイズとBlの値によって、きれいに挙動が変化する部分。すなわち、
以下のところですね。

先に開いていた  Blの値
ファイルのサイズ 8191  8192  8193  
27931バイト   正常 正常 異常
27932バイト   正常 異常 異常
27933バイト   異常 異常 異常

また、Blを16384まで大きくすれば常に正常挿入になるかと思ったけどそうはならない、
という部分もなかなか興味深いところ。


今回の結果が完全にランダムなら、もはや追跡不可ということであきらめようかとも思い
ましたが、なかなか論理的な挙動を示しているようなので、もう少し追い込んでみたいと
思います。が、さて、どうしたものか。
とりあえず、あとから読み込ませるほうのファイルをいじるときりがなくなるので、
当面は先に開いておくほう、すなわち.cgiファイルとBlの値だけをいじって少し遊んで
みたいと思います。
 

[4995] Re^4: ファイル挿入(1) 1.60製品版

としき 2022/09/02(Fri) 00:36
[4934]へのコメント http://toshiki.la.coocan.jp/
ちょっと間が空いてしまいました。

> なかなか論理的な挙動を示しているようなので、もう少し追い込んでみたい

> 当面は先に開いておくほう、すなわち.cgiファイルとBlの値だけをいじって少し遊んで

遊んでみました。
とりあえず、前回の結果の再掲。

> なんというか、なかなか面白い結果となりました。
> 特に面白いと思ったのは、あとから0007.CGファイルを読み込ませるとき、先に開いて
> いたファイルのサイズとBlの値によって、きれいに挙動が変化する部分。すなわち、
> 以下のところですね。
> 
> 先に開いていた  Blの値
> ファイルのサイズ 8191  8192  8193  
> 27931バイト   正常 正常 異常
> 27932バイト   正常 異常 異常
> 27933バイト   異常 異常 異常

これの続きを試してみました。

先に開いていた  Blの値
ファイルのサイズ 8190  8191  8192  8193  8194
27930バイト                        正常  異常
27931バイト         正常 正常 異常
27932バイト         正常 異常 異常
27933バイト   正常  異常 異常 異常
27934バイト      異常

おぉ、なんと美しい。
ただ、konnoさんの報告から、Blをある程度減らすと、170KBほどある元の0007.CGIでも
OKになってしまうらしい。
つまり、どこかに何らかの不連続点があるらしい。
まずはこの不連続点を追跡してみたいと思います。
 

[4996] Re^5: ファイル挿入(1) 1.60製品版

めざら 2022/09/02(Fri) 10:25
[4995]へのコメント http://mezala.la.coocan.jp/
> おぉ、なんと美しい。

もはや楽しんでいるみたい。(笑)
これ,双方が1バイト単位なので,確かに敷居(意味違)があるように見えますね。

挿入〈される〉側のサイズが影響するって,どうもよくわからない…。
挿入位置って常に先頭なんですよね。どういう理屈だろう…。

2の倍数とかの規則性があれば想像の糸口もありそうだけど,そのような法則は全然ないのにこの規則性。

素数出現の規則性を探究する数学者を尊敬するなぁ。
でも整数って,本当に均等に並んでいるのだろうか。(いや均等)
全音音階とか不協和音を駆使する作曲家って最強ですね。(違)

[4997] EM の値で [ESC]i の挙動が変わる

konno 2022/09/03(Sat) 18:24
[4995]へのコメント
> ただ、konnoさんの報告から、Blをある程度減らすと、170KBほどある元の0007.CGIでも
> OKになってしまうらしい。

これは、Bl1024*2 から Bl1024*5 までは問題が出にくいということですね。
今回、それとは別の話です。繋がっているかもですが。

何気なく、EM1024 を、EM12 とか小さくしてみたら [ESC]i の症状が良くなったみたいです。
それで、EMの値を変えて色々試してみました。

EM1017 を超えるとNG で、EM1010 ならほとんどのVZ環境で問題改善するようです。
今まで同じVTDOSでも私の環境で [ESC]i の挙動が良くなかった原因が分かった気がします。

今までの環境
---------- option.lst --------------------- 2022/09/03 (Sat) 18:01 --------
Bt64 Bf5632 Bo32768 EM1024 XM2000 Bm3108 Ba4 Bl8192

この環境で、Blは 1024*4 か 1024*5 の時だけ正常に動作していたと思います。
今回、EM1010 以下にすると、Bl2048 でも正常に動作しました。

[ESC]i の挙動としては、EM1010 以下なら、ブロックの入れ替えが起こらないようです。
この環境で XM0 にすると、見た目は正常でも途中のデータが壊れるようです。
みなさん意外と EM を大きく取っていないんですかね。
私はこれからは VTDOS では EM1010 でいきます。

[4998] Re: EM の値で [ESC]i の挙動が変わる

めざら 2022/09/04(Sun) 07:43
[4997]へのコメント http://mezala.la.coocan.jp/
残念ながら,こちらの環境では状況に変化はありませんでした。

 Bt64     Bf4096   Bo32768  EM1010   XM0      Bm4108   Ba2      Hs256
 Hf256    Hx128    Ha64     Hw64     Bl2048   Bc1024   Bu64     Bv1024


ところで,今回知ったのが,コマンドラインでの拡張子無指定実行での挙動とか。
以前,VTDOS のウィンドウ内で一度 VZ を終了して,
VZO.COM/VZO.DEF に改名した製品版 VZ を起動する VZO.BAT を実行し
製品版環境における実験をしていた……と思っていたところ……
C\VZ>VZO の実行では VZO.BAT でなく VZO.COM が起動されるということに
突然気づいてしまった。。。 えー?! そうだったけ??

起動時のファイル名入力窓の下に「EMSを最大1024…」と表示され,
「-EM1010」を書き加えた VZO.BAT を実行していないことに気づいた。

……と思ったけれど,先に起動していた個人用 VZ を終了したときには
既に VWX とか常駐しているわけだから,単純に VZO.COM 実行でいいはず。

……なんだ,VZO.BAT を書き換える必要なんてなかったんだ。…なんて
朝からボケボケです。。。朝だからか。。。
そもそも VZO.BAT なんて,どうして作ったのだろう。要らんのに……

ちゃんちゃん。
…というわけで再度ケチロンを。
EM1010 でも,当方の環境ではブロックの入れ替え(もっと激しいけど)は
製品版環境においては依然として発生しています。
なお,自分の常用環境(1.60t03k k07t1)では発生しません。

[5000] Re^2: EM の値で [ESC]i の挙動が変わる

としき 2022/09/04(Sun) 10:21
[4998]へのコメント http://toshiki.la.coocan.jp/
> ところで,今回知ったのが,コマンドラインでの拡張子無指定実行での挙動とか。

むしろ、最近の環境で変わっている可能性はあります。
昔、生DOSのころは、拡張子無指定だと、カレントディレクトリの中の .com → .exe → .bat の順に探していました。そして、カレントに見つからなければ環境変数pathの順に探しに行く、ということだったと思います。ただ、UNIX系のOSだと、まずはじめにカレントを探す、という挙動がないので、私のようなDOS上がりの人間は、まずはpathの先頭にカレントを示す . をつけるというのがおまじない。
もっとも、UNIX系の人の場合でも、カレントがトップという意識はなくても、あのコマンドはどこだっけ、というのはよくある話らしい。なので、toolsにはwhichというコマンドがあります。めざらさんもお持ちだと思いますので、ドキュメントをお読みになれば、OSごとの差異とか、何か参考になることが書いてあるかもしれません。

> 朝からボケボケです。。。朝だからか。。。

私は昨夜がボケボケでした。
土曜出勤だったというのに、3時間も残業をさせられて。
結局、寝落ちでした。

[4999] Re: EM の値で [ESC]i の挙動が変わる

としき 2022/09/04(Sun) 10:03
[4997]へのコメント http://toshiki.la.coocan.jp/
やっぱりEMSも関係するのか。

> みなさん意外と EM を大きく取っていないんですかね。

私の常用環境ではEM128ですね。
Vz1.60製品版では、EMのあとに数字が付いていないけど、これはEM1を意味しているようですね。つまり、残り全部。ただ、うちの環境の設定がそうなっていると思うのですが、WinXPのcommand.comで提供されるEMSの総量が256ページなので、このツリーの実験では一貫して、EMSは246ページです。
一応、#4729でEM0のときの実験はしていますが、EMSを246ページとった場合と結果は同じでしたので、#4715でEMSが関係するかも、と思ったことは一旦棚上げしていました。
そういえば、製品版ではXM0な設定なんですね。せっかくcommand.comで豊富にXMSを提供しているのにもったいない。
WinXPに入っているVTDOS1.22では常用環境のVzしか使ったことがありませんでした。つまり、上記のようにEM128。WinXPのcommand.comでは上記のようにEMSの量が限られる設定になっていましたが、VTDOSのほうでは逆に、EMSは32MBも提供できるのに使っていないという形。さらにいうと、command.comでは豊富に提供しているXMS、なんとVTDOSではシステム側が全く提供していない。あまり使っていない環境とはいえ、そういうことになっているとは知らなかった。


ちょっと思ったこと。
#4777の文太さんの示唆によると、EMS関連とテンポラリファイル関連は密接にかかわっているらしい。ということはやはりこれは、テンポラリファイル関係のルーチンで何かがある気がする。
#4718でめざらさんは論理行とテンポラリファイルの関連性は薄いというお考えを述べられていますが、逆にみんながそう考えて高橋さんをはじめとして見落としたところがあるのではないか、という気もしてきました。
つまり、テンポラリファイルに退避する時は符号付で、戻すときには符号無しで演算しているルーチンがあるのではないか、とか、論理行末の処理がテンポラリファイル処理の前後で異なる、みたいな感じで。

> この環境で XM0 にすると、見た目は正常でも途中のデータが壊れる

テンポラリファイル使用とEMSの使用とXMSの使用で挙動が異なるということは、それぞれを呼んでいるルーチンの側での差異が何かありそうですね。


今後の私の予定。
まずは#4995の続き。具体的には、Blを減らしていき、最初に開いているファイルを大きくしていって、どこで不連続な挙動が発生するかの調査。あわせて、その閾値はEM0でも同じかどうかも確認。
もうひとつ、もともとの0007.CGIで正常挿入と異常挿入になるBlの境界も調査。こちらも、EM0で同じ値かどうかを確認。
ここまでは、時間がかかるかもしれませんが、きっちりやります。
あと、うちの通常の試験環境では上記のとおり、EMS残り全部でも246ページしか確保できていませんが、EMSをもっと豊富に取れる試験環境を用意し、EMSの値による挙動の変化、ということもやりたい気もする。ちょっと無理かな。さらには、EMSとXMSの値の相関の追跡、なんてことは夢のまた夢。だって、command.comのEMSの値の変更の仕方を調べるところからはじめないと。

[5001] Re^2: EM の値で [ESC]i の挙動が変わる

文太 2022/09/05(Mon) 00:54
[4999]へのコメント
テンポラリファイル管理?

黒本 p.77 より

-------------------------------------------------------------------------
■テンポラリファイル
 64KBを超える(黒本、字が間違ってる)大きなファイルを編集する場合は、
メモリには64KB しか読み込まず、その前後を「テンポラリファイル」に出力します。
 Ver1.6では、EMS、XMS、TMPを、一元的に合計16MBまで管理できます。従来
EMSは2MBまでした確保できませんでしたからより大きなファイルを高速に編集
できます。ただし(略)

 編集テキストのテンポラリファイルは、
  XMS -> EMS -> TMP
の順番で使用します。TMPディレクトリに作成されるファイルは「VZTEMP.$$$」
というただ1つのファイルです。
-------------------------------------------------------------------------

 高橋版以降、「ただ1つのファイル」ではないですよね。窓ごと?

 僕が前にこの件で言及したときには、手元に黒本がありませんでした。
 で、そのとき考えたのは、テンプファイルをEMSに作る? という点でした。
ディスクとメモリは管理の仕方が違うだろう、EMSにテンプファイルが作れるのか?
と。でも、そうは書いていない。「VZTEMP.$$$」は「TMPディレクトリ」を使う
ときのみなんだろう。XMS,EMS,TMPと全部使って1つのテンプファイルとかは
あり得ないんだろう(想像)。完全に「一元的」ではないのだろう。
 ほんとにシームレスに、連続で、「一元的に」やれるのかなぁ? 試さないけど。
 しかし、メモリに載った部分の「前後」って。どんな管理をしてるのだろう?
 64KBを超すファイルを5つ読み込んだら、どうなるんだろう? それでも、VZTEMP.$$$
は1つなの? きっとそうなんだろう。かなり特殊な処理なんでしょうね???

 分からない、分からない、と言ってるだけです。
 ほんとDOSの基本からおさらいしています。if errorlevel 253 goto ...
これがマスターできるのに、2時間! 意外に資料がないんですよねぇ。『MS-DOS
エンサイコロピディア』を最初からあたればよかった。

 僕は選択的です。けっきょく一生(残りわずか)DOSでいくのでしょうが、
そこでは選択的でなければ、ぜったいムリ、と悟りました。雑草取りも大変だし。
とほほ。
 あ、ちなみに、興味がおありではないと思いますが(現実的に)、世界には、
やっぱり今もDOS(MS-DOSだけではないけど、それが中心)にこだわり続けている人が
けっこういます。もちろん、レベルは超高いのですが。PCの黄金時代だったんでしょうね。
アマチュアが趣味で手をだせるOSの時代だった。Google のなにやらグループを覗きました。
かつてはYahooにグループがあって、そこではsedについて教えてもらってました。すいません、
英語の世界です。
 今時フロッピーをニョゴニョゴいわせているのは、世界では、僕だけではありません
でした。ちょっと安心しました。


追伸:あまりちゃんと管理していないのですが、僕は VTDOS@Win7 では、なぜか、
EMS 最大 80  ページだそうです。どうせそんなに大きなファイルを編集
しないじゃん、せめて、これぐらいのところで安定してくださいよ!(祈り) 
というところだったのだろうと思います。
 そういえば、最近、落ちてないと思う。そこそこ使ってますけどね?
 というか、ここ3か月ぐらい、むちゃくちゃ使っています。コマンドラインには
あまり降りてないかな。コマンドラインがしがしなのは、WinMEでのことなので
しょう。

追伸2:当然ですが、僕はMS-DOS 6.20 の環境で、DOSの実験を主にしています。
VTDOSには、Vzを【使う】という意味ではすごく大きな問題はないと思いますが
(あるのかな?)、DOSを使うという意味では、違うな、と思う場面が多々
ありました。masm 6.00 がFDからインストールできないとか。「なんでsetup.exe
が仕事しないんだ?」ではなく、「またダメなの?」でした。

[5002] Re^3: EM の値で [ESC]i の挙動が変わる

めざら 2022/09/05(Mon) 11:09
[5001]へのコメント http://mezala.la.coocan.jp/
>  高橋版以降、「ただ1つのファイル」ではないですよね。窓ごと?

です。pq を参照すれば,起動するたびに新規設定されているのが分かります。
場所は,%Windows% の \temp で,ファイル名は〈VZ[num].$$$〉て感じ。
EM や XM を指定していてもファイル名は設定されます。

確かに読み込んだ「前後」って引っかかりますね。
複数のメモリ空間をシームレスに扱うって,要するに「仮想化」でしょ。
それって,VTDOS 等のエミュレータが代行してくれているのでは?
わかんないけど。(笑)

製品版でちゃんとテンポラリファイルが作られるかどうか試したついでに,-EM0 -XM0 の環境(テンポラリファイルがディスク上に作成される状態)で,[ESC]I の実験してみたら,なんと……正常に動作しました。

VZTEMP.$$$ のサイズは 296,904 バイトだった。
170,335 + 132,553 - 296,904 = 5984
わりと細切れで確保されるんだなぁ……

常用環境から -EM0 -XM0 に変更して実験したら……テンポラリファイルのサイズなどは…
170,335 + 132,553 - 466,608 = -163720
おやおや? テンポラリファイルがでかいな……

なんなのだろう,この違いは……

[5003] Re^4: EM の値で [ESC]i の挙動が変わる

文太 2022/09/05(Mon) 15:37
[5002]へのコメント
めざらさん

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

>pq を参照すれば,起動するたびに新規設定されているのが分かります。
 考えてみれば、僕はWindowsになっても、Vzを2つ立ち上げたことがほぼないです。
 マイコンピュータを2つ開けて(イクスプローラを2つ立ち上げて)、ファイルコピーというのは、かなり頻繁に行っていますが。

>場所は,%Windows% の \temp で,ファイル名は〈VZ[num].$$$〉て感じ。
>EM や XM を指定していてもファイル名は設定されます。
 なるほど。多謝。

>確かに読み込んだ「前後」って引っかかりますね。
 すごいですよね。想像を絶します。1つのファイルが2つになり、5つファイルを開ければ10個の部分に分割されて(テンプファイル内)、1つのファイルで大きくカーソルを移動したら、10個のうち2つは書き換えられ、マクロで5つのファイルを(人間的には)同時に編集とかしたら、10個全部ががちゃがちゃがちゃと書き換えられる……。これ、ぜんぶ、VZTEMP.$$$という1つのファイルの中で行われる。考えたことがなかったですね。
 マシン語の世界。

 XMS, EMS, TMPは別々に管理だとすると、たとえば EMS というメモリ上に編集テキストの文字列多数があって、これが、EMSの中でごちゃごちゃ書き換わる、というのなら、まだイメージできるのですが。
 まあ、ハンドルでオープンみたいなことをすれば、ディスクからメモリにどうせ読み込むのだから……。
 でもそうすると、メモリに上げちゃうのだから、ディスク上にテンプファイルを作る意味がなくなり……。

 もしかしたら、EMSをディスクと見立てる方法とかあるのかしら? そうしたら(いぜん超絶ですが)、EMSとTMPにまたがる、巨大VZTEMP.$$$ とかも想像できなくもないですが……。

>製品版でちゃんとテンポラリファイルが作られるかどうか試したついでに,-EM0 -XM0 の環境(テンポラリファイルがディスク上に作成される状態)で,[ESC]I の実験してみたら,なんと……正常に動作しました。
 ってことは、やはり振り出しに戻る的に、EMSがらみ、テンポラリーファイルがらみ、ということなのでしょうか?

 ちょっとずれますが、巨大ファイルのばあい、EMSがあるばあい、テキストバッファは自動的にEMSに取られるのですね。see p.76.

 ありがとうございました。ちょっとした頭の整理でした。

[5005] Re^4: EM の値で [ESC]i の挙動が変わる

konno 2022/09/05(Mon) 18:34
[5002]へのコメント
> 製品版でちゃんとテンポラリファイルが作られるかどうか試したついでに,-EM0 -XM0 の環境(テンポラリファイルがディスク上に作成される状態)で,[ESC]I の実験してみたら,なんと……正常に動作しました。

なんと、XMSもEMSも無い状態で動作するとは思いませんでした!
試しに巨大ログファイルを読ませてみたら
16,761,676 VZTMP.$$$
キッチリ16メガまで取れますね、16メガ以上はエラーになりますが。

ところで、VZ1.57a で試してみると、16メガ以上取れますね。
VZ0002.$$$ 17,235,986
[ESC]I の実験も、Bl1024 でも Bl8192 でも正常処理できました。

VZ1.57a のメモリ管理は完璧のようで、しかも 16メガの制限もありません。
VZ1.6 で、EMSがらみのバグが混入したということでしょうか。
Bl1024*6 〜 Bl1024*8 の間にも地雷がありそうですし。

VZ1.57a のソースを見比べてみましたが、結構違いがあって読めないです。


# この1.57aは城の地下深くから掘り出しました。
  きれいなソースでは、蟲を出さないんです。
  汚れているのは 1.6 なんです。

[5006] Re^4: EM の値で [ESC]i の挙動が変わる

としき 2022/09/05(Mon) 23:11
[5002]へのコメント http://toshiki.la.coocan.jp/
めざらさんの常用環境では、0007.CGIと0007.CGでテンポラリファイルエラーになるんでしたよね。あれ、違ったっけ?

> 常用環境から -EM0 -XM0 に変更して実験したら

このときの結果はどうなったんですか?
テンポラリファイルエラー?
正常挿入?


> 製品版で(略)-EM0 -XM0 の環境(略)正常に動作しました。

#4711では、テンポラリファイルがらみの異常動作でしたよね。
たとえば、めざらさんの環境で、製品版で -EM0 -XM1024 とかやった場合の結果がどうなるか、ちょっと気になる。もしそのときのテンポラリファイルのサイズがゼロであり、かつ、テンポラリファイルエラーも出ないで正常挿入なら、XMS処理は正常だけどEMS処理かテンポラリファイル処理には異常がある、ということになるわけですから。
あるいは、めざらさんの常用環境で -EM0 -XM1024 のときの結果と -EM0 -XM0 のときの結果がどう異なるか、あるいは同じか、というところも興味のあるところです。
差し支えなければ、ぜひ結果をお教えいただければ幸いです。

[5015] Re^5: EM の値で [ESC]i の挙動が変わる

めざら 2022/09/06(Tue) 21:26
[5006]へのコメント http://mezala.la.coocan.jp/
いや,最初,うちの常用環境では不具合は出ませんでした。see #4666
常用環境で製品版 [ESC]I を使用時,正常終了など.

不具合が発生したのは,製品版の com & def + [ESC]I が最初。see #4671

ファイル挿入とは関係がないような場面で,テンポラリファイルエラーとか,ヌルがぞろぞろとか,命令ラップアラウンドで落ちたりとか……。

> このときの結果はどうなったんですか?

書き忘れるくらいですから,正常終了です。

> 製品版で -EM0 -XM1024 とかやった場合の結果

正常終了。メモリ上にすべて読み込まれ,vztemp.$$$ は作成されず。

> 常用環境で -EM0 -XM1024 のときの結果

正常終了。-EM0 -XM0 のときと同じです。

[5018] Re^6: EM の値で [ESC]i の挙動が変わる

としき 2022/09/06(Tue) 23:52
[5015]へのコメント http://toshiki.la.coocan.jp/
> > 製品版で -EM0 -XM1024 とかやった場合の結果
> > 常用環境で -EM0 -XM1024 のときの結果

むぅ。
XMSに退避する場合はテンポラリファイルエラーを含めて異常動作が起こらず、EMSを使う場合、およびテンポラリファイルを使う場合に異常動作が起こる。
なんとなく、被疑範囲は明らかなような気がしてきた。
気のせいかもしれないけど。

[5027] Re^7: EM の値で [ESC]i の挙動が変わる

としき 2022/09/07(Wed) 12:03
[5018]へのコメント http://toshiki.la.coocan.jp/
> XMSに退避する場合はテンポラリファイルエラーを含めて異常動作が起こらず、EMSを使う場合、およびテンポラリファイルを使う場合に異常動作が起こる。
> なんとなく、被疑範囲は明らかなような気がしてきた。

思い出した。
実家のPC-98、XMSを使っているはずだけど異常挿入が発生していたはず。
ぅぉ、全然被疑範囲は明らかではないということ?

[5032] Re: ファイル挿入(1) 1.60製品版

としき 2022/09/07(Wed) 14:45
[4999]へのコメント http://toshiki.la.coocan.jp/
> もうひとつ、もともとの0007.CGIで正常挿入と異常挿入になるBlの境界も調査。こちらも、EM0で同じ値かどうかを確認。

こっちを先にやってみました。
結果。
うちの環境において、Vz1.60製品版の.comと.defの設定だと、Bl5244だと正常挿入、Bl5245だと異常挿入。また、これは、メモリ設定がうちの環境でのデフォルトの場合、すなわち EM246 XM0 と、EM0 XM0 および EM0 XM1024 の3通りのメモリ設定において、上記 Bl の境界は同一でした。
どうやら、この程度のEMS量では、[ESC]i の挙動が変わらない模様。


ということで、次回。

> まずは#4995の続き。具体的には、Blを減らしていき、最初に開いているファイルを大きくしていって、どこで不連続な挙動が発生するかの調査。あわせて、その閾値はEM0でも同じかどうかも確認。

こちらを試してみます。
また絨毯爆撃かなぁ。

[5055] Re^5: ファイル挿入(1) 1.60製品版

としき 2022/09/22(Thu) 10:22
[4995]へのコメント http://toshiki.la.coocan.jp/
> つまり、どこかに何らかの不連続点があるらしい。
> まずはこの不連続点を追跡してみたいと思います。

追跡してみました。

> 先に開いていた  Blの値
> ファイルのサイズ 8190  8191  8192  8193  8194
> 27930バイト                        正常  異常
> 27931バイト         正常 正常 異常
> 27932バイト         正常 異常 異常
> 27933バイト   正常  異常 異常 異常
> 27934バイト      異常

> ただ、konnoさんの報告から、Blをある程度減らすと、170KBほどある元の0007.CGIでも
> OKになってしまうらしい。


これらの状況から、当初、以下のような結果が出ると予想しました。


先に開いていた Blの値         |→ ここから先は未定義領域
ファイルサイズ ........................8192........................
↓                       *          
増                      *           
加          正常領域       *            
                     *             
  27931                *              
                   *               
                  *                
                 *                 
                *                  
               *                   
              *                    
             *                     
             *      異常領域           
             *                     
             *                     
             *                     
             *                     
             *                     

そこで、まず、Blの値、および先に開いていたファイルサイズをそれぞれ2KBずらして
網を張ってみました。結果。

先に開いていた  Blの値
ファイルサイズ  6142  6143  6144  6145  6146
29978バイト   異常          異常
29979バイト                 
29980バイト                 
29981バイト                 
29982バイト   異常          異常

おや、これはいささか想定外。
だって、Blをへらしたのだから、上記の図の境界線、または正常領域に入っている、
と思っていたのですよ。
そこでBl6144のときに、どこまでファイルサイズを小さくすれば正常挿入となるか
追いかけて見ました。すると、29404バイトのファイルなら、正常挿入となりました。
次に、29404バイト前後のファイルでBlの値を様々に変えて試しました。
結果。

先に開いていた  Blの値
ファイルサイズ  6142  6143  6144  6145  6146
29403バイト            正常 正常
29404バイト   正常 正常 正常 正常 正常
29405バイト   異常 異常 異常 異常 異常
29406バイト   異常 異常 異常 異常   
29407バイト         異常      

あらま。これも想定外。
そして、この横一線のスレッショルドと、上記のBl8192付近の斜めの線が交わる、
Bl6720付近における、Blの値とファイルサイズを変化させたときの実験結果が以下。

先に開いていた  Blの値
ファイルサイズ  6717  6718  6719  6720  6721  6722
29401バイト                  正常
29402バイト      正常       正常 異常
29403バイト      正常 正常 正常 異常   
29404バイト   正常 正常 正常 異常      
29405バイト   異常 異常 異常         
29406バイト      異常          異常

おぉう、なんてことだ。
すなわち、結果としては、以下のようになります。

先に開いていた Blの値         |→ ここから先は未定義領域
ファイルサイズ .............6720.......8192........................
↓                       *          
増                      *           
加          正常領域       *            
                     *             
  27931                *              
                   *     異常領域      
                  *                
                 *                 
                *                  
  29404   *****************                   
                                  
                                  


−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−


なるほど、そういうことですか。
ただし、これは、うちの環境での結果。
すなわち、WinXPのcommand.com、Vz1.60製品版の.comと.def、EM246 XM0での結果です。
この環境が変われば、変曲点は変わることでしょう。

この結果から推測できること。
Blが増加することにより、先に開いていたファイルの、正常挿入可能なファイルサイズ
は減少することがわかりました。これはおそらく、Blが増えることで、Blの後ろにある
何かのバッファが圧迫されるとか境界を越えることで、ブロック挿入時の1バイトずれが
発生するのではないか、と思われます。
私にはバッファの並び順はわかりませんが、何がどう並んでいるかがわかれば、追跡
するべき項目は絞られるような気がしてます。確か、めざら資源のどこかのページに
バッファの配置順があったような気もしますので、探してみたいと思います。
 

[5056] Re^6: ファイル挿入(1) 1.60製品版

文太 2022/09/23(Fri) 00:14
[5055]へのコメント
 う、美しい。感動的だ。

 どこかにたどり着けることを、心よりお祈り申し上げております。

 ラインバッファの後ろに何があるか? これは分かりそうな気がする。気がするだけ
かもしれないけど。テキストバッファのようにEMSに行ったりはしないような、気が、
す、る、、、。XMSにも行かない気がする。
 気にしておきます。少ししたら調べてみようとしてみたいと思います。
 もちろん、今までの20年以上のVz人生で、調べたりしたことは一度もないのですが。

 憂鬱な木曜日でした。
 でも、秋だ! コオロギが鳴いている。

[5057] ラインバッファの後ろ

文太 2022/09/23(Fri) 01:12
[5056]へのコメント
Cseg map : 2022/09/23_00:57:22

    0 1 2 3 4 5 6 7 8 9 A B C D E F 
0   SSSSSSSSSSSSSSSFFFFFFFFFFFFFiiii    S システム領域
1   iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii    F ファンクションキー表示文字列
2   iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii    i 内部マクロバッファ
3   iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii    o 外部マクロバッファ
4   iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii    A エイリアス文字列
5   iiiiiiiiiiiiiiiiiiiooooooooooooo    s 文字列バッファ
6   oooooooooooooooooooooooooooooooo    p 作業ファイル名ポインタ
7   oooooooooooooooooooooooooooooooo    U カットバッファ
8   oooooooooooooooooooooooooooooooo    d 表示文字列展開バッファ
9   oooAAsssssssssssssssssssssssssss    F ファイラーワーク構造体
A   ppppppppppppppppppUUUUUUUUUUdddd    O オプション初期化時参照表
B   ddFFFOOOOOOOOOOOOOOOOOOOOOOOOOOO    T テキストワーク
C   OOOOOOOOOOOOOOOTTTTTTTTTTTTTTTTT    & &z用テキストワーク
D   TTTTTTTTTT&&LLLLLLLLLLLLLLLLLLLL    L ラインバッファ(wm+228)
E   LLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLL    - 緩衝領域以降
F   LLLLLLLLLLLL--------------------
    0 1 2 3 4 5 6 7 8 9 A B C D E F 

[ESC]@
wm+228: -10814 54722 D5C2h

>vmap
1728 <--    2  212016  vz 1.60t -z                00 1B 21 29 3F

1728:D5C2

 これより下をdumpしてみたら、何か分かるのでしょうか? 分からないの
でしょうか?

 「緩衝領域以降」って何でしょう?

--- vzibmj.map ---
 0000:D329       csrchr
 0000:D32C       disptext
 0000:D652       dosheight
 0000:D726       getdosloc
-------------------
 これはどの版だか分からないけど、vzibmj.comをアセンブルしたときの
map ファイル。

 これで少し、、、とか思ったけど、com ファイルなのに、segmentをごにゃ
ごにゃしている(たぶんassemblerとかdosとかを騙してる)Vzとしては、
これじゃ、どうにもなりませんか。

 うん、dump。しても分からないのだろうなぁ。

[5061] Re: ラインバッファの後ろ

めざら 2022/09/24(Sat) 17:10
[5057]へのコメント http://mezala.la.coocan.jp/
>  「緩衝領域以降」って何でしょう?

「スタックセグメントマップ」
http://mezala.la.coocan.jp/vz/notes/segmap.html
とかいうページがございまして…(この呼称が正しいのか自信なし)

pq..149(tmpbuf4,256bytes):TMPSZ ラインバッファ溢れ用の緩衝領域
pq..149+256(ソースにも定義なし,258bytes〜): 緩衝領域以降
マクロバッファほかマクロでアクセス可能なワークエリアはスタックセグメントにありますが,このセグメントの終端(上位メモリ)にスーパー堤防ならぬスーパー緩衝があると考えられています。

例えば,各種バッファを目一杯確保した場合,ソースで確認できる終端の緩衝領域(tmpbuf4)の先にも,さらに同等サイズの緩衝領域が確保されています。

tmpbuf4はラインバッファが溢れたときのための緩衝ですが,さらにもう一段階緩衝があるという構造になっているらしいですね。

で,各種バッファを少なめに確保した場合,これらの緩衝の先に一切使用されない領域が残っている場合があります。なので,そういった余っているメモリを含め緩衝領域以降と称しています。

[5062] Re^2: ラインバッファの後ろ

文太 2022/09/24(Sat) 22:46
[5061]へのコメント
めざらさーん!

 す、す、す、素晴らしい! そういえば、ありましたね、この労作。有用に使えた
ことはないのですが。

>wm+228	ラインバッファ(実質的先頭はwm+230)
 ここだけ、とりあえず、引っかかっていました。230!

 さて、それでは、僕も、独自にこいつを検証してみたいと思います。
 csegmap.defというか、その結果がうまく読めないから。
 時間、かかりまーす。
 しかたがない。やる。
 さっきやりはじめたら、vtdos、落ちてくれるし。30分の努力がパー。泣けました。
 でも、やる。
 これのためにアセンブラの勉強をしとるんじゃい。

 で、呼称ですが、高橋さんがスタックセグメントって呼んでたんでしょうか?
 何て呼びばいいのか分からないのですが、スタックって、後ろから入れるもの、
というか、プッシュ・ポップな構造ですよね。で、なんでそう呼ばれるの? 
とは思いました。

 完全なにわか知識ですが、ある種のアセンブラ(DOSプログラミング)の
入門書では、.comファイルではなく.exeファイルをつくります。たぶんこっちの
ほうが「普通」だからでしょう。セグメントが別々なわけです。
 code, data, stack, extraの4つ。で、「push, popはするものだし、別の
プログラムが使うこともあるから、とにかくstackには必要と思われる3倍くらい
のデータ領域を設定しておきなさい」とか書かれています。
 スタックは、もちろん、「First in, Last out」なもの。某書では、50枚の皿を
縦に積み重ねる、レストランのスプリング付きワゴン(棚=スタック)で説明して
いました。「最初に入れたものが取り出せるのは最後な構造」と。(注)

 そうそう。
 スタックバッファ。あるいは「マクロ用配列・スタック領域」、この単語が昨晩
でてきませんでした。テキストスタックじゃないからね。
 テキストスタックは、僕には魔界。それこそ、異セグですよね。

--------------------------------------------------
@BU @Bu @bu @ubufsz @pc..121 
メモリ/バッファサイズ
 Bu pc..121 マクロ用配列・スタック領域
  のサイズ
   (64)[byte]  <64〜>  ubufsz
   pu, スタックで両側から使用する
   256 程度にはしておきたい
     <---- Bu ---->
    | このサイズ |  pu..0 などで上から使用
    pu→        ←sp  プッシュ・ポップで下から使用
--------------------------------------------------

 で、僕にとっての最大の謎は、たしかにコピーなんでしょうが
(0690  ここまでセグメントvzのコピー)、
そんなことをして、どうDOSとうまくやれるのか、ということ。vz.COMです。
 常駐すると、いろんなことを自分でやらなければならないけれど(DOSに任せられない、
DOSが許してくれない)、かなり勝手が(自由が)できるものらしいのですが。

 Ezは分かりませんが、1.01からVzは常駐してました! (ジャンプしすぎかもしれ
ませんが)そして、蛇足というか釈迦説でしょうが、Vz 1.6は、ほんとすごいみたい。
c.mosさん、その後はいい加減だったかもしれないけど(燃え尽きた)、本気で徹底的に
勝負してたんですよ。see 黒本、p.12-13.
 きっとどうしても頭にうかぶWindowsの影と戦いながら。

(注)では、.comファイルで、以下のようなお決まりのやり方をしたら、push/popしたとき
に使われるはずのスタックセグメント的なものはどう自動で作られるのか? assembler の 
"warning: no stack segment" の意味は分かったけど、ぜったい.comファイルの中にスタック
セグメント的領域はあるはずだと思うんですよねぇ???

CODE	SEGMENT
	ASSUME	DS:CODE,CS:CODE,SS:CODE

 そして、many vz....asms の、assume ds:nothing の謎。いつか解けるのだろうか?

 まったく無根拠な想像です。

 code seg (vz seg)    copy →  code seg (vz seg) + data seg 
 dos的にcode segment してる  |        (pq..112/mh;マクロバッファ先頭以降)
 のはこっち。         |   vz内部(本体)で管理されてるのがこっち。
                |
 こちらをc.mosさんは     |   こちらをc.mosさんは
 「コードセグメント」     |   「データセグメント」
  と呼び            |   と呼んだ。

  これで、これら「セグメント」の分離が行われ、Vz 1.6で、マクロバッファが大きくなれた。
  前提は、コピーされる部分は本物より小さく、それは(きっと)マクロにとって必要な部分
であるということ。

 妄想です。しかし、やがて誤りだったと気づくことになっても、仮説は思い浮かんでしまう
ものなのです。それのない真空状態には耐えられない、もの、らしい、です。


-----
Ygrep "tmpbuf4" c:\vzsrc\cmos
c:\vzsrc\cmos\main.asm      438:GDATA tmpbuf4,	dw,	TMPSZ

Ygrep "tmpbuf3" c:\vzsrc\cmos
c:\vzsrc\cmos\filer.asm      106:	extrn	tmpbuf3		:word
c:\vzsrc\cmos\filer.asm     2909:	mov	dx,tmpbuf3

Ygrep "tmpbuf2" c:\vzsrc\cmos
c:\vzsrc\cmos\alias.asm       39:	extrn	tmpbuf2		:word	
c:\vzsrc\cmos\alias.asm      491:	mov	di,tmpbuf2

Ygrep "tmpbuf" c:\vzsrc\cmos
c:\vzsrc\cmos\alias.asm       38:	extrn	tmpbuf		:word	
c:\vzsrc\cmos\alias.asm      434:	mov	di,tmpbuf
-----

 おお、ほんとうに、tmpbuf4は定義だけされていて、使われていない。
 ありがとうございます!

 ふと思ったのは(超妄想です)、最後のあき、スタックとして使われているのかも。
「スタックセグメント」が正しいのかもしれないですね。

[5063] ラインバッファの前

めざら 2022/09/25(Sun) 08:53
[5062]へのコメント http://mezala.la.coocan.jp/
>  ここだけ、とりあえず、引っかかっていました。230!

ラインバッファの実質的先頭が wm+230 というのは,wm+228 に改行(0D0Ah)が置かれているためです。

似たような例として,オープンしたテキストの先頭にカーソルを置いて cp の値を確認すると,2を示します。

想像でしかないですが,論理的に行頭を判断させる場合に,他の行と同じルーチンで判定できるよう最初から仮想的改行を入れてあるのかな?と思っています。

[5065] Re: ラインバッファの前

文太 2022/09/26(Mon) 16:43
[5063]へのコメント
めざらさん

 ありがとうございました。
 これらは(tmpbuf4と違い)いちおう知ってはいたけど、完全に(半分以上?)忘れていた事柄でした。

 「スタックセグメント」なる用語が気になり、過去ログをグレップしたところ、ああ、なるほど(理解半分ですが)という記事を多数、発見しました。めざらさんのお陰です。
 たぶん「スタックセグメント」(SS)という用語は、1.6以前で、どうもラインバッファが独立セグメントと扱われていた時代からのもののようでした。PK 13階の、S.Kin さんの記事とか、時代は違うけど、けっこう参考になります。
 (やれませんが、Vz 1.5x と Vz 1.6 のソースで、セグメントの扱いが変わっているところだけ調べれば、「コードセグメント」と「データセグメント」分離の真実がつかめますね)

 納得したり、自分なりの結論にたどり着いたわけではないけれど。

 けっきょくのところ、僕が「分かんねー」とずっと思っているのは、Vzのセグメントの扱いなんですね。セグメント変数を含め、いろんな有益な発言がありました。dz != ds という榊原さんの発言にも納得。高橋さんの「テキストスタック」についての発言も、(きっと)確かにそうなんでしょう、と。

 自分がなぜとしきさんの「異セグ」という言葉に引っかかったのか。としきさんが「データセグメント」(ラインバッファの後ろの後ろ)を突き抜けて「異セグ」に行っているのだろうか? と言っていたという意図、などなど。

 めざらさんの労作、というか劇作(!)「スタックセグメント・マップ」を眺めていても、すごーく多くのことを思い出しました。多くを、ほんとは5回目なのに初めて、知った、みたく。ありがとうございます。wseg, dseg などなど。
 「でも、やる!」とか力んでいた作業を、どうもやらなくていいような気がしてきて、気が楽になりました。
 ま、先人の作ったもの道具(ばふつあ&エスカルゴ)だけで、ちゃちゃちゃ、なので、時間はかかるけど単純作業だったのですが。あれは、マクロで自動化はできない。

 うん、けっこういろんな単語から、たくさん勉強させてもらってます。
 楽しい!
 明後日、大根の種まきの予定です。すぐ雨ふるし。アシナガバチの巣と格闘すること3日。まだいるの、ごめん、死んで、と。カボチャの受粉ではいっぱいお世話になったのだろうけど。だって、刺されてしまって、そこ、1週間、しこりが残ったままです。激痛だった。ああ、新陳代謝がちゃんと進行してくれない……。この遅延により、長寿を獲得しているのでしょうね。

[5066] Re^2: ラインバッファの前

文太 2022/09/26(Mon) 21:16
[5065]へのコメント
だから?

 だから? と言われるかもしれないし、思われることでしょう。
 僕自身も、だから、何かわかったの? と自分自身に問いたい。

(1)
Ygrep -w -j "ss" c:\vzsrc\157cmos	; -word -ignore case
c:\vzsrc\157cmos\core.asm      129:blod5:	mov	[bp].lbseg,ss		; ##1.5

(2)
Ygrep "lbseg" c:\vzsrc\cmos
c:\vzsrc\cmos\core.asm      129:blod5:	mov	[bp].lbseg,ss		; ##1.5
c:\vzsrc\cmos\vz.inc      846:lbseg		dw	?		; line buffer seg

 ソースをガシガシ読んでいたS.Kinさんが間違えるはずないよな、と思ったのです。
 で、Vz 1.57のソースを「スタックセグメント」(ss, セグメント・レジスタ変数@CPU レベル)
で、グレップしたのが(1)。
 そう、スタッグセグメントが使われている。(注)

 (2)Vz 1.6ではどうなった? lbsegはそのまま? そのままです。そして、やはり「ss」
が使われている。スタックセグメント!

 このソースレベルのセグメント管理については、いぜん、1ミリの進歩もなく、まったく分からない。
『MASM 擬似命令ハンドブック』(ナツメ)で、segment ends, group などみても、よく分かんない、です。

 はっきりしたのは、【あれ】を「スタックセグメント」と呼ぶのは、ほぼ正しいらしい、ということ。
視点によりけり、視座によりけり、ではありますが。
 で、その後、思い出したのは、たしか高橋さんは、あれを"dseg.map"と呼んでたなぁ、ということ。

 あと、にわか勉強によれば、code seg, data seg, extra seg はいくつあってもいい。リンカーにちゃんと
仕事をしてもらえれば。ただし、stack segmentは、必ず1つでなくちゃいけないし、そこに領域は
確保されなくちゃいけない、ということ。.exeモデルの話。cpuレベルで、push/popで使われるので。
(Vzマクロで、ps[, とやったら例の場所=マクロ・スタック/スタック・バッファにデータが保存
されるように)。でも、明示的でなくとも、.comでも、同じことになっていないわけないだろうと想像
しています。4つのセグ全部で64KB以内でなくてはならない、というのが、comモデルの制限。

 (妄想:しかし、ラインバッファをスタックセグメントにとったからといって、別にFirst in, Last out
な形で扱わなくちゃいけないのかなぁ? そうなんだろう、みたいな気がするんだけど、、、。
 しかし、ラインバッファがいちおう1つのセグメントをなすように設計されているとしても、ラインバッファ
って、1行だよねぇ、、、。)
 


(注)僕は、.comにしろ、.exeにしろ、4つのセグメント及びセグメント変数がどう使われるのか
ほぼ分かっていません。DOSレベル。そのうち分かる、、、と、いいな。


 はい、誰にもどんな反応のしようもない、空想と妄想の世界でした。
 もちろん、上の話が、Vz macroからアクセスできる、kz, dz, vz (code_seg)とは違うレベルの
話だという認識はあります。


追記:しつこくて、ぐちゃぐちゃで、申し訳ありません。

C:\>Ygrep "lbseg" c:\vzsrc\cmos
c:\vzsrc\cmos\core.asm      129:blod5:	mov	[bp].lbseg,ss		; ##1.5
c:\vzsrc\cmos\core.asm      240:	mov	[bp].lbseg,ax
c:\vzsrc\cmos\core.asm      652:	mov	ds,[bp].lbseg
c:\vzsrc\cmos\core.asm      701:	mov	ds,[bp].lbseg
c:\vzsrc\cmos\core.asm      823:	mov	ds,[bp].lbseg
c:\vzsrc\cmos\core.asm      858:	movseg	ds,[bp].lbseg
c:\vzsrc\cmos\core.asm     1174:	movseg	ds,[bp].lbseg
c:\vzsrc\cmos\gets.asm      177:	mov	[bp].lbseg,ss
c:\vzsrc\cmos\ledit.asm      103:	mov	ds,[bp].lbseg
c:\vzsrc\cmos\ledit.asm      320:	mov	ds,[bp].lbseg
c:\vzsrc\cmos\macro.asm     2124:	mov	ds,[bp].lbseg
c:\vzsrc\cmos\main.asm     1834:	mov	[bp].lbseg,ax
c:\vzsrc\cmos\memo.asm     1137:	add	[bp].lbseg,ax
c:\vzsrc\cmos\string.asm     1045:	mov	ds,[bp].lbseg
c:\vzsrc\cmos\string.asm     1106:		mov	ds,[bp].lbseg
c:\vzsrc\cmos\view.asm     1135:	movseg	ds,[bp].lbseg
c:\vzsrc\cmos\vz.inc      846:lbseg		dw	?		; line buffer seg

 これが全部です。Vz 1.6に出てくる「lbseg」。
 最初のころ(夏前ぐらい?)、僕が久しぶりに顔を出したとき、konnoさんの「お誘い」(!)で
覗いたのが、core.asm。「Vzのコアって何?」と開けてみた。Vzのコアとは、ラインエディット
のことでした。だから、そこで、名前の由来どおり、ss値がlbsegに入れられるのは、まあ、なんとなく
筋がとおってそう。でも、そのあと、だいたい、「ds」の中です。

 僕の妄想的仮説は、やはりVz seg copy+マクロアクセス可能データの、めざらさんが「スタッグ
セグメント・マップ」と呼んでるところこそが、Vz 1.6で分離された「データセグメント」だ
ということ。当たり前みたいだ。でも、dseg.mapでした。「スタ・セグ・マップ」が間違っていると
言いたいわけじゃないですよ。謂れと根拠がちゃんとあったのですから。

[5068] しつこい追記

文太 2022/09/26(Mon) 23:15
[5066]へのコメント
 「3章で解説した  COM モデルのプログラムでは特にスタック領域について注意
をはらいませんでした。これは COM モデルのプログラムでは、MS-DOS が自動的に
スタック領域を割り当ててくれるからです」
 『はじめて読むMASM』 p.130。

 (章タイトルは、「スタックセグメントの定義」ですから、「スタック領域」
の「領域」に深い意味はありません。スタックセグメントのことです。上の続きが、
「しかし EXE モデルでは、、、」となるわけです)

 SS (Stack Segment Register) って、なんかあまり見ません。 Vzで 
assume ss: code とかもしてません。すると、逆にいけないのかも。
 ほんとに、何も定義しなくても、mov [bp].lbseg, ss なんてしていいみたいです。

 スタックセグメントは、とにかくある、自動的に存在する、セグメント・レジスタに
ついても自動設定ということですね。蛇足ですが、mov ds,cs はダメです。このために
movseg マクロが、std.inc で定義されているはずです。

-------------------------
【変数定義の一部】 in VZ.INC
bbtm		dw	?		; screen bottom ptr (in buffer)
lbseg		dw	?		; line buffer seg
inbuf		db	?		;
 ※たんなる2バイトの変数です。以下の連中と扱いがぜんぜん違う、と思う。


【comモデルだから、けっきょくcode segmentの一部になるのだけど、内輪での分類として
 以下のように(擬似)「セグメント」は定義される】in VZ.INC

cgroup	group	_work,_data,_base,_code,_exec,_hard,_init,_tail

wseg	macro
_work	segment
	endm

endws	macro
_work	ends
	endm

etc, etc, etc ....
-------------------------

 結局のところ、 CPUがそうみなし、そう操作する COM におけるスタッグ
セグメント(完全DOS管理)を、Vzはいいように使っているだけだろう、
というのが、僕の結論的想像でした。

 ただ、「自動」ったって、サイズという大きな問題があるでしょう、とも思う。
 決まってるんでしょうね。今のところ、このサイズを知らせてくれる情報は見
つからないのですが。かなーりたったころ(3年後)、ああ、あのサイズって
そう決まってたんですか、とかなるのかしらん。
 c.mosさんは、もちろん、これを知っている。

 ほんと、いいように、Vzはスタッグセグメントを一時的「作業領域」として
使っているように見えました。

 というわけで、つまらないことにこだわって申し訳ないのですが、S.Kin さん
の一行にもかかわらず、あのマップを「スタックセグメント・マップ」と
いうのは、あまり正確ではないのかもしれません。
 「データセグメント・マップ」で、c.mos さんも高橋さんも文句はないと思います。
 すると、csegmap.defも、dsegmap.defのほうがいいのかもしれません。

[5070] Vz 1.56

文太 2022/09/29(Thu) 00:58
[5068]へのコメント

 別スレッドにするような話でもないので、ここに。

 うーん、ま、そんなものを手に入れました。
 いろんな人がいろんなお土産をくれるものです。ありがたや、ありがたや。ありがとうございます!

macro.doc 12,862 1990-12-07 01:56

 なんてのが入っていました。
 こんなことが書かれていました。

-------------------------------------------------
#3 VZの未来
 VZに未来はあるか?
##3.1 正規表現
 そんなむずかしいの、わかんなーい。
##3.2 マウス対応
 Turboにゃ負けられん。でもサイズが・・。
##3.3 Windowsへ
 でも、所詮98じゃ、まともに動かんでしょう。
-------------------------------------------------
 (アウトライン・マクロに関して。OLって言ってた、笑い)

 本当にプログラマって(フリーランスならなおさら)、常に自分のスキルアップと世の中の動き、IT技術の進歩を見つめていなくちゃいけないんですね。
 正規表現エンジンをアセンブラで書くのは、ねぇ、、、。wingさんがいて、本当によかった。

 プロ級の人たち(マクロ師)がVzを離れていったのにも、合点がいきました。
 さすがに、VzのためにDOSマシンが作れるようになったぞ、と喜ぶ人もいない。

 日本における各種プラットフォーム(マシン)への、Vzの対応の歴史とかちらっとみて(NEC98とMS-DOSV 6.2とWindowsしか知りませぬ)、c.mosさんの営業努力みたいなものもひしひしと感じてしまいました。


 ちょうど、_Assembly Language Step-by-Step_の著者、Jeff Duntemannさんのブログとかを読んでいたら、1995年ごろに、やばい! 時代はGUIだ、というので、雑誌の主軸を根本的に移した、なんて話を読んだところでした。_PC Technique_から_Visual Developer Magazine_へ。The Coriolis Groupの創始者です。
 ちなみに、_Assembly Language Step-by-Step_は、DOSを完全に捨てたLinux版の3版が2009年に出版されたみたいです。さすがに買いませんが、いい本です。

[5071] Re: Vz 1.56

konno 2022/10/01(Sat) 00:19
[5070]へのコメント
タイトルがらみで書いてしまいますが
私の手持ちの VZ1.5 は、どうやら 1.57 のようでした。
VZ157.DOC の中に

《VZ Ver1.57(92/1/8版)》
《VZ Ver1.57a(92/2/20版)》

こうあって、私のは、 Ver1.57(92/1/8版) のようです。
古いPCには 1.57a が入っていると思うのですが、未だに発掘できていません。

この Ver は、MSDOS Player で表示の不具合があるのです。
ソースからアセンブルすると

2022/09/27 15:47 47,276 vzibmj.com

このサイズになるのですが、これって、1.57 か 1.57a どっちでしょうか。
もしも 1.57 だとしたら、1.57a をお持ちの方にお願いがあります。
1.57a の差分ファイルをください。m(__)m

[5072] Re^2: Vz 1.56

文太 2022/10/01(Sat) 00:59
[5071]へのコメント
 僕には、konnoさんのご希望には添えないようでした。
 手元の、大昔に宮田さんがご恵贈くださったマニュアルは、「Version1.5」と
表紙にあり、今回入手した版は、以下です。

==============================================================================
	VZ Editor Version 1.56  Copyright (C) 1989 by c.mos
			README.DOC
==============================================================================

readme.doc  59,344  1990-12-07  01:56
vz.com      46,580  1990-12-07  01:56 (NEC 98)

 マニュアル(水色本)は明らかに市販品、たぶん、上のファイルも市販品なのだと思う
(こまごまオンラインで ver up があったんでしょうね)。
 整合したのだろうと思っています。(\usはなし、ただし\ibmはあり)

 僕は、個人的には、vz.asms (総称)とか vz.com に関してすごいコレクターになりたい
という希望は持っていません。今回は、ああ、そう展開したんだ、という偶然です。
NEC98機は手放したし、98エミュレータを動かす予定もないので。

 c.mos版、高橋版、konno版のソースで、勝負する、という所存。
 May the source be with you!

 ただ、BasicとかPascalとかCとか?ASMとかを(abandonwares)、このところコレクション
しているので(古書やもぐらソースを含め)、ヴィンテージとかついてやたら高くなければ、
必要なものが必要な人のところに届くという超法規的な姿勢もいいんじゃないかな、と思って
います。
 もうこれらに市場価値はないので、そんなバカみたいに法律(著作権)に縛られなくても、
いいんじゃないか、という感じでいます。
 僕らは趣味でやってるだけなのです。誰の商売の邪魔をするつもりはありません、とか。

 文学屋なので、作家はくえれば、作品の市場価値とか関係ないし、という世界に生きている人
なのです。
 「なぜか金が少し余っている。そうか、お前はお金が足りないのか。なのに、こんなにすげえ
文章で俺を感動させてくれたわけか。じゃ、お金でいいなら、持っていってくれよ」みたいな感覚
で生きています。

 FlaboとかFdeviceとかFgalel(?)とか、ねこさんが活躍していた(S.Kinさんがねこさんのお世話
になった?)アセンブラ系のniftyログとかライブラリ資産とかは、欲しいなぁ、と思っています。
とりわけ正規表現系のアセンブラないしCのソース。
 高度なアセンブラ本には、ちゃんと「マッチング」という章があったりするのですが。
 nifty終末期に、もっと積極的にコレクションしておくべきだったなぁ、とは思ってます。

 もう日本語はどうでもいいや、という姿勢(konnoさんの若かりし頃の姿勢?)になってますので、
英語文献だけでいいや、と思っているのです。
 日本語化は、そのあと、自分でやる! ウソです。
 面倒くせえ、2バイト文字。SJIS。

 10年ぶりにDOS/V系の欲しかったものが、手に入りました。あとはハードの問題だけ(決定的
に重い)。鯖さんあたりの話です。

[5074] Re^2: Vz 1.57

shadow 2022/10/01(Sat) 13:53
[5071]へのコメント
> 2022/09/27 15:47 47,276 vzibmj.com
Ver1.57ですね。

以下のバージョンを1.57→1.57aにアップデートするための差分ファイルを送ります

VZJ31 COM 47956 92-01-08 1:57 : J3100版
VZJ31L COM 47358 92-01-08 1:57 : J3100スリム版
VZIBM COM 46226 92-01-08 1:57 : AX版
VZIBM COM 47012 92-01-08 1:57 : DOS/V版
VZIBMJ COM 47276 92-01-08 1:57 : DOS/V(JP)版
VZUS COM 45628 92-01-08 1:57 : US版

※ 98版、PS/55版には、Ver1.57a へのアップデートはありません。

[5058] Re^6: ファイル挿入(1) 1.60製品版

konno 2022/09/23(Fri) 01:35
[5055]へのコメント
> 先に開いていた  Blの値
> ファイルサイズ  6717 6718 6719 6720 6721 6722
> 29401バイト                  正常
> 29402バイト      正常       正常 異常
> 29403バイト      正常 正常 正常 異常   
> 29404バイト   正常 正常 正常 異常      
> 29405バイト   異常 異常 異常         
> 29406バイト      異常          異常

これは素晴らしい! 見事です。

ファイルサイズ 29404 は EMS 2ページ分ですね。
16k=32768
でもこのサイズではテンポラリは作られるのかな?
32768 は、$8000 正負の反転のバグがありそうですね。

[5067] 29404バイトの境界?

konno 2022/09/26(Mon) 23:12
[5058]へのコメント
このファイルサイズ 29404 というのは、
170,335bytes の 0007.cgi の先頭から 29404bytes のデータですよね。
私もこのファイルでテストしてみました。

VZT 高橋版と、修正VZで、29404 に 132,553bytes の 0007.cg を挿入

Bl8192 と Bl6720 の時、         VZT  修正版
29404 オープン時に ただちに挿入    異常  正常
29404 オープン時に ^QC ^QR 実施後挿入 異常  正常

#5053 の修正は効いているようです。

Bl1024*3(3072) の時、          VZT  修正版
29404 オープン時に ただちに挿入    正常  正常
29404 オープン時に ^QC ^QR 実施後挿入 正常  正常

挿入元のファイルサイズが小さいと異常が出ないのかなぁ。

29404バイトの時 vtdos
Bl 6720 異常
Bl 6719 正常
異常と正常の境目は環境が違っても変わらないようですね。
参考になります。

[5059] Re^6: ファイル挿入(1) 1.60製品版

としき 2022/09/23(Fri) 22:49
[5055]へのコメント http://toshiki.la.coocan.jp/
> ただし、これは、うちの環境での結果。
> すなわち、WinXPのcommand.com、Vz1.60製品版の.comと.def、EM246 XM0での結果です。
> この環境が変われば、変曲点は変わることでしょう。

とりあえず、簡単にできるところということで、EM0だけ変えてみた結果。

先に開いていた  Blの値
ファイルサイズ  6717  6718  6719  6720  6721  6722
29401バイト                  正常
29402バイト               正常 異常
29403バイト            正常 異常   
29404バイト   正常 正常 正常 異常      
29405バイト   異常 異常 異常         
29406バイト                    

少なくともうちの環境においては、EMSの値には影響されない模様。


> 私にはバッファの並び順はわかりませんが、何がどう並んでいるかがわかれば、追跡
> するべき項目は絞られるような気がしてます。確か、めざら資源のどこかのページに
> バッファの配置順があったような気もしますので、探してみたいと思います。

文太さんにご教示いただいた、緩衝領域。
なんだろう、これ。どういうことなのか。
異セグというか、後ろのほうから前のほうに攻めてくる何かがあるのでしょうか。
いや、だって、緩衝という言葉からイメージするのは、車のエアバッグとか、梱包用の
プチプチとか。
 

[5060] 緩衝領域など

文太 2022/09/24(Sat) 03:04
[5059]へのコメント
としきさ、(以下、戯言です)

>文太さんにご教示いただいた、緩衝領域。
>なんだろう、これ。どういうことなのか。

 これについては、バフツアーと過去ログである程度追えそうだな、とか思っています。

>異セグというか、後ろのほうから前のほうに攻めてくる何かがあるのでしょうか。

 「異セグ」という言葉が、、、。
 まったくの空想、幻想ですが、Vzって、ほんとDOSの仕組みをエミュレート
しようとしてると思ってます。DOSの勉強をすればするほど、おい、またか、と。
それがDOS環境を乗っ取る、DOSそのままになろうとする作戦なのか、と。

 で、comファイルです。DOSの.exeファイル的セグメント管理はできないはずです
(素直にDOSに任せて)。

 ところが、Vzのソースをみて、何をしてるの、これ? と思うのが、movseg。
いろんなセグメントが定義されてる。(注)

 とにかく、DOS的なほんとの「異セグ」はないと思う。
 EMSを、XMSを異セグと呼ぶなら、それは容易にありうるけど、これは実験的に
簡単に殺せます。


 後ろから。
 スタックセグメント的に? 同じパターンがVzにありますね。でも、そこ(ライン
バッファの後ろ)ではないと思う。「テキストスタック」(? ^Y とか ^J とかする
ところではなくて)とか、確か呼ばれてるわりと単純な構造。pu みたいなの。そこじゃないと思う。

 で、今のところの僕の想像としては、「そこは多少壊れても大丈夫なんじゃない」と
いうところです。としきさんが追っかけてる問題に関しては、という意味です。
 壊される可能性が高いから、「緩衝領域」と誰かが呼び始め、そんなつもりでc.mosさんは構造したと。

 もう深いから、あんまり希望をもって、としきさんのようには、探求できないのが
残念で申し訳ないです。
 もしかしたら(残念なことに確率高し)、としきさんの問題意識と勘の方向がまったく
分かっていないのかもしれません。申し訳ないことです。

 ただ、情けないよなと、傲慢にも思ってるのは、XMSとEMSは別としても、ラインバッファの仕組みがソース的にいまだ追えてないのが、おいおい、何年Vzやってんだよ、という
ことです。

 僕は、DOS的にはあくまで com モデルなのだけど、でも上の「コードセグメント」と「データセグメント」は、exe モデルのそれではないのだろう、と想像しています。
 いつか、このことについて確信をもって事実を知れたらいいなぁ、と夢見てます。

 僕がとりあえず信じているのは、ラインバッファも緩衝領域も、code segment と
定義されている、けっこう近いところにある、ということです。後ろから、も、たぶん、
ない。


(注)「Vz 1.6においては、コードセグメントとデータセグメントを分離したため、より広いマクロバッファが確保できるようになりました」by c.mos。
 これ、そのまま、DOS的「コードセグメント」と「データセグメント」とは考えられないですよね。だって、com モデルなのだもの。
 高橋さんが、えむしさんに、意味深なことを書いてたのだけど、、、。

(注2)どこの注にもなっていませんが。
 今日、「Vz 1.6は、Vz最後でしかも最大のヴァージョンアップです」(黒本、p.3)という言葉に衝撃を受けました。1.6 以前については、ほぼ何も知らないのですが、ほんとに
そうだったんだろうな、と思いました。

 プログラマーって、しんどい職業ですね。
 ある種の芸術家なのでしょう。

[5064] Re^6: ファイル挿入(1) 1.60製品版

としき 2022/09/26(Mon) 01:27
[5055]へのコメント http://toshiki.la.coocan.jp/
ここにつけます。

> 先に開いていた Blの値         |→ ここから先は未定義領域
> ファイルサイズ .............6720.......8192........................
> ↓                       *          
> 増                      *           
> 加          正常領域       *            
>                      *             
>   27931                *              
>                    *     異常領域      
>                   *                
>                  *                 
>                 *                  
>   29404   *****************                   
>                                   
>                                   
> 
> 
> −−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−


Blの大きいほう、未定義なんだから何が起こってもおかしくない、というのは頭では
分かっています。とはいえ、好奇心には勝てず。ついつい、追及してしまいました。
結果。

先に開いていた  Blの値
ファイルサイズ  9985  9986  9987  9988  9989
26134バイト   正常          正常
26135バイト                 
26136バイト         正常 正常 正常
26137バイト      正常 異常 異常 異常  
26138バイト   正常 異常         
26139バイト   異常          異常

ほほう。
つまり、上記の図に加筆すると、以下のようになります。


先に開いていた Blの値         |→ ここから先は未定義領域
ファイルサイズ .............6720.......8192......9987...............


  26136                      **************             
                         *             
↓                       *          
増                      *           
加          正常領域       *            
  27931                 *             
                    *              
                   *     異常領域      
                  *                
                 *                 
                *                  
  29404   *****************                   
                                  
                                  
                                  
                                  
−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−

こんな感じですね。
うぅん、斜めの部分は約3200バイト。
これは一体何を表しているのか。
また、#4840あたりで「異常挿入を起こす最小のファイルサイズ」などというものに
言及していますが、これがまさに、Blと異常挿入を起こすファイルサイズの相関関係
を表しているものだといえると思います。
あとは、Btを変えるとこのグラフがどう変わるかというのも興味がありますが、
さすがにそれを試す元気はない。

う〜ん、他に何か面白い実験はあるかなぁ。
 

[5069] Bl8192 の時の境界?

konno 2022/09/26(Mon) 23:33
[5064]へのコメント
としきさん、またまた興味深い実験を。(^^;

> 先に開いていた  Blの値
> ファイルサイズ  9985 9986 9987 9988 9989
> 26134バイト   正常          正常
> 26135バイト                 
> 26136バイト         正常 正常 正常
> 26137バイト      正常 異常 異常 異常  

これに触発されて、Bl8192 の時の境界を探してみました。

27931バイト 正常
27932バイト 異常

この値も環境によって変わらないような気がします。
バグ修正のヒントになりそうですが、さっぱりわからない。(>_<)


余談ですが、境界が交わる点を探すのは大変ですね。
昔二つの交点を探すのに方程式がわからなくて二分法のプログラムを
ポケコンに入れて探したのを思い出しました。(^^;

↑ このページの先頭