CVF dll from VB - out of stack space

[pavery]

I am converting a dll used by Visual Basic 6 from Powerstation FORTRAN to CVF 6.6. After fixing the comment lines, the dll compiled & linked ok. But when I make the first function call in VB I get "Out of stack space". I used dumpbin and it looks like all the procs/funcs are there. The old dll works fine. I have not programmed in FTN for several years and can't help but think that I am probably missing something simple (I hope). I did set the /stack:0x80000000 but it did not help. Any ideas?

Thanks alot!

Patty

[Steven_L_Intel1]

Unfortunately, there is nothing you can do to the DLL to change the stack allocation - you'd have to edit VB.EXE itself. Look for use of "automatic arrays", where you declare a local array using a passed-in size, and change them to use ALLOCATABLE (and then ALLOCATE them). For example, if you have:

subroutine sub (n)
real array(n)

change this to:

subroutine sub (n)
real, allocatable :: array(:)
...
allocate (array(n))

No need to deallocate - it will be done automatically on routine exit.

Steve

[pavery]

Steve,

I looked at the code and there are 50+ of these automatic arrays. The problem is the VB program is getting the error immediately when it references the first function. I decided to change the way the first function is exported and it worked. Now I have another problem/question - the Powerstation code used this type of method to export funcs/subs:

FUNCTION ABC_EXP [DLLEXPORT, ALIAS:"ABC"] (A,I)
ABC_EXP = ABC(A,I)
RETURN
END
....
FUNCTION ABC (A,I)
....
ABC = ...
RETURN
END

When the exports are done this way, they show up using dumpbin but VB chokes on the first call. If I remove the ABC_EXP function and use -
!DEC$ ATTRIBUTES ALIAS : "ABC" :: ABC
!DEC$ ATTRIBUTES DLLEXPORT::ABC
in function ABC, the VB call works.

I guess the original coders used the two function method because they also use many of the funcs/subs within the FORTRAN dll code itself. I guess my question now is why isn't this old method working with CVF? Also, if it is not possible to make it work - how can I make these functions available within the dll itself as well as being exported?

After that... then I get to work on the arrays...

Thanks again.

Patty

[Steven_L_Intel1]

I don't understand what you changed nor what is meant by "VB choked", so it's hard for me to comment.

VB uses the external name exactly as you specify it in the declaration, whereas CVF uses the normal STDCALL "decoration" of routine names. That's what the ALIAS takes care of.

The method the code used with PowerStation should still work - if it doesn't, write to vf-support@compaq.com with an example. Otherwise, you would need to add the ALIAS directive in any Fortran routine that called ABC.

Steve

[pavery]

You are right, the code use by the Powerstation program:
FUNCTION ABC_EXP [DLLEXPORT, ALIAS:"ABC"] (A,I)
does work with CVF, however, only when the alias is changed to lower case:
FUNCTION ABC_EXP [DLLEXPORT, ALIAS:"abc"] (A,I)
and the references in VB also changed to lower case.

If uppercase is used, I still get an "out of stack space" error on the first function call.

As I said before, the old Powerstation dll works as is - all upper case. This may be a VB issue but I don't see how since the old dll works fine. Looking at both dlls (Powerstation & CVF) with dumpbin the exports look ok in upper case. I can change all of the VB calls & CVF alias's to lower case and it does work but unfortunately it has caused many other side effects in the programs. Do you have any other recommendations?

Thank you.

[Steven_L_Intel1]

Send a small example to vf-support@compaq.com (include the VB and Fortran code) and we'll take a look. I don't see why the case of the name should matter.

Steve

[Steven_L_Intel1]

Patty,

Thanks for sending the program. I took a look at it shortly before I left work today, and I see what is happening. Basically, the call to ABC in ABC_EXP is calling ABC_EXP recursively, because you exported the global name to be ABC, the same as the real ABC. That call in turn calls ABC_EXP, and so on and so on until you exhaust the stack.

Changing the alias to lowercase breaks the cycle because the real routine ABC has an uppercase external name.

I have a couple of ideas as to how to get the code to work (without changing your VB code) and want to fully understand what is going on (I know it has something to do with the way we export two names for every subroutine) - I'll write back when I know more.

Steve

[Steven_L_Intel1]

The workaround is to add to ABC_EXP the line:

!DEC$ ATTRIBUTES ALIAS:"_ABC@8" :: ABC

What is happening is that the ALIAS that renames ABC_EXP to "ABC" causes the compiler to treat ABC_EXP as if it were ABC for calls to ABC. I don't think this is right, but to change it would mean a major upheaval for the compiler. Also, the usage is likely to cause problems outside of 32-bit Windows, as you're likely to cause a naming conflict with the real ABC.

Steve