「ＤＬＬ」は知ってるけど…… 　「ＤＬＬ」。この名称は「Ｄｙｎａｍｉｃ　Ｌｉｎｋ　Ｌｉｂｒａｒｙ」の略です。日本語に訳すと「動的にリンクするライブラリ」といったところでしょうか＜一語しか訳してないやん。 　通常アプリケーションを作製する場合、「各ファイルをコンパイルする」−「作製されたオブジェクトファイルをリンクする」という手順（いわゆる「ビルド」と呼ばれるもの）を踏んで「実行ファイル（Ｅｘｅファイル）」が作製されます。 　アプリケーションはいっぺんにすべてが作られるわけではなく、ソースファイル単位でまず「コンパイラ」が「オブジェクトファイル」というものを作り、次に「リンカ」が各オブジェクトファイルをくっつけ、「実行ファイル」にします。 　この「ビルド時にリンクする」ことを「静的（Ｓｔａｔｉｃ）リンク」と呼びます。 　このソースコードの一部を実行ファイルとは別に作製したものが、ＤＬＬです。 　実行ファイルとＤＬＬは、別々に作製されます。ＤＬＬも実行ファイルと同じ手順、コンパイルを行い、リンクをして、作製されます。実行ファイルも、ソースの一部がない状態で、コンパイルされ、リンクが行われて、作製されます。こうして、元はひとつだったファイルがふたつに分かれたことになります。 　ＤＬＬへのリンクは、実行ファイルが「実行」された時に行われます。実行ファイルはまず実行ファイルのあるフォルダからＤＬＬを探し、カレントフォルダからＤＬＬを探し、システムフォルダからＤＬＬを探し、ウィンドウズフォルダからＤＬＬを探します。 　ＤＬＬが見つかったら、実行ファイルはＤＬＬへとリンクします。こうしてふたつのファイルはひとつの実行ファイルと同じ機能を持つことになるというわけです。このリンクを「動的（Ｄｙｎａｍｉｃ）リンク」と呼びます。 　このように、ＤＬＬとは「実行するときだけリンクされる、プログラムの一部」なのです。

ＤＬＬを使うメリットとデメリット 　ＤＬＬを使うメリットとデメリットは、なんでしょうか。 　メリットはまず「ファイルサイズの節約」でしょう。ある関数やクラスをいくつものアプリケーションで使う場合、その関数やクラスをＤＬＬの中に入れてしまえば、単純計算で「ＤＬＬのサイズ×（アプリの数−１）」だけの節約になります。 　メリットとデメリットが同時に存在するのが、「同じコードの省略」です。プログラムの中で似たコードをできるだけ作らないのが、バグを減らすコツのひとつです。これはアプリケーション単位の話ですが、ＤＬＬを用いればさらに複数のアプリケーション内の同一コードを省略して、ひとつにまとめることができることになります。 　ですが、これは逆に言えば「そのＤＬＬにバグがあれば、それを使用するすべてのアプリに影響が出る」ということになります。このデメリットは皆さんイヤというほど味わっているでしょう（泣）。 　ただし、このバグを修正する場合、「このＤＬＬを書き換えるだけですべてのアプリが正常に戻る」ということにもなります。これまた「サービスパック」という形でイヤというほど味わっているでしょう（爆）。アプリケーションのサイズが大きい場合、ユーザーがダイヤルアップでダウンロードしなければならない場合等、小さなモジュールで修正できるというメリットは比較的大きいと言えます。 　別に、「ＤＬＬに使うコードは元々多く存在しなければならない」ということはなく、たった一度しか使われないような希有なコードを入れることもあります。例えば、その希有なコードを組めるスタッフがいなくて、外注しなければならない場合、その完成品をＤＬＬとして受け取ることで、実行ファイルとＤＬＬを別プロジェクトとして平行作業することができます。 　仕様書の上で「ここの関数はこういう呼び出しにする」ということをあらかじめ決めておくことで、実行ファイル側のプロジェクトと、ＤＬＬ側のプロジェクトが別々に作業を進めることができます。そして、最後にふたつを一緒のフォルダに入れて実行するだけで、結果が分かります。また、途中のテストも、同期を取る必要がなくなります。 　しかしこれは逆に、「ＤＬＬを作ること自体がプロジェクトになる」ということを示しています。実際、コードをふたつに分けてＤＬＬに入れるだけでも、結構手間がかかります。こういう場合、できればＭＳＤＥＶをふたつ起動して、同時に作製するのがいいでしょう（かなりメモリを食いますが）。 　ＤＬＬは、システムフォルダにインストールされることで、そのＤＬＬをすべてのアプリケーションが使用できるようになります。のちほど説明しますが、すべてのウィンドウズＡＰＩは、ＤＬＬ内の関数として提供されています。つまり、システムフォルダのＤＬＬはそのままウィンドウズのシステムとなるということです。 　また、シェルエクステンション――例えば特定のファイルにプロパティシートを追加したり、特定のフォルダを特殊な機能を持ったフォルダにしたり――を行う場合、これらの機能を実現する「ＣＯＭインターフェイス」も、ＤＬＬに組み込んで使用します。また、コントロールパネル（拡張子ｃｐｌのファイル）も、ＤｅｌｐｈｉやＶＢでおなじみのＡｃｔｉｖｅＸも、ＤＬＬとほとんど同じものです。これらも「システム」として機能し、すべてのアプリケーションが共有します。 　それと、「システムフック」と「サブクラス化」という、ユーティリティアプリケーションにとって非常に強い味方となるこのふたつの機能を使用する場合、ＤＬＬを必ず使わなければならないのです。 　実は、この講座の最終目的として、このふたつを使いこなすというものがあります（予定ですが）。そのためにも、まずＤＬＬというものについてしっかりと理解しておきたい、というわけです。

「ライブラリファイル」のあるＤＬＬを使ってみよう！！ 　さて、では実際にＤＬＬをアプリケーションで使ってみましょう！！ 　ＤＬＬを使う場合、「ライブラリファイル（拡張子がＬｉｂのファイル）」を使う場合と使わない場合で大きく違います。今回は使ってみましょう（使わない方法は次回説明します）。 　今回サンプルとして使ってみるＤＬＬおよびその中の関数を説明します。今回使用するのはsndPlaySound()という関数です。この関数はＡＰＩに区分されますが、その中でも「マルチメディアＡＰＩ」と呼ばれるものです。マルチメディアＡＰＩは、音を鳴らしたり、動画を表示したりといったまさに「マルチメディア」な機能を持ったＡＰＩグループです。ＤｉｒｅｃｔＸのようなばりばりの機能は持っていませんが、アプリケーションでちょっと何かしたいな、という時くらいには十分役立ちます。 　今回使用するsndPlaySound()は、音を鳴らす関数です。ＷＡＶファイルを読み込み、再生するだけの機能を持つ関数です。ＭＦＣはマルチメディアＡＰＩをサポートしていないので、デフォルトではこの関数を使うことはできません。自分で、このＡＰＩを持つＤＬＬへとリンクするようなプログラムを書く必要があるということです。その方法を、これから解説します。 　まず、最初に「Ｗｉｎ３２ＳＤＫヘルプ」のsndPlaySound()のページを見てください。英語で色々書かれていますねー。そのページの一番上の行。関数名の右隣にみっつのボタンがありますね。その一番左の「Quick Info」のボタンを押してください。 　そうすると、この関数のリファレンスページが表示されます。このページは非常に重要です！！　特に重要なのが、５行目のImport Library、６行目のHeader Fileの欄です。 　Import Libraryは、プログラムを組むときに使う情報が入っている「ライブラリファイル」のファイル名です。これが、プログラムを組むときに必要になってきます。 　Header Fileは説明しなくても大丈夫でしょう。この関数のプロトタイプ宣言が書かれたヘッダーファイル名です。この関数を使うソースファイルで、このヘッダーファイルをインクルードすればいいわけです。

ライブラリファイル 　コンパイルが終了してＯｂｊファイルがいっぱいできた後、リンカは「このオブジェクトファイルが使ってる関数はどのオブジェクトファイルにあるのかなー」と調べます。その中から見つからないと、「ぐがっ、てことはＤＬＬかぁ！？」と、今度は「ライブラリファイル」を検索します。 　検索するライブラリファイルのリストは「プロジェクト」−「設定」ダイアログの「リンク」ページ・「一般」カテゴリ・「オブジェクト／ライブラリモジュール」の中に書かれているものです。え？　何もかかれてないって？　さてはあなた、ＭＦＣプログラムしかしてませんね。早速、素の「Win32 Application」を作製して同じ欄を見てみましょう。kernel32.lib user32.lib gdi32.lib...とずらーっと書いてあるでしょう。ＭＦＣはちょっとした工夫で隠してあるだけです（この部分はのちほど説明）。 　さて、見つからない関数があった場合、この「検索ライブラリファイルのリスト」の順に、ライブラリファイルを調べて「関数があるか」チェックします。 　では、「ライブラリファイル」とはなんなんでしょうか。 　「ライブラリファイル」は、ＤＬＬの作成時に一緒に作製されるファイルです。ＤＬＬの中の「外から使われるための関数・クラス」は、特別に外から分かる形になってコンパイルされます（これを「エクスポート」といいます）。このとき、「作製されたＤＬＬのファイル名（基本的にライブラリファイルの拡張子違い）」と「エクスポートされた関数・クラス」が、ライブラリファイルに書き込まれます。 　「関数どこかなー」とリンカは、ライブラリファイルの中の関数を検索していきます。関数が見つかったら「この関数はこのＤＬＬにあるよ」と書き込んで、検索を終了します。不明な関数がなくなったらリンクは終了、実行ファイルが完成します。 　ここで重要なのは「ＤＬＬは必要ない！！」ということです。実行ファイルを作製するときに必要なのは「ライブラリファイル」です。これは逆に言えば「ライブラリファイルがすべて」ということです。ライブラリファイルが古いままだと、新しいＤＬＬと合わなくてアプリケーションが実行できなくなります。リンカはライブラリファイルさえあれば安心してしまうのです。 　「ＤＬＬのメリット」として、ＤＬＬはいつでも気軽に更新できるというメリットを上げました。が、それは同時にバージョン管理が大変だということです。ライブラリファイルとの整合性は常に注意しておいてください。

で……使おうね 　話が逸れちゃいました。例を元にちゃんと使ってみましょう。 　sndPlaySound()のリファレンスを元に、ライブラリファイルとヘッダーファイルが分かりました。まず、ライブラリファイルを何とかしましょう。 　ライブラリファイルは、先ほどの欄に書き加えておけばＯＫ。ファイルの間は半角スペースで空けておきます。まぁ、ＭＦＣなら何もかかれてないと思いますが。 　……で、これで終わり。あっさりですねー。でも、この欄にこのファイルだけ。ちょっと寂しいですね。どうせなら……ＭＦＣと同じ方法を取ってみましょう。 　ＶＣのＭＦＣのヘッダーファイル（たぶんVC/MFC/Include/フォルダ）の中のAFX.hの最初の方を見てください。#pragma comment(lib, "kernel32.lib")みたいなのがずらーっと書いてありますね。そして、中にはライブラリファイル名が……。そう、ここで検索ライブラリファイルリストを設定しているのです。 　#pragmaというのは「プリプロセッサ」のひとつで、その中でも特に様々なことをしてくれるものです。機種依存の高い機能、例えばこのような「ライブラリファイルの指定」を、Ｃ言語標準の機能として使用することができ、プリプロセッサの方で「機種依存の壁」を崩してくれます。 　まぁ、#pragmaはかなり複雑なんで、上のものをそのまま使っちゃいましょう。そうしたら、「設定」ダイアログの方は削除しちゃってＯＫです。 　実際のコードは、stdafx.hの下の方（//{{AFX_INSERT_LOCATION}}の上の行くらい）に、次の２行を追加してください。

ＡＰＩの場合 　先ほどちょっと書いた「Win32 Application」の場合を思い出してください（まだ見てない人は必ず試すこと！！　もしくは「ＭＦＣユーザーのためのＡＰＩプログラミング講座」のサンプルを見てね）。ライブラリファイルの検索リストにずらーっと書かれていましたね。 　さて次に、RegisterClass()とかCreateDC()とかGlobalAlloc()の各ＡＰＩのリファレンスを見てください。user32.lib、gdi32.lib、kernel32.libをそれぞれインポートすること、と書かれていますね。そして、それを上のＷｉｎ３２アプリで検索リストに加えてますね。またはＭＦＣの場合にはAfx.hに#pragmaを使って加えられてますね。 　そう、ちょっと触れたとおり、ＡＰＩはすべてＤＬＬに入っており、ライブラリファイルを使ってアプリケーションからリンクするという形をとっているのです。ＭＦＣを使っていると、「ＤＬＬなんて使ってないよーん」とか思うかもしれませんが、全然そういうことはないのです。ウィンドウズアプリケーションはすべて、こうしてＤＬＬを通してＡＰＩを使用し、アプリケーションが実行されるのです。 　って、別にたいそうなことではないんですが。ＭＦＣに染まっているとこういうことを知らずにプログラミングしてると思います。ＤＬＬを使う時にはＭＦＣの恩恵に与れない場合が多く出てくるので、その準備運動みたいなものです。今まで「ＭＦＣおんりぃ」だった人は、ソースコードとかを見て、ちょっとＡＰＩプログラミングについて見てみるといいかもしれません。

まとめ＆これから 　ちょっと触れたように、この講座は最終的には「システムフック」や「サブクラス化」を解説しようと思っています。また、次回は「ＤＬＬの実行時リンク」を紹介しようと思います。 　「あれ？　ＭＦＣチップスにおんなじのなかった？」ありました（爆）。まぁ図とか増やして、もうちょっと分かりやすくして、別講座にするってことです。あんまり気にしないでね。