2 or more dlls using the same exported function.

Question

4.00/5 (1 vote)

See more:

I have a control surface plugin dll for an audio workstation.
The workstation only allows a plugin to be connected to one midi port for in and out.
So to support more than one of these control surfaces I made a very simple version of the primary dll plugin that forwards midi messages from it's (second) port to the primary plug in dll for processing. So I load the primary dll for the 1st unit then the smaller I/O re-director plug in for the second unit. It all works great. The two dlls communicate via exported functions for message exchange.

I want to be able to load yet another I/O redirector dll for yet a third or even a forth unit on other ports but would like the DLLs to be generic and not specific to the ports.

My question is: What happens when you load the same COM DLL in the same process space and the same function exports for incoming data?

When I examine the exported functions of my dlls when loaded in the DAW app exe file I only see the exports for one "instance" of the exported function in question.

Will I be able to magicly call the same function on both DLLs simultaneously?
Probably not. I'd like to do something like that.

Posted 22-May-11 13:12pm

Ron Anders

Add a Solution

3 solutions

Solution 1

a well written COM object* is discrete for each instance, so you can have one COM dll server exposing any number of the same object types, and you should have no collisions

However, using a single com object instance from multiple places will not be instance safe, and you may indeed get some thread synch issues

Similarly, a vanilla DLL with an exported function cannot assumed to be 'instance-safe' unless it has some form of handle it needs to distinguish between instances, or none of its functions interact

*assuming class is not singleton

Posted 22-May-11 14:34pm

barneyman

Solution 2

I don't know about COM specifically (since I don't use it much) but a regular DLL would support this, given of course that you code the "simultaneous" nature since that's not default behavior (you probably need a DLL manager class that loads all available DLLs and manages calls to/from to support one function call going to multiple places).

Posted 22-May-11 15:21pm

Albert Holguin

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Ron Anders · Accepted Answer · 2011-05-25T16:05:00

I think I may have a solution to my own issue but can't quite figure out how it might be done. I don't have a DDLMain as this is a COM interfacing? plug in for the DAW software. If I could get the HInstance of the smaller I/O redirector plug with it's conflicting exports then I could maybe send the Master plug the address of that particular instance's function to be called.

But without a DLLMain most goolge searches are fruitless.

Thanks in advance for the help,

********* Addendumb *********

theApp.m_hInstance is my handle to the instance.

But curiously is I load 2 copies of the DLL and pass theApp.m_hInstance to the main DLL from both for a look-see, to my chagrin, both DLLs are sending over the same exact value for theApp.m_hInstance.