ことの始まりはKHBIOSの開発時。さまざまな理由からKHBIOS内に収納できるバイナリ圧縮形式が必要になった。
Kタンは様々な形式を試したようだが、技術・ライセンス・サイズ・性能等の理由から、どうもピッタリとハマルものが見つからなかったらしい。(帯に短し、襷に長し、歩く姿は百合の花)
そんなわけで、OSASK計画独自の圧縮形式の研究が始まりました。
Tekは圧縮アルゴリズムという色合いが強い。zipやLhaのようにアーカイバ用のものではない。(もちろんそういう運用も可能ではあるだろうが)
そのせいか、単独での ???.tek という形でなにかが配布されたりしたことはない
間違い。OS自作入門付属のz_tools内に空のディスクイメージであるfdimg0at.tekらがある
OSASKのAPIやbim2bin等に内臓されているという用途が主。
その意味においてはUPXやDOSのDietに近い感覚・・・と思えばいいかな?
OSASKやはりぼてOS等にはこれを展開して読み込むAPIが装備されているので、使う側はそのファイルが圧縮されているのかそうじゃないのかを考える必要がなく、単純に小さなファイルを扱えるというだけになると。
なので、Tekそのものには複数のファイルを圧縮してひとまとめにするという機能が載っていない。
Tekの後ろに付く番号はバージョンではないです。開発・試作された順に振られているだけで、内部は別のものと考えるほうがわかりやすいです。
Tek0を改良したもの。汎用性を重視? 結果、「大きなファイルではTek1が有利だが小さいファイルはTek0のほうが有利」的な性格が出てきた。(改良によってずいぶん改善したが)
2004年5月頃にTek0に変わってbim2binの標準アルゴリズムになった。
Tek0との上位互換等はありません。別の形式です
Tek1は対象ファイルによっては極端に不利になることが判明。
http://oldml.osask.net/oldml/200405/msg00029.html
これを改善した版。
どうやらうまくいったらしく、Tek0、Tek1は互換維持以外は廃止的な扱いとなった。
2004年5月頃登場。
同じくTek0・Tek1との上位互換等はありません。
tek0は推奨されない。(過去の互換維持のみが目的)かといってtek2はOSASKでは自動展開してくれないという問題点を解決するための新形式。2004年6月くらいに登場。
http://oldml.osask.net/oldml/200406/msg00011.html
bim2bi4iに搭載。
同じくTek0・Tek1・Tek2との上位互換等はありません。
さらに進化。・・・のはずだが、どうもうまく性能が出ない。
http://oldml.osask.net/oldml/200407/msg00000.html
Tek4の改良が進むが、ここで各々の性格や特徴を生かして独立させるべきでは?という話になってきた。
Tek4という新形式でなんでもまかなえるようにするのではなく、小さいファイルはTek1を使う・画像ファイルはTek0を使うみたいにうまく使い分けて性能を向上できないだろうか?という考え
http://oldml.osask.net/oldml/200407/msg00000.html
http://oldml.osask.net/oldml/200406/msg00016.html
しかし当然問題点もある。こんなに形式がいっぱいあるのは果たして良いことだろうか???
同じくTek0・Tek1・Tek2・Tek3との上位互換等はありません。別の形式・アルゴリズムです
さらに進化したが、ランセンス的に少々ややこしいことになってしまった。
tek5の圧縮ルーチン | ほとんどLGPL |
tek5の展開ルーチン(C版) | 半分以上がLGPL |
tek5の展開ルーチン(ASKA版) | 完全にKL-01 |
t5lzma.exeというツールがありますが、これはTek5形式でファイルを圧縮する場合に用いられます。
sarは原則としては圧縮ツールではありません。
元々はアーカイバ(複数のファイルを一個のファイルにくっつけてまとめるソフト)としてスタートしています。
Linux等を使っている人はピンとくるでしょうか。tarにあたるものとご理解頂ければ・・・
ただくっつけるだけならメジャーで実績もあるtarでよかったのでしょうが、サイズが一定以上小さくならない・ディスクイメージと同じような扱いができることが理想となり、独自形式の研究が始まりました。
もちろん内部的な処理で若干圧縮?する機能が搭載されています。なので100kb+200kbのファイルをまとめた場合、300kbにはなりません。小さくなります