forums.silverfrost.com Forum Index forums.silverfrost.com
Welcome to the Silverfrost forums
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Output Window functionality + clearwin64.dll

 
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> ClearWin+
View previous topic :: View next topic  
Author Message
DietmarSiepmann



Joined: 03 Jun 2013
Posts: 279

PostPosted: Thu Nov 22, 2018 12:47 pm    Post subject: Output Window functionality + clearwin64.dll Reply with quote

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:
Code:

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
Code:

ftn95 hello.for /link /CFPP /WINDOWS

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

Compiling it via INTEL ifort command

Code:

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
Back to top
View user's profile Send private message
mecej4



Joined: 31 Oct 2006
Posts: 1885

PostPosted: Thu Nov 22, 2018 1:29 pm    Post subject: Reply with quote

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.


Last edited by mecej4 on Thu Nov 22, 2018 3:10 pm; edited 1 time in total
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 7916
Location: Salford, UK

PostPosted: Thu Nov 22, 2018 2:55 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message AIM Address
DietmarSiepmann



Joined: 03 Jun 2013
Posts: 279

PostPosted: Thu Nov 22, 2018 5:33 pm    Post subject: Reply with quote

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
Back to top
View user's profile Send private message
mecej4



Joined: 31 Oct 2006
Posts: 1885

PostPosted: Thu Nov 22, 2018 5:53 pm    Post subject: Reply with quote

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?
Back to top
View user's profile Send private message
JohnCampbell



Joined: 16 Feb 2006
Posts: 2554
Location: Sydney

PostPosted: Fri Nov 23, 2018 2:57 am    Post subject: Reply with quote

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)
Back to top
View user's profile Send private message
DietmarSiepmann



Joined: 03 Jun 2013
Posts: 279

PostPosted: Fri Nov 23, 2018 4:04 pm    Post subject: Reply with quote

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
Back to top
View user's profile Send private message
DanRRight



Joined: 10 Mar 2008
Posts: 2813
Location: South Pole, Antarctica

PostPosted: Fri Nov 23, 2018 8:29 pm    Post subject: Reply with quote

DietmarSiepmann wrote:
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.


Last edited by DanRRight on Sat Nov 24, 2018 8:53 pm; edited 1 time in total
Back to top
View user's profile Send private message
JohnCampbell



Joined: 16 Feb 2006
Posts: 2554
Location: Sydney

PostPosted: Sat Nov 24, 2018 2:19 am    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> ClearWin+ All times are GMT + 1 Hour
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group