| View previous topic :: View next topic |
| Author |
Message |
silverdan
Joined: 14 May 2009 Posts: 29
|
Posted: Tue Nov 16, 2010 7:57 pm Post subject: Pass global variable from DLL to Main EXE? |
|
|
Hello, I am trying to pass a global variable from a DLL to a Main executable. I am converting hundreds of Fortran 77 subroutines(in a huge static library), hundreds of include files with common statements, and hundreds of Main executables that use the values populated in the static library via common statements.
After converting, the static library to a dynamic library(some .net calls) I see that the values from the common statements are not saving to the main executable.
As such, I decided to write a small sample app doing so, but it does not work either. So I'm trying now with a module with no success either.
What am I missing?
| Code: |
PROGRAM GlobalExe
use GlobalModule
Implicit None
CALL global_set_value()
print *, 'value=',global_id
END PROGRAM
|
I have the following test Subroutine in a DLL
| Code: |
SUBROUTINE global_set_value ()
use GlobalModule
IMPLICIT NONE
global_id = "Global Val"
RETURN
END SUBROUTINE global_set_value
|
I have the following test Module:
| Code: |
module GLOBALMODULE
implicit none
!Global variable(s)
character*10,save :: global_id
end module
|
|
|
| Back to top |
|
 |
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 8283 Location: Salford, UK
|
Posted: Wed Nov 17, 2010 9:29 am Post subject: |
|
|
This topic comes up from time to time and you may be able to find my reply by searching on this forum.
The trick is to use LOC to get the addresses in the exe and dll and you will find that they are independent. There are various ways to pass the data via subroutine calls but a new approach (that I have not tried) is to use interprocess shared memory. See the Knowledge Base article http://forums.silverfrost.com/viewtopic.php?t=1321 |
|
| Back to top |
|
 |
silverdan
Joined: 14 May 2009 Posts: 29
|
Posted: Wed Nov 17, 2010 2:06 pm Post subject: |
|
|
Paul,
I spent a long time searching the forum yesterday for, common, module, dll, and some others I don't recall now
I would like to use as little changes as possible. So, not sure about using SHARENAME and such.
I'm just not sure why it worked in the old code/compiler combination and not this one.
Is the reason it works with MS Dev Studio Fortran compiler because it is a Static Library being used by the Main executable?
--Dan |
|
| Back to top |
|
 |
silverdan
Joined: 14 May 2009 Posts: 29
|
Posted: Wed Nov 17, 2010 3:48 pm Post subject: |
|
|
Well, it seems that SHARENAME is not available in .NET. I tried the sample and it gives the following error:
Error 1 SHARENAME is not available in .NET C:\temp\ShareA\ShareA\FreeFormat1.F95 9
Any other suggestion? I would really prefer to use a .Net DLL instead of a Win32 LIB
Thanks,
Dan |
|
| Back to top |
|
 |
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 8283 Location: Salford, UK
|
Posted: Thu Nov 18, 2010 2:43 pm Post subject: |
|
|
Yes it would work OK for a static library where the library is built into the executable at link time.
I don't have any suggestions on how this can be done if you limit yourself to very few code changes. |
|
| Back to top |
|
 |
silverdan
Joined: 14 May 2009 Posts: 29
|
Posted: Thu Nov 18, 2010 2:50 pm Post subject: |
|
|
Ok, it is quite a priority for us that this gets done. So, I guess that changes the game plan to doing more work as necessary. So any suggestions would be great.
A .Net dll is the way we need to go, so SHARENAME seems to be out of the question. Right?
Any suggestions would be much appreciated, even if it will take a while to complete.
Sincerely,
Dan |
|
| Back to top |
|
 |
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 8283 Location: Salford, UK
|
Posted: Thu Nov 18, 2010 6:38 pm Post subject: |
|
|
The underlying Windows API functions that drive SHARENAME are CreateFileMapping and MapViewOfFile.
These functions will be available under .NET either directly or indirectly via .NET functions that call them.
Having said this, it would require work by us in order to implement this using SHARENAME and this may be the only sensible way forward. I am not sure at this point if this is feasible or how much it would cost.
Regarding alternative approaches, given that memory can sometimes "move around" because of garbage collection, it may be necessary to provide "get" and "set" functions for each shared variable.
Sometimes users have taken the approach of putting all of the shared variables into one array (using EQUIVALENCE statements if you wish). The address of this array can then be passed with each subroutine call. This is broadly equivalent to using member functions in C# etc. |
|
| Back to top |
|
 |
|