Dll Instances?
Ok,
I have a dll that is a COM plugin for an audio workstation control surface.
For each control surface unit I must load another instance of the plugin.
The plugins are the same and export the same functions (they must). Let's not get into why for the sake of simplicity. But naturally, the exported functions conflict.
The code does not have a DLLMain but does create theApp.m_hInstance upon load.
I thought I could use theApp.m_hInstance as a unique handle for each of the DLL plugin with conflicting exports and ultimately call even a conflicting function using theApp.m_hInstance as a handle and I can,but sadly and curiously theApp.m_hInstance is the same for both conflicting DLL plugins.
So I must be barking up the wrong tree.
Help?
Thanks in advance.
:Ron
I have a dll that is a COM plugin for an audio workstation control surface.
For each control surface unit I must load another instance of the plugin.
The plugins are the same and export the same functions (they must). Let's not get into why for the sake of simplicity. But naturally, the exported functions conflict.
The code does not have a DLLMain but does create theApp.m_hInstance upon load.
I thought I could use theApp.m_hInstance as a unique handle for each of the DLL plugin with conflicting exports and ultimately call even a conflicting function using theApp.m_hInstance as a handle and I can,but sadly and curiously theApp.m_hInstance is the same for both conflicting DLL plugins.
So I must be barking up the wrong tree.
Help?
Thanks in advance.
:Ron
Can't you make a class with the functions and data of the DLL, load the DLL once, and then create objects of the class?
If you have to load a DLL multiple times, i think you will have to fork a new process for each surface and then Load the DLL
If you have to load a DLL multiple times, i think you will have to fork a new process for each surface and then Load the DLL
Thank you for your reply.
The audio workstation exe lets us load a dll plugin for a usb control surface but only connected to one in and out port and on an exclusive midi channel.
If the user wants to add another unit, the they need to load another instance of the plug.
I want to make all subsequent units use a very small version of the original plugin and forward
midi to and from the "master" plug thereby mincing a plugin that supports more than one i/o port.
It works like a champ for one master and one slave but two slaves use the same slave dll and that's where I run into trouble.
If the slave dlls are required to be unique to each additional control surface install the user will need to keep it all straight, that will be over complicated and I will be disliked.
I am trying to find something unique about 2 identical dlls handle wise in another exe's process that will permit me to route traffic between them and the Master dll.
:Ron
The audio workstation exe lets us load a dll plugin for a usb control surface but only connected to one in and out port and on an exclusive midi channel.
If the user wants to add another unit, the they need to load another instance of the plug.
I want to make all subsequent units use a very small version of the original plugin and forward
midi to and from the "master" plug thereby mincing a plugin that supports more than one i/o port.
It works like a champ for one master and one slave but two slaves use the same slave dll and that's where I run into trouble.
If the slave dlls are required to be unique to each additional control surface install the user will need to keep it all straight, that will be over complicated and I will be disliked.
I am trying to find something unique about 2 identical dlls handle wise in another exe's process that will permit me to route traffic between them and the Master dll.
:Ron
Topic archived. No new replies allowed.