■以前より簡単になったデータ構造の把握

ザウルスもPIシリーズの時代は内部構造に関してシャープさんの鉄のカーテンの向こうとも言える程情報が少なく、ZauBASEなどの対応プログラムを作成する場合にはデータを多数作成してその規則性からデータの構造を推測していました。

MIシリーズもカラーザウルス、初代パワーザウルスの時代は鉄のカーテン的なものがあったのですが、ＭＯＲＥソフト開発環境であるCE-KT5のマニュアル等からデータ構造に関する情報が読みとれるようになりました。

今回のフォトメモリデータファイルの解析にあたってもSZAB(最新のMOREソフト開発環境)に付属しているAPIやクラスライブラリリファレンスといったマニュアル上に記載された各種情報から基本的なデータ構造情報を導き出しています。

また、ＭＯＲＥソフト開発業者向け（CE-KT5/SZABユーザー）に対して公開されているZaurusユーティリティを使うとデータの構造が把握できます。

Zaurus Utilityによるファイル構造表示 これを見るとファイル構造が一目瞭然です。 この情報とバイナリエディタを使って実際のファイルダンプデータを見れば削除フラグに関する情報も把握することができます。 このデータは手書きした画像のものです。 ここから読みとれる点は本来の画像以外にフォトメモリリストで表示される縮小画像「サムネイル」も同一レコード上に存在しているという点です。

■ファイルの構造

フォトメモリの画像データは"PAINT1.BOX"というファイルに書き込まれます。

このファイルを操作する場合には「レコード」と「フィールド」に関する構造の把握が必要になります。

ファイル、レコード、フィールドの階層関係は以下のようになります。

レコードを構成するフィールド情報に関しては上記のザウルスユーティリティで把握できますが、ファイルにはこの他にファイル全体の情報を持つヘッダやチェックサムなどのフッダに関する情報もあり、それぞれの位置関係を正確に把握しないとデータの復元はできません。

もし、不正確な情報でデータを変更するとアプリケーションが暴走する事もあります。

■この段階でわかっていること

SZABマニュアルなどから"*.BOX"ファイルの構造とレコードチェーン（レコードの前後関係）に関する情報はある程度把握できています。

これはAPIマニュアルにおけるZDAMやデータマネージャの関数群の記述、データ構造体の記述から読み取ることができます。

完全に把握したわけではありませんが、"*.BOX"ファイルではファイル上にインデックスに該当するものは持たず必要に応じてインデックスを生成して表示に利用すること、"*.BOX"ファイル内では各データに「前のデータ」「次のデータ」に関する情報（ID)を持つこと、データが無い状態は"0000h"、最後のデータは"FFFFh"となることなどがわかります。

・ファイルが削除された場合

ファイルが削除されるとそのレコードのID情報は"0000"になります。

同時にそのレコードの前のレコードに設定されている「次のレコード」情報が削除されたレコードに登録されている「次のレコード」のものに置き換わります。

同様に削除された次のレコード上の「前のレコード」情報も置き換わります。

この更新によりデータのチェーン状態が維持されます。

・削除前

・レコード２を削除すると

　概念的にはこのような状態になります。（1998/12/08 19:30時点での見解）

■実際のデータを検証してみる

マニュアル等から概略が把握できデータ復活に関するポイントも推測できるのですが、マニュアルからだけではファイル全体としての位置関係が今ひとつ把握できません。

そこでデータの削除前の"PAINT1.BOX"と削除後の"PAINT1.BOX"の違いを検出するプログラムを作成し、変化する部分の把握を行います。

また、データファイルサイズを変化させデータヘッダやフッダの構造などを類推してみます。