Hi all, here i am again...
I'm trying to let a subroutine contained in a .dll access variables of the executable, which are declared in a module of the executable. Since this is not possible, i tried to move those variables to a module belonging to the .dll source. the .dll project compiles and links just fine. the executable does not link to those variables.
what is happening?
in the meantime i read this: https://software.intel.com/en-us/node/535307
i found out that if in the module in the dll i write
!DEC$ ATTRIBUTES DLLEXPORT::"name_of_the_variable_to_be_made_available_by_the_executable"
then it works fine.
what if i wanted to export all the variables in that module? apparently the DLLEXPORT cannot act on a "module"...
Usually when there is no short way to do something, it means that the long way is wrong. Is this the case? is there a more correct way to accomplish what i'm trying to do?
A DLL cannot see symbols of an EXE that links to it. Such references are one-way only. If you built the module into a DLL, then the EXE (and other DLLs) could reference its variables - each must be named in a DLLEXPORT directive. When the module is USEd, the DLLEXPORTs are turned into DLLIMPORTs by the compiler so you don't need to specify those again.
You can make a user defined type, containing all the variables you wish to export, and then declare one instance of this type which is DLLEXPORTed. Then assuming same type declarations in both DLL and EXE, the bunch of variables are accessible (with pre-pended container name).
yes this is what i'm currently doing and it's working.
However, one strange (nice) thing happens: so far i have two modules, (1) "dll_vars" and (2) "exe_vars";
(1) is in the executable source files, (2) is in the dll source files;
if i write "use dll_vars" in the module "exe_vars", all routines of the executable using (2) have also access to the variables declared in (1).