ダイナミックリンクライブラリ

ダイナミック リンク ライブラリ( DLL )は、Microsoft WindowsまたはOS/2オペレーティング システムの共有ライブラリです。

DLL には、実行可能コード(関数)、データ、リソースを任意の組み合わせで含めることができます。

DLL ファイルのファイル拡張子は であることが多いですが、任意のファイル拡張子を使用できます。開発者は、 ActiveXコントロールやレガシー(16 ビット)デバイス ドライバー.dllなど、ファイルの内容を表すファイル拡張子を使用することを選択できます。 .ocx.drv

リソースのみを含むDLLはリソースDLLと呼ばれることがあります。例としては、拡張子が であるアイコンライブラリ.iclや、拡張子がおよびであるフォントライブラリ などがあります。^[1].fon.fot

DLL のファイル形式は実行可能ファイル(別名EXE )と同じですが、Windows のバージョンによって形式が異なります。32ビットおよび64 ビットのWindows バージョンではPortable Executable (PE) が使用され、16 ビットのWindows バージョンではNew Executable (NE)が使用されます。

DLL と EXE の主な違いは、オペレーティング システムが実行を開始するためにエントリ ポイントを必要とするため、DLL を直接実行できないことです。Windows は、DLL によって公開される関数を実行するためのユーティリティ プログラム (RUNDLL.EXE/RUNDLL32.EXE) を提供します。

EXE は同じ形式なので、DLL として使用できます。消費コードは、DLL をロードするのと同じメカニズムを使用して EXE をロードできます。

Microsoft Windowsの最初のバージョンでは、プログラムを単一のアドレス空間で同時に実行していました。すべてのプログラムは、CPU を他のプログラムに譲ることで連携し、グラフィカル ユーザー インターフェイス(GUI) がマルチタスクを実行し、応答性を最大限に高められるようになっていました。すべてのオペレーティング システム レベルの操作は、基礎となるオペレーティング システムであるMS-DOSによって提供されました。すべての高レベル サービスは、Windows ライブラリ「ダイナミック リンク ライブラリ」によって提供されました。描画APIであるグラフィックス デバイス インターフェイス(GDI) は、 と呼ばれる DLL に実装されGDI.EXE、 のユーザー インターフェイスでしたUSER.EXE。DOS の上にあるこれらの追加レイヤーは、実行中のすべての Windows プログラムで共有する必要がありました。これは、Windows が 1 MB 未満の RAM を搭載したマシンで動作できるようにするためだけでなく、プログラムが互いに連携できるようにするためです。GDI のコードは、描画コマンドを特定のデバイスでの操作に変換する必要がありました。ディスプレイでは、フレーム バッファーのピクセルを操作する必要がありました。プリンターに描画する場合、API 呼び出しをプリンターへの要求に変換する必要がありました。限られたデバイス セット (カラー グラフィックス アダプターディスプレイ、HP LaserJetプリンター コマンド言語など) に対してハードコードされたサポートを提供することもできましたが、Microsoft は別のアプローチを選択しました。GDI は、さまざまな出力デバイスで動作するために、「デバイス ドライバー」と呼ばれるさまざまなコードを読み込むことによって機能します。

GDI がさまざまなデバイス ドライバーをロードできるようにしたのと同じアーキテクチャ概念により、Windows シェルがさまざまな Windows プログラムをロードし、これらのプログラムが共有 USER および GDI ライブラリから API 呼び出しを呼び出すこともできるようになりました。この概念は「動的リンク」でした。

従来の非共有静的ライブラリでは、実行可能ファイルが「リンク」段階でビルドされるときに、コードのセクションが呼び出しプログラムに単純に追加されます。2 つのプログラムが同じルーチンを呼び出す場合、そのルーチンは 2 つのプログラムのリンク段階で両方のプログラムに含まれます。動的リンクでは、共有コードは 1 つの別のファイルに配置されます。このファイルを呼び出すプログラムは実行時にファイルに接続され、オペレーティング システム (または、Windows の初期バージョンの場合は OS 拡張機能) がバインドを実行します。

Windows の初期バージョン (1.0 ～ 3.11) では、DLL が GUI 全体の基盤でした。そのため、ディスプレイ ドライバーは、統合デバイス ドライバーインターフェイス (DDI) を介して同じ描画 API のカスタム実装を提供する .DRV 拡張子の DLL にすぎず、描画 (GDI) および GUI (USER) API は、.EXE 拡張子の GDI および USER システム DLL によってエクスポートされた関数呼び出しにすぎませんでした。

動的にロードされるライブラリのコレクションからオペレーティング システムを構築するというこの概念は、2015 年現在も存続している Windows のコア コンセプトです。DLL は、モジュール性など、共有ライブラリ^{[アップデート]}の標準的な利点を提供します。モジュール性により、複数のアプリケーションで共有される単一の自己完結型 DLL 内のコードとデータを変更しても、アプリケーション自体に変更を加える必要はありません。

モジュール化のもう 1 つの利点は、プラグイン用の汎用インターフェイスを使用できることです。単一のインターフェイスを開発することで、アプリケーション自体を変更することなく、実行時に既存のアプリケーションに古いモジュールと新しいモジュールをシームレスに統合できます。この動的な拡張性の概念は、 ActiveXの基盤であるコンポーネント オブジェクト モデルによって極限まで実現されています。

Windows 1.x、2.x、3.x では、すべての Windows アプリケーションが同じアドレス空間と同じメモリを共有していました。DLL はこのアドレス空間に一度だけロードされ、それ以降はライブラリを使用するすべてのプログラムがその DLL にアクセスしました。ライブラリのデータはすべてのプログラム間で共有されていました。これは間接的なプロセス間通信として使用することも、誤ってさまざまなプログラムを破損させることもできます。Windows 95で32 ビットライブラリが導入されたことで、すべてのプロセスが独自のアドレス空間で実行されるようになりました。DLL コードは共有できますが、共有データがライブラリによって明示的に要求されている場合を除き、データは非公開です。とはいえ、Windows 95、Windows 98、Windows Meの大部分は16 ビット ライブラリから構築されていたため、起動時にPentium Proマイクロプロセッサのパフォーマンスが制限され、最終的には DOS ベースの Windows バージョンの安定性とスケーラビリティが制限されました。

DLL テクノロジは Windows アーキテクチャの中核ですが、欠点もあります。

DLL 地獄とは、間違ったバージョンの DLL が使用された場合にアプリケーションが不正な動作を起こすことを指します。^[2]緩和戦略には次のものがあります。

• .NET フレームワーク
• Microsoft Virtual PCやMicrosoft Application Virtualizationなどの仮想化ベースのソリューションは、アプリケーション間の分離を提供するため
• サイドバイサイドアセンブリ

DLL の実行可能コードは、呼び出しプロセスのメモリ空間で同じアクセス権限で実行されるため、使用時のオーバーヘッドはほとんどありませんが、DLL に何らかのバグがある場合、呼び出しプログラムは保護されません。

DLL テクノロジを使用すると、使用するコンポーネントを再コンパイルまたは再リンクすることなく、アプリケーションを変更できます。 DLL を置き換えると、次回アプリケーションを実行するときに新しい DLL バージョンが使用されるようになります。 正しく動作させるには、DLL の変更で下位互換性を維持する必要があります。

オペレーティング システムも DLL を介してアプリケーションに公開されるため、アップグレードできます。システム DLL を置き換えると、次回アプリケーションを実行するときに新しいシステム DLL が使用されるようになります。

Windows APIでは、DLL ファイルはセクションに編成されます。各セクションには、書き込み可能か読み取り専用か、実行可能 (コードの場合) か実行不可 (データの場合) かなど、独自の属性セットがあります。

DLL 内のコードは通常、その DLL を使用するすべてのプロセス間で共有されます。つまり、DLL は物理メモリ内の単一の場所を占有し、ページ ファイル内のスペースは占有しません。Windows は DLL に位置独立コードを使用しません。代わりに、コードはロード時に再配置され、DLL をロードする最初のプロセスのメモリ空間内の空き場所にすべてのエントリ ポイントのアドレスが固定されます。実行中のすべてのプロセスが単一の共通アドレス空間を占有していた Windows の古いバージョンでは、DLL のコードの単一のコピーは常にすべてのプロセスに十分でした。ただし、プログラムごとに個別のアドレス空間を使用する Windows の新しいバージョンでは、各プログラムが DLL のコードを収容するために同じ仮想アドレスを空けている場合のみ、複数のプログラムで同じ DLL の再配置コピーを使用できます。一部のプログラム (または既にロードされている DLL の組み合わせ) でそれらのアドレスが空いていない場合は、別の再配置エントリ ポイントのセットを使用して、DLL コードの追加の物理コピーを作成する必要があります。コード セクションによって占有されている物理メモリを再利用する場合、その内容は破棄され、後で必要に応じて DLL ファイルから直接再ロードされます。

コード セクションとは対照的に、DLL のデータ セクションは通常プライベートです。つまり、DLL を使用する各プロセスは、DLL のすべてのデータの独自のコピーを持ちます。オプションで、データ セクションを共有にして、この共有メモリ領域を介してプロセス間通信を許可することができます。ただし、共有 DLL メモリの使用にはユーザー制限が適用されないため、セキュリティ ホールが発生します。つまり、1 つのプロセスが共有データを破損し、他のすべての共有プロセスが望ましくない動作をする可能性があります。たとえば、ゲスト アカウントで実行されているプロセスは、このようにして、特権アカウントで実行されている別のプロセスを破損する可能性があります。これは、DLL で共有セクションを使用しないようにする重要な理由です。

DLL が特定の実行可能パッカー( UPXなど) によって圧縮されている場合、そのすべてのコード セクションは読み取りおよび書き込みとしてマークされ、共有されません。読み取りおよび書き込みコード セクションは、プライベート データ セクションと同様に、各プロセスにプライベートです。したがって、共有データ セクションを持つ DLL は、複数のプログラムによって同時に使用されることを意図している場合は圧縮しないでください。各プログラム インスタンスが独自の DLL のコピーを保持する必要があり、メモリ消費が増加するためです。

静的ライブラリと同様に、DLL のインポート ライブラリはファイル拡張子で示されます.lib。たとえば、ファイル作成やメモリ管理などの Windows の基本機能の主要な動的ライブラリであるkernel32.dll はkernel32.lib、 を介してリンクされます。インポート ライブラリと適切な静的ライブラリを区別する通常の方法は、サイズです。インポート ライブラリは、リンク時に処理される実際の DLL を参照するシンボルのみを含むため、はるかに小さくなります。ただし、どちらも Unix ar形式のファイルです。

動的ライブラリへのリンクは、通常、ビルド時または実行可能ファイルを作成するためのリンク時にインポート ライブラリへのリンクによって処理されます。作成された実行可能ファイルには、すべての DLL 関数呼び出しを参照するインポート アドレス テーブル (IAT) が含まれます (参照される各 DLL 関数には、IAT に独自のエントリが含まれます)。実行時に、IAT には、個別にロードされた DLL 内の関数を直接指す適切なアドレスが設定されます。^[3]

Cygwin/MSYSとMinGWでは、インポートライブラリには慣例的に.dll.aWindows DLLサフィックスとUnix arサフィックスを組み合わせたサフィックス が付けられます。ファイル形式は似ていますが、インポートをマークするために使用されるシンボルが異なります(_head_foo_dllと__IMPORT_DESCRIPTOR_foo)。^[4] GNU Binutilsツールチェーンはインポートライブラリを生成してリンクすることができますが、DLLに直接リンクする方が高速です。^[5] MinGWのgenlibと呼ばれる実験的なツールは、MSVCスタイルのシンボルでインポートライブラリを生成するために使用できます。

DLL によってエクスポートされる各関数は、数値序数とオプションで名前によって識別されます。同様に、関数は序数または名前によって DLL からインポートできます。序数は、DLL エクスポート アドレス テーブル内の関数のアドレス ポインターの位置を表します。内部関数は序数のみでエクスポートされるのが一般的です。ほとんどの Windows API 関数では、異なる Windows リリース間で名前のみが保持され、序数は変更される可能性があります。したがって、Windows API 関数を序数で確実にインポートすることはできません。

序数による関数のインポートは、名前によるインポートよりもわずかにパフォーマンスが向上します。DLL のエクスポート テーブルは名前で順序付けされるため、バイナリ検索を使用して関数を見つけることができます。見つかった名前のインデックスは、エクスポート序数テーブルで序数を検索するために使用されます。16 ビット Windows では、名前テーブルは並べ替えられなかったため、名前検索のオーバーヘッドがはるかに顕著でした。

実行可能ファイルを特定のバージョンの DLL にバインドして、コンパイル時にインポートされた関数のアドレスを解決することもできます。バインドされたインポートの場合、リンカーはインポートがバインドされている DLL のタイムスタンプとチェックサムを保存します。実行時に、Windows は同じバージョンのライブラリが使用されているかどうかを確認し、使用されている場合はインポートの処理をバイパスします。そうでない場合、ライブラリがバインドされたライブラリと異なる場合は、Windows は通常の方法でインポートを処理します。

バインドされた実行可能ファイルは、コンパイルされたのと同じ環境で実行された場合は多少速くロードされ、別の環境で実行された場合もまったく同じ時間でロードされるため、インポートをバインドしてもデメリットはありません。たとえば、すべての標準 Windows アプリケーションは、それぞれの Windows リリースのシステム DLL にバインドされています。アプリケーションのインポートをターゲット環境にバインドする良い機会は、アプリケーションのインストール時です。これにより、ライブラリは次の OS アップデートまで「バインド」されたままになります。ただし、これにより実行可能ファイルのチェックサムが変更されるため、署名されたプログラムや、ファイル バージョンの管理にチェックサム ( MD5チェックサムなど) を使用する構成管理ツールによって管理されるプログラムでは実行できません。最近の Windows バージョンでは、ロードされたすべてのライブラリの固定アドレスが使用されなくなっているため (セキュリティ上の理由から)、実行可能ファイルをバインドする機会と価値は減少しています。

DLL ファイルは、 (または) API 関数を使用して実行時に明示的にロードできます。このプロセスは、Microsoft によって単に実行時動的リンクと呼ばれています。API関数は、エクスポートされたシンボルを名前で検索するために使用され、– は DLL をアンロードするために使用されます。これらの関数は、POSIX標準 API の 、 、およびに類似しています。LoadLibraryLoadLibraryExGetProcAddressFreeLibrarydlopendlsymdlclose

明示的な実行時リンクの手順は、言語構造ではなく Windows APIに依存するため、関数へのポインターをサポートするどの言語でも同じです。

通常、DLL のインポート ライブラリにリンクされたアプリケーションは、DLL が見つからない場合は起動に失敗します。これは、Windows がアプリケーションに必要なすべての DLL を見つけられないとアプリケーションを実行しないためです。ただし、アプリケーションをインポート ライブラリにリンクして、動的ライブラリの遅延読み込みを許可することはできます。^[6]LoadLibraryこの場合、オペレーティング システムはアプリケーションの起動時に DLL を検索または読み込みません。代わりに、リンカーによってアプリケーションにスタブが組み込まれ、その関数の 1 つが呼び出されたときに を通じて DLL を検索して読み込みますGetProcAddress。DLL が見つからないか読み込まれない場合、または呼び出された関数が存在しない場合は、アプリケーションによって例外が生成され、この例外が適切にキャッチされて処理されます。アプリケーションが例外を処理しない場合、オペレーティング システムによってキャッチされ、エラー メッセージとともにプログラムが終了します。

遅延読み込みメカニズムは通知フックも提供し、 DLL が読み込まれたときや DLL 関数が呼び出されたときに、 アプリケーションが追加の処理やエラー処理を実行できるようにします。

libraryソース ファイルでは、の代わりにキーワードが使用されますprogram。ファイルの末尾の 句には、エクスポートされる関数がリストされますexports。

Delphi では、LIB DLL から関数をインポートするためにファイルは必要ありません。DLL にリンクするには、external関数宣言でキーワードを使用して DLL 名を指定し、その後にnameシンボルの名前 (異なる場合) を指定するか、indexインデックスを識別します。

Visual Basic (VB)では、実行時リンクのみがサポートされていますがLoadLibrary、GetProcAddressAPI 関数の使用に加えて、インポートされた関数の宣言も許可されています。

DLL宣言を通じて DLL 関数をインポートする場合、ファイルが見つからない と VB は実行時エラーを生成します。開発者はエラーをキャッチして適切に処理できます。

VB で DLL を作成する場合、IDE では ActiveX DLL の作成のみが許可されますが、エクスポートされた各関数の順序位置と名前を定義する .DEF ファイルをリンカーに明示的に含めるように指示できるメソッドが作成されています^[7]。これにより、ユーザーは Visual Basic (バージョン 6 以下) を使用して、"Declare" ステートメントを通じて参照できる標準の Windows DLL を作成できます。

Microsoft Visual C++ (MSVC) は、標準C++にいくつかの拡張機能を提供しており、関数を C++ コード内で直接インポートまたはエクスポートするように指定できます。これらは、GCCの Windows 版を含む他の Windows Cおよび C++ コンパイラーに採用されています。これらの拡張機能は、関数宣言の前に属性を使用します。C 関数が C++ からアクセスされる場合、コンパイラーに C リンケージを使用する必要があることを通知するために、C++ コード内でも宣言する必要があることに注意してください。^[8]__declspecextern "C"

属性を使用してインポートまたはエクスポートされた関数を指定する以外に、プロジェクトで使用されるファイル__declspecの IMPORT または EXPORTS セクションにリストすることもできます。ファイルはコンパイラではなくリンカーによって処理されるため、C++ に固有のものではありません。 DEFDEF

DLLDLL のコンパイルにより、ファイルとファイルの両方が生成されますLIB。LIBファイル (インポート ライブラリ) は、コンパイル時に DLL にリンクするために使用されます。実行時のリンクには必要ありません。DLL がコンポーネントオブジェクト モデル(COM) サーバーでない限り、DLLファイルは、PATH 環境変数にリストされているディレクトリの 1 つ、既定のシステム ディレクトリ、またはそれを使用するプログラムと同じディレクトリに配置する必要があります。COM サーバー DLL は、regsvr32.exe を使用して登録されます。regsvr32.exe は、DLL の場所とグローバル一意 ID ( GUID ) をレジストリに配置します。その後、プログラムは、レジストリで GUID を参照して DLL の場所を検索したり、クラス識別子とインターフェイス識別子を使用して COM オブジェクトのインスタンスを間接的に作成したりして、DLL を使用できます。

次の例は、言語固有のバインディングを使用して、コンパイル時に DLL にリンクするためのシンボルをインポートする方法を示しています。

デルファイ

{$APPTYPE コンソール}

プログラム例; 

// 2 つの数値を加算する関数をインポートします。
function AddNumbers ( a , b : Double ) : Double ; StdCall ; external 'Example.dll' ;        

// メインプログラム
var 
R : Double ;    

begin 
R := AddNumbers ( 1 , 2 ) ; Writeln ( '結果は次の通りです: ' , R ) ; end .     
   

Ｃ

静的リンクの前に、プロジェクトに 'Example.lib' ファイルを含める必要があります (Example.dll が生成されていると仮定)。 'Example.lib' ファイルは、DLL をコンパイルするときにコンパイラによって自動的に生成されます。 上記のステートメントを実行しないと、リンカーが の定義の場所を認識できないため、リンク エラーが発生しますAddNumbers。 DLL ファイル 'Example.dll' は、次のコードによって .exe ファイルが生成される場所にコピーする必要がある場合もあります。

#include <windows.h> #include <stdio.h> 
 

// 2 つの数値を加算する関数をインポートします。
extern "C" __declspec ( dllimport ) double AddNumbers ( double a , double b );       

int main ( int argc , char * argv []) { double result = AddNumbers ( 1 , 2 ); printf ( "結果は: %f \n " , result ); return 0 ; }    

        
     
     

次の例は、言語固有の Windows API バインディングを使用して、ランタイム読み込みおよびリンク機能を使用する方法を示しています。

4 つのサンプルはすべて DLL プリロード攻撃に対して脆弱であることに注意する。これは、example.dll が作成者の意図しない場所に解決される可能性があるためである (明示的に除外しない限り、アプリケーション ディレクトリはシステム ライブラリの場所の前になり、HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager\SafeDllSearchMode^[9] またはHKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\CWDIllegalInDLLSearch^[10]がなければ、現在の作業ディレクトリがシステム ライブラリ ディレクトリの前に検索される)。つまり、悪意のあるバージョンのライブラリになる。安全なライブラリのロードに関する Microsoft のガイダンスについては、リファレンスを参照。SetDefaultDllDirectoriesアプリケーションkernel32ディレクトリと現在の作業ディレクトリの両方を DLL 検索パスから削除するには、in を使用するか、現在の作業ディレクトリを DLL 検索パスから削除するには、 SetDllDirectoryWin を使用する必要がkernel32ある。^[11]

オプション明示的宣言関数AddNumbers Lib "Example.dll" _
 ( ByVal a As Double 、ByVal b As Double ) As Double 
              

Sub Main () Dim Result As Double Result = AddNumbers ( 1 , 2 ) Debug . Print "結果は次のようになりました: " & Result End Sub 
	   
	   
	   
 

プログラム例; {$APPTYPE CONSOLE}はWindowsを使用します; var AddNumbers : function ( a , b : integer ) : Double ; StdCall ; LibHandle : HMODULE ; begin LibHandle := LoadLibrary ( 'example.dll' ) ; if LibHandle <> 0 then AddNumbers := GetProcAddress ( LibHandle , 'AddNumbers' ) ; if Assigned ( AddNumbers ) then Writeln ( '1 + 2 =' , AddNumbers ( 1 , 2 ) ) ; Readln ; end . 
  
   
  
       
  

    
      
       
    
          
  

#include <windows.h> #include <stdio.h> 
 

// DLL 関数シグネチャ
typedef double ( * importFunction )( double , double );   

int main ( int argc 、char ** argv ) { importFunction addNumbers ; double result ; HINSTANCE hinstLib ;    

	 
	 
	 

	// DLL ファイルをロードします
hinstLib = LoadLibrary ( TEXT ( "Example.dll" )); if ( hinstLib == NULL ) { printf ( "ERROR: DLL をロードできません\n " ); return 1 ; }	  
	    
		
		 
	

	// 関数ポインターを取得します。
addNumbers = ( importFunction ) GetProcAddress ( hinstLib , "AddNumbers" ); if ( addNumbers == NULL ) { printf ( "ERROR: DLL 関数が見つかりません\n " ); FreeLibrary ( hinstLib ); return 1 ; }	    
	    
		
		
		 
	

	// 関数を呼び出します。
result = addNumbers ( 1 , 3 );	   

	// DLL ファイルをアンロードします
FreeLibrary ( hinstLib );	

	// 結果を表示
printf ( "結果は: %f \n " , result );	 

	0 を返す; } 

Python ctypes バインディングは、POSIX システム上で POSIX API を使用します。

 ctypesをインポートする

my_dll  =  ctypes 。cdll 。LoadLibrary ( "Example.dll" )


# 次の "restype" メソッド仕様は、関数によって返される型を Python に理解させる
ために必要です。 my_dll . AddNumbers . restype  =  ctypes . c_double

p  =  my_dll.AddNumbers ( ctypes.c_double ( 1.0 ) , ctypes.c_double ( 2.0 ) )​​​​ 

print ( "結果は次の通りです:" ,  p )

コンポーネントオブジェクト モデル(COM) は、DLL および EXE ファイル内のオブジェクトの実装をホストするためのバイナリ標準を定義します。これらのファイルの検索とバージョン管理のメカニズムと、言語に依存しない、機械可読なインターフェイスの説明を提供します。COM オブジェクトを DLL にホストすると、より軽量になり、クライアント プロセスとリソースを共有できます。これにより、COM オブジェクトは Visual Basic や ASP などの単純な GUI フロントエンドに強力なバックエンドを実装できます。スクリプト言語からプログラムすることもできます。^[12]

DLLハイジャック、DLLスプーフィング、DLLプリロード、バイナリプランティングとして一般的に知られている脆弱性により、多くのプログラムは、これらのプログラムによって開かれたデータファイルと同じフォルダに含まれる悪意のあるDLLをロードして実行します。 ^{[13] [14] [15] [16]}この脆弱性は、2000年にGeorgi Guninskiによって発見されました。^[17] 2010年8月にACROS Securityが再発見し、何百ものプログラムが脆弱であることが判明した後、この脆弱性は世界中で注目を集めました。^{[18]安全でない場所、つまり}ダウンロードやTempディレクトリ などのユーザーが書き込み可能なフォルダから実行されるプログラムは、ほぼ常にこの脆弱性の影響を受けます。^{[19] [20] [21] [22] [23] [24] [25]}

• Dependency Walker は、DLL および EXE ファイルのエクスポートおよびインポートされた機能を表示するユーティリティです。
• ダイナミックライブラリ
• 図書館（コンピューティング）
• リンカー（コンピューティング）
• ローダー（コンピューティング）
• モリコンズ.dll
• オブジェクトファイル
• 共有ライブラリ
• 静的ライブラリ
• DLL 地獄

• ハート、ジョンソン。Windowsシステム プログラミング 第 3 版。Addison-Wesley、2005 年。ISBN 0-321-25619-0。 
• Rector, Brent 他著。Win32プログラミング。Addison-Wesley Developers Press、1997 年。ISBN 0-201-63492-9。 

• MSDN の dllexport、dllimport
• MSDN のダイナミック リンク ライブラリ
• MSDN のダイナミック リンク ライブラリ セキュリティ
• MSDN のダイナミック リンク ライブラリの検索順序
• Microsoft セキュリティ アドバイザリ: 安全でないライブラリの読み込みによりリモート コード実行が可能になる可能性がある
• Microsoft サポート サイトの「DLL とは何ですか?」
• MSDN のダイナミック リンク ライブラリ関数
• Microsoft ポータブル実行可能ファイルおよび共通オブジェクト ファイル形式の仕様
• dll ファイルに関する Microsoft の仕様
• カーペット爆撃とディレクトリポイズニング
• MS09-014: Safari Carpet Bomb の脆弱性への対処
• DLL プリロードリモート攻撃ベクトルに関する詳細情報
• DLL プリロードリモート攻撃ベクトルに関する最新情報
• ライブラリを安全にロードする