0

このプログラムの stdafx.h は、以下のようなものです。

// ...
#import "./lib/64/msado15.dll" rename("EOF", "EndOfFile") no_namespace
// ...

プログラムは正常に動作し、問題はありません。

msado15.dll を削除したらどうなるか気になりました。それで、私はそれを削除しましたが、プログラムはまだ正常に動作しています。

同じディレクトリにmsado15.dllがなくてもプログラムが機能するのは、dllファイルが別の場所にロードされているためだと思いました。

dll がどこにロードされているかを正確に確認するために、「Dependancy Walker」を使用しましたが、このプログラムが msado15.dll をまったくロードしていないことがわかりました。

何が欠けているのかを理解できれば幸いです。

前もって感謝します。

4

1 に答える 1

3

Dependency Walkerは、静的な DLL の依存関係 (EXE のインポート テーブルに参照がある場所) のみを表示できます。DLL が実行時にLoadLibrary(または遅延読み込み -- を使用して/delayload) 読み込まれた場合、Dependency Walkerはこれを認識できません。

#import実際には、DLL に静的な依存関係を課すことはありません。コンパイル時に DLL から COM タイプ ライブラリ情報を読み込みます。これは、タイプ ライブラリで定義されている COM クラスとインターフェイスの C++ バインディングに変換されます。これらは、またはディレクトリ内の.tliおよび.tlhファイルとして表示できます。DLL ファイルを削除できる可能性があり、これらのファイルがまだ存在する限り、VS はプロジェクトを正常にビルドし続ける可能性があります。DebugRelease

同様に、実行時に、#import実際には DLL に静的な依存関係を課さない (つまり、DLL を EXE のインポート テーブルに追加しない) ため、Dependency Walkerはこの依存関係を認識できません。

ただし、実行時に EXE は (間接的に) を呼び出しLoadLibrary、(DLL が見つからない場合) これにより実行時にエラーが発生し、プログラムが適切に処理するか、プログラムがクラッシュする可能性があります。

とはいえ、#import単に COM タイプ ライブラリをインポートするだけです。COM タイプ ライブラリは、COM オブジェクトで使用されるインターフェイスと、CLSIDそれらのオブジェクトの値を定義します。COM オブジェクトを実装するコードを見つけるために、CLSID値はレジストリを使用して解決されます( HKEY_CLASSES_ROOT\CLSID.

これは、DLL が実行時に必要とされないことさえあることを意味します。ただ、これは珍しいと思います。

さらに、COM オブジェクトはアウト プロセス オブジェクトとして実装される場合があります (別の EXE が読み込まれることを意味します)。この場合、プロセスに読み込まれるのは、関連するインターフェイス用に構成されたプロキシ/スタブ DLL だけです。多くの場合、これらは TLB を使用して定義されます (この場合、#import-ed DLL がロードされます)。しかし、完全に異なる DLL で実装されている可能性があります。どちらの方法でも、DLL は動的に読み込まれます。つまり、Dependency Walkerはそれを認識しません。

プロセスによって読み込まれる DLL を確認するには、 SysInternals Process MonitorやProcess Explorerなどが必要です。

于 2012-08-16T08:01:55.697 に答える