VB.NET 64 bit calling DLL compiled with Intel Fortran 10.1.024 [Intel 64]

[John_P_1]

We have alegacy software product that runs in 32-bit mode on IA32 and x64 systems. The32-bit VB.NET routine calls a 32-bit Fortran DLL. No problems.

We want to move to full 64 bit programming.We have experience compiling x64 applications written entirely in Fortran and runningon x64 systems and have no issues to report. The 64-bit VB.NET program is to call a 64-bit Fortran DLL. Right away there was a problem. The VB.NET passes arrays of data but the DLL does not interpret the data correctly. We have simplified the problem to a sample. The Fortran DLL code is attached.

The data passed is an integer array and the upper dimension of the array. In this sample, the array storesthe numbers0 through 6, and the dimension is passed as an integer varaible, 6. The integer value 6 is passed okay. The elements of the array are not. We tested several KINDs of integers. The problem appears for all types. The sample uses 32 bit integers in VB.NET and Fortran. However, the VB.NET caller is 64 bit and the DLL is 64-bit. Type matching is correct between VB.NET and Fortran.

Fortran output:

integer variable, upper limit of array simension: 6
Array:

Index Value

0 0
1 6
2 6
3 -2147404312
4 1602
5 1516080
6 0

The upper dimension appears at entry 1 & 2, there is a zero at 0 entry, and the rest appears to be random data, except for the 6th, which is zero.

Premier support are stumped for now, because of the load of the 11.0 release, and asked me to check this forum. Someone out there must know something obvious that we missed. For your further information, the identical code in VB.NET and Fortran, if set for 32-bit applications, runs as expected and outputs

6

0 0
11
22
3 3
4 4
5 5
6 6

My colleaugue tells me that the VB.NET caller passes an array of Int32s and was written and compiled with MS VS 2008 & .NET Framework v3.5.

Thanks in advance for any help,

John Potjewyd

[Steven_L_Intel1]

I don't see the attachment. What is the Premier Support issue number?

[John_P_1]

It is premier support issue # 522856. Ron was working on it after Kirill Mavrodiev was unable to work on it. We are stuck as our resident VB gurus believe it must be a Fortran fault, having to do with argument passing conventions that have changed between the (working) 32-bit version and the (failing) 64-bit version, and with possibly new, hidden arguments.

The uploads were made using your system, with "Add Files." I just clicked "Add Files" now and it lists the directory as "VB.NET Fortran x64", and states there are two files in it. The two zip files are: one for Fortran code, other for VB.NET code. Are you able to access these files?

VB-DotNETSample.zip, loads with MS VS 2008

SampleFortranDLL.zip, loads with MS VS 2005 only. Warning: writes a txt file on the root of C: drive.

Both zips contain all project files.

Has anyone else tried running a x64 application in a Fortran DLL compiled in MS VS 2005 through a VB.NET calling application with MS VS 2008 & .NET Framework v3.5?

Further information: we have compiled the DLL in PGI Fortran demo compiler for x64 and achieve output identical to the DLL compiled in Intel Fortran, with identical (but wrong) output.

There must be an absolutely ridiculous reason for this. Else everyone who uses x64 applications would be unable to run it with an x64 VB.NET application, and your board would be full of complaints.

Thanks,

John

[Steven_L_Intel1]

The way attachments in this forum work, you have to click on the file name in the "folder" and then click the "Add attachment" button. I am told that this rather convoluted method was chosen because that's "the WordPress way" and they wanted a common interface among the forums, blogs and knowledge base.

Thanks for the issue ID - I'll check that out.

[John_P_1]

Quoting - Fortranic

It is premier support issue # 522856. Ron was working on it after Kirill Mavrodiev was unable to work on it. We are stuck as our resident VB gurus believe it must be a Fortran fault, having to do with argument passing conventions that have changed between the (working) 32-bit version and the (failing) 64-bit version, and with possibly new, hidden arguments.

The uploads were made using your system, with "Add Files." I just clicked "Add Files" now and it lists the directory as "VB.NET Fortran x64", and states there are two files in it. The two zip files are: one for Fortran code, other for VB.NET code. Are you able to access these files?

VB-DotNETSample.zip, loads with MS VS 2008

SampleFortranDLL.zip, loads with MS VS 2005 only. Warning: writes a txt file on the root of C: drive.

Both zips contain all project files.

Has anyone else tried running a x64 application in a Fortran DLL compiled in MS VS 2005 through a VB.NET calling application with MS VS 2008 & .NET Framework v3.5?

Further information: we have compiled the DLL in PGI Fortran demo compiler for x64 and achieve output identical to the DLL compiled in Intel Fortran, with identical (but wrong) output.

There must be an absolutely ridiculous reason for this. Else everyone who uses x64 applications would be unable to run it with an x64 VB.NET application, and your board would be full of complaints.

Thanks,

John

[John_P_1]

We have had no response on premier support or on this forum. Appears no one uses x64 VB.NET with Fortran x64.

It has been over one week without a whisper from premier support. Do any of you guys have an idea?

[Steven_L_Intel1]

I'll check into it.

[John_P_1]

The issue is resolved! I want to share the solution so that anyone else who develops a Fortran DLL for a VB.NET application in 64 bits on a 64 bit env can benefit from it:

Ron Green and his team at Intel Premier Support confirmed that this is not a Fortran issue. I quote: "Rather, [the problem develops from] the odd handling of array arguments by VB."

Ron writes:

"The key was the rather bizarre and un-intuitive decl' in the VB:

Private Declare Sub FortranDLL Lib "FCALL.dll" Alias "FORTRANDLL" (<[In](), Out()> ByVal Array1() As Int32, ByRef Foo As Int32)

and then just passing the array without the (0) index (which apparently is a fluke that it worked at all)

FortranDLL(Test, Test.Length)

I've convinced myself now that this is not a Fortran issue. Rather, the odd handling of array arguments by VB. I would recommend testing this in both IA32 and x86 to insure it works. Then I would research this whole issue of passing arrays from VB to unmanaged code. IF this syntax works for both 32 and 64 bit envs, I would surely recommend recoding this way for all calls to unmanaged code."

End of quote.

His solution works for both IA32 and x64 envs.

In our sample code, Test is an array of integers and Test.Length is the number of entries. We tested both 4 byte and 8 byte integers in the interface and both work on IA32 and x64 envs.

Thanks Intel Premier Support. Intel recommends MS VS with the Intel Fortran compiler, so the issue had to be resolved by Intel, and it was.

[Ismail_Alkan]

I am having trouble with VB.NET to Fortran which is along the same lines.

My case is a much simpler case I believe.
I have VB2012 subroutine calls to Fortran using "ByVal xx As Single" and this works perfectly under 32-bit of VB and Fortran.
But if I switch to 64-bit VB and 64-bit Fortran, the functions and the subroutines that have "ByVal xx As Single" arguments all fail, but there's no problem with "ByVal xx As Double" type arguments.

I submitted a support ticket on this and Premier Support is still investigating it. They told me that there's an issue related with how VB2012 talks to Fortran under 64-bit. They suggested adding a dummy argument after the first argument but that doesn't seem to work.

Does anyone have a suggestion on a solution or workaround for this?
Perhaps a compiler switch can take care of this?
Unfortunately I have many subroutines using the Single type variables, and changing them will take a very long time.

Thanks,

Ismail

[Steven_L_Intel1]

I want to make the observation that Intel Premier Support isn't the right place to ask "how to" questions - this forum is. This is even more true when asking about interfacing to other languages. If something is part of the Intel Visual Fortran product and it isn't working right, then by all means use Intel Support. But we don't have the resources to help with programming advice and to chase down issues with other companies' products.