Inconsistent menu handle types in module file clrwin.f95?

Module file ftn95\sources64\clrwin.f95 of Salford ftn95, version 8.30 contains subroutines add_menu_item$ and remove_menu_item$ which have menu parameters of different types. The corresponding code in clrwin.f95 is

interface
subroutine remove_menu_item$(menu) bind(C,Name='__remove_menu_item')
use ISO_C_BINDING
integer(C_INT),value::menu
end subroutine remove_menu_item$
end interface

and

subroutine add_menu_item$(menu,name,grey_control,check_control,callback)
use ISO_C_BINDING
integer(C_LONG_LONG)::menu
character(len=*)::name
integer(C_INT)::grey_control,check_control
procedure(clrwin_cb$)::callback
interface
 subroutine add_menu_item$$(menu,name,grey_control,check_control,callback) bind(C,Name='__add_menu_item')
 use ISO_C_BINDING
 integer(C_LONG_LONG),value::menu
 character(C_CHAR)::name(*)
 integer(C_INT)::grey_control,check_control
 type(C_FUNPTR),value::callback
 end subroutine add_menu_item$$
end interface
call add_menu_item$$(menu,trim(name)//C_NULL_CHAR,grey_control,check_control,C_FUNLOC(callback))
end subroutine add_menu_item$

When compiling an application using both subroutines by means of Salford's ftn95 64 bit, the menu parameters of both subroutines are of type INTEGER*8 which I would expect. When I try to compile the same application with INTEL 64 bit compiler ifort, then a warning is generated for the menu parameter of remove_menu_item$, more precisely the following one: The data type of the actual argument does not match the definition. [HANDLE] Hence, should the menu parameter

integer(C_INT),value::menu

of remove_menu_item$ not be substituted by

integer(C_LONG_LONG),value::menu

? The same would apply for some other menu routines in file clrwin.95 (delete_menu_item$ etc.).

We use file clrwin.f95 when compiling a 64 bit version of a 32 bit GUI application by means of INTEL ifort and Salford's clearwin64.dll..

Regards, Dietmar

Dietmar

Thank you for the feedback. I have amended the code for release with FTN95 v8.50.

delete_menu_item$ is correct as it is and I can't see any other HMENU values to change.

Paul,

does

integer(C_INT),value::menu

in the interface statement of remove_menu_item$ not say that I have to pass a parameter of type INTEGER*4 to remove_menu_item$? An does

integer(C_LONG_LONG)::menu

in the interface statement of add_menu_item$ not say that I have to pass a parameter of type INTEGER8 to add_menu_item$? This sounds strange to me and is not the case in the SALFORD 64 bit compile environment where I passed INTEGER8 parameters to both routines.

Could you please tell me the types I would have to call both the routines with when using the ifort compiler?

How do you explain the warning I mentioned with respect to the ifort compiler? It is the interface which I use for the ifort compiler which seems to be wrong in my opinion.

If you are interested, I could provide for an example which runs into problems at runtime, if built with the ifort compiler, but which works if built with the SALFORD compiler.

Thanks, Dietmar

Dietmar

Line 607 of clrwin.f95 is incorrect and should be

integer(C_LONG_LONG),value::menu

If you are are building your own MOD file from clrwin.f95 then you will need to change this line.

If you are dependent on the Silverfrost version of this MOD file then I will need to send it to you.

Paul,

thanks, this helped, the warning disappeared. There are other routines/interfaces in file clrwin.f95 concerning menu handles which should be changed in the same way I think.

However, there is still a run time problem in this context which I cannot explain. To make it easier I reduced my application (using some menu routines of clearwin64.dll) to the sample following.

      integer*4 i
      integer*8 handle
      i = winio$('%mn[&Window[*]]',handle)
      end

This code has been successfully compiled/linked using INTEL's 64 bit ifort compile environment with respect to clearwin64.a of Salford's 8.30 compile environment.

However, the executable does not work properly, if it tries to use Salford's clearwin64.dll , Version 8.30. When trying to execute the winio$ call, error message

Argument number 2 of winio@ should be a 64 bit integer

is displayed which I do not understand.

If I force the executable to use Salford's clearwin64.dll, Version 7.10.0 (by changing the PATH e.g.), then it works fine.

I have no idea why this happens.

Any help is welcome.

Regards, Dietmar

Dietmar

clearwin64,a is intended for gFortran. I would be surprised if it also works for Intel Fortran.

For Intel Fortran I would expect that you would need to create your own mod and object files for ClearWin+ using the supplied source code for the interfaces.

If is just possible that the latest DLL might work and this is available here https://forums.silverfrost.com/Forum/Topic/3475.

Dietmar

I have found a bug that explains the menu failure.

Here is a link to download a new clearwin64.dll for you to try...

https://www.dropbox.com/s/po9v8y6q9k4e61v/clearwin64.dll?dl=0

Dietmar

On further investigation, other similar bugs have come to light. If you have any more problems then please let me know.

Note: For the information of other users, this relates only to the use of ClearWin+ with third party compilers.

Paul,

we have created a 64 bit GUI application using INTEL Fortran linking against clearwin64.a (of SALFORD's ftn95 Version 7.10) and having created the mod and object files from the sources located in the ftn95\source64 subdirectory of the SALFORD 7.10 installation via Intel's Fortran compiler ifort).

I am not sure, if the problems I mentioned in the latter post (which were built with respect to Salford's 8.30 compile environment) would also occur when using clearwin64.a and the corresponding module and object files of Salford's 7.10 compile environment.

I will check this tomorrow.

Regards, Dietmar

Dietmar

Thanks for your reply.

clearwin64.a is built using gFortran and contains object code for the ClearWin+ module interfaces to be used when linking via gFortran. It should be redundant for users of Intel Fortran.

Paul,

I am confused now for we **need **to link against clearwin64.a when creating the corresponding executable from the code mentioned below and named dynamic_menu_0.for via INTEL ifort compile environment. We use the following comands for compiling and linking:

dynamic_menu_0.obj : error LNK2019: unresolved external symbol WINIO$ referenced in function MAIN__
clrwin.obj : error LNK2019: unresolved external symbol __do_winio referenced in function CLRWIN$_mp_STOP_WHEN_WINDOWS_CLOSE$

Here clearwin64.a is used from Salford's Fortran 7.10 compile environment. File clrwin.obj has been created by compiling the source clrwin.f95 from the source64 directory of Salford's Fortran 7.10 compile environment by means of INTEL's ifort compiler.

If removing clearwin.64.a from the link step, I get many unresolveds, e.g. WINIO$ or __do_winio ... Following error code is displayed for these two symbols:

C:\win64app\Silverfrost\ftn95\source64_ifort_11.1.072\intel64\debug\clrwin.obj
dynamic_menu_0.obj : error LNK2019: unresolved external symbol INIO$ referenced in function MAIN__
clrwin.obj : error LNK2019: unresolved external symbol __do_winio eferenced infunction CLRWIN$_mp_STOP_WHEN_WINDOWS_CLOSE$

How would I resolve these symbols if not linking against clearwin64.a?

Regards, Dietmar

Paul,

sorry I had some problems with copy and paste in my last post. So here is the code of dynamic_menu_0.for:

      integer*4 i
      integer*8 handle
      i = winio$('%mn[&Window[*]]',handle)
      end

. Here are the compiler and linker commands:

ifort dynamic_menu_0.for /debug /DINTEL64 /I C:\win64app\Silverfrost\ftn95\source64_ifort_11.1.072\INTEL64\debug /c
xilink /OUT:dynamic_menu_0.exe /debug /INCREMENTAL:NO /SUBSYSTEM:CONSOLE dynamic_menu_0.obj  C:\win64app\Silverfrost\ftn95\source64_ifort_11.1.072\intel64\debug\clrwin.obj C:\win64app\Silverfrost\ftn95\clearwin64.a

This works as expected. Removing clearwin64.a from the link command results in many unresolveds, two of which are WINIO$ and __do_winio

Corresponding error message:

dynamic_menu_0.obj : error LNK2019: unresolved external symbol WINIO$ referenced in function MAIN__
clrwin.obj : error LNK2019: unresolved external symbol __do_winio referenced in function CLRWIN$_mp_STOP_WHEN_WINDOWS_CLOSE$

Regards, Dietmar

Paul,

meanwhile I found that I could link against library clearwin64.lib (SALFORD 7.10), as well, to resolve the unresloved symbols of the previous entry.

Is clearwin64.lib meant for linking 64 bit executables via INTEL?

Regards, Dietmar

Paul,

a test application linked against clearwin64.lib of Salford 8.30 and using the new clearwin64.dll (Version 20.12.8.7) worked successfully and produced the GUI interface expected. No Runtime error any more 😃

The clrwin module and object files have been created via INTEL ifort with respect to SALFORD ftn95 version 8.30.

Thanks, Dietmar

Dietmar

Yes clearwin64.lib is the right stub library to try when linking with Intel Fortran.

As I mentioned above, there are more bug fixes on the way so if you have any further problems then please let me know.

Paul,

in the INTEL 64 bit compile environment we link a big GUI application with respect to Salford's clearwin64.dll from version 7.10 and use the corresponding clearwin64.lib for the link command (xilink).

However, this results in an error because symbol RANDOM is multiply defined:

libifcoremt.lib(for_m_irand.obj) : error LNK2005: RANDOM already defined in clearwin64.lib(clearwin64.dll)
..\p64_intel_debug\p0918w.exe : fatal error LNK1169: one or more multiply defined symbols found

Why is RANDOM defined in clearwin64.lib/clearwin64.dll? It is supplied by INTEL's ifort environment.

If we disable the RANDOM calls in our source base and link again, then the binary is created successfully.

Regards, Dietmar

Dietmar

Some linkers (such as SLINK) have a switch to allow multiple instances. Then it will use one or the other. The Intel linker might have this switch.

The FTN95 RANDOM takes a single DOUBLE PRECISION argument and you will get the same result of you use RANDOM$ instead.

Paul,

I have already tried a switch allowing multiple instances for INTEL linker xilink (the switcch is /FORCE:MULTIPLE) and it worked although this is not the preferred solution I think.

Instead I substituted function RANDOM by function RAND which works analogously (if you add module IFPORT via a use statement).

Thanks for your informations Dietmar