Hey, I have a convoluted problem that may have multiple solutions or even a redesign. I have a great amount of C++ experience and the VS 2003 compiler, but when it comes to linking and DLLs I have a great deal to learn.
My company has a logic base that is shared as a DLL for usage with different GUIs. The logic should remain the same for a Java Web app, a DirectX/OpenGL GUI, or our hardware solution with a custom made screen. This is our reasoning for keeping the data and logic of our menu system in a separate DLL.
I had just finished a new interface to use this DLL as an OpenGL interface. Everything at this stage works.
However, word came from on high that this interface needs to show up in the same executable as another interface for a different machine, using Windows multi-monitor support. Our OpenGL tool can do this by generating the interface itself as another DLL to be added to this third application. This means we have an OpenGL DLL loading our menu logic DLL, and a third final application project loading both.
The problem, then, reared it's ugly head when I tried to use UDP network access to control the GUI. The menu logic library seems to be loaded by both the executable and the OpenGL interface DLL as separate copies (I have been unable to confirm this in debug mode as I'm having difficulty making the compiler see the debug data of the libs), and while the interface loads the data correctly and displays all the default states, the executable with the UDP can't access the same copy of the data.
Is there a way to design this to work as intended, or will I have to import ALL the code from the OpenGL DLL as a seperate copy and recompile it into the new executable, thereby eliminating the second DLL?
