0

一部の製品には、サードパーティのアプリケーションによって読み込まれるプラグイン DLL が含まれています。プラグインでやりたいことのいくつかは、アプリケーション プロセスと競合しているようです。これらの競合があってもプラグインに問題があるとは考えていませんが、アプリケーションに問題がある場合は、通常、プラグインが削除されるまでサポートを提供しません。

シームレスなエクスペリエンスを提供しながら、独自のプロセスでプラグインを効果的にロードできる方法があるかどうかを確認したいと考えています。DLL インターフェイスは、特定のイベントでのアプリケーションからプラグインへのほぼ完全な呼び出しであり、プラグインがアプリケーションとの通信に使用できるインターフェイスです。

編集:誤って提出が早すぎました...

私の最初の考えは、実際のプラグイン DLL をロードする別の実行可能ファイルを生成する shim プラグイン DLL を作成することです。2 つのプロセスは共有メモリを使用して通信するため、プロセスは次のようになります。

  • プラグインのコールバック
  • パラメータを共有メモリに書き込む
  • イベントを設定してプロセスをウェイク
  • プロセスがウェイクしてパラメーターを読み取り、実際のプラグインに送信します。
  • 同様の方法で応答が返ってきます

これにより、すべてが連続して実行され続けますが、残念ながら、呼び出しごとに複数のコンテキスト切り替えが必要になり、呼び出しの数が増えるにつれてパフォーマンスの問題が発生する可能性があります。

4

1 に答える 1

0

ケーキを食べて、それも食べることはできません。DLL は rundll32 などを介して実行できますが、プラグインとしては何も役に立ちません。

確かにラップできます。COM インプロセス サーバーの場合、typelib から EXE サーバーを生成し、その DLL を使用してその実装を行うことができます。それは途方もなくシームレスに聞こえます。通常の DLL の場合、COM から取得するすべてのインタープロセスのものを提供する必要があります。

于 2013-06-21T19:38:41.110 に答える