ＶＣ＋＋でＵｎｉｃｏｄｅを扱うアプリケーションを開発しています。
ひとつのプログラム内に「_UNICODEオプション」でビルドしたdllと「_MBCSオプション」でビルドしたdllを混在させ、相互に呼び出しすることは問題はないのでしょうか？
○UNICODEコンパイルしたdllから、MBCSコンパイルしたdllを呼ぶ とか
○MBCSコンパイルされているdllから、UNICODEコンパイルのdllを呼び出すとか...
※いろんな人に尋ねたり、ネット上を検索してみたのですが、『そういうことをしても良い』とも書かれていないですが、『しちゃダメ』とも書かれていません。
Microsoft的には同一プロセス内は「UNICODE」コンパイルならUNICODEコンパイルで全モジュールを統一しないといけないと規定されているのでしょうか？
異なるコードセットでコンパイルしたdllを同一プログラム内に混在させた場合には、正常動作を保証しない...というようなことがMSDNやVCのヘルプ内に記載されていますでしょうか？
同一のプロセス空間上に、異なるコードセットの命令(A系とW系)がロードされることで、誤動作したりするのではないか？と心配です。
既存のMBCSで作成されたプログラムが何百Ksと有り、これをUNICODE対応しなければなりません。
乱暴な言い方をすると、UNICODE(私用領域を含む)を表示・入力するダイアログ部分だけを_UNICODEでコンパイルし、あまりUnicode文字列操作に関係のない「通信系dll」や「ファイル・アクセス系dll」あたりはMBCSのままとしたい目論見です。
※TCHARを使用してどちらのコンパイル・オプションを使用しても良いようにプログラムを書き換えてUnicode対応しようと考えていますが、そもそも『_MBCSのdll』から『_UNICODEのdll』を呼び出すことが、MicrosoftのVC++として『許されていない』のか『特に問題ない』のかどうかを教えてください。
『混在して呼び出しているが何の問題もないよ』とか『このような誤動作が生じた』とかいう貴重な情報でも結構です。ぜひ教えてください。
※できあがったプログラムは、WindowsNT系のOS上でのみ動作させます。95/98系のOS上で動作させる予定はありません。
※ダイアログでUnicodeの外字(私用領域)を入力できる必要があります。
※WindowsXP Professional(SP1a)上で、VC++6.0(SP5)で開発しています。
> ひとつのプログラム内に「_UNICODEオプション」でビルドしたdllと「_MBCSオプション」でビルドしたdllを混在させ、相互に呼び出しすることは問題はないのでしょうか？
問題ないです。
ただし，MFCのようにUNICODE用と非UNICODE用がわかれている場合，問題が起きるかもしれません。
古いCString(VC++ 6.0やそれ以前)では，CStringはTCHARを保持しているため，
UNICODE用と非UNICODE用でCString自体が変わっています。
> Microsoft的には同一プロセス内は「UNICODE」コンパイルならUNICODEコンパイルで全モジュールを統一しないといけないと規定されているのでしょうか？
そんなことを規定すると，95系とNT系で相互に運用可能なプログラムが作成できなくなります。
> 同一のプロセス空間上に、異なるコードセットの命令(A系とW系)がロードされることで、誤動作したりするのではないか？と心配です。
NT系OSにおいては，A系のAPIを呼び出すと，文字列がすべてUNICODEに置き換えられてW系のAPIが呼ばれます。
つまり，どちらのAPIも必ずロードされます。
> 既存のMBCSで作成されたプログラムが何百Ksと有り、これをUNICODE対応しなければなりません。
> 乱暴な言い方をすると、UNICODE(私用領域を含む)を表示・入力するダイアログ部分だけを_UNICODEでコンパイルし、あまりUnicode文字列操作に関係のない「通信系dll」や「ファイル・アクセス系dll」あたりはMBCSのままとしたい目論見です。
画面まわりは全て一致させる必要があります。
これは，メッセージ関連の，特にWM_SETTEXTなどの関連で問題が起きるためです。
それ以外は，インターフェースさえちゃんとしていれば問題ないです。
そんな変な事普通はしないだろうな。
VCで許されてないとかそういう問題じゃないだろう。
問題ないかどうかは自分でテストしろ。
コーディングの責任は自分で取れ。
>YuOさん ご回答ありがとうございます。
>問題ないです。
⇒ 心強い回答をいただきありがとうございました。
基本的には「受け渡しのインターフェイス」さえ気を付けていれば、や
っちゃっても大丈夫だろう...と自分勝手に決め付けつつ、不安に思って
いました。
おかげ様で安心しました。
>画面まわりは全て一致させる必要があります。
>これは，メッセージ関連の，特にWM_SETTEXTなどの関連で問題が起きるため
>です。
⇒ _UNICODEのモジュールから、_MBCSのダイアログ内のボタンのラベルな
んかをWM_SETTEXTで書き換えたりしなければOKだということですね。
全ダイアログ画面を_UNICODE系で統一できるにこしたことはありません
が、都合により一部のダイアログが_MBCSで残るような際には、充分に留
意します。
>kajikiさん 厳しいご指摘ありがとうございます。ごもっともです。
⇒ 普通はしないのですが、事情が事情でどうしてもやらざるをえないので
す。
普通ならたしかに「Microsoftが許すかどうか」という問題ではありま
せん。
作りやすさや後々のメンテナンス性の観点からみても、おかしいやり方
です。
逆に言えば「だからこそやっても大丈夫なのかどうか」を有識者の皆様
にお尋ねしたかったわけです。
私の開発するアプリケーションは、れっきとした商品ですので、もちろ
んこのBBSでの回答だけを鵜呑みにして、何かあった際に「BBSでは大丈
夫と言われた...」なんて理由では顧客にも社内的にも通用しません。
私のクビが飛びます。
このBBSにお尋ねしているのと並行して、プロトタイプでの実験を繰り
返しています。自分で責任を取る覚悟を決めるための裏づけを得るため
にお知恵をお借りさせていただいた次第です。
kajikiさんが気を悪くされたのでしたら、もうしわけありませんでした。
細かいことは言わないけどさ・・・
もし「問題あります。そういうことをしてはダメです。」って
書き込みがあったらどうするつもりだったのさ？
それでは仕方ない、揃えましょうってんなら最初からそうすればいいし
それでもこのやり方しかないんだってんなら質問したってしょうがないだろ？
れっきとした製品なんでしょ？首が飛ぶんでしょ？
「お墨付き」がほしいならマイクロソフトに聞いたらどうです？
マイクロソフトが大丈夫っていってます。
とはいえ確認はしておいたほうがいいだろうな。
マイクロソフトが保証できないって言ってます。
しかたない。やるしかないなら自分たちで動作確認するか。
いずれにしろ、自分たちでやることに変わりはないのかもしれないですが。
掲示板で得られる答えなんて、あなたの要求から見たらノイズだと思う。
よほど精鋭のみで構成されたメンバでもない限り、
開発始まってからトラブル起こしてかえって時間かかる可能性高そうだ。
YuOさんの書かれていることをキチンと理解して処理がかけない奴が
たった一人混じっただけで、原因特定するだけで一苦労とかね。