Thanks for the quick reply.

I just tried with the USE DFPORT, ONLY: GETENV, and the behavior is the same as without the ONLY.

Now I am creating, as you propose, the same kind of project, but with simplified code, and see if the problem persist.

Best regards,
Emilio

This works for the windows version, and this also confirms that the problem is related to the getenv call.

However, it is not compliant with Fortran 77 and the executable cannot be built on Solaris.

I am still trying to create a small but functional program that reproduces the error. No success at the moment...

Thank you Ian.

On Solaris we are using Sun Fortran 95 8.4 SunOS_sparc 2009/06/03, invoked with "f95 -f77".
However, we are not administrators of this machine, which is widely accesed in our company, and a change of the development platform although feasible, is not inmediate.

On the other hand, we already found a way of making the software work, and this is creating two versions of the subroutine.

What I am doing now is trying to isolate and reproduce the problem, we might get some interesting result from this.

Best regards,
Emilio Murcia

*** Please rename test-vb.for to Test.vb ***

Here there is a very simple case of the DLL call.

Calling the READDLL from the VB program causes the error under certain conditions, related with the /iface: option.

In this case of just one string in the argument list, the default calling convention and string length argument passing after all arguments work. In a more realistic case, we would need to rewrite our VB call.

Changing the options in the "External Procedures" page did not provide a working solution.

I guess the key would be to choose an appropriate option or property for the ATTRIBUTES compiler directive so that the code is minimally changed and still works with CVF and Solaris... but I lack the necessary expertise:

Here is the Code_dll.for:

	SUBROUTINE READDLL (TTL)
*	USE DFPORT, ONLY: GETENV
	!DEC$ ATTRIBUTES DLLEXPORT :: READDLL
	IMPLICIT NONE

	CHARACTER TTL*(*)
	CALL GETENV ('WINDIR',TTL)
	RETURN
	END

Jim,

Thanks for the comment, I agree.

Anyway, in the example above the "WINDIR" was just a "dummy variable" that would work for any of you trying to build the dll.
In our real case, we are getting the content of a variable called "BASES_DATOS" (in perfect Spanish), which is available for our users in both Windows and Solaris.

Best regards,
Emilio Murcia

Quote:

jimdempseyatthecove wrote:

>>CALL GETENV ('WINDIR',TTL)

Emilio,

If the above call is indicative of the environment variable "get" calls, then I would have to assume for portability between Windows and Solaris, that the above call to getenv is in a conditional code section or seperate compile source for your Windows build as opposed to for Solaris build. Meaning you already are performing platform specific build (compile time) customizations, and adding the appropriate platform appropriate USE would be of no consequence. Note, the specified module could be a common wrapper of your own creation (USE YourGetEnvironmentVariable_module).

Jim Dempsey

Steve,

Thank you for your answer.
I just tried your solution and it worked perfectly.

Best regards,
Emilio Murcia

Quote:

Steve Lionel (Intel) wrote:

OH! Now I see. The missing piece is that you compile your source with /iface:cvf or something that changes the default calling convention to STDCALL. This will cause the call to GETENV to corrupt the stack because it wants the default (C) calling convention.

The solution here is to not use /iface:cvf but rather to change the ATTRIBUTES line to:

!DEC$ ATTRIBUTES DLLEXPORT, CVF:: READDLL

The reason the USE DFPORT fixes the problem is that its declaration of GETENV has ATTRIBUTES DEFAULT, changing the convention back to the default.