How to share a pointer between an EXE and a DLL
-
Apologies if the description is long; I just want to make the question clear(er). I have a WIN32 project in which there are some applications and some DLLs that may or may not use a framework. The framework itself is statically linked to apps and DLLs and it has an important data structure that should be unique. Currently, when a DLL is loaded it has no way of knowing if the process in which it was loaded uses the framework and if the data structure has been created or not. If DLL uses the framework and the EXE doesn't, the DLL can initialize the data structure and all is fine. If the EXE uses the framework and the DLL doesn't, the EXE will initialize the structure and all is fine again. The problem appears when both the DLL and the EXE use the framework and only the EXE should initialize the structure and the DLL should just somehow find the address and use the data structure. I know I could use a shared memory area but this is not inter-process communication so I'd rather use something simpler. I even thought of setting an environment variable with the address of the structure but somehow the solution seems cheesy. Do you have any suggestion? Is there any standard/better way of doing this?
Mircea
-
Apologies if the description is long; I just want to make the question clear(er). I have a WIN32 project in which there are some applications and some DLLs that may or may not use a framework. The framework itself is statically linked to apps and DLLs and it has an important data structure that should be unique. Currently, when a DLL is loaded it has no way of knowing if the process in which it was loaded uses the framework and if the data structure has been created or not. If DLL uses the framework and the EXE doesn't, the DLL can initialize the data structure and all is fine. If the EXE uses the framework and the DLL doesn't, the EXE will initialize the structure and all is fine again. The problem appears when both the DLL and the EXE use the framework and only the EXE should initialize the structure and the DLL should just somehow find the address and use the data structure. I know I could use a shared memory area but this is not inter-process communication so I'd rather use something simpler. I even thought of setting an environment variable with the address of the structure but somehow the solution seems cheesy. Do you have any suggestion? Is there any standard/better way of doing this?
Mircea
-
Apologies if the description is long; I just want to make the question clear(er). I have a WIN32 project in which there are some applications and some DLLs that may or may not use a framework. The framework itself is statically linked to apps and DLLs and it has an important data structure that should be unique. Currently, when a DLL is loaded it has no way of knowing if the process in which it was loaded uses the framework and if the data structure has been created or not. If DLL uses the framework and the EXE doesn't, the DLL can initialize the data structure and all is fine. If the EXE uses the framework and the DLL doesn't, the EXE will initialize the structure and all is fine again. The problem appears when both the DLL and the EXE use the framework and only the EXE should initialize the structure and the DLL should just somehow find the address and use the data structure. I know I could use a shared memory area but this is not inter-process communication so I'd rather use something simpler. I even thought of setting an environment variable with the address of the structure but somehow the solution seems cheesy. Do you have any suggestion? Is there any standard/better way of doing this?
Mircea
I'm certainly no expert at COM, but this sounds like the kind of situation where it would be a good fit.
-
Couldn't the executable simply call a function of the DLL, passing the address of the data?
"In testa che avete, Signor di Ceprano?" -- Rigoletto
Thanks for the suggestion but the DLL-EXE API is set in stone. With over 300 DLL modules changing the API is not easy/feasible. I have to find a different solution. I'll probably go with the environment variable; I'll just have to hold my nose while coding :-D
Mircea
-
Thanks for the suggestion but the DLL-EXE API is set in stone. With over 300 DLL modules changing the API is not easy/feasible. I have to find a different solution. I'll probably go with the environment variable; I'll just have to hold my nose while coding :-D
Mircea
-
Apologies if the description is long; I just want to make the question clear(er). I have a WIN32 project in which there are some applications and some DLLs that may or may not use a framework. The framework itself is statically linked to apps and DLLs and it has an important data structure that should be unique. Currently, when a DLL is loaded it has no way of knowing if the process in which it was loaded uses the framework and if the data structure has been created or not. If DLL uses the framework and the EXE doesn't, the DLL can initialize the data structure and all is fine. If the EXE uses the framework and the DLL doesn't, the EXE will initialize the structure and all is fine again. The problem appears when both the DLL and the EXE use the framework and only the EXE should initialize the structure and the DLL should just somehow find the address and use the data structure. I know I could use a shared memory area but this is not inter-process communication so I'd rather use something simpler. I even thought of setting an environment variable with the address of the structure but somehow the solution seems cheesy. Do you have any suggestion? Is there any standard/better way of doing this?
Mircea
I would have used a (third) dll for the (static) "data structure"; the equivalent of a "data repository".
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
-
Rather than use the environment variable you could use the Registry.
Interesting idea! However I would have to take care of cleaning the registry when the app finishes. The environment variable just "evaporates" on exit. Do you see any technical advantage to using the registry?
Mircea
-
Interesting idea! However I would have to take care of cleaning the registry when the app finishes. The environment variable just "evaporates" on exit. Do you see any technical advantage to using the registry?
Mircea
Delete a registry key or value is very simple. And (almost) no one else (except your app) would like to change it.
-
Thanks for the suggestion but the DLL-EXE API is set in stone. With over 300 DLL modules changing the API is not easy/feasible. I have to find a different solution. I'll probably go with the environment variable; I'll just have to hold my nose while coding :-D
Mircea
Is the "framework" API set in stone? It sounds like it should be the one controlling the existence of this structure. You said it was statically linked to both the DLL and the EXE, hence two copies of the library, but you can force it to use a single shared memory location to hold this structure's pointer. Both the DLL and the EXE would ask the framework for a pointer and the framework would use some sort of mutual exclusion / atomic operation to synchronize its access to the shared memory location to either allocate or use the existing structure.
Be wary of strong drink. It can make you shoot at tax collectors - and miss. Lazarus Long, "Time Enough For Love" by Robert A. Heinlein
-
Is the "framework" API set in stone? It sounds like it should be the one controlling the existence of this structure. You said it was statically linked to both the DLL and the EXE, hence two copies of the library, but you can force it to use a single shared memory location to hold this structure's pointer. Both the DLL and the EXE would ask the framework for a pointer and the framework would use some sort of mutual exclusion / atomic operation to synchronize its access to the shared memory location to either allocate or use the existing structure.
Be wary of strong drink. It can make you shoot at tax collectors - and miss. Lazarus Long, "Time Enough For Love" by Robert A. Heinlein
JudyL_MD wrote:
It sounds like it should be the one controlling the existence of this structure.
Absolutely right.
JudyL_MD wrote:
the framework would use some sort of mutual exclusion / atomic operation
Key words here are "some sort of". That was the purpose of my question to ask for recommendations for "some sort of" mechanism :)
Mircea
-
JudyL_MD wrote:
It sounds like it should be the one controlling the existence of this structure.
Absolutely right.
JudyL_MD wrote:
the framework would use some sort of mutual exclusion / atomic operation
Key words here are "some sort of". That was the purpose of my question to ask for recommendations for "some sort of" mechanism :)
Mircea
The first thing that pops into my head is to force the EXE and DLL to make their initial framework calls from separate threads and have the framework use a named mutex. Not elegant spawning a thread just to make a single function call and immediately waiting for that thread to finish, but it would work.
Be wary of strong drink. It can make you shoot at tax collectors - and miss. Lazarus Long, "Time Enough For Love" by Robert A. Heinlein
