ライブラリ
[Wikipedia|▼Menu]
.mw-parser-output .ambox{border:1px solid #a2a9b1;border-left:10px solid #36c;background-color:#fbfbfb;box-sizing:border-box}.mw-parser-output .ambox+link+.ambox,.mw-parser-output .ambox+link+style+.ambox,.mw-parser-output .ambox+link+link+.ambox,.mw-parser-output .ambox+.mw-empty-elt+link+.ambox,.mw-parser-output .ambox+.mw-empty-elt+link+style+.ambox,.mw-parser-output .ambox+.mw-empty-elt+link+link+.ambox{margin-top:-1px}html body.mediawiki .mw-parser-output .ambox.mbox-small-left{margin:4px 1em 4px 0;overflow:hidden;width:238px;border-collapse:collapse;font-size:88%;line-height:1.25em}.mw-parser-output .ambox-speedy{border-left:10px solid #b32424;background-color:#fee7e6}.mw-parser-output .ambox-delete{border-left:10px solid #b32424}.mw-parser-output .ambox-content{border-left:10px solid #f28500}.mw-parser-output .ambox-style{border-left:10px solid #fc3}.mw-parser-output .ambox-move{border-left:10px solid #9932cc}.mw-parser-output .ambox-protection{border-left:10px solid #a2a9b1}.mw-parser-output .ambox .mbox-text{border:none;padding:0.25em 0.5em;width:100%;font-size:90%}.mw-parser-output .ambox .mbox-image{border:none;padding:2px 0 2px 0.5em;text-align:center}.mw-parser-output .ambox .mbox-imageright{border:none;padding:2px 0.5em 2px 0;text-align:center}.mw-parser-output .ambox .mbox-empty-cell{border:none;padding:0;width:1px}.mw-parser-output .ambox .mbox-image-div{width:52px}html.client-js body.skin-minerva .mw-parser-output .mbox-text-span{margin-left:23px!important}@media(min-width:720px){.mw-parser-output .ambox{margin:0 10%}}

この記事は検証可能参考文献や出典が全く示されていないか、不十分です。出典を追加して記事の信頼性向上にご協力ください。(このテンプレートの使い方
出典検索?: "ライブラリ" ? ニュース ・ 書籍 ・ スカラー ・ CiNii ・ J-STAGE ・ NDL ・ dlib.jp ・ ジャパンサーチ ・ TWL(2019年10月)
.mw-parser-output .hatnote{margin:0.5em 0;padding:3px 2em;background-color:transparent;border-bottom:1px solid #a2a9b1;font-size:90%}

この項目では、コンピュータプログラムについて説明しています。書籍や資料などの閲覧・貸出などを行う施設については「図書館」を、その他の用法については「ライブラリー (曖昧さ回避)」をご覧ください。

ライブラリ(: library)は、汎用性の高い複数のプログラムを再利用可能な形でひとまとまりにしたものである。ライブラリと呼ぶときは、それ単体ではプログラムとして動作させることはできない、つまり実行ファイルではない場合がある。ライブラリは他のプログラムに何らかの機能を提供するコードの集まりと言える。ソースコードの場合と、オブジェクトコード、あるいは専用の形式を用いる場合とがある。たとえば、UNIXのライブラリはオブジェクトコードをarと呼ばれるアーカイブツール(アーカイバ)でひとまとめにして利用する。図書館(: library)と同様にプログラム(算譜)の書庫であるので、索引方法が重要である。

また、ソフトウェア以外の再利用可能なものの集合について使われることもある(音声データなど)。
動的リンク

動的リンク (: dynamic linking) は、あるライブラリ内のデータ(コードを含む)を新たな実行ファイルのビルド時にコピーすることはなく、ディスク上に別のファイルとして存在している。ビルド時にリンカが行うのは、その実行ファイルが必要とするのがどのライブラリのどの部分であるか(関数名やインデックス)を記録するだけである。リンク作業の大部分はそのアプリケーションがメモリ上にロードされたときか、実行時である。リンクを行うプログラムコードはローダ: loader)と呼ばれ、実際にはオペレーティングシステム (OS) の一部と見なされる。適当な時点でローダは必要なライブラリをディスク上で見つけてプロセスメモリ空間に(追加のデータ空間と共に)マッピングする。OSによってはプロセスが実行開始する前でないとライブラリをリンクできないものもあるが、多くのOSではプロセス実行時に実際にライブラリを参照したときにリンクできる。後者は「遅延読み込み」などと呼ばれる。どちらの場合もライブラリは動的リンクライブラリ(ダイナミックリンクライブラリ)と呼ばれる。Windows環境では動的リンクライブラリの略称でもある「DLL」という呼び方が一般的であり、動的ライブラリのファイル拡張子は通例 .dll である[1]。動的リンクライブラリの中でも、システム上の複数の実行プログラムによって共有・再利用されうるものを、共有ライブラリ(シェアードライブラリ)と呼ぶ。

ローダの処理は、メモリ上の各ライブラリの位置が実際にロードされるまで確定しないため、ちょっとしたトリックを必要とする。ディスク上のファイル内に絶対アドレスを書きこんでおくことはDLL内であっても不可能である。理論的にはメモリにロードされたときにライブラリを参照している部分を全て書き換えて正しいメモリ上の位置を参照するようにすることはできるが、それによって消費される時間とメモリは無視できない。その代わりに多くの動的リンクシステムではアドレス欄が空欄となったシンボルテーブルをコンパイル時に用意する。ライブラリへの参照は全てこのシンボルテーブルを経由して行われる(コンパイラはシンボルテーブルからアドレスを取り出して使うコードを生成する)。メモリにロードされたとき、ローダがこのテーブルを書き換える。

ライブラリも全メソッド(関数、サブルーチン)のテーブルを持っている。ライブラリに入ってくるときは、このテーブルを経由して各ルーチンにジャンプする。これによってライブラリのルーチンコールにオーバーヘッドが発生するが、通例それは無視できるほど小さい。

動的リンカ・ローダは機能面で様々なものがある。いくつかの場合、実行ファイルに格納された明示的なライブラリパスに依存し、ライブラリ名やディスク上の配置を変更するとシステムが作動できなくなる。より一般的な手法としてはライブラリ名だけを実行ファイルに格納し、OSが何らかのアルゴリズムでディスク上のライブラリを検索する。Unix系システムでは、ライブラリを探す場所(ディレクトリ)を構成ファイルにリストアップしておく。ライブラリ開発者はそこに書かれたディレクトリにライブラリを配置することを推奨される。しかし、この方法では新しいライブラリをインストールする際に問題が発生しやすく、共通のディレクトリにあまりにも多くのライブラリが置かれることとなって管理を難しくする。Windowsではレジストリを使ってCOMコンポーネントやActiveX DLLの場所を決めているが、標準DLLでは、
アプリケーションの実行ファイルの存在するディレクトリ

SetDllDirectory()で指定されるディレクトリ(Windows XP SP1以降でサポート)

システムディレクトリ (NT系ではSystem32)

16ビットシステムディレクトリ (System)

Windowsディレクトリ

カレントディレクトリ

PATH環境変数

で示されるディレクトリを探す(古いバージョンではカレントディレクトリが2番目だった)[2]OPENSTEPはもっと柔軟なシステムを使用していて、ライブラリの探索リストを保持している。しかし不正なDLLが探索の上位に置かれていると実行ファイルは不正動作する可能性がある。Windowsではこれが「DLL地獄」(: DLL hell)と呼ばれ、よく知られている問題である。

Windows XPからはSide-by-Sideアセンブリ(DLL署名、WinSxS)というメカニズムが追加された。これは動的リンク時にライブラリのファイル名ではなく、ライブラリにつけられた署名によってリンクすべきライブラリを決定するものである。これにより、同じファイル名を持つが異なる実装を持つライブラリを同時に使い分ける事ができる。よくあるパターンとして、ソースコードから改変・ビルドされたランタイムライブラリをシステムにインストールする場合にこのメカニズムが有効に働く。システムにインストールされたライブラリはライブラリ探索リスト上比較的上位に存在するが、署名が一致するプログラムにのみロードされるのでDLL地獄は今後解消されるであろうと考えられる。しかし、この機構には一つの弱点がある。それはシステムライブラリをオーバーライドして独自機能を実装する時、この機構は役に立たない方向へ働く。その様な実装をする時には、故意にマニフェスト機能を無効にしてライブラリを作らなくてはならない。もっとも、そのようなアプローチは、システムファイル保護機能が搭載されたWindows 2000のリリース時点で時代遅れであり、Windows Vistaに至っては管理者と言えどもシステムライブラリを書き換える事は出来なくなっている。

動的ライブラリの起源は定かではないが、少なくとも1960年代後半のMTS (Michigan Terminal System) まで遡ることができる ("A History of MTS", Information Technology Digest, Vol. 5, No. 5)。
動的読み込み

動的読み込み (: dynamic loading) は動的リンクの下位カテゴリであり、ビルド時にリンク(暗黙的リンク、: implicit linking)されたもの以外のダイナミックリンクライブラリを、実行中のプログラムが明示的にロードすることである。明示的リンク (: explicit linking) と呼ばれることもある[3]。この場合、ライブラリはプラグインモジュールとして使われるのが一般的で、表計算プログラムのadd-inや特定機能を実現するインタプリタなどが典型的である。

動的ライブラリをサポートしているシステムは、モジュールの動的読み込みAPIもサポートしているのが一般的である。例えばWindowsではLoadLibrary()とGetProcAddress()が用意されていて、Unix系システムではdlopen()とdlsym()が用意されている。いくつかの開発環境ではこの処理を自動化している。逆に、不要になったモジュールを解放(アンロード)するAPI(FreeLibrary()やdlclose())も用意されている。これらのAPIは、特にユーザーによる機能拡張を可能とするプラグインシステムをアプリケーション内に実装することにも役立つ。


次ページ
記事の検索
おまかせリスト
▼オプションを表示
ブックマーク登録
mixiチェック!
Twitterに投稿
オプション/リンク一覧
話題のニュース
列車運行情報
暇つぶしWikipedia

Size:28 KB
出典: フリー百科事典『ウィキペディア(Wikipedia)
担当:undef