ライブラリ
Unix系システムでは、ライブラリを探す場所(ディレクトリ)を構成ファイルにリストアップしておく。ライブラリ開発者はそこに書かれたディレクトリにライブラリを配置することを推奨される。しかし、この方法では新しいライブラリをインストールする際に問題が発生しやすく、共通のディレクトリにあまりにも多くのライブラリが置かれることとなって管理を難しくする。Windowsではレジストリを使ってCOMコンポーネントやActiveX DLLの場所を決めているが、標準DLLでは、
アプリケーションの実行ファイルの存在するディレクトリ
SetDllDirectory()で指定されるディレクトリ(Windows XP SP1以降でサポート)
システムディレクトリ (NT系ではSystem32)
16ビットシステムディレクトリ (System)
Windowsディレクトリ
カレントディレクトリ
PATH環境変数
で示されるディレクトリを探す(古いバージョンではカレントディレクトリが2番目だった)。OPENSTEPはもっと柔軟なシステムを使用していて、ライブラリの探索リストを保持している。しかし不正なDLLが探索の上位に置かれていると実行ファイルは不正動作する可能性がある。Windowsではこれが「DLL地獄」(英: DLL hell)と呼ばれ、よく知られている問題である。
Windows XPからはSide-by-Sideアセンブリ(DLL署名、WinSxS)というメカニズムが追加された。
WindowsのDLLはUNIXから見れば共有ライブラリではない。(訳注:UNIXでもライブラリのマップすべきアドレスを決めている場合がある。ただしそれは性能向上目的であり、基本的にはPIC化されている。)
最近のOSでは共有ライブラリは通常の実行ファイルと同じ形式になっている。これにはふたつの利点がある。第一はひとつのローダで両方をロードできる。それによってローダが若干複雑化するが、十分コストに見合う程度である。第二はシンボルテーブルさえあれば実行ファイルを共有ライブラリとして使うことができる点である。このようなファイル形式として、ELF (UNIX) と PE (Windows) がある。また、Windowsではフォントなどのリソースも同じファイル形式になっている。OPENSTEPでもほとんど全てのシステムリソースが同じファイル形式になっている。
DLLという用語はWindowsやOS/2で主に使われる。UNIXでは「共有ライブラリ」が一般的である。
マルチスレッド環境下でライブラリを使用するにあたっては、別の共有問題が発生する。ライブラリルーチンがデータ領域としてスタックのみを使う場合は問題ないが、ライブラリ内のデータ領域を使う場合、そのデータ領域がスレッド毎に用意されていないことが多い。したがって、そのようなライブラリルーチンを使う場合、実行ファイル側で同時に複数のスレッドが同じライブラリルーチンを使わないように注意しなければならないことがある。