Attaching Fortran dll to a Visual Basic Program

[Groundsel]

I have written a small visual basic utility which references a single Fortran subroutine.  The visual basic program and the Fortran subroutines live in separate projects within a single solution.  Both projects were created from scratch and the !$DEC DLLEXPORT command in the latter were accepted as supplied by the compiler interface. The Visual Basic program is given the Fortran project as a Dependency.  And a suitable declaration was included in the Visual Basic program to the Fortran subroutine.  Everything builds OK but dies in run-time. In my first attempt, I simply placed the Fortran dll in the same folder as the VB executable.

So I tried to make the Fortran dll a reference of the VB project..  The system rejected that attempt to Add it to the references.  The attached message appeared.  What kind of errors (of omission?) on my part could give rise to this error?

[Steven_L_Intel1]

Placing the DLL in the VB project doesn't do anything useful. The DLL gets loaded from wherever is specified in the "Lib" attribute when you declare the routine. You can't make it a reference either.

There are a few things to do to get this to work. You can refer to the VBCallsFortran sample we provide.

1. The Fortran routine must have the STDCALL attribute and an ALIAS attribute that gives the name exactly as it is spelled in VB, including case.

2. If you are on a 64-bit system, your VB.NET project, the Platform should be set to x86 or x64 to match the platform for the DLL, not "Any CPU".

3. The system you run the program on must have the Intel Fortran redistributable DLLs installed (they will be if the compiler is installed.)

[Groundsel]

I have been unable to locate your example VBCallsFortran.  Other threads seem to suggest it should be somewhere under C:\Program_Files(X86) but I don't seem to have it there.  Is there a web site location for it?

[Steven_L_Intel1]

It is in C:\Program Files (x86)\IntelSWTools\samples_2016\en\compiler_f\psxe\MixedLanguage.zip

[Groundsel]

I was afraid you would say that.  For some reason, I don't have it.  Would you be good enough to attach the zip to an e-mail to me.  I am not an unlicensed user but the installation package as used on our local network must have eliminated these examples.  My effort right now seems to be challenged by passing VB strings to character variables in the Fortran subroutine.  My interactive debug shows only the first character being passed.

I have done another (much simpler with one real argument) example in days past.  This one has 10 arguments 4 of which are strings.  I hope your example includes this detail.

[Steven_L_Intel1]

Here it is. In the future we'll have all the samples online.

[Groundsel]

Thanks, Steve

[FortranFan]

Steve Lionel (Intel) wrote:

.. There are a few things to do to get this to work. You can refer to the VBCallsFortran sample we provide.

1. The Fortran routine must have the STDCALL attribute and an ALIAS attribute that gives the name exactly as it is spelled in VB, including case.

2. If you are on a 64-bit system, your VB.NET project, the Platform should be set to x86 or x64 to match the platform for the DLL, not "Any CPU". .. 

Steve,

With threads such as https://software.intel.com/en-us/forums/intel-visual-fortran-compiler-for-windows/topic/509148 and https://software.intel.com/en-us/forums/intel-visual-fortran-compiler-for-windows/topic/624833 in mind, particularly Message #2 in the first and Message #8 in the second, another view on this matter of "Visual Basic calling Fortran" can be that

      ** the Fortran code can be standard with little to no need of employing STDCALL or ALIAS attributes or Intel-specific modules, etc. **

That is, all the Windows-specific stuff on calling conventions, etc. can be moved to Microsoft-arena, meaning to the .NET (Visual Basic or C#) side; after all, C# and Visual Basic can be viewed more as Microsoft products and less as open, ISO-type of standard programming languages.

Is this something Intel would find contrary to its business directives or opposite to what customers would want or find easy to use?  Is that why such an option is not being brought to the attention of users, meaning no such case being included in the samples?

@Groundsel,

Does having standard Fortran code hold any value or appeal for you?  As you may know, that would mean no statements such as "USE IFCOM" in your code since IFCOM is an Intel-specific solution.  It would also mean no errors or warnings from your code if /warn:stderrors compiler option is used which should lead to code that is portable across compilers and platforms.  Now it would entail learning and making use of Fortran standard features toward interoperability in C.  

[Steven_L_Intel1]

The mixed-language samples are moving to using the C interoperability features where it makes sense. You can't do away with STDCALL when dealing with VB, and you might be dealing with non-C-interoperable types or structures. I am on record as recommending use of standard syntax wherever feasible. Sometimes I don't suggest it because it requires more changes to the source than I want to get into in a reply. Also I often don't know what the rest of the code looks like so it may not be applicable to use the standard syntax.

[Groundsel]

Thanks for the example, Steve.  It was exactly what I needed to make this fly.  All is well now.

Cheers!
Tom

[Gerrit_V_1]

I have a related problem:

working on porting a rather large program from VB6 to VB.net (Version 2013) with intel Fortran, version XE 2013 sp1 . The UI is ok and with an other less big program it all went more or less smooth. So far, so good, but when I tried to send more than one filename to the dll for reading and writing some data, the first filename comes through correctly, but the next is rubbish. So, I started with a small demo, zip file attached, that gives the same problem. Any suggestion where/what is wrong with my code?

Any help or suggestion is highly appreciated.

Regards,

Gerrit Verboom

[Steven_L_Intel1]

Your VB code is passing the string lengths after each string address, but the Fortran code is not expecting any lengths due to the REFERENCE attribute (and if it was, they would be looked for at the end of the argument list). The Fortran code might have worked with CVF which had different conventions.

Either don't pass the lengths from VB or add explicit arguments to accept them.

[Vitaliy_C_]

In my case I've got IVF(10.1.011) DLL and VS2013 code that compiles and works properly. But when I try to run it on another computer it stops with an error. As I understand it misses libraries distributing with IVF. But I don’t know what they are exactly. Can anybody help me to find and register them. 

[Steve_Lionel]

• What do I need to deploy my Fortran application on a system where the compiler is not installed?

[Groundsel]

It has been a while since this came up.  What I recall is that the example Steve gave me was all I needed to get this working.  

[Steve_Lionel]

Just make sure that you build your DLL as a Release configuration and not Debug. You might also have to install the Microsoft Visual C++ Redistributables for the VS version you used to build the DLL.

[Vitaliy_C_]

Steve, thank you very much for this link. I loaded libraries for Compiler Pro 11.1 (intel-64). Now everything works fine!