NAG DLLs and .NET

There are some fundamental differences between VB6 and the next generation, VB.NET, as they affect interfacing to NAG Fortran routines. In this article, NAG's David Sayers talks about how NAG users will be able to take advantage of NAG library power and functionality with both VB6 and VB.NET.

On their web site Microsoft say of .NET, "So this next generation of distributed computing builds on the current generation. Microsoft .NET isn't a wholesale replacement of software applications as we know it, but rather a natural evolution that will bring the benefits of collaboration and interoperability to the isolated technology islands we now have."

NAG users will naturally ask what changes will be required of their programs to take the first steps in this evolutionary process. This brief article points to some of fundamental differences between VB6 and the next generation of VB, VB.NET as they affect interfacing to NAG Fortran routines.

All of the .NET languages are built upon a common framework. From a VB perspective these have a C-like bias. In particular, arrays are now stored by row rather than by column.For example an array A(1,2) would consist of elements of contiguous storage:

A(0,0),A(1,0),A(0,1),A(1,1),A(0,2),A(1,2) in VB6.

In VB.NET however a similar declaration would produce elements of contiguous storage:

A(0,0),A(0,1),A(0,2),A(1,0),A(1,1),A(1,2).

The VB6 convention was identical to that defined by the Fortran programming language.This made it easy to pass a VB6 array into a NAG Fortran routine. The first element was passed as the array argument. With this and with the information on the number of rows in the array, the Fortran routine could correctly identify the address of each element in the VB array and hence work with the required elements of the VB array.

If we were to pass exactly the same information (i.e. use identical code) under VB.NET then it is evident that the Fortran routine would be misled. In particular when it accessed the second element of the array thinking it were A(1,0) it would in practice be accessing A(0,1).

To counter this the user has to use the transposed array. Let B(2,1) be the transpose of A, such that B(i,j) = A(j,i). Under VB.NET the storage layout is:

B(0,0),B(0,1),B(1,0),B(1,1),B(2,0),B(2,1)

which is correctly interpreted by the Fortran code as

A(0,0),A(1,0),A(0,1),A(1,1),A(0,2),A(1,2).

Thus in VB.NET we have to deal with the transpose arrays rather than the array itself in order to use the Fortran DLLs. The only further point to note is that the "leading dimension" referred to in the Fortran documentation is the number of rows of A, 2, derived from the first dimension of A. In terms of B, it is the number of columns of B.This is derived from the second dimension of B.

Another C-like feature is the compulsory first index of 0. In VB6 it was possible to change this default using the OPTION BASE 1 construct. We recommended this to our users for then the Fortran and VB array indexing were identical. The OPTION BASE construct is not allowed in VB.NET.

Just as the C language passes its parameters by ByVal by default, so does VB.NET. This is in sharp contrast to VB6 which passed ByRef by default. NAG Fortran routines would normally expect to be passed by reference and so it is important to explicitly give the ByRef qualifier in the corresponding 'Declare' statements.

VB6 and VB.NET now have different numbers of bits associated with Integer and Long types.Whereas a Long variable corresponded to the Fortran type INTEGER in VB6, in VB.NET type Integer corresponds to the 32-bit Fortran INTEGER type.

Because of the last two changes NAG distributes two distinct sets of 'Declare statements' with its Mark 20 DLLs: one set is for use with VB6 and VBA, the other with VB.NET.It is hoped that with these NAG users will be able to take advantage of NAG library power and functionality with both VB6 and well into the lifetime of VB.NET.