IVF DLL/VB 6 problem

[dudley_j1]

I have imported a Compaq Visual Fortran 6.1A project into IVF 9.1. This compiles, and produces a DLL. The import routine linked against static libraries, and the VB kept failing - it would call the DLL OK, but on return it reported a 'divide by zero' error as soon as I used a parameter returned from the DLL.

Changing the link library to 'single-threaded DLL' has resulted in small problems running. Large problems still fail with 'divide by zero.'

In CVF this was a sign of a memory over-write in the DLL, but the DLL code is the same as ever - 10 years of happy useage in DVF/CVF.

I have tried increasing the stack & heap commit & reserve, from 0 to 1 million to 10 million, as this solved a similar problem in DVF 5.0. No success here.

Any other suggestions as to what I might investigate? Allocatable arrays still use the old Microsoft Fortran 5.1 notation: real [allocatable] X(), for example. So far DVF/CVF/IVF have not complained about this.

In principle, all I have done has been to follow the procedure to convert a CVF project into IVF, recompile the DLL, and test the new DLL.

My short-term work-around is in the Visual Basic to use 'ON ERROR RESUME NEXT', which seems to be OK - I'd need to do more regression tetsing. But this is rather unsatisfactory.

Message Edited by dudley_j@wrcplc.co.uk1 on 05-17-200605:21 AM

[anthonyrichards]

Could it be a calling convention problem? See a recent thread below for possible solutions.

http://softwareforums.intel.com/ids/board/message?board.id=5&message.id=18043

[dudley_j1]

It isn't the calling convention, as I have two entry points into the DLL. One always works, and determines a calculation sequence. The second then does the calculations, and now works for the smallest possible problem, but fails on a larger problem set typical of what I am trying to do (model water treatment systems).

I did experiment with changing the calling convention, when I got 'Bad DLL calling convention.'

I changed a load of settings, such as setting default SAVE of local variables, when I was getting the DLL to cause the VB program to 'evaporate' - it crashed without any error message, just unloaded by Windows.