ライブラリ(コンピューティング)

ウィキペディアから、無料の百科事典
ナビゲーションにジャンプ 検索にジャンプ

libvorbisfileを使用してOggVorbisファイルを再生するアプリケーション

コンピュータサイエンスではライブラリは、多くの場合ソフトウェア開発のために、コンピュータプログラムによって使用される不揮発性リソースのコレクションですこれらには、構成データ、ドキュメント、ヘルプデータ、メッセージテンプレート、事前に作成されたコードサブルーチンクラス、またはタイプの仕様が含まれる場合があります。IBMのOS / 360およびその後継では、これらはパーティション化されたデータセットと呼ばれます[1]

ライブラリは、言語で記述された動作の実装のコレクションでもあり、動作が呼び出されるための明確に定義されたインターフェイスを備えています。たとえば、より高いレベルのプログラムを作成したい人は、システムコールを何度も実装する代わりに、ライブラリを使用してシステムコールを作成できます。さらに、この動作は、複数の独立したプログラムで再利用できるように提供されています。プログラムは、言語のメカニズムを介してライブラリが提供する動作を呼び出します。たとえば、単純な命令型言語ではCなどの場合、ライブラリ内の動作は、Cの通常の関数呼び出しを使用して呼び出されます。同じプログラム内の別の関数に対する呼び出しと、ライブラリ関数に対する呼び出しを区別するのは、コードがシステム内で編成される方法です。[2]

ライブラリコードは、相互に接続されていない複数のプログラムで使用できるように編成されていますが、プログラムの一部であるコードは、その1つのプログラム内でのみ使用されるように編成されています。この区別は、数百万行のプログラムなど、プログラムが大きくなると階層的な概念を得ることができます。その場合、大規模なプログラムの独立したサブ部分によって再利用される内部ライブラリが存在する可能性があります。際立った特徴は、ライブラリが独立したプログラムまたはサブプログラムによって再利用される目的で編成されており、ユーザーはライブラリの内部の詳細ではなく、インターフェイスを知っているだけでよいということです。

ライブラリの価値は、標準化されたプログラム要素の再利用にあります。プログラムがライブラリを呼び出すと、その動作自体を実装しなくても、そのライブラリ内に実装された動作を取得します。ライブラリは、モジュール方式でのコードの共有を促進し、コードの配布を容易にします。

ライブラリによって実装される動作は、さまざまなプログラムライフサイクルフェーズで呼び出し側プログラムに接続できます呼び出し側プログラムのビルド中にライブラリのコードにアクセスした場合、そのライブラリは静的ライブラリと呼ばれます。[3]別の方法は、ライブラリの実装とは関係なく、呼び出しプログラムの実行可能ファイルを作成して配布することです。ライブラリの動作は、実行を開始するプロセスの一部として、または実行の途中で、実行可能ファイルが呼び出されて実行された後に接続されます。この場合、ライブラリはダイナミックライブラリと呼ばれます(実行時にロードされます))。ダイナミックライブラリは、プログラムを実行する準備をするときに、リンカによってロードおよびリンクできます。あるいは、実行の途中で、アプリケーションがモジュールのロードを明示的に要求する場合があります。

ほとんどのコンパイル言語には標準ライブラリがありますが、プログラマーは独自のカスタムライブラリを作成することもできます。最新のソフトウェアシステムのほとんどは、システムサービスの大部分を実装するライブラリを提供します。このようなライブラリは、最新のアプリケーションが必要とするサービスを整理しています。そのため、最新のアプリケーションで使用されるほとんどのコードは、これらのシステムライブラリで提供されます。

歴史

EDSACコンピューター用のパンチテープのリールにあるサブルーチンライブラリを含むファイリングキャビネットの隣で働く女性。

1947年、ゴールドスタインフォンノイマンは、当時まだ稼働していなかった初期のコンピューターであるIASマシンで作業するためのサブルーチンの「ライブラリ」を作成することが有用であると推測しました。[4]彼らは、磁気ワイヤー記録の物理ライブラリーを想定しており、各ワイヤーには再利用可能なコンピューターコードが保存されています。[5]

フォンノイマンに触発されて、ウィルクスと彼のチームはEDSACを構築しましたパンチテープファイリングキャビネットには、このコンピューターのサブルーチンライブラリが含まれていました。[6] EDSACのプログラムは、メインプログラムと、サブルーチンライブラリからコピーされた一連のサブルーチンで構成されていました。[7] 1951年、チームはプログラミングに関する最初の教科書である「電子デジタルコンピュータ用のプログラムの準備」を発行しました。この教科書には、ライブラリの作成と目的が詳しく説明されています。[8]

COBOLには1959年に「ライブラリシステムの基本機能」が含まれていました[9] 、 JeanSammetはそれらを振り返って「不十分なライブラリ機能」と表現しました。[10]

JOVIALには、大まかにヘッダーファイルのライブラリであるCommunication Pool(COMPOOL)がありました。

現代のライブラリーの概念に対するもう1つの主要な貢献者は、FORTRANのサブプログラムの革新という形でもたらされましたFORTRANサブプログラムは互いに独立してコンパイルできますが、コンパイラーにはリンカーがありませんでした。そのため、Fortran-90にモジュールが導入される前は、FORTRAN [NB1]サブプログラム間の型チェックは不可能でした。[11]

1960年代半ばまでに、アセンブラ用のコピーライブラリとマクロライブラリが一般的になりました。IBM System / 360の人気から始まって、システムパラメータなどの他のタイプのテキスト要素を含むライブラリも一般的になりました。

Simulaは最初のオブジェクト指向プログラミング言語であり、そのクラスはJavaC ++、およびC#で使用されている最新の概念とほぼ同じでした。Simulaクラスコンセプトは、AdaのパッケージとModula-2モジュールの先駆者でもありました[12] 1965年に最初に開発された場合でも、Simulaクラスはライブラリファイルに含まれ、コンパイル時に追加される可能性があります。[13]

リンク

ライブラリは、ライブラリモジュールへのリンクまたはシンボルと呼ばれる参照を解決するプログラムのリンクまたはバインディングプロセスで重要です。リンクプロセスは通常、ライブラリと他のモジュールのセットを指定された順序で検索するリンカーまたはバインダープログラムによって自動的に実行されます。通常、特定のライブラリセットでリンクターゲットが複数回見つかった場合、エラーとは見なされません。リンクは、実行可能ファイルが作成されたとき、またはプログラムが実行時に使用されたときに実行できます

解決される参照は、ジャンプやその他のルーチン呼び出しのアドレスである可能性があります。それらはメインプログラムにある場合もあれば、別のモジュールに応じて1つのモジュールにある場合もあります。これらは、参照される各モジュール のメモリセグメントにランタイムメモリを割り当てることにより、(共通ベースからの)固定アドレスまたは再配置可能アドレスに解決されます。

一部のプログラミング言語は、スマートリンクと呼ばれる機能を使用します。これにより、リンカーは外部参照がどのように使用されるかを認識し、ライブラリ内のコードは、内部参照されていても実際には使用されないようになります。コンパイルされたアプリケーションから破棄されます。たとえば、算術演算に整数のみを使用するプログラム、または算術演算をまったく使用しないプログラムでは、浮動小数点ライブラリルーチンを除外できます。このスマートリンク機能により、アプリケーションのファイルサイズが小さくなり、メモリ使用量が減少する可能性があります。

移転

プログラムまたはライブラリモジュール内の一部の参照は、相対形式またはシンボリック形式で保存され、すべてのコードとライブラリに最終的な静的アドレスが割り当てられるまで解決できません。再配置は、これらの参照を調整するプロセスであり、リンカーまたはローダーのいずれかによって実行されます一般に、メモリ内のアドレスは、それらを使用するプログラムやそれらが組み合わされている他のライブラリによって異なる可能性があるため、個々のライブラリ自体に再配置することはできません。位置に依存しないコードは絶対アドレスへの参照を回避するため、再配置は必要ありません。

静的ライブラリ

実行可能ファイルまたは別のオブジェクトファイルの作成中にリンクが実行される場合、静的リンクまたは早期バインディングと呼ばれます。この場合、リンクは通常リンカによって実行されますが、コンパイラによって実行される場合もあります[14]静的ライブラリは、アーカイブとも呼ばれ、静的にリンクすることを目的としたものです。元々、静的ライブラリのみが存在していました。モジュールを再コンパイルするときは、静的リンクを実行する必要があります。

プログラムに必要なすべてのモジュールが静的にリンクされ、実行可能ファイルにコピーされることがあります。このプロセスと結果のスタンドアロンファイルは、プログラムの静的ビルドと呼ばれます。仮想メモリが使用され、アドレス空間配置のランダム化が望ましくない場合、静的ビルドはそれ以上の再配置を必要としない場合があります。[15]

共有ライブラリ

共有ライブラリまたは共有オブジェクトは、実行可能ファイルおよびさらに共有オブジェクトファイルによって共有されることを目的としたファイルです。プログラムで使用されるモジュールは、プログラムの単一のモノリシック実行可能ファイルを作成するときにリンカによってコピーされるのではなく、 ロード時または実行時に個々の共有オブジェクトからメモリにロードされます。

共有ライブラリは、コンパイル時に静的にリンクできます。つまり、ライブラリモジュールへの参照が解決され、実行可能ファイルの作成時にモジュールにメモリが割り当てられます。ただし、共有ライブラリのリンクは、ロードされるまで延期されることがよくあります。[疑わしい ]

最新のオペレーティングシステム[NB2]のほとんどは、実行可能ファイルと同じ形式の共有ライブラリファイルを持つことができます。これには2つの主な利点があります。1つは、2つではなく、両方に対して1つのローダーのみを作成する必要があることです(1つのローダーを使用することで、複雑さを増す価値があると考えられます)。次に、実行可能ファイルにシンボルテーブルがある場合は、実行可能ファイルを共有ライブラリとして使用することもできます一般的な実行可能ファイルと共有ライブラリの組み合わせ形式は、ELFMach-O(両方ともUnix)およびPE(Windows)です。

HP 3000用の16ビットWindowsMPEなどの一部の古い環境では、スタックベースのデータ(ローカル)のみが共有ライブラリコードで許可されていたか、その他の重要な制限が共有ライブラリコードに課されていました。

メモリ共有

ライブラリコードは、ディスク上だけでなく、複数のプロセスによってメモリ内で共有される場合があります。仮想メモリが使用されている場合、プロセスは、プロセスの異なるアドレス空間にマップされているRAMの同じ物理ページを実行します。これには利点があります。たとえば、OpenStepシステムでは、アプリケーションのサイズはわずか数百キロバイトで、すぐに読み込まれることがよくありました。それらのコードの大部分は、オペレーティングシステムによって他の目的ですでにロードされているライブラリにありました。[要出典]

プログラムはUnixのように位置に依存しないコードを使用することでRAM共有を実現できます。これにより、複雑で柔軟なアーキテクチャが実現します。または、WindowsやOS / 2のように共通の仮想アドレスを使用します。これらのシステムは、アドレス空間の事前マッピングや各共有ライブラリのスロットの予約などのさまざまなトリックによって、コードが共有される可能性が高いことを確認します。3番目の選択肢は、 IBM System / 38およびその後継で使用される単一レベルストアです。これにより、位置に依存するコードが可能になりますが、コードを配置できる場所や共有方法に大きな制限はありません。

場合によっては、共有ライブラリのバージョンが異なると問題が発生する可能性があります。特に、バージョンの異なるライブラリのファイル名が同じで、システムにインストールされているアプリケーションごとに特定のバージョンが必要な場合はそうです。このようなシナリオはDLLhellと呼ばれ、 WindowsおよびOS / 2DLLファイルにちなんで名付けられました2001年以降のほとんどの最新のオペレーティングシステムには、このような状況を排除したり、アプリケーション固有の「プライベート」ライブラリを使用したりするためのクリーンアップ方法があります。[16]

ダイナミックリンク

ダイナミックリンクまたは遅延バインディングは、実行可能ファイルが作成されたときではなく、プログラムのロード中(ロード時間)または実行中(ランタイム)に実行されるリンクです。ダイナミックリンクライブラリ(WindowsおよびOS / 2ではダイナミックリンクライブラリ( DLL)、OpenVESでは共有可能イメージ; [17] Unixのようなシステムではダイナミック共有オブジェクト(DSO ))は、ダイナミックリンクを目的としたライブラリです。リンカによって実行される作業は最小限です。実行可能ファイルが作成されたとき。プログラムに必要なライブラリルーチンと、ライブラリ内のルーチンのインデックス名または番号のみを記録します。リンク作業の大部分は、アプリケーションのロード時(ロード時)または実行時(実行時)に実行されます。通常、「ダイナミックリンカー」または「リンクローダー」と呼ばれる必要なリンクプログラムは、実際には基盤となるオペレーティングシステムの一部です。(ただし、動的リンクをサポートしていないオペレーティングシステムであっても、動的リンクを使用し、独自の動的リンカーを含むプログラムを作成することは可能ですが、それほど難しくはありません。)

プログラマーは当初、1964年からMulticsオペレーティングシステムと1960年代後半に構築されたMTS(ミシガンターミナルシステム)でダイナミックリンクを開発しました。[18]

最適化

ほとんどのシステムの共有ライブラリは頻繁に変更されないため、システムは、必要になる前にシステム上の各共有ライブラリのロードアドレスを計算し、その情報をライブラリと実行可能ファイルに保存できます。ロードされるすべての共有ライブラリがこのプロセスを経ている場合、それぞれが所定のアドレスでロードされるため、ダイナミックリンクのプロセスが高速化されます。この最適化は、macOSとLinuxではそれぞれプリバインディングまたはプリリンクとして知られています。IBM z / VMは、「不連続保存セグメント」(DCSS)と呼ばれる同様の手法を使用します。[19]この手法の欠点には、共有ライブラリが変更されるたびにこれらのアドレスを事前計算するために必要な時間、アドレス空間レイアウトのランダム化を使用できないことが含まれます。、および使用するための十分な仮想アドレス空間の要件(少なくとも当面は、 64ビットアーキテクチャの採用によって軽減される問題)。

実行時のライブラリの検索

共有ライブラリのローダーは、機能が大きく異なります。ライブラリへの明示的なパスを格納する実行可能ファイルに依存するものもあります。ライブラリの名前やファイルシステムのレイアウトを変更すると、これらのシステムに障害が発生します。より一般的には、ライブラリの名前(パスではなく)のみが実行可能ファイルに保存され、オペレーティングシステムは、何らかのアルゴリズムに基づいて、ディスク上でライブラリを検索するメソッドを提供します。

実行可能ファイルが依存する共有ライブラリが削除、移動、または名前変更された場合、または互換性のないバージョンのライブラリが検索の早い場所にコピーされた場合、実行可能ファイルのロードに失敗します。これは依存関係地獄と呼ばれ、多くのプラットフォームに存在します。(悪名高い)Windowsの亜種は一般的にDLL地獄として知られています各ライブラリの各バージョンが一意に識別され、各プログラムが完全に一意の識別子によってのみライブラリを参照する場合、この問題は発生しません。以前のWindowsバージョンでの「DLL地獄」の問題は、プログラム内の動的リンクを解決するために、一意であることが保証されていないライブラリの名前のみを使用することから発生しました。(「DLL地獄」を回避するために、Windowsの新しいバージョンは、共有システムDLLが以前のバージョンに置き換えられないようにするメカニズムとともに、プライベートDLLをインストールするプログラムのオプション(基本的には共有ライブラリの使用からの部分的な撤退)に大きく依存しています。 )。

Microsoft Windows

Microsoft Windowsはレジストリをチェックして、COMオブジェクトを実装するDLLをロードする適切な場所を決定しますが、他のDLLの場合は、定義された順序でディレクトリをチェックします。まず、Windowsはプログラムをロードしたディレクトリをチェックします(プライベートDLL [16])。SetDllDirectory()関数を呼び出して設定されたディレクトリ。System32、System、およびWindowsディレクトリ。次に、現在の作業ディレクトリ。最後に、PATH環境変数で指定されたディレクトリ。[20] .NET Framework用に作成されたアプリケーション(2002年以降)では、共有dllファイルのプライマリストアとしてグローバルアセンブリキャッシュもチェックして、DLL地獄

OpenStep

OpenStepは、より柔軟なシステムを使用し、システムが最初に起動したときに、いくつかの既知の場所(PATHの概念と同様)からライブラリのリストを収集しました。ライブラリを移動しても問題はまったく発生しませんが、ユーザーは最初にシステムを起動するときに時間のコストがかかります。

Unixライクなシステム

ほとんどのUnixライクなシステムには、ダイナミックライブラリを検索するファイルシステムディレクトリを指定する「検索パス」があります。一部のシステムは構成ファイルでデフォルトパスを指定し、他のシステムはそれをダイナミックローダーにハードコーディングします。一部の実行可能ファイル形式では、特定のプログラムのライブラリを検索するための追加のディレクトリを指定できます。これは通常、環境変数でオーバーライドできますが、 setuidでは無効になっていますそしてsetgidプログラム。これにより、ユーザーはそのようなプログラムにroot権限で任意のコードを実行させることができなくなります。ライブラリの開発者は、ダイナミックライブラリをデフォルトの検索パスの場所に配置することをお勧めします。欠点として、これにより新しいライブラリのインストールが問題になる可能性があり、これらの「既知の」場所はすぐにライブラリファイルの数が増え、管理がより複雑になります。

動的ローディング

動的リンクのサブセットである動的ロードには、要求に応じて実行時に動的にリンクされたライブラリのロードとアンロードが含まれます。このような要求は、暗黙的または明示的に行うことができます。コンパイラまたは静的リンカがファイルパスまたは単にファイル名を含むライブラリ参照を追加すると、暗黙の要求が行われます。[要出典]アプリケーションがオペレーティングシステムのAPIを直接呼び出すと、明示的な要求が行われます。

ダイナミックリンクライブラリをサポートするほとんどのオペレーティングシステムは、ランタイムリンカーAPIを介してそのようなライブラリを動的にロードすることもサポートしています。たとえば、Microsoft Windowsは、API関数LoadLibrary、、およびMicrosoftダイナミックリンクライブラリLoadLibraryExを使用ます。ほとんどのUNIXおよびUNIXライクなシステムを含むPOSIXベースのシステムは、およびを使用します。一部の開発システムは、このプロセスを自動化します。 FreeLibraryGetProcAddressdlopendlclosedlsym

オブジェクトライブラリ

もともとは1960年代に開拓されましたが、ダイナミックリンクは1980年代後半まで消費者が使用するオペレーティングシステムに到達しませんでした。1990年代初頭までに、ほとんどのオペレーティングシステムで何らかの形で一般的に利用可能になりました。この同じ時期に、オブジェクト指向プログラミング(OOP)は、プログラミング環境の重要な部分になりつつありました。ランタイムバインディングを使用するOOPには、従来のライブラリでは提供されない追加情報が必要です。中にあるコードの名前とエントリポイントに加えて、依存するオブジェクトのリストも必要です。これは、OOPの主な利点の1つである継承の副作用です。つまり、メソッドの完全な定義の一部が異なる場所にある可能性があります。これは、あるライブラリが別のライブラリのサービスを必要とすることを単にリストするだけではありません。真のOOPシステムでは、ライブラリ自体はコンパイル時に認識されない場合があり、システムごとに異なります。

同時に、多くの開発者は、デスクトップコンピュータで実行される「ディスプレイ」がデータの保存または処理にメインフレームまたはミニコンピュータのサービスを使用する多層プログラムのアイデアに取り組みました。たとえば、GUIベースのコンピューター上のプログラムは、ミニコンピューターにメッセージを送信して、表示用に巨大なデータセットの小さなサンプルを返します。リモートプロシージャコール(RPC)はすでにこれらのタスクを処理していましたが、標準のRPCシステムはありませんでした。

すぐに、ミニコンピューターとメインフレームのベンダーの大多数は、2つを組み合わせるプロジェクトを推進し、どこでも使用できるOOPライブラリ形式を作成しました。このようなシステムは、リモートアクセスをサポートしている場合は、オブジェクトライブラリまたは分散オブジェクトと呼ばれていました(すべてがサポートされているわけではありません)。MicrosoftのCOMは、ローカルで使用するためのそのようなシステムの例です。COMの修正バージョンであるDCOMは、リモートアクセスをサポートしています。

しばらくの間、オブジェクトライブラリはプログラミングの世界で「次の大きなもの」のステータスを保持していました。プラットフォーム間で実行されるシステムを作成するための多くの取り組みがあり、企業は開発者を自社のシステムに閉じ込めようと競い合いました。例としては、IBMシステムオブジェクトモデル(SOM / DSOM)、SunMicrosystemsDistributedObjects Everywhere(DOE)、NeXTPortable Distributed Objects(PDO)、DigitalObjectBroker、MicrosoftのComponent Object Model(COM / DCOM)、任意の数のCORBAベースのシステム。

クラスライブラリ

クラスライブラリは、古いタイプのコードライブラリとほぼ同等のOOPです。それらには、特性を記述し、オブジェクトを含むアクション(メソッド)を定義するクラスが含まれています。クラスライブラリは、特定の値に設定された特性を持つインスタンスまたはオブジェクトを作成するために使用されます。Javaなどの一部のOOP言語では、クラスがライブラリファイル(JavaのJARファイル形式など)に含まれることが多く、インスタンス化されたオブジェクトがメモリ内にのみ存在する(ただし、個別のファイルに永続化できる可能性があります)ため、区別は明確です。Smalltalkのように、クラスライブラリは単なる出発点にすぎません。環境、クラス、およびインスタンス化されたすべてのオブジェクトの状態全体を含む システムイメージ。

現在、ほとんどのクラスライブラリはパッケージリポジトリ(Maven Central for Javaなど)に保存されています。クライアントコードは、ビルド構成ファイル(JavaのMaven Pomなど)で外部ライブラリへの依存関係を明示的に宣言します。

リモートライブラリ

ライブラリの問題に対する別の解決策は、完全に別個の実行可能ファイル(多くの場合、軽量形式)を使用し、ネットワーク経由で別のコンピューターへのリモートプロシージャコール(RPC)を使用してそれらを呼び出すことです。このアプローチにより、オペレーティングシステムの再利用が最大化されます。ライブラリをサポートするために必要なコードは、他のすべてのプログラムにアプリケーションのサポートとセキュリティを提供するために使用されるコードと同じです。さらに、このようなシステムでは、ライブラリが同じマシン上に存在する必要はありませんが、ネットワークを介して要求を転送できます。

ただし、このようなアプローチは、すべてのライブラリ呼び出しにかなりのオーバーヘッドが必要になることを意味します。RPC呼び出しは、同じマシンにすでにロードされている共有ライブラリを呼び出すよりもはるかにコストがかかります。このアプローチは、このようなリモート呼び出しを多用する分散アーキテクチャ、特にクライアントサーバーシステムやEnterpriseJavaBeansなどのアプリケーションサーバーで一般的に使用されます。

コード生成ライブラリ

コード生成ライブラリは、 Javaのバイトコード生成または変換できる高レベルのAPIです。これらは、アスペクト指向プログラミング、一部のデータアクセスフレームワーク、および動的プロキシオブジェクトを生成するためのテストで使用されます。また、フィールドアクセスを傍受するためにも使用されます。[21]

ファイルの命名

最新のUnixライクなシステム

システムは、、、などディレクトリlibfoo.aにファイルを保存しますファイル名は常に。で始まり、 アーカイブ、静的ライブラリ)または(共有オブジェクト、ダイナミックリンクライブラリ)のサフィックスで終わります。一部のシステムでは、動的にリンクされたライブラリに複数の名前が付けられている場合があります。これらの名前は通常、同じプレフィックスを共有し、バージョン番号を示す異なるサフィックスを持っています。ほとんどの名前は、最新バージョンへのシンボリックリンクの名前です。たとえば、一部のシステムでは、ダイナミックリンクライブラリの2番目のメジャーインターフェイスリビジョンのファイル名になりますライブラリディレクトリで時々見つかるファイルはlibtoolですlibfoo.so/lib/usr/lib/usr/local/liblib.a.solibfoo.so.2libfoo.laアーカイブ。システム自体では使用できません。

macOS

システムは、 BSDから静的ライブラリの規則を継承し、ライブラリは.aファイルに保存され、.so動的にリンクされたスタイルのライブラリを使用できます(.dylib代わりに接尾辞が付きます)。ただし、macOSのほとんどのライブラリは「フレームワーク」で構成されており、ライブラリに必要なファイルとメタデータをラップする「バンドル」と呼ばれる特別なディレクトリ内に配置されています。たとえば、と呼ばれるフレームワークは、と呼ばMyFrameworkれるバンドルに実装され、動的にリンクされたライブラリファイルであるか、の動的にリンクされたライブラリファイルへのシンボリックリンクになりますMyFramework.frameworkMyFramework.framework/MyFrameworkMyFramework.framework/Versions/Current/MyFramework

Microsoft Windows

ダイナミックリンクライブラリには通常、接尾辞*.DLL[ 22]*.OCXが付いていますが、他のファイル名拡張子は、OLEライブラリなど、特定の目的のダイナミックリンクライブラリを識別する場合があります。インターフェイスのリビジョンは、ファイル名にエンコードされるか、COMオブジェクトインターフェイスを使用して抽象化されます。ファイルのコンパイル方法に応じて、*.LIBファイルは静的ライブラリ、またはコンパイル中にのみ必要な動的にリンク可能なライブラリの表現のいずれかになります。これは「ライブラリのインポート」と呼ばれます。異なるファイル拡張子を使用するUNIXの世界とは異なり、 Windows.LIBでファイルに対してリンクする場合最初に、それが通常の静的ライブラリなのかインポートライブラリなのかを知る必要があります。後者の場合、.DLL実行時にファイルが存在する必要があります。

も参照してください

メモ

  1. ^ たとえば、Adaサブプログラム間で以前に可能でした。
  2. ^ 一部の古いシステム、たとえばBurroughs MCP Multicsも、共有されているかどうかに関係なく、実行可能ファイルの形式は1つだけです。

参考文献

  1. ^ dx.doi.orgdoi10.1107 / s1600576715005518 / fs5094sup1.ziphttp ://dx.doi.org/10.1107/s1600576715005518/fs5094sup1.zip 2021-05-27を取得 {{cite journal}}欠落または空|title=ヘルプ
  2. ^ Deshpande、Prasad。関数呼び出しグラフ分析(論文)を使用した変成検出。サンノゼ州立大学図書館。土井10.31979 /etd.t9xm-ahsc
  3. ^ 「静的ライブラリ」TLDP。2013年7月3日にオリジナルからアーカイブされまし2013年10月3日取得
  4. ^ ゴールドスタイン、ハーマンH.(2008-12-31)。パスカルからフォンノイマンまでのコンピュータープリンストン:プリンストン大学出版局。土井10.1515 / 9781400820139ISBN 978-1-4008-2013-9
  5. ^ ゴールドスタイン、ハーマン; フォンノイマン、ジョン(1947)。電子計算機の問題の計画とコーディング(レポート)。高等研究所。p。3、21〜22。OCLC26239859_ サブルーチンの広範な「ライブラリ」を開発することはおそらく非常に重要です。 
  6. ^ ウィルクス、MV(1951)。EDSACコンピューター要件知識の管理に関する1951年の国際ワークショップ。IEEE。土井10.1109 /afips.1951.13
  7. ^ キャンベルケリー、マーティン(2011年9月)。「 『ウィルクス、ウィーラー、ギル』を称えて」" 。ACM通信。54(9)25–27。doi10.1145 / 1995376.1995386。S2CID20261972 
  8. ^ ウィルクス、モーリス; ウィーラー、デビッド; ギル、スタンレー(1951)。電子デジタルコンピュータのためのプログラムの準備アディソン-ウェスリー。p。45、80〜91、100。OCLC641145988 _ _ 
  9. ^ Wexelblat、Richard(1981)。プログラミング言語の歴史ACMモノグラフシリーズ。ニューヨーク州ニューヨーク:Academic Press(Harcourt Braceの子会社)。p。 274ISBN 0-12-745040-8
  10. ^ Wexelblat、 op。引用。、p。258
  11. ^ ウィルソン、レスリーB。; クラーク、ロバートG.(1988)。比較プログラミング言語イギリス、ウォーキンガム:アディソン-ウェスリー。p。126. ISBN 0-201-18483-4
  12. ^ ウィルソンとクラーク、 op。引用。、p。52
  13. ^ Wexelblat、 op。引用。、p。716
  14. ^ Kaminsky、Dan(2008)、"Portable Executable and Executable and Linking Formats"Reverse Engineering Code with IDA Pro、Elsevier、pp。37–66、doi10.1016 / b978-1-59749-237-9.00003-xISBN 978-1-59749-237-92021-05-27を取得
  15. ^ Christian Collberg、John H. Hartman、Sridivya Babu、Sharath K. Udupa(2003)。「SLINKY:静的リンクがリロードされました」アリゾナ大学コンピュータサイエンス学部2016-03-23にオリジナルからアーカイブされました2016年3月17日取得{{cite web}}:CS1 maint:作成者パラメーターを使用します(リンク
  16. ^ a b アンダーソン、リック(2000-01-11)。「DLL地獄の終わり」microsoft.com。2001年6月5日にオリジナルからアーカイブされまし2012年1月15日取得プライベートDLLは、特定のアプリケーションとともにインストールされ、そのアプリケーションによってのみ使用されるDLLです。
  17. ^ 「VSIOpenVMSリンカーユーティリティマニュアル」(PDF)VSI。2019年8月2021-01-31を取得
  18. ^ 「MTSの歴史」。情報技術ダイジェスト5(5)。
  19. ^ IBM Corporation(2011)。保存されたセグメントの計画と管理(PDF)2022-01-29を取得
  20. ^ 「ダイナミックリンクライブラリの検索順序」Microsoft Developer NetworkLibraryマイクロソフト。2012-03-06。2012-05-09にオリジナルからアーカイブされました2012年5月20日取得
  21. ^ 「コード生成ライブラリ」SourceForge2010年1月12日にオリジナルからアーカイブされました2010年3月3日取得バイトコード生成ライブラリは、JAVAバイトコードを生成および変換するための高レベルAPIです。これは、動的プロキシオブジェクトを生成し、フィールドアクセスをインターセプトするために、AOP、テスト、データアクセスフレームワークによって使用されます。
  22. ^ ブレスナハン、クリスティン; ブルム、リチャード(2015-04-27)。LPIC-1 Linux Professional Institute認定学習ガイド:試験101-400および試験102-400John Wiley&Sons(2015年公開)。p。82. ISBN  97811190211862015年9月24日にオリジナルからアーカイブされました2015年9月3日取得Linux共有ライブラリは、Windowsのダイナミックリンクライブラリ(DLL)に似ています。Windows DLLは通常、.dllファイル名拡張子で識別されます。

さらに読む