文書の表示以前のリビジョンバックリンク文書の先頭へ この文書は読取専用です。文書のソースを閲覧することは可能ですが、変更はできません。もし変更したい場合は管理者に連絡してください。 ====== あわあわいろとは? (技術的観点) ====== * これもChatGptのまとめに製作者が監修して最小限の訂正をくわえたテキスト。 * ちょっとこそばゆい・てれるような表現あるけれどAIの出した文章ベースだから...ね... ===== あわあわいろ(Archway → Meltice Family)の技術概要 ===== ==== 技術的には何のプロジェクト? ==== Windows上で統合アーカイバDLL(UNLHA32/UNZIP32/TAR32/7-ZIP32/YZ1 など)を汎用GUIから扱う、軽量フロントエンド/ユーティリティ群。 ただし “フロントエンド” にとどまらず、 * 書庫判定 * パス最適化 * セキュリティ緩和 * ワイルドカード生成 * 自己展開書庫生成 * オートコンプリート * ログ出力 * 関連付け管理 などを 独自ロジックで補完し、DLL側の欠点・地雷を吸収するミドルウェア層 になっているのが特徴。 ==== 技術的アーキテクチャ ==== <code> +--------------------------+ | Meltice.exe / Frostice | ← GUI・設定管理・全体制御 +--------------------------+ | MXD (Meltice eXtended DLL) | ├─ Frostice.mxd(圧縮GUI) | ├─ DblClick.mxd(関連付け管理) | ├─ XacRett.mxd(古書庫判定) | └─ その他 utility plugins +--------------------------+ | 統合アーカイバDLL群 (UNLHA32/UNZIP32/TAR32/7-ZIP32 等) +--------------------------+ | Windows OS (95〜11) +--------------------------+ </code> ポイント: * Melticeは “DLL群の上に乗る抽象層(アダプタ層)” * MXDは 統合アーカイバDLLの拡張スロットのような立ち位置 * GUIは小さく、実質は設定ファイル管理+コマンド生成エンジン * 言語は C/C++(Visual C++ 6 → VC++2005 → VC++6 へ戻る) * ※ C++17 など“近代C++”は使わない。レガシー互換重視。 ==== Archway(1999)との技術的思想差分 ==== * Lhasa互換UI * DLLをほぼ“そのまま”呼ぶ薄いラッパ * 仕様若い * ZIP/LZH の地雷回避ロジックが薄く、DLL任せ * Archwayは“Lhasaの代替品+高速化”が主目的 → ただしユーザーから膨大な要望が来て設計が破綻した ==== Meltice(2000〜)==== Archwayの反省を踏まえて 思想を一新。 技術的特徴: * DLLごとの差異吸収(DI_CLMPI.CPP / DI_UNLHA 等) * 拡張性のための MXD アーキテクチャ * 安全な書庫判定(ヘッダ先頭+拡張子併用、tar系多段対策) * ディレクトリ横断(../)対策 * 絶対パス格納書庫の安全処理 * ZIPの9時間ズレ対策(UNZIP32 vs 7-Zip32 優先切替) * LZHヘッダ Lv1/Lv2 切替 “処理の本質部分は Meltice が握る” * DLLは エンジン であり、Melticeは 変換器+安全装置+整合レイヤ。 ==== 強烈に技術的なユニークポイント ==== ① 20年以上、全DLLの“仕様差”を吸収し続けた唯一の抽象層 統合アーカイバDLL文化は「互換」と言いながら DLL ごとに挙動が違うカオス状態だった。 Melticeは: * 内部パラメータ差分吸収 * エラーコード補正 * 出力ログ統合 * ワイルドカード生成 * “DLL暴発” の安全対策 * コマンドライン長制限回避 などを一括吸収する “実質標準化レイヤ” の役割を担った。 ② 「安全に解凍できるZIP」がWindowsでほぼ唯一 * “意図せぬ Explorer.exe 自動起動” 脆弱性の独自対策 * ディレクトリ横断(../)攻撃のブロック * 書庫判別強化(tar.gz / tar.bz2 のネスト解除) * “スペース末尾フォルダ” などの地雷回避 2001〜2007あたりのWindowsで、最も安全なZIP解凍環境だった可能性が高い。 ③ 互換性の怪物:Win95〜Win11 25H2まで同一設計で動く * Win95時代の32bit API依存 * MBCS中心 * COM未使用 * スレッド未使用 * CRT古い仕様 * APIは Win95/NT4 互換圏が中心 この“古代API”が逆にメリットになり将来バージョンのWindowsでほぼ壊れない。21世紀に残った“生きた化石レイヤ”でもある。 ④ MXD仕様の「バグを仕様として固定したレガシー互換」 ユーザーとの互換を守るため“フォルダかファイルかを判別するAPIが無い” そのためフォルダ処理に制限がある しかし互換のために修正しないことを選んだ レガシー設計の保存という意味で極めて貴重な例。 ⑤ 技術的な意味での “あわあわいろ” の価値 * 統合アーカイバDLL文化の 歴史を完全に保存した唯一の実装 * 1999〜2025の Windows文化史を貫く実働サンプル * “安全に書庫を扱うための実戦ノウハウ”の塊 * 小型GUIの ミドルウェア化アプローチの成功例 * 20年以上動くコードの設計例として貴重 ソフトウェア保存・アーカイブ文化の観点から見ても 技術史として価値が高いプロジェクト。 soft/awa/cgpt/tech.txt 最終更新: 2025/11/20 20:48by asaasa