Re: Look at this before considering to use Intel Visual FORTRAN

From: seti (seti_at_cyberview.com)
Date: 11/21/04 

Date: Sun, 21 Nov 2004 02:02:54 GMT

Juergen wrote:
>
> I am writing code for a commercial package in FORTRAN, which is very
> convenient for complex calculations. I started this work in 1985 and
> DVF made me really happy. User interfaces are for Windows and here
> FORTRAN is definitely not the first choice. So my code is either for a
> standard- or COM-DLL.
>
> I had to move to Intel Visual FORTRAN in a research project and found
> out my DLLs could not be called from MS-Programs like Excel etc.
> anymore (crashes).
>
> I sent a very short example reproducing the problem to IVF Premier
> Support. As a commercial customer, I am used to quick and immediate
> help.
>
> The first technical answer pointing out the cause of the problem
> reached me after MORE THAN 4 MONTHS.
>
> I included the communication below. I believe this information is
> valuable to anybody considering to use IVF in a commercial context.
>
> Juergen
>
> ------------------------------------------------------------------------
> When reading a text file using a simple routine in a FORTRAN-DLL
> called from Excel, the end= condition is not detected. The error
> message is
> Unhandled exception at 0x04c55ac1 (DLL-Test-1.dll) in EXCEL.EXE:
> 0xC0000005: Access violation reading location 0x00000000.
> This is an isolated portion of a very large library, that worked fine
> under Watcom (until 1999) and DVF and now needs to be ported to IVF.
> The issue is time critical!
> The example .net-solution is included. You might need to set the
> correct path to the debug-executable (excel.exe).
> Issue Communication Reply to Issue
>
> Feedback from Juergen Rarey: 10/7/2004 2:35:38 PM
> Hello Sachin,
>
> selecting single-threaded DLL didn't help. I meanwhile implemented a
> workaround by writing a COM-Wrapper in DVF, so the DLL runs in the DVF
> process. Debugging is rather inconvenient and execution speed suffers
> from the out-of-process connection. Wrapping >60 routines with a few
> hundred parameters made me quite unhappy.
>
> BTW, I have no context sensitive help for IVF in Visual Studio .net
> and the IVF-help is not visible in Visual Studio.
>
> I am missing any example code (which was available in DVF and very
> helpful).
>
> Not havving a COM-Server Wizard limits use of IVF significantly.
>
> My nearly 20 support issues with DVF were always resolved very fast
> and competent, your handling of this issue convinced me to avoid IVF
> as long as possible.
>
> You guys should make sure to support the mainstream (Windows, Office,
> .net) instead of putting too much work into versions for dead
> (Itanium) processors or dead (UNIX, Linux) operating systems.
>
> sincerely
>
> Juergen
>
>
> Updated by Intel: 9/29/2004 5:45:13 AM
>
> Hello Juergen,
>
> The developer team is working hard to solve this problem. They have
> also provide following suggestions:
> Multithreaded static library uses mechanism of static TLS (Thread
> Local Storage). MS OS does not support this mechanism for dynamic
> loaded libs. This is the reason why user built DLLs do not work.
> Currently the customers may use multithreaded DLLs or single threaded
> (static or dynamic) libraries.
>
> Please let me know, if this helps you.
>
> Regards,
> Sachin
>
>
> Feedback from Juergen Rarey: 9/16/2004 5:09:13 AM
> I still wait for the update on the progress. More than 4 month.......
> Updated by Intel: 5/3/2004 6:09:35 AM
>
> Hello Juergen,
>
> I have added your issue into our problem tracking database. I will
> keep you updated on the progress of the same.
>
> Regards,
> Sachin
> Intel Customer Support
>
>
> Feedback from Juergen Rarey: 4/30/2004 1:09:53 AM
> Hello Sachin,
>
> I prepared a 6.6b Workspace and a VS-IVF Solution with 2 projects for
> you.
>
> You can start all 3 items (after you set the right path to your
> Excel.exe).
>
> 6.6B - The command button in the Excel-*** starts the DLL, which
> opens and reads the file DDB.CFG until the end and returns without
> error.
>
> VS-IVF
> - Read-Test-W is a Windows program that reads the file to the end. No
> problem
> - DLL-Test-1 is identical to the 6.6B example but crashes in the first
> read of LU 20. (It shouldn't do that ;-))
>
> I believe, solving this isolated problem will also yield the solution
> to my problem with the large DLL.
>
> The problem is time critical, because a colleague, who is responsible
> for about 30% of the DLL just moved back to Japan and has no DVF but
> bought IVF and VS.Net for the further cooperation. We have convergence
> problems in his part and can do nothing at the moment :-(
>
> The DLL is the thermodynamic calculation engine for a large program
> package sold to 40+ large Chemical Companies worldwide
> (www.ddbst.com).
>
> Best regards
>
> Juergen
>
>
> Updated by Intel: 4/29/2004 6:44:44 AM
>
> Hello Juergen,
>
> Thank your for the nice testcase.
> I could reproduce your problem. But I faced the same problem with CVF
> 6.6a also.
>
> Can you please elaborate more on the steps to reproduce the problem?
>
> Regards,
> Sachin
> Intel Customer Support
>
>
> Feedback from Juergen Rarey: 4/28/2004 4:48:27 AM
> Hi Hrishikesh,
>
> I just updated to 8.0.047 pe 048.1. I still get the same error. Can
> you reproduce the problem?
>
> regards
>
> Juergen
> Updated by Intel: 4/26/2004 2:46:42 AM
>
> Hi Juergen,
>
> I have received your issue; will update you with my investigation.
>
> Regards,
> Hrishikesh Hegde
> Intel Customer Support

        "it's time to move on. Intel Visual Fortran is
         where the action is today."
                -- Steve Lionel

Your experience suggests that *ACTION* and *INACTION* appear to be
synonymous for some. In any case, as a developer you should've known
better than to anchor your application on an incomplete work in progress
compiler.