Warpっぽくいこう

INFの「文書」についての部分 (下) -- '99.6.11

前回までの部分をアレすると, これでよーやく文書を組み立てることができたりする。 それから, Rexxのページでのソレ ってのも参考になるかも。
で, 今回は 拡張コードと呼んでいる部分についての解説だよん。

文書の中にこつ然と姿を現すソレは, まるで HTMLのタグのよう。 ってなこと前にも書いたような気がする。 ソレがどーゆーものかは, inf2hを使うと確認できるかも。 inf2h -ctrl \os2\book\os2ug.inf ・・・ みたいな感じで。

そのバイト列(拡張コード)は, 0xffから始まる訳だけど, 構造としてはそれなりに単純。 0xffの次に, 1バイトの長さ, 1バイトの ID, (存在するなら)その値 ・・・ そんなとこ。

◇

さて, INFファイル研究の専門家としては, (← ないって, そんなの)
それら拡張コードのパターンてゆーか, これまでに発見したすべてのソレを列挙しておいた方がよいかもね。

う, まとめているつもりだったけど, まったくまとまってないね。あはは。
このほかにも少し分かっている部分もあるんだけど, これ以上アレすると, 落書きなのか何なのか分からなくなるので, ちょっち控えてみる。

INFの「文書」についての部分 (上) -- '99.5.27

以前公開した INFファイルヘッダーに, 項目を追加してみよー。 それは, オフセット 0x44 からの 単語辞書の情報だよん。 つまり, 今まで秘密にしといたブツな訳だ。エヘヘ (^^;

ヘッダーに含まれる情報によって, 各種の項目を自在に取り出したりできる訳だけど, でも, 取り出された情報も何らかの構造を持っている。 しかも読み手を拒絶するかのよーな意味不明さ。 (←このページもね)

◇

これまでの情報で, どんなことが分かるのだろう。どれだけのことが可能になるのだろー。
INFファイルのタイトルは, ヘッダーにその物ズバリ入っているからアレだとして, 各ページごとのタイトルは, content情報の中に content titleてのが入っている。 あとはその文書内容だけだよね。 そして, その文書内容に関係ありそーなのが, 文書テーブルと呼んでいる部分と, 単語(または文字)辞書と呼んでいる部分。
そう, 文書に簡単にアクセスするのなら, 文書テーブルの部分は 1項目 4Bytesなので, ある番号を添字にその項目を取り出し, 指し示された位置にあるとこからアレコレするだけ。

んじゃ, ページ番号を添字に 文書を取り出すことは可能なんだね ・・・ とか思うかもだけど, ソレはちょっと違う。 ページ番号を添字に, content情報を得ることができ, その中にある 項目番号てのを添字に, 文書テーブルから文書の位置を取り出すことになるのだ。ややこしいね, まったく。
だから, 短いページなら 項目件数は 1で, 文書テーブルからひとつ取り出すだけ。 長ければ, いくつものソレを取り出さなければダメ。

そして得た, そのページの文書の位置。 そこから文書が始まるのかと思いきや, 果たしてそこには まったく意味不明の Byte列が並んでいるだけ。

ローカル辞書とか勝手に名前付けたけど, そんなものでも何でもないのかも。もっとよい名前があったら変更するかも。 で, 件数てのは, そのローカル辞書の件数。

◇

さて, ここから 単語(または文字)辞書と呼んでいる部分, そして, いましがた出てきた ローカル辞書てのを駆使することになるのだ。
(↑)でゆーところの, 文書の長さと バイト列, そこから得られるブツが実際の文書なんだけど, その部分は, 1文字＝ 1バイト(あるいは 2バイト) ではなく, 1単語＝ 1バイト, なのだ。

で, 単語(または文字)辞書の構造は とゆーと, 長さ, 文字列, 長さ, 文字列, ・・・ の繰り返し, で 長さは 1バイト。 てことで, 配列のよーに数値を添字にして単語を選ぶことができる, ごく単純な構造な訳よ。
でも, 文書は 1バイト単位。 ソレがそのまま単語配列の添字になっている訳じゃない。 だって, そのままでは 256種類の単語の組み合わせの文章にしかできないもんね。

その間を埋めるものが, ローカル辞書とか呼んでいる部分。 バイト列をひとつひとつ取り出し, そこからローカル辞書の項目を選び出し, さらにそこから単語配列の項目を選び出し, 文章が紡がれていく。
その, ローカル辞書は, ひとつの項目あたり 2バイト。 そう, 単に単語配列の添字になっているだけ。

これで完了かとゆーと, そーでもなかったりする。 文書のバイト列には, 特殊なコードが埋め込まれていたりするのだ。

• 0xfa ・・・ HTMLの Pタグのようなもの。
• 0xfb ・・・ HTMLの CENTERタグのようなもの。
• 0xfc ・・・ スペースを組込む／組込まないの切り換え。
• 0xfd ・・・ HTMLの BRタグのようなもの。
• 0xfe ・・・ 強制(？)スペース。
• 0xff ・・・ 拡張コード (と, 勝手に呼んでいるシロモノ)

◇

コレを書いたときの号の OS/2 Worldに, INFファイルをテキストに変換するプログラムが付いてきたりして。 むむっ, 挑戦する気だなっ。 (← 違うって)
でも, 情報量としては, σ(^^) のが多いね。 そのプログラムには, INFファイルヘッダーで, １項目抜けがあるし, ↑の 0xfcについての処理もない。 さらに, 拡張コードについての部分も ・・・。 逆に, こちらに足りなかったものは見つかっていないし。 フフフのフ, 勝ったかも。(←張り合ってどうする)

オンライン文書ファイル, part (2) -- '99.2.25

*.INFファイル構造の そのつづき。ふと思ったんだけど, なぜ「オンライン文書」なのだろー？ help viewとすると, オンライン文書の表示 とか, そんな説明になっているけど, オフラインでは読んではいけないとでもゆーのだろーか。・・・ な訳ないね。

◇

INFファイルヘッダー部分の構造は(一部)アレしたけど, でもその後には？ そう, そこには複雑に入り組んだ情報が, 雑然と そこかしこ いたるところに転がっていて, 何が何だか訳ワカメ状態なのら。 なーんて。 収集付かないのはこの文章の方だね。 (^^;
で, すべての情報はヘッダーの各項目から指し示されていて, だから, ファイルの中での位置とか順番には何の関係もなさそう。 ファイルに対しランダムアクセスできる言語であれば, 必要な項目のみを抽出するのは, いとも簡単 ・・・ なのかな。構造さえ理解できれば。

てことで, 前回ゆってなかった部分について, いくつか取り上げてみ鯛鴨。 (←ぉぃ)

☆ まずは, コードページとかの情報について。 その位置から, その長さ分のバイト数 格納されている訳だけど, そこの領域の構造は, 長さ(2), ID(2), 情報(残り) とかゆーのが繰り返し入ってたりする。
それぞれの項目は, 長さにはそれ自身も含めての長さが, IDとその情報とゆーのは こんな(↓)感じ。

• 0x0000 ・・・ バージョンみたいなもの, CountryCode, CodePage ・・・ それぞれ 2Byte ずつ
• 0x0101 ・・・ Word(？) (ソースファイルで指定したものだったはず)・・・ それぞれ 2Byte ずつ
• 0x0102 ・・・ よくわかんないや。てへっ (^^)＼(バキッ☆)

☆ 次は フォント情報について。 INFファイルヘッダー にはその位置情報しか含まれていないっぽい。 と, ゆーのも, その場所から始まるとこに件数と位置が入っているから。 ポインターのポインターみたいな感じになっていて, 件数(2), 位置(4) の合わせて 6Bytesのエリアを ヘッダーが指してるってことだね。
で, そこから示される領域の 1件当たりの長さは 39Bytes ・・・ これは 33Bytesの名前と, そしてその後に 2Byteずつ幅と高さ(逆だったかも), そして何だったか忘れたけど あと 2Bytesが入っている。

☆ そして 変換文字列？について。 でもコレ, 使い方分からないんだよね。 (T_T
構造は 文字列域の長さ(1), 不明_1(2), 不明_2(2), 文字列域。その繰り返し。 そして, 文字列域は, その中に二つの文字列が入っていて, 文字列(A)の長さ(1), 文字列(A), 文字列(B) ってな感じ。

◇

なんだか取りとめもなくアレしたところで, ・・・ バイちゃ (^o^)/~

オンライン文書ファイル(*.INF)の構造 -- '99.2.5, '99.2.10

Dr.InfMan からの挑戦状。『わっはっはっ, キミはこの謎を解くことができるかねー』。 (← って, 訳わからん)
ちなみに, Dr.InfMan てのは Dr. Dialog で作った, INFファイル管理(マネージャー？)ソフトで, 「ドクター なんとかマン」てゆー名前から想像する類のものではありません。 (←て, 何だよソレ)

◇

*.INFファイルといえば, 古くからその形式でのドキュメントが出回っているらしく, なにやら ソレ形式の週刊誌だか月刊誌だかもあったらしい (今もあるのかしんないけど＆日本じゃないけど)。
HTMLが広まる前, ハイパーリンクといえばこれだった ・・・ のかも知れない (違うかもだけど)。

HTMLのよーなもの, とは言え, ファイルの中身はバイナリ。 とてもじゃないけど, 何書いてあるのかさっぱし。 grepで文字列を探し出そうとしても, ヒットする気配 まるでなし。 これじゃ INFファイル 作る方も大変かもね。 って, もちろんそんな訳なくて, れっきとしたツールが存在する。しかも J_Pocket (Warpの CDに付属しているおまけみたいなブツ) に。

その手順は, HTMLの亜種みたいなソースを(作って)用意し, ソレをコンパイラーつかトランスレータに与えるだけ。 「HTMLの亜種」つったけど, もしかしたら HTMLはコレを参考に考えだされたのかも, みたいに似ているし, 時代(？)が違う。 昔はリアルタイムに レンダリング できなくて, だから構文的に間違いもない 2進数形式に, って感じだったのかも。

んで, そのソースファイルの記述方法は 付属の(どれだったかの) CD-ROMに入ってたりする (INFファイルで提供されてたはず)。 もちろん変換手順も。 だけどしかし, できあがった INFファイルの, その形式についてはどこにも記されていない。
ま, 当たり前かもだけど, ちょっち残念。 表示する OSによってもその形式は(もしかすると)異なるのかも知れないし, そんなものかもね。 そーいや, 古いところに新しく追加された形式 らしいものもあって, バージョンによっても違うのかも。

◇

INFファイルのヘッダーは こんな感じ。そこにある名称は σ(^^) が勝手につけたものなので, ほかのINF Viewer開発者に「文書テーブル」とかゆっても, 伝わらない可能性が高いかも。

で, (↑)では分かりにくいcontent-tableてゆー部分を, ちょっち補足。 ココが指している部分は, こんなイメージ。

content-table
□□□□
□□□□
□□□□
□□□□
 〜 〜
□□□□

左側は, content-table 位置が指している内容。4 Bytesのポインター × content数。それぞれが指し示しているのは, content情報 (↑は ひとつしかないけど, 複数あると思ってくらはい)。
んで, ひとつひとつのcontent情報は, 長さが可変だったりする。 文字列が含まれているからってだけじゃなく, フラグによって項目があったりなかったり, そーゆーのがいくつか含まれているのだ。

まず, 拡張フラグと記している部分からして, あったりなかったりする。 レベル/フラグの該当する bitが ONのとき, その項目が現れるのだ。 そしてさらにその 16bit(2 Bytes)の内容によっては, またいくつかの項目が増えたりする。

レベル番号とかゆってるとこは, Tree構造になっている contentの, その階層のこと。 で, bit5 が ONなら, content情報に拡張フラグが含まれるってことだね。
こーやってまとめてみると, 結構複雑な構造してるよね, INFファイルって。 我ながら, よくこんなの分かったね, とかゆってみたくなる。誉めて誉めて, みたいな。 (← アンタは犬か)

てとこで, 次は 拡張フラグ(のビット構成)について。

0. 位置(x,y) (+5Bytes)
1. 幅・高さ (+5Bytes)
2. viewport
3. 属性 (+2Bytes)
4. nosearch
5. noprint
6. ctrlarea (+2Bytes)
7. tutorial
8. clear
9. (不明)
10. group情報 (+2Bytes)
11. autosplit
12. (不明)
13. (不明)
14. (不明)
15. (不明)

autosplitだとかの名称は, たぶん, ソースを記述するときのタグ名だったはず。違うかもだけど。
項目の後ろに括弧付きでバイト数が記されているのは, この拡張フラグの後ろに, そのよーな情報が付くとゆーこと。 そしてそれが同時に現れたばーい, bitの小さい順から現れるよーになっている。 bit0と bit1が ONなら, こんな感じ。 拡張フラグ + 位置(5Bytes) + 幅・高さ(5Bytes) でも, bit6 と bit10 の情報のばーいは, なぜかソレが逆で, bit10 の情報が先に現れたりする。

こーゆーアレだから, content titleの文字列まで到達するのは なかなか大変かもね。 で, 拡張フラグの後にも さらに項目番号とゆー これまた, 可変長の物体が出現したりする。でもコレは, 単純に項目件数の 2倍の長さだからソレほどでもないかも。

◇

Dr.InfMan ・・・ それは, こーゆー部分を処理しながら, けなげにcontentを表示してたりする。 だから変な動作をしたとしても, 笑って許してね (^^)＼(バキッ☆)