2001/06/06
X-Dayは

6月10日。

2001/06/04
緊急

あちらこちらでb2eを見かけるようになってきました。自分のソフトがディープに使われてるのを 見るのはすっごく嬉しいです。有り難うございます!>ALL と、そういうわけで、今日は アクセスログやら検索エンジンやらで、b2eを求めて世界中を探し回ってみてました。(^^; というか、今まで自作のしか入れたことなかったので、いきなり増えまくって大盛況。

しかし、見てみるとかなり気になることが。X-Day用に書き途中だった文書を慌てて アップロードしときます。なんか文面が反感買いそうな気もしますが。 「for all b2e writers」。特に[注意!]のトコ必読。

ホイール

メッセージを受けてスクロールするコードを書いたら、何故か3日に一度くらい 逆向きにスクロールして困ったので諦めた覚えが(^^;。うちのMicrosoftのドライバは 勝手にSCROLL用メッセージに振り替えてくれるから、それでいいやという妥協もあったりします。

2001/06/03

エディタですか。
Windows用でオープンソースとなると Text maid とか テキストエディタ あたりですねぇ。 UranusはたぶんスタートアップコードからしてVC++6依存なのでマズいです。未だに時々改善要望が 来るので、Uranusは作り直さないとなぁ、と思ってはいるんですが。

ちなみにエディタ、個人的には CoolMint に惚れてたりします。

2001/05/26
マクスウェル撃破

近所のゲーム屋ではFFXの予約受付などと宣伝しているご時世なのに古いRPGの話でなんですが、 何の脈絡もなくテイルズoPの話。アーリィの街のBGMはいいです。黄昏れてる感じの雪の町を イメージした曲はだいたい私にヒットするよう。ロマサガ3のポドールイとか。

b2e色々

・16bitのexeに対してはパラメータの個数が制限されてるのかも。調べる必要有り。

・jp/us切り替え機能も可能ならつけたいところ。トトトトトは格好悪すぎ。

・自動でDOS窓が閉じないexeでも閉じるように。今でもb2eの書き方次第では
> (xcmd command.com /c ace a -c2 -m1 (arc.ace) (list\*))
みたいに [xcmd command.com /c exe名] を介せば出来ちゃったりしますが、 こんなトリッキーな書き方はして欲しくないですし。

顔文字

単に文字だけで書くより (^^; をつけた方が100倍良く自分の心境を表せると思うから、 私は顔文字を多用してます。別に美しい日本語を書くことが目的なのではなく、 言いたいことを伝えるのが目的なんだから。(笑) などを使う理由も全く同じ。

…文章力が無いせいで顔文字に頼らざるを得なくなってるだけ、とも言う。

2001/05/24

>ycさん
私自身が自分で宣伝してる起動時間測定なんぞはあまり信用しないほうが…(^^;;。
aceは、Ace.exe よりは Ace32.exe を使うとよろしいかと。 確かに16bit版の方は8個以上ダメですね。なんでだろ。

2001/05/23
Visorがやって来た

やーやーやー。

でも忙しくて触ってる暇が…。

2001/05/21
Noah3(仮)の起動速度@解凍優先

b2eの数にどう影響されるか、という話です。

まず、起動時に b2e フォルダ内の拡張子 *.b2e なファイルを全てリストアップします。 この時点では b2e の中身は読み込まないでファイル名だけを記憶するので、2.xx の NSX と 比較すると圧倒的に高速ではありますが、そうは言っても b2e ファイルの数に関して 直線的に所要時間が増えるのは確かです。( ただし数百個レベルなら平均して0.1秒も かかりません。Celeron400MHz,WinMeにて。 )

次に書庫かどうかのチェック作業が入ります。まず拡張子から当たりをつけます。 この作業も最悪ではb2eのファイル数に比例しますが、ファイル名リストアップに輪をかけて 微々たるものです。で、この拡張子検索でヒットしたものがファイル内容による検査に対応してる DLLで、その検査に成功したなら、解凍へ移行します。

↑まず一つ目の結論として、このパターンになる lzh,zip,rar,cab 等々の解凍に関しては b2e数の影響はほぼ0と言っていいと思います。というか、このパターンを 高速化するためだけに作ったのがNoah3(仮)です。

拡張子探索でHitしたものがexeを利用する形式だった場合 or Hitしなかった場合、結果としては一旦全b2eファイルの ロードが行われることになります。b2e数に比例して解凍が始まるのが遅くなるとしたなら、 原因はここ以外在りません。上記の環境での計測では、30個で0.1秒とかそんな ペースで時間がかかります。つーか30個も入れるなよと言いたいのは 山々ですが、まぁそんなもんです。これを重大な遅延と感じるかどうかの判断はお任せします。

↑上に書いたような作業を行ったあげく解凍できなさそうだったら、初めて圧縮に移ります。 ( とっとと圧縮しやがれと感じた人には圧縮優先モードをお勧めします。) まず、設定で指定された圧縮形式とb2e等に書いてある圧縮形式名の照合を順に行っていきます。 内蔵ルーチンから始めて読み込んだ順にb2eと照合していきますので、一番最後に読み込まれたb2e だったりするとまたそれなりに時間がかかります。Loadよりはかなり速いですが、 それでも環境によってはそろそろ蓄積で実感できる程度になってくるかもしれません。

↑この照合作業は、圧縮優先モードに限ってかなりの改善の余地があります。 そのうちその手段を投入する予定。

設定画面の起動に関しては、[有効b2e数の二乗に比例]という致命的な項があります。 これは、明らかに遅い。100個辺りで秒単位に達する気がします。 我慢してください。(^^;;

結局何が言いたいかといいますと、

・確かに b2e が増えればそれ相応に遅くなります。
・けど、(特に解凍作業に関しては)30個40個ではたいした遅延ではないです。
・よっぽどLoadLibrary一回の方が遅かったりします。
・ではありますが、厳選して必要なb2eだけ入れた方が望ましいことに変わりはありません。

presented by k.inaba (kiki .a.t. kmonos.net) under CC0