FTN95 v5.01

I have upgraded to v5.01 and trying to rebuild our software compatible for VS2005. I have a simple Win32 example which now gives an error at link time when it didn't with v4.x. I am now using /clr /clr_ver 2 when compiling and using dbk_link2.

The code has a call

type (GDIM) paper integer i,ipapty, ndc,ndt ! call gEnqDrawingLimits(paper,ipapty)

and an interface:

subroutine gEnqDrawingLimits(dim,type) use gino_f77 assembly_interface(name='EnqDrawingLimits') type (GDIM), intent(out) :: dim integer, intent(out) :: type real px,py dim=new@('GinoGraphics.GDIM') call papenq(px,py,type) dim%xpap=px dim%ypap=py end subroutine

When compiling I get an error:

[DBK_LINK Ver. 2.0.0 Copyright(c) Silverfrost Ltd 2001-2006] *** Attempt to call Void GENQDRAWINGLIMITS(GINO_F77!GDIM*, Int32*) as if it were GENQDRAWINGLIMITS(GINO_F77!GDIM*, System.Int32*)

What is the difference between Int32* and System.Int32* and how do I avoid this error?

We can take a look at this but it may take a little while because the main expert is currently on holiday.

Can you supply a complete sample so we are sure of the problem. i.e. code we can compile without change that illustrates the problem.

Paul,

I have puttogether a very cut down example which shows the problem. How can I send you a zip file with the 5 files necessary?

Didi you get the zip file?

Yes thanks. Presumably my email reply did not get back to you.

Paul,

Yes, I got your reply, but you didn't acknowledge the zip file, only metioning the /ignore switch suggestion for the other problem I had.

Have you managed to reproduce the unmatched variable types in the code I sent?

Hope to look at this tomorrow.

David

We have had a look at this but we need to do some further test which may take some time to complete.

In the meantime the problem raises two questions...

1. Do you get the same problem on your machine if you build for .NET 1.x?

2. It is necessary to build for .NET 2.0?

At the moment we have chosen to build and release ftn95lib.dll for .NET 1.x only and maybe you should do the same for your DLLs. They will still be available under .NET 2.0. The only essential reason for building a .NET 2.0 assembly is if you want to include .NET 2.0 features in your DLL, i.e. if you want to do something that cannot be done with .NET 1.x. The alternative is either to release two versions of your DLL or to require your users to upgrade to .NET 2.0.

Paul,

I am somewhat confused over all the different components and versions. The reason why we bought FTN95 v 5.0 was because we understood that we needed this version to be able to build dll's which were compatible with VS 2005 (and presumably .NET 2.0). Hense we are now using the /CLR_VER 2 switch.

As you know we have written a C# interface between the dll's built with FTN95 so that GINO is accessible from all the different .NET languages, which all worked fine under VS 2003 (.NET 1.1).

I am fully expecting that we might have to supply two different version of GINO.NET, but I am not sure yet.

If that helps clarify things from our point of view, any information from your side would be helpful.

David

Just to confirm, my understanding is that you do not need to create a 2.0 release. Your 1.1 build will run OK under 2.0. You will only need to build for 1.1 if you have C# components that are not available under .NET 1.1.

Paul,

No, you do not understand our situation.

We have GINO 6.5 built using FTN95 3.4 , which works under .NET 1.1 (VS2003). Unfortunately we have some users who have upgraded to .NET 2.0 (VS2005) and they report that they can no longer use our 1.1 implementation. You yourself said that the previous release of the compiler was not compatible with VS2005.

We are therefore trying to build a set of GINO dll's etc. that can be used under .NET 2.0 (VS2005) and so I am trying to build our next release using FTN95 5.01 with the /CLR_VER 2 switch which I understood we needed to get things to work in the new Microsoft Environment.

It is when we tested the new version that we get the compiler error that I reported and sent to you. I admit that the test was using a F90 test program and obviously uses F90 modules which would not be used by C#, VB users, so we will test the new implementation under VS2005 and see if it works there anyway.

I presume that the error we found is not simple to fix.

Hi David,

As Paul said, there should not be a problem with using a .NET 1.1 library assembly from a .NET 2.0 program assembly. The .NET 2.0 framework is backwards compatible with 1.1. The main reason I can see for building a .NET 2.0 assembly is to take advantage of the new features (e.g. new standard classes).

Do you have any more information on the problems your users are having with using your .NET 1.1 library? Have you been able to reproduce these problems yourself? If so perhaps you could upload / send us a sample of the problem so we can take a closer look at it.

The original bug in this thread has now been fixed.