こんばんは、川合です。
余興で始めたsarですが、実は昨日のうちから余興の範囲を脱しつつ
あり（Z-SlashによるとZAKKYさんには見抜かれつつあるようですが）、
いろいろ小細工をやっています。
sarはそもそもtarの代用としてスタートしましたが、sarでプログラ
ムを1ファイルにまとめると、当然tarでまとめるよりも小さくなります
（無圧縮の場合）。いや、圧縮しても、その差がうんと小さくはなるも
のの、やはり元が小さいsarのほうが若干小さくなります。
一方、僕はOSASKのアーカイブ機能でSF16を使った仕組みを採用しま
したが、SF16によるアーカイブはtarの何倍も無駄があります。どんな
に小さいファイルでも320KB以上になってしまいます。たとえば、
kdun00bは無圧縮状態では640KBになっています。全部のファイルサイ
ズの合計は223KBでしかないのにもかかわらず、です。これが圧縮後の
サイズに多少の悪影響を及ぼしていることは想像に難くありません。
これをsarにできたらなあ、と思うのは自然な発想です。しかし、僕
は僕なりの信念があり、アーカイブ形式というものは、かならずディス
クイメージであるべきです。ディスクイメージとして使えないようなア
ーカイブフォーマットは結局駄作なのです（tarをファイルシステムと
して使えるOSは多分無いと思いますが、つまりそれはtarのフォーマッ
トが、ファイルをくっつける以上の特徴を持っていないせいだと思いま
す）。LHAもZIPもアーカイブ機能を持っていますが、OSのファイルシス
テムとして使われるという話はなさそうですので、フォーマットがあま
り良くないのでしょう。・・・僕はファイルシステムにもアーカイブに
も使えるようなフォーマットの存在を信じていて、それに到達したいわ
けです。SF16は互換性という点で最強のアーカイブフォーマットです。
で、要するに僕はsarをディスクイメージにも使えるようにしようと
しているわけです。ディスクイメージフォーマットをそのままアーカイ
ブフォーマットに採用するという今までの発想ではなく、アーカイブフ
ォーマットをディスクイメージフォーマットに拡張しようというわけで
す。このsarフォーマットはもちろんCFとかに使ってもいいですが、サ
イズの大幅な変化に対応しにくいので、CD-Rのようなデバイス向きだろ
うと思っています。
ディスクイメージとなるとまずKHBIOS対応が真っ先にあって、KHBIOS
情報を格納できるようになっていなければいけません。ということでフ
ォーマット的に配慮しました。あとはセクタサイズにあわせてアライン
可能にしたり、ファイル属性に多少の柔軟性を持たせたり、パーミッシ
ョン属性を作ったり、更新日を秒よりも細かい単位で記録できるように
して、さらに年は可変長でいくらでも書けるようにしました（というか
前バージョンからそういうフォーマットにしてありますので、互換性が
あります）。
また各ファイルの後ろに任意の余白をいれて、ファイルサイズが大き
くなることに備えることもできるようにしてあります。ファイル名も可
変長で、どんなにロングなファイル名でも問題ありません。ファイル名
には0x00や改行コードなど、ありとあらゆるバイトを使用可能にしてお
いたので、単純2バイト系文字コードや4バイト系などでも、問題は生じ
ません。
SF16とはことなり、ディスクイメージ容量やファイルサイズにも一切
の制限がありません（SF16は最大2GBまで）。どんなデバイスとも相性
がいいと思います。
・・・詳細はこの際どうでもいいのですが、とにかくsarはディスク
イメージにそのまま転用できるようなフォーマットになっていて、将
来はOSASKやDOSASKから、ディスクやメモリカードをこのフォーマット
にしたり、それを読み書きしたりできるようになるでしょう。フォー
マットはSF16と同等かそれ以上に単純なので（だからsartolはコンパ
クトなわけですが）、サポートも容易になりそうです。
さて、ではOSASKが解釈できるsar形式のディスクイメージを作る方
法です。
prompt>sartol e kdun00d.org . !Atmark! -4k ARCINFO0.TXT KDUN00A.BIN KAODUN.BG KAODUN.CHR KAODUN.ETC
一番違うのは、今まで1にしていたところが「@-4k」になるところです
。この意味は、@が「tek圧縮されているものについては自動解凍してか
らアーカイブに加えよ」という意味で、-が「KHBIOS対応にせよ」とい
う意味です。4kは4KBアラインをさせるためのもので、これはOSASK側の
事情で、4KBアラインが無いと次バージョンでのサポートがつらいので
、とりあえず4kを指定してください（このせいで多少の無駄ができます
が、SF16_40sのときの比ではありませんのでご安心ください）。
ファイル名は必ず大文字で指定して、しかもARCINFO0.TXTを先頭にす
るのを忘れずに。sartolもedimgのように設定ファイルで書けたほうが
便利そうですね。次のバージョンでは検討します。
これで作ったkdun00d.orgは、640KBではなく232KBになります。64%の
削減です。圧縮した場合の展開速度もちょっとは速くなります。
圧縮後のサイズで比べると、81バイトの差になります。tek5の強力な
圧縮力で差し引き408KBの差は81バイトにしかならないわけですが、ま
あわずか81バイトだって小さくなる分には歓迎です。
なお、まだベータリリースすらしてない手元のOSASK開発版では、sar
+tek5のkdun00d.binが元気に動いています。もちろん、SF16+tek5や、
sar+tek2など、どんな組み合わせでもOKです（全部の組み合わせを試し
たわけではないですが、うまくいくはず）。
さらに、今回のsartolはtek展開ルーチンにASKA版を使ってみました
。そのおかげで@-4kのサポートで機能が増えたのに、exeのサイズは512
バイトほど小さくなって、5.5KBになっています。たぶん展開速度も上
がっています。Linuxユーザや非x86ユーザのために、C版の代替ソース
も一緒に入っています（int幅やエンディアンに依存している部分があ
りそうなので、結局今のままではx86以外では手を入れないといけない
かもしれませんが）。
http://k.hideyosi.com/sartol0b.lzh (19.1KB)
しばらくはやりませんが、そのうち一般公開以外は、lzhなしでsar
オンリーとかにしちゃいそうです（テスターの皆さんに導入を促すた
めに）。
それでは。
--
川合 秀実(KAWAI Hidemi)
OSASK計画代表 / システム設計開発担当
E-mail:kawai !Atmark! osask.jp
Homepage http://osask.jp/