Clearwin on Linux and Windows

I see Gino GUI builder works on both Windows and Linux, while Winteracter staying itself on Windows communicates with Linux via network (X Windows). How difficult to make Clearwin to work on Linux or at least on Linux virtually via X Windows?

Does Clearwin work with other compilers on Windows besides gFortran ?

I have used ClearWin+ on Windows with Intel iFort as well as gFortran and I plan to provide a YouTube demo shortly.

Fortran Standard 2018 pays now attention on better language interoperability of Fortran with all other languages, not just C/C++. Julia and Python could come probably next. That also automatically means better interoperability between different Fortran compilers too, not just fancy like Julia or Python .

Definitely here something has to be done right now. I tried Clearwin with gFortran and immediately got a punch into the face that my gFortran 13 can not use pre-built modules of Clearwin made with gFortran 8. If we will change versions every year this sounds like a disaster. OK, not a problem, the option was mentioned in Help to compile Clearwin themselves, but no examples were given.

Also there was mentioned the advise/requirement for parallel development of two Clearwin applications - native for FTN95 and foreign for gFortran/Intel/NAG/etc. This is i guess because something can not be done if you use different compiler. Is this advise still the live option with Clearwin in case of mixing parts of the code with different compilers ? If differences were minimal it would be OK even without two versions. Pre-compiler options come to mind but for them FTN95 has to adjust to C/C++ style for that like all other Fortran compilers already using while FTN95 still has its own ones, MUCH less capable and which will not allow broader interoperability. Curious how Gino succeeded to make an universal application for all compilers and OSes, did it miss a lot on that road ? I never used Gino, third party apps is on a long run almost always a bad idea. Somehow Gino and Winteracter in 25 years still not dead but that was due to support of big boys like Apple with Absoft and in part Intel. Both of them will go sideways from now. Absoft is dead, and Intel will not have any resources to support its Windows app, look in its disastrous shape last couple years - a total mess. Linux version though works perfectly thanks to support from even bigger big boys, like S&P 500 companies and top500 supercomputers (all but one Linux). This why FTN95, its developers and all users of Windows should look at Linux too. It became beautiful OS, it overjumped Windows finally because all billions cell phones work on Linux. Most of applications look fresh and classy, while Windows ones dull, boring and ugly. Try to install VirtualBox and customize it additionally with the Extension kit and some apps and in 1-3 hours you will see that yourselves. Just the editor Kate is a pure masterpiece. VirtualBox makes your PC Windows and Linux at the same time, you do not like it - just uninstall it and install Hyper-V with another Windows or even DOS 2.1 to play Tetris 1.0 on CGA screen 😃 Very convenient and useful app.

Native PL was also not implemented as Help says. But that was years ago. Is it implemented now?

Native PL was also not implemented as Help says. But that was years ago. Is it implemented now?

In what context was it not implemented?

I do not know. I am just citing the Help file :

%pl      has not been implemented for 64 bit ClearWin+.
 

Also it says

%og  Stricter type checking in gFortran means that some scalar arguments (to OpenGL functions) must be changed to one-element arrays.
 

What that exactly means and how it will look to fix it?

%pl is available in 64 bit ClearWin+. I can't find the statement that you quote.

For %og you only need to make a change when you get a compile time failure. Then a scalar argument v must be changed to an array v with one element.

Dan, argument checking in newer versions of Gfortran can become a nuisance with old codes in which scalar arguments are passed as arguments when the corresponding dummy argument is an array. If such mismatched arguments are then passed along as arguments to other subroutines in a chain, fixing the code can be time-consuming.

If you do not mind taking a slight risk, and you are sure that the code being compiled is otherwise error free, try the Gfortran option -fallow-argument-mismatch .

Another solution to the mismatch problem is to surround the scalar actual argument(s) in question with brackets. For example, replace the 4th argument n in the CALL

if ( miter <= 2 ) call dlsodi(res,addafl,jacfl,n,y,ydoti,t,tout(io),itol,rtol(j),atol(j),1,    &
                              & istate,0,rwork,lrw,iwork,liw,mf)

by [n], as in

if ( miter <= 2 ) call dlsodi(res,addafl,jacfl,[n],y,ydoti,t,tout(io),itol,rtol(j),atol(j),1,    &
                              & istate,0,rwork,lrw,iwork,liw,mf)

Thanks for the hint, mecej4

Mecej4, alas, unfortunately that does not work, same problem of clrwin$.mod was created with different version of GNU Fortran compiler.

Try to create gFortran Clearwin app with this simplest example, may be i'm doing something wrong

use clrwin$
i=winio$('Hello all')
End

It was compiled this way

gfortran aaa.f90 -fallow-argument-mismatch -o g.exe

All my 30+ years with this compiler I have an impression that no matter what its new feature I will try I am the first and the only user of it so far. All the features are always look like they were left unfinished but no one discusses them or requests to continue. Also I never seen in the forums a single attempt of company to attract any slightest attention to what they have done or what's new they are currently working on. Isn't this another devilry or Matrix I don't know but the fact is really unbelievable.

Now trying Clearwin for outside compilers which seems was done a half dozen years ago. I so far haven't successfully compiled a single simplest Clearwin program with gfortran compilers. How to resolve version conflict ones and for all times with compilation of libraries in foreign compilers?

Quoted from DanRRight gfortran aaa.f90 -fallow-argument-mismatch -o g.exe I think this usage does not include the relevant 'clearwin.dll' when building g.exe

I tried

gfortran aaa.f90 clrwin$.mod -fallow-argument-mismatch -o g.exe

gfortran aaa.f90 clearwin64f.dll -fallow-argument-mismatch -o g.exe

All give the same error:

'Can not read module clrwin$.mod because it was created by a different version of GNU Fortran'. Downgrading to version 8 from my current 13 looks not that attractive

Please await an upcoming Youtube video that I am aiming to provide this week.

Dan, here is how I built your postage-stamp-size example on Windows 11.

1. In a working directory, place a copy of clrwin.f95 (original in the FTN95 source64 directory).

2. With your example source code, dang.f90, also in the same directory, and using the Cygwin Gfortran 11.3 that I have, I built the application with the commands

   gfortran -fdollar-ok -c clrwin.f95 gfortran -fno-underscoring -fdollar-ok dang.f90 c:\LANG\FTN95\redist\clearwin64.dll -o dang

The first compilation produces a fresh clrwin$.mod for use by the second command line. Please use the correct path to clearwin64.dll in the second command line. The resulting application dang.exe can then be run to show the small output window from your program.

When you try the same procedure with your larger application, you may need in addition the Gfortran option -fallow-argument-mismatch.

Here is a link to a video that describes how to create applications from Plato using any of the compilers FTN95, gFortran and Intel iFort.

https://www.youtube.com/watch?v=50BY9gyNY2o

Thanks Mecej4, this solution with as usually perfect guiding description finally works and resolves the major problems of initial start of new thing. You saved me from days of clueless attempts.

Thanks Paul for new video. Clearwin finally has signs of perfection i always wanted to see from the beginning. Visual Clearwin was good idea at that time but it did not get enough traction i think. Please keep broadening its usage. Today with most Fortran compilers, tomorrow hopefully also with other OS

By the way i read in the documentation (possibly i did not update it for a long time) that %cw usage with gFortran/Intel changed vs FTN95 but still i see the attempt to open the %cw text window and write something into it. Unfortunately text window did not work when i ran this code clearly made for other compilers i do not know where from it got into my computer: error messages - missing %cw related and Info related functions. Is this my gFortran installation bug/feature (Equations dot com 13beta) ?

    program aw
      use clrwin$
      integer i,c0,c1,c2
      integer(CW_HANDLE)::h1,h2,cwh1
      common h1,h2
      integer,external::child_func

      i=winio$('%pv%fr&',400,400)
      i=winio$('%ww[no_border]%ca[MDI frame]&')
      i=winio$('%mn[&Child]&',child_func)
      i=winio$('%lw',c0)

      i=winio$('%aw&',c0)
      i=winio$('%ww[no_border]%ca[First Child]&')
      i=winio$('%pv%30.3`cw[hscroll,vscroll]&',10,cwh1)
      i=winio$('%lw&',c1)
      i=winio$('%hw',h1)

      call set_max_lines$(cwh1,50)
      call cw_write$(10,'Hello there!')

      i=winio$('%aw&',c0)
      i=winio$('%ww[no_border]%ca[Second Child]&')
      i=winio$('%pv%gr[black,metafile_resize]&',200,200)
      i=winio$('%lw&',c2)
      i=winio$('%hw',h2)

      call draw_ellipse$(100,100,50,50,255)
    end

!--------------------------------------------
    integer function child_func()
      use clrwin$
      integer i
      integer(CW_HANDLE)::h,h1,h2
      integer hh
      common h1,h2
      h=clearwin_info$('FOCUS_WINDOW')
      hh=0
      if(h.eq.h1) hh=1
      if(h.eq.h2) hh=2
      if(hh.gt.0) then
        i=winio$('Window %wd is active %2nl%cn%`7bt[OK]',hh)
      endif
      child_func=1
    end

%cw is not supported for third party compilers.

The documentation refers to an alternative that uses a call to cw_write$. This is incorrect.

For third party compilers %cw can be replaced by %re. Then you do an internal write (to a character variable str) and call EditWriteLn$(hwnd, str) where hwnd is obtained from %lc.

To avoid confusion, i will post the error i got after downloading today Demo file (with newer clrwin.f95 and other library files)

Compiling file clrwin.f95 using gFortran.
Compilation completed with no errors.
Linking...
c:/users/rigt/gcc/bin/../lib/gcc/x86_64-w64-mingw32/13.0.0/../../../../x86_64-w64-mingw32/bin/ld.exe: c:/users/rigt/gcc/bin/../lib/gcc/x86_64-w64-mingw32/13.0.0/../../../../x86_64-w64-mingw32/lib/../lib/libmingw32.a(lib64_libmingw32_a-crt0_c.o):crt0_c.c:(.text.startup+0x2e): undefined reference to `WinMain'
collect2.exe: error: ld returned 1 exit status
Linking completed.

But that's possibly because this Fortran file above is kind of 'defective' using %cw which does not work with third-party compilers (i'll repeat i do not know where i found this Fortran file with $ instead of @). Again, still compiling it in batch file outside Plato has no problems.

But the Demo1 project itself works now in Plato OK. The only little problem was that it did not load into Plato the file demo.f95 which i loaded separately after loading project from Demo1.zip archive.

Would be nice to add OpenGL to Demo1. I have a 3D game written in FTN95 (actually in FTN77 first versions) and OpenGL. May be needs a bit polishing but it works. Including it here would improve the Demo1 and the attractiveness of Clearwin

There are some OpenGL demo programs in the FTN95 samples which by default are located in C:\Users\UserName\OneDrive\Documents\FTN95 Examples\OpenGL.

There is also some code in ftn95.chm at FTN95>ClearWin+>OpenGL>The conversion of a Red Book example.

Was the reason to remove %cw because of conflict of FTN95 with gFortran, iFort and basically all other compilers respect to where goes the default console print* - is it channel 0, or 1, or 2 or 6 etc?

Before %cw in FTN95 was using channel 0 for Print*. Now channel 2.

The %cw has a lot of flexibility and usability. You also can use any other channels, for example 155 or 43124 and you will just write there like this:

i=winio@('%100.25cw[hscroll,vscroll]&',155) - creates this window for all other such prints like this:

write(155,*) ...

Good about %cw is that 1) it has virtually unlimited buffer 2) you can change font, 3) font size, make it bolt, italic etc, 4) change window backgrounds and 5) i think you can even change color of output fonts. I do not even mention you can highlight and Ctrl+C and Ctrl+V the text from it and save if you need which workaround %re also can do. Typically, if you simulation works, it prints a lot of stuff as intermediate warnings and info etc and all that if goes into %cw instead of Command Prompt is not lost in %cw. Essentially the %cw is the same as Command Prompt window, but you can open 10 different %cw windows and write specific outputs you need there with no limit and all will be saved, while Command Prompt has small buffer you now can not find where to change in Windows Registry, and even if you increase it it is still very limited and often useless

Now i speculate (i need still to succeed to migrate and run my code with other fortrans which may take unknown time as i used tens of thousand lines of Clearwin text everywhere in the codes ) with this workaround %re instead of %cw we are getting a small buffer and additionally essentially losing the ability simply to Print* or write(155,) Fortran standard way and return back to ancient ages with its black Command Prompt window for all your Print outputs...Hope i am wrong.