08336/08113 CRG00666
文太 回数の訂正
( 1) 18/10/14 12:22
08305:文太さんへのコメント コメント数：1
個人的環境や使用法に依存する数値なので、どこまで有意味なのか分かりません。
が、正確な数字が出せるときには、出しておいたほうがいいと考え、過去の記載を
「編集・修正」しようとしたのですが、このような形のほうが、記事の有用性は
ともかく、数字が読みやすいと思い、ここにこれを繋げておきます。
文字列を同一文字列で置換すれば、正確な回数が出たのに、といちばん最初に
思ったのに、さぼっていました。
僕のエラーログでの出現回数
Ａ：
'REP MOVSW 命令ラップアラウンド' ７６回
Ｂ：
67 EB 8E C0 58 8B F7 36 8B 3E 40 06 51 56 F3 A5
上記のエラーダンプ、コード列 ４９回
（こちらには、前の僕の記事に誤記があったはずです。ずっと少なく数えていた）
ＢがすべてＡに含まれているのかまでは分かりません。
「ラップアラウンド」以外で、同一のコード列が出力されていた可能性もある
でしょう。
ちょっとしたスクリプトかマクロを書けば、これを調査することは可能ですが、
そもそも上のＡ、Ｂのデータにどれだけの意味があるのか分からないときに、
Ｃのデータを出す行為は不要だろうと考えました。
最初にこの話題をあげたとき、こんなに頻繁に（多数回にわたり）、起こって
いた事象だとは思いませんでした。
ただ、オペレーションのパターンと不具合発現のパターンには、たしかな
手ごたえ、「前にも何度もあった」という感触があったのです。そして、起きたとき、
オペレーションが、ふだんよりずっとシンプルだったのです。それで原因解明が
比較的容易かもしれないと、、、。
ずっと深いですね、きっと。
08337/08113 BQO00549
konno Re: 回数の訂正
( 1) 18/10/14 15:56
08336:文太さんへのコメント コメント数：1
> 僕のエラーログでの出現回数
> 'REP MOVSW 命令ラップアラウンド' ７６回
> ただ、オペレーションのパターンと不具合発現のパターンには、たしかな
> 手ごたえ、「前にも何度もあった」という感触があったのです。そして、起きたとき、
> オペレーションが、ふだんよりずっとシンプルだったのです。それで原因解明が
> 比較的容易かもしれないと、、、。
そのログのVZはずっと K07t1 なんですよね。
原因究明に役立つかもしれませんので、そのエラーログをメールで
送ってくれませんか。
エラーの出たアドレスが手掛かりになるかもしれないからです。
私のログはVZのバージョンがコロコロ変わっているので特定が難しいのです。
今までは特定が無理だと思って諦めていたのです。
08338/08113 CRG00666
文太 Re^2: 回数の訂正
( 1) 18/10/14 17:08
08337:konnoさんへのコメント コメント数：1
送らせていただきました。
１０分ぐらい経って、戻ってきておりませんので、届いているかと
思います。
08339/08113 BQO00549
konno Re^3: 回数の訂正
( 1) 18/10/14 18:33
08338:文太さんへのコメント
> 送らせていただきました。
> １０分ぐらい経って、戻ってきておりませんので、届いているかと
> 思います。
ログいただきました。
VZのどこでエラーが多いかなど色々参考にさせていただきます。
08340/08306 GST01234
10♯ Re: ＳＷの適正値
( 1) 18/10/15 16:00
08306:文太さんへのコメント コメント数：1
僕の設定はSW1でした。
元々SW3で、SW2で運用してた時期もあったようなので、
なんらかの利点があってSW1にしてるのだと思いますが、詳細は覚えていません。
あと、SW0はなんらかの制限があったような気がします。
08341/08306 CRG00666
文太 Re^2: ＳＷの適正値
( 1) 18/10/15 17:34
08340:10♯さんへのコメント
ありがとうございます。
SW0で、やばそうだと感じたら、次はSW1にしたいと思います。
SW0,調子いいみたいですよ（１００％信憑性のない発言）。
ふと。
「なぜそんなに古いソフトを使ってるの？ 新しいのにすれば良いのでは
ないかしら？ そんなに分かりやすく落ち込んで。そのため息、不幸がうつり
そうで嫌よ」
「あのね、１０年かかって英語の通訳になれたんだよ。それを次の日に
英語が敵性語だから、今日からイタリア語の通訳になれって言われている
ようなものなの。無理なんだよ。その古いソフトでなければできないことが
たくさんある。分かんないだろうけど」
（メタファーは適材適所。フィクションです。落ち込んでません。この日
のために、周到にWinMEを準備してきました。ダイジョーブ、マイ・フレンド）
プラットフォームは変更しますが、生涯Ｖｚｅｒです。
気分の悪い思いをさせてしまいました。申し訳ございませんでした。
08342/08314 BQO00549
konno SORT.DEF（高橋版）の問題はここ？
( 1) 18/10/15 23:17
08328:konnoさんへのコメント コメント数：1
SORT.DEF（高橋版）を色々な環境で試してみました。
・MSDOS Player
ソート実行時に固まった。
&t でステップ実行したら固まらずに終了した。
其の後は普通に動くようになった。何で？
・DOS窓VZ
普通に動いた。
ここからは、SCASB_MODE=0 のVTDOS環境です。
・VZS 榊原版VZ
常駐ではソート実行時に固まった。
非常駐では動いた。何で？
・その他のVZは皆駄目でした。
なお、非常駐VZだと、エラーになってもVZが落ちるだけで
VTDOSは動き続けますね。
・SORT.DEF（高橋版）のオプションを変更
; o32+64+512, ;(ec)?o|=2, ;options
o32+64, ;(ec)?o|=2, ;options
こう変更して、バックアップ無しとしたら
普通に動いてしまった。 あれぇ？
マクロの中に
:f &Sc(dx=pq..149,pq) &Sy(dx) &Sc(bx,"sort.$$$$$$")
こういう行があるので、バックアップのファイル名で使用していると
思われるが、どうも何かがおかしい。
それで、その後にあるマシン語を逆汗したら
sub_1 proc near
4E dec si
4E dec si
8B 0C mov cx,[si]
4E dec si
2B F1 sub si,cx
3B F7 cmp si,di
74 07 je loc_ret_5 ; Jump if equal
56 push si
51 push cx
E8 FFF0 call sub_1 ; ★★ (014E)
59 pop cx
5A pop dx
loc_ret_5: ; xref 7810:0157
C3 retn
sub_1 endp
こういうサブルーチンがあるんですが、この中で
E8 FFF0 call sub_1 ; ★★ (014E)
この行、自分自身を呼び出していますよね。
これ、条件次第では無限ループになってしまうのではないでしょうか。
上記の実験で固まったときは、Ctrl+Breck も効かないので
ここで無限ループになってしまったのではないでしょうか。
もしかして、これを直せたら、SORT.DEF（高橋版）の問題は解決してしまうかも。
なお、動いたと言ってもソートが正常に出来ているかはわかりません。
08343/08314 CXB00940
としき Re: SORT.DEF（高橋版）の問題はここ？
( 1) 18/10/16 00:19
08342:konnoさんへのコメント コメント数：2
参照先：http://toshiki.la.coocan.jp/
> この行、自分自身を呼び出していますよね。
sortで自分自身の呼出しと言ったら、普通、再帰だと思います。
高橋さんなら、当然、quick sortを使っていそうだし。
あと、cxもdxもdiも変えずにsiだけを変えているように見えますから、
いつかどこかで止まるような気はします。
以上、勘だけでものを言ってみました。
08344/08314 GST01234
10♯ Re^2: SORT.DEF（高橋版）の問題はここ？
( 1) 18/10/16 00:48
08343:としきさんへのコメント コメント数：1
※一回編集しています
この部分のコードを見る限りは、ある内容のバイト列とそれの2バイトの長さから成る表を逆向きにスキャンしているようですね。
これは再帰呼び出しである必要は無いように見えますけど再帰呼び出しにしている理由が分りません。
あと、終了条件が後方スキャンしてるsiのdiに対する一致なので何を出力してるのか不明です。
スキャンしてる表に問題があれば固まるので、固まるか固まらないかだけのルーチンになってるように見えます。
率直に言うと意味が分らないので不可解なコードではあります。
クイックソートのようには見えないかな？
08345/08314 BQO00549
konno Re^2: SORT.DEF（高橋版）の問題はここ？
( 1) 18/10/16 01:19
08343:としきさんへのコメント コメント数：1
> sortで自分自身の呼出しと言ったら、普通、再帰だと思います。
> 高橋さんなら、当然、quick sortを使っていそうだし。
ソートルーチンならそうでしょうが、これはバックアップのルーチンなんですよ。
バックアップのルーチンには2か所マシン語ルーチンがあり、これは後半のものです。
省略したサブルーチンの上の部分をアップします。マシン語では一繋がりです。
0100 start:
0100 8B 36 01AC mov si,ds:data_2e ; (7810:01AC=0)
0104 8E 1E 01AA mov ds,ds:data_1e ; (7810:01AA=0)
0108 33 ED xor bp,bp ; Zero register
010A 32 C0 xor al,al ; Zero register
010C loc_1: ; xref 7810:0119
010C 4E dec si
010D 4E dec si
010E 8B 0C mov cx,[si]
0110 03 E9 add bp,cx
0112 4E dec si
0113 88 04 mov [si],al
0115 2B F1 sub si,cx
0117 3B F2 cmp si,dx
0119 75 F1 jne loc_1 ; Jump if not equal
011B loc_2: ; xref 7810:0138
011B 8B D6 mov dx,si
011D loc_3: ; xref 7810:0120
011D AC lodsb ; String [si] to al
011E 0A C0 or al,al ; Zero ?
0120 75 FB jnz loc_3 ; Jump if not zero
0122 C6 44 FF 01 mov byte ptr [si-1],1
0126 8B CE mov cx,si
0128 49 dec cx
0129 2B CA sub cx,dx
012B B4 40 mov ah,40h ; '@'
012D CD 21 int 21h ; DOS Services ah=function 40h
; write file cx=bytes, to ds:dx
012F 72 1C jc loc_ret_4 ; Jump if carry Set
0131 46 inc si
0132 46 inc si
0133 36: 3B 36 01AC cmp si,ss:data_2e ; (7810:01AC=0)
0138 75 E1 jne loc_2 ; Jump if not equal
013A 16 push ss
013B 1F pop ds
013C 55 push bp
013D B4 01 mov ah,1
013F 50 push ax
0140 8B D4 mov dx,sp
0142 42 inc dx
0143 33 C9 xor cx,cx ; Zero register
0145 B1 03 mov cl,3
0147 B4 40 mov ah,40h ; '@'
0149 CD 21 int 21h ; DOS Services ah=function 40h
; write file cx=bytes, to ds:dx
014B 58 pop ax
014C 58 pop ax
014D loc_ret_4: ; xref 7810:012F
014D C3 retn
バックアップファイルの書き込みルーチンのようですが、くだんの
サブルーチンへは飛んでいませんね。 あれぇ？？？
もしかしてあのサブルーチンはデコイか盲腸か？
バルタン星人はトラップ大統領だった・・・
> あと、cxもdxもdiも変えずにsiだけを変えているように見えますから、
> いつかどこかで止まるような気はします。
なるほど、止まるまでに６４K回ループしてしまうんですね。（違うと思う）
08346/08314 BQO00549
konno Re^3: SORT.DEF（高橋版）の問題はここ？
( 1) 18/10/16 02:10
08344:10♯さんへのコメント コメント数：1
10#さん、#8345 に書いたように、このサブルーチンは使われていないようです。
でも、もし使ったとしたら
56 push si
51 push cx
E8 FFF0 call sub_1 ; ★★ (014E)
ここで、プッシュ2回してループしているので、たとえ一回のループで抜けた
としても、プッシュポップの辻褄が合わなくてハングアップしてしまうような
気がします。
とりあえず、バックアップオプションを使わなければ動作するようですが
できれば不具合の原因を突き止めたいものですね。
08347/08314 GST01234
10♯ Re^4: SORT.DEF（高橋版）の問題はここ？
( 1) 18/10/16 03:07
08346:konnoさんへのコメント コメント数：2
> 56 push si
> 51 push cx
> E8 FFF0 call sub_1 ; ★★ (014E)
>
> ここで、プッシュ2回してループしているので、たとえ一回のループで抜けた
> としても、プッシュポップの辻褄が合わなくてハングアップしてしまうような
> 気がします。
最早どうでもいいようなミクロな話ですけど、push/popの数が一致してて
且つ、終了条件にヒットすればpopしたsi→dxの内容が使われることは無いので、
この手続きの中では問題にはなりませんね。
しかし、このマクロもマシン語コードもVZのワークを多々直接参照してるようなので、
コワいことやってるなーって素朴な印象です。
p*系の変数からオフセット足したアドレスを参照してたりとか…
マシン語コードのSSの参照先とか、waのオフセット13とかがワークのどれを見てるとか分りますか？
あと、pfにprをコピーしてたりとかしますね。
率直に言ってコワイ。
08348/08314 GST01234
10♯ Re^3: SORT.DEF（高橋版）の問題はここ？
( 1) 18/10/16 09:33
08345:konnoさんへのコメント コメント数：1
<1行目の内容><01h>
<2行目の内容><01h>
...
<最終行の内容><01h>
<各行の合計バイトサイズ>
08349/08314 CRG00666
文太 Re^5: SORT.DEF（高橋版）の問題はここ？
( 1) 18/10/16 18:45
08347:10♯さんへのコメント コメント数：1
＊字句、修正しました
まったく的はずれだったら、どうかお許しください。
僕は、自分が逃げたとはいえ、Ｖｚの脆弱性やvtdosの不具合が少しでもなくなって
くれることをひたすらに願っています。
そして、10#さんは、やっぱりプロ、さすが、と驚嘆しています。背伸びをして申し
あげると、少し勉強になってもいます。
>マシン語コードのSSの参照先とか、waのオフセット13とかがワークのどれを見てるとか分りますか？
>あと、pfにprをコピーしてたりとかしますね。
>率直に言ってコワイ。
pf[=pr,bl[=kp-k,#N #P #m
(r<0||wa..13+v<bl+v) bl],pf],?{ #C r+,>e} ;<v>僕、読んでませーん。
;変数調べただけ m(__)m
この件なのですが、間違っているかもしれませんが、内部ワークを「参照」するのは、ほぼ公認です。
ちゃんと書き戻せば、いっときの書き換えもＯＫ。
バグさえなければ、コードセグメントだって、commnad.comの常駐部だって書き換えて「ＤＯＳを
騙す」（意味がちゃんと分かってません）ことも、Ｖｚマクロはできます。
pfにprをコピーはマクロ初心者でも、仕組みが分かればやります。
ps[=pa, nantoka syori ps],
（バッファすり替え＝検索バッファにゴミを残さない）は、この手のことの最初の一歩で（おそらく）、
ポインタの知識のある人なら、Ｖｚマクロを始めて１週間としなくても、なるほど、と使う技です。
pf（#Nするので、ファイル名ヒストリーバッファに）にゴミを残さないためにpr（リネーム用ワーク）
とすり替えています。
もしpfの内容を何がしかの理由で、prにコピーしたければ、histcopyで&Sh(pr,pf)（length注意）
で、c.mosさんがvz1.6で表に出してくれた関数で、できます。
@wa..13 @wb..13 @tmax
テキスト構造体
dw text buffer end ptr
テキストバッファの終端を示すポインタですね。
ＥＭＳにいることも（＝異セグ）あるのではなかったでしたっけ？
とにかく、wa..13は、テキストバッファを参照して、#Cをしていいか判断しているようです。
ラインバッファなら異セグにいかないので、僕でもワークとして使います。bl（ラインバッファサイズ）、
これがこのマクロのワークだとドックにありますね。
これを眺めてみてください。
http://mezala.la.coocan.jp/vz/notes/segmap.html
Text record（オープンファイルごとに。wa..XX） wa..13はここの欄
上のサイトに「内部ワーク」（参照するだけなら僕もする）の地図があります。（先日は、害が
ないので、ファンクションキーラベルを書き換えました。驚いたことに、あの長大なツリーの基点。
見る意味はありません。）ここからテキストバッファでもテキストスタックでもファイラプールでも、
どこでもアクセスできます。普通マシン語を使うでしょうが、セグメントを一瞬変えれば、
. or .. （ポインタ演算子）でも、書き替えられます。
危険な行為かもしれませんが、危険にならないようにプログラムするのが我々の仕事です。
コワクはないですよ、きっと。
SSの参照先は僕も気になりますが、スタックセグメントって、ＤＯＳから見ると、Ｖｚのデータ
セグメントのことではなかったかと思うので、そこでポインタで示された内容（アドレス）の意味
が分かれば、たとえば前回のコード列内の（SS:[0640]）も、どこだか、何を指しているのか、
分かりそうだと思っていました。Ｖｚマクロから見れば、上の「内部ワーク」のことでしょう。
（僕は、SS:[0640]に意味を見出してはいませんが。たとえ意味が分かっても何もできません）
see #08276
3C70:0107 368B3E4006 MOV DI,SS:[0640]
とにかく、sort.def, 逆アセコード内のSSは、vzの挙動を把握しているkonnoさんが調べれば
分かるのか分からないのか、というところなのでしょう。
-------------------------------------------------------------------------------------------
最後に無知な文太が一言：
Ｖｚの世界では、「ローテクはハイテク」という言い回しで表現されてきました。
コマンド・関数・変数としてc.mosさんが表に出してくれたものを、短く賢く使って、マクロを書くのが正道
という意味なのでしょう。と同時に、ローテクは後ろでＶｚ自体が、（いわゆる）ハイテク・Ｖｚコードが、
ガサッガサッと動いて仕事をしてくれていることを意味するので、マシン語が偉いってわけじゃないよ、
という意味だとも僕は解しています。
上のコードをみて、#N #P #m #C（ローテク技）をしているとき、色々やって調べてる（調整してる）な、
と思ったものですから。
だから、すいません、マシン語マクロばかりがコワイわけではありません。普通のマクロもvtdosを
落とせる、と僕は思っています。
ブロックをコピーしただけで、テキストスタック（ＥＭＳ上のあること多し）がガサっと動いて、ＥＭＳ
の窓がこれまた動くのだと思いますので。このとき、マクロバッファもファイラプールも窓移動で、
ガサッガサッと。
分かってない奴の、分かったような、分かんないような、抽象論でした。m(__)m
背伸びはせず、格好つけず、知ったかぶりせず、書いたつもりです。それでも、間違いが含まれている
可能性は、すいません、僕のばあい、いつも、あります。m(__)m
有益なことが言えるとも思えませんので、レス不要ですよ。
08350/08314 GST01234
10♯ Re^6: SORT.DEF（高橋版）の問題はここ？
( 1) 18/10/16 19:11
08349:文太さんへのコメント コメント数：2
c.mos氏はこのdseg内のオフセットを保証しているとは思いますが、
僕のvzでは例えばpcは0111hになってたりとかします。
こういったことは改版の時点で厳密な管理が無いとズレていくものだと思うのですが、
マクロの中の、特にマシン語が直接参照するdsegのアドレスには問題無いのでしょうか？
※追記
あと、VTDOSにはEMSを禁止するオプションもあります。
これはVZにもありますが、問題切り分けには使えます。
08351/08314 CRG00666
文太 Re^7: SORT.DEF（高橋版）の問題はここ？
( 1) 18/10/16 20:53
08350:10♯さんへのコメント コメント数：1
ありがとうございます。
>c.mos氏はこのdseg内のオフセットを保証しているとは思いますが、
>僕のvzでは例えばpcは0111hになってたりとかします。
>こういったことは改版の時点で厳密な管理が無いとズレていくものだと思うのですが、
>マクロの中の、特にマシン語が直接参照するdsegのアドレスには問題無いのでしょうか？
よりによって、僕がこれに何かコメントを返すのは、躊躇われますが、大間違いなこと
を書けば、さすがに、konnoさんが、やんわり修正してくれるでしょう。
はい、「改版の時点で厳密な管理」はされてきたと思います。前に書いた、Ｖｚの伝統
です。めざらさんのセグマップで「絶対アドレス」と書かれてますよね。pcが0111hなのは、
10#さんのところでも僕のところでも、同じはずです。
コードは（残りのぶんだけ）太っていい。でもデータは動かすな、なのかな？
sort.defなどのマクロに関していえば、マクロ語のなかで、ax=pc,のようにすれば、
マシン語ルーチンでもなんら問題ないはずですよね、マシン語で、mov ax,0111とかは
あんまりしないではないのでしょうか。してないのではないでしょうか。この辺は、
分かりません。上のように「厳密な管理がなされている」という前提なら、問題ではない
のだろうとも考えますが。
これが厳格に守られてきたのが「伝統」なのだろうと僕は思っています。
たぶん、間違ってない歴史的エピソード。Win95のころ、Win対応として、ちゅーぱっち
というのが出ました。ＶｚがWin環境で動くようになった（詳細は不明。テンポラリーファイル
の管理、かな？）。しかし、上のdseg内のアドレスへの配慮はなかった。既存マクロが動かない
という大きな問題がniftyで指摘されたようなことはなかったと思いますが、niftyのfgaldcには、
そこの空気があったのです、おそらく。「これでは、既存マクロが動かないよ」、とたぶん、
高橋さんは言った。それで、高橋版ドックの冒頭が、こうなっているのだと思います。（注）
「マクロを作るならば、マクロをよく知っている人の作った Vz がいい」
http://mezala.la.coocan.jp/vz/env/win/win98.html#vzt03k2
高橋版の前の榊原版も、ここは守った。Vzが1.5から1.6になったとき、c.mosさんが、
コードセグメントとデータセブメントの分離という大きな変更をしたにもかかわらず、
1.5マクロが1.6Vzで大混乱しないような配慮をした。これを、踏襲してのことだったと、
僕は理解しています。
おかげで、セグメント変数って、わ、分からない、、、。
前に、konno版に関して、konnoさんの「保守性」（安全第一主義）に関して、「アドレスが
１バイトずれただけで」と書きました。これのことを言っていたつもりです。僕の理解では、、、。
>あと、VTDOSにはEMSを禁止するオプションもあります。
>これはVZにもありますが、問題切り分けには使えます。
「問題の切り分け」ですね。うん、うん、ちょっと分かるぞ、これ。サンクスです。m(__)m
問題は、ＥＭＳのないＶｚを僕がうまく使えないことなんですが、これは僕の問題。ファイラ
などのワークというかバッファをどこまで縮めれば（制限を受け入れれば）、テストができるの
かさえ、うううう。ま、ゆっくりやります。
お教え、ありがとうございます。
（注）ちゅーぱっちをどれくらいの人が使ったのかは分かりません。特定のマクロ、あるいは
もっと広く、ワークを参照するマクロを使わない人には害はなかったはずで、マクロ師、マクロイド、
マニアックなマクロ・ユーザ以外には、ありがたかったのではないかと思います。
08352/08314 GST01234
10♯ Re^8: SORT.DEF（高橋版）の問題はここ？
( 1) 18/10/16 21:14
08351:文太さんへのコメント コメント数：2
僕はワークやバッファ類をどこに置くとかは全く把握してないのであれなんですけど、
なんならXMSを使えば大容量ファイルの置き場にはなったと思います。
（確かEMSに比べて制限は大きかった）
このあたりの、XMSを導入してむにゃむにゃしてる頃に、僕の環境は
EXTTPAのSW1になったようです。
僕文太さんに言われるまでcyupatch使ってましたよ。
絶対アドレスは絶対安全か？
それを盲目的に信じる前提はあるのかも知れませんが、
sort.defは絶対安全という前提があるが故にこれを読まなくて良いかというと、
読まないと切り分けは出来ませんですな。
マクロ師の力を必要としてるのは他ならぬマクロユーザーなのでは？
08353/08314 BQO00549
konno Re^5: SORT.DEF（高橋版）の問題はここ？
( 1) 18/10/16 22:22
08347:10♯さんへのコメント コメント数：1
> マシン語コードのSSの参照先とか、waのオフセット13とかがワークのどれを見てるとか分りますか？
私もよくわかっていないのですが、MAC16.DOC には
■ セグメントの変更
-----------------------------
コードセグメントとデータセグメントを分離したため、マクロでアクセスするワークエリアは、全てスタックセグメントに移動しました。このため、
dz=gz, p=wa+$92, .. dz=cz,
のように、セグメントを変更する必要はありません。
また、このように「dz=cz,」でセグメントを復帰しているマクロとの互換性を考慮して、「cz,dz.gz」はすべてスタックセグメントを指しています。真のコードセグメントの値は、セグメント変数「vz」が示します。
こうあるので、VZのコードはCSEGで、その他はほとんど、SSEG なのだと思います。
今の私の環境では、SORT.DEF のエラーで
2018-10-16 11:38:29 VZIBMJ(17EA) 17EA:14A1 'REPNE SCASB 命令ラップアラウンド'
AX=000A BX=CCDA CX=FFF7 DX=0100 SI=0001 DI=0001 BP=CCDA DS=3E51 ES=3E51 FLAGS=0646
CS:IP=17EA:14A1
17EA:1491 C3 FC 51 57 06 1E 07 8B FE B9 FF FF B0 0A F2 AE
17EA:14A1 8B F7 07 5F 59 C3 B2 00 EB 1F E8 F9 FF 73 03 FF
0000:1492 ENDLIN
SS:SP=274A:CACE
274A:CABE 46 02 4A 27 80 16 EE CB DE 00 FF FF 89 D2 51 3E
274A:CACE 4A 27 9A 7B 7E 1F 8E 14 3D 19 02 00 26 19 ED 16
mg 274a:04d2 マクロエリア
mg 274a:11cf vz.def
mg 274a:6252 sort.def
pu 274a:b0f2 マクロ配列エリア
sp 274a:b1f0 マクロスタック
51F7:06E3 テキストスタック
数値は多少違うものがあるかもですが、マクロのワークは全て SS のセグメント
だと思います。
マクロ内のマシン語も当然そのマクロのアドレスにあるので、その中で動きます。
このマクロでは常に endlin でエラーになっているようですが
ソースでは、
------------------ CORE.ASM
CORE.ASM 258: public toplin,endlin,prelin
CORE.ASM 269:; call endlin
CORE.ASM 277:endlin proc
CORE.ASM 270: call endlin
CORE.ASM 289:endlin endp
CORE.ASM 1149: call endlin
------------------ MEMO.ASM
MEMO.ASM 48: extrn endlin :near
MEMO.ASM 558: call endlin
------------------ TEXT.ASM
TEXT.ASM 75: extrn endlin :near
TEXT.ASM 1033: call endlin
TEXT.ASM 1635: call endlin
TEXT.ASM 2053: call endlin
TEXT.ASM 2079: call endlin
------------------ VIEW.ASM
VIEW.ASM 27: extrn endlin :near
VIEW.ASM 808: call endlin
VIEW.ASM 956: call endlin
でも、マクロのトレースでは、常に
:z ek],&06 &d
この終了処理の、ek], のポッブ実行直後にVTDOSがエラー表示します。
wa..13 は、VZ.INC の中ですが、DSEG.MAP がわかりやすいですね。
;--- Text record --- ;wa,wb,wo,wm,wf
26 tmax dw ? ; text buffer end ptr
これかな。
08354/08314 BQO00549
konno Re^4: SORT.DEF（高橋版）の問題はここ？
( 1) 18/10/16 23:13
08348:10♯さんへのコメント コメント数：1
> <1行目の内容><01h>
> <2行目の内容><01h>
> ...
> <最終行の内容><01h>
> <各行の合計バイトサイズ>
すみません、わからないです。
debug のデータですか？
08355/08314 CRG00666
文太 Re^9: SORT.DEF（高橋版）の問題はここ？
( 1) 18/10/16 23:14
08352:10♯さんへのコメント
うーん、まったく話がどこへ向かっているのか分かりません。
が、分かる範囲で、回答させていただきますね。
>僕文太さんに言われるまでcyupatch使ってましたよ。
すいません、vtdosの作者が、マクロを使われないとは想像していませんでした。
それでも、マクロを積極的に使わなくても、製品版vz.defが標準だと思いますので、多くの
バグが取られているはずの高橋版の流れをくむkonno版が良いと思います。
（余計なことですが、Ｖｚマクロって、マシン語コードを含む含まない以前に、Ｖｚの
一部だと思っています。^KDとか。当たり前すぎますかね。）
>sort.defは絶対安全という前提があるが故にこれを読まなくて良いかというと、
>読まないと切り分けは出来ませんですな。
ここは、まったく分かりません。
僕は、sort.defのユーザではないです。c:\wk\sort.defとどっかで書いたと思いますが、
konnoさんに請われて、ＤＬしました。また絶対安全なマクロだとも思っていません。ただ、
すでにvtdos環境での、Ｖｚの脆弱性を露呈させているのだと、思っています。
それでも、僕が僕の環境で解決できなかった問題は、これとは別だろうと想像しています。
で、撤退しかなかった、という経緯ですが、これ、関係ありませんよね？
この手のことは、多少遅くても、僕は個人的にpsort.exe, sortf.exe, ssort.exeに担当して
もらっています。パラグラフ・ソートは、まだ３回ぐらいしか使ったことがないのですが。
ただ、konnoさんの狙いは、高橋版sort.defを機能するようにする、ということではないの
だろうと想像していました。Ｖｚの弱いところを建て直す、これが狙い、そう思っていました。
>マクロ師の力を必要としてるのは他ならぬマクロユーザーなのでは？
もうどっちも絶滅危惧種ではないのかと思います。
ぼくは、誰にも頼らずにＶｚできると思ってます。仕事の道具なものですから、そうでない
と、それこそやばい、ということになります。そのためのWinMEなんです。
それでも、こんなのプログラミングの論理世界とはなんの関係もないのかもしれませんが、
僕には、おそらく、めざらさん、konnoさん、としきさんが、友人として必要、なん、だろう、と、
思います。あはははは。嘘かほんとか。
もし僕の勧めで、10#さんがcyupatachから高橋版（konno版）に移られたことが問題だったの
だとしたら、すいませんでした。今からでも、戻れば宜しいのではないでしょうか。そんな風に
思いました。
意思疎通、できてないですよね、ここ、きっと。
すいませんが、話の展開の方向がまったく見えておりません。
僕は何も茶化していないし、不真面目でもないつもりなのですが。たんにスキルレベルが2018年の
Ｖｚｅｒとしては低すぎる、ということかと。しかし、これは、僕の人格の一部なので、した選択の
結果なので、本人も諦めております。ご迷惑をお掛けしております。m(__)m
08356/08314 CRG00666
文太 Re^9: SORT.DEF（高橋版）の問題はここ？
( 1) 18/10/16 23:32
08352:10♯さんへのコメント コメント数：1
しつこくて申し訳ありません。これは、僕の独り言です。
コミュニケーションって難しいですね。
全体に、10#さんの独り言だな、と思いました。ですから、この前の僕の投稿みたいに
色々書くことはなかったのだろうと。
>マクロ師の力を必要としてるのは他ならぬマクロユーザーなのでは？
きっとここだけでしょう。
僕個人に関していえば、あるいはsort.def（高橋版）に関していえば、純粋なユーザは
いないように思っております。
レス不要ですよ。
08357/08314 GST01234
10♯ Re^5: SORT.DEF（高橋版）の問題はここ？
( 1) 18/10/16 23:43
08354:konnoさんへのコメント
> すみません、わからないです。
> debug のデータですか？
バックアップの二番目のマシン語の部分のファイル出力がこの形式で出力してるようです、
という覚え書きです。
08358/08314 GST01234
10♯ Re^10: SORT.DEF（高橋版）の問題はここ？
( 1) 18/10/17 00:16
08356:文太さんへのコメント
まあ最早誰もマクロ師を必要とはしていないでしょう。
僕はこのマクロを読むことが出来ないので、マクロ師がいればな、とは思います。
08359/08314 GST01234
10♯ Re^6: SORT.DEF（高橋版）の問題はここ？
( 1) 18/10/17 00:21
08353:konnoさんへのコメント
なるほど。
僕もちょっと見てみた限りではそれらワークのアドレスに問題が無さそうだってことは理解出来ました。
あと、バックアップ部分のマシン語の挙動も大体は把握出来ました。
となると、バックアップのマクロのどこかにトリガーがあるということまでは推測できますね。
08360/08314 BQO00549
konno Re^7: SORT.DEF（高橋版）の問題はここ？
( 1) 18/10/17 01:40
08350:10♯さんへのコメント コメント数：2
> c.mos氏はこのdseg内のオフセットを保証しているとは思いますが、
> 僕のvzでは例えばpcは0111hになってたりとかします。
う、VZK だと1バイトずれていますね。何故だかわからないです。
VZEXもここは同じようにずれていますが、他のワークもずれているようで
動かないマクロがあるようです。
> こういったことは改版の時点で厳密な管理が無いとズレていくものだと思うのですが、
> マクロの中の、特にマシン語が直接参照するdsegのアドレスには問題無いのでしょうか？
相対アドレスで参照するものは大丈夫ですが、私が私家版で使っていた版は
vp がずれてしまっていて、カレンダーマクロで誤動作して気が付いた次第です。
マシン語が直接参照するdsegのアドレスは、絶対アドレスなので、ポインタが
ずれたら即誤動作するので致命的な問題になります。
SORT.DEF もマシン語が直接参照しているようですね。ちょっと読めてないですが
どこかで壊れて、マクロのポップがトリガーになって落ちているように見えますね。
ポップで、sp のポインタが２ずれるんですが、どうもおかしい気がします。
> あと、VTDOSにはEMSを禁止するオプションもあります。
> これはVZにもありますが、問題切り分けには使えます。
ありがとうございます。必要に応じて使わせてもらいます。
08361/08314 CRG00666
文太 Re^8: SORT.DEF（高橋版）の問題はここ？
( 1) 18/10/17 08:29
08360:konnoさんへのコメント コメント数：3
「めざら資源」セグマップ
スタックセグメント概略
絶対アドレス 相対アドレス データ内容
0000 wseg
0110 pc
10#さんwrote:
> c.mos氏はこのdseg内のオフセットを保証しているとは思いますが、
> 僕のvzでは例えばpcは0111hになってたりとかします。
文太wrote:
>めざらさんのセグマップで「絶対アドレス」と書かれてますよね。pcが0111hなのは、
>10#さんのところでも僕のところでも、同じはずです。
0110hと0111hの差について語られていたとは、気づいておりませんでした。
konno版もc.mosオリジナルと同じです、と信じていて、そう伝えたつもりでおりました。
ここで、僕は、完全に間違えていました。m(__)m
konnoさんwrote:
>う、VZK だと1バイトずれていますね。何故だかわからないです。
そ、そういうことか、、、。これで話が【少し】ずれたんだ、、、。
手元には、７個くらいpcを使うマクロがありました。
c:\def\filter2.def 400: &Sm(m,pc+292,46) ;push all double user vars
c:\def\popn.def 161::M pc[=c,pd[=d,pg[=g,pn[=m,pq[=q,pu[=u,pv[=v,px[=h,pz[=e,pw[=w,pr=pa,
c:\def\sheriff.def 113: &So(pm,"$$pc") (r)? p=pc, ? p=pm,
c:\def\sonota.def 1071: &Sm(pq..149,pc+292,46) ;push all double user vars
c:\def\stkhelp.def 1182: } ?bx=pc,
c:\def\stkmenut.def 32: (ks&1)??{ &b(5) >04 } ;pc..57 = ks
c:\def\tkdate.def 12: &11 &Sc(pc,ps) ;; pc="１９９４年１２月３１日",
もっとも別にこれに大きな問題はありませんよね、pcをpcとして使っている限り。
マシン語の中で、直値としてみたら、いろいろやばいだろうな、とは思いますが。
意見も何もありません。
が、戻るなら戻ったほうが気持ちもいいし、「めざら資源」とも整合するのですが。(^^;
過去の無用なくび木なのでしょうか？ メリットは？ (^^;
sort.defのことは僕には実害がありません。が、こっちは、ちょっと、、、。実害は、今は、ない
はずですが、、、。作家の考え方次第なのでしょう。
できたら、.docに入れて欲しいとは思います。
08362/08314 GST01234
10♯ Re^8: SORT.DEF（高橋版）の問題はここ？
( 1) 18/10/17 09:46
08360:konnoさんへのコメント コメント数：1
> org 100h
> entry: jmps entry1 ; -16
> vzversion: db "VZ1.60t ",0,EOF ; -14 ;##k07
> entry1: jmp init ; -5
> dw 0 ; -2
オリジナルは entry1 の jmp init がショートジャンプのようですが、
kVZではニアジャンプになってますね。
sort.defはpc相対を使っていないのでこれはシロだと思いますけど。
08363/08314 GST01234
10♯ Re^9: SORT.DEF（高橋版）の問題はここ？
( 1) 18/10/17 10:02
08361:文太さんへのコメント コメント数：1
本来0110hから始まるpcが0111hにずれてる事に対して、
本来0120hから始まるワークはずれていませんね。
これはpc相対で16バイト目以降に問題があると思われます。
上のgrepではfilter2とsonotaが該当するようですが。
08364/08314 CRG00666
文太 Re^10: SORT.DEF（高橋版）の問題はここ？
( 1) 18/10/17 14:23
08363:10♯さんへのコメント コメント数：1
10#さん、本当にありがとうございます。m(__)m m(__)m
顔面蒼白、これ以上になく僕の顔は今、まっ白でしょう。
頭の中に色はつかないけど、まっ白だと感じています。
冗談をいえば、脳梗塞で脳が死んだ人のように、まっ黒なのかもしれません。
熊に出会ってしまった人のように、髪の毛は、逆立ってます。
いい歳した大人が、この程度のことで人生がひっくり返ったみたいに、
動揺しても始まらないので、ちょっと落ち着いて考えます。
現実的にはそういう訳にもいかないのですが、旅に出たほうがいいな、
と感じています。
とはいえ、vtdosとは本質的に関係がありません。
もっと大きいのかもしれない。
いや、大したことではないはず、です。
08365/08314 CRG00666
文太 Re^11: SORT.DEF（高橋版）の問題はここ？
( 1) 18/10/17 16:24
08364:文太さんへのコメント コメント数：1
いちいち顔面蒼白とかしないように。いちいち逆毛とか立てないように。
けっこう立ち直り、はやかった。
たしかに、「pc+xx」はやばいようですね。
Ygrep -w "pc" c:\def
c:\def\chgenv.def 200:; &Sm(pc+60,cp+2,20) &Sm(pc+174,cp+22,176)
c:\def\lxclnd.def 107: &Sm(pc+292,pq..149,46) ;pop all double user vars
;こっちはイディオムですからねぇ。これは書き戻しの場面でしょうね。
もう一般ユーザが存在しない（konnoさんにとってはいるのかな）ご時勢ですし、、、。
誰も気がつかないんですよね、、、。
konno,
0110h: 00 56 5A 00 00 00 00 00-00 00 25 00 00 00 00 00 ･VZ･･･････%･････
0120h: 00 00 00 00 00 00 40 00-00 80 00 01 00 10 50 00 ･･････@･･･････P･
takahasi,
0110h: 56 5A 54 00 00 00 00 00-00 25 00 00 00 00 00 00 VZT･･････%･･････
0120h: 00 00 00 00 00 00 40 00-00 80 00 01 00 10 50 00 ･･････@･･･････P･
しばらく高橋版にします。マシンの台数が多いので、入れ替えが終わるのがいつに
なるのか分かりませんが。この大混乱は、もっとも苦手とするところなのです。
このマシンは入れ替えた、って、一覧表をつくるの、、、。
それでも、紆余曲折ありながらも、前進ですよ。
10#さん、ありがとうございました。
08366/08314 CRG00666
文太 基点ポインタ（？）の絶対アドレス
( 1) 18/10/17 17:20
08365:文太さんへのコメント
他は問題ないようです。これぐらいはできるな、と。
konno
0000 wseg
0110 pc 0111h *
028E pq 028Eh
dseg
03EC pn 03ECh
0442 fg 0442h
04D2 mg 04D2h
05B9 pv 05B9h
062A vp 062Ah
08367/08314 BQO00549
konno Re^9: SORT.DEF（高橋版）の問題はここ？
( 1) 18/10/17 18:49
08361:文太さんへのコメント コメント数：1
> 手元には、７個くらいpcを使うマクロがありました。
>
> c:\def\filter2.def 400: &Sm(m,pc+292,46) ;push all double user vars
> c:\def\popn.def 161::M pc[=c,pd[=d,pg[=g,pn[=m,pq[=q,pu[=u,pv[=v,px[=h,pz[=e,pw[=w,pr=pa,
> c:\def\sheriff.def 113: &So(pm,"$$pc") (r)? p=pc, ? p=pm,
> c:\def\sonota.def 1071: &Sm(pq..149,pc+292,46) ;push all double user vars
> c:\def\stkhelp.def 1182: } ?bx=pc,
> c:\def\stkmenut.def 32: (ks&1)??{ &b(5) >04 } ;pc..57 = ks
> c:\def\tkdate.def 12: &11 &Sc(pc,ps) ;; pc="１９９４年１２月３１日",
う、結構あるもんですね。
早急に対処したいと思います。ご迷惑おかけしました。
08368/08314 BQO00549
konno VZk の ｐｃ ズレ問題
( 1) 18/10/17 19:10
08362:10♯さんへのコメント
> > org 100h
> > entry: jmps entry1 ; -16
> > vzversion: db "VZ1.60t ",0,EOF ; -14 ;##k07
> > entry1: jmp init ; -5
> > dw 0 ; -2
>
> オリジナルは entry1 の jmp init がショートジャンプのようですが、
> kVZではニアジャンプになってますね。
> sort.defはpc相対を使っていないのでこれはシロだと思いますけど。
そうか、すっかり忘れていましたが、これで思い出しました。
org 100h
entry: jmps entry1
;vzversion: db "VZ1.60t ",0,EOF ;##k07
vzversion: db "VZ1.60t",0,EOF ;##k07t1-2 pc=110h
entry1: jmp init
こう修正して、pc が一致しました。ここの長さを変えたら駄目だったんですね。
VZEX もこうなっていて、以前、ダニー版ベースの VZk8 を弄っている時に
一度これをやってしまって、直したんですが、その後 VZk7 に戻った時に
ここを修正するのを忘れていたようです。
取りあえず、公開しているものは、修正版をアップします。
08369/08369 BQO00549
konno VZk 公開版の pc ズレ修正・差し替え
( 1) 18/10/17 20:15
コメント数：1
#8350 で、10#さんの指摘により、VZk のコード領域の内部ワーク pc が
１バイトずれていたのが発覚しました。
原因は
;vzversion: db "VZ1.60t ",0,EOF ;##k07
vzversion: db "VZ1.60t",0,EOF ;##k07t1-2 pc=110h
ここでした。
取りあえず、公開しているものは、修正版をアップするということで
VZk07T1（2010-03-01）を、VZk07T01.LZH として、VZの部屋に差し替えアップしました。
・コード領域の内部ワーク pc が１バイトずれていたのを修正、差し替え(2018-10-17)
旧版とはサイズは一緒です。1バイト差は自動調整されるようです。
バイナリの比較で29bytes 違いがあります。
08370/08314 BQO00549
konno Re^10: pc ズレ、やばいかも
( 1) 18/10/17 20:37
08367:konnoさんへのコメント
> う、結構あるもんですね。
> 早急に対処したいと思います。ご迷惑おかけしました。
コード領域の内部ワーク pc の１バイトずれで、値を比較してみました。
VZo VZk修正 VZk旧
pc 110h 110h 111h
pc+292 234h 234h 235h
pc..57 0 0 B900h
修正版は問題ないようですが、旧版は、変な値になっていますね。
> > c:\def\filter2.def 400: &Sm(m,pc+292,46) ;push all double user vars
pc+292 は、ここですかね。
246 sysvar dw VARCNT dup(0) ; A,B,C ... system variables
> > c:\def\stkmenut.def 32: (ks&1)??{ &b(5) >04 } ;pc..57 = ks
pc..57 は、これですね。
114 sftkey dw 0 ; ks key shift status
うう、結構やばいかも。
08371/08369 BQO00549
konno Re: VZk 公開版の pc ズレ修正・差し替え
( 1) 18/10/17 21:46
08369:konnoさんへのコメント
VZk07T3（2015-12-11）を、VZk07T03.LZH として、VZの部屋に差し替えアップしました。
・コード領域の内部ワーク pc が１バイトずれていたのを修正、差し替え(2018-10-17)
旧版とはサイズは一緒です。1バイト差は自動調整されるようです。
バイナリの比較で29bytes 違いがあります。
後はソースと一致しないものが多いので、時間がかかりそうです。
要望があれば優先的に対応します。
08372/08314 GST01234
10♯ Re^9: SORT.DEF（高橋版）の問題はここ？
( 1) 18/10/18 06:04
08361:文太さんへのコメント コメント数：1
余談ですけど、近頃僕は「信じる」という行為は控えるようにしてます。
これは、思い込みに繋がり、そこから仮に「正義」などに繋がれば、
酷い結果になる原因にもなります。
歴史からの教訓ですかね。
08373/08314 CRG00666
文太 Ｖｚ文化
( 1) 18/10/18 13:15
08372:10♯さんへのコメント コメント数：1
人生にはみっつの坂がある。のぼりざか。くだりざか。まさか。
口承文化と活字文化の落差を、またしても感じさせてくれました。
活字は先読みできる。口承では完全に話者のペースになれる。それで、
うまくやると洗脳できる。
理解したからといって、実践できるわけでもないですが。
信念をもたないのが僕の信念だ。「外」はないようですね。
Ｖｚ文化にはこんな言い伝えもあります。
「ニーモニックが読めるからといってc.mosさんのソースを読めるわけでは
ないのと同様、Ｖｚマクロのシンボルその他を暗記したからって、m.gannさん
のマクロが読めるわけではない」
高橋さんのマクロでは、（きっと）プロのプログラマ的に正統だろうと思いますが、
それでも、m.gannさんが目標だったのも（きっと）あって、Ｖｚの癖をとことん
知り尽くした上でのプログラミング・スタイルなのでしょう。
Ｖｚの「内部ワーク」の利用は当然ですが。
知ったかぶりではなく想像です。
sort.defでは、「癖」でも「裏技」でもないでしょうが、テクニックが駆使
されているようです。かなりのスキルレベルで、読解の行為に深いコミットメント
のあるマクロ師でなければ、読めないか、読もうとしないか、かと思いました。
僕レベルだと、おお、とほんの一部分で、テクニックを学ばせてもらえる程度
でした。sort.exeではいけませんか？ と思うような奴には無理ですね。
（いつかME環境で使ってみようとは思っていますが。フィールドでなくカラム
でソートは、、、。sortfはオプション指定がいつも難しくて、、、。）
「内部ワーク」。めざらさんがあのように素晴らしく纏めてくださってますが、
あれが明らかになるのに、１０年くらいに及ぶ、多くのＶｚｅｒたちの苦闘が
ありました。文字どおりの血と汗と涙の結晶。
最終的に発表したのは高橋さん。でも、高橋版Ｖｚも「セグマップ」も、
高橋さんがきっと５０人くらいのマクロ師、マクロイド、マニアック・ユーザに囲まれ
ていて、その価値を理解してくれる人たちがいたからこそ、生まれたのだろうと思います。
あんなこと、誰も、一人ではやれないと思う。
めざら資源で、一人であれを纏め直した、めざらさん。僕はあの作品に感動します。
08374/08314 GST01234
10♯ Re: Ｖｚ文化
( 1) 18/10/18 14:42
08373:文太さんへのコメント
ネットワークの世界に「口承文化」ってないですよねｗ
08375/08375 BQO00549
konno VTDOS+VZ で #N、#P でのエラー
( 1) 18/10/18 20:58
コメント数：2
VTDOS+VZ でファイル編集中に #N や、#P で、拙作の TAGL_F5.DEF を実行すると
&z("expand") を呼ぶところでマクロエラーになります。
ESC を押すと、VTDOSが、ラップアラウンドエラーで落ちます。
実は、私の環境では、expand.def が無かったんです。
つまり、ファイル操作窓で、マクロ呼び出しなどでファイルが無いエラーになると
ESC で入力窓を閉じる時、VTDOSが、ラップアラウンドエラーで落ちるのです。
エラー内容は
2018-10-18 20:29:03 VZIBMJ(17EA) 17EA:DE8E 'REP MOVSW 命令ラップアラウンド'
AX=0023 BX=4000 CX=0082 DX=FF00 SI=EA60 DI=FF04 BP=CBEE DS=E800 ES=F800 FLAGS=0246
CS:IP=17EA:DE8E
17EA:DE7E 40 06 51 57 51 57 E8 B1 00 E8 2D 04 5F 59 F3 A5
17EA:DE8E E8 44 04 5F 59 36 03 3E 46 06 48 75 E5 E8 AC 2E
SS:SP=274A:CACE
274A:CABE 00 00 04 FF CD E2 04 FF 23 00 8A DE 04 FF 82 00
274A:CACE 04 FF 82 00 4A 27 4A 27 76 03 DB A3 90 06 00 FF
-u 17EA:DE7E
17EA:DE7E 40 INC AX
17EA:DE7F 06 PUSH ES
17EA:DE80 51 PUSH CX
17EA:DE81 57 PUSH DI
17EA:DE82 51 PUSH CX
17EA:DE83 57 PUSH DI
17EA:DE84 E8B100 CALL DF38
17EA:DE87 E82D04 CALL E2B7
17EA:DE8A 5F POP DI
17EA:DE8B 59 POP CX
17EA:DE8C F3 REPZ
17EA:DE8D A5 MOVSW
17EA:DE8E E84404 CALL E2D5
17EA:DE91 5F POP DI
17EA:DE92 59 POP CX
17EA:DE93 36 SS:
17EA:DE94 033E4606 ADD DI,[0646]
17EA:DE98 48 DEC AX
17EA:DE99 75E5 JNZ DE80
17EA:DE9B E8AC2E CALL 0D4A
-q
0000:DE59 POPWINDOW
ここは、入力窓ルーチンの窓を閉じるところですね。
SORT.DEF も、バックアップルーチンで、#N を使用していますが、
何かエラーが出ていた気がします。
MSDOSPlayer や、DOS窓では、マクロエラーがあっても落ちません。
この辺に何かありそうな気がするのですが。
08376/08375 GST01234
10♯ Re: VTDOS+VZ で #N、#P でのエラー
( 1) 18/10/18 21:54
08375:konnoさんへのコメント コメント数：1
ざっくりですが、画面の出力座標かサイズに問題が起こってるようですね。
外してるかも知れませんけど、scrn.asm の win か doswd2
これらはマクロからアクセスしてログを取ることなどは出来ますか？
08377/08375 CRG00666
文太 Re: VTDOS+VZ で #N、#P でのエラー
( 1) 18/10/18 22:03
08375:konnoさんへのコメント コメント数：1
いつもの超断片的補足です。(^^;
http://tamaneko.world.coocan.jp/vz/TAGL_F5.def
=== tagl_f5.def v.06 ===
* M
24 [F05] "検索文字列の取得"
(s==1||s==2)? { &z("expand") >* } ; コマンドライン
このように、tagl_f5.defは、sが
1 : 文字列入力モード
2 : コマンドラインモード
であると、expand.defが呼ばれる仕様になっているのですが、
expand.defがないばあい（%vzdef%ディレクトリに、かな？）、つまり
>ファイル操作窓で、マクロ呼び出しなどで、ファイルが存在せずエラーになると
>ESC で入力窓を閉じる時、VTDOSが、ラップアラウンドエラーで落ちるのです。
失礼しました。
マクロを見るまで、何を言ってるのかよく分からなかったもので。m(__)m
#N
#72 #N 新規ファイルオープン
[ESC]N @N
#P
#25 #P ファイル名の複写
^QN le_copyfile
r は常に 0
編集中のフルパスのファイル名が
カーソル位置に書き込まれる
&?(wa+146) と同じ
に何かあるのかも？ と。
追試するには、まだまだ環境整備がままなりません。m(__)m
08378/08375 BQO00549
konno Re^2: VTDOS+VZ で #N、#P でのエラー
( 1) 18/10/18 22:20
08376:10♯さんへのコメント コメント数：1
> ざっくりですが、画面の出力座標かサイズに問題が起こってるようですね。
> 外してるかも知れませんけど、scrn.asm の win か doswd2
> これらはマクロからアクセスしてログを取ることなどは出来ますか？
えーと、何をすればいいのかわかりませんが
VTDOS環境では、全てのVZで同じ操作で落ちました。
オリジナルVZとオリジナルDEFでも、#Nで、拙作の TAGL_F5.DEF を実行して
落ちます。
TAGL_F5.DEF の冒頭は
24 [F05] "検索文字列の取得"
(s==1||s==2)? { &z("expand") >* } ; コマンドライン
こうなっていて、これは、上村さんの、GET.DEF と同じです。
私はこのマクロをベースに改造したのですが、expand.def が無いのに
気が付かなかったのです。
入力窓の中で、マクロがエラーで止まって、フラグとか
スタックとかの数値に矛盾が出てるんでしょうかね。
08379/08375 BQO00549
konno Re^2: VTDOS+VZ で #N、#P でのエラー
( 1) 18/10/18 22:47
08377:文太さんへのコメント コメント数：1
文太さん、解説どうもです。(^^;
私はいつも説明不足というか、舌足らずというか。
#8378 に書いたように、上村さんの、GET.DEF をベースに改造したので
この部分が問題になるとは思ってもいませんでした。
上村さんの、GET.DEF の最後のほうには
●ファイル名の補完
文字入力ウィンドウまたはコマンドラインで実行すると、ファイル名を補完
します。（T.Tanomura氏作EXPAND.DEF必要）
とあります。
上村さんが他人のマクロを組み込むなんて想像もできなかった。
T.Tanomura氏も凄い人だったんだなぁ。
08380/08375 CRG00666
文太 Re^3: VTDOS+VZ で #N、#P でのエラー
( 1) 18/10/19 00:13
08379:konnoさんへのコメント コメント数：1
>#8378 に書いたように、上村さんの、GET.DEF をベースに改造したので
>この部分が問題になるとは思ってもいませんでした。
こんな風に話がすぐに先に進むのであれば、何の問題もありません。
上村さんの、GET.DEFは、存じておりませんでした。
>上村さんが他人のマクロを組み込むなんて想像もできなかった。
>T.Tanomura氏も凄い人だったんだなぁ。
うーん、どうなんだろう。
でも、fgalapぐらい？、fgalpk初期には、「たのむら〜、たのむ」
みたいな感じで、上村さんは色んな人から貪欲に、超速で、勉強して
いましたよ。ほんとＶｚの基本を徹底的に勉強した人でしたねぇ。
いまごろ、ほんと偉いと思う。
田野村さんは、計算に強い人だった感じかなぁ。expand.def、僕も
使ってますよ。
って、何か変な感じ。
ボク、1999年くらいにniftyデビューだったので。もう高橋さんも
いない頃。
08381/08375 CRG00666
文太 Re^4: VTDOS+VZ で #N、#P でのエラー
( 1) 18/10/19 00:35
08380:文太さんへのコメント コメント数：1
もう少し問題を絞り込んだほうが良いような気がしますが。
マクロのどの部分でかとか。
(s==1||s==2)? { &z("expand") >* } ; コマンドライン
この部分だけで落ちますね。
で、落ちるのはvtdos環境に限定されていないと思います。今、純ＤＯＳで
expand.defを0expand.defにリネームして、
=== tagl_f5.def v.06 ===
* M
24 [F05] "検索文字列の取得"
のマクロを再カスタマイズ、検索窓で[F05]したら、マシンが落ちました。
落ちるのはまずいだろう、とは思いますが。
マクロがいけない？ vz.comがいけない？ マシンが落ちるのが正しい？
補足でした。
08382/08375 CRG00666
文太 vz.com, s>0の問題みたい
( 1) 18/10/19 00:55
08381:文太さんへのコメント コメント数：1
す、すげえ。
「画面の出力座標かサイズに問題」。これに一票。
vz.comの問題だと思う。
=== Macrotmp by B ===;
* M
50 ^^ "Macrotmp"
&z("expand") >*
*
これをexpand.defがない環境でやりました。
s==0, [ESC]が効いて、マシンは落ちない。「c:\def\expand.defが見つかりません」
のメッセージが出る。
s==1, 落ちる。
存在しないファイルを窓を開けた状態から&z()（???）でファイルオープンしないこと、ですかね。
#Nとかについては、また別件でしょうか？
08383/08375 CRG00666
文太 痩せたＶｚ、太ったＶｚ
( 1) 18/10/19 01:26
08382:文太さんへのコメント
お疲れ様です。
僕の一票で候補者が当選しても、とうぜん、僕にできることは何もありません。
冗談でなく。
ふと、これは高橋さんも知らなかったのかなぁ、と考えていて。いや、この手
のことを全部潰していたら、ゼロ戦Ｖｚはゼロ戦でなくなり、きっと、comに
収まらなくなっていたのだろうと想像しました。
大昔の10#さんのＶｚソースレビュー（メモリ管理？）を思い出してそう
思いました。
これってマクロで対処できるのでしょうかね？ 僕はユーザがそういうことを
しないこと、でいいような気がしました。
もう我々しかいないのだから、Ｖｚを無意味に（？）太らせないほうがいい、と。
08384/08375 BQO00549
konno Re^3: VTDOS+VZ で #N、#P でのエラー
( 1) 18/10/19 02:18
08378:konnoさんへのコメント コメント数：1
とりあえず、VZ.DEF か、VZ2.DEF のようなインクルードマクロに
エラーイベントマクロ
1 "!Abort" /
を入れると、今回のエラーで落ちるのは無くなったようです。
'/' は、全マクロ終了だったかな。
副作用はわからないです。
おそらく、マクロ終了時の処理、オプションの初期化みたいなことを
やっているのではと想像しますが、本当のところはわかりません。
でも、SORT.DEF はやっぱり落ちるみたい。
08385/08375 CRG00666
文太 Re^4: VTDOS+VZ で #N、#P でのエラー
( 1) 18/10/19 11:05
08384:konnoさんへのコメント
/ マクロの実行を終了
ネストレベルに関係なく全てのマクロが終了する
マクロを終了するときは '.' を使うほうがよい
（モード型のマクロも終了してしまうため）
誰かがもう少し詳しく纏めていたような気もしますが、僕に分かったのは
これだけです。使ったことないですよね。ほとんど禁止されてたみたいなもの
だった気もするし。
「/ マクロを強制中断（使用禁止？）」（上村さんの「道場」より）
プッシュ・ポップも戻さないで、強制終了。
僕の印象のソースは、ここかもしれません。
でも、その!abort技、ありなんじゃないでしょうか。かなり稀な緊急事態のような
気もするし。こうなったら、Ｖｚを再起動せよ、で、いいような。