Calling Fortran Dynamic Library for a VB 6.0 application

[darkos]

Normal 0 false false false MicrosoftInternetExplorer4 st1:*{behavior:url(#ieooui) } /* Style Definitions */ table.MsoNormalTable {mso-style-name:"Table Normal"; mso-tstyle-rowband-size:0; mso-tstyle-colband-size:0; mso-style-noshow:yes; mso-style-parent:""; mso-padding-alt:0in 5.4pt 0in 5.4pt; mso-para-margin:0in; mso-para-margin-bottom:.0001pt; mso-pagination:widow-orphan; font-size:10.0pt; font-family:"Times New Roman"; mso-ansi-language:#0400; mso-fareast-language:#0400; mso-bidi-language:#0400;}

Greetings all,

I have a problem running a Fortran DLL (Built in Intel VF 2008) from a VB 6.0 application under Vista. When the Fortran DLL was built in Compaq VF 6.0 the application run fine under Windows XP, but it did not run in Vista and that is why we moved to Intel Visual Fortran. Now I get the following error message:

Forrtl: severe (28): CLOSE error, unit 47, file Unknown

Image PC Routine Line Source

Libifcoremd.dll 03DF3E5E Unknown Unknown Unknown

Any suggestions?

Thank you,

Darko

[Steven_L_Intel1]

Without seeing the application sources it's very difficult to tell. Did you add STDCALL and REFERENCE attributes to the VB-called routines or build with the /iface:cvf option? (The latter is default if you used the "Extract Compaq Visual Fortran Project Items" wizard.

[darkos]

Hi Steve,

Thank you for responding so promptly. I was able to find that paper regarding the transition to IVF from CVF. I did try the /ifort:cvf without success (still getting the same error). I also changed some of my routines so they do not include the suffix @#, but this did not work too, since now the VB application is not seeing the routines at all. The code is FORTRAN with C wrapper that handles all calls from and to the VB application interface. Does this rule for removing the suffix @# only apply to IVF routines or also to C routines?

Thank you,
Darko

[tenuti]

I have basically the same issue:

Our Visual Basic executable invokes a long sequence of Fortran DLL's

The calling conventions seem to be right, otherwise they wouldn't run on a large installation base (maybe 3,000 customer installations) since 2006

Sometimes we have the same crash noticed by darko:

Forrtl: severe (28): CLOSE error, unit 234, file Unknown

Error in LIBIFCOREMD.DLL. The unit number tends to be the same for half an hour or more, but it changes from day to day.We haven't understood yet the cause:

- it could be the Kaspersky antivirus

- it could be a particular Microsoft Runtime Library we link statically

- it could be some other Microsoft debugging information tool

The bug appears several times on our developer machines and sporadically on some customer machine, who could have installed some Microsoft development tool.

[Steven_L_Intel1]

It could be data corruption. I assume your code does not open unit 234? Which compiler version are you using? We did have an issue some time back where the run-time library's exit handler was being invoked after a DLL was unloaded.