Plain

暫くの間サヨウナラです。

全霊を掛けた遅延工作虚しく、来週の月曜に出立が決まりました。作者は先に現地入りということらしいので、とりあえず開発機を持参し、何か始まりだしたらバレナイ内にコッソリ送り返すことにしますが、それでもやはり30日前後までですか。

さて。音楽ファイルを保存する形式としてはM3U形式が一般的だと思いますが、このM3U形式、実は二種類くらいあるんですね。一つはプレーンな形式。ファイルのパスが列挙されているだけというシンプルなブツです。そしてもう一つはEXTM3U形式。どうもWinAmpが利用している形式らしく、ファイルのパスの他に音楽ファイルの情報が追記されます。Dimでもタグを扱う関係上、プレイリストの保存はEXTM3U形式が望ましいだろうと思ったのですが…EXTM3U形式のちゃんとした仕様が良くわからない…。タイトルとあーてすとを区切る「-」という文字列の扱いを如何するのかが問題となるので、とりあえず他のプレイヤーさんのEXTM3Uは如何してるのかなと見てみたところ…う〜む、華麗にスルーしている。つまり、EXTM3Uはエスケープに対応していない、と見てそう遠くはないのでしょう、多分。また、ソフトによって「-」の前後にスペースが入っていたり入なかったりする辺り、仕様がかなりいい加減なのでしょう。それじゃ困りますので、とりあえずXMLを採用してみました。少し遅くなりますが、XMLなら拡張も楽ですし、何より文字列のエスケープもちゃんと出来る。…気のせいか独自路線を突っ走りだした気が少しだけしますが、まぁ…しょうがないですね、多分。

日本優勝。感無量です。初代の優勝国というのは歴史に残る大変な名誉。二代目や三代目とは価値が全然違う。いや優勝して良かった。

野球はとりあえず置いておくとして、Dimですか。とりあえず最低限のレベルのブツが出来ました。「超軽量」、「タスクトレイ左クリックでプレイリストを表示」、「GUIでプレイリスト編集」という作者の要求をギリギリ満たしているレベルです。色々と工夫しましたよ…。起動を少しでも早くするためにBASS(マルチメディア再生用ライブラリのことです)の初期化は初めてメディアが再生される時にするとか、ウィンドウは基本的には表示せず、表示するにしてもDLL内に隔離しておき、必要な時になって初めて読み込むなどなど。また、本体のファイルサイズにも気を配り続けています。100KB超えるようなことになろうものなら開発終了です。ちなみに、UPXはメモリ使用量が微増するため使う予定は今のところありません。ああ、あとランダム再生にも気を使いました。リストへの追加や削除といった操作が無い限り、一週するまで同じ曲に遭遇することはありません。また、たとえランダム再生中であれど、「前の曲」を選択した場合には履歴を辿ってみる努力を少しだけさせてみました。同じ曲が連続する様なランダム再生は詐欺以外の何物でもないですしね。

さて。そうして出来た叩き台版をとりあえずベクターさんにも登録しましたが…無念ですねぇ。本当は32bitでの出力といったBASSの機能を引き出す設定や、ウィンドウ上でのホットキーのカスタマイズ、さらにはウィンドウを最小化する時にはタスクトレイに格納、といった様な機能を付加したいのですが…時間が無い。今日一日引き篭もって野球観ながらひたすら頑張りましたが、この程度しか出来ませんでした。あああああ、全く。雪国行きたくないですねぇ。せめてマシン持ち込ませて欲しいですねぇ。困ったものだ困ったものだ困ったものだ。しかたないので、とりあえずXreaさんのとこにIniFileの設定項目について触れておきます。復活するまではそれで御容赦下さい。と言っても使って下さる奇特な方がいれば、の話ですが。

ああ、忘れてた。Dimのプレイリストは基本的にはUTF-8で読み書きされているため、もしかしたら他のソフトさんのプレイリストを流用しようとした場合には壮大な文字化けに遭遇なさる危険性があります。故に、プレイリスト編集はdim.dllのウィンドウをご利用なさることをお奨めします。…何故UTF-8なんていう文字セットを採用したかって？色々理由はありましたが、とりあえず一番大きな理由、それは気が向いたからです。何となくUTF-8って気分でしたもので。

日本勝ちましたね。いや良かった。三連敗なぞしようものなら一生球場なんぞに足運ぶものかとさえ思ってました。

さて。作者の蒸発が近付いてきました。今からVacantの画像処理を造り始める場合、復活予定時期の5月中旬になると完全に内容を忘却、理解出来なくなっていると予想されるため、とりあえず今の段階で放置することにします。生きて帰って来られた場合には開発再開です。

そう言う訳で。Vacant製作は一休みです。代わりに、限りなく少ない時間ではありますがDimに着手します。Dimとはバックグランドで再生すること"だけ"を目的とした軽量なmp3Playerです。軽量なmp3PlayerとしてはGSPlayer2、Evil_Player、Fittle、billyや1by1といった辺りが有名ですか。この内、Dimと同じBASSというライブラリを使用しているEvil_Player、Fittle、Billyと較べた場合、Dimの方が断然軽い。インチキが入っている物理メモリ使用量は放置するとして、肝心の仮想メモリ使用量が何と1MB以上違います(当社比)。まさに軽量。ただ、問題は操作性がちくと終わってることです。何せ、ウィンドウがない。Drag&Dropでファイルを登録出来ないのはストレスが溜まります。と言う訳で、Dimの最適化＋軽量化＋リストビューだけがあるウィンドウを造っている最中です。う〜ん。蒸発するまでに完成するかな…？

あう
野球日本代表また負けてしまた
もうだめ

カレンダーに私的な休日を設定出来るよう色々と細工してみたのですが、恐ろしく疲れました。「yyyy年m月d日」という方法だけでなく「yyyy年m月の第二月曜日」という方法でも指定出来るようにし、かつ全ての年で有効な「m月d日」や「m月の第三火曜日」のような方法でも指定出来るようにしてみました。…設定画面を見ても間違いなく設定方法が分からないと予想されるため、設定方法のドキュメントが必要なわけですが、あまりに疲れたためとりあえず放置します。

…あれ？久しぶりにWin9x用のバイナリを実行したら物凄く文字化けしてるような。はぁ。どうもv0.1.2.0辺りから既に化けてるようですね…。全く、困ったものだ。

とりあえず調査したところ、文字化けはフォントの文字コードの設定が適当過ぎたことが原因でした。サクッと適当な文字コードを指定して文字化けは一件落着。v0.1.6.0からは無問題のはずです。そして次なる問題は…設定画面を出そうとするとエラーが出る点ですか。ちょっとコレは意味不明ですねぇ…。Manifestファイルがバイナリに含まれていない状態で設定用DLLを呼び出す場合に限り、TImageListが内部リソースの読み込みに失敗しているようですが…。う〜む。何がいけないのか全くわかりません。お手上げに近いですね、コレは。かくなる上はWin9xでもManifestを含んだままでビルドするか、あるいはWin9x用バイナリでは設定は手作業でお願いします、と開き直るかの二択になりそうですね。前者を採用するとほぼ完全にWin9x用バイナリにおける設定画面のデバックを放棄することになり、後者を採用するとWin9xで使って下さる方が万に一人すらいなくなる可能性が高い。う〜む…こんなことなら、もう少ししっかりとWin9x用バイナリもチェックしておくんでしたか。少し後悔の今日この頃です。

フォントで10.5ptってありますよね？MSWord等でデフォルトのサイズとして指定されるなど、それなりに認知度のあるフォントの"サイズ"だと思います。しかし。それなりに認知度がある"サイズ"であるにもかかわらず。何故かWindowsが提供するフォント選択ダイアログでは、この10.5ptを選択出来ないのです。う〜む。「小数点の処理が凄く面倒だ…」→「そうだ、小数点の処理なんてうっちゃれば良いんだ！」といった辺りでしょうか。この考え方と言いますか気持ちは凄く分かりますが、同調していても10.5ptは選択出来ない。しかたないので、適当に10.5ptを選択出来るようなダイアログを拵えました。これで作者が気に入っているTahomaで"高さ"が-14、すなわち"サイズ"で10.5ptのフォントを選択することが出来るはずです。自分の好みを貫くというのもつくづく大変なものです。

設定は全部DLLに隔離しているのですが、流石はDelphiのVCLと言ったところでしょうか。構築は手早く、簡単に出来るのですが、とにかくファイルサイズが肥大化してしまいます。今の段階で、既にVCLを使っていない本体の約四倍。う〜む。かなり面倒ですが、差分パッチで配布という方法も考慮した方が良いのかもしれませんね。

本体の再構築にやっと目処が立ちました。コンセプトは相変わらず「本体は何もしないソフト」であり、SimDiary互換的な日付管理処理を直系プラグインに丸投げし、SimDiary互換的機能を孫プラグインとして保持する、そんな仕様にすることにしました。この仕様、Xreaさんに今放置してあるChevronとは違い、孫プラグインを導入した点が味噌です。これにより、日付管理プラグインとの親和性が段違いに増すはずです。

花粉の時期ですねぇ…。作者は花粉を喰らっても涙や鼻水、眼の痒みといった定番どころの症状は基本的にはないのですが、代わりに何故か恐ろしいほど眼が充血してくれます。これ、かなり困るんですよねぇ…。平然とした態度でウサギの如く目を血走らせているため、どっから見ても怪しい人そのもの。いっそのこと、鼻水や涙が出てくれたほうが自然な花粉症で助かるのですが…。ビシッと一発効く充血解消目薬の開発はまだですかね。

まぁそんな下らないことは置いとくとして。カレンダーとエディタが中途半端なままですが、とりあえずそれらを放置して設定ダイアログを造り始めることにします。Chevronの設定ダイアログから流用出来るところは流用するため、想定外の事象により遅延が生じたとしても二週間以内で出来ると期待されます。そして、設定ダイアログが本体の構築進捗に追いつき次第、画像関連に取り掛かることにします。それで一段落…ですね。そうそう、忘れてましたがGrepですが…どうしたものかな。"検索"みたいなタブを設けて、そこで処理させるのも一案なのですが…Grepは様々な意味で本体への負荷が大きいため、別アプリにするのも有力な案だったりします。ただ、その場合、本体との連携が大変難しくなる、或いは本体との連携を断ち切るということになってしまったり、そうはならなかったり…。う〜む。まぁ、とりあえず放置ということで。

最近、作者は少々ハイカラに被れてます。カレンダーの曜日とかが"S"とか"M"とかの気取った一文字だけなのもその一環です。そして、日付もデフォルトでは"1日(月)"とかではなく、もっとハイカラな表記に…と思ったのですが、そもそもハイカラな日付表記ってどんな按配なんでしょう？ロクに外国へ行った事もないため、想像すら出来ない…。う〜む…とりあえず"1 (月)"のように"日"の部分を抜かすことにより、そこに垢抜けっぽい雰囲気を醸して良しとしましょう。

ハイカラは良いとして、少しだけ構成のお話を。ChangeLogメモの基本仕様である"タイトル＋カテゴリ＋本文"を反映するため、タイトル一覧に「カテゴリ」という属性を適当に新設しました。要はGMailのラベルみたいにGrep等で引っ掛けるためのモノだと推定されます。そう言えば、良く見たらこのExciteブログさんにも"カテゴリ"なんていうコンボボックスがありますが、きっと同じようなモノなんでしょう。…ちょっと設定してみますか。とりあえず今回の投稿を"開発日誌"とカテゴライズ。良くわかりませんが、とりあえずこの状態で今後は投稿することにして様子見ですね。

そうそう。外国の日付表記を探る上で、このExciteさん以前にお世話になっていたGoogleさん提供のBlogger上に存在していた作者の旧雑記のURL、一体全体ドンナノでしたかね…？かれこれ約10ヶ月ぐらい前のこと故に完全に忘れてしまいました。一定期間管理が放置されている場合は自動で削除されます的なシステムだと良いのですが、そうでない場合にはGoogleさんのサーバーにデブリが放置されることになってしまうため、大変宜しくないような、そうでもないような…。

起動速度をもっと速くしてみようと先週辺りから取り組んでいたマルチなスレッドによる設定等各種ファイルの読み込みが完成しました。よし、どの程度速いのか早速計測…と意気込んでいたのですが…想定外の事態が発生しました。何も工夫しないシングルなスレッドの方が起動が速い…。この結果を見てから考えるに、結局、読み込んだ情報を本体に反映させる段階で処理のキューが詰まってしまうため、それならば淀みなく流れるシングルスレッドの方が速くなる、といったところでしょうか。う〜む、成る程…。さて。マルチなスレッドで記述した部分を全て修正しますか…。

語ると涙が出てしまうため黙しますが、とにかく様々な紆余曲折を経てChevron改めVacantの基礎部分がボンヤリと出来てきました。ChevronからVacantへと移行する際に事実上ほとんどの部分を造り直したため、機能的には最後に上げて放置していたChevronよりも遥かに貧弱ですが、そこそこ丁寧に仕上げているため不具合遭遇率は若干減っていると期待出来る…かもしれません。しかし、作者が要らぬ寄り道をしたせいで、予想を遥かに上回る進捗の遅延っぷりです。春になったら一ヶ月ほど雪国に飛ばされ、その間Hikageは身動き一つ出来ず完全に消滅してしまいますので、何とかそれまでには完成させたいのですが…果たしてどうなることやら。

そうそう。Xreaさんのところに"バイナリ＋そーす"との言葉と共に上げましたが、どうやら肝心のそーすを入れ忘れてしまったようです。全く、困ったものだ。

ChangeLogメモに"似た"形式での読み書き用DLLと設定の読み込み用(以外には使い物にならない)インチキXMLパーサーをDLLにしたブツがやっと完成しました。これからメモ・日記関係のソフト造ろうかなと考えてる方がいらっしゃる場合、是非ChangeLogメモ形式を採用して欲しいものですね。そうすれば、作者の心の琴線に触れるようなソフトが出てきた場合、作者自身が楽に移行出来ます。自分の好みに合致したソフトがあるなら、別に自分で開発する必要性はありませんしね。

あと、Chevronですが、"Vacant"という名称に変更しようかと思ってます。Chevron"だと、ReBarのChevronを検索する際にヒットしてしまい、大変邪魔でよろしくない。その点、Vacantなら技術関連でヒットする可能性は低そうですし、"Vacant.exe"で日本語検索してもヒットしないので他のソフトさんに迷惑掛ける可能性も低そうです。ちなみに、"カラッポ"という意味合いでこの"Vacant"という名称を付けています。軽くてスカスカ、まるでヘチマみたいなアプリという意味です。

何故か、作者は3月後半~4月前半辺りから一ヶ月程の期間、雪国へ篭らねばならないようです。いつの間にかそう決まったそうです。それも、セキュリティのため開発機の持ち込みはNGとか。ファイル共有なんてしないし、そもそもネットワークにも繋がなくていいから持ち込ませて欲しいのですが、それでも駄目なんだそうです。一ヶ月も日の光を浴び続けたら消滅してしまいそうですが、耐えるしかない。全く、困ったものだ

先程気付いたのですが、この時期に蒸発とか書くといかにもライブドア関連の沈没に巻き込まれたとか、就職活動中だとか、センター試験だとかのビッグなイベントで忙しいと誤解されそうですが、残念ながらいずれも違います。では何をやっているかと申しますと、開発でちょっとした思い付きを試してみたくなり、その為に必要となる膨大な単調作業をマシーンになって処理しているだけです。時間掛かるかもしれませんが、その内戻りますので、残念ながら消えるわけじゃありません。…ネットでのみ出現する場合、こうした生存確認みたいなヤツって意外と面倒ですねぇ…。

不本意ですが、少しの間蒸発します。

ここに上げられている画像と比べてカレンダーの文字が汚い、という旨のメールを頂いてしまいましたが、あの画像のフォントは別に特別なブツではありません。あれは、少なくともXPであれば標準で入っているはずの「Tahoma」なるフォントです。作者が個人的に好きなフォントであり、思い切って作者特権を発動、メニューやカレンダー等での標準フォントにしてしまいましたが…流石にちょっとやり過ぎたかな…。う〜む。もう少し問題が発生するようであれば、無難に「ＭＳ ゴシック」にするべきかもしれませんね。…まぁそれはどうでもいいとして。「Tahoma」であの画像のように綺麗な文字で表示するためには、ClearTypeというのを有効にする必要があります。デスクトップを右クリックし、「プロパティ」-「デザイン」-「効果」-「次の方法で〜滑らかにする」というコンボボックスの値を「標準」から「ClearType」にするとClearTypeが有効になります。すると、あの画像のようにカレンダーの文字列が綺麗になるはずです。

とりあえずChevronの骨組み完成版を上げてみます。ソース同梱ですし、DelphiとCが少々出来て、かつエディタとカレンダー以外は何もイラン、暗号もイランという方は、この段階でのソースを改造なさるのがベストかもしれませんね。

正月が終わってしまいましたねぇ…。虚しい。

さて。終わったことは放置するとして、開発では多大な変更がありました。まず、UNICODE化の廃止。とある壁にぶち当たり、悩みに悩んだ結果、面倒になったためUNICODE用のコードをざっくり切り捨てました。まぁ余興で取り組んでいた事柄ですし、如何でも良いことですね。次に、エディタの行番号。これも廃止、コード撤廃となりました。理由はいつかの投稿にもあるはずですが、とにかくちらつくからです。作者はエディタの行番号は常に表示させておく派なのですが、それでも我慢出来ませんでした。あとカレンダーの表示仕様。とりあえず枠で囲う方式を採用し、本文存在日付を太字化、という仕様に落ち着きました。あとの仕様は成るように成っていくでしょう、多分。

上記が主だった変更点です。そして、下記がこれからの仕様検討です。
以前、ChangeLog形式を採用すると言いましたが、これが今揺らいでいます。理由は暗号化。暗号化やパスワードといったプライバシーな機能、自身が一切使わないためか、すっかりその存在を忘れてました。さて、それではこれら暗号機能を付け、ファイルを暗号化した場合…たとえChangeLog形式を採用したとしても、汎用性なんてあるわけがない。暗号化が独自の処理である以上、絶対に保存処理の過程に独自性が介入してしまいます。そこで考えられる選択肢は二つ。一つ目は独自仕様路線を極めることです。汎用性無視。移行ツール出すから問題ない、と開き直ります。そして二つ目は暗号機能自体の撤廃です。汎用性の方が重要。そもそも暗号機能なんてあるのがいけない、撤廃だ、と開き直ります。個人的には後者の方が仕様的にも労力的にも望ましいのですが、現実的には暗号化・複合化DLLを拵え、それを公開することによって最低限の汎用性を維持しながら前者の仕様を採用するのが最善…でしょうか。う〜む。何だかなぁ。

…というよりですね、何故にメモや日記といった分野には統一規格がないのでしょう？やはりマイクロソフトさんがそういった種の決定版ソフトを出してないからでしょうか？何にせよ、困ったものだ。

基本UIが半分程出来ました。左側の白い部分は「メモ帳」を拡張したエディタ、右側上部がカレンダー、そして右側下部はまだ真っ白ですがタブコントロールです。御覧の通り、カレンダーは上部据え置きにしてしまいました。理由は一つ。縦長の領域にカレンダーを配置する場合、下の方の空間に困るからです。何か入れないと空白で困るならば、タブを入れてしまえ、という具合です。

あと、カレンダーですが、本文存在日付の太字化などの強調方法を如何したものかと思案しているところです。とりあえず現在日付を太字化+下線付きで表示し、本文が存在する日付は灰色でなく黒で描写…という仕様を想定していたのですが、それだと設定で土日等に青や赤といった色を指定した場合に色の衝突が生じることに今更気付きました。困りましたね、コレは…。この場合、開き直って現在日付は下線を引っ張るだけで済ませたいところなのですが、果たしてそれで良いのだろうか…。ちなみに、SimDiaryのような現在日付領域の塗り潰しは出来れば回避したいところです。アレ、実は見た目の効果は大したことない(単に色付けされるだけの)くせに、描写や更新に掛かるコストが甚大という割に合わない仕様だったりしなかったりするからです。う〜む。困ったものだ。

んんん？昨日の投稿で32KB制限が云々言ってますが、特に問題ないはずですよねぇ。確かに32kB以上のファイルを読み込ませても、固まったり何だりで使い物にならないことは事実ですが、一応使えることは使える。昨日の作者はどうも血迷っていたようです。しかし、一度投稿したブツを今更削除するのもアレですので、とりあえず放置してしまいますか。

気合でWindows標準エディットコントロール、要は「メモ帳」のエディタ部分を拡張していたのですが、やはり色々と壁がありますね…。まず挙げられるのが描写のちらつき。メモ帳さん、少しちらつき過ぎですよアナタ。巧いちらつき低減方法もないため、ストレスが溜まりますね…。また、エディタの左側に余白を設定出来るみたいなので、とりあえず描写処理に行番号描写処理を無理やり割り込ませてみたのですが…これのちらつきが特に酷い…。事実上、実用に耐えるブツじゃないです。しかし、破棄するのも勿体無いので、ちらつきなぞ気にならんという方専用のオプションとして封印してしまいますかね…。

そして、次に引っ掛かるのが地味に32KB制限です。32KB制限とは、32KB以上のファイルは編集出来ないというWin9x時代の古き良き負の遺産のことです。Win2k(あれ？WinXP以上でしたか…？)以上であれば当該制限は解除されている…のですが、そうは問屋が卸さない。エディットコントールの提供する関数が32KB制限を前提としているため、それ以上の容量を読み込ませた状態で掛かる関数を呼び出すと、当然のようにエラーで落ちてしまうのです。…何だかなぁ…。

さらに、もう一点気になるのがパフォーマンスの問題です。無限アンドゥ・リドゥを実現するため、標準のアンドゥ操作を乗っ取って色々と小細工しているのですが、UNICODEで操作する場合、確実にパフォーマンスの観点ではANSI版に劣るはずです。これはUNICODEとANSIを共存させ、かつソースの可読性を維持するための苦肉の策なのですが…やっぱり何だかなぁという感じがしてきます。TMemo拡張型のコンポがあまり見当たらないのは、やはりメモ帳がエディタとして正直微妙だからなのかもしれませんね…。

とりあえずDelphiでReBarに入れることが出来るメニュー完成です。興味ある方はとりあえずソーソ込みで時限的にデモ上げますのでどうぞ。割と自然な感じになっていると思うんですけど、実際のところはどうなんでしょう？とりあえずIEとEmEditorという二つのアプリケーションのメニューの動きを模してみたのですが…。まぁ、少なくとも作者がメニューに求める動作は実装させましたし、追って修正していけば良い話ですか。

後はこれをTWinControl派生のVCLに移植出来ないかなといったところなのですが、中々面倒そうなんですよね。そもそも、先程適当にコピペしてVCL用に修正、実行したところ、何故か描写処理が暴走、画面の表示が吹き飛んでしまったりしなかったりしました。そのため、コード移植に当たっては逐一正常動作を確認しながらでないと「極めて」危険なのです。う〜む。何て面倒なんだ。放置するか否かは五分五分です。

C++止めてDelphiに戻しました。コピーコンストラクタや代入が面倒だとか、「with」文という記述法が(C言語の延長故に)ないとか、読み取り専用のPropertyが無いためカプセル化が巧く出来ないなどと理由は様々ですが、これ以上の理由の列挙は無意味ゆえにしません。要はC++が肌に合わない上に飽きた、それだけです。ただ、その決断によるデメリットは甘受するつもりです。例えばUNICODE対応。これについては少し気合と労力を割いて対応します。また、UNICODE対応に関連してANSIベースなVCLの使用も極力抑えます。それによりファイルサイズも小さくなるはずであり、パフォーマンスで一石二鳥、要する労力10倍以上といった辺りですか。…実は作者の造るブツにおいてはUNICODEに対応する必要性はほぼ無いのですが、そういう無駄で、恐ろしく手の掛かることに挑むことこそ趣味の醍醐味。飽きない限り、UNICODE対応に精を出します。

とりあえず、上記の方針で走ってみます。まぁ、例えこの方針が挫折したとしても、納期も責任もないこのプロジェクトでは壊れるのは元々無い作者の面子や信頼ぐらい。特に問題がない辺りも趣味の良い所ですね。最終的に成果物が出来て、なおかつ作者が満足出来ればそれで良い。仕上げは流流、仕上げを御覧じろ、といった辺りですか。

何となくC++を勉強中です。C言語とは違い触るのは全くの初めてであり、多少不安もあったのですが…なんてことはない。C言語とDelphiを足して3で割ったようなブツじゃないですか。と、言うわけでDelphiからC++に浮気開始です。だいたい、DelphiじゃUNICODEに今一ピリッと対応出来そうにありませんしね。

さて。浮気するのは良いとして、C++に慣れる為にもまず何か造ろうということで、IEのようなReBarに突っ込むことの出来るメニューでも造るかとおもむろに始動したのですが、これが何とも曲者でした。WM_PAINTで適当に描写することでIEのような「見た目」だけは簡単に実現出来たのですが、その後が実に難しい。C++習い始めたばかりのハイパー初心者への課題としては難易度が間違っていました。何せ、「ファイル」というメニューを表示中に、隣の「編集」というメニューの方へ移動すると「編集」メニューの項目が表示される、というメニューとしての超基本動作の取っ掛かり部分を造るだけで3日経ってしまいました(事実上、WM_ENTERIDLEというメッセージに辿り着くまで3日ですかね…)。う〜む、メニューめ…今まで何てこと無いコントロールだと思っていましたが、如何して如何してやってくれるじゃないですか…。まだ第一ラウンドだというのに、既に作者はグロッキー気味です。

何となくVisual C++ 2005 Express Beta2をインストールしてみました。重い…しかし、Eclipse + CDTよりもコード補完がマシなはず。早速PlatformSDKと連動させよう…と思ったのですが、何ですかアレは。パスを設定する「オプション」-「プロジェクトとソリューション」-「VCディレクトリ」の部分が明らかに壊れてるじゃないですか。MSの開発者は誰一人としてコレに気が付かなかったのでしょうか…？う〜む、まぁ良いか…。とりあえず適当に設定し、使えるようにしてプロジェクトを新規作成。…おお、凄い。勝手にWndProcの雛形書いてくれる上に、御丁寧にもReadMe.txtまで用意してくれるとは…。思ったより面白そうですので少し遊んでみることにします。

ずっと考えていた事項を幾つか決定しました。

まず、プロジェクト名。SimDiaryからChevronにします。Chevronは元々SimDiaryの後継として途中まで造って放置していたブツですが、それを仕上げようかと思います。理由は一つ、SimDiaryとは仕様的にかなり異なるブツを造るため、名前が同じでは抵抗があるからです。かといって"SimDiary2"なんていうのも嫌ですし、さっくりと名前を変えてしまおう、といったところです。まぁこれは如何でも良いことですか。

次にディレクトリ構成。仮にデータの保存先を"C:\data"とした場合、とりあえずデフォルトの仕様では"C:\data\txt"以下に"yyyymm.log"としてファイルを保存します。画像等は"C:\data\img"以下に日付に応じたフォルダを拵え、そこに縮小画像用のキャッシュやら何やらの情報を放り込むことにします。これなら割と綺麗なディレクトリ構成になる…と思います。また、当該書き込み・読み込み処理はdllに丸投げします。それにより、従来の仕様を提供するdllを拵えることで、互換性も一応保たれる…かもしれません。

そして最後にテキストの構成。これは保存単位を現行の日単位から月単位へと変えるとともに、ChangeLogメモに似た形式を採用します。この仕様なら汎用性もありそうですし、割と良さ気ですね。ただ、問題を挙げるとすれば…作者はChangeLogメモを使ったことないんですよね。書きっ放し読みっぱなし放置しっぱなしが基本スタイルな作者には整頓術系はちくと疎い分野であり、知識が全くありません。そのため、これから勉強を始めるわけですが…間違った方法や仕様を覚える危険性も無きにしも非ず。どんなとんでもになるか楽しみです。

とりあえずは上記仕様でやってみようかと思います。ああ、あとDimのような仕様を採用し、面倒を克服すればメニュー、ツールバー、ホットキー、その他を自由にカスタマイズ出来るようにもしてみますか。

今日は何故か一日暇ですのでDelphiで少し真面目にコンポを製作中です。とりあえず造るべきだったのは無限アンドゥ・リドゥに対応したTMemoです。TEditorだとプロポーショナルフォントが使えませんし、TSonEditは仕様が今一つ肌に合わないため、他のブツが必要なのですが、探し方が悪いのかそういった条件を備えたブツが中々見当りません。そのため、止むを得ず自前で拵えました。表面的には動いていそうな気がしますので、とりあえず良しとします。時と共にいずれ良くなっていくでしょう、多分。次にUxTheme.dll対応のTStatusBarです。「Delphi2005Personalが無償公開されるだろうし、その際にTStatusBarもUxTheme.dllに正式に対応するだろう」と期待して放置していたのですが、全然公開されないじゃないですかDelphi2005Personal。しょうがないので、これまた自前で拵えました。PlatformSDKのUxTheme.hを適当にDelphi用にしたブツを用意し、適当に描写させるようにしたところ、とりあえず巧く描写されているようです。Theme…もといXPのスキンを変更した場合にはどんな具合になるかが大変懸念されますが、面倒臭いのでソレもとりあえず放置です。そして最後にTCoolBarでChevronが出るように修正…といきたかったのですが、ReBarの仕様が良くわからないためあえなく挫折。…まぁ、そのうち運が良ければ出来るかもしれませんし、とりあえず放置です。その代わりに、UxTheme.dll対応のTTabSheetを拵えて一段落です。

久方振りにDelphi起動しましたが、やはりVCLは良い。階層的で美しいです。泣けるほどファイルサイズが肥大化しますけどね…。

そうそう。出来立てホヤホヤで不具合だらけであろうブツをXreaさんのとこに上げときました。興味ある方はソースで配布してますので御自由にどうぞ。不具合を見つけた場合、出来ればその内容と直し方を御教示頂ければ幸いです。

Dimがあらかた出来ました。後はID3v2タグの取得ぐらい…なのですが、面倒なんですよね、タグの取得。巧くいかなければ放置してしまうのも手ですね。

さて、Dimが出来てきたところでふと思い出したのですが、そう言えば作者はSimDiaryなるブツも造っていたのでしたね。すっかり忘れていました。随分ご無沙汰してましたので、そろそろ再着手するのも一興ですね。…しかし、今見直すと…凄い仕様ですね、コレは。二年程の間、適当とその場凌ぎが積もりに積もった好い加減な仕様を改めて見せ付けられると、流石に驚きを隠せません。よって、再着手に当たっては、旧版との互換性が完全に失われてしまいますが、もう少しマトモな仕様にしようかと思っています。仕様変更に伴う不幸のメールが来そうですが、既に旧版の仕様では開発意欲が全く湧かないため、しょうがないこととして諦めて下さい。移行ツールは一応出す予定ですので。ああ、あと新しい仕様はまだ完全に白紙状態ですので、こんな仕様を採用しろとかありましたら今の内にお願いします。開発を開始してしまってからでは戻れませんからね。後だしジャンケンは御法度です。さて、どんな仕様にするかな。

あと、ここからは如何でも良い話なのですが…ちょっと気晴らしにとNScripter製のゲームを起動したところ、何やらビープ音が延々鳴ってくれています。何ですか、コレは？他のNScripter製のブツでも鳴る当たり、M/BとNScripterとの相性が破壊的に悪いのか、とにかくピーだがプーだか鳴ってしまうようです。そして、原因がさっぱりわからない。全く、何と言うことだ…。こういう形でNScript.dat復号ツールと正規表現の知識が役に立つとは予想だにしませんでした。世の中、何がどこでどう役に立つかわからないモノですねぇ…。

半分くらい出来ました。とりあえず何かの音が鳴るようです。「想定の範囲内」の操作では一応不具合もなし。また、メモリリークもなさそうです。航海はある程度順調かもしれません。

今回、C言語で再構築ということですが、Delphi版と同じブツが出来るのでは面白くない。そこで、無駄なことを色々考えています。例えば「お気に入り」機能。要は、プレイリストやらフォルダやらを適当に登録しておこう、という趣旨です。フォルダも登録出来る点がDelphi版と比しての機能面での進歩であり、そして軽さの点での退歩といった点です。他には…あれ？変更をメモしといたテキストファイルが見当たらない…。まぁ、良いか。とにかくそんなところです。

そうそう。この間ココでテレビが死に掛けているとボヤイタ記憶があるのですが、先程遂にお亡くなりになられました。NHKのニュースを付けていたのですが、いきなり「バンッ！」という爆発音？がしたと思ったら、既に事切れていました。約20年も作者に連れ添ってくれた苦労人が一瞬にしてただの箱…。長年使っているブツが壊れるというのは、何とも物悲しいものですねぇ…。

不具合の修正に成功しました。不具合の内容はHeapの一部破壊。そして、破壊していた原因は、既に解放していた領域を多重に解放していたことでした。これだからC言語は…。まぁ、CのGNUコーディング規約にDelphi的コーディング規約を混ぜ、さらに手抜き記述を推進するための作者的規約を盛り込んだ怪しいコーディング規約を採用していたため、こういう不具合に直面するのも必然だったのかもしれません。今は、とりあえずGNU規約にある程度準拠させ、加えてCで書かれた某ソフトのソースを参考にした「正しいC言語の書き方」みたいなブツで書いています。やっぱり何事も王道こそ最良の道ですね。

そうそう、アイコンを減色しました。今まではどうも50色以上使っていたようだったので、それを16色に減色。その結果、5KBの減量に成功しました。そしてファイルサイズは…何と11KB。これは凄い。同じ機能を実装するにあたり、Delphiだと25KBは必要だったのですが、たった11KB。ヒイヒイ言いながらメモリ管理するだけの価値があるというモノです。本当にたった11KB？と思われる方もいらっしゃるでしょうから、証拠画像も用意しました。確かに11KBです。この分なら、最終成果物完成時点でも25KBを切ることが出来るかもしれませんねぇ。

昨日は原因不明の不具合にヤケになり、C言語なんてもう止めたと宣言しましたが、やっぱりもう一度だけ取り掛かることにします。何だかんだと言いましても、同じ程度の動作を実現するにあたり、ファイルサイズがDelphiで35KB~40KB程度、対してCでは20KB~25KB程度とやはり魅力的です。また、起動直後のメモリ使用状況についても、仮想メモリで約60KBくらい節約出来ている様な気がします。以上より、軽さを追求するならCの方が優れていることは明らかです。ただ、(特に作者が構築する場合には)Delphi版と比して安定性で著しく劣るのは否めないのも事実。なので、とにかく慎重に構築してみることにします。それでも駄目だった場合には、ざっくりとVisual C++ Toolkit 2003とPlatformSDKをアンインストールですね。なまじ残っているとファイルサイズの魅力に囚われてDelphiに集中出来ませんしね。年内一杯ぐらいまでは、この「追求するは軽さ、言語はC(駄目ならDelphi)」という方針で行くことにします。

一応C言語版のDimもある程度出来たのですが…これは駄目ですね。ファイルサイズが思ったより縮まなかったのも誤算ですが、何よりDelphi版と較べると安定性で著しく劣るのが痛いです。やっぱりいい加減な作者にはDelphiやJavaといった色々と勝手に管理してくれる様な言語の方が向いています。よって、開発言語をDelphiに戻してしまいますね。

丸秘とか書かれていたような気がする紙切れを紛失しました。作者ピンチ…。

FModの性能評価をしてみました。その結果、Bassの方が軽さに優しいという驚愕の事実が発覚しました。…そもそも、ファイルサイズがBassの約90KBに対してFModが約160KB。この時点でBassの方が軽そうだと気付くべきでした…。…まぁ、良いか。とりあえずBassの方が軽いmp3Playerには向いているという事実がわかっただけでも良いいとして、さっさと開発です。メニューやホットキーの読み込みはもう完成しているので、後はPlayerとしての機能を付けるだけです。

そうそう、性能評価と言えば、他の軽くて有名なプレイヤーさんを幾つかチョイスしてDelphi版Dimと軽さ較べをしてみました。すると、Bassの初期化にCPUやメモリを喰われるのが弱点なのですが、それ以外ではGUIを半分放棄しているだけあってかなり軽い部類との結果が出ました。一応、"軽量なmp3Player"との看板は守れているようです。

新しい開発機が先程届きました。早速適当なアプリを入れて試しているのですが…凄い、凄いですよメモリ1GB。Excelとブラウザを同時に動作させてもスワップしない。変なボタンを押すと直ぐに軽く固まっていたEclipseもサクサク動くじゃないですか！メモリの増設部分が何故か破損して以来256MBでずっと頑張っていたため、この1GBの感動は筆舌に尽くし難いです。最廉価モデルでCPUとメモリにだけ金を掛けた構成にして大成功です。…ただ一点、ファンがうるさい点を除けば、ですけどね…。

先程Eclipseを起動したところ、何故かCDTで巧くビルド出来てしまいました。数日前にはちっともビルド出来なかったのですが…謎です。謎ですが、とりあえず動いているので放置です。さて、これで念願のコード補完が出来る…と思っていたのですが、何ですかアレは？コードの補完候補を表示させようとしたところ、ゆうに3分弱はEclipseが固まりました。明らかに自分で記述した方が早い。これは恐らく、作者の開発機がCDTを走らせるには低スペック過ぎる…ということなんでしょうねぇ。…残念です。しかし、コード補完以外は素晴らしいですね。流石IDEです。エディタにポチポチ記述していた時と較べると天と地です。当分はこの構成でいくことにします。

IDEで思い出したのですが、VisualStudio2005が無償配布されるとかされないとか。Eclipseも良いですが、無償配布されるならVSも捨てがたいですねぇ。

昨日は勢いでメモリを1GBにしてしまいましたが、そんなに必要なかったような気がしてきました。現在、作者の開発機(256MB)は恒常的に100MB分くらいスワップしているのですが、それはつまり512MBあれば十分足りているということでは…。そもそも、始めから1GBでなく、必要になった時点で増設すれば良いではないか…。後悔先に立たずってヤツですかね。少し泣けます。まぁ、今更どうにか出来るわけでもなし、代引に怯えながらとりあえず忘れるのが一番ですね。

現在、作者は"Bass"というライブラリをメディアの再生に使わせて頂いているのですが、この"Bass"、少しCPU使用率が高いんですね。如何したものか…と悩んでいたのですが、あるじゃないですか、似たようなライブラリが。"FMod"というライバル的なライブラリ発見です。おまけにフリーソフトでの利用なら無料という点まで同じ。また、やはり"Bass"と同様に機能については定評があるらしく、その高機能さゆえにXBOXなるゲーム機にも使われているとかいないとか。メディア関連に疎い上に、XBOXというブツに触ったことのない作者には今一つピンとこない例えですが、恐らくとても高機能なんでしょう。早速Delphi用サンプルを少し走らせたところ、CPU使用率が"Bass"より低そうな気がします。

さて、ここまでお膳立てが整っている以上、浮気しないわけにはいきませんね。"Bass"には悪いのですが、"FMod"への浮気プロジェクトを厳粛に開始することにします。

流石にもう限界ということで、新たな開発用ノートを調達中です。いやー、最近のブツは凄いですね。CPUにAMDのTurion、メモリをIGB、適当にOfficeとマウスを付けてそのお値段、しめて16万也。安い。財政的にほんの少し厳しいですが、それでも安い。ちなみに、現在の作者のノートはCPUにCeleron(R)の1.6GHz、メモリ256MBという涙モノのスペックですが、それでも確か18万以上はしたと記憶しています。時代は流れているんですねぇ…。

軽く感動したので、ちょっと開発とは無関係ですが投稿してしまいますね。

昨日の唸り以降、物凄い勢いで作者のマシンが天寿へ向けて邁進してくれています。まず、CDドライブが何故か壊れました。書き込みは勿論100%失敗。読み込みもサッパリです。HDDだけでなく、CDドライブまで？…何故？…まぁ、そんなことは如何でも良い。感動したのは、Cドライブにインストーラーによるアプリケーションのインストールが出来なくなったことです。勿論、アカウントに管理者権限がなかった等という、いかにも作者にありそうな落ちは無しでの事です。具体的には、この開発機のCドライブにはまだ10GB以上の空きがあるのですが、50MB程度のファイルをインストールするインストーラーを走らせると、何故か「空き容量が足らん」と怒られてしまいます。意味不明ですが、それじゃ話になりませんので、とりあえずDドライブではどうかなと試したところ何の問題もなくインストール完了。先週にOSを再インストールしたばかりゆえに、レジストリが壊れている可能性は低いはず…。全く、困ったものだ。

先程、開発機を立ち上げようとしたところ、HDD周辺部分がすわ工事現場の音か？というような唸りを上げながら立ち上がりました。驚きましたね…。突然「ウィィィ…ガガガガガガガ…」ですか。…いや、音なんて如何でも良い。一番の問題は作者のHDDが今にも死にそうなことのはず。とりあえず拾ってきた外付けHDDに主要なファイルを移し、念のためにYahooブリーフケースに開発用ファイルを移し準備万端。いつでも掛かってこい、という具合です。別に来なくても構いませんけどね。

クラスを用いたPascal的なDimの本体が大体出来てきました。そして、その過程で気付いたのですが、恐らく現状のDimでは日本語ファイル名を扱う上で不具合が生じているはずです。例えば、「C:\MyMusic\ウィンナーソーセージ.mp3」というファイルをプレイリストに登録していると仮定した場合、Dimのプレイリストポップアップでは「ーセージ.mp3」と表示されるはずです。これでは意味不明な文字列になってしまうので、とりあえず修正しましたが…日本人のくせにマルチバイトの考慮を完全に忘却している辺り、作者も知らず知らずの内にハイカラに被れてきているのかもしれませんね。う〜む、恐ろしい。

Dimのクラス化構想ですが、見事に自爆しました。先程、仕様に致命的な欠陥を発見し、何とか取繕うと善処したのですが、明らかに茹でパスタ路線一直線ということで断念しました。ほんの少しだけ仕様が甘かったかな…。う〜む…。困ったものだ…。しかし、偽VCLのソースは流用出来るので、再構築に掛かる時間は割りと短くて済むはずなのが唯一の救いですか。

とりあえず、何かのお役に立つ可能性があるかもしれませんので、ソースを時限的に上げときます。何だかんだと面倒になってきましたので、とりあえずBuild 0.6.0.0をVectorさんへ送ってしまいましょう。作者の環境では何となく動いてますし、大丈夫でしょう、多分。そうそう、今度こそVectorさんにメールが届くと良いんですけどねぇ…。

セコセコと表面だけをVCLに似せたクラスを造っているのですが、やはり可読性が全然違いますね。それに、やはり自然です。Delphiでクラス無しのプログラムは違和感があり過ぎました。ただ、TObjectの動作をCreateWindowExで造ったWindowと同期させるのは少し難しいですね。一応動くことは動いているのですが、クラス無しの場合と較べて爆発的に安定性が落ちています。運が悪いと、"らんたいむ　えらー"のような文字列が無限に出現するという不幸に見舞われるかもしれません。う〜ん、物事巧い話ばっかりとは行かないものですねぇ。

今日の午後、あやうく死ぬとこでした。いや〜、恐ろしい。こういう事態には困ってしまいますね、全く。ネットではサイトの管理人さんが突然蒸発するなんてことを割りと良く見かけますが、危うくその仲間入りするところでしたよ。

"dim.dll"のソースですが、段々パスタに近付いてきました。やはりC言語のようにクラスを極力使わない、というやり方は作者には向いてないようです。このままではとてもじゃありませんが保守出来ませんので、いずれ汎用性の高いクラスでも作って、それで再構築が必要そうですね。

言うことを聞かないテレビに正拳突きしたところ、右手に多少不具合が発生しました。不覚です。しかし、テレビも10年経つと駄目になるもんですねぇ。色の調整もバカになってしまい、NHKのアナウンサーの方の顔色がまるでナメック星人みたいになってしまいました。

Bassが返すストリームの値はCardinalでしたね…。Integerの範囲で処理していたため、物凄い勢いでリークしてました。おまけにコンパイラオプションのオーバーフローチェックが無効になっていたため、タスクマネジャーを何となく見るまでとんと気付きませんでした。いやぁ〜…失礼しました。ほとんど使っている人がいないと予想される点が救いです。調子に乗ってVectorさんに登録しないで本当に良かった。

不本意ですが、不具合修正のためにDim Build 0.3.0.0を出してしまいました。本当はメニューの編集をGUIで出来るようにしてから出したかったのですが、TreeViewのDrag&Dropに手間取ったため、いまだに出来ていません。しかし、不具合を放置しておくのもそろそろ気分的に限界。ということで、止むを得ずメニュー編集関連の操作を隠蔽しながら公開した、という次第です。あれ…今気付いたのですが、バージョン情報が"Build 0.2.0.0"になっていますね…。う〜む。まぁ、良いか…。

そうそう。GUI関連の操作についてはDLLに分割して開発しています。編集なんて四六時中するわけでは無いと想定されますので、使う時にだけメモリに読み込ませた方が絶対にお得だからです。

何故"GetProcAddress"が自由なアクションの定義用途としてあまり聞かないか、ですが、それは恐らく"GetProcAddress"が大文字・小文字をバッチリ区別してしまうからだと考えられます。それに引数も画一的にしないと不味い。制限だらけですね。下の方で「"GetProcAddress"で造る」などと宣言した手前、これらの制限に目を瞑って造ってましたが、もう限界です。廃止です、廃止。泥臭い方法であれど、大文字・小文字を区別しないという方式を採用することにします。

そうそう。"NScript.dat"復号ツールを再公開しました。如何でも良いツールなんですが、やはり、物凄くたまに必要になりますね、アレは。