一括表示

> 　DOS の時代は apath というパスを付加するプログラムがあって、
> 重宝していました。窓では利かないようです。この話はいつか、書
> いた気がしますが。

apathって、ベクターで調べてみても２つあるようなのですが、どちらのこと
でしょうか。もしかして、もう一方を使えば窓でも問題解決、ということは
ないか。

元々、pathに限らず、環境変数ってコマンドラインの文字数制限に引っかか
って、長いものを設定する事ができませんでした。生ＤＯＳだと、標準では
コマンドラインて127バイトでしたから。もしかしたらＩＢＭのＤＯＳとか、
あるいはＭＳのＤＯＳでも新しいバージョンのものではオプションで増やす
ことができるかもしれませんが。
この制限よりも長い環境変数を設定したい、ということで、多くのソフトが
作られました。私の知っているいくつかの環境変数追加ソフトも、このよう
ないきさつで作られました。
ところが、窓の時代になって、コマンドラインの文字数制限そのものが緩和
されました。

cf.
http://support.microsoft.com/kb/405531/ja

これにより、この種のソフトに対する世間のニーズは一気に低下。もちろん、
その制限より長い環境変数を使いたいという人は常に存在しますが、一般的
な需要は十分満たしたという事でしょう。

> 　DOS の時代に環境変数を増やすことのできるプログラムがあった
> はずなんですが、窓ではご指示にしたがって環境変数のところを開
> けましたが、環境変数を増やすことはできないみたいですね。あん

「環境変数を増やす」というのは環境変数領域の事でしょうか。
それであれば、増やしすぎると今度は逆にコンベンショナルメモリの領域を
圧迫する事になるので、程々にしておいた方がよろしいかと。
そうではなく、新しい環境変数名と、それに対する値を設定したいという事
であれば、めざらさんのお答えの通り。
マイコンピュータのプロパティのシステムの詳細設定の中の環境変数のとこ
ろに追加ってありませんか？
私も知らなかったのですが、もしかして、制限ユーザであればこれが表示さ
れないという事なんでしょうか？　＞　めざらさん
 

> 　apath は 1992 by North/P.P.P.という署名があります。 ＤＯＳの

あ〜、鷲北君のですね。
＃彼は大学の後輩です。

ま、新しい時代というか新しい環境になって、それまでのツールで不都合を
きたすようになったら、ベクターなどで新しいツールを探すようにした方が
いいでしょう。私の経験では、むしろ、そういう機会を捉えてソフトあさり
をすることにより、思わぬソフトに巡り会うなど、嬉しい副作用があること
も多いです。

> 　環境変数容量を増やすとコンベンショナル・メモリが食われるの
> はわかりますが、ＥＭＳをたっぷり取っていても、コンベンショナ
> ル・メモリは多いほうがいいですか？

Ｖｚ *だけ* を普通に使っている分には、極端な値に設定しない限り、環境
変数の容量で圧迫される程度では何も問題は起きないと思います。だけど、
子プロセスでいろんなソフトをガシガシ起動する、なんて場合には問題が起
きる可能性があるかもしれません。例えば、使い方によっては子プロセスで
何かを起動するマクロ、なんていうのもありますよね。もちろん、問題の起
きない可能性の方が高いわけですし、原因不明の不具合がおきたときに原因
の候補の一つとしてこの問題が頭の片隅に引っかかってくれば良い、という
程度でいいと思います。
ちなみに、わたしの知っている話では、とある環境変数関係のツールのドキ
ュメントに書いてあったことですが、そのツールの作者の知り合いの人は、
環境変数領域を、なんと６４ＫＢも確保していたとか。当時、まだＤＯＳ３
の時代、ＵＭＢなんていうものもなかったし、ＦＥＰもコンベンショナルメ
モリに鎮座ましましているでしょうし、さぞ空きメモリが少なかった事だろ
うと推測されます。

> 　アドミニストレーターで窓を開いていますが、環境変数のところ
> に追加ってのは出てきません。ＸＰプロフェッショナルです。新規、
> 編集、削除の３項目だけあります。

ん〜、「新規」で追加できませんか？
もう少し試行錯誤してみて下さい。
 

  あら、そうでしたか。ちっとも知りませんでした。無知の涙、
なんちゃって。

　起動直後にかけています。

Cseg map : 2008/06/08_10:14:25
    0 1 2 3 4 5 6 7 8 9 A B C D E F 
0   @@@@@@@@@@@@@@@XXXXXXXXXXXXXXXXi
1   iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii
2   iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii
3   iiiiiioooooooooooooooooooooooooo
4   oooooooooooooooooooooooooooooooo
5   oooooooooooooooooooooooooooooooo
6   oooooooooooooooooooooooooooooooo
7   oooooooooooooooooooooooooooooooo
8   oooooooooooooooooooooooooooooooo
9   oooooooooooooooooooooooooooooooo
A   ooooooooooooooooooooooXXUUUUUUUU
B   SSSSSSSSSSSUUUUUUUUUUUU-------@@
C   @-------------------------------
D   ----------::::::::::::::::::--==
E   ==============================--
F   --------------------------------
    0 1 2 3 4 5 6 7 8 9 A B C D E F 

> 　これはすごい。この記号から、そこまで読み取れるんですか？

　読み取れる部分しか細かく表示していないからです。本当はもっと細分化して
やればさらに詳しく見て取れますが，結局，マクロバッファというのは限られた
区画の中でのやりとりですから，ほぼ想像がつきます。

> この際、あたしの VZ.DEF を見て、ご指南下さいな。

　見たらほぼ予想通りだったので，バッファサイズに関していえば，これ以上
目新しいことは提示できませんね。重複しますが，

> Bm1024*30		;マクロバッファのフリーエリア
　他を弄らなければ，あと3000くらいは増やしても大丈夫そうです。

> Bl1024*4		;行バッファサイズ (256..(Bt*1024/8))
　十分だと思いますが，マクロバッファを増やす代わりにこちらを増やすという
選択もあります。でも，でがらしさんはあまり長い段落を扱っていなさそうなの
で，十分でしょう。

> Bc1024			;削除文字列バッファサイズ
　使い方によりますが，行バッファをあまり取らなくていいということは，削除
バッファも多く取る必要はないかもしれません。なぜなら行バッファの範囲しか
文字列削除をしないからです。カット・ペーストはスタックを使えばよいですし。

> Bu512			;マクロ配列領域サイズ
　うーん，まぁこんなところで。かなり余ってると思いますが，どんなマクロを
でがらしさんが使っているか分からないので。わたしは大規模なモード型マクロ
を使わないので256だったりします。

> Bv256			;ログファイル履歴バッファサイズ	##1.6
　niftyの会議室が過去のものとなった以上，これはキッパリ，ゼロです。

> TC10			;オープン可能なテキスト数
　MSPELL を常用するなら増やしてもいいですね。

> 　関連質問ですが、VZ.DEF にコメントや「;」を頭につけて無効に
> している記述がいくつかありますが、こういう記述を削除するとマ
> クロバッファの空きが増えますか？

　まったく増えません。ただし，見た目に同じようなコマンドのコメントは，
「:」になっていますが，これはバッファに読み込まれるのでシェイプアップ
（削除ではない）すれば空きは増えます。例えば，
70	[ESC]O	@O	:O ファイルのオープン
                     　　↓
70	[ESC]O	@O	:Open Files
…のように，ヘルプメニューに表示されるものなどはコロンの後ろ側の先頭の
１文字は変えずに全体の文字数を減らします。

> 　また「#if 98」という９８０１用の記述がたくさんあります。現
> 在は９８０１を使わないので、これが無意味になっています。これ
> も削除するとマクロバッファの空きが増えるでしょうか？

　まったく増えません。
　一致しないシンボルの範囲は元々読み込まれないからです。

> 　「* A エイリアス」もほとんど使っていない記述が多いですが、
> これも削除するとマクロバッファの空きが増えるのでしょうか？

　増えることは増えますが，いいとこ200〜300バイトですね。
　それなら便利なエイリアスを活用することを考えたほうがよいと思います。

> 必要もないので、そのうちということでご勘弁を。

やだ。勘弁しない。
＃なにを言ってる＞おれ
＃＃いあ、宿直明けでヘロヘロなもので、ごめんなさい

> プログラムに数メガなんていうとぎょっとします。昔の感覚が残
> っているんですよね。ＤＯＳの時代ならせいぜい数十Ｋくらいだ
> と思いますが。窓の時代だとソフトも大きくなっちゃうんでしょ

初めて提唱されてからは、もう１０年以上経つのかな。
「富豪的プログラミング」という考え方があります。
ＣＰＵ速度無限大、メモリ容量無限大、ＨＤＤ容量無限大、回線速度無限大、
を前提にしてもいいじゃないか、みたいな考え方です。
googleで検索すればもっと細かくて正確な解説がいくつも見つかります。
もちろん、これは極論ですし、さらに、ある種の前提があって、その前提を
無視した場合には非難の対象にしかなりません。

要は、難しい制限を考慮しなければいけないからプログラムは難しくなり、
コードは汚くなり、ユーザーインターフェースはわかり難くなり、納期は長
くなる事が多くなるわけです。つまり、そんな制限を取っ払ってしまえば、
プログラムはシンプルになり、バグは混入しにくくなり、短期間でリリース
できるようになってユーザも満足、という、ある種の理想論というか非現実
的な考え方ではあるのですが、実はプログラマの業界では賛同者は割と多い
ような気もします。

多分、昔の７ビット文字コードしか使えない時代の人からすれば、２バイト
シフトＪＩＳコードでテキスト処理をするなんて、えらく贅沢な事でしょう。
あるいは、ぱちぱちとトグルスイッチで２進数を設定してプッシュスイッチ
でメモリに書き込んだ、なんて人にとっては、キーボードからプログラムを
入力してコンピュータ自身にマシン語に変換させる、ということはびっくり
するような事かもしれません。でも、今はそれが普通。

ということで、感覚的にはでがらしさんのおっしゃっている事に大いに賛同
するのですが、少なくとも頭では、今はそういう時代なんだ、と思い込むこ
とにしています。
もちろん、無理してそういう時代についていく必要はさらさらないわけで、
だからこそ私はいまだにメインマシンが生ＤＯＳマシンだったりするのです。
あるいは、最新式のマシンでちょっと古いソフトを使ったりすると、自分で
も驚くほどに日常業務が効率化したりします。例えば、ＤＯＳの末期の頃の
マシンで一太郎Ver.3とかVer.4を使う、なんていうのが該当するかな。

> うか？　節約せんといかん時代なのに。

節約というよりも、レバレッジを効かせる、という考えの方が前向きかも。
マシンが高機能化すればするほど、あるいは、新しいソフトを探し出して使
いはじめる事によっても、梃子は長くなります。
でも、所詮、梃子は梃子。
自らの能力を向上させれば、すなわち入力の量を多くすれば、もしかしたら
最新のマシンを使うよりも多くの出力を絞り出す事ができるかもしれません。




いやあ、やっぱり宿直明けだなぁ。
散漫というか、何を書いているんだか自分でもよくわからん。 
本当に申し訳ない。