windows - ファイル内のオフセットから LoadLibrary

Question

さまざまなタスクを実行する多数のクラスがあるスクリプト可能なゲーム エンジンを作成しています。エンジンのサイズは急速に拡大しているため、大きな実行可能ファイルを dll モジュールに分割して、ゲーム ライターが実際に使用するコンポーネントのみを含めることができるようにすることを考えました。ユーザーがゲーム (つまりスクリプト) をコンパイルするときに、正しい dll を最終的な実行可能ファイルの一部にする必要があります。私はすでにかなりの量のオーバーレイ データを持っているので、このブロックの一部として dll を保存できるかもしれないと考えました。私の質問はこれに要約されます：

LoadLibrary をだまして特定のオフセットでファイルの読み取りを開始することは可能ですか? これにより、dll をクリーンではない一時ファイルに抽出するか、dll の自動インクルードを完全に破棄して、ユーザーにゲームと一緒に dll をパッケージ化するように指示する必要がなくなります。

最初は「メモリから dll をロードする」アプローチを考えていましたが、移植性の理由と単に恐ろしいハックのように見えるという理由で拒否しました。

何かご意見は？

敬具、

フィリップ・ベネフォール

Answer 1

あなたは存在しない問題を解決しようとしています。DLLのロードには、実際には物理メモリは必要ありません。Windowsは、DLLコンテンツ用のメモリマップトファイルを作成します。DLLからのコードは、プログラムがそのコードを呼び出したときにのみロードされます。未使用のコードは、予約済みのメモリページ以外のシステムリソースを必要としません。32ビットオペレーティングシステムでは、20億バイトに相当します。それらをすべて消費するには、多くのコードを作成する必要があります。50メガバイトのマシンコードは、すでに非常に大きなプログラムです。

メモリマッピングは、LoadLibrary（）にやりたいことを実行させることができない理由でもあります。必要な現実的なシナリオはありません。

リンカの/DELAYLOADオプションを調べて、起動パフォーマンスを向上させます。

Answer 2

そのタスクのすべての解決策は「恐ろしいハック」であり、それ以上のものではないと思います。

私が見る最も簡単な方法は、カスタムファイルシステムを提示し、1つの実際のファイル（ライブラリのコンパイル）から複数の個別のDLLへのシステムアクセスパスをハッキングする独自の仮想ドライブを作成することです。たとえば、TrueCryptのように（オープンソースです）。LoadLibraryそして、あなたが変更なしで機能を使うかもしれないより。

しかし、私が見る正しい方法は、タスクを変更することであり、このアプローチを使用しないでください。構造体やポインターなどを使用して、独自のスクリプトインタープリターとコンパイラーを作成する必要があると思います。

主なことは、ライブラリを使用することによるあなたの利益を理解していないということです。現時点でコンパイルされたコードはそれほど重くなく、非常にうまくパックされていると思います。その他のリソースは、最初の呼び出しで動的にロードされる場合があります。あなたがする必要があるのは、スクリプトエンジンのすべてのコンポーネントの作業サイクルを正しい方法で整理することです。