none
CRuntimeClass のメンバ、m_pfnCreateObject は何処で設定されているのでしょうか? RRS feed

  • 質問

  • お世話になります。

    MFC 自体は大きすぎるので、MFC に似たライブラリ、と言ってもライブラリのソースコードの集まりですが、それを作ろうとしています。

    ドキュメント / ビュー アーキテクチャも作ろうと思い、CRuntimeClass 構造体を調べているのですが、そのメンバ m_pfnCreateObject が何処で設定されているのか判りません。

    CRuntimeClass 構造体はメンバ関数 m_pfnCreateObject を使って、CreateObject を呼び出しているのは判ったのですが、その m_pfnCreateObject へ何処で何が設定されているのか、皆目見当がつきません。

    IMPLEMENT_DYNAMIC、あるいは DECLARE_DYNAMIC マクロで設定されているのかと思いましたが、

    static const CRuntimeClass class##class_name;

    この一文の意味が判りません。
    この一文で m_pfnCreateObject が設定されているとも思えず、行き詰ってしまいました。

    何かヒント的なものでも構いませんので、よろしくお願いします。

    2011年3月12日 3:55

回答

  • ヘルプは読みましたか?

    CreateObject できるものは、DECLARE_DYNCREATE マクロを設定しています。同様に、CHoge* pHoge; ar >> pHoge; ができるものは、DECLARE_SERIAL マクロを設定します。

    これらの、define を見るとどういう形で定義しているかわかります。もし、そこで記述されている内容が理解できない。。。という場合は、C言語のリファレンスやC++言語のリファレンス(おもに、#define の置き換えに関する記述)の理解が足りないということだと思われますので、まずはそちらの理解を進める必要があると思います。

     


    わんくま同盟,Microsoft MVP for Visual C++(Oct 2005-) http://blogs.wankuma.com/tocchann/
    • 回答としてマーク ミッヒー 2011年3月16日 6:09
    2011年3月12日 4:56
  • ドキュメント / ビュー アーキテクチャも作ろうと思い、CRuntimeClass 構造体を調べているのですが、そのメンバ m_pfnCreateObject が何処で設定されているのか判りません。

    IMPLEMENT_RUNTIMECLASS(IMPLEMENT_DYNAMIC, IMPLEMENT_DYNCREATE, IMPLEMENT_SERIAL) などで初期化されています。
    一度見られているのかもしれませんが、m_pfnCreateObject という識別子が現れないからと言って、代入されていないとは限りませんよ。

    MFC 自体は大きすぎるので、MFC に似たライブラリ、と言ってもライブラリのソースコードの集まりですが、それを作ろうとしています。

    ところで、あるもの と似たようなものを作るときに、あるもの のソースコードを見ながら作ることは良いのでしょうか。
    ヘッダーファイルとはいえ、ロジックが書かれている部分もありますので、それを見ながら作ることは、良いのでしょうか?

    ドキュメント / ビュー アーキテクチャも作ろうと思い、CRuntimeClass 構造体を調べているのですが、そのメンバ m_pfnCreateObject が何処で設定されているのか判りません。

    ドキュメント / ビュー アーキテクチャを実現するために、CRuntimeClass 構造体の実装を知る必然性はあるのでしょうか?
    ご自身で設計・実装するのであれば何も問題ありませんが、他者の実現方法を参考にそのまま実装することは問題がある可能性があります。
    (著作権だけでなく、契約面でも明示的に許諾されているかなど)

    # 使い道次第。著作権・契約の解釈にもよる。
    # 配布する可能性がある類似品(クラスライブラリ)開発に取り組むのであれば、参照すべきではないと考えます。(少なくとも)


    質問スレッドで解決した場合は、解決の参考になった投稿に対して「回答としてマーク」のボタンを押すことで、同じ問題に遭遇した別のユーザが役立つ投稿を見つけやすくなります。
    • 回答としてマーク ミッヒー 2011年3月16日 6:09
    2011年3月12日 5:05
    モデレータ
  • ##(Token-Pasting Operator)はMacroで指定された文字列に置き換えて連結します。
    MSDNを参照すればすぐに分かると思います。

    >IMPLEMENT_DYNAMIC/DECLARE_DYNAMIC
    これらのMacroは複雑な定義になっていますが、そういう場合はPreprocessすれば良いです。
    例えば、IMPLEMENT_DYNAMIC(CMainFrame, CMDIFrameWndEx)をPreprocessすると以下になります。

    CRuntimeClass* __stdcall CMainFrame::_GetBaseClass()
      { return (CMDIFrameWndEx::GetThisClass()); }

    __declspec(selectany) const CRuntimeClass CMainFrame::classCMainFrame =
      { "CMainFrame", sizeof(class CMainFrame), 0xFFFF, 0,&CMainFrame::_GetBaseClass, 0, 0 };

    CRuntimeClass* __stdcall CMainFrame::GetThisClass()
      { return ((CRuntimeClass*)(&CMainFrame::classCMainFrame)); }

    CRuntimeClass* CMainFrame::GetRuntimeClass() const
      { return ((CRuntimeClass*)(&CMainFrame::classCMainFrame)); }

    ポイントは上記の太字の箇所です。

    DECLARE_DYNAMICは単なる宣言ですので省きます。

    • 回答としてマーク ミッヒー 2011年3月16日 6:09
    2011年3月12日 5:16
  • 同じく、作られたもののライセンスが気になります。

    ちなみに##はToken-Pasting Operatorです。

    • 回答としてマーク ミッヒー 2011年3月16日 6:09
    2011年3月12日 5:35
  • 残るは Azulean さんご指摘の、著作権がらみの問題ですね・・・。

    「マイクロソフト ソフトウェア ライセンス条項」というファイルがあるはずです。
    (C:\Program Files\Microsoft Visual Studio 9.0\Microsoft Visual Studio 2008 Professional Edition - JPN\eula.txt)

    これに「3. 追加の許諾条件および使用制限。」、「d. 再頒布可能コード。」に「i. 使用および再頒布の権利。」と「ii. 再頒布の条件。」という定義はあります。
    参考にしてコードを書くことを、著作物の複製・改変・翻案と解釈されるかは、私には何とも言えません。
    複製・改変などとみなされる場合、MFC は「i. 使用および再頒布の権利。」に明示的に記載されているため、「ii. 再頒布の条件」の制限が付されます。この場合、「お客様のプログラムにおいて、再頒布可能コードに重要かつ主要な機能を加えること」などの条件を満たす必要があります。

    個人的には、単に同等機能を再実装するだけであれば、重要かつ主要な機能を加えることに相当するとは思えません。
    ただし、参考にしてコードを書くことが、この条項の制限を受けるかどうかは、私からは何とも言いかねます。

    # この条項で認められている MFC への変更は、アプリケーションの一部を想定されているものとみられます。
    # ビジネスで類似のクラスライブラリを開発するなら、まず参照を禁じるのが妥当な判断だと思います。


    質問スレッドで解決した場合は、解決の参考になった投稿に対して「回答としてマーク」のボタンを押すことで、同じ問題に遭遇した別のユーザが役立つ投稿を見つけやすくなります。
    • 回答としてマーク ミッヒー 2011年3月16日 6:09
    2011年3月12日 6:10
    モデレータ
  • Microsoft 社からの回答があったので投稿します。
    以下、メールより抜粋 ( 個人情報部分を削除しています )


    弊社といたしましては、大変恐縮ながら、このような MFC コードの実装を参考としたアーキテクチャの構築およびコードの作成については、ライセンス上の許諾範囲外に相当すると考えております。

    MFC ライブラリに含まれるソースコードの上部には英語にて定形のコメントが記載されているかと存じます。
    該当コメントにおいても、同ソースの著作権および知的財産は弊社マイクロソフトに帰属しており、当該ライブラリの参照は、MFC ライブラリを使用いただく際のドキュメントの補足として、MFC ライブラリの実装を確認する目的でのみご利用いただくことを意図していることをご案内しております。
    そのため、MFC ライブラリの実装を参考にして、ライブラリに含まれる弊社実装をお客様のアーキテクチャやコードに反映して作成を行うことはお控えくださいますようお願いいたします。

    今回のご要望の背景としては、弊社 MFC ライブラリをより単純化した機能の作成を検討されていると承っております。
    このような場合、ご実施いただく手順はおおよそ以下のようになるかと存じます。

     (1) 概略の設計段階として、全体として実現したい機能および要件を決定します。
     (2) 上記要件に沿って、独自に機能単位ごとのより詳細なインターフェース、アーキテクチャの設計を考案します。
     (3) 各機能単位ごとに、設計を具体化する実装を行います。
     (4) 各機能を組み合わせて、全体として要件を満たす機能を実現できるように実装の修正と検証を繰り返します。
     
    今回のご要望は、(3) の実装部分において、MFC ライブラリの具体的な実装を参考にされたいという内容と承っております。
    しかし、これは上述のとおりお控えいただきたく存じます。

    例えば、(1) ないし (2) の初期等、より早期の段階において、MFC ライブラリの外部的な動作や、機能のインタフェースなど、抽象度の高い振る舞いのみを参考として、検討を進めていただくことには問題はございません。
    より具体的には、(4) を経て最終的に完成された実装 (ソース コード) と弊社ライブラリの実装を比較した場合に、明らかに主要な実装における類似性が見受けられる場合は著作権上問題となりうるため、あくまでも早期検討段階での参照までにとどめていただければと存じます。

    弊社におけるソース コードの公開の基本的な目的は、上述のとおり弊社ライブラリ使用時のドキュメントの補足および実装の理解という点にございますので、この主目的を基本としてご活用いただければ幸いです。

    弊社の見解としては、以上となります。


    という事で、皆様がご指摘して下さったように、MFC のソースコードを見て、独自のライブラリを作るのはライセンス違反になるそうです。
    ただし、MFC の動作を見て、それを参考にプログラムを作るのは問題ないとの事です。
    もっとも、あまりに酷似していたら、ソースコードの公開を裁判所で迫られるんでしょうね・・・。

    ライセンスに関して助言して下さった方々、ならびに本来の質問に回答して下さった方々に感謝いたします。
    ( MFC にライセンスに関する Microsoft 社の公式見解という事で、不本意ながら、自分に回答マークを付けさせていただきました )

    • 回答としてマーク ミッヒー 2011年3月16日 6:09
    2011年3月16日 6:08

すべての返信

  • ヘルプは読みましたか?

    CreateObject できるものは、DECLARE_DYNCREATE マクロを設定しています。同様に、CHoge* pHoge; ar >> pHoge; ができるものは、DECLARE_SERIAL マクロを設定します。

    これらの、define を見るとどういう形で定義しているかわかります。もし、そこで記述されている内容が理解できない。。。という場合は、C言語のリファレンスやC++言語のリファレンス(おもに、#define の置き換えに関する記述)の理解が足りないということだと思われますので、まずはそちらの理解を進める必要があると思います。

     


    わんくま同盟,Microsoft MVP for Visual C++(Oct 2005-) http://blogs.wankuma.com/tocchann/
    • 回答としてマーク ミッヒー 2011年3月16日 6:09
    2011年3月12日 4:56
  • ドキュメント / ビュー アーキテクチャも作ろうと思い、CRuntimeClass 構造体を調べているのですが、そのメンバ m_pfnCreateObject が何処で設定されているのか判りません。

    IMPLEMENT_RUNTIMECLASS(IMPLEMENT_DYNAMIC, IMPLEMENT_DYNCREATE, IMPLEMENT_SERIAL) などで初期化されています。
    一度見られているのかもしれませんが、m_pfnCreateObject という識別子が現れないからと言って、代入されていないとは限りませんよ。

    MFC 自体は大きすぎるので、MFC に似たライブラリ、と言ってもライブラリのソースコードの集まりですが、それを作ろうとしています。

    ところで、あるもの と似たようなものを作るときに、あるもの のソースコードを見ながら作ることは良いのでしょうか。
    ヘッダーファイルとはいえ、ロジックが書かれている部分もありますので、それを見ながら作ることは、良いのでしょうか?

    ドキュメント / ビュー アーキテクチャも作ろうと思い、CRuntimeClass 構造体を調べているのですが、そのメンバ m_pfnCreateObject が何処で設定されているのか判りません。

    ドキュメント / ビュー アーキテクチャを実現するために、CRuntimeClass 構造体の実装を知る必然性はあるのでしょうか?
    ご自身で設計・実装するのであれば何も問題ありませんが、他者の実現方法を参考にそのまま実装することは問題がある可能性があります。
    (著作権だけでなく、契約面でも明示的に許諾されているかなど)

    # 使い道次第。著作権・契約の解釈にもよる。
    # 配布する可能性がある類似品(クラスライブラリ)開発に取り組むのであれば、参照すべきではないと考えます。(少なくとも)


    質問スレッドで解決した場合は、解決の参考になった投稿に対して「回答としてマーク」のボタンを押すことで、同じ問題に遭遇した別のユーザが役立つ投稿を見つけやすくなります。
    • 回答としてマーク ミッヒー 2011年3月16日 6:09
    2011年3月12日 5:05
    モデレータ
  • ##(Token-Pasting Operator)はMacroで指定された文字列に置き換えて連結します。
    MSDNを参照すればすぐに分かると思います。

    >IMPLEMENT_DYNAMIC/DECLARE_DYNAMIC
    これらのMacroは複雑な定義になっていますが、そういう場合はPreprocessすれば良いです。
    例えば、IMPLEMENT_DYNAMIC(CMainFrame, CMDIFrameWndEx)をPreprocessすると以下になります。

    CRuntimeClass* __stdcall CMainFrame::_GetBaseClass()
      { return (CMDIFrameWndEx::GetThisClass()); }

    __declspec(selectany) const CRuntimeClass CMainFrame::classCMainFrame =
      { "CMainFrame", sizeof(class CMainFrame), 0xFFFF, 0,&CMainFrame::_GetBaseClass, 0, 0 };

    CRuntimeClass* __stdcall CMainFrame::GetThisClass()
      { return ((CRuntimeClass*)(&CMainFrame::classCMainFrame)); }

    CRuntimeClass* CMainFrame::GetRuntimeClass() const
      { return ((CRuntimeClass*)(&CMainFrame::classCMainFrame)); }

    ポイントは上記の太字の箇所です。

    DECLARE_DYNAMICは単なる宣言ですので省きます。

    • 回答としてマーク ミッヒー 2011年3月16日 6:09
    2011年3月12日 5:16
  • 同じく、作られたもののライセンスが気になります。

    ちなみに##はToken-Pasting Operatorです。

    • 回答としてマーク ミッヒー 2011年3月16日 6:09
    2011年3月12日 5:35
  • とっちゃん さん、Azulean さん、kozz さん、佐祐理さん、回答ありがとうございます。

    ## が置き換える意味だと言うのは何となく判っていましたが、Azulean さんの言われるとおり、m_pfnCreateObject という名称ではなく、pfnNew で変更 ( 代入? )
     されているんですね。

    皆さん、ありがとうございます。


    残るは Azulean さんご指摘の、著作権がらみの問題ですね・・・。

    Visual Studio 2008 のインシデントが残っているはずなので、MFC のソースを参考にしてプログラムを作る事に問題が無いのか、Microsoft 社に質問してみます。
    今日は臨時休業でしたが。

    回答を頂き次第、このスレッドに投稿させて頂きます。
    ありがとうございました。

    2011年3月12日 5:38
  • 残るは Azulean さんご指摘の、著作権がらみの問題ですね・・・。

    「マイクロソフト ソフトウェア ライセンス条項」というファイルがあるはずです。
    (C:\Program Files\Microsoft Visual Studio 9.0\Microsoft Visual Studio 2008 Professional Edition - JPN\eula.txt)

    これに「3. 追加の許諾条件および使用制限。」、「d. 再頒布可能コード。」に「i. 使用および再頒布の権利。」と「ii. 再頒布の条件。」という定義はあります。
    参考にしてコードを書くことを、著作物の複製・改変・翻案と解釈されるかは、私には何とも言えません。
    複製・改変などとみなされる場合、MFC は「i. 使用および再頒布の権利。」に明示的に記載されているため、「ii. 再頒布の条件」の制限が付されます。この場合、「お客様のプログラムにおいて、再頒布可能コードに重要かつ主要な機能を加えること」などの条件を満たす必要があります。

    個人的には、単に同等機能を再実装するだけであれば、重要かつ主要な機能を加えることに相当するとは思えません。
    ただし、参考にしてコードを書くことが、この条項の制限を受けるかどうかは、私からは何とも言いかねます。

    # この条項で認められている MFC への変更は、アプリケーションの一部を想定されているものとみられます。
    # ビジネスで類似のクラスライブラリを開発するなら、まず参照を禁じるのが妥当な判断だと思います。


    質問スレッドで解決した場合は、解決の参考になった投稿に対して「回答としてマーク」のボタンを押すことで、同じ問題に遭遇した別のユーザが役立つ投稿を見つけやすくなります。
    • 回答としてマーク ミッヒー 2011年3月16日 6:09
    2011年3月12日 6:10
    モデレータ
  • 誤解されるといけないので、私の目的を書いておきます。

    あくまでも Windows 上で動くアプリケーションの開発であり、そのアプリケーション開発に MFC ではなく、MFC のサブセット的なライブラリを作成して使用するつもりです。
    作成したライブラリはアプリケーション開発にのみに使用し、ライブラリ単体での販売、譲渡等は一切行うつもりはありません。

    誤解を招く書き込み、お詫び致します。

    2011年3月12日 6:55
  • ライセンス云々についてはとりあえずおいておくとして。。。
    すごく素朴な疑問です。

    MFCは何が大きすぎるのでしょう?
    ファイルサイズですか?それとも違う何かでしょうか?

    ファイルサイズが問題なのだとしたら、スタティックリンクすれば必要な関数だけがリンクされるので十分小さなサイズになると思います。というより、仮に自作したとしても同じくらいの大きさになると思いますよ。


    わんくま同盟,Microsoft MVP for Visual C++(Oct 2005-) http://blogs.wankuma.com/tocchann/
    2011年3月12日 7:33
  • あ・・・。

    知識不足も甚だしいですね。スタティックリンクしても、使わない関数もリンクされるのとばかり思っていました。

    もっとも、説明すると長くなるから、という理由で MFC は大きい、と書いたのであって、実際はドッキングバーのカスタマイズが目的なんです。
    こちらも Microsoft 社の特許に触れる可能性もありますが、ドッキング / フローティング時の動作を別のものにしたいと思っています。

    そうなると、CFrameWnd クラスの RecalcLayout をオーバーライドする事になりますが、オーバーライドした中身は完全に別のものを呼び出す形になってしまいます。
    本来、CFrameWnd クラスが行っているドッキングバーの処理を、まったく別のものがやっている状態ですので、だったら、CFrameWnd クラス自体を作ってしまおう、というのが発端です。

    ただ、ドキュメント / ビュー アーキテクチャーも使うので、単純に CFrameWnd を CWnd から派生させると MFC の中を大冒険する事に・・・。

    だったら、MFC の勉強も兼ねて、必要なものだけ作ってしまおう、というのが今回の質問に至った経緯です。

    2011年3月12日 7:50
  • ライセンスとか特許については調べなきゃわからないので、とりあえずパスするとして。。。

    ドッキングバーのカスタマイズですか。CControlBar あたりは調査しましたか?まぁそれでも除去。。。となっているところからするとこれじゃだめなんでしょうけど、何をやろうとしているのかわからないのでこれ以上は何とも言えません。

    勉強もかねてということなので、とりあえず作ってみるのはありだと思います。作ってみるという程度ならライセンスに抵触する可能性は高くとも何かを言われることはないと思います。頑張ってください。

     


    わんくま同盟,Microsoft MVP for Visual C++(Oct 2005-) http://blogs.wankuma.com/tocchann/
    2011年3月12日 11:57
  • ドッキングバーではなく、Visual Studio が行っているドッキング可能なツールウィンドウ的なものを作成しています。Microsoft 社の特許に触れる可能性、というのはこの部分です。

    MFC 版は完成していますが、それでデータを作成して、ゲームを作ろうとしているので、クラスライブラリに頼らない、少しでも早い、なんなら C のみのプログラムを書く勢いでやっています。その過程で MFC 版を非 MFC 版にしてみよう、という状態です。

    あくまでも私個人と、友人が使うソフトにその機能があり、ゲームとして世に出る、かどうかは判らないものに関してはそういった機能は一切使いません。
    会社という形態ではなく、個人サークルが作成しているもの、というニュアンスですね。

    2011年3月12日 16:45
  • ドッキングウィンドウシステムとか。。。かな?

    だとすると、Future Pack でやってるようなことでしょうか?とりあえずMFC版はできている。。。ということなので置いておくとして。。。

    少しでも早いを目指すということは現状満足のいかない速度で動作している。。。ということですかね?それならMFCを使わず。。。ではなく、どこにボトルネックがあるかを探す。。。が先ではないでしょうか?

    でも、データを作成する部分というのは、裏方ツールなわけですよね?そこは労力をかけるところじゃないのでは?と思います。

    もちろん使いやすいに越したことはありません。でも完成させようとしているのはゲームで、今話題しているのはそのゲームで使うデータを作成するツールのコーディングに関してですよね?それはMFCに頼らずに作らないとならないほどの開発パワーをかけてまで、ファイルサイズを縮小させなければならないのでしょうか?


    わんくま同盟,Microsoft MVP for Visual C++(Oct 2005-) http://blogs.wankuma.com/tocchann/
    2011年3月13日 2:01
  • とっちゃん さんの仰るとおり、労力をかける部分ではないのは承知しています。

    ですが、私は C++ = MFC というぐらい MFC に頼り切ってきました。その為、WinMain から始まるネイティブなプログラムの経験が乏しいのです。
    また、ゲームとして作成されるアプリケーションは色々な PC で動く事を想定して、少しでも早いものを、という心理が働いています。

    まあ、手段の為に目的を忘れている可能性は否定しませんが、今まで MFC というコップ ( にしては大きいですけど ) の中でしかプログラムを作ってこなかった人間が暴走している、という感じでしょうか。
    特に決まった納期があるわけでも、友人から急かされているわけでもなく、完璧に趣味の世界に入りつつあります・・・。

    2011年3月13日 2:35
  • Microsoft 社からの回答があったので投稿します。
    以下、メールより抜粋 ( 個人情報部分を削除しています )


    弊社といたしましては、大変恐縮ながら、このような MFC コードの実装を参考としたアーキテクチャの構築およびコードの作成については、ライセンス上の許諾範囲外に相当すると考えております。

    MFC ライブラリに含まれるソースコードの上部には英語にて定形のコメントが記載されているかと存じます。
    該当コメントにおいても、同ソースの著作権および知的財産は弊社マイクロソフトに帰属しており、当該ライブラリの参照は、MFC ライブラリを使用いただく際のドキュメントの補足として、MFC ライブラリの実装を確認する目的でのみご利用いただくことを意図していることをご案内しております。
    そのため、MFC ライブラリの実装を参考にして、ライブラリに含まれる弊社実装をお客様のアーキテクチャやコードに反映して作成を行うことはお控えくださいますようお願いいたします。

    今回のご要望の背景としては、弊社 MFC ライブラリをより単純化した機能の作成を検討されていると承っております。
    このような場合、ご実施いただく手順はおおよそ以下のようになるかと存じます。

     (1) 概略の設計段階として、全体として実現したい機能および要件を決定します。
     (2) 上記要件に沿って、独自に機能単位ごとのより詳細なインターフェース、アーキテクチャの設計を考案します。
     (3) 各機能単位ごとに、設計を具体化する実装を行います。
     (4) 各機能を組み合わせて、全体として要件を満たす機能を実現できるように実装の修正と検証を繰り返します。
     
    今回のご要望は、(3) の実装部分において、MFC ライブラリの具体的な実装を参考にされたいという内容と承っております。
    しかし、これは上述のとおりお控えいただきたく存じます。

    例えば、(1) ないし (2) の初期等、より早期の段階において、MFC ライブラリの外部的な動作や、機能のインタフェースなど、抽象度の高い振る舞いのみを参考として、検討を進めていただくことには問題はございません。
    より具体的には、(4) を経て最終的に完成された実装 (ソース コード) と弊社ライブラリの実装を比較した場合に、明らかに主要な実装における類似性が見受けられる場合は著作権上問題となりうるため、あくまでも早期検討段階での参照までにとどめていただければと存じます。

    弊社におけるソース コードの公開の基本的な目的は、上述のとおり弊社ライブラリ使用時のドキュメントの補足および実装の理解という点にございますので、この主目的を基本としてご活用いただければ幸いです。

    弊社の見解としては、以上となります。


    という事で、皆様がご指摘して下さったように、MFC のソースコードを見て、独自のライブラリを作るのはライセンス違反になるそうです。
    ただし、MFC の動作を見て、それを参考にプログラムを作るのは問題ないとの事です。
    もっとも、あまりに酷似していたら、ソースコードの公開を裁判所で迫られるんでしょうね・・・。

    ライセンスに関して助言して下さった方々、ならびに本来の質問に回答して下さった方々に感謝いたします。
    ( MFC にライセンスに関する Microsoft 社の公式見解という事で、不本意ながら、自分に回答マークを付けさせていただきました )

    • 回答としてマーク ミッヒー 2011年3月16日 6:09
    2011年3月16日 6:08