皆さん、こんにちは。

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

　通常のＤｏｓ窓Ｖｚでは、起動できます

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

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

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

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

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

　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）、だめでした。

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

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

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

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

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

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

あきろさん

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

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

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

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

　こんばんは。

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

> 　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をチェックしているので、その部分をコメントにと
書いたつもりでした。
でも、結果的には関係なかったようですね。

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

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

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

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