Unknown symbols in GUI app link

Quoted from LitusSaxonicum

The apostrophe is also a key part of the Saxon Genitive.

Can I have this month's award for pedantry please? Eddie

A fitting reward would be a plaque, engraved with Latin text that is unblemished by punctuation, a la https://i.stack.imgur.com/lMmJi.jpg .

There is another unresolved symbol which I found when linking a 64 bit GUI application, namely

DELETE_POLYGON_DEFINITION@

I wonder how to get rid of this symbol. The code sequence to create/delete the polygon is

        CALL CREATE_POLYGON@ (...)
         CALL FILL_POLYGON@(...)
          CALL POLYLINE@(...)
                  ........
         CALL DELETE_POLYGON_DEFINITION@(...)

All 4 subroutines are listed in the ClearWin+ documentation Appendix A, Functions ported from DBOS, Graphics, but only the last is marked as undefined by slink64. I know there are alternate routines, however, I wonder, how to set parameter 4 of DRAW_FILLED_POLYGON@ which is the alternate routine to DELETE_POLYGON_DEFINITION@ (which specifies the fill color using the current color mode).

Thanks for any help.

Regards, Dietmar

Dietmar, the 4th parameter for DRAW_FILLED_POLYGON@ is an integer created with a call to RGB@. I only use Win32, so it's an INTEGER*4. You call RGB@ with 3 parameters: the Red, Green and Blue components, each described with an integer in the range 0...255. RGB mode, with 24-bit colour is the default in Clearwin these days, no longer the 16 colour VGA mode.

You can specify 'ICOL' as in the documentation using say:

ICOL = RGB@ (0, 0, 0) (for black)

or just put it in the subroutine call, as in:

CALL DRAW_FILLED_POLYGON@ (IX, IY, N, RGB@(127, 127, 127) ) (grey)

You really need to update your codes to use the 'post-DBOS' graphics to future proof them.

Eddie

Dietmar

CREATE_POLYGON@, FILL_POLYGON@ and DELETE_POLYGON_DEFINITION@ belong to a set of DBOS routines that have not been implemented for 64 bits. The first two will link but will fail at runtime. These can be replaced by the single routine DRAW_FILLED_POLYGON@.

POLYLINE@ is provided (via DBOS.INS) but this just calls DRAW_POLYLINE@ which is therefore more direct.

Paul, Eddie,

thanks for your help and information.

I was a little bit confused because the only symbol out of CREATE_POLYGON@, FILL_POLYGON@ and DELETE_POLYGON_DEFINITION@ that slink64 complained about was DELETE_POLYGON_DEFINITION@.

I wondered why the alternate routine to DELETE_POLYGON_DEFINITION@ was DRAW_FILLED_POLYGON@ and thought maybe DELETE_POLYGON_DEFINITION@ would have some visual effect on the screen (like repainting the area covered by the polygon with the background or similar). And I wondered who would free the handle which I thought was still valid under 64 bit.

That's why I asked how to set the color (parameter 4) of DRAW_FILLED_POLYGON@, and Eddie answered this question. What I really meant was to which value I should set the color (e.g. the backgroud color etc.).

Later I found the semantic of DELETE_POLYGON_DEFINITION@ in the Library reference FTN77.

It turned out that DELETE_POLYGON_DEFINITION@ does not have any visual effect on the screen. Hence I think I should replace

          CALL CREATE_POLYGON@ (...)
          CALL FILL_POLYGON@(...)
          CALL POLYLINE@(...)
                  ........
         CALL DELETE_POLYGON_DEFINITION@(...)

by

      CALL DRAW_FILLED_POLYGON@(...)
      CALL DRAW_POLYLINE@(...)

where in call DRAW_FILLED_POLYGON@ and DRAW_POLYLINE@ the same colors are used as in CALL FILL_POLYGON@ and POLYLINE@, respectively.

This means that routines CREATE_POLYGON@ and DELETE_POLYGON_DEFINITION@ are obsolete in the 64 bit ftn95 compile environment. To my opinion this is a slight difference to the information given in the table of alternate routines in the ClearWin+ documentation.

Paul, could you please confirm, if my idea of code replacing mentioned above is correct?

Thanks and regards, Dietmar

Dietmar

Yes I can confirm that you are correct.

CREATE_POLYGON@ and FILL_POLYGON@ are not implemented for 64 bits. When called they produce a runtime error report. So your tests must have avoided calls to these routines.

Paul,

I am currently trying to link an INTEL64 app with clearwin64.lib/clearwin64.dll from ftn95 version 8.62.1 (internal version numer 22.3.15). The code named mymove.for is

      character*256 mybuffer_src,mybuffer_target,c,curdir$
      integer*2 n
      N=5
      mybuffer_src='abcdfghijk'
#IF SALFORD
      call  MOVE@(mybuffer_src, mybuffer_target, n)
#ELSE
      call  MOVE$(mybuffer_src, mybuffer_target, n)
      c=curdir$()
      write(*,*) 'Current Directory: ', c
#ENDIF
      write(*,*) 'mybuffer_src=',mybuffer_src(1:n)
      write(*,*) 'mybuffer_target=',mybuffer_target(1:n)
      read(*,*)  c
      end

I tried to compile it via command

ifort mymove.for /Zi /debug /fpp /DINTEL64 clearwin64.lib

, however, symbol MOVE$ remained unresolved, the corresponding error message was

mymove.obj : error LNK2001: unresolved external symbol MOVE$
mymove.exe : fatal error LNK1120: 1 unresolved externals

. The same code compiles successfully for SALFORD via command

ftn95 mymove.for /debug /link /64 /CFPP /DEFINE SALFORD 1

. Moreover if commenting/deactivating the call of MOVE$ for INTEL64 the compile is successful. Now I wonder if symbol MOVE$ might have been forgotten somewhere in the environment needed when building INTEL64 stuff making use of clearwin64.

Regards, Dietmar

Dietmar

MOVE@ is an inline FTN95 routine. It is translated directly into assembler code.

I guess that I could add it to clearwin64.dll and maybe even use the same name.

Note that FTN95 usually allows the $ as an alternative to @ so generally you don't need conditional compilation blocks like that used here.

Paul,

it would be nice if I could use MOVE$ from clearwin64.dll, for my current INTEL64 implementation uses INTEL C functionality to implement it. Would it be possible to treat other routines (e.g. LS,RS) in the same way?

Concerning your note I am confused: if I substitute MOVE$ by MOVE@ in line 8, then the **ifort **command mentioned in my post results in

mymove.for(8): error #5078: Unrecognized token '@' skipped
      call  MOVE@(mybuffer_src, mybuffer_target, n)
----------------^
compilation aborted for mymove.for (code 1)

. This is in sync with your document doc\clearwin64.txt (Using 64 bit ClearWin+ with third party compilers) where you stated

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

Compiling mymove.for with ftn95 via command

ftn95 mymove.for /CFPP /debug /link

results in

WARNING the following symbols are missing:
MOVE$                                    c:\ds\samples\salford_8.62\lgotemp@.obj

and executing mymove.exe results in a runtime error (call to missing routine _MOVE$). Regards Dietmar

Dietmar

MOVE$ will not work at the moment but routines like WINIO@ can be written as WINIO$ and this form should work for both FTN95 and INTEL.

I will aim to provide MOVE$ and at least some of the other FTN95 intrinsics.

Dietmar

I have added MOVE$ to clearwin64.dll for the next release of this DLL.

Routines like RS are more tricky because

1. the names are very simple and could easily overlap other usage and

2. the arguments can have various types.

For these routines there are standard Fortran alternatives.

  i = 8
  print*, rs(i,2), ishft(i,-2)
  print*, ls(i,2), ishft(i,2)

Thanks, Paul.

Your suggestion concerning RS and LS is exactly the way I have implemented when using clearwin64.dll of ftn95 version 7.10 for my INTEL64 build.

For clearwin64.dll of ftn95 version 8.62.1 I thought it would be a good idea to use as as many routines from the dll as possible for my INTEL64 build (rather than using my INTEL64 implementation of the routines).

Regards Dietmar