Output Window functionality + clearwin64.dll

The Salford Fortran compiler (ftn95) supports option '/WINDOWS' which makes read and write statements go to the so called 'Output window' of the application generated - as opposed to the command window. We would like to use the functionality of the Salford output window for read/write statements in an application compiled with INTEL compiler ifort (64 bit version) and using Salford's clearwin64.dll for GUI input/output'.

Please look at the following application named hello.for:

integer*4 KI,KA
      character*10 mychar
#IFNDEF INTEL64
      KI=1
      KA=2
#ELSE
      KI=5
      KA=6
#ENDIF     
      write(KA,'(A)') 'hello world: enter 1-10 characters'
      read(KI,'(A10)') mychar
      write(KA,'(A,A)') 'mychar=',mychar
      end

Compiling it via Salford ftn95 command

ftn95 hello.for /link /CFPP /WINDOWS

makes the read and write statements go to the Salford output window.

Compiling it via INTEL ifort command

ifort hello.for /fpp /DINTEL64

makes the read and write statements go to the DOS command window the compiled application (hello.exe) has been started from. Now I would like to make all the read and write statements of the INTEL generated application go to a new output window (with functionality analogously to the Salford output window of the Salford generated application above).

Is this possible by means of Salford's cleawin64.dll? Which calls of clearwin64.dll would I use? I know in former times there were calls like create_window@, open_to_window@, set_default_window@ which could be used for this purpose, but I am in doubt if they are still supported by clearwind64.dll.

Thanks for any advice Diemar

Dietmar,

I don't think that this approach will work, for the following reasons.

1. FTN95 and Intel Fortran do not use the same pre-connected I/O unit numbers.

2. FTN95 and Intel Fortran differ in how each treats attempted READ/WRITE to I/O units that have not been connected with a prior OPEN statement.

3. Within a single program or DLL, if you have some routines compiled with FTN95 writing to, say, unit-11, and some other routines compiled with Intel Fortran writing to the same unit, the actual I/O will go to two different files or, if there is a clash because the same file name is used in both parts in OPEN statements, a program crash may occur.

4. Fortran I/O is actually performed by routines in the RTL (Run Time Library) of the Fortran compiler. Thus, I/O statements such as READ and WRITE get translated by FTN95 into calls to routines with names such as WSF1@@, R4@WSF and WSF2@. The same I/O statements, compiled with Intel Fortran, would be translated into calls to routines with names such as _for_write_seq_lis. These routines exist in separate DLLs (or static libraries), and are not at all interchangeable.

Also, for FTN95, the 'Windows' option is essentially a linker command that defines an FTN95 executable as being a Windows application rather than a Console application.

The option sets a flag in the header of the executable and is not related to any of the DLLs that it accesses.

Thanks for your informations, mecej4, Paul.

I think for the GUI application in question in most cases the output window functionality is used to display error cases.

Hence I am trying to change the channel of the write statements and make the write statements write to a file which is displayed at the end of the GUI application (which should be only a short time after the error occurred).

Regards, Dietmar

Is it feasible to rearrange your code such that the Intel-Fortran-compiled part does no console I/O, and any file output is completed before the FTN95-compiled part reads those output files and displays the gist in a window?

As mecej4 indicated, code compiled with ifort will use ifort I/O routines and code compiled with FTN95 will use FTN95 routines. If you want to send output to FTN95/Windows.out, could you create a library of routines for I/O that are compiled with FTN95, to access Salford's clearwin64.dll for GUI input/output ? I have not tried this mix, but in the past have mixed 32-bit ftn95 and ifort .obj files (which only one did I/O)

John, mecej4,

originally the GUI application has been created/linked as a CONSOLE application. If everything works fine (i.e. no errors or warnings) then the application does not execute read or write statements (to the DOS terminal it has been started from). However, in special situations (errors or warnings), write statements (to the DOS terminal) are used. I don't think that the application uses read statements (with respect to the DOS terminal).

Moreover I don't think that once the GUI part of the application has been displayed, there are write statements to the DOS terminal the application has been started from.

That's why I would try logging the write output (with repect to the DOS terminal) to a file and display this file short time after the error or warning situations (mentioned above) occurred.

I think rearranging the code would be more effort.

For the same reason I would not want to create a new ftn95 created library, like John suggested.

John, is it really possible mixing 32-bit ftn95 and ifort .obj files?

Thanks for your suggestions and help.

Regards, Dietmar

Quoted from DietmarSiepmann is it really possible mixing 32-bit ftn95 and ifort .obj files? There exist universal way which works with all compilers and needs almost zero effort, just changing few letters in BAT file which is doing compilation. Just compile little differently your ifort files to create you dll not the obj. Use dll with FTN95 same way as you do with obj. Both have to be either 32 or 64 bit, not a mix.

And often obj files of ifort are also usable with FTN95 but better not to play with Russian roulette.

Dietmar,

As you have discovered with I/O (which has the most problems) if you link in a .obj from another compiler, you will need supporting routines from that compiler's libraries. I tried this approach a few years ago to link my dot product function, compiled with ifort AVX instructions and it worked easily as it was just assembler instructions. Once you require the compiler's supporting library routines, then it gets more complicated. The better approach is to assemble the routines in a .dll and make sure the required .dll's are referenced in the link, although my case did not require this complexity. Although my case was 32-bit, I would expect that 64-bit may be better as there are fewer calling conventions to navigate.