Hello,
I have binary files generated by Delphi application, and have the VB code to read it. Since Fortran's binary format is different, I think of making the DLL in VB and use in Fortran. So, I would like to knowwhether CVF/ifort have options to use VB generated DLL or not.
Thanks,
Mohan
I have binary files generated by Delphi application, and have the VB code to read it. Since Fortran's binary format is different, I think of making the DLL in VB and use in Fortran. So, I would like to knowwhether CVF/ifort have options to use VB generated DLL or not.
Thanks,
Mohan
連結已複製
7 回應
Almost certainly one can use the DLL, but how difficult it would be depends on what kind of DLL it is. If it's a native (non-managed DLL), it's fairly easy. If it's a managed DLL, then one would use the Fortran Module Wizard tool to create interfaces to the DLL routines.
Can you attach a sample DLL here so I can take a look? It would help if you gave me the Delphi or VB declaration of the routine with its arguments and types of arguments.
Can you attach a sample DLL here so I can take a look? It would help if you gave me the Delphi or VB declaration of the routine with its arguments and types of arguments.
CanI suggest that you use a VB application to call your DLL and then pass the data as required to a Fortran DLL, a lot easier and the code exists in the samples. Uisng the Fortran Wizard can waste a lot of time and not end up with a usable product.
Managed DLL's are not a great problem, if yours is non managed you can make it managed using a simple trick from Microsoft - create small small managed app then add your dll to the small one and it will make it managed and then just register it.
JMN
[bash]cd B:UsersJohnDocumentsVisual Studio 2010ProjectsbManagedDLLbManagedDLLbinDebug RegAsm.exe bManagedDLL.dll /tlb:bManagedDLL.tlb /codebase copy "*.tlb" "B:UsersJohnDocumentsVisual Studio 2010ProjectsCPPClientCPPClient*.tlb" erase *.txt cd pause
[/bash]
Managed DLL's are not a great problem, if yours is non managed you can make it managed using a simple trick from Microsoft - create small small managed app then add your dll to the small one and it will make it managed and then just register it.
JMN
[bash]cd B:UsersJohnDocumentsVisual Studio 2010ProjectsbManagedDLLbManagedDLLbinDebug RegAsm.exe bManagedDLL.dll /tlb:bManagedDLL.tlb /codebase copy "*.tlb" "B:UsersJohnDocumentsVisual Studio 2010ProjectsCPPClientCPPClient*.tlb" erase *.txt cd pause
[/bash]
Hi Steve,
Initially I created the DLL with vb6 (unmanaged), but then I thought it would be good idea to start a test problem. Following are the codes. I created "Test_Add.dll" from VB and attached to CVF through Project -> Add to Project -> Files
VB code:
Public
Public Function test_add(ByVal a1 As Integer, ByVal a2 As Integer) As Integer
test_add = a1 + a2
End Function
End
Class
CVF 6.6 code:
Program Test
!IMPLICIT NONE
!DEC$ ATTRIBUTES DLLIMPORT :: test_add
!DEC$ ATTRIBUTES STDCALL :: test_add
!DEC$ ATTRIBUTES ALIAS:'_TEST_ADD@8':: test_add
INTEGER :: i1,i2,i3
WRITE(*,*) 'Enter two integers'
READ(*,*) i1,i2
i3=test_add(i1,i2)
write(*,*) i3
End Program Test
CVF Error:
Compiling Fortran...
..\Test\Test.f90
Linking...
Test.obj : error LNK2001: unresolved external symbol _TEST_ADD@8
Debug/Test.exe : fatal error LNK1120: 1 unresolved externals
Error executing link.exe.
Test.exe - 2 error(s), 0 warning(s)
Oh, you're using CVF...
There are two problems you have. The first is that the name of the routine in VB is 'test_add', not '_TEST_ADD@8'. Yes, the latter would be what CVF would use for a Fortran routine, but VB does things its own way. The second problem is that you don't have an export library to link against - you can't link to a DLL. So instead you could use the Win32 API routines LoadLibrary and GetProcAddress to call the routine. If I recall correctly, CVF has a DLL\LoadLibrary sample illustrating how this is done.
There are two problems you have. The first is that the name of the routine in VB is 'test_add', not '_TEST_ADD@8'. Yes, the latter would be what CVF would use for a Fortran routine, but VB does things its own way. The second problem is that you don't have an export library to link against - you can't link to a DLL. So instead you could use the Win32 API routines LoadLibrary and GetProcAddress to call the routine. If I recall correctly, CVF has a DLL\LoadLibrary sample illustrating how this is done.
Steve,
I would also like to call a vb.net managed dll from Intel Fortran. I made the dll "COM visible" and used the Module Wizzard based on the steps mentioned here: http://software.intel.com/en-us/forums/showpost.php?p=135683
Then performed the REGASM step.
In my Fortran program I imported the module with a use statement.
Is this all I need to do to acess the DLL? Or do I need to reference something in the Project's linker settings?
With the following code I get the following error message Unhandled exception at 0x00000000 in TestNetDll.exe: 0xC0000005: Access violation.
[fortran]program TestNetDll use BDataObj implicit none ! Variables integer(4) :: func4 ! Body of TestNetDll func4 = AnInterface_ClearKeyBuffer(NULL) end program TestNetDll[/fortran]
I would also like to call a vb.net managed dll from Intel Fortran. I made the dll "COM visible" and used the Module Wizzard based on the steps mentioned here: http://software.intel.com/en-us/forums/showpost.php?p=135683
Then performed the REGASM step.
In my Fortran program I imported the module with a use statement.
Is this all I need to do to acess the DLL? Or do I need to reference something in the Project's linker settings?
With the following code I get the following error message Unhandled exception at 0x00000000 in TestNetDll.exe: 0xC0000005: Access violation.
[fortran]program TestNetDll use BDataObj implicit none ! Variables integer(4) :: func4 ! Body of TestNetDll func4 = AnInterface_ClearKeyBuffer(NULL) end program TestNetDll[/fortran]
Typically you at least need to call COMINITIALIZE first. But without seeing all of what you're doing, I couldn't begin to guess where the problem might be. I assume that AnInterface_ClearKeyBuffer is a routine generated by the module wizard. You could step into it in the debugger and see how far you get before the error. I am not sure what NULL is here in this context, or how it is interpreted by the routine you call.
