CatShanty3(仮) #
地味に構想は練っている。
明るい未来ではあるものの非常に大変そうで、しばしば悲観的になってしまうが、のんびりと取り組んでいる。
CatShanty2がいつのまにか大きくなっていた #
数年に渡り改修とリリースを繰り返せたのは愛してくれたユーザーの皆さんのおかげであり、心より感謝しお礼申し上げる次第だ。
本当にありがとうございます。
なんだかんだで支えられながら大きくなったと思う。
振り返れば自分が欲しかった物は作れたと思っている。
いつだったかEmuCRで数回取り上げられ海外からの来訪が増えた時期もある。
英語対応をしていればまた違った盛り上がりがあったのかもしれないが、自分の中では上出来だと満足している。
振り返り #
今でこそエミュランチャに当たり前のようにある「起動時に他のプログラムを連携起動」することは、2009年当時にカナ入力のエミュレータ仮想マシンに対しローマ字入力を行う素晴らしいサポートソフトが公開されていて、それを一緒に起動したいという単純な思いから付けた。ほかにもサイオブレードのメロディモジュールシミュレータもクールで、これも一緒に起動できるじゃないかと気付き可能性が見えた。バッチの連携はそこから広がった。
対応エミュレータを特定せず起動方法を与えるやり方も斬新だったのではないかと思う。当初はこのコンセプトを理解してもらえず苦労した。その当時のランチャは対応するエミュレータが決まっているのが普通で、未対応のエミュレータに対してはランチャが対応するのを待つかユーザーからリクエストを出すのが普通だった。それを、実行ファイルへの引数、iniやレジストリの事前書き換え、起動後のキーマウス発行スクリプトなどで、「自動化」「自動処理」と呼ばれる仕組みを取り入れて解決してみた。
内部的にはリストビューの表示処理などは今で言う「データドリブン」にあたると思われる。
CatShanty2ではSQLite3のメモリマップをそのままWin32のオーナードローのポインタへつなげている。こうしておけば、あとは難しいことをせずともSQLite3でクエリを実行すれば勝手にリストビューに表示される。しかも高速に。しかし言葉の範囲が広すぎてデータドリブンの正確な定義は今でも解っていない。1 2
またCatShanty2の起動中にスクリーンセーバーを無効化したり、CatShanty2からエミュレータの終了を促せるというアイディも我ながら気に入っており、当時は「その発想があったか」と称賛されもしたが、これも昨今のエミュでは当たり前となっていることだろう。
老朽化 #
つまり、私のプログラムレベルなんてこんなものだということを言いたい。
少しのアイディアと機能欲求だけで作ってしまった。
掲示板でも幾度と書いているようにCatShanty2はActiveBasic4で作られている。
Basicとは言え幾多のポインタをつないだ高速な（汚い😋）コードがかけた。素晴らしい開発環境ではあるが x64＋Unicode 化はActiveBasic5に移植する必要3があり、何より既にサポートが終了している。
アイディアが出尽くしたいま、新しい開発環境でCatShanty2に並ぶCatShanty3を作れるか、自分が一番不安になっている。
老朽化は開発環境だけでなく自身にも言えることかもしれない。
再生要素 #
CatShanty2に満足はしているが、CatShanty3を作り直す理由を再確認してみる。
- 開発環境の老朽化
- 新しい要望に答えられない現状
- x86 shift-jis の問題
- リフレッシュ
- データベース構造とイメージファイルの関係
開発環境の問題 #
ActiveBasicはサポートが終了して久しい。
ソースコードが一定量を超えた時点からデバッガが動かなくなった。更にコードが増加すると今度はコンパイラが動作しなくなる。
新しい要望に応えるのが難しいのはこれが原因で、万一のバグ修正のために空きコード量を確保しておく必要が出てきたためである。
x86プログラム(32bitプログラム)であることに別段不具合はない。そんなに大きな値を扱うとこはないだろうし、Wow64のおかげでそれと意識することなく普通に動作している。
ただ、ANSI文字が主体というのは芳しくない。
今どきsjisでは表示したい特殊文字が不足している。SQLite3は本来UTF8なためCatShanty2内でわざわざsjis→utf8に変換して格納しているのも勿体ない。表示にUTF8対応のコンポーネントを使用すればよいのだがiniファイルや外部テキストなどを考えるとやっぱりCatShanty3ではANSI環境という仕様に落ち着いていた。
画面に飽きた #
人は飽きる。
気分をリフレッシュするため、フォントやレイアウトサイズやカラーテーマという機能を設けていたが、私は基本レイアウトに飽き始めた。このあたりの構想はまた別の投稿で書くことにする。
データベース構造とイメージファイル #
端的に言えばプライマリキーをどうするか悩んでいる。
イメージファイルはメディアからの転送でファイル化するが、転送プログラムや転送中の微細なエラーによってファイル内容が異なる場合がある。特にフロッピーディスクなどは色々な理由で様々なバージョンが生まれてきたりする。 或いは全く同じファイル内容で書き出し出来ても、私なぞは「念の為」とファイル名を変えて保持しておいたりする。
データベースとイメージファイルの紐つけを如何にすべきか。オーソドックスに連番IDか、当時掲示板でもご意見を頂いたファイルハッシュか、これまで通りファイルパスか。
確かファイルハッシュを用いたアイディアで頂いたのは「ファイルハッシュでユーザーが移動したファイルも追跡する」というものだった。素晴らしいアイディアで是非検討したいと思っているのだが、上に書いたように「同じハッシュでファイル名違い」などをどのように処理するかが課題となる。
現在の方法であるイメージパスはOS上で唯一のものでありプライマリキーとするに相性が良いと考え採用した。私はDOS/Vの時代からエミュレータはE:ドライブ4で運用しており、これまで数代に渡ってPCを乗り換えてきたが滅多にファイルパス構成を変更しない。
しかし当然ながら良くファイルパスを変更するという人もいるだろう。そんな人には不便をかけていると思うが、某所で「相対パス非対応はダメすぎる」と、ダメにすぎるが付いた書き込みを見たときにはかなり気が滅入った。今でも心に刺さっている。
イメージファイルパス（プライマリキー）の変更機能も付いていた後の書き込みなので、相当ちょくちょくファイルを移動する人で一々変更なんてやっていられないという事例と想像する。
こうした反省を踏まえ、ベースフォルダの考えや、出来たらファイル追跡などもどうにか実現したいとは思っているが…。
１年ほど前からそんな事を考えながら、新しい取り組み方を模索している。