I have a copy of the executable and source code of an old program. The EXE file does not run. It gives an error message that the "entry point" cannot be found in the dynamic link library. When I try to compile on CVF the source code I keep getting errors related to the intrinsic data types. I have used the simple tools my compiler provides for enabling FORTRAN 66 Semantics but it does not work. Does anyone have any tips on what else I can do to make this work? Thanks, Deb75
I doubt there's anything about f66 code in general which would cause such a problem. It may take more specifics for people to help; which compiler, what compile commands, and specifically what error message came up. When there are problems due to old source, it's not likely to be f66 compliant code, but something which happened to work on some particular implementation.
If you have a current version (6.6) of CVF, send us the source in a ZIP file to firstname.lastname@example.org and we'll take a look. Your description of the problem doesn't ring a bell for me - as Tim says, we need more info. Feel free to also include the EXE in the ZIP file.
Hi; My compiler is Compact Visual Fortran 6.6. The Compiler Option I used is "Enable Fortran-66 Semantics" on the Project-Settings-Fortran-Fortran Language dialog box. When I try to run the executable it gives the following error message: "Entry Point not found"-"The procedure entry point RtAllocateHeap could not be located in the dynamic link library ntdll.dll". Since it did not run I tried to compile the source code. It did not compile since several errors showed up. Most of them are related with intrinsic data types that apparently are not the same. That's when I tried unsuccesfuly to alter the project settings to make the compiler understand the old code. Thanks for your interest and help, Debbie
First, the EXE. This program was built with Microsoft Fortran PowerStation 1.0, a 16-bit DOS product. It apparently makes references to system DLL entry points no longer supported by current versions of Windows. So rebuilding will be the answer.
The program is not Fortran 66, in that it has uses of the CHARACTER datatype and character concatenation. But it isn't Fortran 77 either, because it makes some rather peculiar assumptions about mixing of data types, such as trying to concatenate a character with a real. MS Fortran had this bad habit of allowing "free" conversion of numeric datatypes to character in such contexts - CVF doesn't. There is an array of values initialized with character literals in a DATA statement - if you declare that array as CHARACTER*4, that particular error should go away.
The majority of problems are with mixing integer and real datatypes in calls to the MIN and MAX intrinsic. The source doesn't declare most of its variables, relying on implicit typing. But it would not astonish me if MS Fortran allowed mixing types here as well. You'll need to make sure the types are consistent - perhps using REAL(int-variable) to convert the integers to real in these contexts will work for you.
The two remaining problems I saw were the use of a $DEBUG directive (which CVF warns about and then ignores - just remove this) and an extra comma at the end of a FORMAT (remove it).