64 bit ClearWin+

I am trying to port a 32 bit Fortran application to 64 bit which makes use of e.g.

 INITIALISE_MOUSE@
 SET_MOUSE_BOUNDS@

. I am using the Intel 64 bit Fortran compile environment (compiler: ifort). When linking, both symbols INITIALISE_MOUSE$ and SET_MOUSE_BOUNDS$ remain unresolved although I am linking against Silverfost's libraries clearwin64f.a/clearwin64.a. Looking at Silverfrost's web site

Silverfrost > Documentation > FTN95 Help > ClearWin+ User's Guide > Mouse

I could find both INITIALISE_MOUSE@ and SET_MOUSE_BOUNDS@. Now I wonder how I could resolve these symbols. I could not find these symbols in the clearwin64 dlls/libs as of 26th March 2013.

How would all the other symbols mentioned on the web site be resolved?

These two functions are old DBOS functions that were ported to Win32 but have no effect under Win32. You can either delete them or write your own dummy routines.

Just to re-assure you, here is the ClearWin+ code for INITIASE_MOUSE@.

STUB('INITIALISE_MOUSE@',__initialise_mouse)

void __initialise_mouse(void) { //noth }

In other words, INITIALISE_MOUSE@ is translated to __initialise_mouse which is a dummy routine.

SET_MOUSE_BOUNDS@ is the same.

I have tried to port everything to 64 bit ClearWin+ that can be ported and may be needed. If there are other missing functions then please let me know.

A Fortran/Clearwin application ported from 32 bit to 64 bit makes use of the calls

  A=WINIO@('%hw&',IHDLW1)
  A=WINIO@('%lw',LHDLW1)

(in sequence). The output value for IHDLW1 is 0 for both the 32 and the 64 bit application (where the names WINIO@ have been mapped to WINIO$ for the 64 bit version). However, the output value for LHDLW1 is -1 for the 32 bit application and 0 for the 64 bit application. IHDLW1 and LHDLW1 are of type integer*4. The winio@ calls mentioned above are preceded by other winio@ calls of the form

 A=WINIO@(<format code ending with &amp;>,...)

The 64 bit application has been built with the Intel Fortran Compile environment (compiler ifort.exe) and is linked against the ClearWin+ 64 bit dll.

I wonder why the results for LHDLW1 are different.

LHDLW1 needs to be a 64 bit integer for 64 bit apps.

Use the integer kind CW_HANDLE as described in the documentation.

Correction. It is IHDLW1 that needs to be INTEGER*8 not LHDLW1.

Thanks a lot, Paul, this helped and made the 64 bit application react in the same way as the 32 bit application with respect to handle LHDLW1 retrieved by means of the winio call.

Unfortunately I do not know which of the handles need to be 64 bit and which need to be 32 bit for the Clearwin+ 64 bit dll. I'm afraid this problem will occur, as well, in other situations, hence I would appreciate any help how I could find out which of the handles need to be 64 bit for the Clearwin+ 64 bit dll. From your information, Paul, I think some of the handles are 32 bit, others are 64 bit.

You should have a text file with instructions.

Here is the relevant section...

ClearWin+ occasionally uses HANDLEs that correspond to Microsoft HANDLEs such as HWND, HDC, HFONT, HBITMAP etc. These are all addresses (C pointers). So in 32 bit FTN95 they are stored in user code as INTEGER4 variables whilst in 64 bit fx64 they require INTEGER8 variables. For this reason the clrwin$ modules define an INTEGER KIND called CW_HANDLE that matches the environment. This means that relevant HANDLEs should be declared with type INTEGER(kind=CW_HANDLE). Note, however, that some HANDLEs described in the ClearWin+ documentation do not represent Microsoft HANDLEs and these are invariably INTEGER*4. This includes the %gr handle used in a call to select_graphics_object$.

Dietmar,

I can remember asking a related question in the forum under the title 'When is a handle not a handle?' - although I can't seem to find it now. Certainly %gr asks for a [u:09d2625726]Clearwin+ [/u:09d2625726]handle. I can't remember what other handles are Clearwin+ handles, and which are Windows handles - but there is probably a Clearwin+ handle associated with %dw as well as with %gr.

However, if you read the CHM file, there are some very subtle clues: if Clearwin+ gives you a handle, then it is a Windows handle. If you give it a handle, then it is a Clearwin+ handle. Often, Clearwin+ works even if you haven't presented the numeric value of a Clearwin+ handle, because arithmetic is never done with the handles, and any value works. Neglecting to set a Clearwin+ handle shows up as an apparently unsolvable problem (for example) if you have two %gr areas, and you have relied on the default for an integer when passing across handles to Clearwin+ for both of them.

It is all so much easier with 32-bit Clearwin+, as both handle types are 4-byte integers. One or two old FTN functions take 2-byte integers, and similar size problems arise there.

Eddie

We are trying to port opengl functionallity from 32 bit to 64 bit. Our application makes use of call GLUTMOUSEFUNC. This function is mapped to __cwMouseFunc in FTN95 (32 bit, salflibc.dll). When we link our application to create a 64 bit executable (using the intel fortran 64 bit compiler and linking against the clearwin64+ dll) symbol GLUTMOUSEFUNC remains unresolved. Looking at the clearwin64.dll we see that other functions concering the glut stuff have been mapped to functions of clearwin64.dll, for example glutDisplayFunc which has been mapped to function __cwDisplayFunc of cleawin64.dll. We wonder if __cwMouseFunc should, as well, be contained in clearwin64.dll.

Yes it looks like the following functions have been left out by mistake...

__cwMouseFunc
__cwKeyboardUpFunc
__cwSpecialUpFunc
__cwGetUniqueMenuItem glutExtensionSupported

I have added the first three of these functions to the download.

Before using any of the files in the download, make sure that you have backed up your existing files.

I have not tested the bindings for the added functions. These appear in source64\opengl.f95. If the compile does strong type checking then then the type of the argument will be wrong.

We try to port a big existing application from 32 bit to 64 bit. I can not find the following functions in clrwin.f95

• GETENV
• CURDIR
• UPDATE_WINDOW

We need this functions.

I am working on this.

I have added getenv$ and you will be able to call this function from either FTN95 (with a new salflibc.dll) or from a new clearwin64.dll. But note that the bindings are different...

For FTN95 you declare

character(len=1024)::getenv$

otherwise you need to have

USE clrwin$

current_dir$ is already implemented and is preferred to curdir because its declaration is common to FTN95 and third party compilers.

However, I have added curdir$, but note that the bindings are different in the same way as for getenv$.

Note that update_window is an old routine used with ClearWin (%cw) windows. So check that it is used in a relevant way.

However, I have now provided access to it in clearwin64.dll via the name update_window$.

I will post another reply when the new version has been uploaded.

A new 64 bit DLL has been uploaded to http://www.silverfrost.com/beta/clearwin64.exe

The default path for this self-extracting archive is C:\Program Files (x86)\Silverfrost

Please backup all related files before extracting.

Note that the argument in update_window$ is a 64 bit integer.

Paul, thank you for your work. Do the functions also with LINUX?

I notice that Simfit is available for LINUX so I guess the answer is YES. Perhaps other users might advise on how to do this (using Wine?).

I have uploaded a new ClearWin64.dll (same URL as above). This brings the GDI+ additions up to date, including text rotation.

The function winio$('%im[image_name]') doesn't work on Windows 8

I have logged this for investigation but a small sample program would help.