64 bit ClearWin+

Thanks John and Dietmar. That's good, a decade ago 1 GB array created 1GB EXE.

Also, does IFORT load this entire 1GB array into memory just to assign its single element or not?

Another question - what maximum size arrays you succeeded to allocate with 64bit compiler? How fast allocation goes (how many GBs per second) ?

We are trying to port the Salford clearwin online help mechanism of a Salford 32 bit Fortran application to 64 bit using Intel Fortran Compiler ifort, version 11.1, for compilation, xilink for linking and resource compilers src.exe and rc from the Intel 64 bit compile environment.

We use the following application browse.for which is based on a Salford demo application written in C.

       PROGRAM FACTOR
#ifdef INTEL64
       use mswin$
       USE IFWIN
       USE CLRWIN$
#endif
       IMPLICIT NONE
#ifndef INTEL64
       INCLUDE <WINDOWS.INS>
#endif

       INTEGER rwinio
#ifdef INTEL64
       CALL ADD_HYPERTEXT_RESOURCE$('TEXT')
       
       rwinio=winio$('%mi[BROWSE]&');
       rwinio=winio$(
     *  '%ca[ClearWin Browser]%mn[&File[E&xit],&Back,&History]&',
     *  'EXIT','PREVIOUS_TEXT','TEXT_HISTORY')
       rwinio=winio$('%bg[grey]%ww%pv%70.20ht@','INTRODUCTION')
#else
       CALL ADD_HYPERTEXT_RESOURCE@('TEXT')
       
       rwinio=winio@('%mi[BROWSE]&');
       rwinio=winio@(
     *  '%ca[ClearWin Browser]%mn[&File[E&xit],&Back,&History]&',
     *  'EXIT','PREVIOUS_TEXT','TEXT_HISTORY')
       rwinio=winio@('%bg[grey]%ww%pv%70.20ht@','INTRODUCTION')
#endif
       
       END

The code of file browse.for to be compiled depends on define INTEL64 which is set in the compile step to produce the intel code; if define INTEL64 is not set in the compile step then the code is meant for the 32 bit Salford scenario. Using resource file browse_ctrls.rc

TEXT HYPERTEXT browse.htm
run BITMAP run.bmp
BROWSE ICON browse.ico

and compiling it to object file browse_ctrls.obj we can link a 32 bit application browse.exe using the Salford compile environment and a 64 bit application browse.exe using the Intel 64 bit compile enviroment and Salford's clearwin64.dll.

The code makes use of a hypertext file browse.htm which supplies the texts etc. used in the help file. The hypertext file is integrated into the final executable by means of the resource compiler which generates an object file against which the final executable is linked.

For the 32 bit scenario we use Salford's resource compiler src.exe whereas for the 64 bit scenario we use the resource compiler from the INTEL64 build environment.

Application browse.exe creates a menu bar consisting of menus 'File', 'Back' and 'History'. The latter two menus provide the functionality to navigate through the help texts.

This works pretty well and as expected for both the 32 bit version and the 64 bit version with the exception of the history menu in the 64 bit case. Clicking the history menu makes the 32 bit application display a window used to navigate through the help themes. However, when clicking the history menu in the 64 bit case, then the application crashes displaying the information window 'ClearWin+ error'

Argument no 8 of winio
should be a list-box call-back function - not string 'H*f*i(H...'

Here ... is a string containing some 'strange' characters.

I suspect the problem might be the resource compilers. For the 32 bit scenario we use command

src browse_ctrls /binary SALFORD\browse_ctrls.obj

for the 64 bit scenario we use command

C:\Program Files (x86)\Microsoft Visual Studio 8\VC\PlatformSDK\bin\win64\amd64\rc.exe /fo INTEL64\debug\browse_ctrls.obj browse_ctrls

. Any comments are welcome.

Dietmar

There is a very good chance that this issue has been fixed in the latest download, uploaded on Wednesday of this week.

Also the new web browser control %wb may be better for your needs.

Thanks Paul,

I used the chance and installed the latest download as you suggested. With this new version my 64 bit test application worked as expected and in the same way as the 32 bit application.

Dietmar

Paul,

in a previous post I addressed the problem of a symbol which caused a 64 bit application linked against clearwin64.a to crash at runtime. The application was built with the Intel Fortran compile environment (ifort + xilink). The crash occurred only for the version built without the debug flag being set. If the debug flag was set, everything worked fine and as expected.

I asked the Intel support for advice and provided Intel support with a test application. Now Intel support responded concerning the clearwin64 dlls and export libraries: 'I had one of my colleagues examine your files and at least one of the DLLs was built assuming gfortran was calling them and the export libraries were clearly assuming gfortran.'

I do not know if that is true, however, if so, what are these assumptions and what would I do then?

Moreover, I created map files while linking both the debug and 'non debug' version of the test application. The map files differ significantly concerning the symbols SymInitialize, StackWalk64 and SymCleanup (one of which caused the crash). If you are interested I could provide them as well as the example code.

Regards, Dietmar

Dietmar

Please see my reply to your private message.

Thanks for the offer to send the files but I don't think that we could make use of them at the moment.

Paul,

concerning the problem linking a 64 bit binary with Intel Fortran and using clearwin64 we are still facing runtime problems for the non debug version. Now Intel support asked:

'Do you know which version of Microsoft C++ was used to build clearwin64. Since I'm able to build and run under VS 2012 and 2013, I'm wondering if the version that was used to build clearwin64 is not compatible with the libraries that come with VS 2008 and 2010.'

I used clearwin64 dlls and libs dated from 12th February 2014 when creating the binary in question. And I am using MSVC 2008.

Could you please tell me if the clearwin64 stuff is compatible to the dlls and libraries that come with MSVC 2008?

Thanks and regards, Dietmar

The relevant version is Visual Studio 2010.

Dear Paul,

we use still ClearWin+ 64-bit with the Intel Fortran 64-bit Compiler.

We have the problem, that some graphic routines are missing in clrwin.f95. So I tried to adapted them but I run into an exception calling them.

I dont know if my ported declaration of 'create_polygon@' and 'fill_polygon@' for 64-bit is correct.

Thats the code that I am using in file clrwin.f95 (64-bit):

!-------------------------------------------
interface
subroutine create_polygon$(x,y,n,hwnd,ierr) bind(C,Name='__win_create_polygon_l')
use ISO_C_BINDING
integer(C_INT)::x(*),y(*)
integer(C_INT),value::n
integer(C_LONG_LONG)::hwnd
integer(C_INT)::ierr
end subroutine create_polygon$ 
end interface
!-------------------------------------------
interface
subroutine fill_polygon$(hwnd,col,ierr) bind(C,Name='__win_fill_polygon_l')
use ISO_C_BINDING
integer(C_LONG_LONG),value::hwnd
integer(C_INT),value::col
integer(C_INT)::ierr
end subroutine fill_polygon$
end interface
!-------------------------------------------

I changed hwnd from C_LONG_LONG to C_INT but the effect is the same.

Is there a chance to get it working?

With the newest clearwin64.dll I get the message during the execute of create_polygon$:

ALLOCATE_POLYGON_HANDLE@ has not been ported to the current platform.

So, we can't use these routines?

This class of functions has not been ported to 64 bits. An alternative is to use DRAW_POLYGON@ and DRAW_FILLED_POLYGON@.

Ok, so I have created my own routines CREATE_POLYGON$ and FILL_POLYGON$ using DRAW_POLYGON$ and DRAW_FILLED_POLYGON$. My workaround works for my cases very nice.

Thanks.

The help page on '64-bit ClearWin+' contains some typos. Under the section on primary changes, it indicates in a couple of places that the module winprm$ (should read mswinprm32) should be used instead of msw32prm. I think there is a similar error with winapi$, which should be mswinapi$, although I have not been trying to use that module.

From my understanding of the Help pages (which is not very strong!) I should be able to change all references to clrwin to clrwin$ and still compile from FTN95 in 32-bit mode. However, I get an error message when trying to use window_update$, which is not found. I think it is found in the 64-bit clrwin$ - I can find it using another compiler, but I have not been able to test it with FTN95 yet. I can get around the problem, apparently, by using window_update@ from clrwin, but I am wondering if I am doing something wrong.

I wonder which help pages you are using. If you can let me know I will check the details.

The main thing to note is that the \(endings for modules and routines are for use with third party compilers. If you are using only FTN95 to compile ClearWin+ code then I suggest that you avoid using the\) endings.

Thanks for the quick response Paul. I found the typos in Silverfrost\FTN95\doc\clearwin64.txt, and when I searched from within Plato by clicking on Help ~ ClearWin+ ~ Index ~ 64 bit ClearWin+

The pages above also use the word 'paralled' a couple of times, which I assume is 'parallel'.

The reason I changed from @ to $ everywhere is because the page says:

'There are two primary changes that are required in order to make ClearWin+ code accessible to both fx64 and FTN95 (so that it can access salflibc.dll from FTN95 and ClearWin64.dll from fx64).

'First, ClearWin+ routines that end with the @ symbol must be changed so that they end with the $ (dollar) symbol.'

I took the general meaning of the text and the specific reference to salflibc.dll (as opposed to salflibc64.dll) to imply that using the $ sign would make it possible to use the same code for compiling with FTN95 using both 32-bit and 64-bit, and for compiling in 64-bit with other compilers.

OK. The text will have been written before porting FTN95 to 64 bits. I will take look and aim to clarify the meaning.

Just to confirm, you should be able to use the \(endings from FTN95 but they are designed and intended for use with third party compilers. Also the\) routines will have an independent set of 'missing routines'.