COM MFCアプリケーションでウィンドウが表示されない

Question

私はATLサポート付きのMFCアプリケーションを持っています。アイデアは誰かがmfcアプリケーションで宣言されたインターフェイスのインスタンスを作成するときです。

comクライアントがcmd.exeの場合、これはすべて正常に動作します。私はインターフェイスをインスタンス化するクイッククライアントを作成しました。このインスタンスが発生すると、ウィンドウは必要に応じて表示されます。

しかし、このインスタンシエーションが別のcomオブジェクト（たとえば、atlサーバーオブジェクト（サービス））で実行された場合、ウィンドウは表示されません。 mfcプロセスはDcomLaunchプロセスで作成されますが、ウィンドウは表示されません。すべて正常に動作しますが、ウィンドウがデスクトップに表示されません。

つの質問：

1）なぜ私の窓は、このような状況では表示されませんか？

2）コンソールアプリケーションで同じインタフェースを作成すると、mfcアプリケーションの1つのプロセスしか作成されず、コンソールアプリケーションが何回起動するのか、そしてサービスが複数のオブジェクトをインスタンス化しようとすると、 1つのmfcプロセスが作成されます！なぜこれが、どうして私はこれを避けることができますか？どのようにして、最初のmfcプロセスが常にクライアント呼び出しに応答する同じプロセスであることを確認できますか？

（私はこれは、すべてのセキュリティ設定が原因だと思う...しかし、私はすでにいくつかと何を変更しよう...）

おかげ

サービスを作成することはできません一般的に

ヌーノ

Answer 1

窓。 Vista以前では、特定のサービスプロパティの「ログオン」タグで「デスクトップとの対話をサービスに許可する」チェックボックスを使用して、サービスがデスクトップと対話する（たとえば、ウィンドウを開く）ことができます。 Vistaをターゲットにしている場合、これは選択肢ではありません。

しかし、これはあなたが扱っているDcomLaunchサービスであることを考慮すると、明らかにそうしたくありません。

• 作成したUIがセッション0
にのみアクセスできるようになります。それはあなたがほとんど誰もがいくつかの理由（順不同）のために、とにかくこれをやって、あなたに対して助言書いた独自のサービスであっても
• ウィンドウを作成すると、（おそらく）特権プロセスに攻撃サービスが作成されます。これは、ユーザーが実行する他のプロセスがサービスのウィンドウと対話できるためです。

上記はVista以前のものであり、とにかく悪い考えであるため、UIを公開したいサービスの一般的に受け入れられている「ベストプラクティス」はUIを含む別個のアプリケーションを持つことです使用するIPCメカニズムを使用してサービスと通信します。