Tuesday 15 September 2015

c++ - Are there any known techniques for using separating a DLL plugin into it's own process? -


Some of our products have a plugin DLL that is loaded by a third party application. Some things that we want to do in our plugin, they struggle with the application process. Although we do not believe that despite these disputes, there is a problem with our plug-ins, whenever they have problems in their applications, they will not generally support the plug-ins until they are removed.

I am interested to see if we can effectively load in our process in any way, while still providing an intuitive experience. The DLL interface can be used to communicate with that plugin application, which quite a few completely plugs on some events from the app and calls from an interface.

Edit: Started by mistake very quickly ...

My initial idea is to create a shim plugin DLL which creates a separate executable which loads the actual plugin DLL.

  • Write parameter in shared memory
  • Set the event to wake up the process
  • The project wakes up and reads the parameters and sends the actual plugin.
  • The response comes back in the same way

    Although all this is happening progressively, it unfortunately involves multiple reference switches for each call The number of calls increases.

    You can not eat your cake and eat it too. DLL can be executed via rundll32 or something like that, but it will not be useful after your plugin.

    Of course you can wrap it: If it was a COM inproc server, you can generate a EXE server with Typelib, then implement it using that DLL. It seems as if it gets it. For Regular DLL, you must provide all the interprocess materials received from com.

  • No comments:

    Post a Comment