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

  VTDOS140 - konno 14/05/19-07:24 No.6482
  ┗ Re: VTDOS140 - shadow 14/05/20-21:30 No.6483
   ┗ Re^2: VTDOS140 - konno 14/05/21-00:54 No.6484
    ┗ Re^3: VTDOS140 - 10# 14/05/21-01:36 No.6485
     ┗ Re^4: VTDOS140 - shadow 14/05/21-21:49 No.6486
      ┣ Re^5: VTDOS140 - 文太 14/05/21-22:31 No.6487
      ┃┣ 脱線で、どうでもいいこと - 文太 14/05/21-22:54 No.6488
      ┃┗ Re^6: VTDOS140 - shadow 14/05/22-21:18 No.6491
      ┃ ┗ Re^7: VTDOS140 - 文太 14/05/22-23:09 No.6493
      ┗ Re^5: VTDOS140 - 10# 14/05/21-23:52 No.6489
       ┣ Re^6: VTDOS140 - 文太 14/05/22-00:23 No.6490
       ┗ Re^6: VTDOS140 - shadow 14/05/22-21:46 No.6492
        ┣ Re^7: VTDOS140 - konno 14/05/25-03:50 No.6494
        ┃┗ Re^8: VTDOS140 - 10# 14/05/25-17:10 No.6495
        ┃ ┗ Re^9: VTDOS140でのlxschd.def の挙動 - konno 14/05/26-02:06 No.6499
        ┃  ┣ Re^10: VTDOS140でのlxschd.def の挙動 - 文太 14/05/26-23:06 No.6500
        ┃  ┃┣ おもに独り言 - 文太 14/05/26-23:42 No.6501
        ┃  ┃┃┣ さて、C:¥を使うべきか。 - 文太 14/05/27-21:56 No.6502
        ┃  ┃┃┗ Re: おもに独り言 - konno 14/05/27-22:40 No.6504
        ┃  ┃┃ ┗ Re^2: おもに独り言 - 文太 14/05/27-23:12 No.6505
        ┃  ┃┗ Re^11: VTDOS140でのlxschd.def の挙動 - konno 14/05/27-22:15 No.6503
        ┃  ┃ ┗ Re^12: Win7のUAC問題 - konno 14/06/14-22:31 No.6550
        ┃  ┗ Re^10: VTDOS140でのlxschd.def の挙動 - 10# 14/05/28-01:06 No.6506
        ┃   ┣ Re^11: VTDOS140でのlxschd.def の挙動 - 文太 14/05/28-01:49 No.6507
        ┃   ┗ Re^11: VTDOS140でのlxschd.def の挙動 - konno 14/05/28-07:31 No.6508
        ┃    ┗ Re^12: VTDOS140でのlxschd.def の挙動 - 文太 14/05/28-12:28 No.6509
        ┃     ┗ Re^13: VTDOS140でのlxschd.def の挙動 - konno 14/05/28-23:43 No.6510
        ┃      ┗ Re^14: VTDOS140でのlxschd.def の挙動 - 10# 14/05/29-01:23 No.6511
        ┃       ┣ Re^15: VTDOS140でのlxschd.def の挙動 - 文太 14/05/29-01:45 No.6512
        ┃       ┃┗ 64000 bytes のファイル - 文太 14/05/29-01:57 No.6513
        ┃       ┗ Re^15: VTDOS140でのlxschd.def の再現手順 - konno 14/05/29-21:46 No.6514
        ┃        ┗ Re^16: VTDOS140でのlxschd.def の再現手順 - 10# 14/05/30-00:23 No.6515
        ┃         ┗ Re^17: VTDOS140でのlxschd.def の再現手順 - konno 14/05/30-01:28 No.6516
        ┃          ┣ Re^18: VTDOS140でのlxschd.def の再現手順 - 文太 14/05/30-09:06 No.6517
        ┃          ┗ Re^18: VTDOS140でのlxschd.def の再現手順 - 10# 14/05/31-00:37 No.6520
        ┃           ┗ Re^19: VTDOS140でのlxschd.def の再現手順 - 文太 14/05/31-09:19 No.6521
        ┃            ┗ Re^20: VTDOS140でのlxschd.def の再現手順 - konno 14/05/31-19:35 No.6522
        ┃             ┣ Re^21: VTDOS140でのlxschd.def の再現手順 - 文太 14/05/31-21:31 No.6523
        ┃             ┃┗ Re^22: VTDOS140でのlxschd.def の再現手順 - konno 14/06/01-14:06 No.6526
        ┃             ┃ ┗ Re^23: VTDOS140でのlxschd.def の再現手順 - 文太 14/06/01-18:57 No.6528
        ┃             ┃  ┗ データ、プログラムの所在地 (lxschd.def) - 文太 14/06/01-19:13 No.6529
        ┃             ┗ Re^21: VTDOS140でのlxschd.def の再現手順 - 10# 14/06/01-01:59 No.6525
        ┃              ┗ Re^22: VTDOS140でのlxschd.def の再現手順 - konno 14/06/01-15:13 No.6527
        ┃               ┗ Re^23: VTDOS140でのlxschd.def の再現手順 - 10# 14/06/02-01:56 No.6530
        ┃                ┗ Re^24: VTDOS140でのlxschd.def の再現手順 - 文太 14/06/02-12:52 No.6531
        ┃                 ┣ Re^25: VTDOS140でのlxschd.def の再現手順 - 文太 14/06/02-14:30 No.6532
        ┃                 ┣ &z()のバグ - 文太 14/06/02-14:50 No.6533
        ┃                 ┃┗ 【資料】 &z()のバグ - 文太 14/06/02-17:10 No.6534
        ┃                 ┗ Re^25: 解決!VTDOSでのlxschd.def 設定 - konno 14/06/03-00:14 No.6535
        ┃                  ┣ Re^26: 解決!VTDOSでのlxschd.def 設定 - 10# 14/06/03-00:34 No.6536
        ┃                  ┃┗ Re^27: 解決!VTDOSでのlxschd.def 設定 - 文太 14/06/03-00:46 No.6537
        ┃                  ┗ Re^26: 解決!VTDOSでのlxschd.def 設定 - 10# 14/06/03-23:45 No.6538
        ┃                   ┣ 追加情報 - 文太 14/06/04-01:01 No.6539
        ┃                   ┗ Re^27: 解決!VTDOSでのlxschd.def 設定 - konno 14/06/04-22:48 No.6540
        ┃                    ┣ Re^28: 解決!VTDOSでのlxschd.def 設定 - 文太 14/06/05-00:37 No.6541
        ┃                    ┣ Re^28: 解決!VTDOSでのlxschd.def 設定 - 10# 14/06/05-01:22 No.6542
        ┃                    ┃┗ Re^29: 解決!VTDOSでのlxschd.def 設定 - konno 14/06/06-00:14 No.6544
        ┃                    ┗ Re^28: 解決!VTDOSでのlxschd.def 設定 - 10# 14/06/05-22:55 No.6543
        ┃                     ┣ Re^29: 解決!VTDOSでのlxschd.def 設定 - 文太 14/06/06-00:27 No.6545
        ┃                     ┗ Re^29: 解決!VTDOSでのlxschd.def 設定 - konno 14/06/06-00:34 No.6546
        ┃                      ┗ Re^30: 解決!VTDOSでのlxschd.def 設定 - 10# 14/06/06-23:56 No.6547
        ┃                       ┗ Re^31: 解決!VTDOSでのlxschd.def 設定 - konno 14/06/07-01:56 No.6548
        ┗ Re^7: VTDOS140 - 10# 14/05/25-17:13 No.6496
         ┗ Re^8: VTDOS140 - shadow 14/05/25-19:16 No.6497
          ┗ Re^9: VTDOS140 - shadow 14/05/25-20:17 No.6498
           ┗ Re^10: VTDOS140 - 10# 14/05/30-23:51 No.6519
            ┗ MASM の歴史 - 文太 14/06/01-00:50 No.6524

(6482) 6482VTDOS140  投稿者:konno   2014/05/19(月) 07:24
   コメント数 1

VTDOS1.40 が出ました。

まずはVTDOS掲示板からの引用

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

今回の主な変更点はANSIシーケンスによるV-TEXTエミュレーションを実装し、
Wineでの動作を実現しました。

DOSのコンソール出力は、ANSIシーケンスを多段に処理するという、
意味不明なことが起こってます。(^^;)

Linux上でDOS用のUnixクローンlsを実行してディレクトリを表示するなどの、
シュールな操作も可能になります。

その他、$xsetを拡張しました。

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

ということで、詳細はおいおい検証してみますが、まずは気になるパフォーマンスを。

VTDOS単体では40%ほどになっています。1.37と同等か、より速くなった感じです。
カーソル移動もページ送りも速くなりました。

CKWV連動だと54〜58%ほどでこちらも上がっています。
カーソル移動もページ送りも速くなり、もたつきは感じません。
ばっちりです。(^_^)

10#さん、ありがとうございます。

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

(6482) 6483Re: VTDOS140  投稿者:shadow   2014/05/20(火) 21:30
    6482 番 konno さんへのコメント    コメント数 1

お久しぶりです。
プログラマではないので難しいことはわかりませんが下記のような現象が起こります。

win8.1 x64 VTDOS140において
VZK07S3のソースをアセンブルすると下記のエラーが出ます。

VZ非常駐のコマンドラインから実行するとエラーが出ます。
ml /Zm /VM /c /Cp %MASM% main.asm
ml /Zm /VM /c /Cp %MASM% scrn.asm

Out of environment space
Microsoft (R) Macro Assembler Version 6.00B
Copyright (C) Microsoft Corp 1981-1992. All rights reserved.

Assembling: scrn.asm
error A4910: cannot open file:
scrnIBM.asm(1881): warning A6: : chkkanjilow
scrnIBM.asm(1894): error A2006: : chkkanjilow
Microsoft (R) Macro Assembler Version 6.00B
Copyright (C) Microsoft Corp 1981-1992. All rights reserved.

VZ常駐のコマンドラインでは問題なくアセンブルできます。
また、VTDOS137ではVZ非常駐でも問題なくアセンブルできます。

私の環境だけの現象でしょうか?

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

(6482) 6484Re^2: VTDOS140  投稿者:konno   2014/05/21(水) 00:54
    6483 番 shadow さんへのコメント    コメント数 1

shadowさん

> VZ常駐のコマンドラインでは問題なくアセンブルできます。
> また、VTDOS137ではVZ非常駐でも問題なくアセンブルできます。
> 私の環境だけの現象でしょうか?

$xsetは使用されていますよね。

1.38以降、環境変数の扱いが変更になっています。
set の代わりに $xset や yset のような拡張SET 使用する必要があります。
path =    も同様なので
$xset path =  のように変更します。

これで問題が出るのであれば、10#さんに報告したほうがいいでしょうね。
いままでVZ無しでアセンブルしたことないからなぁ。

うう、うちでVZの常駐解除して MK6.bat (アセンブルバッチ)実行したらエラーで落ちた。(;_;)

2014-05-21 00:23:57 VZIBMJ(25FB) 0003:2096 '無効命令 66'
2014-05-21 00:25:16 COMMAND(014F) 014F:0197 '無効命令 0F'

あれ? もう一度やってみたらもうエラーが出ない?
最初のエラーはVZのVer違いか、その影響かも。

POWERSENSITIVITY=0 にしているのでタイミングの問題かも。
POWERSENSITIVITY=3000 くらいにして様子をみてみます。
そういえばうちはコンベンショナルメモリも拡張しているなぁ。
TPAEXT=1
TPALOW=1

shadowさんの設定はどうなっていますか。

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

(6482) 6485Re^3: VTDOS140  投稿者:10#   2014/05/21(水) 01:36
    6484 番 konno さんへのコメント    コメント数 1

$xset は32bit関連だったと思いますが、 masm6は16bitですよね。

Windows 8.1 x64 での不安定感は僕も経験があります。
command.comの無効命令 0F は割かし頻度高いです。
なぜか7x64では出ないんです、これが。

1.38で導入したUMB関連を一番疑っていますので、
頃合を見て調整を検討しています。

あと、文太さんが経験されている文字化けを、
僕も1.40で頻発するようになってるので、
次回アップデートの課題にしています。

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

(6482) 6486Re^4: VTDOS140  投稿者:shadow   2014/05/21(水) 21:49
    6485 番 10# さんへのコメント    コメント数 2

konno さん
10#さん

> $xsetは使用されていますよね。
環境変数に同様の問題があったので$xsetを使っています。
あっ、アセンブルバッチのsetは変更していませんでした。
$xset HARD=IBMJ
$xset MASM=/DIBMJ
に変更してアセンブルしてみると
2014-05-21 19:20:54 ML(2EF3) 51C3:A812 'HMA REP MOVSW'
2014-05-21 19:20:54 ML(2EF3) 51C3:A816 'HMA REP MOVSB'
このようなログが60行ほど出ています。
setのままアセンブルすると上記のエラー+下記も出ています。
2014-05-21 19:20:54 COMMAND(2E5E) 9576:2ACD 'Win32コンソールプロセス起動エラー 87 'CMD /C dir vzIBM.com''

> shadowさんの設定はどうなっていますか。
私の設定は下記のとおりです。

POWERSENSITIVIT=1500
USECMD=1
TPALOW=0
TPAEXT=0
UMB=64

因みに、UMBをコメントにしてアセンブルすると無限ループに入るのでXで閉じることになります。
アセンブルはソースの話題が出ていたのでたまたま試しただけなので通常の使用では問題ないのでアップデートは気長に待っています。
      - No.6486 -    このTreeへ    コメント元:6485 へ [リストへもどる] soft

(6482) 6487Re^5: VTDOS140  投稿者:文太   2014/05/21(水) 22:31
    6486 番 shadow さんへのコメント    コメント数 2

皆様

 PCばかりでなく人生全体の調子が悪いので、出遅れております。
 今日も秀丸からの文太です。
 文字化けが10#さんのところでも出たようで、よかった(って言って
よいのか)。
 shadowさん、たぶん手で写されたのだと思うので問題ないと思いますが、
powersensitivitYです。vtdos.cfgに意味不明の言葉があると読み飛ばして
くれるのでしょうか。ああ、UMBがいっぱい。
 環境変数ばかりか、ほんとクリップボード近辺がおかしいです。これは
vtdosが原因ではなく。その切り分けだけは、できたのだけど、、、。やれやれ。
      - No.6487 -    このTreeへ    コメント元:6486 へ [リストへもどる] soft

(6482) 6488脱線で、どうでもいいこと  投稿者:文太   2014/05/21(水) 22:54
    6487 番 文太 さんへのコメント

 ああ、上げなきゃよかった。↑
 clppset.exeの実行ファイルが壊れていた、というオチでした。
 どこでどうやって壊したのだか。
 やっとvtdosなしXP+ATOK8まで戻りました。

--- vtd_err.log ---
2014-05-19 21:23:50 CLPPST(1720) 7370:0077 '無効命令 00'
2014-05-19 21:33:13 CLPPST(1720) 7370:0077 '無効命令 00'
2014-05-20 23:24:07 CLPPST(1720) 7370:0077 '無効命令 00'
2014-05-21 12:27:22 CLPPST(1720) 7370:0077 '無効命令 00'
2014-05-21 21:13:34 CLPPST(1722) 7370:000D '無効命令 00'
2014-05-21 22:38:33 CLPPST(16A5) 2868:00BD '無効命令 6E'
2014-05-21 22:38:33 COMMAND(10AC) 0728:8D74 '無効命令 67'

 3日間ですよ。でもね、「これはvtdosが原因ではない」と正しく直観
しておりましたよん。
 もしかしたら泣き顔を見られたかもしれないけど。汗。

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

(6482) 6491Re^6: VTDOS140  投稿者:shadow   2014/05/22(木) 21:18
    6487 番 文太 さんへのコメント    コメント数 1

文太さん

vtdos.cfgから間違っていたので修正しました。
一度入力して問題なく動作していると自分では気づかないですね。

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

(6482) 6493Re^7: VTDOS140  投稿者:文太   2014/05/22(木) 23:09
    6491 番 shadow さんへのコメント

shadowさん

 #6492, 完璧なレポートですね。さすがです。テスターの鏡です。

 以下ですが、

>vtdos.cfgから間違っていたので修正しました。
>一度入力して問題なく動作していると自分では気づかないですね。

 ああ、コピペで元々が間違っていたんですね。
 後半の「問題なく動作している」については曖昧かな、僕にはよく
わからないぞ、と思いました。

 デフォルト(注)で動き、その指定(POWERSENSITIVIT=1500 <-最後の
Y抜け)は無視されていた可能性が高いように思いました。(偶然?)結果
は同じですが。
 無指定・無記述でデフォルト動作みたいですよ。TPALOWとか僕は書いて
ないし。

 こんな実験をして、エラーメッセージもなく起動できましたから。

--- vtdos.cfg ---
SHELL=c:\vtdos\command.com /e:8192 /p /msg /k c:\vtdos\vtvz.bat
;POWERSENSITIVITY=3000
POWER=3000		;読み飛ばしなのだろう

(注)
--- vtdos.txt ---
POWERSENSITIVITY=n
  アイドル検出の感度を指定します。デフォルトは1500で小さいほど省電力。
  0で負荷管理無効


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

(6482) 6489Re^5: VTDOS140  投稿者:10#   2014/05/21(水) 23:52
    6486 番 shadow さんへのコメント    コメント数 2

Win32コンソールの87は環境変数ですので、やはり$xset推奨に該当します。
MLのHMA警告は以前のVTDOSでは出てませんか?

UMB(というかMCB構成)の問題は、多少手を入れつつ様子を見てますが、
まだ改善には至っていません。
UMB=0で発生する現象はヒントになるかもしれません。

キー文字化けは修正できたっぽいのですが、
この不具合は1.40で出来たものなので、文太さんの現象はやはり原因不明です。

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

(6482) 6490Re^6: VTDOS140  投稿者:文太   2014/05/22(木) 00:23
    6489 番 10# さんへのコメント

10#さん

>キー文字化けは修正できたっぽいのですが、
>この不具合は1.40で出来たものなので、文太さんの現象はやはり原因不明です。

 了解です。ようやく、VTDOS 140に追いつけたと思いますので、観察を継続します。


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

(6482) 6492Re^6: VTDOS140  投稿者:shadow   2014/05/22(木) 21:46
    6489 番 10# さんへのコメント    コメント数 2

command.comによって挙動に差がありました。

MS-DOS6.2は常駐・非常駐共に問題なくアセンブルできました。
PC-DOS7.0(IBMDFT)とPC-DOS2000は常駐では問題なく非常駐ではアセンブルできず。
freecomは常駐では問題なく、非常駐ではmlが起動直後に固まります。

いずれもHMAの警告は出ています。



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

(6482) 6494Re^7: VTDOS140  投稿者:konno   2014/05/25(日) 03:50
    6492 番 shadow さんへのコメント    コメント数 1

shadowさん

1.40は何かありそうですね。
vz.comをリネームしたら最近のVTDOSは全て起動BATで落ちてしまい、久しぶりに
DOS窓VZを立ち上げて修正しました。

検証不足ですが、LXSCHD.DEFのスケジュール追加でファイルの内容が一部入れ替わって
しまいます。
保存前は正常に見えます。

1.38 と 1.40 で同じ現象が起きます。
1.37、1.39は問題ありませんでした。

とりあえず1.39で様子を見た方がよさそうですね。

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

(6482) 6495Re^8: VTDOS140  投稿者:10#   2014/05/25(日) 17:10
    6494 番 konno さんへのコメント    コメント数 1

lxschd.defを入手しましたが、
使い方が分からず往生しています。
1.38と1.39の違いがIAS関連のみなので、
この二つでの違いは謎です。
1.41はやや大きめのアップデートになります。

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

(6482) 6499Re^9: VTDOS140でのlxschd.def の挙動  投稿者:konno   2014/05/26(月) 02:06
    6495 番 10# さんへのコメント    コメント数 2

> lxschd.defを入手しましたが、
> 使い方が分からず往生しています。

lxschd.def V2.02 ですよね。
LXSCHD   DEF        23,651 99-04-08   15:01

私のは若干中身が違っていたので、上記のdefで検証しなおしました。
PC98用なのか、修正が必要です。157行目

;		    &Sc(CC,"A:\")
		    &Sc(CC,"C:\")  ; A:\ を C:\ に変更

その先、162行目も同じく変更

;		    &Sc(CC+64,"A:\")
		    &Sc(CC+64,"C:\")

これで起動すると、C:\ にカレンダーが作成されます。
新規作成なら問題ないようですが、サイズが43Kほどの物に追加作成して67kほどに
なると、57kあたりから古い日付の既存のデータで上書きされてしまいます。
保存する前は正常に見えた気がします。

追加作成は、現在の日時よりデータが古い場合に自動作成されます。


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

(6482) 6500Re^10: VTDOS140でのlxschd.def の挙動  投稿者:文太   2014/05/26(月) 23:06
    6499 番 konno さんへのコメント    コメント数 2

konnoさん

 完全に的外れだったらご容赦ください。

>PC98用なのか、修正が必要です。157行目
 LX用だから、LXではAが起動ドライブなのかな、とか。モバギしか知らない
のですが。LX用で、旧8用はないかと。

;		    &Sc(CC,"A:\")
		    &Sc(CC,"C:\")  ; A:\ を C:\ に変更
これで起動すると、C:\ にカレンダーが作成されます。

 これがとても気になりました。Win8以降については分かりませんが、Win7
では、ルートにファイルが作れなくはありませんか? できるのですか?
 何か設定がありますか?

 疑問のような質問のような……?


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

(6482) 6501おもに独り言  投稿者:文太   2014/05/26(月) 23:42
    6500 番 文太 さんへのコメント    コメント数 2

konnoさん、と言いつつ、独り言です。

 時間があったら、lxschd.def を入れてみて、スケジュール管理についてもう
少し真剣になってみたいな、とも思うのですが、ちょっと時間がなくて、ごめん
なさい。紙を使ってさえ、スケジュール管理ができていません、しくしく。

 でも、 間違っているかもしれませんが、konno さんのほうが 10# さんより、
Vzマクロについては通じてる。lxschd.def のどのあたりが問題を引き起こし
てそうか、VTDOS の何に引っかかっているのか、konnoさんならヒントとか出せる
のじゃないのかな、と思いました。
 余計なお世話、余計なお節介でした。m(__)m

 それから、これは本当に独り言というか空想なのですが、多くの人がエミュレ
ータ上でエディタのマクロまで動かそうなんて大変だとコメントしています(2
ちゃんねるとか)。実は、10# さんも同じことを仰っていた。もちろん、マクロ
によります。MS-Dos 自体をいじりまくる高橋さんのマクロなんて VTDOS で動い
たら、10# の執念に僕は脱帽するでしょう。あるいは、たとえば高橋さんのサブ
リナが動かないとなったら(debug が動くのだから動くのだろうと楽観)、この
場合、僕にはヒントの出しようもありませんが、エミュレートが不完全みたいで
す、どうにかなりませんか、とか言ってみると思う。
 これこれこんな風に、NTVDM ではいけるのに VTDOS では駄目です、とか。

 lxschd.def がどこまで MS-Dos を直接いじっているのかは全くわかりません
が(スケジュール管理マクロがそんなに MS-Dos をいじる必要はないだろうと想
像しています)、僕は、Vzがまともに動けば、大抵のマクロは動く、僕が偏愛
している syo さん的なマクロなんて(僕がつくるマクロとか)動かないわけが
ない、と思ってます。基本コマンドに条件分岐とループが入っているだけみたい
なものですから。ポインタを使うといっても、所詮、Vzのお腹のなかをいじっ
ているだけだろう。m.gann さんのマクロはコードは超絶だけど、やはりVzの
お腹の中で賢く、Vzの癖を読み切って計算させてるだけで、やはり同じく動く
だろうと思っています。基本(大ざっぱに言って)、Vzマクロってキー入力の
自動化、キー入力ルーチンのエミュレートだと思っているからです。榊原さんの
言葉を、そんな風に解釈・理解してるだけなのですが。
 もしそれらのマクロが動かないなら、ふつうにマニュアルでエディットに使う
Vzだって、まともに動いてくれないだろうと。そうだったら、VzもVTDOSも
僕には使えない……。

 大きく間違っていたらお教えいただけると、あるいはご意見をお伺いできれば
幸いです。が、これはあくまで独り言です。

 もう一言。あまりに怠惰であることは承知のうえなのですが。konnoさんは、#6494

>vz.comをリネームしたら最近のVTDOSは全て起動BATで落ちてしまい、久しぶりに
>DOS窓VZを立ち上げて修正しました。

 と書かれていました。本筋からずれたしょうのない質問なのですが、日本語入力
を捨てれば、英語版VzはWin7でもそれなりに動くのでしょうか? MSジャパンが
command.comの日本語対応その他に怠慢しただけで、NTVDM+command.comは、Win7あ
るいはWin8でも健在ですか? これがあるだけでも、ファイル管理ができるから、
朗報なのですが。m(__)m
 試すのが、簡単じゃないのです。m(__)m

 サポーターから野太い黄色い声のチアリーダーになりつつある、すね毛付き文太。
 厳しい季節を越えたら精力的にテスターします。m(__)m


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

(6482) 6502さて、C:¥を使うべきか。  投稿者:文太   2014/05/27(火) 21:56
    6501 番 文太 さんへのコメント


 いやーん、「管理者権限」。こんな基礎的な話が通じてないわけがないですね。
失礼しました。

(某掲示板より)
-------------------------------------------------------------------------
 C:(7の OS が入っているドライブ)ドライブでは Administrator の権限を
持ったユーザーでないと、セキュリティー上ドライブ直下にはフォルダーしか作
れないこと、 OS に悪影響を与えるフォルダーは一般のアカウント users(〜)
では’読み取りと実行’しか出来ないことが分かりました。

 どうしても C: ドライブにファイルを書き込みたいならば Administrator の
権限を持ったユーザーアカウントを作り、そのアカウントでアプリを動かせば C:
ドライブにも書き込めます。
-------------------------------------------------------------------------

 で、lxschd.def 2.02 には(必要ないかもしれませんが)lxschd.doc が入っ
ていません。doc が入っているのは、v. 1.1 で、これは「軟体保管計画」にあ
りませんでした。
 FGALDC ライブラリの18階(LX用?)にアップされていたからだと思われ
ます。
 管理者権限でやればCのルートのデータファイルがつくれるわけで、検証実験
に問題はないのでしょう。
 ドック付き v. 1.1 の要不要については、10# さんに問い合わせメールを送り
ました。

 ドックがなくて使い方が分かる、あるいは容易に事故が再現できるマクロなの
かどうかは、僕には分かりませんでした。


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

(6482) 6504Re: おもに独り言  投稿者:konno   2014/05/27(火) 22:40
    6501 番 文太 さんへのコメント    コメント数 1

> 紙を使ってさえ、スケジュール管理ができていません、しくしく。

私も紙のスケジュール管理は無理です。
その私が唯一使えたのがLXSCHD.DEFなんですね。

> lxschd.def のどのあたりが問題を引き起こし

まさにそのとおりでした。
データが64kをまたぐ辺りでおかしくなるようです。
思えば以前から64kを超えるスケジュールデータがおかしくなることが何度もあり
64kを超えないように運用していたのと同根の問題かもしれません。

>  それから、これは本当に独り言というか空想なのですが、多くの人がエミュレ
> ータ上でエディタのマクロまで動かそうなんて大変だとコメントしています(2
> ちゃんねるとか)。実は、10# さんも同じことを仰っていた。

え、そうなんですか。私はVZが動けばマクロも動くと思っています。
だって、VZ自体がマクロで動いているようなものでしょう。

>  と書かれていました。本筋からずれたしょうのない質問なのですが、日本語入力
> を捨てれば、英語版VzはWin7でもそれなりに動くのでしょうか?

もちろん32ビットWin7のDOS窓で日本語VZが30行、40行のLFNで動いていますよ。
文字化けしないFEPが無いだけです。あ、VJEやNECAIとかは試してないな。
Win8ではどうか知りませんが。
過去記事でいろいろ書いてあるはずですが、纏めないとわかりにくいですよね。

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

(6482) 6505Re^2: おもに独り言  投稿者:文太   2014/05/27(火) 23:12
    6504 番 konno さんへのコメント

konnoさん、お騒がせし、またご丁寧にありがとうございます。

>私も紙のスケジュール管理は無理です。
 いや、これは意図が食い違っている。僕にとっては、紙がいちばんシンプルで
分かりやすいのです。スケジュール管理をPCやマクロには、根本的に任せられ
ない。 が、この思いこみを、lxschd.def で、と一瞬思ったのですが、日常と時
間の管理のために、ドコモバを持ち歩いたり、データ移動・同期を考えたり気に
したり、また電池の補充を準備したりより、根性で手帳がまだ成功の確率が少し
あります、というか、成功の確率、少しでいいから、あるといいな。

>その私が唯一使えたのがLXSCHD.DEFなんですね。
 過去ログで読みました。konnoさんにとっては、本当にそうなんですね。

>データが64kをまたぐ辺りでおかしくなるようです。
 あ、Vzにとっては不吉な数字。

>>  それから、これは本当に独り言というか空想なのですが、多くの人がエミュレ
>> ータ上でエディタのマクロまで動かそうなんて大変だとコメントしています(2
>> ちゃんねるとか)。実は、10# さんも同じことを仰っていた。

>え、そうなんですか。私はVZが動けばマクロも動くと思っています。
>だって、VZ自体がマクロで動いているようなものでしょう。

 御意、です。よかった。うん、ぜったいそうですよ。ありがとー! 安心。

>もちろん32ビットWin7のDOS窓で日本語VZが30行、40行のLFNで動いていますよ。
>文字化けしないFEPが無いだけです。あ、VJEやNECAIとかは試してないな。

 ふ、不思議な世界。つまり、VTDOSなしだとまともな日本語入力ができない、
ということですね。でも、おお、ファイラは健在なんだ!! ファイル名に日本語
なんて使わないもーん。
 はやく自分で体験してみなさいよねぇ。ただ、Win7では、Vzが遅い、、、。


 別記事の話題。「管理者権限」、これですね。
 ルート。 いえ、MS-Dos だって、Windows だって、やっぱりルートにごちゃご
ちゃファイルを作るのは作法違反だとは思ってました。不都合がなかったので、
UNIX 使ってるわけじゃないし、 文句あっか、とやってきたのですが、Win7 に
「文句あり」と言われてしまいまして。
 でも、これ、転ぶ人はそれなりにいるみたいですよ。というか、セキュリティー
上、云々。
 まったくPC初心者みたいな話で、お恥ずかしいかぎりです。m(__)m


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

(6482) 6503Re^11: VTDOS140でのlxschd.def の挙動  投稿者:konno   2014/05/27(火) 22:15
    6500 番 文太 さんへのコメント    コメント数 1

>  LX用だから、LXではAが起動ドライブなのかな、とか。モバギしか知らない
> のですが。LX用で、旧8用はないかと。

ああ、そうでした。そもそも名前がLX・・・でしたね。
今は日記や備忘録としてVTDOSで使用しているもので。

>  これがとても気になりました。Win8以降については分かりませんが、Win7
> では、ルートにファイルが作れなくはありませんか? できるのですか?

ということは、文太さんの環境ではルートにファイルが作れないということですか。
うちの環境では問題なく作れます。職場のPCでも。
DOS窓VZでも新規DAT作成できましたよ。
管理権限(アドミニストレータ)モードだから?
ユーザーモードではいろいろ制限があるようで、文太さんのはそうなっているのでは。

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

(6482) 6550Re^12: Win7のUAC問題  投稿者:konno   2014/06/14(土) 22:31
    6503 番 konno さんへのコメント

独り言ですが

> ということは、文太さんの環境ではルートにファイルが作れないということですか。
> うちの環境では問題なく作れます。職場のPCでも。
> DOS窓VZでも新規DAT作成できましたよ。

えーと、今はできなくなりました。PCの環境を弄ったせいか
ckwv7で、例のUAC だかのダイアログが出るようになってしまった。
VTDOS単独では出ないようですが、C:\ の変更は出来なくなりました。
これって嫌がらせとしか思えないよね。

> 管理権限(アドミニストレータ)モードだから?
> ユーザーモードではいろいろ制限があるようで、文太さんのはそうなっているのでは。

いままで気にしてなかったけど、UACをOFFにしてたんですね。
職場のPCは弄った覚えがないけどOFFになっているので、まあいいか。

うーん、しばらくC:\ を使わないで運用してみるかな。


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

(6482) 6506Re^10: VTDOS140でのlxschd.def の挙動  投稿者:10#   2014/05/28(水) 01:06
    6499 番 konno さんへのコメント    コメント数 2

リプライ先が・・・(^^;)

当初UMBがらみでMCBの構成を変更したことが起因しているものと想定して、
DOS3.X互換のMCBオプションを用意してみたんですが、これが原因では
なかったようです。

1.37〜1.40で思い当たる節がこの部分だけですので、以前から存在した問題が
環境の変化によって顕在化したものではないかと考えています。

環境の変化といえば、環境変数の問題の対策として、$XSETを用意しましたが、
これによって環境変数の構成が変化しているものと思われます。
また、ひょっとしたらcommand.comに始まる、各プロセスのロードアドレスも、
変化しているかもしれません。

いろいろ調べてるうちに、32bitコンソールの実行に問題があることが判明
しました。
これは32bitコンソールの実行中にコンベンショナルメモリーの一部を、
間違って書き換えてしまうもので、command.comの不正命令の原因でした。
具体的には3箇所不具合箇所があって、そのうち2箇所はかなり以前から
存在していましたが、書き換える確立は1/2で、それが顕在化する確立は
さらに下がるものと思われます。
残りの一つは8に対応する変更時に発生したもので、Windowsのコマンド
を実行する場合、他の二つに比べて高い確立で発生するものでした。

今回明らかになった障害は、実際の挙動に対しては間接的に作用するので、
具体的にどういった問題が発生するとも明確ではありません。
それゆえ、改善される内容も明確なものではありません。
例えば shadowさんのmasmの挙動を見てみると、出力されるエラーの内容は
変化しているようです。(但しメモリー不足のエラーが出ます)
lxschd.defは僕が試した1.1は、エラーが出て動かなかったものが、
動くようにはなりました。
(まだkonnoさんが遭遇した現象を試すにはいたっていません)

1.41はしばらく様子を見て公開する予定です。

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

(6482) 6507Re^11: VTDOS140でのlxschd.def の挙動  投稿者:文太   2014/05/28(水) 01:49
    6506 番 10# さんへのコメント

10#さん

>1.41はしばらく様子を見て公開する予定です。

 ゆっくりいきましょうね!
 ロング・ヴァケーション中の、文太より。
 休んでばっかりじゃないの?

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

(6482) 6508Re^11: VTDOS140でのlxschd.def の挙動  投稿者:konno   2014/05/28(水) 07:31
    6506 番 10# さんへのコメント    コメント数 1

> (まだkonnoさんが遭遇した現象を試すにはいたっていません)

データは1行でもあれば追記されます。

07/08/01(水)

この日付データで起動すると64k超えて、保存した内容がおかしくなります。

07/09/01(土)

こちらの日付ではおかしくならないです。

うう、DOS窓VZのBATをYSETにしたら問題が出ない?


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

(6482) 6509Re^12: VTDOS140でのlxschd.def の挙動  投稿者:文太   2014/05/28(水) 12:28
    6508 番 konno さんへのコメント    コメント数 1

konnoさん

 lxschd.defをちらと眺めlxschd.docをさらっと読み流した奴のコメントです。
 久しぶりで懐かしく、マクロの勉強にもなりました。これって構造体だなぁ、
とか。

>うう、DOS窓VZのBATをYSETにしたら問題が出ない?
 VTDOS がらみが原因なら、そこぐらいなのかなぁ、と少し思いました。
 konno さんは、lxschd.def 用に環境変数を使われてますか? MS-Dos の環境
変数を使わなくても lxschd.def は使えますよね。そこが関係するのかな、と。

 もしかして、他のプログラム用の環境変数を YSET にしたら、問題が出なくな
った、という意味でしょうか? だとしたら、メモリ管理にけっこう大きな問題
がありそう。

 10# さんは手間だから、lxschd.def を試すとしたらきっと環境変数を使わず
デフォで試すだろうな、と思ったもので。
 まだ、興味が向かないというか、「スケジュール管理は間にあってるしねぇ」
みたいな感じでしたよ。ドックは入手されていました。


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

(6482) 6510Re^13: VTDOS140でのlxschd.def の挙動  投稿者:konno   2014/05/28(水) 23:43
    6509 番 文太 さんへのコメント    コメント数 1

> >うう、DOS窓VZのBATをYSETにしたら問題が出ない?

すみません、ysetは関係なかったようです。

実行環境 	データ	作成時間
-----------------------------------
Win7Dos窓 	正常	1秒
dosbox0.72 	正常	24秒
200LX	 	正常	25秒  ※休日データ作成でマクロがエラーで止まる
VTDOS1.39	異常	3秒

こんな感じで、VTDOSだけ64k以上でデータが異常になります。
200LXでデータが異常になったのは他の要因だったのかもしれません。
う〜む。

>  konno さんは、lxschd.def 用に環境変数を使われてますか?

いや、何も設定してないです。

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

(6482) 6511Re^14: VTDOS140でのlxschd.def の挙動  投稿者:10#   2014/05/29(木) 01:23
    6510 番 konno さんへのコメント    コメント数 2

2.02で試してみました。
lxschd.datを64kオーバーさせる方法が思いつかなかったので、
各行をキーマクロで最大幅まで埋めたんですが、64kに至りませんでした。
仕方が無いので、全行コピペで行数2倍の荒業を試してみましたが、
現象を確認できませんでした。
といっても、これはリリースしたばかりの1.41での話しです。
ちなみに未だ新規行追加の方法を把握していません(^^;)

どうでも良いですが、仕事のタスク管理をVZだけでやってたりします。

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

(6482) 6512Re^15: VTDOS140でのlxschd.def の挙動  投稿者:文太   2014/05/29(木) 01:45
    6511 番 10# さんへのコメント    コメント数 1

>lxschd.datを64kオーバーさせる方法が思いつかなかったので、
>ちなみに未だ新規行追加の方法を把握していません(^^;)

 笑。

>どうでも良いですが、仕事のタスク管理をVZだけでやってたりします。

 でしょうねぇ。それでこそ、Vzer。

 konnoさんのレポートもお見事でした。
 で、再現の条件としては、何が必要なのでしょう?

>といっても、これはリリースしたばかりの1.41での話しです。

 おお、早い、、、。
 1.41でも出ますか? >konnoさん?

 lxschd.datを作ったことのない文太でした。
 スケジュール管理をしたことがない文太、ですね。汗。

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

(6482) 651364000 bytes のファイル  投稿者:文太   2014/05/29(木) 01:57
    6512 番 文太 さんへのコメント

=== Macrotmp by B ===;
* M
50 ^^ "Macrotmp"

a="01234567890123456789012345678901234567890123456789012345678901", ;62bytes
i=1000,

(i){&?("%s",a) #m}		;(i){loop} 定数回ループ

;64 kilo bytes isn't the same as 64000 bytes, is it?  bunta?

*

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

(6482) 6514Re^15: VTDOS140でのlxschd.def の再現手順  投稿者:konno   2014/05/29(木) 21:46
    6511 番 10# さんへのコメント    コメント数 1

> lxschd.datを64kオーバーさせる方法が思いつかなかったので、
> 各行をキーマクロで最大幅まで埋めたんですが、64kに至りませんでした。

あう、超簡単と思っていたので、そんな状態だったとは夢にも思いませんでした。

> 仕方が無いので、全行コピペで行数2倍の荒業を試してみましたが、
> 現象を確認できませんでした。

げげ、lxschd.def を使わないで検証テストですか。

> ちなみに未だ新規行追加の方法を把握していません(^^;)

すぐにわかると思っていたので説明が手抜きすぎたようですね。

1.最初にlxschd.def を起動すると、だいたい2か月前から一年後までの日付データを自動的に作成します。
「ESC」キーでlxschd.def は終了し、データを保存します。

2.そのlxschd.dat の中身を削除して

07/08/01(水)

この日付データを貼り付けて保存してください。

3.lxschd.def を再び起動します。
 自動的に日付データが追記され、一か月先までの64k超のデータが作成されます。

4.ページ戻しで日付が正常に減少することを確認します。
 行数が先頭で1になるのを確認します。

5.「ESC]で終了します、データは保存されます。
 マクロがエラーで止まった時は手動で保存してください。

6.lxschd.dat をオープンして最後までページ送りします。
 
  13/06/11(火) あたりで内容が古い日付に変わります。

13/06/11(火)
‥・・・・
09/03/15(日)
 ・
 ・
 ・
10/04/02(金)  最終データ

うちのVTDOS環境ではこうなります。
ちなみに、1.41でも異常になりました。


> どうでも良いですが、仕事のタスク管理をVZだけでやってたりします。

私的専用マクロでしょうか。
公開の予定は?
そういえば、10#さんのマクロ、見てみたいですねぇ。

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

(6482) 6515Re^16: VTDOS140でのlxschd.def の再現手順  投稿者:10#   2014/05/30(金) 00:23
    6514 番 konno さんへのコメント    コメント数 1

うーん、手順どおりにやってみましたが再現しません。
他の要因でしょうか?
ちなみに僕はまだ k07s3 を使ってます。lxschd.defは2.02で、VWXは1.08B
vmapはこんな感じです。


VMAP Version 2.01  Copyright (C) 1989-91 by c.mos

addr PSP  blks   size  owner/parameters           hooked vectors
---- ---- ---- ------  -------------------------  -----------------------------
FB01 <--    1   10704  vwx 1.08b -v1 -x1          2F
FD9F-FF00   1    5648  <free>
                       --- UMB total:  16 KB ---
1001 1101   3   20608  command                    23 24 2E
150C        1    2816  <free>
15BD <--    1    3888  vz 1.60s -z                1B 21 29
16B1-9FFE   1  562368  <free>

----- EMS ver4.0 (frame: C000h) -----
handle pages   size  name
------ ----- ------  --------
     1    13   208k  VZ
  free  2035 32560k
 total  2048-32768k


タスク管理にマクロは利用していませんよ。
「予定」のセクションに仕事の行程を1行ずつ任意にテキストにして、
適切な順番に並べ替えて、終わった順番に「完了」のセクションに移動するだけです。
一時期GTDとか言われてたやつです。
行単位の編集が手軽なエディターが最適なツールで、
別にVZでなくても実は良いです。

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

(6482) 6516Re^17: VTDOS140でのlxschd.def の再現手順  投稿者:konno   2014/05/30(金) 01:28
    6515 番 10# さんへのコメント    コメント数 2

> うーん、手順どおりにやってみましたが再現しません。
> 他の要因でしょうか?

げげ、もしかしてうちの環境だけの問題なのか。
VZは高橋版でもダメで、sw2 も sw3 にしたり、vwxのオプションを変えたり、
VTDOS環境だけで出るのは何が違うのか。

あと思いつくのはVZ.DEFのオプションかなぁ。
あじゃさんの opt_lst.defの結果です。

---------- option.lst --------------------- 2014/05/30 (Fri) 01:12 --------
 DOSV  VZt  VZk  z+  St-  vw+  zk-
 
 Bt64     Bf4224   Bo32768  EM1024   XM1      Bm9445   Ba258    Hs256
 Hf256    Hx256    Ha256    Hw128    Bl8192   Bc1024   Bu256    Bv256
 
 SW3   TC10  WD0   We100 PG0   RS3   Ta8   Tb4   Ci0   Co2   WL1
 LC46  VM0   CA52  Sr39  Qt1   Qc10  Qw50  RM0
 
 An$0F  Ac$05  Al$1A  Ah$78  As$70  Ao$E0  Ar$B0  Am$5F  Ab$70  At$70
 Aw$70  Af$74  Ai$0F  Aj$74  Ak$2F  Ag$01  Au$70  Ae$02  Ay$00  vs$00
 vy$00  Ad$07
 
 Dl-  Dc+  Dt+  De+  Ds+  Db-  Dn-  Du-  Df+  Dp-  Dh+  Dg+  Dr+  Dj+  Dv+
 
 FM23    FW2050  FV1     FS2     FO2
 
 Ei+  Es+  Ez-  Eb-  Eu-  Et+  Eh-  Ew-  Ec+  Ex-  En-  Ev+  Ek-  Ea-  RO-
 Ej-  Eo+  El-
 
 RX-  ZH-  Sx+  Se+  Sd+  Sk+  Sy-  YN-  Sn-  Sq-  FP+  FR-  FK+  FQ+  Sz-
 
 Sc-  Nd+  Vb+  Sv-  Tv-  YM-  CH-  Hp-  Hp-  lf-  Is-  Da+  Nf+
 Ce2048   ml+  mc*  Ys$09  Yo$0E  Yr$0B
---------- End of option.lst ----------------------------------------------

10#さんのところはどうですか。


> タスク管理にマクロは利用していませんよ。
> 「予定」のセクションに仕事の行程を1行ずつ任意にテキストにして、
> 適切な順番に並べ替えて、終わった順番に「完了」のセクションに移動するだけです。

なるほど、手作業の切り貼りでしょうか。

> 別にVZでなくても実は良いです。

うう、10#さんがVZerでなかったら、VTDOSは存在しなかったんですね。
正直、VTDOSが生まれた今の状況は奇跡のようなものだと思います。

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

(6482) 6517Re^18: VTDOS140でのlxschd.def の再現手順  投稿者:文太   2014/05/30(金) 09:06
    6516 番 konno さんへのコメント

10#さん

>あじゃさんの opt_lst.defの結果です。(konnoさんwrote)

 というのは、

めざらさんの「軟体保管」
http://homepage3.nifty.com/mezala/vz/history/maclib1.html

で、以下を検索して落とせます。
VZ_OPT.DEF

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

(6482) 6520Re^18: VTDOS140でのlxschd.def の再現手順  投稿者:10#   2014/05/31(土) 00:37
    6516 番 konno さんへのコメント    コメント数 1

こんな感じですが、参考になりますかね。

---------- option.lst --------------------- 2014/05/30 (Fri) 23:51 --------
 DOSV  VZt  z+  St-  vw+  zk-

 Bt64     Bf16384  Bo32768  EM1024   XM0      Bm8194   Ba3      Hs256
 Hf256    Hx256    Ha256    Hw92     Bl8192   Bc1024   Bu32     Bv1024

 SW3   TC35  WD250 We250 PG0   RS1   Ta8   Tb8   Ci8   Co0   WL0
 LC59  VM0   CA52  Sr7   Qt0   Qc40  Qw100 RM0

 An$0F  Ac$0E  Al$0B  Ah$0B  As$0E  Ao$0D  Ar$0A  Am$0E  Ab$0B  At$0E
 Aw$0F  Af$0B  Ai$8E  Aj$0A  Ak$0E  Ag$01  Au$0E  Ae$12  Ay$00  vs$00
 vy$00  Ad$0F

 Dl-  Dc-  Dt-  De+  Ds-  Db-  Dn-  Du-  Df-  Dp+  Dh-  Dg+  Dr+  Dj-  Dv-

 FM7     FW1024  FV1     FS0     FO3

 Ei+  Es+  Ez-  Eb+  Eu-  Et+  Eh+  Ew+  Ec-  Ex-  En+  Ev-  Ek-  Ea+  RO-
 Ej+  Eo+  El-

 RX-  ZH-  Sx+  Se+  Sd-  Sk-  Sy-  YN-  Sn+  Sq+  FP-  FR-  FK-  FQ-  Sz-

 Sc-  Nd-  Vb-  Sv-  Tv-  YM-  CH-  Hp-  Hp-  lf+  Is-  Da-  Nf+
 Ce0      ml+  mc*  Ys$0F  Yo$0D  Yr$0E
---------- End of option.lst ----------------------------------------------

ちょっと前に文太さんに話したことですが、
僕はDOS時代使っていたソフトのほとんどを使い続けていますが、
古いソフトは当然動作保証が無いため、騙し騙し使っています。
最早Win2k時代の32bitアプリですら動くかどうかは怪しいですよ。
コマンドラインユーティリティーで32bit版がある場合は、
割りに早い段階で移行しています。

環境の設定や調整で安定すればラッキーだと思っていて、
そのための試行錯誤や、クラッシュに対するリカバリーや、
不具合回避の習慣化は身に染み付いています。
今回の障害も設定の調整で済めばラッキーだと思ってます。
(DOS自体がそういうものでしたよね)

DOS時代から、VZは設定や環境如何で不安定化しがちでしたので、
安定しているDEFにおいそれと手を入れることは無かったですし、
環境移行で問題が出る場合は極力慎重に、保守的に調整を入れています。

僕にとってはその程度の手間は掛けてもいいぐらい使い勝手のいい道具なんですが、
それゆえ、マクロの活用により利便性を追求する動機はあまり無く、
キーバインドに近い扱いだったりします。
その反面テキスト操作にコマンドラインを活用するため、xscriptや、キーマクロ
などは不可欠だったりします。

仕事の道具の一つとして日常的に活用してるため、コアなVZユーザーの一人
であることは間違いないのですが、マクロ文化などはほぼ知らずにいたので、
いわゆるVZerとは、似て非なるものだと思ってます。

VTDOSを一人立ち上げた時点ではVZは忘れられた存在で、
自称最後のVZユーザーという認識でした。

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

(6482) 6521Re^19: VTDOS140でのlxschd.def の再現手順  投稿者:文太   2014/05/31(土) 09:19
    6520 番 10# さんへのコメント    コメント数 1

konnoさん、
 早い話が、10#さんは、Vzは便利だけどマクロのことは任せるよぉ、と
仰っていると僕は解釈しました。

 特に何も思いつきませんでした。
 「賢い自分用の設定」について思いを馳せようと思ったのだけど、、、。
 知らない暗号がけっこうある、、、。

K: konno,  T: TenSharp,  B: Bunta
---------------------------------

K  DOSV  VZt  z+  St-  vw+  zk-
T  DOSV  VZt  z+  St-  vw+  zk-
B  DOSV  VZt  z+  St-  vw+  zk-

K  Bt64     Bf4224   Bo32768  EM1024   XM1      Bm9445   Ba258    Hs256
T  Bt64     Bf16384  Bo32768  EM1024   XM0      Bm8194   Ba3      Hs256
B  Bt64     Bf4096   Bo32768  EM1010   XM128    Bm7998   Ba2      Hs1024

K  Hf256    Hx256    Ha256    Hw128    Bl8192   Bc1024   Bu256    Bv256
T  Hf256    Hx256    Ha256    Hw92     Bl8192   Bc1024   Bu32     Bv1024
B  Hf512    Hx1024   Ha128    Hw512    Bl8192   Bc768    Bu512    Bv128

K  SW3   TC10  WD0   We100 PG0   RS3   Ta8   Tb4   Ci0   Co2   WL1
T  SW3   TC35  WD250 We250 PG0   RS1   Ta8   Tb8   Ci8   Co0   WL0
B  SW2   TC14  WD80  We80  PG0   RS4   Ta8   Tb4   Ci0   Co6   WL0

K  LC46  VM0   CA52  Sr39  Qt1   Qc10  Qw50  RM0
T  LC59  VM0   CA52  Sr7   Qt0   Qc40  Qw100 RM0
B  LC24  VM0   CA52  Sr165 Qt10  Qc50  Qw0   RM0

K  An$0F  Ac$05  Al$1A  Ah$78  As$70  Ao$E0  Ar$B0  Am$5F  Ab$70  At$70
T  An$0F  Ac$0E  Al$0B  Ah$0B  As$0E  Ao$0D  Ar$0A  Am$0E  Ab$0B  At$0E
B  An$0F  Ac$13  Al$1A  Ah$B0  As$F0  Ao$E0  Ar$B0  Am$0E  Ab$B0  At$70

T  Aw$0F  Af$0B  Ai$8E  Aj$0A  Ak$0E  Ag$01  Au$0E  Ae$12  Ay$00  vs$00
K  Aw$70  Af$74  Ai$0F  Aj$74  Ak$2F  Ag$01  Au$70  Ae$02  Ay$00  vs$00
B  Aw$70  Af$E0  Ai$0F  Aj$74  Ak$0E  Ag$01  Au$4F  Ae$12  Ay$00  vs$00

K  vy$00  Ad$07
T  vy$00  Ad$0F
B  vy$00  Ad$07

K  Dl-  Dc+  Dt+  De+  Ds+  Db-  Dn-  Du-  Df+  Dp-  Dh+  Dg+  Dr+  Dj+  Dv+
T  Dl-  Dc-  Dt-  De+  Ds-  Db-  Dn-  Du-  Df-  Dp+  Dh-  Dg+  Dr+  Dj-  Dv-
B  Dl-  Dc+  Dt-  De+  Ds+  Db-  Dn-  Du+  Df+  Dp+  Dh+  Dg+  Dr+  Dj-  Dv+

K  FM23    FW2050  FV1     FS2     FO2
T  FM7     FW1024  FV1     FS0     FO3
B  FM31    FW2048  FV1     FS1     FO3

K  Ei+  Es+  Ez-  Eb-  Eu-  Et+  Eh-  Ew-  Ec+  Ex-  En-  Ev+  Ek-  Ea-  RO-
T  Ei+  Es+  Ez-  Eb+  Eu-  Et+  Eh+  Ew+  Ec-  Ex-  En+  Ev-  Ek-  Ea+  RO-
B  Ei+  Es-  Ez-  Eb+  Eu-  Et+  Eh-  Ew-  Ec-  Ex-  En-  Ev-  Ek+  Ea-  RO-

K  Ej-  Eo+  El-
T  Ej+  Eo+  El-
B  Ej-  Eo-  El-

K  RX-  ZH-  Sx+  Se+  Sd+  Sk+  Sy-  YN-  Sn-  Sq-  FP+  FR-  FK+  FQ+  Sz-
T  RX-  ZH-  Sx+  Se+  Sd-  Sk-  Sy-  YN-  Sn+  Sq+  FP-  FR-  FK-  FQ-  Sz-
B  RX-  ZH-  Sx+  Se+  Sd+  Sk-  Sy+  YN-  Sn+  Sq-  FP+  FR-  FK+  FQ-  Sz-

K  Sc-  Nd+  Vb+  Sv-  Tv-  YM-  CH-  Hp-  Hp-  lf-  Is-  Da+  Nf+
T  Sc-  Nd-  Vb-  Sv-  Tv-  YM-  CH-  Hp-  Hp-  lf+  Is-  Da-  Nf+
B  Sc-  Nd-  Vb-  Sv-  Tv-  YM-  CH-  Hp-  Hp-  lf-  Is-  Da-  Nf+

K  Ce2048   ml+  mc*  Ys$09  Yo$0E  Yr$0B
T  Ce0      ml+  mc*  Ys$0F  Yo$0D  Yr$0E
B  Ce0      ml+  mc*  Ys$03  Yo$60  Yr$30


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

(6482) 6522Re^20: VTDOS140でのlxschd.def の再現手順  投稿者:konno   2014/05/31(土) 19:35
    6521 番 文太 さんへのコメント    コメント数 2

文太さん

> K: konno, T: TenSharp, B: Bunta

ナイスな比較表ですね。ありがたいです。
やっぱりVZって人それぞれで好みにカスタマイズできるのがいいですね。

で、いろいろ試したんですが、現時点で分かったこと。
VZがEMSを使わずにマクロバッファが足りなくてマクロが休日データ追加時に
止まった時かな?VTDOSで正常データができました。
あとは全部異常データになります。

文太さんの処ではどうでしょうか。

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

(6482) 6523Re^21: VTDOS140でのlxschd.def の再現手順  投稿者:文太   2014/05/31(土) 21:31
    6522 番 konno さんへのコメント    コメント数 1

konnoさん

>文太さんの処ではどうでしょうか。
 すいません、僕は交通整理やアシスト役をやっていてテスターはやれていません。
 僕的には、ひと段落かな、という感じでいます。
 総じて、VTDOS 1.41、いい感じです。使用時間が短すぎますが、文字化けを見てません。


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

(6482) 6526Re^22: VTDOS140でのlxschd.def の再現手順  投稿者:konno   2014/06/01(日) 14:06
    6523 番 文太 さんへのコメント    コメント数 1

> >文太さんの処ではどうでしょうか。
>  すいません、僕は交通整理やアシスト役をやっていてテスターはやれていません。
>  僕的には、ひと段落かな、という感じでいます。

うう、確かに文太さんのおかげでlxschd.defの所在や使い方などが伝わったのですが
そこまでやってくれているのに起動もしてないということはないのでは。(;_;)

でもこのマクロ、エラーで止まると表示オプションが変わってしまうのが難点ですね。
おかげさまで原因はだんだん絞り込めてきました。


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

(6482) 6528Re^23: VTDOS140でのlxschd.def の再現手順  投稿者:文太   2014/06/01(日) 18:57
    6526 番 konno さんへのコメント    コメント数 1

konnoさん

>そこまでやってくれているのに起動もしてないということはないのでは。(;_;)

 すいません、本当なんです。再カスタマイズさえ、したことがないのです。使える
ようになるのに道が長すぎる、とのっけに判断しました。m(__)m
 VTDOSのために、今回(小さな範囲で)走り回っただけなのです。m(__)m

>これは、_HOLIDAY.DEF という別マクロが必要でした。
>軟体計画の、LXSCHD.DEF 2.0 にDOCと共に入っています。

 相当にデータ、プログラムが散逸してしまったマクロなんですね。


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

(6482) 6529データ、プログラムの所在地 (lxschd.def)  投稿者:文太   2014/06/01(日) 19:13
    6528 番 文太 さんへのコメント

 konnoさん掲示板のこれまでのやり取りの情報のみから、以下をまとめました。
 僕はマクロの中身をまったく知りません。

LXSCHD.DEF 2.02		マクロ本体				軟体補完計画	◆
LXSCHD.DOC		取り説(v.1.1)				ベクター
_HOLIDAY.DEF		補助マクロ(LXSCHD.DEF 2.0に同梱)	軟体補完計画
LXSCHD.DEF 2.0		LXSCHD.DOCを含む			軟体補完計画	◆

 ◆の2つで揃うと思われる。


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

(6482) 6525Re^21: VTDOS140でのlxschd.def の再現手順  投稿者:10#   2014/06/01(日) 01:59
    6522 番 konno さんへのコメント    コメント数 1

謎解きは梱包テープの端を探すかのごとくですね。

確かに僕の環境では休日データが出来ていません。
しかし64kは超えています。
メモリ不足エラーの出ない範囲でBmを増加しても休日データは出来ません。

EMSを使わずにというのは、何かの条件で使うこともあるということ?
64k超えでマクロ実行がクラッシュしているということ?


僕の場合好みというよりは当てずっぽうでカスタマイズですけどね。
各設定値の意味や効果、限界値などは厳密には分かりません。
マクロも素人です(^^;)

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

(6482) 6527Re^22: VTDOS140でのlxschd.def の再現手順  投稿者:konno   2014/06/01(日) 15:13
    6525 番 10# さんへのコメント    コメント数 1

> 謎解きは梱包テープの端を探すかのごとくですね。

わかります。なかなか見つからない時がありますよね。

> 確かに僕の環境では休日データが出来ていません。
> メモリ不足エラーの出ない範囲でBmを増加しても休日データは出来ません。

これは、_HOLIDAY.DEF という別マクロが必要でした。
軟体計画の、LXSCHD.DEF 2.0 にDOCと共に入っています。

> EMSを使わずにというのは、何かの条件で使うこともあるということ?
> 64k超えでマクロ実行がクラッシュしているということ?

・この時はEMSの無い環境だったので、_HOLIDAY.DEF が読み込めなかった。
 _HOLIDAY.DEF を実行しない時はデータは異常にならないようです。

・VTDOSで、TPAEXT=1、TPALOW=1 としてメモリを906kまで空けてマクロ実行すると
 休日データも入った正常なデータができました。

・マクロがメモリに残っている状態でもう一度データ作成しようとするとエラーになる。
 DOS窓VZでやったらDOS窓が消えました。
 LXSCHD.DEF はLXLOADER.DEF 使用を推奨しているので、&zと相性が悪い?

・1度の実行ではVTDOS以外は異常データが出来ていない。
 VTDOSでも保存するデータが64k以内なら異常にならない。

今までで分かったのはこのくらいですね。
私的にはこれ以上絞り込むのは難しそうです。
このマクロはハイテクを駆使していて、複数マクロの切り替えとかバッファメモリの
直接操作(EMS含め)している気がするので今回は相性的な問題かなと思います。
今まで通りデータが64kを超えないように運用すれば問題ないです。

> 僕の場合好みというよりは当てずっぽうでカスタマイズですけどね。
> 各設定値の意味や効果、限界値などは厳密には分かりません。

私も未だによくわかってないというか、さらに忘れてきていますね。

> マクロも素人です(^^;)

私もVZの改造デビュー当時はマクロ初心者を自認してました。
VZのソース弄りでマクロの理解がすすんで少しはレベルが上がったのかな。

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

(6482) 6530Re^23: VTDOS140でのlxschd.def の再現手順  投稿者:10#   2014/06/02(月) 01:56
    6527 番 konno さんへのコメント    コメント数 1

丁寧な梱包ほどぐるぐる巻きだったりとかw
真の几帳面はテープの端を折り返す?

_HOLIDAY.DEFを導入して、祝日設定も動作しました。
その後に、2〜3回入力しましたが、やはり再現していません。

ちなみに、一応vmapが既出ですが、TPA拡張は使っていません。
EMSを利用すればマクロのロードはできるということでOKですよね。
TPA拡張はその環境でテストされたアプリはおそらく存在しない、
という意味では信頼性に不安は無いですか?
(オプションを用意しておいてなんなんですけど)

DOS窓が落ちるということは、DOS窓内で無効命令に飛んでるということですよね。
これは純正環境を正とした場合でもクラッシュする条件がある、
ということでOKですか?

LXLOADER.DEFというのは今回使用していませんが、これを使えば再現する、
ということであれば、これはLXSCHDでも_HOLIDAYでもなく、
LXLOAERの使用に伴う問題ではありませんか?

もし、LXLOADERの使用を中止すればこの障害は発生しないと仮定すると、
LOLOADERは怪しいマシン語とか使ってますね。
DOSのSETPSPとか、RESIZEとか、EMSのREALLOCとか呼び出しています。
DOSのRESIZEはVTDOSではいわく付きで、
自然な解釈の挙動として、割り当て済みメモリブロックのRESIZEを行いますが、
実際に呼び出される、フリーエリアのRESIZEをサポートすることになった、
という経緯があります。これが正しいのかどうかは分かりません。

EMSを使わないオプションで現象が再現される場合、EMSは白ということになります。

これ、僕一人で原因究明するとなると、僕のメモリーがクラッシュしますね(;−;)



*Interrupt jump tableより

DOS 2+ - RESIZE MEMORY BLOCK

AH = 4Ah
BX = new size in paragraphs
ES = segment of block to resize

Return:
CF clear if successful CF set on error AX = error code (07h,08h,09h) (see #01680 at AH=59h/BX=0000h) BX = maximum paragraphs available for specified memory block
Notes: Under DOS 2.1-6.0, if there is insufficient memory to expand the block as much as requested, the block will be made as large as possible. DOS 2.1-6.0 coalesces any free blocks immediately following the block to be resized

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

(6482) 6531Re^24: VTDOS140でのlxschd.def の再現手順  投稿者:文太   2014/06/02(月) 12:52
    6530 番 10# さんへのコメント    コメント数 3

10#さん

 テープは絡まりまくっているようですね、笑。

konnoさんwrote at #6527
> LXSCHD.DEF はLXLOADER.DEF 使用を推奨しているので、&zと相性が悪い?

 とのことですので、

>LXLOADER.DEFというのは今回使用していませんが、これを使えば再現する、
>ということであれば、これはLXSCHDでも_HOLIDAYでもなく、
>LXLOAERの使用に伴う問題ではありませんか?
>もし、LXLOADERの使用を中止すればこの障害は発生しないと仮定すると、

 konnoさんは、LXLOADER.DEFをお使いではないと思われます。
 &z()マクロロード関数にバグがあり、関数の上位互換として各種のマクロ
ローダー・マクロがあります。


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

(6482) 6532Re^25: VTDOS140でのlxschd.def の再現手順  投稿者:文太   2014/06/02(月) 14:30
    6531 番 文太 さんへのコメント

konnoさん、僭越ながら

>ちなみに、一応vmapが既出ですが、TPA拡張は使っていません。
>EMSを利用すればマクロのロードはできるということでOKですよね。

>DOS窓が落ちるということは、DOS窓内で無効命令に飛んでるということですよね。
>これは純正環境を正とした場合でもクラッシュする条件がある、

 つまり、
 TPA拡張なし、EMSありのVTDOSでどのような再現条件があるのか。
 「純正環境」=VTDOSなし環境でも、再現するのか。

 これでVTDOSの問題か、NTVDMあるいはマクロの問題か、切り分けられるよ、
と僕は読みました。

 そもそもマクロの所在やヴァージョンがごちゃごちゃで、再現条件も曖昧だと
迷宮入りっぽいな、と思っています。
 何となく、最初(#6510)VTDOSの問題かと思ったのですが、違うのかな、と
思いはじめています。


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

(6482) 6533&z()のバグ  投稿者:文太   2014/06/02(月) 14:50
    6531 番 文太 さんへのコメント    コメント数 1


--- vzt.doc ---
 ◎高橋版Vzの機能
;---- バグフィックス -----
●&z() のバグフィックス。(!Open と wm==0 とキーボードマクロは今後対応予定)
---------------

 これは今回、関係がないと思います。

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

(6482) 6534【資料】 &z()のバグ  投稿者:文太   2014/06/02(月) 17:10
    6533 番 文太 さんへのコメント

konnoさん、本筋からずれてごめんなさい。

10#さん、キーボードマクロ、僕も使うときには「だーいすき」と言いながら
使います。便利ですよね。
 キーボードマクロと&z()とかを話題に絡ませてしまったので、以下を大雑把に
調べました。

 ふつうの使い方では、以下に遭遇することは極めて稀、と言ってよいでしょう。
 僕は経験がない。
 また、高橋版の日付は以下だと思いますので、おおかたvz.com内でフィックス
されているようです。 vzt.com  60,888  1999-12-21  19:19
 ま、こういう、こゆーい世界なのです。テクニカルなことは、僕には理解不能
ですが。

 また、EmmettさんのLXLOADER.DEFは、以下の日付なので、きっと、高橋さんの
指摘を反映されて、そのような複雑なことをするローダーになっているのでしょう。
resize, EMS など。もちろん未見です。

LXLOADER.DEF 3.21 汎用外部マクロローダ v3.21 1999/03/16 仲原孝 (Emmett)

 年表風にまとめると、

m.gann指摘		94/08/14
高橋フィックス法	97/11/03
Emmett ローダー		99/03/16
高橋vzt.com		99/12/21

 僕は断片的な状況証拠から薄っぺらに推測しているだけなので、もうちょい
途中に色々あった・あるように思って下さい。

* ----- * ----- * ----- * ----- * ----- * ----- * ----- * ----- * ----- * 

nifty: FGALDC
>08256/08293 xxxxxxxx  高橋 洋光    &z() のバグフィックス
>(15)   97/11/03 20:03                     コメント数:1


   &z(ptr) をバグフィックスすると以下のようになります。
   (ラベル :e はロード失敗のエラー処理)

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

                (mg.14<pn.5)?>e                         ; ※1  by m.gann
                (wm)??{                                 ; ※2  by m.gann
                        (s-sm)?>e
                        (s==3)?{#[ &s #95 #E &d #98}
                              ?{&s cp[,#> lx[,#H #95 #E (r])?#u cp],#?}
                }
#ifn s16
                ;--- 榊原版対応 ----
                fg..33-,                                ; ※3  by m.gann
                                                        ; ※4
                (sm)?&i("$
                $(50,53,8B,1E,A0,01,B4,50,CD,21,A1,C4,03,0B,C0,74)$
                $(14,8E,C0,BB,FF,FF,B4,4A,CD,21,B4,4A,CD,21,72,05)$
                $(03,C3,A3,CA,03,5B,58,C3)")
#endif

                rr-,                                    ; ※5−1
                wm.2+,                                  ; ※6
                &z(ptr)
                (wm.21&$F0)??{                          ; ※7
                        r[,(sm)?&Em(fz)?&Em(wa..10) r],
                }
                pq..137.0-,                             ; ※8  by m.gann
                (r||rr==0)?>e                           ; ※5−2

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

  ※1  キーボードマクロでの不具合

   私はキーボードマクロを使用してないため、全く研究してません。登録し
  ていないマクロをキーボードマクロから呼ぶと不具合が起こるとの事。(^^;
   詳しくは PK MES13 #01742 参照。(--- see below, added by bunta)


  ※2 vz -z で常駐直後、編集モードへ一度もいかずに、\[CR] でファイラー
        またはコマンドラインで &z() を実行すると画面が崩れる。

   常駐直後には、 Vz はまだ完全にはワークの初期化を終了していません。
  wm など初期化されぬまま(wm==0)、 &z() を実行してしまいます。

   この辺は説明が難しい。&z() が実行できるなんて奇跡。(^^;
   画面が崩れてしまうのは   &z() が EMS を使用、 Vz が EMS を使用する
  ためのワークも初期化さていないので再マッピングも不能( vz 上のページ
  は変化するが、EMM ハンドル上では変化せず)。そのため、ファイラープー
  ルではなくて読み込んだ .def ファイルを使用して無理矢理強引に表示して
  るため。データのフォーマットが違うためグチャグチャ。(^^;


  ※3 未登録のプリフィックスキーでカスタマイズ後の不具合。

   未登録のプリフィックスキーや、メニューでカスタマイズエラーを起すと
  headerp (fg..33) が初期化されずに残ってしまいます。   これはポインタ
  ですが、モジュールヘッダ部分をカスタマイズしたかどうかのフラグにもな
  っています。
   このフラグが残っているため、再度カスタマイズした場合、モジュールヘ
  ッダ部分はすでにカスタマイズ済みと勘違いし、最後のモジュールと接続し
  てしまいます。


  ※4 編集モード以外で実行すると、メモリーアロケーションエラーでハン
        グする場合がある。

   コマンドラインまたはファイラーから、スワップせずに command.com  を
  呼ぶと、pq..157  (ほぼ、kz:kp) の位置より後ろを、command.com を実行
  するために領域を解放します。この時、DOS はいろいろな情報をこの領域の
  先頭に埋めこみます(MCB : メモリーコントロールブロック)。
   command.com  実行後、編集モードへ行かなければ、この MCB はそのまま
  の状態になっています。&z() は この MCB がある場所と同じ場所を.def を
  読み込む場所にしているため、MCB の上にファイルを上書きしてしまい壊し
  てしまいます。再度  DOS を呼んだ時、情報は失われていますのでハングす
  る結果になります。


  ※5 .def ファイルをカスタマイズしなかった場合、rr が初期化されない。

   &z()  など再カスタマイズ系の関数・コマンドは、文法的にエラーを起こ
  さなければ正常終了してしまいます(返り値 r は 0 )。例えば、通常のフ
  ァイルや .def  ファイルで「* macro」の無い物は r==0 です。 この時 rr
  は変化しないので、&z() のエラー処理を r だけで判断した場合、>* &* を
  実行した時の動作は不定です。


  ※6 &z() で EMS を使用した場合、使用した EMS ページを解放しない。

   &z()  は、ファイルをロードする場所がなければ(例えばメインメモリー
  を使い切ったなど) 、未使用な EMS を2ページ確保し、そこにファイルを
  読み込みます。しかし、クローズする時 wm.2 のテキスト番号は0番ですの
  でコンソールファイルと勘違いし、EMS を解放しません。 このページは Vz
  を終了しなければ常に使用中になってしまいます。
   &z()  を実行するごとに新たに未使用なページを確保するので、フリーペ
  ージが2ページずつ減って行く結果になります。


  ※7  &z() で EMS を使用した場合、EMS のマッピングがそのまま。

   &z() のテキストバッファが EMS の場合、マッピングを元に戻していませ
  ん。編集モードで実行した場合、もし編集ファイルが EMSに有った場合(コ
  ンソールなどは常に)、編集ファイルへ文字を書きこむと、画面が崩れファ
  イルが破壊されます。
   ファイラーだと、 #P のパス名の変更を実行すると、パス名は変化します
  がファイル名は元のパスままです。


  ※8 ファイラーで &z() 使用後、#U (newpath) などを実行すると、カー
        ソル位置が変化する。

   &z() 実行時、ファイル名をフルパス名に変換する時、pathbuf (pq..137)
  を使用します。本来ここは、ファイラーでパスを変更した場合にファイルの
  検索用に使用されます。&z () 使用後初期化しませんのでゴミが残ってしま
  い、#U などを実行した場合、通常カーソルは先頭に戻ってしまいます。


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

   !Open 時の &z() は特殊ケースなので省略。


* ----- * ----- * ----- * ----- * ----- * ----- * ----- * ----- * ----- * 

nifty: FGALPK
>01742/01742 xxxxxxxx  m.gann           キーボードマクロと外部マクロ
>(13)   94/08/14 22:07

 マクロバッファに読み込まれていない外部マクロを、キーボードマクロに登録
 するとトラブルが発生します。これはモジュールメニューのキーボードマクロ
 サイズの異常として現われ、そのまま使い続けると、ハングアップなどの二次
 トラブルに見舞われます。

 この経験のある方、気になる方は次のチェックを入れておくと安心です。
 (キーボードマクロを活用している人は、案外少ないようでもあるが..)

 このチェックにより、キーボード登録中、またはキーボードマクロから呼ばれ
 た場合は &z() 以降を実行しません。


41 ^K^ "再カスタマイズ"
        &07 &#80(0)

42 ^KZ "全角/半角変換" &07 &z("zenhan") >*     ;&07: 安全チェック
43 ^KB "矩形ブロック" &07 &z("block") >*

7:      &Im(fg+65,0)                            ;init storep, headerp
        (pn.5||mg..2..(-5).8=='$')??.           ;to kbd || from kbd
        &b(9) &q                                ;pn.5: dspkeyf


;7:     &Im(fg+65,0)                            ;init storep, headerp
;       dz[$a000, r=((lc-1)*160).2, dz],        ;画面左下隅の 'm' を検知
;       (r-'m'&&mg..2..(-5).8-'$')?.            ;するようにした場合
;       &b(9) &q


※ mg..2..(-5).8 の -5 はネストの深さによる。

※ &Im(fg+65,0) はカスタマイズエラー時の不具合い解消(前述)

※ こうした安全策を採用する場合は outlaw などの利用が有利。>上村さん

※ トラブルだけ防止できれば十分だと思うけど。>榊原さん

 m.gann


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

(6482) 6535Re^25: 解決!VTDOSでのlxschd.def 設定  投稿者:konno   2014/06/03(火) 00:14
    6531 番 文太 さんへのコメント    コメント数 2

>  konnoさんは、LXLOADER.DEFをお使いではないと思われます。 
>  &z()マクロロード関数にバグがあり、関数の上位互換として各種のマクロ
> ローダー・マクロがあります。

文太さん、私の言いたかったことを分かりやすくまとめてくださり、どうもです。
答はLXLOADER.DEF3.21の中にありました。

軟体のLXLOADER.DEF3.21のパッケージの中の、BF_PLUS.DOC の解説を引用します。

---------------------------------------------------------------
                    ※※ #BF+ の設定について ※※

  中略

 さて、 問題は、メインメモリが Bf KBytes よりは残っているが、しかし Bf+32
  KBytes よりも少なくなってしまった場合です。 この時VZは、メインメモリが
  足りないにもかかわらず、残りのメインメモリいっぱいのサイズのテキストバッ
  ファだけを確保して外部マクロを読もうとします。これでは、ちょっと大きなマ
  クロファイルは最後まで読み込まれず、「尻切れ」の状態でロードされてしまい
  ます。本来なら、こういう読み込み方が行なわれた場合は、何らかのエラーコー
  ドを返してロードを中断すべきところですが、VZは何事もなかったように正常
  終了してしまうのです。

  中略

  そこで、EMS ド貧民を救済するための方策が、この #BF+ の設定なのです。
                                    *
 この設定を行なうためには、 必ず Bf88 以上の数値を指定し、 かつオプション
  Sk- の状態で、VZを起動することが絶対に必要です。こうすると、どんなにテ
  キストを多くオープンしてもメインメモリは常に  88 KBytes 以上は空いている
  ことになりますね。この状態で #BF+ にしておくと、強制的に LXLoader 内部で
  Bf52 に設定変更した上でマクロをロードしますので、 マクロをロードするテキ
  ストバッファが最低限  32 KBytes 程度は常時メインメモリに確保できるわけで
  す(88-52-32=4 の 4 KBytes は、VZが作業用に使う余裕です)。

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

このDOCはLXLoaderの動作の仕組の解説のようですが、&zの不具合回避法としてみると
Bf88
Sk-
の設定がいいようです。先のopt_listでは私のだけ Sk+ になっていたので上記の
設定に変更してlxschd.def 実行したら、VTDOSで正常なデータが出来ました!!

先人の資料や過去ログはやはりお宝ですね。


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

(6482) 6536Re^26: 解決!VTDOSでのlxschd.def 設定  投稿者:10#   2014/06/03(火) 00:34
    6535 番 konno さんへのコメント    コメント数 1

なんとまー、問題の答えは古文書にありましたか。
VTDOSの不具合調査は時に発掘作業の様相を帯びることが多々ありますが、
ことVZに関しては先人の残した資料が最も有用ですね。
先人って、同世代なんですけどね(^−^)

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

(6482) 6537Re^27: 解決!VTDOSでのlxschd.def 設定  投稿者:文太   2014/06/03(火) 00:46
    6536 番 10# さんへのコメント

konnoさん、おめでとう! konnoさんなら、きっと解法を見つけるだろうと
思ってました、本当に!

>先のopt_listでは私のだけ Sk+ になっていたので上記の
>設定に変更してlxschd.def 実行したら、VTDOSで正常なデータが出来ました!!

 やった、解決! いちおうチームプレイということで。v(^^)z

 僕、この.docを読んだことがあります。12時間くらいかけないと、今は、何を
言っているのか分からないだろうけれど。

----------
@SK @Sk @sk 
その他のスイッチ
 Sk  -   DOSコマンド実行前にテキストスタックをクリア
----------

 うぐ、意味不明だ。

 とにかく、やった! 意味不明だけど、かなり嬉しいですよ。V(^^)z


10#さん、SK みたいな暗号の意味は、saki..さんの、stkhelp.defですぐ分かります。
マクロに興味がなくても、長期にわたってVzとつき合う場合、これは有用ですよ。
 辞書を引いても、何も考えない奴も使っておりますが。

「軟体」
STKHELP.DEF 1.60B11 汎用ヘルプシステム STKhelp v1.6β11 2004/12/29 長崎則久
STKHB11.LZH	14592	ish VZMACRO.SHD

 マクロもすごいのですが、VZMACRO.SHDがキモです。

 「同世代」、なのかな? おじさんたち。
 でも、楽しいですよん。ワクワクしちゃう。
 こういうところで変に感動とかしてるし。


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

(6482) 6538Re^26: 解決!VTDOSでのlxschd.def 設定  投稿者:10#   2014/06/03(火) 23:45
    6535 番 konno さんへのコメント    コメント数 2

BF_PLUS.DOCを読んでみましたが、
このドキュメントからよくSk-を導き出しましたね。感心します。
逆にVTDOS以外の環境ではSk+でも問題なかったんですか?
オリジナルの&zはかなりコワい仕様(仕様?)だったようですね。
これはtVZでは解消されているため、LXLOADERは不要、という解釈で
OKですか?
      - No.6538 -    このTreeへ    コメント元:6535 へ [リストへもどる] soft

(6482) 6539追加情報  投稿者:文太   2014/06/04(水) 01:01
    6538 番 10# さんへのコメント

--- vzt.doc ---
■ &z() のバグフィックス
 詳細は FGALDC MES15 #08256 参照。(前掲 by bunta)
 ただし、その後に見つかった不具合は、vzt のみ更新してあります。
---------------
 ということは、まだあったのね。


-------------------
nifty: SVC
>00327/00499 xxxxxxxx  c.mos            -Bf
>( 2)   93/09/28 01:49  00318へのコメント

何件か報告がありますが、「-Bf」を無指定、あるいは1に設定して、
テキストバッファを常時EMS上にとると、1.58aでは動作が不安定になります。
(全くデバッグしていなかった)

とりあえず「-Bf64」でお使いください。

ちなみに、「-Bf」指定は、何のメリットもないです。
さらに、テキストバッファが32KBとなり、テンポラリのブロックサイズが16KBと
小さくなるため、ラージファイルのジャンプも遅くなります。
			c.mos
-------------------
 m.gannさんは、作者が「メリットなし」と言ったことにメリットを「創った」
わけなんだ、すごいなぁ。
 コマンド#99もしかり。

-------------------
>02582/02587 xxxxxxxx  m.gann           #99
>( 2)   93/11/25 22:55  02456へのコメント  コメント数:1

 以前、#99 を #O #J #56 の窓でも使えるようにして欲しいと要望したことが
 あったけど、なんの反応もなし。
 却下というより、話がとんと通じていないらしい。


>02625/02627 xxxxxxxx  榊原 知     謎のコマンド#99
>( 2)   93/11/26 19:48  02586へのコメント

 #02586 c.mos さん
 #99 の動作をソース上で追っかけてみましたが、これは偶然の産物みたいで
すね。
 1行入力ルーチンで #97以上のコマンドが実行されると、[CR]と同様に入力
した文字列をヒストリーに格納した後、呼出元にコマンド番号を返します。
 コマンドラインモードではコマンド番号を確認してそれに応じた処理をしよ
うとしますが、#99 というコマンドはないので何もしません。結局、入力中の
文字列がヒストリーに格納されるだけです。
 一方、 入力窓の場合は[ESC]かどうかを区別するだけですから、[CR]と同様
の処理が行なわれます。それで、入力窓の場合は #99 が使えないのです。
-------------------

 とんと通じてなかったんです。そこまで読むか、m.gannさん。

 あ、すいません、調子に乗りました。個人の著作物なので、こういう引用は
(こんなに盛大には)もうしません。


>これはtVZでは解消されているため、LXLOADERは不要、という解釈で
>OKですか?

 これにちゃんと原理的に答えるのは konno さんの役回りです。
 僕は大丈夫でしょう、と思ってます。状況証拠: lxloader 必須という話は聞
いたことがない。

 vzt.doc に書かれてないバグまで潰してくれてるのだから、、、。
 &z()  関連かどうか記憶にありませんしちょっと調べられませんが、tVZ のあ
と、DANNYさんが、dVZ を作られていて、さらにVzのバグを潰しています。
 困ったソフトですが(ふつうそうバグに遭遇することはないでしょう、という
のは高橋版をずっと使ってきた恩恵なのですが)、だからかえって、マクロ師た
ちが燃えた、というのも本当かもしれませんね。

 VTDOS 1.41、使ってゆきますね。
 何かあったらレポートさせていただきます。
 しばらく本業に集中します。m(__)m


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

(6482) 6540Re^27: 解決!VTDOSでのlxschd.def 設定  投稿者:konno   2014/06/04(水) 22:48
    6538 番 10# さんへのコメント    コメント数 3

10#さん、文太さん、すみません、間違いでした。

bf88、sk- で正常データがいったんできたんですが、その後の再現では
また異常データが出るようになってしまいました。
環境を色々変更しているので混乱があったようです。

しかたがないので、bt64 を、bt32 に変えてみたら、こんどこそ正常になりました。

こんどは間違いないです。

bt32
bf88
sk-

の3点セットでlxschd.def は完璧に動作します。

bt32 にするとバッファが細切れになる分スピードが落ちることになるので
できればやりたくなかったのですが、背に腹は変えられない。
Win7ならその差はほとんど体感できないていどでしょうが。

> このドキュメントからよくSk-を導き出しましたね。感心します。

実は2010年ごろまでは、sk- だったようです。
なぜ sk+ に変えたのかまったく思い出せません。
このドキュメントの話は私も読んでいたので、これを見たときにピンときたのです。

> 逆にVTDOS以外の環境ではSk+でも問題なかったんですか?

おそらくどこかを壊してたんでしょうが、たまたま影響が出にくいところだったのかも。
事実、Sk- にしてから、コマンドラインの挙動が安定しました。
3点セットにしたら、Win7のDOS窓で起動時に出ていた不正な文字も出なくなりました。

> オリジナルの&zはかなりコワい仕様(仕様?)だったようですね。
> これはtVZでは解消されているため、LXLOADERは不要、という解釈で
> OKですか?

TVZでほとんど解消はされていますが、上記のごとくまだバグは残っています。
オプションの組み合わせで解消できた今回はラッキーというべきでしょうか。

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

(6482) 6541Re^28: 解決!VTDOSでのlxschd.def 設定  投稿者:文太   2014/06/05(木) 00:37
    6540 番 konno さんへのコメント

konnoさん、

>bt32, bf88, sk-,
>の3点セットでlxschd.def は完璧に動作します。

 おめでとうございます、今度は本当に。
 いやぁ、面倒でトリッキーな変数ですねぇ。
 悩んだあげく、bfは88にしました。btは64のまま。
 btは32でも、それほど、、、と考えて、マクロのサイズを調べました。
 stkhelpがデブ、vz.defもデブ、blogjumpもデブ、でも32Kに収まってました。
 でも、bt64で。

>bt32 にするとバッファが細切れになる分スピードが落ちることになるので……
>Win7ならその差はほとんど体感できないていどでしょうが。

 そうなのかぁ、マシン語というかVz本体の処理ならそうなんでしょうね。
 いえ、僕はWin7でのVzの(Vzマクロと外部コマンド−−grepとか−−)
動きの遅さに、やだなぁ、って思ってしまって、XPのNTVDMがいいよ、まだ、
いや、WimMEが最高だ、とか思ってしまってます。
 本当に後ろ向きな奴です。でも、本気の仕事はこっちだな、との感を強くして
しまいました。
 でも、Win7でVzがIME付きで動くというのは、とてつもない安心感です。

 今回もおつき合い頂きまして、ありがとうございました。 m(_B_)m


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

(6482) 6542Re^28: 解決!VTDOSでのlxschd.def 設定  投稿者:10#   2014/06/05(木) 01:22
    6540 番 konno さんへのコメント    コメント数 1

なるほど。
よほどでない限りBt64はデフォだと思うので、ここは盲点かもしれませんね。
僕も次にクラッシュが起きたときはBt32にしてみようかと思います。

有名な話ですが、command.comは子プロセスのためにメモリーを一部解放し、
戻ったときに、開放したメモリーの一部を再利用しようとしますよね。
チェックサムで妥当性の検証をした上でなんですが。

VZも開放したフリーエリアの再利用をしているフシがあるので、
command.comと衝突したりして、安定性に影響がでることもあるかな?
と想像しています。


grepは32bitでいいのを探せばネイティブの性能で動作しますよ。
僕は現状16bit2種類と32bit1種類使い分けてます。
16bitコマンドが使いにくくなってきてるので完全移行したいところですが、
新しいgrepはなかなか思うように探さなかったりします。
マニュアル読めよという話なんですけどね(^^;)


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

(6482) 6544Re^29: 解決!VTDOSでのlxschd.def 設定  投稿者:konno   2014/06/06(金) 00:14
    6542 番 10# さんへのコメント

> よほどでない限りBt64はデフォだと思うので、ここは盲点かもしれませんね。

Emmettさんは同じDOCの中で Bt32 にも言及しています。

> もしもこれで困る場合は、オプション Bt の値をもう少し小さくしてやる必要が
> ありますね。 といっても、Bt32 より小さくしたのでは、せっかくの #BF+ の設
> 定が無に帰することになりますから、 Bt32 で起動するのが最善の方策となるで
> しょう。このへん、設定に頭を悩ませる必要のあるところです。

これは少ないメモリをやりくりするための手段のようですが、Bt32はバッファの
転送サイズとしてある意味ベストサイズなのではないかと思います。
なにせ、VZには64kの境界をまたぐ処理にバグが残っているように思えるので。

32kで2度に分けて処理する場合は64kの境界を超えることがないのでバグが出ない
のではないかと思っています。

> VZも開放したフリーエリアの再利用をしているフシがあるので、
> command.comと衝突したりして、安定性に影響がでることもあるかな?
> と想像しています。

まさにその通りで、モードによっては同じエリアにマクロをロードすることがあります。
当然MCBの情報が壊されるので、その後外部コマンドを使用するとメモリアロケーションエラーになるわけです。

これはFGALDCでは既知の情報ですが、10#さんはDCには参加されてなかったでしたっけ。

> 新しいgrepはなかなか思うように探さなかったりします。
> マニュアル読めよという話なんですけどね(^^;)

うう、私もいまだにwgrepしか使えてないんです。脳の劣化のせいですかね。(^^;

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

(6482) 6543Re^28: 解決!VTDOSでのlxschd.def 設定  投稿者:10#   2014/06/05(木) 22:55
    6540 番 konno さんへのコメント    コメント数 2

今更ですが再現したためご報告します。

僕の環境ではEMSを使用し、Btが54以上で再現しました。
これは以前からの条件なので、見落としがあったか、
それ以外の条件があるのかも知れません。

BtオプションとEMSが関係するtext.asmをざっと眺めてみましたが、
障害が発生する仕組みを見出すには至っていません。
あるいは、macro.asm辺りのほうが関連性が高いかもしれません。

えっと、後世に向けての覚書です。
      - No.6543 -    このTreeへ    コメント元:6540 へ [リストへもどる] soft

(6482) 6545Re^29: 解決!VTDOSでのlxschd.def 設定  投稿者:文太   2014/06/06(金) 00:27
    6543 番 10# さんへのコメント

10#さん、以下、ありがとうございました。

>今更ですが再現したためご報告します。
>えっと、後世に向けての覚書です。

 すごいです、ちゃんとしてます、さすがです。

 うーん、やっぱり出るんでしょうね、どうでもいいことですが、僕は最初、こ
れは「不具合」再現が難しそうだな、と思い、やがて、なぜか、きっとこれ、や
っぱり出るんだろうと思っていました。
 いつの日にか、ここに、こんなバグが! ほら、条件を整えたら、皆のところ
でも出るでしょう、なんてなれたらいいですね。
 MS-Dos のメモリ管理とVzのそれ、なのかな……?
 lxloader、関係ないんだよなぁ……?

 ◎高橋版Vzの機能
●&z() のバグフィックス。(!Open と wm==0 とキーボードマクロは今後対応予定)
                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
                  注意すべきは、いちおう、ここです。
                  エディタですから、まず、テキストの編集を
                  しましょう!
                  キーボードマクロを使う人は、基本コマンド
                  のマクロ化は、よくよく考えて行いましょう!

#81, ^K_, :KBM_Print で、&nnとか出たら、注意ですよ。
キーボードマクロは、#aみたいなのの羅列であるのが普通です。

 閑話休題。

>grepは32bitでいいのを探せばネイティブの性能で動作しますよ。
>僕は現状16bit2種類と32bit1種類使い分けてます。

 なるほど、研究・実験してみます。するしかないですね。
 僕の32ビット・コンソール・アプリについての印象はあまりよくありません。
思いっきりメモリが使えるはずなのに、速くない、という感触でした。どれだけ
の長さのスクリプトを読み込めるか、となったら、もちろん、32ビットの圧勝
でしたが。
 16bit として、僕はグレップで、cgrep, ygrep, izgrep, grep (GNU) を使い
分けているというか、それぞれをそれぞれの場所で習慣的に使ってます。32bit
では、yagrep, jgrep2 ですね。最後のはコンソール・アプリでないので、ちょっと。
 10# さんの3つって何でしょう、教えてくれませんか。

 GNUは正統です。 でも、BRE, ERE, Perl5-like なんてオプションで分けな
いで(正規表現ってそれでなくても、すぐ間違えるから)、全部 Perl5-like で
いいな、と思ってます。それで、jgrep2 も(でも、あれは半端)。やはり本物は
yagrep。
see 野ざらし言: #4366.
http://hpcgi3.nifty.com/mezala/noz/wforum.cgi?no=4366&reno=4360&oya=4230&mode=msgview&page=0
 ただ、sed になると、ちょっと違いますかね。 置換は深刻なので。 これは、
serow SED と Onigsed です、僕は。


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

(6482) 6546Re^29: 解決!VTDOSでのlxschd.def 設定  投稿者:konno   2014/06/06(金) 00:34
    6543 番 10# さんへのコメント    コメント数 1

> 今更ですが再現したためご報告します。
> 僕の環境ではEMSを使用し、Btが54以上で再現しました。

Bt54以内なら再現しないということですね。
関係ない話かもしれませんが、10#さんが Bf16384 なのは何か理由があるのでしょうか。

> BtオプションとEMSが関係するtext.asmをざっと眺めてみましたが、
> 障害が発生する仕組みを見出すには至っていません。
> あるいは、macro.asm辺りのほうが関連性が高いかもしれません。

ひとつ前の記事に書きましたが、VZで64kをまたぐ境界付近の処理でバグが残って
いるように思います。そのからみではないかという気がします。

プロフィール情報とか何か影響することってありますかね。
      - No.6546 -    このTreeへ    コメント元:6543 へ [リストへもどる] soft

(6482) 6547Re^30: 解決!VTDOSでのlxschd.def 設定  投稿者:10#   2014/06/06(金) 23:56
    6546 番 konno さんへのコメント    コメント数 1

niftyは会員だったこともあるんですが、基本的にROM専でした。
ログも残してないので何をやってたのかも定かでないです。

Bfはvz.defでは256なんですが、なぜ16384なんでしょうね。

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

(6482) 6548Re^31: 解決!VTDOSでのlxschd.def 設定  投稿者:konno   2014/06/07(土) 01:56
    6547 番 10# さんへのコメント

> niftyは会員だったこともあるんですが、基本的にROM専でした。
> ログも残してないので何をやってたのかも定かでないです。

そ、そうでしたか。私もROMが長かったですが、表に出ない人も沢山居たんでしょうね。

> Bfはvz.defでは256なんですが、なぜ16384なんでしょうね。

Bfの数字 * 64 のようです。
Bf88 なら、88*64 で、5632 ですね。


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

(6482) 6496Re^7: VTDOS140  投稿者:10#   2014/05/25(日) 17:13
    6492 番 shadow さんへのコメント    コメント数 1

32bitのmasm6.14で試した限りは、問題なくアセンブルできました。
16bitのmasm6.11は386以降が必要なため、VTDOSではインストールできませんでした。
masm6の入手方法が分かれば教えていただきたいです。
最近のmasmは.186のアセンブルできませんね。

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

(6482) 6497Re^8: VTDOS140  投稿者:shadow   2014/05/25(日) 19:16
    6496 番 10# さんへのコメント    コメント数 1

入手したのは、おそらく2001年ころでlink切れになっているようなので関連ファイルをメールにて送信しました。

うーん、niftyメールでは上手く送信できず、gmailでは実行ファイルは送信できないのですね。@yahoo.co.jpで送信しましたので未着であればご連絡ください。

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

(6482) 6498Re^9: VTDOS140  投稿者:shadow   2014/05/25(日) 20:17
    6497 番 shadow さんへのコメント    コメント数 1

失礼しました。
実行ファイルを添付できないと言ううことは受診もできないですね。

ml関連ファイルを”宅ふぁいる便”にアップロードしました。
ダウンロードURLはgmail宛に送信しました。
よろしくお願いします。
      - No.6498 -    このTreeへ    コメント元:6497 へ [リストへもどる] soft

(6482) 6519Re^10: VTDOS140  投稿者:10#   2014/05/30(金) 23:51
    6498 番 shadow さんへのコメント    コメント数 1

VTDOS1.41ではメッセージの内容は変化しましたが、
メモリ不足のエラーが出ます。
6.1x以降の32bitMASMへの移行をお勧めします。

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

(6482) 6524MASM の歴史  投稿者:文太   2014/06/01(日) 00:50
    6519 番 10# さんへのコメント

 記念に、ちょっと備忘録というか、調べてまとめてみました。
 気にしないでください、自分史みたいなものですから。
 ちょっと前からやりたかったの。


beginning	1981
MASM 3.0	1984, MS-DOS 3.0
MASM 4.0	1985, with symdeb 4.0, mapsym 4.0,  masm.exe 85,566 1985-10-16 04:00
MASM 5.0	1987
		1989, Vz Editor 1.5
MASM 5.1/6	OS/2アプリケーション(masm.exe -> ml.exe)1991, MS-DOS 5.0
MASM 6.1	32ビットWindowsのコンソールアプリケーション
		当初、バージョン6.1と6.11ではMS-DOS上で動作させるため
		Phar Lap TNT DOSエクステンダが同梱された。
		ただし、6.1は最終バージョンのWindows NTでは動作しない。
MASM 6.11	パッケージ販売されたMASMの最終バージョン
		MASM.EXE = a compatibility driver for users of earlier versions of MASM.
		ml.exe is the assembler. 6.0, ditto.
		1993/12, Vz Editor 1.6
MASM 6.11d	16bit 最終ヴァージョン(ml.exe  388,096  1995-02-19  10:30)1995
		1995, Win95
MASM 6.14	+patch, to 32bit Win Console Application 1999 
		2000, WinME
MASM 6.15	Visual C++ 6.0 プロセッサ・パックの一部。2000
		2001, WinXP
MASM 7.0	Visual C++ .NET 2002に同梱。
MASM 7.1	Visual C++ .NET 2003に同梱。
MASM 8.0	Visual C++ .NET 2005に同梱。
		x64版とあわせて(ml64.exe、x64コードをアセンブル)

【参考文献】
MASM, wiki:
http://ja.wikipedia.org/wiki/Microsoft_Macro_Assembler
MASM32:
http://www.masm32.com/history.htm
MS-DOS, wiki:
http://ja.wikipedia.org/wiki/MS-DOS#.E6.AD.B4.E5.8F.B2
Vz年表 by mezala:
http://homepage3.nifty.com/mezala/vz/history/chrono.html
MS Windows, wiki:
http://ja.wikipedia.org/wiki/Microsoft_Windows#Windows_95_.2F_98_.2F_98SE_.2F_Me

16bit
MASM 4.0		masm.exe  85,566  1985-10-16  04:00
MASM 5.1		masm.exe 110,899  1990-06-21  00:00
MASM 6.11d		ml.exe   388,096  1995-02-19  10:30
			masm.exe  49,152  1993-08-19  18:50
32bit
MASM 7.10.4035		ml.exe   413,696  2005-03-24  16:25
MASM 8.00.50727.218	ml.exe   357,120  2006-09-23  22:55


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