Delphi calling fortran, now in its own DLL

For many years we have had no problem with calling our fortran subroutines and functions. We have had no problem calling external functions from DLLs be they written in fortran or Delphi etc.

Now, the roles have been reversed and the main app is Delphi which needs to call the fortran routines via a DLL. This we have created and the Clearwin+ dialogs, for example, are created fine. The majority of the fortran code still works - it would be a nightmare to consider re-writing it - but the odd routines crash the program. Why ?

The fortran LINKER had used to produce dozens of warnings about the sizing of COMMON areas. This was never a problem when the program was driven by fortran, but is it a problem now that the fortran is a DLL ? I have spent a few hours aligning all the 'offending' COMMON areas ....but still, certain routine calls from the DLL crash the program.

In more detail : Delphi calls a controlling fortran routine which then decides which SUBROUTINE to then call. There is no issue with calling this initial controlling routine. It is thereafter, further down the chain of routine calls within the fortran environment that crashes. Routines that have previously been called and processed fine, suddenly are not able to be accessed.

Paul, et al, do any of you have experience of this problem ? Thanks in advance.

Steve

Sorry. I don't have anything useful to contribute to this.

Try mask_underflow@ at the beginning of Fortran code

Steve:

do any of you have experience of this problem ? With that approach, your odds of finding a solution may be very slim. Instead, follow a divide and conquer strategy.

Since few of the members of this forum probably use Delphi, the thing to do is to write a replacement for the Delphi driver. Do it in Fortran, and make it call the Fortran DLL in a way that is as close as possible to how you expect the Delphi driver to call the DLL. Other than calling the DLL, the driver need not have any other capability, no GUI routines, no network access, etc.

Once you get this working, you can turn your attention the Delphi part, and investigate whether or not it is passing arguments to the DLL in compliance with the expected ABI. When the demarcation of responsibility is clearly defined, debugging the pieces is easier.

Please delete this post.

Please delete.

Please delete.

Sorry for the multiple posts. I received a PhP error, along with a suggestion to retry, which I followed.

'Ran into problems sending Mail. Response: 421 Server is busy, try again later.

DEBUG MODE

Line : 124 File : smtp.php'

Administrator: please remove all but one copy. Thanks.

Is there not a button that deletes your own posts? I have one and I do not have administrator access to the forum.

There is no delete button, not even a grayed-out, inactive one.

The administrator may need to give specific users delete permission in their profiles, but this is just a guess.

For me the delete button is an x next to an button with 'edit' on it but it looks like it does not stay there for long.

I do see the button with 'Edit' on it and to the left of the word a small icon of scissors cutting paper. When I hover the mouse over the button a small pop-up shows 'Delete/Edit', but clicking on the button opens up the editing page with no place to specify 'delete'.

Thanks for your comments.

Turns out that stack overflow was happening and to overcome problem it was necessary to make local variables static. Delphi must have a lower stack size than the default Salford environment.

Incidentally, when using a LNK script file, is there any way to inform SLINK an increased stack size ? Using the 'stack' option keeps returning an error message.

See the help file ftn95.chm at Win32 platform->Using the linker->Reference->Interactive mode....

stack reserve [,commit]