Plain

あ〜、やっぱりC++、と言うよりクラスは良いですねぇ。コードの見易さや安定性等がグンと上がります。ただ、少し気になるのがGDIオブジェクトです。何故か、Cで書かれたDelayerと較べてGDIオブジェクトが多いんですね。何故でしょう？物理メモリの消費量が多いのは、クラスを使う以上ある程度当然ですが、何故GDIオブジェクト？動作に何の問題もないため放置しますが、気になりますねぇ…。

そう言えば、ランチャーも自作したいですねぇ。上の画像をご覧頂ければご理解頂けるかと思うのですが、"fenrir"さんは仮想メモリの使用量が中々です。しかも、どうも定期的に物理メモリを無理矢理解放しているのではないかと推測される謎な挙動をする等、シンプル軽量志向な作者にはやはり高機能過ぎます。…いや、正直に言いましょう。適当な作者の場合、このソフトを使用していると割りと誤爆するんですね。開発環境を構成するソフトのアンインストーラが何故か動き始めた時には、流石に作者も少し困ってしまいました。もっとフールプルーフというか、愚かな人間でも安全に使えるようなソフトが欲しいのですよ作者は。愚かなくせに我侭ですいません。

お久しぶりです。とりあえず、まだ生きてます。

適当にDelayerのウィンドウが表示されない原因を調査していましたが、残念ながら作者の能力では把握しきれませんでした。全く、どうなっているんでしょうかね？プレイリスト周りで駄目らしいのですが、お盆期間中にもう一度試す機会のあったWindowsMEでは元気に動いてしまいました。それで。結局のところ、書き直しでもしてみようかなという結論に至りました。C++を軽く勉強したので、恐らく安定性の点で大きな向上が望めるはずです。多分。(作者には)時間は幾らでもありますので、のんびり開発していきます。

あと、つい先日OSを入れなおす際に気付いたのですが、EclipseとCDTが共にバージョンアップしていますね。特にCDT。4.0になって多少は良くなった気がします。コードの補完が相変わらずVisualStudioと雲泥の差ですが、しかし、その駄々っ子ぶりが憎めません。

お盆の三日間を休むために、お盆までの期間は週七日体制です。あれ？今ふと気付いたのですが、何だか休みを一日分損してるような、ないような…。うーむ…まぁ、もう決まったことですし、どうでも良いか。とりあえず、8月の中旬までHikageは消滅します。恐れ入りますが、どうぞよろしくお願い致します。

今後の開発を見据えて、ちょっとC++を勉強中です。といっても、Delayerで使っているCのように、ファイルサイズ縮小のために標準のライブラリを用いないでのC++です。…標準ライブラリを用いない場合、"new"が内部でmallocしているらしく駄目になる、と伺っていたのですが、どうやらオペレータ何とかをオーバーライドすれば解決出来るらしいではないですか。と言うわけで、"new"と"delete"をそれぞれ改悪した基底クラス、そしてDelphiでいう"TList"、STLでいう"vector"に当るものを造ってみました。いやぁ、時間掛かりました。しかし、やはり良いですねクラスは。コードが綺麗ですし、何より管理し易いです。Delayerもいずれはこの怪しいC++で書き直そうかなという気も多少したりしなかったり。

そう言えば、このExciteさんの記事ってごく普通にGoogleさんで引っ掛りますね。自身の記事が検索において物凄く邪魔でした。今まで知らずに多くの方々にご迷惑お掛けしていたかと思うと、申し訳ないです。早い内にここは閉鎖し、Xreaさんのところに移すべきです。ただ、XreaさんはASPは駄目みたいなので、今までのログの管理が問題ですが…う〜ん、まぁ、良いか。とりあえず近い内にここは閉鎖することは決定、ということで。とりあえず、こんな感じでぼちぼちと移行させていきます。

Tokkyさん、ご協力ありがとうございます。そうですか、より深刻ですか、そうですか…。困ったな、何故だろう？う〜ん…これはもう原因追求よりも、ウィンドウ表示関連を再構築し直す方が早そうな気がしてきました。来月のお盆辺りにまとまった休みが取れそうなので、とりあえずはその方向性でいこうかと思います。ご迷惑をお掛けしてしまい申し訳御座いません。

Dimではウィンドウが表示出来た、とのことですが、そもそもDelayerは外見以外はDimとは根本から違う設計で構築されています。早い話が、Dimは起動時にこっそりウィンドウを生成し、当該ウィンドウ内でプレイリストを管理するという構造でしたが、一方、Delayerは「ウィンドウを表示」が実行されるまではウィンドウが生成すらされないという、より省リソースな設計がなされています。また、実はプレイリスト自体も「再生」や「プレイリスト表示」等の要求があるまで読み込まない等、とにかく思いつく遅延工夫が満載です。…と言うわけで、Dimよりリソースに大幅に優しく、しかし安定性を大きく欠く(ANSI版限定みたいですが…)。それが現在のDelayerです。いやぁ、個人的にはそうした無駄でアホっぽい工夫が大好きなんですが、まさかブルースクリーンという形でしっぺ返しを喰うとは思ってもいませんでした。以後、特にANSI版に対してはもっと注意しながら造ることにします。本当に失礼致しました。

muinさん、重ね重ねありがとうございます。しかし…そのログで何故、次の処理へ進まないのか、ちょっと理解出来ません。"end of playlist initialize"の言葉通り、PlayListのInitializeが正常に終了しているではないですか。そのくせ、次の処理へ進む旨のログが出力されていない…。やはり環境に依存したものでしょうか？いや、もしかしてDelayer(ANSI版)が正常に動作した作者のWindowsMEの方こそ特殊な環境なのでしょうか？何だかもう良くわからなくなってきました。とりあえず、来週もう一度対処してみます。ご迷惑をお掛けしてしまい、申し訳御座いません。

あ、そう言えばバージョン情報に「Log Mode」という文字列を付けたままv0.2.2.0をリリースしてしまいましたが、別にログは出力されませんのでご安心下さい。

Tokkyさんとmuinさんありがとうございます。おふたりのおかげで、どうやらウィンドウ生成時に本体が保持しているプレイリストを、ウィンドウ側でも参照出来るよう同期を取る関数内において、何らかの例外が発生しているらしいことが解りました。しかし、流れを追うことが目的のDLLであったため、具体的にどのコードがNGなのかまでは解りませんでした。そのため、申し訳御座いませんが、当該関数内処理を一行ずつ出力するログ出力DLLを造りましたので、どうか今一度ご協力をお願いいたします。

ログ出力用DLL v2.0.0(ANSI版専用)

「fenrir」というランチャーを使ってみましたが、これぁ凄いですね。ちょっと作者には高機能過ぎる気も微妙にしますが、それ以外は別段問題もないため、当面はこれでいかせて頂こうかと思っています。貴重な情報ありがとうございました。

そう言えば。プレイリストの表示仕様ですが、これは"Client"セクションの"TrackStyle"という値を0か1にすることで変更出来ます。ちなみに、従来の仕様が1、新規追加した仕様が0です。動作がイメージと違うという場合には、その旨お知らせ下さい。

上、それでもなおウィンドウを出せないのは最早、環境に依存する何らかの問題としか考えられません。とりあえず、「ウィンドウ表示」関連のログ出力仕様なDLLを拵えてみましたので、もし宜しければ出力されたログの内容をお知らせ下されば幸いです。…もっとも、プログラム初心者な作者ですので、ログを見たところで何も解らない可能性が大変大きいですが…。

Delayerの展望としましては、とりあえずExplorerみたいにListViewのカラム項目をカスタマイズしたいと思っています。ID3タグの各種項目や、ビットレートを表示・非表示することが出来れば実に面白そうで、ワクワクします。…ワクワクしますが、しかし、実現は中々難しい。恐らく、物凄い力技を駆使すれば実現出来ると思うのですが、それはやりたくないのです。とは言え、ここ二週間程暇をみてはスマートそうな方法を模索していますが、全く巧くいきません。

Delayerとひとまず置いておくとして、作者は今猛烈にランチャーが欲しいです。今まではBlueWindというランチャーを使わせて頂いていたのですが、環境を少し変えたところ、何故かAccessViolationが多発です。…いやぁ、懐かしいですねAccessViolation。何も言わずに落ちるC言語とは違い、何の例外かを断末魔の叫びとしてあげながら落ちていく辺りにDelphiのスマートさを感じます。…いや、Delphiの良さを再確認するのはどうでもいい。とりあえずランチャーです。BlueWindから機能の大部分をげっそり落として、オートコンプリート、適当なアイコン描写、擬似XMLでの項目管理、グローバルホットキー、そして気が向いたらDelphiのVCLを使ってXML管理ツール。こんなものですか。う〜ん…低機能で素晴らしい。この線でいきましょう。いやぁ、何だか楽しくなってきます。

とりあえず目に付いた部分の修正と、簡単な設定の追加をしてみました。後はID3v2タグ関連なんですが…これは大変面倒なため、とりあえず放置します。今度まとまった時間を取れた時にでも修正に取り掛かることにします。

プレイリストポップアップの「名前順に表示」という御要望がありましたが、具体的な動作イメージが湧かない、と言うよりは意味が良く分からなかったため見送りとさせて頂きました。御容赦下さい。

色々と予定に変更があったため、WindowsME上でのANSI版の動作検証を前倒しで行うことが出来ました。して、その結果はと言いますと、早い話がほぼ問題なし、というものでした。起動、再生、ウィンドウ表示、コマンドライン。いずれの処理も想定通りに動いてくれました。発見した不具合も、UNICODE版と共通して発生するものでしたので、今回の検証をもって正式にDelayerはWindows9x系でも動くことを保証致します。

先程前回の投稿をふと見たところ、何やらTrackBackなるものがあるではないですか。このTrackBackという機能の存在価値が今一理解出来ていませんが、とりあえず今までの経験上、「神はこう仰った」的な意味不明なものだと思っていました。しかし、リンクを辿ってみたところ、何やらTokkyさん？という方の情報発信サイトに繋がりました。しかも、よりによってDelayerのANSI版をお使いだとか。しかもしかも、ウィンドウが全然出ないとか。いやぁ…申し訳御座いません。パス操作関数の不具合潰して大丈夫とか思ってましたが、全然駄目みたいじゃないですか。とりあえず、来週の海の日には緊急事態が発生しない限り時間がありそうなので、WindowsME上でのANSI版の検証をしてみる予定です。ANSI版をお試し下さっている方、重ね重ね申し訳御座いませんでした。

v0.1.9.0のリリース前検査としておもむろにANSI版を起動したところ、いやぁ、驚きました。何故か起動すらしてくれなかったのです。慌ててUNICODE版で起動したところ、ウィンドウ表示が悪さしていた模様。そして原因を探ったところ、"ウィンドウ側"のファイル名の拡張子を取得する関数が極めて怪しい動作をしていたことに気が付きました。"本体側"の拡張子取得関数は正常に動くため、今まで全く気が付きませんでした。とりあえず"本体側"の関数群を丸々コピーすることによって正常にウィンドウを表示させることに成功しましたが、今度の週末に何とか時間を取って関数郡の見直しをする必要があるかもしれませんねコレは。…まぁそれは置いておくとして。ANSI版を試そうとして下さった方、本当に申し訳御座いませんでした。ウィンドウすら表示出来ないくせに対応OSにWin9x系入れてしまっていました。深くお詫び申し上げます。

あと、申し訳ないついでなのですが、BASSのAdd-Onについてはほとんど検証をしていません。手元にあったWMAファイルでの動作は検証しましたが、他の形式は入手や検証の時間がありませんでした。ほとんど問題はないはずですが、一応、時間を見つけ次第追って検証致します。

大変勝手ながら、7月は忙しいため開発速度を落とさせて頂きます。もしかしたら一人や二人くらいはいらっしゃるかも知れない、作者に期待して下さっている方、大変申し訳御座いませんがどうか御了承下さい。

結局、CommCtrlのバージョンに依存した関数も回避出来ていますので、Windows9x上でもAnsi版は動くのではないかと言う様な気がしてきます。実際のところはどうなんでしょうね？試してみたいところなのですが…何故か作者のカレンダーの土日の欄は7月の下旬まで変な書き込みがされています。しかも、土日に忙しいくせに、何故か平日が暇になるということが無いという信じがたい事態です。どうなってんですかね全く。…とりあえず、動作検証が出来そうなのは7月の4週辺りでしょうか。Ansi版はUnicode版よりも御使用なさっていらっしゃる方が遥かに少ないため、不具合報告を頂ける可能性も無さそうですし…。う〜む、困ったものだ。

それにしても、作者がヒッソリ出現してからもう二年以上経つんですねぇ。この二年で技術は向上しましたが、代わりに暇な時間(に加え、暇として捻出することが出来る時間)を失ってしまいました。世の中、そうそう巧くはいきませんね。ただ、忙しいからと言って趣味の時間を削るタイプではないので、これからも無理矢理時間を作って細々と開発していきたいと思っています。また、折角二年間を振り返ってということなので、作者の拙いブツを使ってくださる奇特な方にも、この場を借りてお礼申し上げたいと思います。どうもありがとうございます。

あれ？今良く良く見たところ、別に問題ない気がしてきました。朝の出かける時でしたので慌ててたのかな。う〜む、不具合があるのか無いのか良くわかりません。しかし、折角の期待ですので、とりあえず普段はほぼ放置に近いAnsi版のデバックにでも当ててみることにします。

あ。今気付きました。Ansi版のウィンドウで、WindowsNT系で登場した機能を使ってしまってました。恐らく、Windows9x系の人はウィンドウの表示すら出来ないのではないかと予想されます。いやぁ、申し訳ないです。以後気を付けます。…とは言え、作者のWindows98無印はお亡くなりになられてしまいましたし、WindowsMEは実家に放置してあるしでテスト環境がないですねぇ…。う〜ん、良い機会ですし、無料になったというVMWareとやらを入れてみるのも一興かもしれませんね。

ウィンドウのタグ関連を取得させたら、途端にマトモっぽい雰囲気が出てきた気がします。う〜ん、とりあえずタグ取得に関しては最低限の線はいってるみたいです。実験用に用意したAnsiでのタグやUTF-16でのタグを適切に表示出来ています。しかし、"長さ"については信頼性の上で問題があります。それと言いますのも、取得処理において良く分からない点があるからです。ファイルサイズ縮小のために、ランタイムっぽいライブラリを省いているのですが、そのランタイムが無いと浮動小数点演算、平たく言えば小数点の計算が出来ません。しかし、Webを彷徨っていたところ、ランタイム無しでも浮動小数点演算を可能にするコンパイラオプションとコードを発見したので組み込んでみました。コンパイラオプションはともかく、コードについては意味を理解出来ていません。しかし、適当に動いている。となれば取るべき道は唯一つ、放置です。問題が起きたら、その都度対応しましょう。

あとはグローバルホットキーとタスクトレイのカスタマイズ、おまけでコマンドラインといった辺りでしょうか。う〜む。ホットキーとタスクトレイは面倒ですねぇ。こういう時は出来ればDelphiでいきたいのですが、いきなりファイルサイズ500KB以上のDLLを拵えるというのもアレですしねぇ…。全く、困ったものだ。

うわぁぁぁぁぁぁぁぁ！Eclipseさん何てことしてくれるんですかコノIDEは！プロジェクト削除の際に、ご丁寧にも周囲のファイルやディレクトリを根こそぎ削除してくれたりする親切設計だったのですね。おかげ様でv0.1.4.0のソースが完全消失。即座に復元ソフトに掛けましたが、共通関数を記述したファイルが何故かEclipseの環境設定系のファイルになっていたりと、大変不完全な形での救出となってしまいました。いやぁ、そーすを公開してて本当に良かったです。とりあえずv0.1.3.0のそーすと、救出に成功した変更履歴を参照することによって再構築も出来ます。

それにしてもEclipse…。今までもこちらの意図と挙動が異なるという事がありましたが、まさかこんな落とし穴があるとは…。まぁ、使い方が悪いことに起因する逆ギレだということは作者自身が一番良く理解していますが、それでもやはり恨まずにはいられません。

SetProcessWorkingSetSize。功罪入り乱れたAPIであるため封印していましたが、やはり面白そうなので使うことにしました。このAPIの効果は、使用中のメモリの退避のようなものです。ウィンドウを最小化するとメモリ使用量が激減しますが、あれと似たような効果をもたらします。実際、Delayerの起動時平均物理メモリ使用量は2.7MBですが、起動中にこのAPIを呼ぶと約0.5MB程度になります。効果絶大ですね。

しかし、一見省メモリで良いように見えますが、そこには落とし穴もあります。それは、全般的な初動時動作が若干鈍くなることです。一旦HDDに退避させた情報を再びメモリへ書き出すため、どうしても"軽快"さを損なってしまうのです。…しかし、メモリ使用量が激減するという効果そのものは大変面白い。そのため、設定として紛れ込ませることにしました。ちなみに、現状では"delayer.ini"の"Client"セクションに"Swap"というキーを作り、値を"1"にすれば当該設定が有効になります。

そうそう、ID3v2のUTF-8等については土日に取り掛かります。また、ウィンドウのタグ取得に関しては来週の土日以降ですか。う〜む。時間が足りません。

Xreaさんのサイトを少し改善しました。やっぱり白黒かつシンプルなデザインが一番です。あと、サイト再構築に乗じ、不具合の存在に気付いていながらも放置していた色々なモノを片付けました。おかげで、憑き物が落ちたようにスッキリした気分です。

つい先程まで知らなかったのですが、MP3のID3v2にはv2.4.0などという規格があったのですね。AnsiとUNICODE(UTF-16)でのタグ取得に成功し、これで終わりかと思ったのも束の間。v2.4.0で追加されたというUTF-8などというモノがあるじゃないですか。時間ばかり掛かるくせに、あまり見返りがありませんねタグというモノは…。

…とりあえず、タグのUTF-8とウィンドウ上でのDrag&Dropの処理を捌けば、ひとまずDelayerの完成です。BASSのAdd-On対応については気が向いた時にすることにします。

適当にDimだったディレクトリをDelayerにしたのですが、何だか画像が表示されていませんね。何故だろう？う〜む…まぁ良いか。その内サイトも造り直す予定ですし、それまで放置します。

何だかソートが巧くいきませんでした。何故だろう？と数日間悩み続けたのですが、やっと判明した原因は処理高速化のための情報遅延読み込みに基づく比較対象不存在でした。意味分からんという方に例えるならば、対戦相手が突然家に帰りだしたため不戦敗、というぐらいアホっぽい顛末です。やっと謎の不具合の修正が済んだところでID3v2タグの取得に取り掛かれます。

そう言えばVacantを随分長い間放置中です。DelayerのDLLをC言語で書き直したりといった事をしていたため、すっかり時間を喰ってしまっています。時間が欲しいですねぇ。作者の好きなノベル系ゲームもダウンロードすらしたものの、ずっと書庫の状態で放置中です。ちょっと異動するだけで、まさかこんなに忙しくなるとは…。全く、困ったものだ。

うああああ、ネットがやっと繋がりました。思えば自由にネットに繋げられるのは、山奥に篭らされた時以来ですから二ヶ月ぶりです。いやぁ、長かった。連絡無いなと思いながら部屋に戻ったところ、いきなり「工事完了しました」的な書類が机の上に載っていたという「それってどうなの？」的な業者さんのやり方も気にならないくらい嬉しいです。それに、これでmp3のID3v2タグの情報もやっと収集出来ます。開発時間は異動に伴い減少しましたが、とりあえず本格的に活動再開です。

前回の更新から15日…。結構経ちましたねぇ。雪国から生還し、やっと落ち着いて開発出来ると思っていたのですが、気が付いたら配属が変わっていました。意味不明ですが、決まっているらしい以上は仕方がない。そのため、GW以降はずっと引越し関連に費やしてしまいました。そのくせ、まだネットも繋がっていないんですよねぇ。光の申し込みが最短で15日、長くて一ヵ月半も掛かるとは思ってもいませんでした。そのため、Web上での活動は光が無事開通するまでは基本的にはありません。ああ、勿論ローカルでの開発は継続しています。Dim…ではなくてDelayerとかはウィンドウ操作における省エネや安定性向上などを施しています。それだが僅少とはいえHikageという存在の価値ですから当然ですね。

やぁ〜と帰還出来ました。やはりダークサイドな作者には、澄んだ空気や綺麗な水よりも排ガス臭い空気や味の付いた水の方が性に合います。

まぁそんな感傷はさておき。今後の開発日程というか予定ですが、とりあえずDimをそれなりに満足出来る段階まで仕上げ、Vacantの開発はその後ということにします。Dimの完成予定は…う〜ん、二ヶ月以内…といったあたりですか。今後は開発時間が従来よりも短くなりそうな気配なため、ちょっと長めに見積もっておきます。

ああそうだ、忘れるところでした。Dimの名称をDelayerに変更します。既にVectorさんにDimというソフトが登録されていたため、そちら様に迷惑が掛かるといけないからです。

もうそろそろ復活出来そうです。いやぁ、長かった…。見渡す限り樹木しかない山の奥地。道で人とすれ違うことが遂に一度もなかったような僻地で、やたら厳重な物理的セキュリティ…。如何考えても無駄ですが、作者はそうしたアホっぽい無駄は嫌いじゃないです。

さて。物凄く久しぶりに自由にネットにアクセス出来るということで、とりあえずC言語で何か書こうと思ったわけですが…Visual C++ Toolkit 2003が落とせなくなってるじゃないですか。何ということだ…。Visual C++ 2005 Express Editionでビルドするのはバイナリに変なゴミ？らしきブツが付くので嫌なんですよねぇ。仕方ないので探し回り、何とかまだ生きてるリンクを発見、保存することが出来ました。作者のようにVisual C++ Toolkit 2003を気に入っていらっしゃる方は、お早めに保存されることをおすすめします。

ああ、そう言えばVectorさんに新規登録願い出したDim、やはり登録されてませんね。うーむ、仕方ない、山から帰還したらVectorさんに質問状なり何なりを送ってみますか。…思えば一年以上この問題を延々と放置していていましたが、それもここまでです。