Run-time error '453', need help

Run-time error '453', need help

I am trying to create an VB6 GUI for my fortran code. I used Microsoft powerstation4 to create the Dll file. but there is always an error message comes out:
Run-time error '453'
can't find Dll entry point PassStrToFortran in fordll32.dll

And I tried an correct sample fortran file which has it's own dll file, it works well with it's own dll file. but when I tried to use the dll file created by Microsoft powerstation4, the same error comes out.
I am just concerning whether it is because of the fortran version. should I use CVF other than Microsoft powerstation4. need help to figure it out. thank a lot.

here is the sample fortran file:
! Written by Eric Niblack

! This demonstrates passing various type to Fortran DLL functions.
! More importantly, it shows how to pass fixed length ANSI strings,
! which is the only way older Fortran DLL code could do it.
! To operate on variable length strings, you must use
! the OLE Automation APIs as described in VB4DLL.TXT using C language.
! The VB4DLL.TXT file ships with the VB 4.0 product.
! Due to an architecture change in VB 4.0 32/16, it is different
! than VB 3.0 in that strings are stored in OLE BSTR and Safe Array
! formats. Consequently, the functions below need to be typed
! this way to interface properly. The most dramatic change is in
! the conversion done in Basic before and after the function call
! into the DLL passing arrays of strings.
! See below the code for more helpful information.
! See notes for Powerstation 1.0 NT users below.

! Also demonstrated are the three general methods of exporting
! the functions so that VB can call them. Notice that the 3
! string functions are seen in the ForDLL32.DEF file. Second, the
! long and real array functions are resolved using an "Alias" part
! in the "Declare" statements on the VB side. Finally, the mixed
! type function is resolved using a local Fortran ALIAS attribute.
! You may use the "DUMPBIN /EXPORTS FORTDLL32.DLL" command line utility
! to see the resulting symbols.
! The DEF file or Fortran ALIAS are the prefered methods.

Subroutine PassLongArrToFortran(Arr)
Integer(4) Arr(3,7)
Integer i, j
Do i = 1,3
Do j = 1,7
Arr(i,j) = 25*i+j
End do
End do
End subroutine

Subroutine PassDblArrToFortran(Arr)
Real(8) Arr(3,7)
Integer i, j
Do i = 1,3
Do j = 1,7
Arr(i,j) = 20.0D00*i + 0.1D00*j
End do
End do
End subroutine

Subroutine PassStrToFortran(Str)
Character(24) Str
! 0 1 2
! 123456789 123456789 123"
End subroutine

Subroutine PassStrArrToFortran(Str)
Character(24) Str(5)
Str = "012345678901234567890123"
End subroutine

Subroutine PassStr2DArrToFortran(Str)
Character(24) Str(5,2)
Str = "012345678901234567890123"
End subroutin

Subroutine PassEachArrToFortran(LongArr,RealArr,Str)
!MS$ ATTRIBUTES ALIAS:'_PassEachArrToFortran':: PassEachArrToFortran
Integer(4) LongArr(5)
Real(8) RealArr(5)
Character(24) Str(5)
Integer i
Do i = 1,5
LongArr(i) = 20*i
RealArr(i) = 25.1D00*i
End do
Str = "012345678901234567890123"
End subroutine

! The numeric data types here are designed to the largest sizes. If you
! need a different size, choose accordingly:
! Integers:
! | | Data Type |
! | Bit | VB | Fortran |
! |-----|---------|------------|
! | 16 | Integer | INTEGER(2) |
! | 16 | Long | INTEGER(4) |
! | 32 | Integer | INTEGER(2) |
! | 32 | Long | INTEGER(4) |
! Real:
! | | Data Type |
! | Bit | VB | Fortran |
! |-----|---------|----------|
! | 16 | Single | REAL(4) |
! | 16 | Double | REAL(8) |
! | 32 | Single | REAL(4) |
! | 32 | Double | REAL(8) |
! STDCALL is not needed for all of these. The default calling convention
! in Fortran is very similar. For consistency, it is always used.
! Note that the string routines are only for use with fixed length strings.
! If you need to operate on variable length strings, you will need
! to use C language.
! See Chapter 22 in Programmer's Guide
! Notes for Powerstation 1.0 NT users:
! Why is this written in Fortran 90? It is more portable than
! Fortran 77 with MS specific keywords. Luckily, converting
! isn't a big deal.
! Look at the ForDLL16.for source file, since it is
! using the correct syntax except without any of
! the attributes.
! Given this subroutine:
! Subroutine PassStrArrToFortran(Str)
! Character(24) Str(5)
! Str = "012345678901234567890123"
! End subroutine
! becomes:
! Subroutine PassStrArrToFortran[DLLEXPORT,STDCALL](Str)
! Character*24 Str[REFERENCE](5)
! Str = "012345678901234567890123"
! End
! Some guidelines for converting 90 to 77 format are:
! 1) Indent so the code begins in column 7
! 2) Move the information to the right of ATTRIBUTES to
! square braces AFTER the routine name and BEFORE the
! open parentheses for the parameter list.
! 3) Move the parameter variable attributes, if any, to square braces
! immediately AFTER the variable name and BEFORE any dimension
! list.
! 4) Note that in PS 1.0, all STDCALL routines pass non-string parameters
! by VALUE, which is not the case in PS 4.0. As such, all data to be
! passed by reference must be marked as REFERENCE similar to the above
! example.
! 5) Use the older Fortran sizing syntax using '*' and not parentheses.
! 6) End the subroutine/function with END only without SUBROUTINE, etc.
! 7) Save in a .FOR file
! Some other minor syntax changes may be required.

7 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

Try to change "!MS$" everywhere in the code to "!DEC$".


CVF supports the !MS$ syntax, but try removing the space - MS spelled it as !MS$ATTRIBUTES.


Retired 12/31/2016

first, thank you all for the good advice. I have tried it, and seems the space isn't the key of the problem. But I noticed that when I tried the sample file above again, these three Subroutines, PassStrToFortran(Str),PassStrArrToFortran(Str) and PassStr2DArrToFortran(Str) ,which all relate to strings, still have same problem. And the other three work well. is there any thing should be concerned about strings when you convert fortran subroutin to Dll.

I am really desperated now, cause I have a long fortran program waiting for me. and it is only so simple a example. need help...

I've never used Microsoft's PowerStation FORTRAN, so I don't know how it works. Also, it's unclear to me whether you're having problems passing strings when Fortran routines call your DLL or when your VB GUI calls it.

If you were using Visual Fortran, then you shouldn't have any problem with Fortran routines calling your DLL. The normal Fortran calling conventions would be in effect and understood by both the callers and the callees (in your DLL).

If you're having problems with VB calling calling your DLL, it's probably because you're passing arrays of fixed length strings rather than single fixed length strings. I believe that there's a special structure you have to use when passing arrays of strings, both fixed and variable length. Fortran strings have a hidden length that is passed together with the string data itself, and this can cause problems if not properly handled.

Visual Fortran comes with example programs that demonstrate how to pass arrays of strings and variable length strings.


You should also look at Visual Fortran's on-line help for "mixed-language programming" under the "Strings" topic as well as in the book _Digital Visual Fortran Programmer's Guide_.


Ihere, I could reproduce Run-time error '453' with an own mixed VB-CVF program (DLL). If you click on the Help button in the same dialog box where you get this error message, you can read the following in the VB-Help:

"The dynamic-link library (DLL) in a user library reference was found, but the DLL function specified wasn't found within the DLL. This error has the following causes and solutions:

- You specified an invalid ordinal in the function declaration.
Check for the proper ordinal or call the function by name.

- You gave the right DLL name, but it isn't the version that contains the specified function.
You may have the correct version on your machine, but if the directory containing the wrong version precedes the directory containing the correct one in your path, the wrong DLL is accessed. Check your machine for different versions. If you have an early version, contact the supplier for a later version.

- If you are working on a 32-bit Microsoft Windows platform, both the DLL name and alias (if used) must be correct.
Make sure the DLL name and alias are correct.

- Some 32-bit DLLs contain functions with slightly different versions to accommodate both Unicode and ANSI strings. An "A" at the end of the function name specifies the ANSI version. A "W" at the end of the function name specifies the Unicode version.
If the function takes string-type arguments, try appending an "A" to the function name."

In my case it was a differens between the declaration of the DLL function name in VB and the exported name and alias from CVF DLL: I had mixed upper and lower case in VB, and only upper case in DLL's exported name and alias.


Leave a Comment

Please sign in to add a comment. Not a member? Join today