::Filezを超えた？

Filezで、書き込めないデータベースを、

自作のファイラーを、機能アップして、書き込めた。

ワンハンド・ファイラーで、しかもDAのファイラーが、ここまで出来ていいの？

PalmInsiderProで、吸い出したファイルを、コマンド　Eで、メモリー中にコピー

メモリー内のDBを、コマンド　Eで、外部ファイルにコピー

VoiceDialが、ROM表示になってるのは、ReadOnly属性が、立っているためです。
元々、ROMにあったDBの属性そのままコピーされてる証拠かな・・・

ROM判断を変更しました。また、Protectされていると赤表示に・・・

しかし、３５ｋバイトまでに減量したのに、４ｋも増えてしまって、３９ｋバイトに、なってしまった。

もうPalmInsiderProも、いらないかも？　だって、UI懲りすぎで、使いにくいから・・

追記

＊＊６４ｋバイトの壁＊＊

Palmには、幾つかの制限があるが、その中の一つに、「データベース内のリソースのサイズは、最大で、６４ｋバイトまで」、というものがある。

１レコードの最大長も６４ｋバイトまでだ。

この制限に従って、データ・マネージャーや、エクスチェンジ・マネージャーは、設計されているし、メモリーマネジャーすら６４ｋの壁を持っている。

しかし最近は、実行コードを、ARMコードで作るソフトが、多くなっている。
ARMコードには、６８ｋコードのように、３２ｋの壁がないので、作ろうと思えば、６４ｋを超える実行コードだって、簡単に作れてしまう。

何故、このような話しを、するかというと、今、解析中のソフトVoiceDialが、８００ｋバイトを、超えるARMコードを、持っているのだ。

こういった、イレギュラーな、DBの場合、通常の手段では、外部にとりだせても、書き込む事は、できない。

実際に、私の作ったファイラーでも、書き込めないし、取り出せもしない。

で、ある人に、PalmInsiderProというファイラーを、教えてもらった。

この製品なら、書込みも、取り出しも可能だ。

ここからが、本題だ。

他人の作ったファイラーに出来て、自作のファイラーでは、出来ないというのは、問題である。

さらに、PalmInsiderProは、凝った作りで、スタイラスを、使わないとほとんど操作が、出来ないUIである。

タップ嫌いの私としては、PalmInsiderProは、使わないで済ませたい。

そこで、自作ファイラーに、機能追加を図って、完成にこぎつけた。

問題となったのは、８００ｋもあるリソースを、どうやってデータベースに組み込むかだった。

プログラム内で、リソースを作って、データベースに組み込むのは、経験がある。
MemHandleNewを使い、必要なチャンクを用意して、HandleからPointerを、取得して、リソースを、書込み、DmAttachResouceで、データベースに追加する方法である。

しかし、MemHandleNewの最大サイズは、６４ｋまで、そのたのデータベース・マネージャーのAPIも、６４ｋまでのリソースしか、作れない。

そこで、ネットをさまよっていたら、ロシア人のフォーラムで、６４ｋ越えのHandleを取得する方法に、たどり着いた。

MemChunkNewを使う方法だ、これは、ローレベルのAPIで、システム専用APIとなっており、使ってはいけない物だが、しょうが無い。

で、何もかんがえないで、サンプルのまま使い、ファイルから読み込んだARMコードを、書き込んで、DmAttachResouceで、データベースに追加するまでは、完了するのだが、
通常なら、追加が終わった時点で、自前で用意した、チャンクを、Freeするのだが、これを行うと、エラーを起こしリセットされてしまう。

かといって、Freeしないで、終わろうとすると、「チャンクを開放してないよ」
「メモリーが、DBのよって、ロックされたままだよ」というエラーが出て、Palm機器は、不安定な状態になり、いつ爆発するか、わかったもんじゃない。

Freeしないでも、怒られない方法は、自前で、用意したHandleを、システムのものだよと、詐称してしまう方法があるが、表面上のエラーを回避しただけで、問題は、解決されていない。

「メモリーが、DBによって、ロックされたままだよ」というエラーも、Attachした後に、そのリソースを、読み込んで、Lock,Unlockすると、解決した。

しかし、すっきりした訳ではなく、二日ばかり、悩んだ末に、ロシア人の作った方法を、そのまま使うのをやめることで、解決した。

要点は、
・移動可能なChunkは、Handleで、移動不可のChunkは、Ptrである。
・データベース・マネージャーは、想定外の大きさのChunkは、ストレージ・ヒープにコピーできないので、そのまま使おうとする。

さらに、まったく逆の、メモリーから、外部メモリーへの吸出しロジックも組んだ。

・ヘッダー情報を、読み込み
・全てのリソース情報を、吸い出して
・リソース用のインデックスを作り
・ヘッダーとインデックスを、外部ファイルに書き出す。
・あとは、リソースのChunkを、その後に、順次、書き出すだけ。

もちろんテストには、VoiceDial.prcを使った。

外部ファイルのVoiceDial.prcを、メモリーにコピーして、ReadOnly属性とか、コピープロテクト属性を、色々変えながら、吸出しテストを繰り返した。

で、最後にオリジナルのVoiceDial.prcと、コピー。コピーしたVoiceDial.prcの、
バイナリ比較。

「むむ、１バイトの差があるぞ・・・」

見てみると、データベースを、何回更新したかの情報が、違ってした。

そう、メモリー中で、属性を、変えた回数が、違ったのだ・・・