VC6 と VC7 の互換性

MFC の DLL は mfc70.dll に、そして ATL の DLL は atl70.dll になったようです。

これらは同じクラスであっても、たとえば mfc42.dll で実装されていたものとはバイナリレベルでの互換性がなく、Visual Studio .NET にて改めてビルドしなおす必要があるそうです。

　

以前の ATL の CComModule が、ATL 7.0 では次のクラスに分けられたそうです。

CAtlBaseModule	HINSTANCE とリソースインスタンスを含む、ほとんどの ATL アプリケーションに必要
CAtlComModule	COM クラスに必要
CAtlWinModule	ウィンドウクラスに必要
CAtlDebugInterfacesModule	インターフェイスデバッグのサポート
CAtlModule	特定のアプリケーションに必要な基底クラス
CAtlDllModuleT : CAtlModule	DLL 用の標準エクスポートを提供
CAtlExeModuleT : CAtlModule	実行ファイル用のコードを提供
CAtlServiceModuleT : CAtlModule	サービスプログラムの作成をサポート

　

これによって、機能の細分化や、従来は必要だったらしい Init メソッドと Term メソッドをコンストラクタとデストラクタに移動するなどが実現したそうです。

また、従来の CComModule は、互換性を保つため、現在も使用することができるようです。

　

ATL 3.0 (Visual C++ 6.0) までの、システムの ANSI コードページ (CP_ACP) を用いた文字列変換から、実行中のスレッドの既定の ANSI コードページによる変換に変わったそうです。

_CONVERSION_DONT_USE_THREAD_LOCALE を定義すると、以前と同様のシステムの ANSI コードページによる変換が可能のようです。

　

文字列の変換マクロは次のような命名規則で用意されています。

SourceType から DestinationType への変換マクロで、[C] と [EX] はそれぞれ、C と EX を省くことが出来るという意味です。

[C] の部分は、この C を入れることで変換後の値を定数とすることができ、[EX] の部分は、この EX を入れることでバッファの初期サイズを指定することが出来るということのようです。

SourceType と DestinationType のところに指定できる文字は次の通りです。

　

A	ANSI 文字列です。
W	UNICODE 文字列です。
T	標準文字列です。_UNICODE が定義されていれば W を、それ以外は A を意味します。
OLE	OLE 文字列です。W と同等です。

　

このマクロによって、以前と比べて次の点が改善されたそうです。

• 小さい文字にはスタックメモリを、スタックが不足する場合はヒープをしようする。
• 関数を終了する前でも、スコープを抜けた時点で解放される。
• ループごとに解放されるようになったため、ループ内でも通常通り使用可能。
• 大きい文字列の取り扱いにも適している。
• USES_CONVERSION を定義する必要がなくなった。
• OLE の意味が W で固定になった。

　

何の断りもなく、CString 型の変数へ BSTR 型の値を格納しようとするとエラーが発生するようになったそうです。

その代わり、CString 型は ANSI 用の CStringA と UNICODE 用の CStringW とが用意されたようで、CStringW 型の変数にならば直接、BSTR 型の値を格納することが出来るようです。

　

ただ CString 系クラスは、ANSI と UNICODE 間の変換機能も備わっていて、それを利用したい場合には、明示的にコンストラクタを呼ぶことで解決できるようです。

　

たとえば、CString 型へ BSTR 型を渡したい場合には、上のように BSTR 型を CString クラスのコンストラクタへ渡すことで、変換可能です。

　

これは変更点というより、バグ修正と捕らえた方がいいようです。

CComEnumImpl というのはコレクションを実装しやすくするクラスだそうですが、従来の ATL 3.0 はこの Skip メソッドに 0 を渡した場合に正しいエラーコードが得られなかったり、大きい値を渡した場合の処理に一貫性がなかったりしたそうです。

これもバグフィックスでしょうか…。

とりあえず、従来の CWnd::DestroyWindow でツールヒントを表示するとアサーションエラーが発生していたそうです。

ので、次に示すメンバ変数を AFX_THREAD_STATE から AFX_MODULE_THREAD_STATE に移動されたそうです。

• CToolTipCtrl* m_pToolTip
• CWnd* m_pLastHit
• int m_nLastHit
• TOOLINFO m_lastInfo
• int m_nLastStatus
• CControlBar* m_pLastStatus

　

明記されていませんでしたけど、きっとこれでアサーションエラーが表示されなくなっているのでしょう。

これがどのような対処だったのか良くわかりませんけど、たぶん、メモリが解放されるタイミングを変えたとかそういう対処なのでしょうか…。

静的ライブラリや DLL で、wchar_t 型をとる関数を呼び出すときに LNK2001 未解決の外部シンボルエラーが発生する場合があるそうです。

なお、BSTR や LPWSTR という型も wchar_t* に解決されるそうで、これもこのトラブルの要因となるようです。

　

これは、従来は unsigned short として処理されていた wchar_t が、/Zc:wchar_t というコンパイラオプションによって、wchar_t 自体がネイティブな型として処理されるために起こるそうです。

新規の MFC プロジェクトではこのオプションが既定で ON となるそうで、このオプションが ON でなかったころに作成したライブラリと、ON のプロジェクトとが共存した場合、関数シグネチュアが一致しなくなるそうです。

　

とりあえず、MFC とか ATL とかの部分をチェックしてみました。

プロジェクトのプロパティの 「全般」 を見てみると、なぜか ATL COM のはずが、Unicode Debug 構成では ATL を使用しない設定になっていたので、ATL を静的リンクで使用するようにしました。

そういえば、MFC は明示的に静的リンクした記憶はあるけれど、ATL はそんな問いを見た記憶がないので、もしかすると新たに DLL 化したのかも…。

とりあえずこれでリビルドをかけてみましたが、特に改善は見られませんでした。

　

とりあえず Visual C++ 7.0 で標準なら、wchar_t をビルドインにしようかと思ったのですけど、先日あらたに Visual C++ 7.0 で作成した静的ライブラリは wchar_t のビルドインにはなっていなかったので、とりあえずこの COM も wchar_t のビルドイン定義はしないことにしました。

とりあえずいちばん目立つ警告メッセージがこの libcmtd.lib で定義されているものが幾重にわたって出てきてしまうようです。

また、最後の方で ”defaultlib 'LIBC' は他のライブラリの使用と競合しています。/NODEFAULTLIB:library を使用してください。” という警告も出てきています。

　

ここで関わってきている libcmtd.lib というのは、コンパイラオプションで /MTd を指定し、マルチスレッド対応のランタイム （ "d" が付くのでそのうちのデバッグバージョン） を使用する際に使われるライブラリのようです。

　

デバッグバージョンとリリースバージョンのランタイムを共存しないようにした方がいいとの記載もあったので、もしかするとこれかもしれません。

というのも、Visual C++ 7.0 にした際に、スタティックライブラリを組み込んだ COM になったためです。

　

ライブラリはリリースビルド済み。そして今つくっている COM はデバッグモード…。

ということで、とりあえず早速、COM の方を Unicode Release MinDependency でビルドしなおしてみると、libcmtd.lib に関するリンクエラーはすっかりなくなりました。

　

ならばと、静的ライブラリのデバッグ版を別のファイル名にて作成し、COM の Unicode Debug にリンクさせてみたところ…、相変わらずエラーです。

これは互換性とかの問題ではなく、単純にリンカとか静的ライブラリの知識不足のようですね…。

　

Debug 番で、標準 C++ ライブラリを、シングルスレッドから、COM で指定しているマルチスレッドに変更したところ、見事、多重定義のエラーはなくなりました。

…、ということは、４種類作らなくてはいけないのでしょうか…。

いきなり動かすものでもないですし、ランタイムライブラリを排除できればいいのですけどね。

試してみたところ、どうやら /MT 系のマルチスレッド対応の静的ライブラリを作れば、シングルスレッドを示す /ML の方でも何とか平気のようです…。

また、/MTd の COM で /MT の静的ライブラリを読み込んでみたところ、

という警告は出るものの、致命的なエラーにいたることはないようです。

またこの警告は、【リンカ】 の 【入力】 で、libcmt.lib を除外することで回避することも出来るようなので、とりあえずはそのままでよさそうです…。

　

とりあえずこの段階で、警告こそあるものの、ビルドに失敗するというほどではなくなりました。

　

残っている警告のうち、ひとつは CRegKey クラスまわりの様子です。

何でも、”ATL::CRegKey::QueryValue が古い形式として宣言されました” という警告メッセージが表示されています。

　

…、CRegKey って MFC だったような…。

Visual Studio .NET のドキュメントで調べてみると、どうやら CRegKey は ATL に所属しているようです。…、と思えば、MSDN 2001/04 では ATL と MFC の両方にあるような感じです。

　

とりあえず ATL だしということで、ATL のドキュメントを見てみると、QueryValue メソッドは互換性のために残されているようです。

この QueryValue はオーバーロードを使って、引数に応じてレジストリの型を指定する使用になっていましたが、新しい CRegKey では QueryStringValue や QueryDWORDValue といったように、メソッド名を使って区別するように変更になったようです。

実際、この方がソースも見やすくなるし、変なところで頭を使わなくていいのでいい感じです。

　

そして若干気になるのが、次のメッセージ。

statreg.cpp と atlimpl.cpp が不要とのことですけど、おそらくこれは CComModule が細分化されたのに関するメッセージではないかと思います。

ただ、CComModule を差し替えるにもいったいどのような手順を追ったらいいか良くわからず…。とりあえずはビルドできるので良しとしましょうか…。

　

と思いつつも、コンパイル時のメッセージを眺めてみると、StdAfx.cpp にて、この警告が表示されているのがわかりました。

ということで StdAfx.cpp を開いてみると、しっかりとこの２つのファイルがインクルードされていたので、コメントアウトしてみました。

すると、この警告メッセージは表示されなくなりました。

　

あと、残すところのエラーは、DLL の EXPORTS にて、序数を割り当てないでくれとの警告メッセージです。

　

• DllCanUnloadNow
• DllGetClassObject
• DllGetClassFactoryFromClassString
• DllInstall
• DllRegisterServer
• DllRegisterServerEx
• DllUnregisterServer

ドキュメントで LNK4222 を調べてみると、上のエントリを序数でエクスポートしないでくれとのことです。

ということで、念のためコメントアウトしつつも、これらについている序数 @1 とかを消してみることにしました。

　

あとは、不要になったらしい USES_CONVERSION を探してみます。

そしてこれを削除してみると、しっかりとエラーが出てしまいました。これは新しい ATL COM プロジェクトを立ち上げないとだめなのでしょうか…。

　

これは、従来の W2A マクロとかでは依然として USES_CONVERSION が必要で、USES_CONVERSION を取り除いた場合は、CW2A などに置き換える必要があるようでした。

　

この CW2A ですが、次のように書くとバグの原因となるので気をつけましょう。

CW2A は実質的にクラスで構成されているようで、CW2A で変換された文字列は、そのクラスの内部バッファへ記録されるようです。

上記のようなプログラムを実行した場合、CW2A にて内部バッファのポインタを temp に取得できるまではいいのですが、その後、役目を終えた CW2A のクラスが破棄され、内部バッファが解放されてしまいます。