[HOME]  [全部表示 会議室風]  [全部表示 保存用]  [HOME]  [リストへもどる] [リストへもどる]

一括表示


  stkhelp.def は入力できません - あきろ 10/01/16-12:54 No.4861
 ┗ Re: stkhelp.def は入力できません - めざら 10/01/16-16:28 No.4864
  ┗ Re^2: stkhelp.def は入力できません - あきろ 10/01/16-18:48 No.4865
   ┗ Re^3: マクロローダーを替えたら・・ - あきろ 10/01/17-16:07 No.4870
    ┗ Re^4: マクロローダーを替えたら・・ - konno 10/01/17-21:53 No.4871
     ┗ Re^5: LXLoaderでも起動するようになりました - あきろ 10/01/18-01:35 No.4877
      ┗ サイズの問題のようです - konno 10/01/20-01:33 No.4891
       ┣ Re: サイズの問題のようです - あきろ 10/01/24-01:23 No.4915
       ┗ Re: サイズの問題のようです - konno 10/01/26-00:28 No.4918

(4861) 4861stkhelp.def は入力できません  投稿者:あきろ   2010/01/16(土) 12:54
   コメント数 1

 皆さん、こんにちは。

 私の所では、vtdos(Vz)にて、stkhelp.def を起動しようとすると、
「stkhelp.def は入力できません」というメッセージが出て、起動できませ
ん。

 通常のDos窓Vzでは、起動できます

 vtdos は、1.16〜1.18 どれでも同じ結果でした。command.com は、MSDOS6.2
です。

。皆様のところでは、どうでしょうか?

      - No.4861 -    このTreeへ           [リストへもどる] pre

(4861) 4864Re: stkhelp.def は入力できません  投稿者:めざら   2010/01/16(土) 16:28
参照先:http://homepage3.nifty.com/mezala/
    4861 番 あきろ さんへのコメント    コメント数 1

 あきろさん,こんにちは。

 うちでは vtdos v1.16 + PC-DOS6.3 + vzt03k_k07t で,所期の動作です。

> 「stkhelp.def は入力できません」というメッセージが出て、起動できません。

 このメッセージを誰が出しているかが問題ですね。
 あきろさんは,ローダーに無法者を使っていませんか?
 手近なファイルをスキャンしたところ,&m(2) を使っているのは無法者だけでした。

 この疑いが当たっていれば,何らかの理由でメモリ(マクロバッファ含む)不足の可能性が高いと思われます。

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

(4861) 4865Re^2: stkhelp.def は入力できません  投稿者:あきろ   2010/01/16(土) 18:48
    4864 番 めざら さんへのコメント    コメント数 1

 めざらさん、こんばんは。

 無法者は、使ってません。当時、よく分からなかったので、わかりやすかっ
た LXLoader.def を利用しています。

 起動直後のVzをマクロメニューで見ると、

 LXLoader.def(v3.21)
 LXLD_CFG.def
 vzfl.def
 ffauto.def
 freeform.def(v2.30c)
 specium.def

 が読み込まれています。が、どのマクロにも &m(2)は記述されていないよう
です。

 vz.def(vtdos では、vz_vtdos.def) の、あちらこちらバッファサイズなど
を大きくしてみましたが、起動しません。

 うーん、原因はどこにあるのだろうか。(。_゚?

 もう、あれこれとマクロを使わなくなったので、何とも言えないのですが、
今のところ、stkhelp.def だけが起動しません。

 ファイラーで見てみると、こんなにサイズの大きいマクロは、他にはないで
すねぇ。やっぱり、何かのメモリ不足なんだろうなあ。環境変数の領域サイ
ズも大きくしてみましたが(/e:8192)、だめでした。

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

(4861) 4870Re^3: マクロローダーを替えたら・・  投稿者:あきろ   2010/01/17(日) 16:07
    4865 番 あきろ さんへのコメント    コメント数 1

 めざらさん、こんにちは。

 stkhelp.def が起動できなかった問題ですが、マクロローダーを LXLoader
から outlaw に変更してみると、無事に起動しました。

 vtdos と LXLoader の組み合わせで起きるようです。原因はさっぱりわかり
ませんが。

 ところで、outlaw では、マクロ登録の時に、シフト実行で読み込むマクロを
変更できるのでしょうか? LXLoaderでは、以下のように記述することで可
能なのですが。

86 ^QN "newfile" (ks&1)? >> &88
86 "newfile2" &88

 outlawに完全に移行すのは、ちょっと大変で尻込みしてしまうなあ。でも、
登録したマクロの多くは、今は利用していないので、整理になってよいかな?
(^^;

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

(4861) 4871Re^4: マクロローダーを替えたら・・  投稿者:konno   2010/01/17(日) 21:53
    4870 番 あきろ さんへのコメント    コメント数 1

あきろさん

>  vtdos と LXLoader の組み合わせで起きるようです。原因はさっぱりわかり
> ませんが。

マクロファイルが読めないときにこのメッセージが出るようですね。
この症状はVTDOSの以前のバージョンからあったのでしょうか。

LXLoaderは200LXのスリープチェックをしていますね。この int15hのファンクションは
VTDOSでは無効状態になっているので、もしかしたらこれが原因かもしれませんね。
#LXの行をコメントにしてみたらどうでしょう。

まあ、outlawに移行するのがいいのかもしれませんが、原因が気になったもので。

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

(4861) 4877Re^5: LXLoaderでも起動するようになりました  投稿者:あきろ   2010/01/18(月) 01:35
    4871 番 konno さんへのコメント    コメント数 1

 こんばんは。

 結論から言うと、stkhelp.defを最新のものに差し替えたところ、なんなく起
動しました。v1.60β8 → v1.60β11

 どうやら、v1.60β8 は、LXLoader.def のバグ回避ルーチンに引っかかって
いたのではないかと推測というか想像します。

 しかし、もしそうだとしたら、なぜ vtdos(vz)環境でのみバグ回避ルーチン
に引っかかったのかが疑問です。。

(以下、LXLoader.doc より)
○ LXLoader.def に採用されているバグ回避ルーチンが対応しているバグは、 全
部で9種類に及んでいます (^^;;。 LXLoader を使えば、9種類のバグを全部
かいくぐって、安全にマクロをロードするか、もしくは最悪の場合でも致命的
な結果が出る前にエラーメッセージを出して正常終了してくれます。


 以下、参考までに書いておきます。

 実は、v1.60β11 にたどり着く直前に、LXLoader のオプションを変更するこ
とにより、β8 でも起動することができていました。

 LXLoader には、BF オプションというのがあります。通常は「-」つまり off
で使うようにとのことですが、これを on にすると stkhelp.def が起動しま
した。

 このオプション専用の解説ファイルがあり、一部を抜粋します。長いのです
が、私が下手に割愛するよりもよいと思い、固まりをそのまま下に貼り付け
ます。

--------------------------------------------------------------------------
 VZは、メインメモリに十分に余裕がある時は、外部マクロを読み込む際のテキ
ストバッファをメインメモリに取ります。 この時は、 最大で、vz.def のオプ
ション Bt で設定されたサイズのテキストバッファが確保されます。Bt64 の場
合なら 64 KBytes ですね。 従ってこの場合でしたら、マクロファイルのサイズ
が 64KBytes のマクロまでロードできることになります。

 しかし、メインメモリの残りが vz.def のオプション Bf で設定された数値にま
で減少すると、 今度はVZはテキストバッファを EMS に取って外部マクロを読
み込みます。 EMS は通常 2 ページ、32 KBytes 取られますので、この状態なら
32 KBytes のマクロファイルまで読み込むことができることになります。これを
越えるファイルサイズのマクロはまずない(というか、EMS からロードされる可
能性が常に存在する以上、マクロ作家はこれを越えるファイルサイズのマクロを
公開するのはあまり望ましくない)ので、通常はこれでも不便することはまずあ
りません。

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

 LXLoader は、 デフォルトでは、こういう状況に遭遇したら、メインメモリの残
りをゼロだとVZに思い込ませ、 強制的に EMS からマクロをロードさせるよう
に仕組んであります。EMS に常時空きがある環境では、これでまったく問題なく
マクロがロードされます。 しかし、うちのLXみたいに (^^;; EMS にほとんど
空きがない状態だと、 こういうケースではマクロはロードできず、Load Error.
のメッセージと共に組み込みが中断されてしまいます。

 何にも悪いことをしてないのに、突如このメッセージで外部マクロの読み込みが
拒否されるという現象が生じたら、これを疑いましょう。この場合は、テキスト
をいくつかクローズして、メインメモリを Bf+32 KBytes 以上空きのある状態に
して再度実行すれば、マクロはロードできるようになるはずです。

 しかし、この現象は予期せぬ時に突然生じますから、突然マクロが実行できなく
なるのは精神衛生上よろしくありませんね。それに、必要があってオープンして
あるテキストを、わざわざ閉じないとマクロが実行できないというのも不便な話
です。そこで、EMS ド貧民を救済するための方策が、この #BF+ の設定なのです。

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

 結論から言えば、おそらく stkhelp.def v1.60β8 に何らかの問題があった
のだと思います。しかし、なぜ vtdos(vz)環境でのみ起動しないという現象
が現れたのか、その原因を探るための参考になるのでしょうか?

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

(4861) 4891サイズの問題のようです  投稿者:konno   2010/01/20(水) 01:33
    4877 番 あきろ さんへのコメント    コメント数 2

あきろさん、とりあえず、問題は解決できたようで。

>  LXLoader には、BF オプションというのがあります。通常は「-」つまり off
> で使うようにとのことですが、これを on にすると stkhelp.def が起動しま
> した。

今回の問題は、どうやらこれが原因のようですね。

2000/05/11 09:49 33,480 STKHELPv1.60β8.def
2004/12/06 12:34 25,105 STKHELPv1.60β10.DEF
2004/12/29 09:33 25,018 STKHELPv1.60β11.DEF

ご覧のように、新しい版になってファイルサイズがだいぶ小さくなっています。
かなりの最適化がなされたようですね。
これにくわえて、VTDOS環境でフリーエリアが増えたことにより、かえってメインメモリ
が中途半端に残っている状態になって、旧版のサイズでは引っ掛かってしまったと
推測します。だから BF が効いたのだと。

>「+」にして利用したことはないんです。最初っからずっと、「-」です。

これは、「−」でも、int15hをチェックしているので、その部分をコメントにと
書いたつもりでした。
でも、結果的には関係なかったようですね。


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

(4861) 4915Re: サイズの問題のようです  投稿者:あきろ   2010/01/24(日) 01:23
    4891 番 konno さんへのコメント

 なるほど、β11はβ8の3/4のサイズしかありませんね。
 多少すっきりしないところもありますが、とにかく、問題なく動作している
のでよしとします。

 たまに、通常のDos窓Vzを立ち上げてみると、しゃきしゃき動くのが気
持ちよいです。

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

(4861) 4918Re: サイズの問題のようです  投稿者:konno   2010/01/26(火) 00:28
    4891 番 konno さんへのコメント

> 2000/05/11  09:49            33,480 STKHELPv1.60β8.def

よくみると、このサイズって、EMS2ページ分の32kb(32768bytes)を超えてますよね。
これでも読み込めるのかいな、と思って中身を覗いてみると・・・
げげ、タブがスペースになっていますね。これではサイズが増えるわけだ。(++;
で、スペースをタブに置き換えてみたら、30627bytesになりました。(^^;

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