Introduction
ClearWin+ is accessible from third party 64 bit Fortran compilers. Any third party 64 bit Fortran compiler that passes character variable arguments in the same way as FTN95 can be used and this includes gFortran, Intel Fortran and NAGfor. In this article we will refer to any such compiler as "fx64".
The 64 bit ClearWin+ library is accessed via a DLL called clearwin64.dll. A small number of changes to ClearWin+ code are required for fx64. Once these changes have been made the code can still be compiled and developed using FTN95.
The initial Fortran code must be Fortran standard conforming. This means that FTN95 library routines that are not in the ClearWin+ library must be removed or replaced. For example CORE4(0) can not be used with fx64 whilst LOC may not be available. A number of old FTN95 intrinsics such as RS, LS and LENG can be replaced by standard conforming Fortran 90 variants. See below for further details.
Paralled development using both FTN95 and fx64 can go hand-in-hand provided the code is kept within the Fortran 95 Standard (plus what is now a significant number of 200x extensions permitted by FTN95). Paralled development is advisable for two reasons. First because of the debugging and CHECKMATE features of FTN95 and second because ClearWin+ error reporting is very limited when using fx64.
The standard Silverfrost interfaces to ClearWin+ routines are provided in code form for copying to the local project folder. These must be used instead of, for example, INCLUDE <clearwin.ins> and USE clrwin.
Primary changes required in the ClearWin+ code
There are two primary changes that are required in order to make ClearWin+ code accessible to both fx64 and FTN95.
First, ClearWin+ routines that end with the @ symbol must be changed so that they end with the $ (dollar) symbol. Thus winio@ becomes winio$, window_update@ becomes window_update$, and so on. Note that @ can be replaced globally by $ except where it appears within string quotation marks.
Source code to interface with the ClearwIn+ library is provided in the compiler sub-folder FTN95\Soure64 and these files can be copied into the current project or they can be used to create a ClearWin+ interface library for fx64. Note that the command line option /DOLLAR_MOD must be included when compiling with FTN95.
Second, ClearWin+ INCLUDE and USE statements must be changed as indicated in the following table...
Old |
New |
Source64 file |
INCLUDE <clearwin.ins> |
USE clrwin$ |
clrwin.f95 |
INCLUDE <win32api.ins> |
USE mswinapi$ (See note 1) |
mswinapi.f95 |
INCLUDE <win32prm.ins> |
USE mswinprm$ |
mswinprm.f95 |
INCLUDE <windows.ins> |
USE mswin$ (See note 2) |
mswin.f95 |
INCLUDE <opengl.ins> |
USE opengl$ |
opengl.f95 |
USE clrwin |
USE clrwin$ |
clrwin.f95 |
USE mswin32 |
USE mswinapi$ (See note 1) |
mswinapi.f95 |
USE msw32prm |
USE mswinprm$ |
mswinprm.f95 |
USE mswin |
USE mswin$ (See note 2) |
mswin.f95 |
Minor changes required in the ClearWin+ code
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 INTEGER*4 variables whilst in 64 bit fx64 they require INTEGER*8 variables. For this reason the modules define an INTEGER KIND called CW_HANDLE that matches the environment. This means that relevant HANDLEs should be declared with type INTEGER(CW_HANDLE). Note, however, that some HANDLEs described in old ClearWin+ documentation do not represent Microsoft HANDLEs and these are invariably INTEGER*4. This includes the %gr identifier used in a call to select_graphics_object$.
fx64 is assumed to use Standard conforming ISO_C_BINDING in order to interface with DLLs written in C/C++ (the programming language used for the ClearWin+ library). This form of binding is used in Source64 files for the ClearWin+ modules.
When calling winio$, FTN95 constructs and passes an initial additional argument that describes the types of the arguments that follow. For third-party compilers, ClearWin+ does not have this information so it uses a peeking process to create it. This works well except for callback functions that can be presented as either user callbacks or as standard ClearWin+ callbacks that appear in the form of literal quoted strings such as "EXIT". In order to safely disambiguate these two forms it is recommended that the winio$ argument "EXIT" be changed to CB$("EXIT") etc.. This changes "EXIT" to "CLEARWIN+EXIT".
Changes required for specific ClearWin+ format codes
Some winio$ format codes require special attention as follows...
%lw |
%lw leaves the window open (a modeless dialog). In some contexts the window may close prematurely in which case a call can be made of the form... |
%eb |
Some of the edit_info members are pointers so the corresponding array of integers must be replaced by a structure (TYPE(edit_info))
that is defined in the supplied clrwin.f95 used to create the clrwin$ module. If a NULL pointer is required it can be declared as... |
%ht |
The existing HYPERTEXT keyword can be used resource scripts. Is HTML is an alternative. |
%cw |
External WRITE/PRINT statements (for %cw) will not work directly with fx64 but it is possible to use an internal WRITE (to a character variable str, say) and then call cw_write$(unit, str). An alternative is to use %re together with an internal WRITE and then to call EditWriteLn$(hwnd, str) where hwnd is obtained from %lc. |
%og |
Stricter type checking in gFortran means that some scalar arguments (to OpenGL functions) must be changed to one-element arrays. |
%di |
has occasional limitations when using the related resource compiler. |
%gr |
Some very old (DBOS) routines have not been ported to x64. |
%pl |
Options such as [x-array] that change the number of arguments, must appear in a winio$ call rather than a winop$ call. |
In some very unusual cases, the peeking process mention above may not scan winio$ format codes correctly. In which case, %za and %zz can be added to mark the beginning and end of a Window. %za is placed at the beginning of the first winio$ format string (in a continuation sequence) and %zz is placed at the end of the last. If winio$ is called without continuation then the two codes mark the beginning and end of the single format string.
If a manifest file is used in order to provide an XP theme for the controls then it may necessaey to change the markup code in the manifest file in order to include
<assemblyIdentity processorArchitecture="*"/>
Parallel Development using FTN95
One set of source files can normally be used for both FTN95 and fx64. However, if necessary, preprocessor directives can be used in order to handle any differences. For example, the following fragment of code could be for FTN95 only...
#ifdef FOR_FTN95
integer,pointer::C_NULL_PTR=>NULL()
#endif
In this case the FTN95 command line would include: /cfpp /vparam FOR_FTN95 1
Using Plato
Translating FTN95
Here are some FTN95 intrinsics that will need translating...
Deployment
The DLL clearwin64.dll can be released free of charge.
Commercial Limitation
Development of 64 bit ClearWin+ code effectively requires an FTN95 licence from Silverfrost. Otherwise ClearWin+ error reports are not transmitted to the developer.
gFortran download
64 bit gFortran can be downloaded from https://gcc.gnu.org/wiki/GFortranBinaries by searching for mysys64.