出力されたファイルの確認 　ＤＬＬを作製したときに、いろんなファイルが生成されたと思います。そのファイルを確認してみましょう。 　ＤＬＬファイル（*.dll）は、作製した関数やクラスが入っているファイルです。実行時に、Ｅｘｅはこのファイルにリンクします。逆に言えばＥｘｅファイルを作るときには必要ないファイルでもあります。 　ライブラリファイル（*.lib）は、「どのＤＬＬでどの関数やクラスがエクスポートされているか」が書かれているファイルです。これがＥｘｅファイルを作るときに必要となるファイルです。 　エクスポートファイル（*.exp）は、基本的には使わないファイルです。ライブラリファイルとは別に、ＤＬＬやエクスポートされた関数やクラスについての情報を持つファイルです。あとで定義ファイルとかに使ったりすることもありますが、ここでは説明しません。 　プログラムデータベース（*.pdb）は、デバッグ時にのみ作製され、デバッグには欠かせないファイルです。これは結構重要なので、あとでしっかり説明します。 　基本的に重要なのはこの４ファイルです。ではまず、Ｅｘｅファイルのビルドに必要なライブラリファイル、そして関数の宣言が書かれたヘッダーファイルについて見ていきましょう。

検索ディレクトリの指定 　ＤＬＬを使うアプリケーションを作る時に必要なファイルは「ヘッダーファイル」と「ライブラリファイル」です。もちろん前前回のように「ライブラリを使わない方法」を使えば両方ともいりませんが、自作ＤＬＬでそれは難しいことは、前回を読めば分かると思います。 　さて、この２ファイルをどうやって使えばいいのか、順に見ていくことにしましょう。 　インクルードファイルの指定に使う#includeでは、ふたつのファイル指定方法があります。ひとつは"で囲むもので、これはプロジェクト内のファイルをインクルードするときに使います。 　もうひとつは<と>で囲むもので、これはすべてのアプリケーションで使うようなヘッダーファイルをインクルードするときに使います。 　このどちらを使ってＤＬＬのヘッダーファイルをインクルードするかは、ＤＬＬによって違ってくると思います。 　システムフック用のＤＬＬといった、特定のアプリケーションのみでしか使わない場合には、ＤＬＬのヘッダーファイルをＥｘｅのプロジェクトがあるフォルダへとコピーし（「プロジェクトへ追加」をする必要はありません）、"でインクルードするのがいいでしょう。 　ＭＦＣのような、複数のアプリケーションから使用するＤＬＬの場合には、< >を使ってインクルードできるようにするのがいいでしょう。また、ＤＬＬがまだ作製途中で、なんども改変する場合にはヘッダーファイルのコピーは避けた方がいいので、そういった場合にもこちらの方がいいでしょう。 　では、どうやって自作ＤＬＬのヘッダーファイルを< >でインクルードするのかというと、「検索ディレクトリ」にこのヘッダーファイルがあるフォルダを追加すればいいのです。 　「オプション」ダイアログの「ディレクトリ」のページで「表示するディレクトリ」を「インクルードファイル」にしてください。そうすると、その下の欄にフォルダ一覧が表示されると思います。 　< >でインクルードされるファイルは、すべてのここで指定されたフォルダから検索されています。ここに書かれているフォルダを見てみれば、そこにはＷｉｎ３２ＳＤＫやＭＦＣのヘッダーファイルがあるはずです。 　自作ＤＬＬのヘッダーファイルが置かれているフォルダを、ここに追加してください。そうすることで、< >で同じようにインクルードすることができるようになります。 　また、ついでですのでライブラリファイルとソースファイルのフォルダも追加しておいてください。 　ちなみに、検索は上に書かれたフォルダから行われるので、同じファイル名のヘッダーファイルやライブラリファイルがある場合には、順番が重要になってきます。望んだファイルがロードされないと感じたら、この部分を注意してみてください。 　個人的には、ここの部分はプロジェクトごとにも設定できるようにして欲しかった……（ライブラリファイルは「設定」ダイアログの「リンク」−「インプット」で追加できました）。

どこでインクルードするか 　さて、では実際にインクルードしてみましょう。Ｅｘｅファイルの側で#include <Func.h>のようにインクルードすればＯＫです。 　ただし、注意すべき点がふたつあります。 　まずひとつは、どのファイルでインクルードするかという問題です。 　インクルードする場所は主にふたつ。ひとつはソースコードの頭。もうひとつはStdAfx.hの中です。 　「特定の機能だけを持つＤＬＬ」の場合には、その機能を使うソースコードでインクルードするのが一番でしょう。ですが、そのＤＬＬの機能を複数のソースコードで使用する場合には、そのすべてでインクルードしなければなりません。 　それを回避するのが、StdAfx.hでのインクルードです。このファイルでインクルードすることで、プログラム全体からＤＬＬの機能を使用することができるようになります。基本的には、この方法を採るのがいいと思います。 　ところがこれにはデメリットもあります。 　「プリコンパイル済みヘッダーファイルを使用」の設定が入っているとき、StdAfx.hは巨大なオブジェクトファイルとして作製されます。このあと、ＤＬＬ側のヘッダーファイルを書き直す度にStdAfx.hを再コンパイルすることになります。これはかなりの時間がかかるので、毎回毎回行うとかなり辛いと思います。 　このふたつのメリットとデメリットを考えて、ＤＬＬが完成するまではソースコードで、完成したらStdAfx.hでインクルードするのがいいでしょう。

「標準インクルードファイル」の作製 　もうひとつの問題は、どのファイルをインクルードすべきかという点です。前回作製したＤＬＬの場合、__declspec(dllexport)を用いてエクスポートした場合には、Func.hにはDLL_EXPORTが用いられているのでDefs.hもインクルードしなければなりません。また、仮にFunc.hでCArrayなどを使っていればafxtempl.hをインクルードする必要が出てきます。 　つまりどういうことかというと、Ｅｘｅの側で、インクルードするファイルを決めなければならないということです。ＤＬＬ側で必要としたヘッダーファイルは、Ｅｘｅ側でも必要になるということになります。が、ＤＬＬのインクルードは、当然ソースファイルや、StdAfx.hに書いてあったりして、分かりにくい場合が多いでしょう。 　そこで、ＤＬＬ側に「このヘッダーファイルをインクルードすればばっちり大丈夫！」というファイルを作ってしまいましょう。 　これはＤＬＬのプロジェクトとは無関係のファイルなので、「ファイル」−「新規作製」とかは使わずにヘッダーファイルをＤＬＬのプロジェクトがあるフォルダに作ってください（ここではファイル名をStdHead.hとします）。 　そして、その中身は次のような感じに書いてください。

ライブラリファイル 　は、実はもうできちゃってます。 　ライブラリファイルも、ヘッダーファイルと同じく「オプション」の「検索ディレクトリ」で登録されたフォルダから検索されます。ここでライブラリファイルのあるフォルダを登録しておけば、ＯＫです。 　あとは、ライブラリファイルを「検索リスト」に加えれば終了。#pragma comment(lib, "Test.lib")と、上の「これさえインクルードすればすべておっけー！」ヘッダーファイルに書き込まれていることを確認してください。 　あと、ヘッダーファイルと同様、ファイル名の重複、検索ディレクトリの優先順位に気を付けてください。 　ここまでで、Ｅｘｅファイルの側は終了。あとはビルドしてしまえば、完成です。 　簡単にまとめると、まず検索ディレクトリに「ヘッダーファイル」と「ライブラリファイル」のあるフォルダを加え、次にＤＬＬのヘッダーファイルのあるフォルダに標準ヘッダーファイルを作製し、最後にＥｘｅの側でこれをインクルードする、とこの３つの手順を踏むことで、Ｅｘｅ側はビルドできます。 　で、ここからが結構大変だったり……。

ＤＬＬの位置と自動コピー 　さて、ＤＬＬが完成し、Ｅｘｅもビルドが終了した。じゃーデバッグテストで実行してみよう、とそのまえにＤＬＬがどのフォルダにあるかを確認してください。 　「ＤＬＬを使おう！！」で説明したように、ＤＬＬは特定のフォルダにある必要があります。Ｅｘｅファイルやシステムフォルダ、ウィンドウズフォルダにＤＬＬがなければ、Ｅｘｅは異常終了します。これはデバッグ時でもなんでも同じです。 　とゆーわけで、まだ置いていない場合には、作製したＤＬＬを特定のフォルダにコピーしてください。システムフックのように特定のＥｘｅでしか使わないＤＬＬはＥｘｅと同じフォルダに、ＭＦＣのように複数のアプリケーションから使用するＤＬＬはシステムフォルダにコピーするのがいいでしょう。 　でも、ＤＬＬをいちいちドラッグアンドドロップしてコピーするのは非常にめんどくさいです。ですが、これは簡単に解決します。これを自動化しましょう。 　ＤＬＬ側のプロジェクトを開き、「プロジェクト」−「設定」ダイアログの右端のタブ「ビルド後の処理」のページを開いてください。このページでは、ビルド後にＭＳ−ＤＯＳコマンドを使用することができます。 　「ビルド後の処理の説明」欄は、ビルド時にアウトプットに表示される文字列です。適当な言葉を入れておいてください（筆者は「DLLのコピー」と入れています）。 　次に「ビルド後の処理コマンド」にコピーのコマンドを追加します。ＭＳ−ＤＯＳのコピーコマンドはそのまんまcopyです。書式は

プログラムデータベース 　ＤＬＬの作成時に同時に生成されたファイルの中に、拡張子がｐｄｂのファイルがあると思います。 　このファイルはプログラムデータベースと呼ばれ、デバッグのための情報が書き込まれています。 　プログラムデータベースには、ＤＬＬやＥｘｅのどの部分がソースコードのどの位置にあたるのかが書き込まれています。デバッガを実行すると、デバッガはこのファイルを読み込みブレークポイントの設定にあわせてソースコードを表示します。 　ソースコードの検索は、３段階に行われます。 　まず、プログラムデータベースにはソースファイルの位置がフルパスで書き込まれています。まずこのファイルを検索します。 　見つからなかった場合には、インクルードファイルなどと同じく「検索ディレクトリ」に書き込まれたフォルダを検索します。 　それでも見つからないと「ソースファイルの検索」というダイアログが表示され、ソースファイルのあるフォルダがどこにあるのか訊かれます。 　ここでキャンセルすると、とうとうソースファイルの検索を諦め、ＤＬＬ内のコード（いわゆるアセンブリコード）を表示します。 　なんと言っても特徴的なのはフルパスが書き込まれているという点です。一応補助的な検索機能はあるとはいえ、フルパスで直接というのはなかなか強烈です。 　さて、もうひとつ疑問が残ります。それはプログラムデータベースファイルの検索です。ソースファイルと違い、「検索ディレクトリ」は使用しません。……イヤな予感のしたあなた、正解です。 　実は、デバッグ版のＥｘｅファイルにはｐｄｂファイルの位置がフルパスで書き込まれています。これはぜひ自分で確かめてみてください。たぶん最後の方に書いてあると思います。デバッガはＤＬＬを読み込んだとき、まずこのフルパスでｐｄｂファイルを読み込んでみます。 　ない場合には、デバッガはＤＬＬの置かれたフォルダを検索し、ｐｄｂファイルを探します。注意して欲しいのは、ＤＬＬのような検索を行うわけではないということです。ＤＬＬがシステムフォルダにあるのなら、システムフォルダしか探しません。Ｅｘｅのあるフォルダに置いても、なんの意味もないということです（おそらくプリコンパイル済みファイルの関係で、同名のｐｄｂファイルが存在しやすいためだと思われます）。 　で、これで検索は終わり。見つからなかった場合には、ＤＬＬのコードさえ表示せず、何事もなかったかのように次の行へと移ります。 　以上のように、プログラムデータベースはフルパスが多く使われています。これはふたつの点で注意が必要です。 　ひとつは、フルパスに２バイト文字が入っているとデバッグができないという点です。たぶんこれはＭＳＤＥＶのバグだと思います。「ＤＬＬにステップインできないよ〜」という方はこの部分を注意してみてください。 　もうひとつは再配布の問題です。他の方のハードディスクにコピーするのですから、フルパスはまったく意味をなしません。使ってもらう方に「ソースファイルの検索ディレクトリをちゃんと指定してもらうこと」と「ＤＬＬと同じフォルダにｐｄｂファイルを置いてもらうこと」の２点を説明する必要があるでしょう（インストール時に書き換えるっていう手もあるけど）。 　もちろんこれは、自分で使う場合にもプロジェクトファイルの移動などは難しいということです。うまくいかないときには以上のような部分に注意してみてください。

再配布するＤＬＬ 　さて、ＤＬＬが完成した、Ｅｘｅも完成した、デバッグも終了した、じゃぁホームページに掲載しましょう、という段階です。 　まず必要なのが、自作ＤＬＬファイルとそれを使用するＥｘｅファイル。これは当然ですね。どちらもリリースバージョンだということを確認してください（「デバッグ」と「リリース」については次回説明する予定です）。 　自作ＤＬＬが「拡張ＤＬＬ」の場合、もう２ファイル、MFC42.dllとMSVCRT.dllの２ファイルが必要になります。前者はＭＦＣが、後者はランタイム関数が入っているＤＬＬです。 　この２ファイルに関しては注意が必要です。まず、標準インストールのウィンドウズ９５には入っていません。また、バージョンの問題もあります。MFC42.dllは、ＶＣの４．２と５．０で使用されていますが、４．２に添付されたものは５．０で作られたＥｘｅやＤＬＬとリンクできません。クラス等、追加されたものがあるからです。 　以上のことをふまえて、この２ファイルを再配布する必要があります（もちろんマイクロソフトによって許可されています）。ただし、圧縮して６００ＫＢ弱……ちょっと大きいですね。 　実際、ＤＬＬを作製する場合（ってゆーかＶＣで作製する場合）にはこれが大きなネックになっています。各社のアプリケーションにも添付されていることが多いため、インストールする必要がない場合も確かにありますが、ある場合ももちろんあります。できれば、インストーラなどを使って、安全にインストールするのがいいでしょう。 　ちなみに、ＥｘｅがどのＤＬＬを使用しているのか簡単に調べる方法を解説しておきます。 　Ｅｘｅをデバッグモードで実行すると、アウトプットにその時点でウィンドウズがロードしているＤＬＬが表示されます。 　その中で「'*.dll' をロードしました、合致するシンボル情報は見つかりませんでした。」と表示されたものは、配布する必要はありません。 　「'*.dll' のシンボルを読み込みました」は、そのとき初めてロードされるＤＬＬです。これはデバッグバージョンで使用するＤＬＬなので、このリリースバージョンのＤＬＬが、配布する必要のあるＤＬＬということになります（デバッグバージョンのＤＬＬは通常のアプリケーションでは使用されないため、「すでにロードされている」ということはないはずですから）。 　もう一度書きます。「'*.dll' のシンボルを読み込みました」と書かれているＤＬＬのリリースバージョンを配布してください。MFC42.dllのデバッグバージョンはMFC42d.dll、MSVCRT.dllのデバッグバージョンはMSVCRTd.dllです。で、配布するのはあくまでリリースバージョンですから。念を押すようですけど、くれぐれも注意してください。

プログラマーに公開する場合 　同様に再配布する場合でも、アプリケーションとしてではなく、他のプログラマーが使えるようにＤＬＬを公開したい場合もあるでしょう。 　そういう場合、最低限必要なのは、リリースバージョンのＤＬＬとライブラリファイル、そしてヘッダーファイルです。この３つはかならず配布してください。 　でも、使ってくれる人のことを考えるのなら、やっぱり全部がいいでしょう。つまり、上の３つに加えて、デバッグバージョンのＤＬＬ＆ＬＩＢ、デバッグに必要なプログラムデータベース、そしてソースコード。 　これらがあるとないとでは、デバッグのしやすさが全然違います。確かに、ソースコードを配布するのは勇気がいるかもしれません。でも、コードを見てもらい、使ってもらうことで自分のプログラムを鍛えてもらえるということは大きいことです。できるだけ、全部添付するようにしましょう。 　あ、こういう場合には「これさえインクルードすれば全部ＯＫヘッダーファイル」も添付した方がいいでしょう。

まとめ 　今回はちょっとまとまりがなかったかなーとゆー気がしないでもないです。「ＤＬＬ関係の細かな注意」みたいになっちゃったかも。でも、ＤＬＬ関係で分かりにくい部分は網羅したつもりです。どうでしょー。 　次回は、関数ではなくクラスを作ってみます。また、「デバッグバージョン」と「リリースバージョン」のふたつのＤＬＬを作る方法や、ＤＬＬ側でデバッグする方法などを解説しようと思います。