【要約】依存DLLゼロの単体exeで配る ― Windows×Rustで「全部入り」を1ファイルにする舞台裏 [Qiita_Trend] | Summary by TechDistill
> Source: Qiita_Trend
Execute Primary Source
// Problem
開発者は、多機能な画像ビューワ『mIV』を、追加インストール不要な単体exeとして配布する際に、複数の技術的障壁に直面した。単にファイルを同梱するだけでは、以下の問題が発生した。
- ・重量級の依存物：PDFエンジンやAIモデル、FFmpeg等の膨大なファイルを抱えている。
- ・ランタイム依存：Visual C++ 再頒布可能パッケージの有無により、実行が阻害される。
- ・アーキテクチャの壁：64bit本体から32bitのSusieプラグインを直接読み込めない。
- ・DLLロードの競合：FFmpeg（LGPL）は動的リンクが必要だが、OSは本体起動時にDLLを要求するため、実行時の展開では間に合わない。
// Approach
開発者は、Rustの機能とマルチプロセス設計を組み合わせ、依存関係を「埋め込み・展開・隔離」する戦略を採用した。具体的には以下の手法を講じた。
- ・include_bytes! の活用：外部ファイルをコンパイル時にexeへ埋め込み、初回起動時に %APPDATA% へ展開する。
- ・crt-static の採用：Cランタイムを静的リンクし、VC++再頒布可能パッケージへの依存を排除する。
- ・マルチプロセス化：32bitプラグインやPDF描画を別プロセスとして分離し、IPC（標準入出力）で通信する。
- ・2段ロケット方式：FFmpeg対策として、DLLを要求しない軽量な「ランチャー」を先行させ、本体起動前にDLLを展開する。
// Result
開発者は、365MBの単体exeを実現し、ユーザーが「ダブルクリックするだけ」で全機能を使える環境を構築した。これにより、以下の成果を得た。
- ・PDF描画の高速化：プロセス並列化により、描画時間を1.4秒から10ミリ秒へと大幅に短縮した。
- ・ライセンス遵守：FFmpegを動的リンクのまま扱うことで、LGPLの制約をクリアした。
- ・高い堅牢性：重い処理や相性の悪いモジュールを別プロセスに隔離し、本体のクラッシュを防いだ。
Senior Engineer Insight
> OSのローダの挙動とライセンス制約の衝突を、ランチャーによる2段構成で解決した設計は極めて合理的である。単なる「全部入り」ではなく、プロセス分離による並列化やクラッシュ耐性の向上まで見据えた設計は、実戦的だ。ただし、365MBというサイズは、配布の容易さと引き換えにした大きなトレードオフである。ネットワーク帯域が制限される環境では、このサイズがボトルネックとなる。配布物としての「手軽さ」と「データ量」のバランスをどう取るかが、運用上の鍵となるだろう。