WorkPad 用プログラムの組み方(4)

Prev 1 , 2 , 3 , 4, 5 , 6 , 7 , Next

このページの目次

• pdb ファイルの構造
• Program1 record header pealer.
• Program2 record header attacher.
• Program3 database splitter.

pdb ファイルの構造

おや?まだこのドキュメントを読み続けている??

普通、ここまで欠点だらけの OS を見たら、 そろそろ見捨てるような気がするのだが…まだ?

では、ちょっと WorkPad 上のプログラムを作成することから離れて、 pdb ファイルの構造を説明しよう。 最終的には PalmOS の GUI デザインを理解するためには、 実はここの構造を理解しておく必要がある。

pdb ファイルは PalmOS の database の中でも、 record database を PC に持ってくるためのフォーマットである。 逆に言えば、 pdb ファイルには record database の保持する全ての情報を持っている。 従って、pdb ファイルについて理解すれば database についても理解が深まる。

プログラムの作成には perl5 を使う。 最終的には apart-pdb.perl ファイルのやっていることを理解し、 好きなファイルを pdb ファイルにしたり、 その逆を行うのが目的である。

これができるようになれば、 PC 上の任意のデータを WorkPad に持ってくることも、 その逆もできるようになる。 このデータを WorkPad 側で適切に解釈することができれば、 WorkPad 上でデータを使うことができるようになる。

先に断らなくてはいけない。

このドキュメントを書いた当時、 pdb ファイル並びに prc ファイルのフォーマットに関する 公式のドキュメントは存在しなかった。 従ってこのドキュメントはこの公式のドキュメントを元にしていない。

現在では http://www.palmos.com/dev/tech/docs/fileformats.zip に解説がある。 この公式解説ドキュメントが出たのは 2000年 5月。 PalmOS が出てから一体どれほどの時間が経ったのかを考えると、 Palm Computing 社を自社製品をまじめに考えているとは思えない、 呆れ返るほどの時間が経っている。

これから述べることは複数の人間が解析した結果を あちらこちらから拾ってきてまとめた結果である。

しかし、同時にその解析結果が Palm Computing に支持されているものもある。 Palm OS Emulator(POSE) のプログラムコードとして記述されている pdb 並びに prc ファイルの解析ルーチンがそれである。 具体的には、POSE 30a3 のソースファイル、 LoadApplication.cpp に詳しい。 が、内容に関する詳細な解説はどこにもない。

POSE は Palm Computing によって技術的に援助されているプログラムである。 従って、ここにある PalmOS に関する解析結果の多くは、 Palm Computing によって暗黙に支持されている、と考えて良い。 仮に prc, pdb ファイルのフォーマットが間違っている場合、 POSE は役に立たないことになるが、 これは Palm Computing 社にとっても損失である。

従って、POSE の情報は正しいと仮定して良いだろうし、 その情報をベースにすれば prc, pdb ファイルの フォーマット情報は正しいと思って良いだろう。

もう一つ信頼できると想定して良い情報源は pilot-link のソースコードである。

hacker の解析結果というのは、 時として「プログラマー自身が誤解している公式発表」よりも 正しいことがあり得る。 まぁ、この場合は POSE と同じレベルの hack の賜物なので、 どちらがどちらに比べて正しいと言うことはないが。

pdb ファイルは大きく3つの部分から成り立っている。 database header 部、record header 部、 そして record data 部である。 すでに 前の章 で出てきたように pdb ファイルは data 部が最後に存在する。 通常のファイルの先頭に header を適切につけてやれば、 pdb ファイルになる、ということだ。

database header は 78byte 固定長、 固定フォーマットのフィールドで、pdb ファイルの先頭に存在する。 ここには database 固有の情報が存在する。 78byte の header はさらに次のような情報から成り立っている。

database header 領域の次に来るのが record header 領域である。

record header 領域は、簡単な構造をした element, record header element が database header にあった number of records の数だけ存在する。 さらに、record header 領域の最後には 2 byte の 0x00 で埋められた 領域が存在する。

record header element の構造は record database と resource database では全く異る。 prc, pdb ファイルがどちらなのかは database header の flags フィールド、 0x0001 bit が 1 の場合は resource database, 0 の場合は record database なので、database header を解析することで、 record header element の構造が判明する。 それぞれの場合の構造、サイズは次の通りである。

record header 部の最後の 2byte(0x00 が2つ)の pad の後には、 record body 部が来る。 record body 部には、実際に使われるデータが格納されている。

record database で、application info size が 0 でない場合は、 record body 部の最初に application info が格納されている。

record database で、sort info size が 0 でない場合は、 sort info が格納されている。 格納場所は application info が存在しない場合は record body 部の 最初に、application info が存在する場合はその後に、 sort info が格納されている。

application info, sort info の後には record data が順に入っている。 record data は record index の順に従っている。

pdb, prc ファイルのフォーマットは拡張性があると言えばいいのか、 ないと言えばいいのか、良く判らない。

例えば、record のサイズは pdb ファイルの先頭からの offset の 組合わせでしていされており、直接指定されていないこともあって、 64kbyte の制限を受けない。 従って、将来 PalmOS から record size の制約が無くなった場合も、 このフォーマットは使い続けることができるだろう。

ところが、record の数は16bit しかないため、 64k個の制限を受けたままである。 これは Palm Device の各種リソースサイズの制約がなくなり、 より多くの record が格納できるようになったときに問題となる。

record サイズの制限が pdb, prc ファイルには存在しない、 という点は、実は CodeWarrior においては問題として発生する。 CodeWarrior はこの 64kbyte の壁をまじめにチェックしていないらしく、 リンカーによって prc ファイルをつくる際に、 64kbyte を越えても全くエラーが発生しない。 これは HotSync を実行して始めてエラーとなるのだが、 その際のエラーでは一体何が起ったのかさっぱり判らない。

もう１つの問題点があり得るとすれば、 それは 4byte に align されていない、という点だろう。

Palm Device がいつまでも MC68000 ベースとは限るまい。 MC68030 等を使うことは MC68020 までの MPU が持っている各種の制約や バグを回避する上で重要だが、 この MPU は 4byte align ベースのアクセスしか許さない、 という性質を持つ。

その一方で、record のサイズ制限がなくなる等した場合、 現在の database を使う必要性などない、という事もできる。 この場合は通常のファイルシステムを RAM disk 上に構築した方が便利だ、 ということだ。 Database というのは確かに極めて限定された世界では有利だが、 汎用性がない。 IBM の System390 と同じ database フォーマットが 最終的に広範的に計算機に適用されなかった理由は、 まさにこの汎用性のなさゆえに単純な「ファイル」という構造に 駆逐されたためである。

Program 1. record header pealer

以上の pdb, prc ファイルのフォーマット情報に基づいて、 perl プログラムを作ってみよう。

最初のプログラムは各種 header 部を引き剥がす、 header pealer をつくってみよう。 オプションを使って application info, sort info を残す、 削るを選択できるようにしよう。

• 入力は stdin も含めてファイル名指定にしよう。
• 出力は stdout だけにしよう。 ファイルへの書き出しはリダイレクトしてくれ。
• -v で version メッセージを出すようにしよう。
• --help でヘルプメッセージを出して終了するだけにしよう。
• -a で application info を残す。
• -a- で application info 残さない(デフォルト)。
• -s で sort info を残す。
• -s- で sort info を残さない(デフォルト)。
• - だけの場合は、それ以降は option ではないとする。 これをつけておかないと、「間違ったオプション」なのか stdin を指定しているのか 判らないからね。

複数ファイルを同時に処理したりはしない。 そんな作業は shell を適切に使えば処理できる。 勝手に既存のファイルを上書きしない(これは stdout に出せばいいからだ)。 パフォーマンスは考えない。 pdb と prc 両方を扱えるように書く。 高度なトリックも使わない。低度なトリックも多分使わない。 判りやすく書くつもりだが、そうなるとは限らない。

コード全体を列挙するのはページの無駄なので さるぅんプロジェクト の PDBHeaderPealer.perl から取ってきて欲しい。 これを使うと、バイナリを理解しないエディターでも、 pdb header は取り除けるだろう。 ただし、PalmOS の特徴の1つである「改行は 0x0a」(MacOS は 0x0d で、 Windows は 0x0d, 0x0a である)問題は解決しない。 それに関しては nkf などを使い対処すること。 そうすれば 先に示したプログラム の出力結果も処理しやすくなるだろう。

プログラムの概略は簡単すぎて説明するのが恥ずかしくなるぐらいだが…。

コメントの後に、いくつか定数項が定義されている。 と言っても Perl には「const」等のキーワードは存在しないので、 単に特定の変数に対して、値を設定しているだけだが。

その後、option 処理を行う。 規定された文字列以外の最初のオプションを入力 pdb ファイル名とし、 処理を行った後正常終了する。 それ以外の場合は、メッセージを出力して終了する。

run_pealer 関数が実際に pdb ファイルから header を引き剥がす 関数の実体である。

まず、必要なファイルを open し、binary mode にする。 STDOUT も binary mode に切り替える。

次に pdb header を読み出す。 その後、record/resource header 分を全て skip する。

Applicatoin info と Sort info 領域を読み出し、 もし、$ApplicationInfo, $SortInfo 変数がそれぞれ 0 以外であれば 読み出した分を STDOUT に書き出す。

後は、残りの部分を読んでは、STDOUT に書き出すのを繰り返す。

まぁ…header を削除するプログラムは、 これ以上手の抜きようもなかろう…というわけでいいものとしましょう。 とりあえず(疑問があったらきっと聞いてくるだろうと言うことで)。

Program 2. record header attacher

Pealer を作ったら、Attacher を作るのが筋というもの。 任意の File に Attacher で Pdb header をつければ、 Database として WorkPad 上で参照できるようになる。 参照できるようになればこっちのもの。 WorkPad 上でいろいろ扱いようもあるというものである。

ここで重要な方針を立てる。曰く、
PDB header をつける ということと File の意味を理解して、適切に record 化する ということとは別の話である。

ファイルシステムがファイルの中身なんぞ知ったことではなく、 全部バイト列として処理するがごとく、 Attacher もファイルを「ファイル」以上の何者とも見なさない。 単なる一定サイズ毎にぶった切った record の羅列に変換する。 Attacher が作った database を適切に読み解くのは (つまり、普通のアプリケーションが File を解析するがごとく、 record を解析していくのは) WorkPad 上の Application の仕事であって、 Attacher のお仕事ではない、とする。

この割り切りを行う pdb file へのコンバーターは、 はっきり言って今のところ PDBHeaderAttacher.perl だけしか見当たらない。

そもそもが、Palm は record を「ただのバイト列」としてしか管理していない。
「OS が record のフォーマットなんぞ知ったことではない」
というのは極めて正しい選択なのだが application はこの record を直接参照することができるために、 application 側に欲目が出てしまっている。 結果、application 毎にフォーマットの異なる、 しかも application にとって非常に解析のしやすい固定ピッチの、 さらに言うならば Machine dependent で Compiler dependent な、 データベースフォーマット、というものが発生してしまっている。

この状態の何がそんなに悪いのか、について 計算機心理学(という言葉が嫌いであれば Computer Usability。 しかし XEROX Parc で開発されたもは計算機科学ではなく、 計算機心理学だ)的に 説明するのは極めて難しい。 非常に多くの場所に「人間が頑張れば」とか 「フォーマットコンバーターを導入すれば」と言った 例外処理を導入することができるからだ。 一方でメリットは明白で、 メモリスペースの省力化とアプリケーションの単純化が計れることは 幼稚園児にでも判るだろう。 このため、Palm Co. が出している様々なドキュメントでも、 この傾向は増長される傾向にある。

しかし、これは絶対に取ってはいけない方針である。 データとアプリケーションは明白に分離されなくてはいけないし、 アプリケーションが複雑になってでも データは可能な限り非固定長フォーマットで記述される必要があるのだ。

計算機心理額的に説明するのは複雑で面倒なので、1つの例を挙げよう。 specific なフォーマットを採用すると、 この例で起ったことと同質のことが あなたのアプリケーションにおいても生じるからだ。

例とは「2000年問題」である。

そもそも、2000年問題というのは、 『計算機が2000年を正しく判断できない問題』 の事ではない。 銀行などのデータベースに 2000年以降の処理を記述できない というのが 2000年問題なのだ。 それ以降に出てきた、「2000年になると時計が狂う」という問題は、 2000年問題なのではなく、 「チップをけちりすぎた結果生じたバグ」でしかない。 まずここを混同しないよう、指摘しておこう。

その上で。 では、なぜ「データベースに2000年以降の処理を記述できな」かったか? 答は簡単で、年のフィールドが10進数2桁分しかなかったからだ。 2桁しかないのでは、1900年代の分しか処理できない。

なぜそんなことをしたのか? このデータベースのフォーマットが決まった当時、 メモリもディスクスペースも、オープンリールテープも、 とても高かったからだ。 1970年代前半までのプログラマーにとって、 「技」と言ったら「メモリをどうやってセーブするか」ということだったのだ。 そうすれば計算機のコストが安くなるので、 利益率が増大する。 そう、当時は「プログラム」は「計算機」に付随するものでしかなく、 計算機を買うときには「プログラム付きで」買っていたのだ。

彼らはデータ構造を極めて「汎用に」しようとはしていた。 でなければ 10進数2桁ではなく、16進数2桁という値を使っていただろう。 この方がデータをより小さくできるのだから。

別に当時のプログラマーが2000年が来ることを知らなかったわけではない。 彼らはこう思っていたのだ:
「2000年までは 25年もあるじゃないか。 それまでにはこのプログラムはきっと時代遅れになっているよ」

彼らは半分だけ正しかった。 確かにプログラムは時代遅れになった。 確かに計算機そのものは時代遅れになり、破棄された。

彼らが間違っていた半分とは、
「確かにプログラムは破棄されたし、計算機も破棄されたが、データは残った」
という点である。 データが残ったのはそのデータを作った人たちが それを使い続けたかったからだ。 銀行などの計算機消費者は、 計算機を取り替える度に前の計算機に入っていたデータを全て破棄する、 などということには我慢ならなかったのだ。 なにしろ、そのデータこそが彼らの生命線だったわけだし、 そのデータを再入力するなどとんでもない話だからだ。 そんな人件費をどうしてかける必要がある? プログラムを適応させた方がいいじゃないか? 新しい計算機は早いのだから。

こうしてデータと、そのデータのフォーマットは生き残った。 年を表すフィールドは相変わらず10進数2桁で表現されていた。

不幸は、データを保存するためのリソース、 つまり HDD の容量と値段の低下速度があまりにも速かったことにある。 あまりにも速く、あまりにも廉価になったため、 電子取引は急速に広がっていった。 データフォーマットに問題を残したままで。 また、一方で電子取引は人間が常時作業するのと異なるため、 24時間の取引を可能にしてしまった。 システムが停止するのは正月の3ヶ日ぐらいなものになってしまった。

そして、ある日、誰かが気がついたのだ:
「おや?データフォーマットに問題があるぞ?」
そして別の人が気がついたのだ:
「おい、3ヶ日ではデータを書き換えきれないぐらい、データがあるぞ」
そして 2000年問題が騒ぎ立てられはじめたわけだ。

2000年問題は問題がもっとも広汎に発現した例だが、 もっとも端的に何が起るのかを示している。

• プログラマーが Application と Data を一体化して見ているとしても、 そんな見方をしているのはプログラマーだけである。 一般のユーザーはデータはデータ、プログラムはプログラムとしてみており、 application は交換しても data は交換したくないものだ。
• application の寿命で data の寿命を決定し、 そのフォーマットを決定するとえらい目にあう。

これらを総合するとこうなる。
「WorkPad 用のプログラムだからと言って、 データフォーマットを WorkPad でさえ使えれば良い、 などとしていると、後でしっぺ返しを食らう」

この観点で行くと、database という形式を選んだ PalmOS 自体、 十分な先見の明があったとは言えない。 pdb フォーマットも不適切と言える。

ただ、pdb ファイルは header を引き剥がしさえすれば普通の ファイルにすることができる。 当然その逆をやり、application でデータの解析を行うようにすれば、 問題は最小限に抑えられるだろう。

• 1 record 65024byte を最大値とする。(65024 = 65536-512) 512 の倍数にすることで、 Memory Mapped File と同様の感覚で操作しやすくなるだろう (本当は 4096 の倍数にしたかったのだが、無駄が多すぎる。 一方、65500 ではあまりにもギリギリまで使っていすぎて危険である。 そこで 65536-512 を選ぶことにした。妥協の産物だ…)。
• 『65024』という数値は固定とする。 1つにはこれがサンプルコードでしかないから。 もう１つには可変にしても意味がないから、である。
  65024 という大きさの record が有利である最大の理由は、 参照にしか使わないという理由による。 メモなどの書き込みや変更が必要な database の場合は、 「変更している最中は」もっと細かい、可変長単位での管理の方が有利になる。 例えば1行1record とか。 しかし、そのような状況を PC からデータを送る場合には気にする必要は ほとんどない。 PC から転送するデータはその多くが変更されることのない、 参照が主なデータである。
  また、変更が必要な場合も、 一時的に record を分割して変更に対応し、 変更が終わったらまた1つの record に結合し直せば良い。 つまり「細かい状態のままで管理し続ける方が良い」状態というのは あまりないのだ。
• 1 record の区切りに関して特に制限は設けない。 『直前の '\n' まで』とかそういうことは一切しない。 65024byte までは 1 record とし、 それ以降は次の record に記録していく。 これはたとえ「残り1byte」であっても同様に処理するものとする。 何度も言うようだが「フォーマット」に「意味」を与えるのは Application の仕事だからだ。
• Application Info, Sort Info ブロックは一切つけない。 これは、このプログラムによって作られた pdb ファイルは 特定の Application 専用であるという前提を持たないからだ。 これは持たせるつもりもない。
• 標準入力は受け付けない。が、ちゃんとチェックするわけでもない。 これは record 数等を決定するには入力ファイルのファイルサイズを 獲得する必要があるが、STDIN のサイズは決定できないからだ。
  もちろん標準入力からの入力の場合、 temporary file に書き込んでからそれを利用する、 という手も考えられる。 しかし、それは当 script file の外でも可能な処理だ。 であれば、当 script 自体がそのような処理を行う必要はない。
• resource database は作らない。 record database だけとする。 …これは簡単で、各 resource のtype など、 この方法では指定できないから。
• category = 0, secret = 0, busy = 0, dirty = 0, delete = 0 で record header を作る。 record ごとに category を指定しても意味はないし、 secret は欲しければ自分で変更して欲しい。 busy, dirty, delete は pdb ファイルの方でビット立てても意味ないし。 (つーか delete するんならその record は何のためにインストールするのやら)
• Database header は、 「適切に close されており」「file stream ではなく」 「copy 可能で」 「device をreset しない」 「open 中に install しては駄目」 「backup bit は on」「application info block は変更されておらず」 「read/write 可能である」ように作る。 また、application info, sort info は存在しないとする。 これらを変更したければ、自分でコードを変更すること。 もっとも、その価値があるオプションだとは思えないが。
• create time, modified time, backup time は全て 0x00000000。 これは基本的に時間計算が面倒だからだ。 これらを適切に設定するためのデータを供給させるのは、 かなり厄介。今の時刻が1904年1月1日から何秒目だか、簡単に判るかい?
• modified time は 0x00000000。
• 出力は stdout だけにしよう。
• 与えられたファイルに関する解析は行わない。 フォーマット変換もしない。 例えば MS-DOS(や Windows) では、改行コードが 0x0d 0x0a という 2byte である。Mac では 0x0d だけである。 一方 PalmOS や unix は 0x0a だけである。 当然、PalmOS に 0x0d 0x0a や 0x0d だけを与えても、 改行コードを自動的に適切に処理することはできないだろう。 しかし、それは nkf32 などを使って PC 側で変換しておくか、 あるいは Application 上で処理すべき問題であって、 このプログラムが対処すべき問題ではない。
• ファイルサイズが 0 の場合は database を作らない。

• --help でヘルプメッセージを出して終了するだけにしよう。
• --Name で database 名を指定する。 これを指定しないと database 名は 'Kirameki-Man'になってしまう。 (せっかく「タイムボカン」シリーズの新しいのが出ることだし…ね :P)
• --Version で database version を指定する。 指定がない場合、デフォルトでは 0x0000 になる。
• --ModifiedNumber で modified number を指定する。 指定がない場合、0x00000000 になる。
• --DatabaseType で database type を指定する。 ただし、これは 'file' のような「アスキーコード」ではなく、 数値でのみ指定できるとする。 指定がない場合、0xda7aba5e になるものとする (database の t を 7 で、s を 5 で置き換えたものやね)。
• --CreatorID で creator id を指定する。 ただし、これは 'file' のような「アスキーコード」ではなく、 数値でのみ指定できるとする。 指定がない場合、0xb1fcbbb3b になる。 (ちなみに、これは「奥山」を EUC で記述したコードである)
• - だけの場合は、それ以降は option ではないとする。 利用上、注意する必要があるのはファイル名に '-' (ハイフン１つだけ)を渡すと、それは stdin という意味になってしまう、 ということだ。 これは Perl の仕様であって、どうしようもないが、 これを指定してしまうと、正しく動かなくなる可能性がある。

コード全体を列挙するのはページの無駄なので さるぅんプロジェクト の PDBHeaderAttacher.perl から取ってきて欲しい。

プログラムのほとんどの部分は option 処理である。 見ての通り何のチェックもしていないので、 下手な使い方をすると破綻するだろう。

実質的な部分は run_attacher という関数にある。 と言っても、

• -e を使ったファイルの存在識別。
• stat()関数によるファイルサイズの獲得。 (これは Windows と unix ではうまく行くが、 他の OS でも同様にうまく行くかどうか、実は自信がない。 あるいは seek を使った方が良かったか?)
• int() を使わないと record 数が浮動小数点になる。
• pack()関数を使ったイメージの実際の作成。

という事以外はあまりにも「そのまんま」なコードなので解説は ほとんど要らないだろう。 説明が欲しい人はメールを欲しい。 人数が多ければ考えるが…普通要らないよね? (コードを組むのにかかった時間も1時間だし、 そのうち40分は usage() にかかっているていたらくだ)

このプログラムは、単にサンプル以上の意味が、実はある。 このプログラムができたおかげで、 unix でいう.ほげほげrc ファイル相当の database が作れる。

.ほげほげrc というのは、 unix を使っている人にとっては簡単に理解できるだろうが、 『ほげほげ』というプログラムにとっての「設定ファイル」である。

このファイルがいつからこのファイル名になったのかは判らない。 おそらく、BSD unix の .cshrc が始めてではないか? と思われるが確証はない。誰か知ってたら教えて欲しい。

unix のプログラムは大抵の場合、 起動時にまずデフォルトの設定というのを持っているが、 それを「設定ファイル」というもので置き換え、 各ユーザーの好みにあった動きをするようにチューンできる。 unix はマルチユーザー OS なので「特定の人の好みに合わせたバイナリ」 というものを用意するのは現実的ではなかったのだ。

また、このファイルはテキストファイルであった。 このため、変更のために専用のツールを必要とせず、 移植が容易であり、 最終的に unix の強力な移植性と unix 間での環境移動のしやすさをもたらした。

テキストファイル処理に伴うオーバーヘッドが問題とされなかったのは、 決して unix マシンが resource が十分あるマシンだからではない。 実際、初期の unix マシンには 64kbyte のコードサイズと、 64kbyte の 作業用 RAM 領域しかないもの(これでも「贅沢」なのだが) がほとんどだった。 このサイズは PalmOS のメモリ量以下なのはすぐ判るだろう。 つまり、当時のマシンに可能である以上、 PalmOS にとってもこの構造は決して「贅沢」な使い方ではないはずだ。

では、なぜテキストファイルだったのか。 それは「使いやすさ」のためだ。

バイナリファイルによる設定ファイルに専用の設定ツールを作ると、 そのアプリケーションもまた設定ファイルを必要とし、 その設定ファイルのためにまた設定ツールが必要になる… これは無意味な無限ループを作り上げる。

各アプリケーション自体に設定変更機能を追加することは可能だが、 それはアプリケーションを増大させ、 結果として「ある一定の code size restriction」の中で 実装可能な機能が制限されてしまう。

結果、「汎用的なバイナリファイルエディター」と 「汎用的なテキストエディター」のどちらかを使って 設定ファイルを作るようにするしかなかったのだ。 そして、「汎用的なテキストエディター」はこの必要性以外でも どのみち必要とする。 であれば、テキストエディターだけで十分だ、と言うことになる。

この判断ルールは全く同様のことが PalmOS についても言える。 汎用のテキストファイル(というかテキストファイルを database 化したもの) で設定を記述することができれば、 アプリケーションごとに設定プログラムを作る必要も、 アプリケーション内に設定変更機能を追加する必要もない。

テキストによる設定ファイルが作れる、と言うこの条件はさらに、 locale ファイルを作成することで localize 処理をも簡単にする。 J-OS の Localizer は既存のアプリケーションを各国語対応できるという 意味では有能だが、 アプリケーションを最初から多言語対応に作ろうとする場合には これだけでは不十分である(PalmOS の機能の方がこれでは不十分なので、 Localizer にも限界はある、という意味だ)。 結局多言語対応はアプリケーション設計段階での対応を必要とし、 その作り込みには locale ファイルを必要とする。

「設定ファイル」も「locale ファイル」もユーザーが自由に 変更しやすいテキストフォーマットであれば、 より自由で使い勝手の良いアプリケーションを作り上げることができるだろう。

Program 3. database splitter.

1つの database を 1つの file にする方法と、 1つの file を 1つの database にする方法が手に入ったら、 次は 1つの database を複数の file にする方法と、 複数の file を 1つの database にまとめあげる方法が必要になる。 つまり、record ごとの分解と再構成のためのツールだ。

1つの database を record 単位に分解する perl script として、 split-pdb.perl というものを作ろう。 正確には「作り直そう」。 これは旧来 apart-pdb.perl という名前だった script を直す、という意味だ。 2000/02/14 現在の apart-pdb.perl は prc ファイルに対して 正常に処理を行うことができていない。 これを直してしまえば、prc/pdb ファイルの別なく、 全ての database ファイルを分解することができる。

この split-pdb.perl はもうひとつだけ欲目を出そう。 join-pdb.perl というファイルをこのさらに後に作るわけだが (そしてそれはバラバラのファイルをそれぞれ record として 登録するものになるわけだが)、 フォーマットを互換性のあるものにしよう。 つまり、split-pdb.perl で分解したイメージはそのまま join-pdb.perl で同じイメージに再合成可能なようにするわけだ。

その代わり、1つの犠牲を払おう。 split-pdb.perl はこれからデザインするわけだが、 既存の split-pdb.perl の出力と互換性を持たせることは考えない。 いや、最終的に互換性があっても構わないのだがその事にはこだわらない。

split-pdb.perl の出力は、1 record data image に対して 1 file とする。 この record data には application info, sort info も含める。 従って、database header, record header をどこか別の所に出力し、 そこには record data image file 名の情報が追加されるべきである。

この段階で、record image は stdout のような標準出力へは 出力できないことになる。 そもそも1つのものを複数に分配するのだから、stdout のような1つしかない 「口」では役不足なのは明らかだ。 そこで、「database header, record header」を stdout に出力し、 record image は「split-pdb.perl 指定の」file naming rule で 出力することにしよう。 これで、問題になるのは stdout で出力するファイルのフォーマットだけになる。 以後、これを「出力ファイル」と呼ぶことにしよう。

出力ファイルはテキストファイルとする。 テキストファイルは『perl がテキストと認識できるもの』で書かれている ものとする。つまり今後出てくる「空文字」や「改行」、「行末」は それぞれの perl に依存するものとする。 特に「改行」文字は OS ごとに異るので、 perl にお任せと言うことにする。

出力ファイルにはコメントが書けることにする。 コメントは # ではじまり、その行末までをコメントとする。 コメントは処理の最初に削除され、 「単なる改行コード」と同じ扱いになることとする。

perl において、正規表現で /^\s*$/ で表される行 (この中にはコメントを削除した後に上記正規表現にマッチするものも含む) は、 「空行」と等価であると仮定する。 これはつまり全角の空白「　」だけの行は「空行ではない」ということでもある。

pdb ファイル名やファイルサイズなど、 直接的には関係のない情報は全てコメントで記述することにする。 これには、record offset のような、 「分離後は価値を持たない」 情報も、 「record size」のように直接はしていされていない情報も、 含めることとする。

database header は

Database {
    .....
}

で囲まれるものとする。 重要なポイントは、 Database { はこれ単体で1行、 閉じる方の }も単体で1行でなくてはならない、という点だ。

record header は

Record {
    .....
}

で囲まれるものとする。 Record { もDatabase {同様これ単体で1行、 閉じる方も同様である。 Application Info, Sort info はそれぞれ Application { Sort { も同様である。

Database や Record の各要素は基本的に

    version    12345

のように \s*<name>\s+<value>\n の組で成り立つとする。

value が数値の場合、表現は4通りあり得るものとする。 0 以外の数値ではじまる場合、それは 10進数であるとする。 0b ではじまる場合、それは2進数表現であるとする。 0x ではじまる場合、それは16進数表現であるとする。 0 ではじまるそれ以外の場合は 8進数表現であるとする。

value が文字列の場合、'.... ' のように ' で囲まれているとする。 さらに、文字列の中に ' を含める場合は\'と、 \ を含める場合は\\と表現するものとする。 \xab のように \x ではじまると、
次の2文字と合わせて4文字で 1byte を16進数で表現されているものとする。 さらに、0x09 を \t, 0x0a を \n, 0x0d を \r で表すものとする。 つまり、database 名は完全に1行に収まる。
基本的に non ASCII 文字コードは、すでに出ているコードを除いて 16進表現で表すこととする。 ただし、\x00 だけは「database 名の最後の文字コード」として、 表示しない。
また漢字での表現はしない。 これは、sjis,jis,euc,unicode,ebcdic などを処理するのが面倒すぎるからだ。 勘弁してくれ。

value が bit field のように 1, 0 の場合、 各ビットごとに 1 の場合、0 の場合の記号が定義されているとする。 その意味はコメントで書かれているとする。 1,0 では定義しない。 どっちがどっちやら…という状態が発生すると厄介だからだ。

Database は空行を除いて、最初に定義されていなくてはいけない。 Record は Database の後に「record 0 から順番に」定義されてなくてはいけない。

name は順不同で並ぶ。 1つの group の中で同じ名前の値が複数回定義されてはいけないし、 複数回定義しない。 また、定義が不足している、という状態が起こってもいけないし、 起さない。つまり「デフォルト」という状態は存在しない。

Application, sort, record data のそれぞれが、 サイズ 0 の場合、data を書き出すファイルを作らない。 この場合はファイル名は「空」になる。 '' ではなく 「なんもなし」 になる。

こんな感じかしら?

プログラムコードは さるぅんプロジェクト の split.perl から獲得して欲しい。

split.perl <pdb file> <file output directory>

が正しい起動方法とする。 これ以外の方法で起動した場合、あるいは pdb file がない、 file output directory が見つからない、 などの場合はヘルプメッセージを出力して終了する。

option は存在しない。 --help すら用意しない。 そうすればファイル名指定とかが楽だからね。

pdb file 名に - を指定すると(perl のルールに従って) stdin になる。 - というファイル名は使えないとする。

同様に file output directory 名に - は指定できない。 さらに、file output directory はすでに存在してなくてはいけない。 split.perl が利用するファイルと同じ名前のファイルがすでに存在する場合、 そのファイルは単純に上書きされる。 既存ファイルが保存されることはない。 もし既存ファイルが書き込み禁止であった場合、 そこで動作はそこで停止する。

最後につくらなくてはいけないのは、 split.perl の逆をするプログラム、 つまりバラバラになっているバイナリファイルを1つの prc/pdb ファイルに 組み立てるプログラムだ。

Prev 1 , 2 , 3 , 4, 5 , 6 , 7 , Next

このページに関する コメント、情報、誤りなどの情報がありましたら、 奥山 まで。

2000-07-14 やっとこさ、split.perl ができた。
でも join.perl がまだ全然… こいつが完成せんとこのページは終わらないというのに。