DLL using objects from calling EXE
I am using a DLL to plug my game-specific code into a generic engine. I need to let the DLL know about all the subsystem objects (graphics, input, timer, sound, etc.) in the calling application. I pass pointers (to the subsystem objects) to the DLL when it is loaded, and I then use these pointers within the DLL to access the subsystems from within the game-specific code.
At least, that is my desire. The DLL doesn''t seem to like referring to memory that is not in its own space. So how would I go about getting the DLL to use the subsystem objects allocated by the calling application?
Thanks in advance,
Mike
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/base/using_shared_memory_in_a_dynamic_link_library.asp
I don''t know why your dll can''t use memory allocated by the calling process, since the dll''s memory space is mapped to the caller''s, but maybe your modules are using seperate heaps.
------------
- outRider -
I don''t know why your dll can''t use memory allocated by the calling process, since the dll''s memory space is mapped to the caller''s, but maybe your modules are using seperate heaps.
------------
- outRider -
I have changed my approach a bit. I would like to convert all my subsystem classes into singletons, which are initialized at the start of the game. These singleton subsystems would then be used by the game-specific classes defined in the DLL. Unfortunately, the DLL and the EXE would each have their own instance of the singleton.
Is there a clean (or semi-clean) way to allow the DLL and EXE to share the same singleton object?
-Mike
Is there a clean (or semi-clean) way to allow the DLL and EXE to share the same singleton object?
-Mike
quote:from the MSDN:
Win32 DLLs are mapped into the address space of the calling process. By default, each process using a DLL has its own instance of all the DLLs global and static variables.
So does this mean that a DLL will use the calling executable''s memory space? If so, then why does using a singleton class with both the EXE and DLL result in two seperate singletons created for each? How would I get them to share the same singleton instance?
outRider, I looked through that article, but it seems to be oriented towards sharing a single DLL''s memory across multiple processes, which isn''t quite what I think I want.
Any thoughts?
Mike
an easy way to allow the dll to have access to the exe''s singletons, although non-clean imho, is to set them up as global, non-static, variables in the exe and to mark them as extern in the dll. that way the linker will resolve the extern references in the dll with the exposed variables of the same name in the exe.
but as outRider has already mentioned, passing pointers to your class objects to the dll should work, as the dll is mapped into the exe''s address space. it essentiallly becomes a part of the exe as if it were statically linked by the linker instead of dynamically linked by the OS loader and/or runtime.
what exactly do you mean by "The DLL doesn''t seem to like referring to memory that is not in its own space"? are you getting exceptions, and if so what kind, and if not, what then? have you traced through your code to validate that the pointers are pointing to the same address within both the exe''s code as well as within the dll''s?
also, if you''re using C++, have you tried using references instead of pointers?
but as outRider has already mentioned, passing pointers to your class objects to the dll should work, as the dll is mapped into the exe''s address space. it essentiallly becomes a part of the exe as if it were statically linked by the linker instead of dynamically linked by the OS loader and/or runtime.
what exactly do you mean by "The DLL doesn''t seem to like referring to memory that is not in its own space"? are you getting exceptions, and if so what kind, and if not, what then? have you traced through your code to validate that the pointers are pointing to the same address within both the exe''s code as well as within the dll''s?
also, if you''re using C++, have you tried using references instead of pointers?
gahh! please disregard my previous post re: using externs. i was being a stupid-head and mixed up my thoughts on static linking vs dynamic linking.
doctorsixstring: If you find any decent solution pleas tell me becouse I have almost exact same problem.
You should never let your fears become the boundaries of your dreams.
You should never let your fears become the boundaries of your dreams.
quote:Original post by Anonymous Poster
what exactly do you mean by...
Basically, my main executable initializes my singletons, and then I load the DLL and call its object creation functions (i.e. Game* CreateGameObj()). I set breakpoints in the DLL and notice that Gfx::Instance() == 0 (Gfx is one of my singleton subsystem classes). In other words, the singleton is never created in the DLL.
As I was typing, I may have just realized my problem. Should I initialize my singletons AFTER loading the DLL w/ LoadLibrary()? I have a slightly non-traditional feature in my singleton classes - the first call to GetInstance() will NOT create the singleton class, but will return NULL until the user runs SingletonClass::Init(). I am using this so that I may do all my subsystem initialization at one time (as well as cleanup using SingletonClass::Destroy()).
Also, I have been thinking about not using a DLL after all. It may be easier to simply have all the game code in the main executable. This would mean I would have to put the same WinMain() code in every individual game that uses my engine, but that may not really be much of a price to pay. What do you guys think? Is using a DLL worth it?
-Mike
[edited by - doctorsixstring on October 13, 2003 2:06:06 PM]
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement