Hi Everyone, My main engine is using an interface which determines the type of renderer the engine should use. All the rendering specific code for opengl/directx can be found in the appropriate sub-libraries. The engine will call 'LoadLibraryEx' on the appropriate renderer and will call an 'init' function. I believe its very similar to a factory. Bascially, I have a class called a scene that is passed to the renderer and the dll traverses and renders the scene appropriately. The normal setup for an application would look something like this: Create a window Create a MainEngine object Initialize the Engine (which loads/sets up the renderer) Create a scene Add the scene to a queue All of the above works perfectly. However, my next task has been to add texturing to the scenes. My goal is to have a resource manager which can keep track of all textures, scenes, etc. and you will send a message to the main engine to render the appropriate scene. The problem I've encountered is that the renderer gets mapped into the processes address space, but it can't find the address for my resource manager. Here is a better diagram of whats going on: [app] (loaded on execution) --> [engine] (loaded during engine setup) --> [opengl renderer] So my question is, what is going on here? MSDN states that the renderer dll will be mapped into the calling process (which should be the main engines address space, which should just be the exe's address space if I understand it correctly) and it should have access to everything available to the main engine and in the exe. If this isn't the case, is there any way to make something along these lines work? And if there isn't, do you have any suggestions on a redesign? Thanks! -brad

Quote:
You will only have access to the DLL on exported interfaces.

You will also have to be carefull about memory allocation, as you can't delete memory in the EXE that was new'ed in the DLL and vice-versa.
These are sadly limitations of the windows DLL system, dynamic libraries on most other platforms are much simpler [grin]

I definitely understand the memory allocation mismatch issues. My idea is that the resource manager would be a singleton, and everything that needs to load/use a resource would need access to this manager to retrieve their specific data. My resource manager is initialized along with my renderer, but the renderer is unable to access the resource manager singleton.

Everything is linked against the same runtime (mt dll debug), so there shouldn't be any issues in that general area.

-brad

My code is built in this order:

1. MyEngine.dll (and all of its dependencies)
2. Renderer.dll
3. exe

Both the renderer and exe link against MyEngine.dll.

Basically, my renderer will make a call to the resource manager "gsresourcemgr::get ()", in an attempt to fetch the loaded texture. This call fails because it returns an invalid address (0x00000000).

Quote:Then you EXE.exe would load the Renderer.dll, which then loads the ResManager.dll. No matter, a DLL should be visible by the whole process, so calling your resource manager should be fine.

This is good that you mentioned it. My resource manager is being created within my exposed engine class. It then loads the Renderer.dll. This seems to be the same as loading it from the exe, correct?

-brad