Program crash no matter what

I had a program crash and this time, clicking 'Details' actually showed something. Program is too big to post, but thought I could post the crash details. I am stumped. I've snipped the screen shots an put them here. As beast I can tell, it occurs in the SALFLIBC.DLL in a call to the routine named WSF1##. It matters not what code is at line 94. It always crashes right there with an access violation.

Any help or advise on further debugging I should do would be most appreciated. Bill

Just on a lark, I tried something else.

If I remove all of the INTERFACE definitions, it appears to work without error. I will continue with this. I onoly used the INTERFACE definitions as a help to find coding errors that weren't showing up until run-time.

If you are not already doing so then you should use the CHECKMATE option on the FTN95 command line. Also use the debugger SDBG to run programs that fail.

Paul, I've been doing that (Checkmate WIN32). But I'm not finding all the argument type/length mismatches during the compile phase. So I have devolved into a manual matching process. This was more of a heads-up just in case someone else had this class of problem.

And before folks offer extra advice on type/length compatibility, the files used/created by this code have to be compatible with the user's original data, some of which dates back to the mid-1980's. So, before I make the final plunge, I have to absolutely guarantee and test file compatibility which includes binary direct access file where data size/typing matching is paramount.

So, I'm going slow to make sure of full compatibility (even if it means manually slogging through all the files and interfaces and where they are used). I knew the process would be long when I started.

But I'm not finding all the argument type/length mismatches during the compile phase. So I have devolved into a manual matching process. When subprograms and source code files are compiled the compiler cannot check outside the scope of the current source file. In fact, a subroutine developed today may be compiled and added to an object library, which is used years later by someone else. The compiler cannot check against potential mistakes before they are committed!

However, FTN95 excels at finding mismatches at run time. Therefore, the heroic manual matching process is neither necessary nor effective.

[u:ce891a4220]mecej4[/u:ce891a4220]: In those instances of SW debug where there is a file to be read and much processing to occur, then running a file (or files) against the code is a great way to have FTN95 find subtle errors.

mecej4[/u:ce891a4220]**: In those instances of SW debug where there is a file to be read and much processing to occur, then running a file (or files) against the code is a great way to have FTN95 find subtle errors.

[quote:ce891a4220]However, FTN95 excels at finding mismatches at run time. Therefore, the heroic manual matching process is neither necessary nor effective.

What you do not know is this code is manual entry oriented. There is no input file since, for the user, the original records are on paper.

That means that to get to the place where the error occurred may take anywhere between 10 and 500 keystrokes. So, subtle type mismatches that cause a 'crash' are even more labor intensive than you may have imagined.

And changes due to this 'new' compiler add an additional level of complexity. It is a good thing, since a few deeply buried bugs have been uncovered. But getting to the end is, and will continue to be, a long manual process.