10698/10682 CRG00666 文太 Re^3: 検証、[ESC]I マクロでとしきさんの生ログデータの情報
( 1) 23/03/24 22:49 10697:konnoさんへのコメント
はい、そうなんです、filter.def。でもね、、、。
http://mezala.la.coocan.jp/vz/notes/vars.html
xc v1.6 ブロック範囲比較変数
値 カーソル位置(cp)と選択開始位置(tblkp)との比較
-1 cp < tblkp
0 cp == tblkp
1 cp > tblkp
※比較はオフセット値で行われるため,常に正しいというわけではない。
64KBの敷居をまたぐ可能性がある時に正確な比較をするためには,
カーソル位置のロングポインタ(マークで使用)を用いる必要がある。
-------------------------------------------------------------------
少なくともこれに引っかかったとは思えないんですよねぇ。
そんなに運は悪くないだろうと。処理対象(範囲)が大きくない、が
より客観的で合理的な根拠ですが。
64KB。またしてもテキストバッファの限界値。
セグメントの境界だものね。???
.com ファイルの制限、これも。
vzo.com 57,694 1993-12-06 02:00 ;cmos
vz.com 62,184 2018-10-17 19:11 ;konno 一杯ま近ですよ。
10699/10682 BQO00549 konno Re: VTDOS+EMS+VZでの不具合検証
( 1) 23/03/24 22:54 10682:konnoさんへのコメント コメント数:2
良い知らせと悪い知らせがあります。
10#さんとのやりとりで私が上手く伝えられなくてどうなることかと思いましたが
再現が出来たと朗報がありました。
それとともに、新たなVZのバグが発覚したようです。
メールの返信の内容を貼り付けます。
-----------------------------------------------------------
>試験をやり直した結果再現しました。
おお、再現出来ましたか、よかったです。
>余談になりますが、僕の試験で把握出来た事をお伝えします。
>まずこの現象はEk+では再現されないようですが、この場合は前回僕がお伝えした結果になります。
>それから、試験をパスした(一致した)状態で窓替え(F2)を行ってすぐ比較を行うと相違が出ます。
>これはMS-DOS上のオリジナル版でも出ます。
試験をパスした(一致した)状態で窓替え(F2)を行ってすぐ比較を行うと相違が出るのですか。
この現象は知りませんでした。やはり検証不足だったようです。
MS-DOS Player や DOSVAXJ3 でも同じ現象になりました。
[F02]の後の比較マクロで6か所文字化けが出ますが、これは VZ のバグだと思われます。
思い当たるルーチンが有るので修正したVZで試してみました。
MS-DOS Player や DOSVAXJ3 では、文字化けが無くなり、正常になりました。
VTDOS では、やはり内容が変わっています。
10#さんのおかげで、一歩前進出来たみたいです。ありがとうございます。
>この事を踏まえ調査を行うつもりです。
よろしくお願いいたします。
私ももっと検証を進めたいと思います。
-----------------------------------------------------------
ということで、調査をしていただけるのはうれしい知らせですが
比較で一致しても直後に[F02]窓替えで再比較すると文字化けが出るという新たなVZのバグが発覚しました。
これは、BL1024 か BL2048 の時だと思われるので、BLの影響で長い行の途中に改行が入るのではないかと想像しました。
過去記事の
#10322:Bl3072 の大穴が塞がったかも 投稿者:konno 2022/10/11(火) 21:59
> Bl3072 では 3700bytes を超えるところで改行が入っていました。
> ソースに改行を挿入するところがあるはずだと当たりをつけて
> 「,LF」で検索すると、それらしいところが TEXT.ASM にありました。
>
> fread proc
> 中略 410行目
> cmp si,di
> jne read3
> mov byte ptr [si-1],LF
> _break
> read3: cmp byte ptr [si-1],LF
> _until e
> clz
> ret
> read9: stz
> read_x: ret
>
>
> ここの
> mov byte ptr [si-1],LF
> があやしいと思い、色々試したところ
>
> cmp si,di
> jne read3
> stc ;★##k 221011 キャリーをセット
> jmps read9x ;★ ゼロフラグをクリアしてリターン
> ; mov byte ptr [si-1],LF ;★ Bl3072 の時 3700bytesで強制改行(実行しない)
> _break
> read3: cmp byte ptr [si-1],LF
> _until e
> read9x: clz ;★ ゼロフラグをクリアしてリターン
> ret
> read9: stz
> read_x: ret
>
>
> このように変更したら、Bl3072 で改行文字化けが無くなりました。
これを思い出し
cmp si,di
jne read3
jmps read9x ;★ ゼロフラグをクリアしてリターンへ
mov byte ptr [si-1],LF
_break
read3: cmp byte ptr [si-1],LF
_until e
; clz
read9x: clz ; or sp,sp = zf0 cf0
ret
このようにシンプルに修正したVZでは、文字化けも無く正常処理出来ました。
今までは余計なところまで弄ってエンバグしていたようです。
正常動作するVZは、だいぶ前に戻ってしまいました。
今まで積み上げてきたものが全部崩れてしまった感じです。(^^;
# まるで賽の河原で石積みをしているような・・・ だって私、VZの亡者ですから。
10700/10682 DGF01024 めざら Re^3: 検証、[ESC]I マクロでとしきさんの生ログデータの情報
( 1) 23/03/25 10:35 10697:konnoさんへのコメント コメント数:1
参照先:http://mezala.la.coocan.jp/
> 確か、xc もバグがあったような。
> これは怪しいですね。どうでしょ >めざらさん
怪しいというわけではないのかと…。xc の件は,バグと言うより仕様だと思いますが,
マニュアルに警告が書いてないのでバグ扱いが妥当かもしれませんけどね。
(一応,cp と tblkp とあるけれど,それだけだとソース読める人とかが対象)
なお,filter.def マニュアルには,「64KBをこえる大きなブロックは扱えません。」と
明記してあるので,ローカル 10: のルーチンが巨大ブロックに対応していなくても
それは仕様であってバグではありません。もちろん VZ のバグとの関係もありません。
#i の戻り値を xc の値で上書きしているのは,その振る舞いを見越しているわけで,
これまた VZ マクロらしい無駄のない動作だと思います。
・ブロック処理は,下から上に向かったブロック(xc==-1)の方が速度的に有利
・その場合でも処理後のカーソル位置をテキスト末尾に移動
…という感じかなぁ…
そのへんは,改造するほど入れ込んでいる文太さんに聞いた方が的確かと。
10701/10682 CRG00666 文太 Re^4: 検証、[ESC]I マクロでとしきさんの生ログデータの情報
( 1) 23/03/25 11:54 10700:めざらさんへのコメント コメント数:2
特に何も聞かれてないと思いますが。
何もできない、ほぼ何も考えられない(知識が足りない)という感じですが。
(1)原因は、vtdosか、vz.comか、filter.defか。??? どれも可能性あり。
(2)>filter.def マニュアルには,「64KBをこえる大きなブロックは扱えません」
とあり、
これは、xcの件。しかし64KBを超えるファイルでテンポラリーファイルとかテキスト
バッファが絡んだら? これは、きっとvz.comがらみの事柄。
(3)こういう場合、経験とか実体験とか統計的に無意味だろうと思いますが、
それでもいまのところWinMEでは経験していない(と思う)。
とにかく、(1)としきログ、(2)clppestがらみ、(3)filter.def文太がらみ
では、(3)に圧倒的に発現条件についての情報が足りません。再現できません。
さらに、この3つがどれだけ重なった、関係した事態なのかも分からない、、、。
新しい情報みたいにみえて、misleading な事柄でした、おそらく。
他意はないですが、いちおうお伝えしておくと、(僕の読解力のせいだろうと
思うのですが)、(2)について、僕は何の話だかまったく分かっていません。
10702/10682 DGF01024 めざら Re^5: 検証、[ESC]I マクロでとしきさんの生ログデータの情報
( 1) 23/03/25 13:28 10701:文太さんへのコメント コメント数:1
参照先:http://mezala.la.coocan.jp/
> とにかく、(1)としきログ、(2)clppstがらみ、(3)filter.def文太がらみ
> (2)について、僕は何の話だかまったく分かっていません。
ごめんなさい。不具合の発生したファイルを提供したので,細かな手順などはすべて
端折ってしまいましたから,わたしと konno さん以外は見えなくて当然です。
せっかくだから補足しますと,自分のコンテンツで「ラジオドラマ資源」なるものが
ありまして,これの一年単位の番組基本情報ページがあるわけです。1950年代は
わりとラジオドラマの放送が多くて,それなりのサイズのテキストになります。
先日のファイルが 300KB 弱で,2,100行強,ラインバッファを超える1行はありません。
この一年分のデータは,スプレッドシートで複写した TSV で,クリップボードに転送。
このとき手作業でファイルに落とすことなく,愛用の clppst を使って貼り付けます。
そして,貼り付けたタイミングでエラーが発生したわけです。300KB 弱ありますから,
当然,巨大ブロックを挿入する [ESC]I と同様のマクロコードが clppst.def にあります。
具体的に,上記の手順でした。
再現条件は EMSを使用,clppst.def 実行,64KBを超えるテキスト,です。
としきファイルと異なるのは,ラインバッファを超える行がないこと。たぶんそのくらい。
(↑ これ,ウソです。としき兄のご指摘(#10703)がありました。)
10703/10682 CXB00940 としき Re^6: 検証、[ESC]I マクロでとしきさんの生ログデータの情報
( 1) 23/03/25 14:11 10702:めざらさんへのコメント コメント数:1
参照先:http://toshiki.la.coocan.jp/
> としきファイルと異なるのは,ラインバッファを超える行がないこと。
めざらさんの提供されたファイルの一番長い行って、何バイトくらいですか?
私の提供したファイルでは、確か7000バイトに満たないくらいだったはず。
そして私の場合、Blは8192に設定してあって、ラインバッファを越えていないはず
なのに異常動作が発生したという認識です。
この辺、何か私の認識誤りか確認ミスがあったかな。
いまになってそういったことが発覚したとなると、かなり困ったことです。
10704/10682 DGF01024 めざら Re^7: 検証、[ESC]I マクロでとしきさんの生ログデータの情報
( 1) 23/03/25 16:07 10703:としきさんへのコメント コメント数:1
参照先:http://mezala.la.coocan.jp/
あらら,実際のファイルで調べもしないで適当なこと言っちゃいました。
すみません.
わたしのファイルだと,急拵えしたこんなマクロで 1600バイトほどと表示されました。
1 ^\ "" ?.
a-,
#^ #<
:l ; ---- main loop ----
cp[,
#> r=cp-0],
(r>a)?a=r,
#d (r)??>l
&m("%u",a)
:z ; ---- exit ----
&d #] .
うちのラインバッファも 8192 取ってるので,断然余裕ですが。
10705/10682 CRG00666 文太 ゴミ
( 1) 23/03/25 16:48 10704:めざらさんへのコメント コメント数:1
awkだとどう書くんだっけ? と。ちゃんと忘れてました。
--- maxlen.awk ---
{ if (maxlen < length) # length()が推奨されているらしい
maxlen=length
}
END { print maxlen }
------------------
C:\>jgawk -f maxlen.awk c:\0etxt\asm\tbook\mast_td.txt
141
問題まったくないですね。すっかり安全志向。
ただ、どっかでkonnoさんが、bl の値により、挙動(結果)が違う、
と書かれていたので、それの再検証からいくかな等々、いちおう真剣に
考えてはいます。BL=8192 bytes これには、実用上、問題は何もない
と思っていますが。
タネをしこんで厨房に立ち、カレーを作り始める(時間がかかる。時間を
かけると美味しい)。そしたら、とらじさんのように、なるへそ、
そう攻めてみるか、とか思いつくのかなぁなんて思ったけど、別に何も
思いつきませんでした。カレー作りに夢中になっただけだった。
(「どこどこ」開発中の会話より。doko2.defを相当ひさしぶりに動かした。
いえいえ、キーの格納のされ方もすごいです)
あ、こういうのゴミ発言って言うんでしたよね。
追伸でなく本題:clppst.defの件、発現条件は分かりました。10#さんからの
回答の意味も少しわかりました。多謝>めざらさん。
10706/10682 BQO00549 konno xc のバグと対策
( 1) 23/03/25 18:29 10701:文太さんへのコメント コメント数:1
xc のバグといえば、あむのさんの対策を思い出します。
CODEX.DEF で検索しましたが、BL2048 だと CODEX.DEFが起動しない! まいった。(>_<)
BL4096 なら起動できたので、以下に引用します。(^^;
-----------------------------------------------------------
> 06847/06847 xxxxxxxx あむの xc にはご注意!
> (15) 97/07/10 07:56 06827へのコメント
変数 xc にはよく知られたバグがあります。
(1) 32,767 byte の前後にかかる後ブロック(注)で xc の値が 0 となる
ファイル 32767 65536 65K+32767 (byte)
+------------+----------+--- .... ---+---------- ......
・========* ・====*
blk blk
(*印がカーソル位置)
本来ならば xc == 1 。
(2) 文字境界ブロック (mb==2) 限定のバグ
・ファイル先頭行にブロックがかかること。
・前ブロック(注)であること。
・カーソルカラム数がブロック終端のカラム数(wa..51)より小さい。
この場合、xc の値が 0 となる。(本来はxc == -1)
(例) ファイル先頭
+-------------------------------+
| *===========================|
|======・ blk |
| |
(*印がカーソル位置)
(注) 前ブロック カーソルがブロックの前の場合(xc:-1)
後ブロック カーソルがブロックの後の場合(xc:1)
ですから、上記バグの条件にあたらないことが明確ならば、xc は有用です
が、それ以外の場合には使わない方が良いかと思います。
* * *
xcの代替手段としては、マーク機能(&#M(n))をブロック前後で使って、その
マークの値を比較するというのが一般的ですが、これまたちょっと問題を孕ん
でいます^^;。
というのは、純正Vzには、ロング整数を比較する&Lcという関数にも著名
なバグがあって、使えないのです(榊原さん版Vzは修正されています)。
というわけで、自力ですると、例えばこんな↓ふうになります。
FGALPK Mes13 #02168 94/12/17 y.mikome さん ご紹介の方法に若干手抜き
したものです。
=Test
カーソルをブロックの前にする。
マーク#0 wa+126 (wa..63,wa..64)
マーク#1 wa+130 (wa..65,wa..66)
* M
89 ^\ ""
?.(mb)??.
#M #B &#M(1) #B p$8000, ;ブロック前後でマークする(位置は元に)
(wa..64 > wa..66 || (wa..64 == wa..66 && p+wa..63 > p+wa..65) )?#B
*
ここまで -----------------------------------------------------------
私は xc を使ったこともなく、よくわかっていなかったのですが
今このマクロを見ると、なんとなく読める気がします。(気の精)
# 読める! 私にも読めるぞぉ! ララァ
06858番の発言では
-----------------------------------------------------------
あ、いえ、ブロックのサイズの問題ではないのです。ファイルサイズとブロ
ックの位置の問題なんです。
百聞は一見に如かず、ということでこの↓マクロを実行して xc の値を確か
めて下さい。
=Test
巨大なファイル(例えばログファイル)上で実行して下さい。
* M
80 ^\ ""
?.mb0,&d
&Im(wa+126,0) wa..63=$7FFF,
#U #< #b #> #d
&m("xc:%d",xc)
*
また、幸い?なことにバグは xc==0 のときだけのようですから、その時は
実行させず、警告メッセージを出すだけにしても良いかもしれませんね(特に
今回のマクロの場合は、バグでない xc==0 の時も実行させる必要もなさそう
ですから)。
ここまで -----------------------------------------------------------
これを踏まえて、気が向いたら調べてみたいですね。(無責任モード)
10707/10682 BQO00549 konno Re: BL8192 は #BでCPズレの可能性
( 1) 23/03/25 18:41 10705:文太さんへのコメント
> ただ、どっかでkonnoさんが、bl の値により、挙動(結果)が違う、
> と書かれていたので、それの再検証からいくかな等々、いちおう真剣に
> 考えてはいます。BL=8192 bytes これには、実用上、問題は何もない
> と思っていますが。
みなさん BL8192 でお使いのようですね。
過去の [ESC]i マクロでとしきデータの行長は BL8192 以下でしたが、CPズレでブロックが入れ替わったという記憶が。
EK- で #B を繰り返し使うと CP ズレが起こることがある、と私は感じました。
今は BL8192 でも安心できない気がするので、検証を続けているのです。
バグが特定できれば回避して運用するのは可能だと思うので、みなさんの情報が頼りです。
10708/10682 BQO00549 konno Re^2: 良い知らせ
( 1) 23/03/25 18:48 10699:konnoさんへのコメント
VTDOS BBS で、10#さんからのお知らせがありました。
> 原因が判明したので遠からず修正可能です。
> リリースまでもう少し頂きます。
うれしいです。\(^^)/ ヤッタ-
ありがとうございます。
気長にお待ちしています。
10709/10709 DGF01024 めざら 【乞検証】現環境で出来なくなったこと
( 1) 23/03/26 11:12 コメント数:2
参照先:http://mezala.la.coocan.jp/
みなさまにお願いがあります.掲題のとおりの検証です.
各人の環境で以下の2点の現象が生じるかどうか教えてください.
(手元での発生条件がよくわからないのです)
(1) to Filer
60 \[CR] "" ?. #O #m ;to filer ;H_ear
コマンドライン専用コマンド #98 と操作を合わせるために v1.5 時代から使用.
このマクロを現環境で実行すると,#O #25 の動作になる.
ところが,GPD MicroPC の VTDOS 環境では所期のファイラが起動.訳がわからない.
どの版から発生しているかというと,下記のとおり.
2009/12/12 k07s5 ok
2010/01/04 k07t ok
---------------------------< ここが境界と思われるが上記のとおり確証得られず
2010/03/01 k07t01 NG (GPD MicroPC では ok !?)
2022/11/13 k07t02 NG
(2) mp0で次検索(少し長いです.ごめんなさい)
;= ^QF.def = H_ear mp0常用者のいきなり検索・次検索
55 ^QF "" ?. k20&ks, mp[, (ks&1)?{ &j(10) }
#F &Cr &j(-1)
(r)?{ mp], . }
&s (k)?#r ?#c >01
35 ^R "" ?. (ks&1)??{ #r . } c-, >00
36 ^C "" ?. (ks&1)??{ #c . } c+, >00
0: &s mp[=2, &o(#r+c) >>
1: (r)?{ &o(#c-(cm-35)) &b(2) } mp], &d
(r)?{ &m(19) }
?{ &m("%c",cm+'÷' ) } ; ▲▽ (59:^_)('∞':↑↓)
;------ end of ^QF.def ------
マクロ 55 は正常動作だが,35,36が動作しない.
これは VTDOS 環境で発生しており,高橋版でも同じ.
VTDOS 環境では,@A 等の [Alt]+[英字] キーでコマンド/マクロを実行すると
Windows が警告音を鳴らしてくる.この現象と同根か?
お時間よろしきときに,お試しください.>みなさま
10710/10709 CRG00666 文太 Re: 【乞検証】現環境で出来なくなったこと
( 1) 23/03/26 14:58 10709:めざらさんへのコメント コメント数:1
=== Macrotmp by B ===; vtdos & k07t01
* M
36 ^E "" ?. (ks&1)?{ &m("shift") } ?{ &m("non-shift") } .
*
面白いマクロだった! 使い方に習熟するのに時間がかかるだろうけど。
あまりにあまりな基本動作なので。もらっちゃおう!
ただ、上が効きませんでした。
わお、^D なら効く!
これ、重大問題だ。今晩、純DOSとWinMEでやります。
^C だけなの?
^A OK
^B OK
^C NG
^D OK
^E NG shift で秀丸起動!
^F OK
^G OK
^H OK
^I 2 stroke key registered 問題ないと思う。
^J OK
^K 2 stroke key registered ふだん使ってるから。
^L OK
^M OK
^N 2 stroke key registered
^O 2 stroke key registered
^P OK
^Q 2 stroke key registered
^R OK
^S OK
^T OK
^U OK
^V OK
^W OK
^X OK
^Y OK
^Z OK
^Cと^E がおかしい、という結果でした。Vzの版の問題なのですか?
シフト付き^Cと^Eを、僕はふだん使ってなかったから気づきませんでした。
さらなる調査希望。
追記:^Eですが、秀丸が何を開けたかというと、コンソールファイルと思しい。
-------------------------------------------------------------------------
VTDOS Version 1.53 Copyright (C) 2009-2017 by 10# Build[Sep 5 2017]
以下略
-------------------------------------------------------------------------
こんなの。
VTDOS 版が古いです。怠惰です。
vtdos.exe & vz.com の両方に関わってしまってる?
おお、ファイル名は、0f5a1dbc.txt.(秀丸を閉じようとした)
c:\Users\xxx\AppData\Local\Temp\0f5a1dbc.txt だそうです。windows の tmp
ディレクトリですね。
10711/10709 CRG00666 文太 Re^2: 【乞検証】現環境で出来なくなったこと
( 1) 23/03/26 15:25 10710:文太さんへのコメント コメント数:1
=== Macrotmp by B ===; on VTDOS & k07t01
;(1)
* M
60 \[CR] "" ?. #O #m ;to filer ;H_ear, OK
;(2)
55 ^QF "" ?. k20&ks, mp[, (ks&1)?{ &j(10) } ;OK, shift IME ON OK
#F &Cr &j(-1)
(r)?{ mp], . }
&s (k)?#r ?#c >01
35 ^R "" ?. (ks&1)??{ #r . } c-, >00
36 ^C "" ?. (ks&1)??{ #c . } c+, >00
0: mp[=2, &o(#r+c) >> ;shift, str srch
1: (r)?{ &o(#c-(cm-35)) &b(2) } mp], &d
(r)?{ &m(19) } ;「文字列が見つかりません」
?{ &m("%c",cm+'÷' ) } ; ▲▽ (59:^_)('∞':↑↓)
*
ずいぶんと先走り、端折った書き方をしたので。少しちゃんと。
上のマクロ 60 番に、僕の環境では問題ありませんでした。ふだん \[CR] は
デフォの #n で、これにも、上の60 番マクロにも、同機能をふだん実現する
マニュアル操作の「#O #m」も問題なし。
55 番マクロ、問題なし。
35 番マクロ、シフトもノンシフトも問題なし。
36 番マクロ、シフトに問題あり。よって前発言の調査となりました。
10712/10709 CRG00666 文太 ゴミ2
( 1) 23/03/26 15:43 10711:文太さんへのコメント コメント数:1
see #10541
いえいえ、
>VTDOS Version 1.53 Copyright (C) 2009-2017 by 10# Build[Sep 5 2017]
最新版でした。バーアップしたんだった。
で、新版が来ると。EMSがフィックスされて、もしかしたら、ほぼ1年越し
の問題が解決されるかもしれないと。イエイ! そしてまたまた新しい問題が
見つかると。ふにゃ。
10713/10682 CRG00666 文太 Re: xc のバグと対策
( 1) 23/03/26 15:47 10706:konnoさんへのコメント コメント数:1
konnoさん
情報、ありがとうございます。
ただ、古いですね。32KB 近辺のバグは除去されていると思しいです。
で、マーク4バイトX2で対策しようかとも思っているのですが、昨晩
深みにはまってしまい、、、。
僕以外気にしてない、そして、本当の原因はここじゃない、というあたりで
逃避行動に出ています。
とにかく、情報多謝です。当たり前でしょうけれど、ロングの比較は、
高橋版(榊原版)から、符号なしに統一されフィックスされているはずです。
10714/10709 CRG00666 文太 on WinME
( 1) 23/03/26 22:45 10712:文太さんへのコメント
すべてのテストを正常にパスしました。vz.comもまったく同一のものです。
VTDOS環境、というかもしかしたら、Win7 (OS) のなせる技でしょうか。
もしかしたら、一部、その英語キーボード付きマシンの特殊性?
なお、先ほど、^\E を再びやったら、今回は、164c11bc.txtをオープンした。
これってもしかして、Vzが作るテンポラリーファイルでしょうか? Windows
以降で、ファイル名をユニークにした奴?
中身は、前回と同じく、vtdos 起動時のコンソールファイルの中身。でも
Vz起動前ですから(vtdos, vz起動バッチの順)、そんなものがVzの
テンポラリーファイルの「中」に書き込まれるというのは、相当に変ですね。
なお、うちでは、.txtが「秀丸」に関連付けされているから秀丸でした。
164c11bc.txtみたいなのをオープンせよ、という命令がOSに送られている
のだと思います。
純DOSのテストは要らない、という判断です。
konnoさんが手元で検証(確認)できたら、10# さんに報告してくれると助かり
ます。
alt のテストは以下。ごめんなさい(謝ることはない)問題なしです。
=== Macrotmp by B ===; vtdos & k07t01
*M
36 @A "" ?. (ks&1)?{ &m("shift") } ?{ &m("non-shift") } .
<cut>
36 @Y "" ?. (ks&1)?{ &m("shift") } ?{ &m("non-shift") } .
36 @Z "" ?. (ks&1)?{ &m("shift") } ?{ &m("non-shift") } .;これだけwindowsに登録
;されてるアプリに取られるけど
* ;正常です。ホットキー。
;警告音、鳴りません。
Windows 7 Professional Service Pack 1 (32 bit) がOSです。
10715/10709 BQO00549 konno Re: 【乞検証】現環境で出来なくなったこと
( 1) 23/03/26 23:27 10709:めざらさんへのコメント コメント数:2
> (1) to Filer
> 60 \[CR] "" ?. #O #m ;to filer ;H_ear
これは単独のマクロにして試しましたが、私の環境では、全てファイラーが開きました。
VZの種類もEMSも関係ないように思われました。DEF のオプションとか環境変数とか?
わかりません。
> (2) mp0で次検索(少し長いです.ごめんなさい)
> ;= ^QF.def = H_ear mp0常用者のいきなり検索・次検索
これは VTDOSではシフト実行が上手くいかないようですね。MS-DOS Player などでは問題なし。
ふと思いついて
> 35 ^R "" ?. (ks&1)??{ #r . } c-, >00
> 36 ^C "" ?. (ks&1)??{ #c . } c+, >00
↓
35 ^R "" ?. k=ks&1, (k)??{ #r . } c-, >00
36 ^C "" ?. k=ks&1, (k)??{ #c . } c+, >00
このように、変数に入れたら、VTDOSでも上手く動きました。
思うに、最近のCPUは速すぎて、シフトチェックのタイミングが微妙なのかと。
この辺の調整は可能なのかもしれませんが、要望したほうが宜しいですかねぇ。
シフトチェックは変数を介したほうが確実とどこかで見たような気が。
> VTDOS 環境では,@A 等の [Alt]+[英字] キーでコマンド/マクロを実行すると
> Windows が警告音を鳴らしてくる.この現象と同根か?
[Alt]+[英字] キーはWindowsで予約されている場合がありますからねぇ。
DOSを優先にするオプションとかあったかなぁ。
10716/10709 CRG00666 文太 Re^2: 【乞検証】現環境で出来なくなったこと
( 1) 23/03/26 23:50 10715:konnoさんへのコメント コメント数:2
konnoさん
以下は、普通に行きますか?
=== Macrotmp by B ===;
* M
36 ^C "" ?. k=ks&1, (k)?{ &m("shift") } ?{ &m("non-shift") } .
36 ^E "" ?. k=ks&1, (k)?{ &m("shift") } ?{ &m("non-shift") } .
*
10717/10682 BQO00549 konno Re^2: xc のバグと対策
( 1) 23/03/26 23:54 10713:文太さんへのコメント コメント数:1
> ただ、古いですね。32KB 近辺のバグは除去されていると思しいです。
高橋さんが直してくれてたんですか、ありがたいですね。
あとは、#B を繰り返し使うと CP がズレたりするのではないかと私は疑っています。
#B を使わないようにマクロを修正できれば安心できるのですが。
> で、マーク4バイトX2で対策しようかとも思っているのですが、昨晩
> 深みにはまってしまい、、、。
すみません、余計なことを言ってしまったようで・・・
10718/10709 BQO00549 konno Re^3: ks&1 は変数に入れたほうが確実
( 1) 23/03/27 00:05 10716:文太さんへのコメント コメント数:1
> 以下は、普通に行きますか?
> 36 ^C "" ?. k=ks&1, (k)?{ &m("shift") } ?{ &m("non-shift") } .
> 36 ^E "" ?. k=ks&1, (k)?{ &m("shift") } ?{ &m("non-shift") } .
はい、VTDOSで普通に表示されます。
文太さんのところでも問題ないですよね?
やはりカッコに入れると上手く動かないんですかね。
STKHLP にありました。
> ※常にその時点のキーの状態を示すため、SHIFT 押下げで動作を
> 変更するマクロでは、最初に k=ks&1 のように保存しておく。
やはりこのほうが確実ということでしょうね。
10719/10682 CRG00666 文太 Re^3: xc のバグと対策
( 1) 23/03/27 00:21 10717:konnoさんへのコメント
konnoさん
あっちの結果報告を待っています。m(__)m
ちょっとビックリしたので。
(xc について)
>高橋さんが直してくれてたんですか、ありがたいですね。
(ロング関数について)
--- vzt.doc ---
◎榊原版Vzより移植
●&Lc・&Id のバグ修正。また、全ての long 演算を符号なしに統一しました。
---------------
少なくともこっちは、榊原さんですね。
xc については、32KBは初耳で(現象確認できず)、64KBは、めざらさんが
仰っていたとおり、「仕様」でしょう。対策法も確立してるし。
高橋さんのvzt.docには記載なし。
>あとは、#B を繰り返し使うと CP がズレたりするのではないかと私は疑っています。
マクロイドとしては、これは困るんですよねぇ。2023年になって、まだこんな
ことを言ってる、、、。としきさん事例ですよね。あれは何なんだろう?
>#B を使わないようにマクロを修正できれば安心できるのですが。
それは、たぶん、ほぼムリ。本質からずれますが、僕は、ブロックを下からした
ことなんてほぼないのです。すると、ほぼ自動的に、#B する。
>> で、マーク4バイトX2で対策しようかとも思っているのですが、
>すみません、余計なことを言ってしまったようで・・・
いえいえ、konnoさんにしては珍しく、他人(ひと)のお尻を叩いている。
はい、叩かれてるなぁ、という自覚はあります。
が、暇をみつけて、他のマクロをやってます、、、。オレ、かなり頭が悪いらしい
という自覚がふつふつ。場合分けができない!
10720/10709 CRG00666 文太 Re^4: ks&1 は変数に入れたほうが確実
( 1) 23/03/27 00:26 10718:konnoさんへのコメント
konnoさん
>文太さんのところでも問題ないですよね?
あります!
>やはりカッコに入れると上手く動かないんですかね。
k に保存してもダメです。
あいかわらず、^\E では、秀丸です!
まいったぁぁぁぁ。
僕のところでは(vtdos環境)、^\C と ^\E だけなので、それを避ければ
いいのですが。何だか、奇妙な制限のつく環境になってるなぁ。
10721/10709 DGF01024 めざら Re^2: 【乞検証】現環境で出来なくなったこと
( 1) 23/03/27 14:16 10715:konnoさんへのコメント
参照先:http://mezala.la.coocan.jp/
> シフトチェックは変数を介したほうが確実とどこかで見たような気が。
うーん,でも,押しっぱなしなのに ks が変わらないとしたら変ですよね。
右シフトとか左シフトとかも何かあるのかなぁ……
to Filer の方は,版とは関係がなさそうで,いよいよ闇の中です。
確かに外部マクロに切り出すと問題がなかったりするのに,
内部マクロとして記述すると「動かない」ではなく「変な動き」。
記述の場所を変えてみるとかしてみるか……
ありえないとは思いつつも,前後の改行コードが変だったりして。
10722/10709 DGF01024 めざら Re^3: 【乞検証】現環境で出来なくなったこと
( 1) 23/03/27 18:54 10716:文太さんへのコメント コメント数:2
参照先:http://mezala.la.coocan.jp/
きゃー! うちも [Shift][Ctrl]E でコンソールファイルみたいなテキストファイルが
notepad(メモ帳)でオープンされたし。うわー,コマンドラインでやったことが全部ある。
ぜんぶ見えてるの,恥ずかしー。(笑)
これ VTDOS の隠しコマンドか何かでしょうかね。
^C は両方とも non-shift だと思ったら,直前のメッセージがそのままっぽいです。
k=ks&1, &t としてみたら,トレースにも入らないです。つまり,無効キー。
^E も同様にしてみたら,やはりトレースする前に例のテキストオープン。
10723/10709 BNY00646 shadow Re^4: 【乞検証】現環境で出来なくなったこと
( 1) 23/03/27 19:49 10722:めざらさんへのコメント コメント数:2
> これ VTDOS の隠しコマンドか何かでしょうかね。
VTDOS.TXTより引用
■ホットキー
通常モード時に次のキーに機能が割り当てられています。
キーアサインはvtdos.cfgで変更できます。
Ctrl+Alt+PageUp バックログモードへ移行
Ctrl+Alt+. カレントディレクトリーでWindowsシェルを起動
Shift+Ctrl+C バックログをクリップボードへコピー
Shift+Ctrl+E バックログの内容でエディターを起動
Shift+Ctrl+F カレントディレクトリーでファイラーを起動
これですね。
10724/10709 DGF01024 めざら Re^4: 【乞検証】現環境で出来なくなったこと
( 1) 23/03/27 20:51 10722:めざらさんへのコメント コメント数:1
参照先:http://mezala.la.coocan.jp/
ksmiru.def 実行してみたら,うちのシフトキーは左右とも 3 だった。。。
何故だろう。謎だ。
= ksmiru.def =
* m
89 ^\ "ksを見る";システム変数 ks の変化を見る
?.
:A a=ks,
(i8){pu.i--='1'-(a&1<<(7-i))!, } ;ビット表示
&m("ks= %3d $%02x %8s",a,a,pu)
:B (a-ks)?>A ;ks が変化したか?
&k (r-$1B)?>B ;ESCが押されてない?
&m("終了")
*
10725/10709 BQO00549 konno Re^5: 原因はVTDOSのバックログ機能だった
( 1) 23/03/27 20:58 10723:shadowさんへのコメント
> これですね。
おお、さすが shadowさん、私はそこまで気が回りませんでした。
私の VTDOS.CFG は
NO_BACKLOG=1
このように、バックログ機能を無効にしていたので気が付かなかったのですね。(^^;
10726/10709 DGF01024 めざら Re^5: 【乞検証】現環境で出来なくなったこと
( 1) 23/03/27 21:01 10723:shadowさんへのコメント コメント数:1
参照先:http://mezala.la.coocan.jp/
shadow さん,ありがとうございます!
> Shift+Ctrl+C バックログをクリップボードへコピー
> Shift+Ctrl+E バックログの内容でエディターを起動
これですね。全然隠しじゃなかった。
おかげでスッキリしました。 m(_'_)m
10727/10709 CRG00666 文太 Re^6: 【乞検証】現環境で出来なくなったこと
( 1) 23/03/27 21:07 10726:めざらさんへのコメント コメント数:1
shadowさん、めざらさん、
>これですね。
ですね! ちゃんと.doc 読め。
サーンクス! ありが10匹!
vtdos.txt、読みまーす!
NO_BACKLOG=1
これで、^\C & ^\E 復活。
Ctrl+Alt+. カレントディレクトリーでWindowsシェルを起動
これはいけるかも。"explorer here" なんですけどね。「カレント」を
編集画面で一生懸命見るのだろうか? そんなマクロを書いたことがある記憶。
どうせファイラへ行くんだろうなぁ。
10728/10709 CRG00666 文太 ゴミ3
( 1) 23/03/27 21:18 10727:文太さんへのコメント
ゴミ・シリーズ、お気に入りみたい。
>「カレント」を編集画面で確認するのか?
--- vz.def ---
* T テキストウィンドウ
"Open File: <$pd> [Now $wc]",76
--------------
と設定してあると、ファイル・オープン窓の上に見えますね。
#O で、リターンでやっぱりそのままファイラに行っちゃいそうですけど。
カレントを調節するために。ぐるぐる、ぐるぐる。
10729/10709 BQO00549 konno Re^5: KS のシフトチェックの値
( 1) 23/03/27 22:51 10724:めざらさんへのコメント コメント数:1
> ksmiru.def 実行してみたら,うちのシフトキーは左右とも 3 だった。。。
> 何故だろう。謎だ。
VTDOS での値ですか?
> = ksmiru.def =
これいいですね。
無入力 左シフト 右シフト
VTDOS 32 35 35
MS-DOS Player 0 3 1
DOSVAXJ3 32 35 33
Win98ME DOS窓 32 35 33
私の環境ではこうなりました。
これは、純DOS と Win窓環境の違いでしょうか。
VTDOS だけ左右が同じなんですね。仕様なのでしょうか。
実用上問題は無いですが、気になりますね。
そういえば、VTDOS環境になってから、(ks&3)? が上手く動かなくて、変数に代入するようになったような。
VTDOSは、(KS&3)? ではシフトチェックの値取得が上手くいかない時があるのでしょうか。
この辺、ダメもとで 10#さんにメールしてみようかな。
10730/10682 BQO00549 konno EK+ で BL3072 の時の挙動
( 1) 23/03/28 00:41 10699:konnoさんへのコメント
[ESC]i マクロの検証では、EK- で BL3072 の時は、全ての環境で NG になりました。
EK+ で BL3072 の時の挙動を確認したら、10#さんの環境が再現出来たようです。
VTDOS+高橋版VZで EMS環境で EK+, BL3072 の時、正常処理されました。
[F02]の後の比較マクロで6か所相違が出ます。修正VZでは一致します。
これは、XMS環境でも同じでした。
オリジナルVZでは、EMS環境でも XMS環境でもラップアラウンドエラーで、VZが落ちます。
MS-DOS Player と DOSVAXJ3 では、EMS環境でも XMS環境でも NG になりました。
試した全てのVZでファイルサイズが増える同じ壊れ方でした。
EK+ で BL3072 の時 VTDOS だけが正常処理されるとは、ビックリです! (゚゚;)
# このあたりに時空の歪みの境界があるのでしょうか。(@.@)
10731/10709 DGF01024 めざら Re^6: KS のシフトチェックの値
( 1) 23/03/28 22:04 10729:konnoさんへのコメント コメント数:1
参照先:http://mezala.la.coocan.jp/
ksmiru.def は榊原さんのナイスな小物マクロです。
konno さんの環境は常に Numlock が立ってるのですね。
もしかして,本体連動しないテンキーとか接続していたりします?
(それか,デスクトップのフルキーボードって Numlock 立ってるのでしたっけ?)
無入力 左シフト 右シフト
VTDOS 0 3 3
所期の値 0 3 1
> この辺、ダメもとで 10#さんにメールしてみようかな。
ホットキーの事例もあることだし,まずは皆さまのコメントを待ちましょうか。(笑)
10732/10709 BQO00549 konno Re^7: KS のシフトチェックの値
( 1) 23/03/29 02:50 10731:めざらさんへのコメント コメント数:1
> ksmiru.def は榊原さんのナイスな小物マクロです。
そうだったのですか、2進数の表示は凄いと思いました。読めないし。(^^;
> konno さんの環境は常に Numlock が立ってるのですね。
> もしかして,本体連動しないテンキーとか接続していたりします?
> (それか,デスクトップのフルキーボードって Numlock 立ってるのでしたっけ?)
富士通の10キー付ノートPCです。Numlock が無いと使えないのです。
そうか、$20 32 は、Numlock が立っていたのですね。全然気が付きませんでした。
このマクロでの数値は
STKHLP IBM版表示 VTDOS MSDOSPlayer DOSVAXJ3
+1 :R[Shift] 3 1 1
+3 :L[Shift] 3 3 3
+4 : [Ctrl] 4 4 4
+8 : [Alt] 8 8 8
+16: [ScLk] 16
+32: [NmLk] 32 32
+64: [Caps] 64
+128: [Ins] 128
DOSVAXJ3 の [Caps] は、1度押しでIME起動、2度目以降は [Caps]ON 表示のままになります。
他のエミュでは、IME に取られるのか、表示が出ないですね。
この KS の値は、AH02 INT16h BIOSコールの値とほぼ同じですが、シフトだけ違います。
ax$0200,&i($16) k=ax,&m("key= %04x %d",k,k%256) ;AH02h shift check
STKHLP IBM版表示 VTDOS MSDOSPlayer DOSVAXJ3
+1 :R[Shift] 3 1 1
+3 :L[Shift] 3 2 2
これは、.vz1.5 の時の値ですね、1.6 ではvzが値を変更しているのかな。
AH12 INT16h BIOSコールは、AH02 の値とほぼ同じですが、違いもあります。
81 ^^ "keyshift?"
?.
:a
; ax$0200,&i($16) k=ax,&m("key= %04x %d",k,k%256) ;AH02h shift check
ax$1200,&i($16) k=ax,&m("key= %04x %d",k,k%256) ;AH12h (enh) shift check
&w(10)
&k (r-$1B)?>a ;ESCが押されてない?
&m("") &d .
*
AH12h (enh) shift check では、VTDOSで
+16: [ScLk]
key= 1000 0
このように、ah に 10h が入りますね。微妙な違いです。(^^;
> > この辺、ダメもとで 10#さんにメールしてみようかな。
>
> ホットキーの事例もあることだし,まずは皆さまのコメントを待ちましょうか。(笑)
メールしちゃいました。(^^;
やっぱり WinAPIの仕様らしいです。
>Win32Consoleの仕様を理解して貰えれば話は早いのですが、
>VTDOSはDOSコマンドとWin32コンソールコマンドをシームレスに扱う為に、
>Win32ConsoleをUIとすることが第一要件になってます。
>DOSキー入力の元はCONIN$からのキーイベントで、シフト状態もこれから生成しています。
>これはキューイングされたイベントなのでリアルタイムなシフト状態という訳ではありませんが、
>概ねリアルタイムな物となります。
>このキーイベントの仕様としてシフトだけが何故か左右の区別がありません。
>この仕様に則った場合、コンソールでの貼り付けが利用可能になります。
>貼り付けをサポートするのもこの仕様を採用する理由ですが、貼り付けの仕様上、
>シフト状態がリアルタイムな物である事を保証するものではありません。
仕様ということで、あとは直に変数に代入することで問題なく使えると思います。
10733/10709 CRG00666 文太 Re^8: KS のシフトチェックの値
( 1) 23/03/29 13:27 10732:konnoさんへのコメント コメント数:1
無意味な報告ですが。WinAPI の仕様。うーん、この手のことまで
処理してくれるAPIがあるものなんだ、、、。
無入力 左シフト 右シフト
VTDOS 0 3 3
WinME 0 3 1
でした。上はめざらさんのほぼ丸写しですが、実験はちゃんとしてます。
10734/10734 BNY00646 shadow VTDOS & VZでファイル名が異常
( 1) 23/03/29 20:56 コメント数:3
ファイル名に = が入っていると変な現象が起こります。
例えば
windowsで abc=.txt のファイルを作成
VTDOS で dir すると
abc=.txt 問題なし
vzを起動しfilerで見ると
abc_~1.txt
上記の表示になります。
Rename と ロングファイル名表示は問題ありません。
ショートファイル名で = の箇所が _~1 の表示になります。
全てのVZで同じことがおきます。
皆さんの環境ではどうなんでしょうか?
10735/10709 BQO00549 konno Re^9: KS のシフトチェックの値
( 1) 23/03/29 22:31 10733:文太さんへのコメント コメント数:1
> 無意味な報告ですが。WinAPI の仕様。うーん、この手のことまで
> 処理してくれるAPIがあるものなんだ、、、。
必ずしもDOSコールの上位互換ではないというところが、痛しかゆしですよね。(^^;
> 無入力 左シフト 右シフト
> VTDOS 0 3 3
> WinME 0 3 1
> でした。上はめざらさんのほぼ丸写しですが、実験はちゃんとしてます。
確認頂きありがとうございます。やはり同じですね。
10736/10734 BQO00549 konno Re: VTDOS & VZでファイル名が異常
( 1) 23/03/29 22:39 10734:shadowさんへのコメント コメント数:1
> ファイル名に = が入っていると変な現象が起こります。
'=' は、ショートファイル名に使えない文字なのではないでしょうか。
純DOSエミュのNP2 で試すと、無効なパス名と怒られます。
これだけでは何なので、ネットで検索すると
http://elm-chan.org/docs/fat.html#lfn
こちらのサイトから引用すると
-----------------------------------------------------------
短いファイル名
短いファイル名では、8バイトまでのボディとオプションのドット(.)+3バイトまでの拡張子に制限される、いわゆる8.3形式のファイル名が使用できます。
パス名のトータル長は、3バイトのドライブ文字 + 64バイトのパス + 12バイトのファイル名の合計79バイトとなります。
ファイル名を構成する文字は、ASCII英数と一部のASCII記号$%'-_@~`!(){}^#&および拡張文字(非ASCII文字)の任意の組み合わせが可能です。
長いファイル名
LFNでは、255文字までのファイル名が使用可能です。
使用可能な文字は、SFNで使用可能な文字全てに+,;=[]が加わっています。
ドットはファイル名の中にいくつでも含めることができ、スペースもファイル名の任意の位置に挿入することができます。
ただし、ファイル名の末尾に来るドットやスペースは無効で、API入力の段階で除去・無視されます。
ファイル名の先頭に来るドットやスペースは有効ですが、UIによっては(たとえばWindowsコモンダイアログ)これらのファイル名を入力できません。
LFNエントリには、大文字変換は行わずに入力のままの形のUnicode(UTF-16)文字列として格納されます。
-----------------------------------------------------------
このように書いていました。
各種DOSエミュでは、'=' があるとロング名として扱っていると思われます。
10737/10734 CRG00666 文太 Re: VTDOS & VZでファイル名が異常
( 1) 23/03/29 23:16 10734:shadowさんへのコメント コメント数:2
shadowさん
あはははは。「確定申告」は必要だから困るんだよ、というのは分かる。
でも、なんでまた、そのような冒険を?
ほんとに必要なのですか?
とにかく、DOS 6.2V のドコモバのVzファイラではファイルが作れません
でした。ここのcommand.com は、「Invalid keyword」と言っていました。
ネットでは、「それは代入の意味になっちゃうから、クゥートに入れない
とダメなの」みたいな書き込みがありました。Win LFN 環境。
なんだろう、パソコンに意味のある記号を裸でコマンドラインには書けない
みたいなニュアンスでした。
vtdos環境だとVzファイラでファイルは作れるが、仰るとおり、a_b~1.txt
になりますね。LFN扱いなのでしょう。そしてその際、= -> _ 変換が
(見た目上?)入るのでしょうかね?
a=b.txtを作ろうとしたときの話です。
なお、秀丸からa=b.txtでファイル保存をしようとしたら、ちゃんと上書きを
尋ねてきました。a_b~1.txtが内部的に(?)a=b.txtと認識されているみたい
でした。
もう迷宮入りみたいなものですが。以下、Win7 環境。
>dir a=b.txt (command.com)
File Not Found
>dir a_b~1.txt (command.com)
2023/03/29 22:58 5 a=b.txt
>dir a=b.txt (cmd.exe)
2023/03/29 22:58 5 a=b.txt
>dir a_b~1.txt (cmd.exe)
2023/03/29 22:58 5 a=b.txt
とのことでした。(5 は 5 bytes)
もちろん僕は詳しい仕組み(理屈)をまったく知りません。
10738/10709 CRG00666 文太 Re^10: KS のシフトチェックの値
( 1) 23/03/29 23:22 10735:konnoさんへのコメント
konnoさん
深追いしてもしょうがない話ですが。
STKHLP IBM版表示 VTDOS MSDOSPlayer DOSVAXJ3
+1 :R[Shift] 3 1 1
+3 :L[Shift] 3 3 3
というのを見ると、そのAPI、C++か何かで書きなおせるん
だろうな、とか空想しました。
MSDOSPlayer, DOSVAXJ3 の作者さんも、そのAPIを使ってますよね、
きっと。
それより、上の調査、ありがとうございました。VTDOSしか使わない
にしても、他のエミュとの比較は有効ですね。自分ではしないのだけど、、、。
たしゃぁ〜 m(__)m
10739/10734 DGF01024 めざら Re: VTDOS & VZでファイル名が異常
( 1) 23/03/30 08:39 10734:shadowさんへのコメント コメント数:1
参照先:http://mezala.la.coocan.jp/
小文字で abc だからかな?と思い,エクスプローラで大文字の ABCD=.txt を作り,
確認したところ,ABCD_~1.TXT と表示された。あ,拡張子が小文字だった,と思って,
同様に ABCDE=.TXT を作ったところが,やはり ABCDE_~1.TXT と表示された。
という状況となりました。
これは,すごく古い vzk(例えば vzk5 とか)で同様になりますね。
「=」の制限は,cmd.exe にあるくらいで,ファイル名としては制限ないようです。
10740/10734 BNY00646 shadow Re^2: VTDOS & VZでファイル名が異常
( 1) 23/03/30 08:39 10736:konnoさんへのコメント
色々調べていただき有難うございます。
> 使用可能な文字は、SFNで使用可能な文字全てに+,;=[]が加わっています。
私が調べた使用可能な文字はLFNの方だったようです。
早とちりしていました。
10741/10734 BNY00646 shadow Re^2: VTDOS & VZでファイル名が異常
( 1) 23/03/30 08:53 10737:文太さんへのコメント コメント数:1
> でも、なんでまた、そのような冒険を?
> ほんとに必要なのですか?
と聞かれれば必要じゃないです。
興味本位です。
ブラウザで調べた情報をコピペしてエディターで一時保存しています。
保存するときに1行目がファイル名になるのでそのまま保存しているのですよ。
たまたま=が含まれていたのです。
清書のためVZで開くときに気づいたのでした。
10742/10734 BNY00646 shadow Re^2: VTDOS & VZでファイル名が異常
( 1) 23/03/30 13:31 10739:めざらさんへのコメント
> 「=」の制限は,cmd.exe にあるくらいで,ファイル名としては制限ないようです。
VTDOS.CFG設定のUSECMD=0|1
ビルトインコマンドの実行にCMD.EXEを利用します。とありました。
USECMD=0 に設定すると
VZの新規ファイル作成で abc=.txt を作ると
dirでもABC_~1.TXTと表示されました。
エミュレーターの仕様であることがわかったので良しです。
10743/10734 CRG00666 文太 Re^3: VTDOS & VZでファイル名が異常
( 1) 23/03/30 14:04 10741:shadowさんへのコメント コメント数:1
shadowさん
すばらしいですね!
うん、LFN <-> SFN の話でなく、その情報管理システム。
ワードですよね、1行目がとりあえずのファイル名になるの。
そして、「一時保存」と「清書」のシステム。
いやあ、何度も同じこと、グーグル先生にお聞きしておりますなぁ、という
場面はたしかにあり、どんどん消失してゆく記憶力にもかかわらず、道具立てで
解決にのぞむ根性にかけておりました。
がんばります!
10745/10734 CRG00666 文太 事故レス
( 1) 23/03/30 14:49 10737:文太さんへのコメント コメント数:1
昨晩のテストがどうも奇妙な気がしてきたので、やり直しました。
--- (1)vtdos, usecmd=1, cmd.exe used
C:\>dir a_b~1.txt ;OK
2023/03/29 22:58 5 a=b.txt
C:\>dir a=b.txt ;NG
ファイルが見つかりません ;でも、なんで日本語? command.com + biling.sys
;で、日本語メッセージなのじゃなかったか?
C:\>dir "a=b.txt" ;OK
2023/03/29 22:58 5 a=b.txt
--- (2)vtdos, usecmd=0, cmd.exe NOT used, command.com v.6.2 used
C:\>dir a_b~1.txt ;OK
A_B~1 TXT 5 23-03-29 22:58
C:\>dir a=b.txt ;NG
無効なキーワードです. - a=b.txt
C:\>dir "a=b.txt" ;NG
パラメータの書式が違います. - "a=b.txt"
--- (3)「コマンドプロンプト」窓 = cmd.exe
C:\>dir a_b~1.txt ;OK
2023/03/29 22:58 5 a=b.txt
C:\>dir a=b.txt ;NG
File Not Found
C:\>dir "a=b.txt" ;OK
2023/03/29 22:58 5 a=b.txt
cmd.exeが変に見えるのは、クゥオートがないせいです。
少しだけ追記。さっき、めざらさんあてに「cmd.exe、変ですか?」という主旨の
発言をアップし、そして削除しました。
そこに書いたもう1つの点は、CUIのコマンドラインには、(たとえば引数の
区切りに半角スペースを使うなど)、そもそも制限条件があり、その影響で、
ファイル名とその扱い(クゥオートなど)にGUIにはない条件がでるのでは?
ということでした。
全体に、上で納得しました。
追記:Vzファイラでも、lf+ にすれば、ちゃんと、「a=b.txt」と
表示されました。
追記2:しつこいですねぇ。usecmd=1 環境です。vtdos窓です。
C:\>dir |more
だだだ、、、 cut
2023/03/29 22:58 5 a=b.txt
だだだ、、、 cut
コマンドラインで【その】ファイル名を指定したりしなければ、
ふつうに出ますね。これって驚くべきことなんだっけ? いえ、全体に
整合してると思います。
10746/10734 DGF01024 めざら Re: 事故レス
( 1) 23/03/30 18:54 10745:文太さんへのコメント コメント数:1
参照先:http://mezala.la.coocan.jp/
> cmd.exeが変に見えるのは、クゥオートがないせいです。
そうですね。要するに,文太さんがおっしゃるとおり,空白入りファイル名と同様に
コマンドラインでは引用符で括らないとダメという話でしたね。直接の関係なし。
事故?
10747/10734 BQO00549 konno ロング名のあれこれ
( 1) 23/03/30 19:33 10743:文太さんへのコメント
皆さん盛り上がっていますね。
私もまとめ的に、エミュ三種の盛り合わせを。(^^;
各種DOSエミュで、DIR してみました。
VTDOS USECMD=1 VZk常駐/非常駐 MSDOS6.2
D:\01 のディレクトリ
2023/03/30 15:26 0 MS=.txt
2023/03/30 15:26 0 MSs=.txt
2023/03/30 15:36 0 VT=.txt
VTDOS USECMD=0 VZk常駐/非常駐 MSDOS6.2
Directory of D:\01
MS_~1 TXT 0 23-03-30 15:26
MSS_~1 TXT 0 23-03-30 15:26
VT_~1 TXT 0 23-03-30 15:36
※ USECMD=0 だと、ショート名になるんですね、メッセージも英語に。(^^;
MS-DOS Player FreeCOM
D:\01 のディレクトリ
MS_~1 TXT 0 23/03/30 15:26
MSS_~1 TXT 0 23/03/30 15:26
VT_~1 TXT 0 23/03/30 15:36
DOSVAXJ3
ディレクトリは D:\01\
MS= TXT 0 2023-03-30 15:26 MS=.txt
MSS= TXT 0 2023-03-30 15:26 MSs=.txt
VT= TXT 0 2023-03-30 15:36 VT=.txt
楽天01~1 TXT 68 2023-02-19 22:51 楽天0123456789 01.txt
おや? 何か変ですね。
ショート名なのに "=" 表示になっています。
LFNでは、SFNで使用可能な文字全てに+,;=[]が加わっています。とありますが、
ファイル名に "=" を使うと、他のエミュではロング名として作成されますが、
DOSVAXJ3 では新規作成できません。
これは、作者様に、別件でメールしました。
# アイドル推しが増えるかもしれないの。嬉しい!!
# 「なんてったって アイドル」 と言えば、誰?
10748/10734 CRG00666 文太 Re^2: 事故レス
( 1) 23/03/30 21:10 10746:めざらさんへのコメント
>事故?
(1) 昨晩のテストに間違いが含まれていた。
(2) 削除されためざらさん宛のレスに「cmd.exe、変?」「たしかに変ですね」
というのが含まれていた。
そんな事故でした。