Sign in to follow this  
Galapaegos

dlls, interfaces, and accessing objects

Recommended Posts

Galapaegos    277
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

Share this post


Link to post
Share on other sites
swiftcoder    18428
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]

Share this post


Link to post
Share on other sites
Deception666    182
Quote:
Original post by swiftcoder
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]


This is only true if you link to a static runtime. If you use a dynamic runtime, then new / delete and malloc / free should work across DLL boundaries.

Share this post


Link to post
Share on other sites
Galapaegos    277
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

Share this post


Link to post
Share on other sites
Deception666    182
Is this how your code is built?

EXE.exe
Renderer.dll
ResManager.dll

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.

Maybe a little code would help?

Share this post


Link to post
Share on other sites
Galapaegos    277
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

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this