2

サードパーティ アプリケーションで TE Edit (ter32.dll から) のテキストにアクセスしようとしています。(これに関する最初の投稿はこちら) APIを調べて、関数にアクセスするために dll を動的にロードしようとしました。残念ながら、この ter32.dll の (アフターマーケットのリワーク) には多くの依存関係があります。必要に応じて、必要な各 dll を動的にロードしようとしましたが、循環依存関係に遭遇しました。ter32.dll には x が必要です。x には y が必要です。x が必要なため、y はロードされません。これらを遅延して静的にロードする必要がありますか? アプリケーションにオーバーヘッド/肥大化/依存関係が必要ないので、そうではないことを願っています。

1）何が欠けていますか？
2）これを回避する方法はありますか？
3) ter32.dll の TE Edit 内のテキストにアクセスする他の方法を持っている人はいますか?

4

1 に答える 1

3

DLL をロードすると、ローダーがすべての依存関係をロードします。これらの依存関係は、各 DLL のインポート テーブルに一覧表示され、ローダーによって解決されます。何もする必要はありません。

したがって、DLL の依存関係を自分で処理する必要があるという結論にどのように達したのか理解できません。この DLL を非標準の方法でロードしていますか? MS C ランタイムが必要な場合など、WinSxS 依存関係のマニフェストが必要ですか? 他に知っておくべきことはありますか？

とはいえ、この DLL をプロセスにロードしても、独自の仮想メモリを持つ別のプロセスからテキストを抽出するのに役立つとは思えません。言い換えれば、テキストを抽出しようとするあなたの現在の試みは失敗すると確信しています。仮想メモリ バリアを回避する方法は、フックを使用して他のプロセスでコードを実行することです。

于 2011-08-19T06:43:21.667 に答える