Communication between two DLLs within the same process

Question

I have an application that loads "aaa.dll". "aaa.dll" loads two other dlls "bbb.dll" and "ccc.dll".

aaa.dll is a third party dll not written by myself. But bbb.dll and ccc.dll are written by me.

Is there any way for bbb.dll and ccc.dll to communicate with each other? Pointing to any resource will be very helpful.

Type of communication: I need to send a state as set or not from bbb.dll to ccc.dll.

Thanks everyone. LoadLibrary()/GetProcAddress did the trick. I wanted to ensure bbb.dll doesn't load a second copy of ccc.dll. Also Interprocess Communication seems to be overkill for what I needed was in-process communication.

Thanks everyone again.

Answer 1

You can do direct API calls. Its in same process so the static objects will also be shared.

Answer 2

DLLs do not communicate. Classes communicate. Think about the classes that need to communicate to each other, and the answer will be much more clear.

Answer 3

You can use any of a wide range Win32 IPC stuff - shared memory, mutexes, events, etc. give more details on what kind of communication you need and forum will give you more concrete advice.

Answer 4

ccc.dll should export a 'SetState' function. bbb.dll could then call said function whenever it needs to. You'll need to link bbb.dll to ccc.dll, either statically or via LoadLibrary/GetProcAddress.

Answer 5

You need a third assembly to act as an interface between the two. This interface assembly would export all the required objects and/or methods required for the two other assemblies to communicate with one another.

This following example is of course considering .NET as the platform, but the same exact concept can be used in Win32/C++ projects.

This is sort of a tough one in regards to architecture. Two DLL's in .NET cannot directly communicate two ways without some overhead, however, you can communicate one way. The reason is you can only reference one assembly from another, otherwise you will have a circular reference.

There is a simple solution though, but this would require three assemblies on your part. Take the following assemblies:

• Interface.dll
• Client.dll
• Server.dll

Just by names you should be able to get a good idea of how this is going to work. Basically, Interface.dll would contain the exposed objects that both Client.dll and Server.dll would need to communicate with one another. Both Client.dll and Server.dll would reference and Interface.dll to gain access to these objects.

With that method, both assemblies have access to all the objects that either one would need to communicate. Interface.dll would also contain exposed methods that both Client.dll and Server.dll would need to communicate. So it could contain for example a "Send" and "Receive" methods, that either Client.dll or Server.dll can use.

You would have to develop some sort of communication standard for this.

• What are these assemblies going to communicate with one another?
• How are these assemblies going to communicate?

With those two being said, whether you are communicating actual classes and objects or just messages, a third assembly to handle this would work flawlessly, as long as you put in the effort in the architecture and design.

Don't take the names to heart, Client.dll, Server.dll, and Interface.dll are all just examples of a common methodology of how such a task can be done. Using this method, there would be no circular references, and thus your assemblies could communicate two ways, instead of one.