わんちゅう日記

気ままにヒトリゴト

タグ:VisualC++

気分が良いわんちゅうさん。大きな悩みの種が解決したので仕事帰りにブックオフで東京事変の「教育」と「大人」を購入。残りのアルバムは新品で買うかな…。

さて、大きな悩みの種は「"MFCをスタティックリンクで使用するアプリ"からは"MFC拡張DLL"が利用できない」ということでした。これを無事解決できたので気分が良いのです。

続きを読む

一昨日書いたクラスを丸ごとDLL化する方法。これは暗黙的リンクのときは楽に扱えます。しかし、明示的リンクを使用すると少し厄介です。まあ、今日ちょっと思いついたことやってみたらできたんで、分かってしまえばそうではないのかも知れません。ただ、これがMFCとかC++の作法に合っているのかが気になりますが…。新しい言語を覚えるときって、その言語特有の作法が気になるんですよ。その作法に合わせないと他の人が見たときの可読性が悪くなりますからね。

さて、いきなり「暗黙的リンク」とか「明示的リンク」とか書いていますので、なんのこっちゃと思い方もおられるでしょう。ですので、明示的リンクによるDLLにエクスポートしたクラスの利用方法を紹介する前に、これらの言葉についてわんちゅうの感覚で説明しようと思います。

続きを読む

MFCの話です。
ある関数をDLL化して他のプログラムから呼び出そうとするとき、DLL作成時に「エクスポート」という作業が必要になります。具体的にはdefファイルにエクスポートする関数名を列挙したり、関数宣言の部分に修飾子を加えたりします。

では、C++でクラスを丸ごとエクスポートしたい場合にはどうすればいいのか?

修飾子「AFX_EXT_CLASS」をクラス宣言に加えてください。これでそのクラスが丸ごとエクスポートされます。具体的には…

class AFX_EXT_CLASS PopopoPohn
{
private:
    void func1();

public:
    hogehoge();
    ~hogehoge();
    void func2();
}


あとは、PopopoPohnクラスが定義されているヘッダファイルをインクルードしてプロジェクトにlibファイルを登録すれば、普通のクラスを利用するときと同様に扱うことができます。

いや~、実は今日、これをすっかり忘れていましてね。ヘッダファイルもlibファイルも登録してあるのに、なんで「未定義の外部参照」と言われちゃうのかな~と2時間ぐらい悩んでいたんですよ。それでふと思い出したのが、この「AFX_EXT_CLASS」でした。

さて、この方法はDLLのリンク方法を「暗黙的リンク」で行うときは特に考えることもなくすんなりといきます。しかし、もう一つのリンク方法である「明示的リンク」のときはどうすれば良いのか…。これが今課せられている問題です。

先日、「Visual Studio 2005でビルドしたプログラムが自分のPC以外では動かな~いヾ(≧◇≦)/」と書き、その翌日、1日かけてOSの再インストールからやり直したわんちゅうさん。結果、駄目でした。
やっぱり他の人のPCでは動かないねぇ(´・ω・)(・ω・`)ネー
わんちゅうの環境ではXPでも7でも動くのにねぇ~(´・ω・)(・ω・`)ネー

で、これはもうOSのせいではない、再インストールはしたくないと思い、原因を調べていました。その結果、「セキュリティパッチの有無」が原因となりました。

よくは見ていませんが、「MFCの不具合を利用して任意のコードが実行されてしまう」という脆弱性があるようで、これに対するセキュリティパッチの有無でビルドしたプログラムが動くか動かないかが分かれるようです。
このパッチは再頒布パッケージだけでなくVisual Studio本体にも適用されます。パッチ適用後のVisual Studioでビルドしたプログラムでは、実行時に要求する再頒布パッケージのバージョンを意図的に変えているようです。その為、パッチを適用していない再頒布パッケージ上ではプログラムが要求するMFCのバージョンと一致しないため、「アプリケーションの構成がおかしい」と言われて、プログラムが実行できなかったのです。
なお、このセキュリティパッチは、Visual Studio用のものも再頒布パッケージ用ものも、Windows Updateで自動的に適用されるようになっています。

と、言うわけで、この騒動は一件落着。あとはビルド環境をどうするか統一すれば、何の問題もなくなりそうです。

モンダミンに慣れると、モンダミンしないと少々気持ち悪くなってしまいますな。歯磨きだけではすっきりしないというか、そんな感じです。しかし、モンダミンがアース製薬の製品ということがいまだに納得できません。どうもライオンの製品だと思ってしまうんですよねぇ。

さて、今日仕事でハマったことのメモ。
あるプロジェクトとそのプロジェクトから呼び出すDLLの文字セットは、一緒でなければなりません(・_・)!
いや、単純に、Unicodeのダイアログとマルチバイトのダイアログを1つダイアログ上に貼り付けようとしたら、ビルドは通るものの実行時にエラーになってしまったんですね。で、片方ずつ実行したら、マルチバイトの方の初期処理時にエラーになっていると。なので、Unicodeの方を無効にして、さらに呼び出す側のプロジェクトの文字セットをマルチバイトに変更したら、無事にマルチバイトのダイアログを呼び出すことができたんですよ。もちろん、この状態ではUnicodeのダイアログを呼び出すときにエラーになってしまうんですがね。

仮にも独立したDLLになっているので、文字セットでハマるとは思っていませんでした。でも、よく考えれば文字セットは統一されてないと、データのやり取りに支障が出るんですよね。勉強になりましたよ。

このページのトップヘ