Using a Fortan DLL in VB that has a STOP command

[alanbcole]

I am looking for a suggestion on how to handle the following problem. My dll file is running older Fortran code that on a error goes to an error handling subroutine that uses the STOP function to end the program. This inturn closes my VB application. I would like the VB application to stay open so i can read my error file and report it. Thanks

[Steven_L_Intel1]

There's nothing you can do about this that I can think of (other than to remove the STOP, which doesn't belong in a DLL anyway.)

Steve

[alanbcole]

The reason the stop was there originally(wasn't alway's a DLL)was that the error routine could be call many times when was only needed once. I have found that it could get stuck in a infinite loop. I am stuck as to how to handle this. The original code was purchased code for my company and i was told that i could not change the code itself. Any ideas would be appreciated.

[Steven_L_Intel1]

You have no choice - you have to remove the STOP. There is nothing you can do in the VB code that I know of to prevent the program from exiting.

Steve

[Intel_C_Intel]

You could try wrapping your DLL in some C++ with all calls protected by ter...catch blocks, but I'm not sure even that would work, since the STOP would probably take down your wrapper DLL, which would take down your application. According to the documentation STOP 'terminates program execution' - just like you hit Alt+F4

[david_jones]

"I would like the VB application to stay open so i can read my error file and report it. "

... why not just always start a second application, read the file and report it if there are errors ? (e.g. starting both applications from a batch file) Or write an application which will kick off your VB process, wait for termination, and then read and process any error file.

David Jones

[Intel_C_Intel]

I would change the Fortran code, so that it doesn't change what it is really trying to do when you hit the STOP line. Set up a return flag, and then Return instead of stopping. Essentially ending the processing in the .dll in a graceful way under your control. In effect, doing the same thing this program did before it was a .dll.

When you were told not to change the Fortran code, hopefully this wouldn't be considered a prohibitive change. Unless you are working for a pointy-haired boss, in which case you should spend a lot of money trying to resolve this problem and never quite getting there. After all, you must have had to make similar, non-substantive changes to get this to be a .dll callable from VB.

[gfthomas8]

Agreed. As a curiosity, how typically is a STOP statement implemented in Windows? Given that the Fortran standard is unlikely to even acknowledge Windows, is there any chance that CVF(/IVF) could warn of the presence of a STOP in a DLL? That way the STOP could be replaced by a RaiseException(EXCEPTION_NONCONTINUABLE_EXCEPTION,...), say, which can be handled and logged by the DLL using C++/SEH?

Ciao,
Gerry T.

[Jugoslav_Dujic]

Probably it's just a wrapper around ExitProcess.

[Steven_L_Intel1]

I don't think CVF has any way of knowing the code is in a DLL. I believe ExitProcess is indeed what is used.

Steve

[Intel_C_Intel]

Steve, I thought Gerry meant that if you were compileing a DLL with CVF/IVF, then the compiler could warn you, and suggest (implement?) alternatives...

[Jugoslav_Dujic]

Well, there's _DLL symbol automagically !DEC$DEFINEd for one...

But personally, I don't like the idea; sounds too picky and partial warning to me. It's as if "Warning: don't use POINTER-valued functions because they're prone to memory leaks". There's a thousand things where a careless programmer could err -- I don't think it's 100% compiler's business to spot each and every.

Jugoslav

[Intel_C_Intel]

Jugoslav,

True in the majority of cases, but can you really think of a legit use for STOP in a DLL?

Dan

[Jugoslav_Dujic]

Well, probably no; but, to extend my point, can you think of legit use for:

EXIT()
ExitProcess()
TerminateProcess()
ExitThread()
TerminateThread()
PAUSE
etc.

as well... I assure you I'm able to write more horrid things than calling that from a dll, but I don't expect from the compiler to tell me I'm an idiot :-).

Jugoslav

[gfthomas8]

Alan:

Here's an outline of how to get rid of a STOP in a CVF DLL. It works, but use it at your peril.

The idea is to replace the STOP in your CVF DLL source by a less heavy-handed action that doesn't kill your VB client. You do this, not by changing the DLL source (say the file StopIt.f90 contains the STOP), but rather its corresponding asm (StopIt.asm) which you edit (to get rid of the STOP, replacing it with a RaiseException API call), recompile with ML.EXE (Microsoft assembler 6.11d) and whose output (StopIt.obj without the STOP) you add to your project. Now rebuild your DLL in the usual way and you'll be off to the races, eventually...

Some tips:
-Try this on a test DLL;
-In Settings/Fortran/Listing Files, check asm and source;
-When you have StopIt.asm add it to the project _and_ remove StopIt.f90 since you're done with it and it's unchanged from the original;
-In StopIt.asm, the STOP is _for_stop_core: change it to _RaiseException and stick in a 'use kernel32' if it's not already present. Replace the STOP assembly statements with those appropriate to RaiseException;
-Recompile StopIt.asm using ML from the command line,
eg, ml /c /Cp /coff /Zm StopIt.asm;
-When you've regenerated StopIt.obj (sans STOP), add it to your project. Rebuild your DLL;
-In raising an exception, it falls through the cracks to VB which at least has the Err object, whereas Fortran has nothing other than STOP, for error handling;
-If the exception you raise is not handled by VB's Err object, then make it so via

http://archive.devx.com/premier/mgznarch/vbpj/1999/05may99/bb0599.pdf

-If all this seems daunting, it's not;
-Good luck.

BTW, the only thing worse than a STOP in a CVF DLL (that hasn't allocated a console) is a PAUSE. Try it to test your reflexes (but save your data beforehand).

HTH,
Gerry T.

[Intel_C_Intel]

Gerry...wow! ;o)

Seems like it'd be easier to just edit the code, especially if you have it to hand!

Incidently, can you get at _control87 / _status87 / _clear87 from VB? You could handle just about anything in FORTRAN then (with the right compiler options)

[gfthomas8]

> Seems like it'd be easier to just edit the code,
> especially if you have it to hand!

I agree. But sometimes one has to apply desperate measures. BTW, you can use the same strategy to statically link CVF to VB. See

http://archive.devx.com/upload/free/features/vbpj/1999/11nov99/jc1199/jc1199.asp

>
> Incidently, can you get at _control87 / _status87 /
> _clear87 from VB? You could handle just about
> anything in FORTRAN then (with the right compiler
> options)

I had this in a C/C++ DLL but the code is long frozen and not readily accessible to me. Lately I use CVF to export these functions for VB use and if I get time this week I'll post the details.

Ciao,
Gerry T.

[Intel_C_Intel]

Gerry,

That would be cool. My interest is more from a mixed language point of view though. Our current error handling set-up is something of a bastardisation!

I don't think we have the correct FORTRAN compiler options, because a direct call from C++ can result in an exception that is handled in the C++ layer, but if the FORTRAN nests, or recurses, FP errors aren't thrown back to the C++ properly (i.e. aren't thrown back at all). This often results in Infinities and NaNs propagating around the system, which generally bolloxs everything :)

[gfthomas8]

>
> Incidently, can you get at _control87 / _status87 /
> _clear87 from VB? You could handle just about
> anything in FORTRAN then (with the right compiler
> options)

Dan:

Here's how. Add a MyCVFDLL.def file to your CVF project and in it put:

;DEF file
LIBRARY for MyCVFDLL

EXPORTS
; Function Ordinal
; -------- -------
;F95 exports (list these here)

;C exports
Clearfpu @6
fpClass @7
fpNaN @8
fpFinite @9
Statusfpu @10
SetControlfpu @11
GetControlfpu @12

(Note: the symbol and its ordinal @? are separated by a tab stop).

Add the following .c file to your project:

#include
#include
#include
#include
#ifdef _WIN32
#define CCONV __stdcall
#endif

int CCONV SetControlfpu(unsigned int nu, unsigned int mask)
{
unsigned int j;
// Set fp control word
j= _control87( nu, mask);
return (j);
}

int CCONV GetControlfpu(void)
{
unsigned int j;
// Get current fp control word
j = _control87(0, 0);
return (j);
}

int CCONV Clearfpu(void)
{
unsigned int j;
// Get and clear fp status word
j = _clear87();
return (j);
}

int CCONV Statusfpu(void)
{
unsigned int j;
// Get fp status word
j= _status87();
return (j);
}

int CCONV fpClass(double x)
{
int j;
// Get status word of the fp class of x
j = _fpclass(x);
return (j);
}

int CCONV fpNaN(double x)
{
int j;
// Check if x is NaN - returns >0 if TRUE
j = _isnan(x);
return (j);
}

int CCONV fpFinite(double x)
{
int j;
// Check if x is finite (including zero) - returns >0 if TRUE
j = _finite(x);
return (j);
}
etc, etc,...

Compile the dll and view its dependencies to see the exports. Look in the VC++ docs for usage of these exports from VB.

To use the functions in fortran, supply an interface for for each function: eg,

interface
integer(4) function Clearfp [C, ALIAS:'__clearfp'] ()
end function Clearfp
end interface

integer(4) status

status = Clearfp()

etc.

As far as mixed language exception handling goes, I follow the CVF docs and samples, but I do the error handling in Fortran not C/C++. Works fine.

HTH,
Gerry T.

[billaustralia]

very easily (sorry steve)

replace the stop by
i=0
i=i/0

and put an
on error resume next
before your call to the dll
and test for an integer div by zero after.

Works like charm.

[billaustralia]

and also works in vf debug.
Immediately after the i=i/0 is executed, you are back in the vb or vba.