In our company we use a big number of critical programs written in pure Fortran 77, and we are nowadays successfully performing a transition from CVF to IVF (XE 2013) because of the transition to x64.
99,9% of the times the source code remains compatible, and that is great news.
However, we are facing a problem that we did not have with CVF: some of our subroutines callgetenv, and until now we were able of using these system calls with no USE DFPORT sentence but now, with IVF, this statement is needed.
This sentence is not desired because our software is multiplatform, while DFPORT is --afaik-- Windows-specific. Basically, from the same source files we build:
- Windows executables (Win32 / x64)
- Windows dll (static) (Win32 / x64) -- same source as above, except that the "main" program is not included in the project <-- the problem appears with the dlls
- Solaris SPARC executables
Our dll's are called by a GUI writen with MS VS2008 Express --it could be migrated to VS2010 Professional if that would help--.
In Windows, both exe and dll build with no comments. However, calling the dll from the GUI causes an error and the GUI informs of a write attempt into protected memory. On the other hand, adding a USE DFPORT sentence in the subroutine works, but as I commented this is undesired.
Can we somehow "initialize" the system calls so that the Fortran code also works in the dll, while keeping compatibility with Unix?
Another option would be to create two versions of a subroutine just containing the "getenv" call. In the subroutine version for the dll, an USE DFPORT statement would be added, while in the other version --for Windows and Unix executables-- no USE would be needed... but this solution would imply forking the code.
P.D.: The development platform is: Visual Studio 2010 Professional + Intel Parallel Studio XE 2013 running on Windows XP SP3