Microsoft KB Archive/74544

= Restrictions Applying to FORTRAN 5.1 Windows DLLs =

PSS ID Number: 74544

Article Last Modified on 5/5/2001

-

The information in this article applies to:


 * Microsoft FORTRAN Compiler for MS-DOS 5.1

-



This article was previously published under Q74544



SUMMARY
There are a number of restrictions regarding the use of Windows dynamic- link libraries (DLLs) written with Microsoft FORTRAN version 5.1. The restrictions apply primarily to I/O and the number of supported instances of a DLL.



MORE INFORMATION
The following restrictions apply to I/O in a FORTRAN Windows DLL:

 DLLs may not perform I/O to the screen; only I/O to files is supported. There is no mechanism for preventing you from including screen I/O commands in your programs. If screen I/O is attempted, the I/O may be superimposed over the current Windows display, and the machine may hang. FORTRAN DLLs cannot access binary or unformatted files using the READ or WRITE statement. Using the FORTRAN statements READ or WRITE on a BINARY or UNFORMATTED file from a DLL will result in a GPF (general protection fault). For a work around using Windows API functions, see article 102698.  When opening a file in a DLL, you must explicitly give the file name in the OPEN statement or use a CHARACTER variable to assign the name. For example: CHARACTER*12 filename filename = 'file.dat'  OPEN(10, FILE = filename) If the filename is left blank, the program will prompt for it with the message:

File name missing or blank - Please enter name?

However, because screen I/O is not supported, this message will be superimposed over the current Windows display, and the machine may hang.   You cannot access a file that has been opened and left open in any routine outside of the DLL. In this case, no error message is generated, but all I/O is ignored. An alternative to this is to CLOSE the file in the calling routine and pass the name of the file to the DLL. The DLL can then OPEN the file with ACCESS='APPEND' and continue writing to the file. The following program illustrates this alternative:

(In the calling routine:) CHARACTER*12 filename filename = 'file.dat' CALL sub (filename) ! make sure file is closed before passing

(In the DLL:) SUBROUTINE sub (filename) CHARACTER*12 filename  OPEN(1, FILE=filename,   ACCESS='APPEND')  You must explicitly CLOSE all files opened in a DLL before the application terminates. If you don't do this, Windows will hang while exiting the program, and any information left in the output buffer for the file will be lost.

The following restrictions apply to the number of instances supported for a single DLL:


 * 1) FORTRAN Windows DLLs are not re-entrant. This means that FORTRAN 5.1 does not support multiple processes calling the same DLL at the same time. It is possible for multiple processes to call the same DLL, but there is only one copy of the code and data for the DLL loaded into memory at any one time. This means that multiple processes will not be using different copies of the code and data segments of the DLL. If multiple processes access the DLL, no I/O (screen or file) should be performed from the DLL, and you cannot rely on any static data being preserved in the program. Again, this is because different processes are using the same data area, and the consequence may be inconsistent or erroneous results. In the case of I/O, there is no guarantee that internal variables used for I/O in the DLL will be set correctly.

Note: Multiple instances of non-DLL applications will be given separate data segments. Multiple instances of Windows FORTRAN programs are not supported, however, because the program uses &quot;fixups&quot; in the code segment to address variables in memory. (The use of fixups is integral to large memory model programs and only the large model is supported for FORTRAN Windows programming.) Because there is only one copy of the code for the application, and therefore only one copy of the fixups to the data, only the data from the last invocation would be used.

Other Restrictions
 Character strings passed into a DLL may not be declared as type CHARACTER*(*) in the DLL. This is because the internal table used by a FORTRAN application to store the length of character strings is not available to the DLL.</li> Routines in DLLs cannot contain the STOP statement. All routines must return program control to the calling application.</li>  All FORTRAN 5.1 DLLs must explicitly export the symbol WEP. To do this, the statement EXPORTS  WEP should be added to the DLL's module definition file. The WEP routine is included in the FORTRAN 5.1 startup code.

If a DLL already has a user-defined WEP routine (for example, in a mixed- language DLL with existing C code), the WEP routine should be renamed __WEP (with two underscores). The FORTRAN 5.1 startup code will call __WEP, if present, during DLL termination. For additional information concerning the WEP function, see the Windows 3.0 Software Development Kit (SDK) documentation.

NOTE: The above information on WEP is contained in both the FL.DEF and README.DOC files for FORTRAN version 5.1. Both of these sources, however, incorrectly refer to __WEP as _WEP. </li></ol>

Additional query words: kbinf 5.10

Keywords: KB74544

Technology: kbAudDeveloper kbFORTRAN510DOS kbFortranSearch kbZNotKeyword3

-

[mailto:TECHNET@MICROSOFT.COM Send feedback to Microsoft]

© 2004 Microsoft Corporation. All rights reserved.