forums.silverfrost.com

[MJW4498]

Hello!

I'm having an issue where I'm not picking up the subroutine CW_WRITE$ in clearwin64. I'm working with the latest v9.00, however a colleague of mine is not having this issue and they are working in v8.80.

When I compile my program, I can see from the .map file that is is not picking up CW_WRITE:
---
CW_WRITE$ *Unresolved* -
---

I can see it is picking up some items from clearwin64.dll though (this is where it is picked up from for my colleague in v8.80), for example we have the following in the .map file:
---
COMMAND_LINE - CLEARWIN64.DLL
---

So the question is, is CW_WRITE$ actually in CLEARWIN64.dll?
I've noted that I can find the CW_WRITE$ subroutine within the program folder (C:\Program Files (x86)\Silverfrost\FTN95\source64) in clrwin.f95:
---
!! %cw functions...
subroutine cw_write$(unit,info)
integer(C_INT)::unit
character(len=*)::info
interface
subroutine cw_write$$(unit,info) bind(C,Name='__cw_write')
use ISO_C_BINDING
integer(C_INT),value::unit
character(kind=C_CHAR)::info(*)
end subroutine cw_write$$
end interface
call cw_write$$(unit,trim(info)//C_NULL_CHAR)
end subroutine cw_write$
---
This is then included in clearwin64f.f95. So I presume it makes its way into clearwin64f.dll, but does it get into clearwin64.dll?

Can anyone shed some light on this for me?

Thanks in advance!

[/u]

[PaulLaidler]

CW_WRITE$ is a routine that is used to output text to a ClearWin+ window that uses the %cw format code. It is provided for use with third party compilers such as gFortran.

When compiling with the native FTN95 compiler, CW_WRITE@ (or CW_WRITE$) is not needed because text can then be written to a %cw control using Standard conforming WRITE or PRINT statements.

CW_WRITE$ is exported from ClearWin64.dll as __cw_write so it needs an interface in order to access it from a Fortran program. For FTN95 users the interface is provided, for example, via USE clrwin.

The equivalent for gFortran users is USE clrwin$ but current usage requires that the user imports clrwin.f95 into their project. Alternatively you can extract the code that you have found and include the interface in your code.

[MJW4498]

Thank you for this Paul.

Everything you have said is what we had understood, but in v8.80 we had to use CW_WRITE$ in the native FTN95 compiler.

Has something changed between v8.80 and v9.00?

Note: it was working in v8.80 but is not in v9.00. The maps in v8.80 show that the following are resolved:
---
__close_metafile - CLEARWIN64.DLL
__close_printer - CLEARWIN64.DLL
__cw_write - CLEARWIN64.DLL
__do_copies - CLEARWIN64.DLL
---
but in v9.00 the corresponding are not resolved:
---
CLOSE_METAFILE$ *Unresolved* -
CLOSE_PRINTER$ *Unresolved* -
CW_WRITE$ *Unresolved* -
DO_COPIES$ *Unresolved* -
---

[PaulLaidler]

MJW4498

1) Is the failure occurring when you build with FTN95 or some other compiler?

2) How do you provide the interface for the missing routines? For example is it a USE statement and if it is what does it look like?

[MJW4498]

Paul

1) Yes we're building with FTN95

2) It is the following use statement:
---
USE mswin$
---

Thanks

[PaulLaidler]

MJW4498

At the moment I don't understand how you managed to get this to work with either of these versions of FTN95. I would need more details of the history and perhaps copies of your v8.80 clearwin64.dll and clrwin$.mod64 in order to make progress. These might be different from the initial v8.80 release.

The current recommended practice is to import the interface source files from Silverfrost\FTN95\source64. Details are provided in the video https://www.youtube.com/watch?v=WM8XgsLGneo.

Here are two sample programs that illustrate how it works with v9.0

[DanRRight]

I have no clue why to use cw_write@(10,'Hello world') when just usual write(10,*)'Hello world' is doing the same plus much much more. Does it allow to colorize the text and write it with fonts of different size mixing them on the fly?

By the way the demo Paul showed in the previous post I often use as a substitution for Windows or Linux (under WINE) own Command prompt window. Add color to its background and make different units to separate different streams of output data. You will not lose anything after closing them, such windows have practically infinite write capacity and In Linux you can open and close such windows and nothing will happen with the continuing writing code, no crash or stop. Open and close of them is just one click, you choose your own much nicer looking fonts

[PaulLaidler]

Dan

Please see my post of 9 December.

[MJW4498]

Hi Paul,

Thank you for this.

Our generalised code for 32-bit / 64-bit compilation (last worked on in 8.80) has winio$ and cw_write$ functions. We've tried your first example (which ran successfully in v9.00) so my colleague suggested trying cw_write@ instead of cw_write$ for our code in v9.00, which does work.

Following this, we tried this back in v8.80, but it does not work there. So, something in handling @/$ appears to have changed between v8.80 and v9.00.

My colleague did say that when he did the original preparation for 64-bit he found this confusing, and sometimes had to just change between them from what he expected to the other to get things to work (just presumed it was an error in his expectation, rather than a bug). Now he's just confused!

[PaulLaidler]

MJW4498

Is this issue resolved now?

Just to be clear, cw_write$ is only provided for third party compilers such as gFortran. If you are not using a third party compiler then PRINT is preferred to cw_write$.

In other words %cw normally communicates directly with the FTN95 IO system but this is not possible when using a third party compiler.

[MJW4498]

Paul,

I wouldn't necessarily say that it is "Resolved", as we don't fully understand why the cw_write@/$ switch has to be done, but we are happy that we can continue.

Just to note, in 32-bit we used %cw for both output AND input (ie as a terminal). With 64-bit we have had to split off the "input" from the output. At that time, "write(10,*) 'hello world'" didn't work for us in 64-bit, but cw_write$ did (even though we were in Silverfrost throughout). As that coding worked for us we don't want to revisit it (we don't wish to play around with graphical interface, just get data into/out of the program while we concentrate on the core modelling algorithms).

[PaulLaidler]

MJW4498

Thank you. That is sufficient for me to close this issue.