Unknown symbols in GUI app link

We are porting a GUI Application from 32 bit to 64 bit using ftn95 version 8.10.0. When linking the 64 bit executable it turns out that several symbols are missing, e.g. RELEASE_SCREEN_BLOCK@ RESTORE_SCREEN_BLOCK@ PCX_TO_SCREEN_BLOCK@ SCREEN_BLOCK_TO_PCX@ GET_SCREEN_BLOCK@ CREATE_SCREEN_BLOCK@ GET_MOUSE_POSITION@ RECTANGLE@ DRAW_TEXT@ DELETE_POLYGON_DEFINITION@ POLYLINE@ FILL_POLYGON@ CREATE_POLYGON@ FILL_RECTANGLE@ GET_MOUSE_BUTTON_PRESS_COUNT@ TEXT_MODE@ GET_GRAPHICS_RESOLUTION@ GET_GRAPHICS_MODES@ VGA@ DRAW_LINE@ This did not occur when linking the corresponding 32 bit binary.

Now we tried to get rid of the problems with symbols DRAW_LINE@ and GET_GRAPHICS_MODES@ by adding the lines

      C_EXTERNAL DRAW_LINE@ '__win_draw_line'(REF,REF,REF,REF,REF)
      C_EXTERNAL GET_GRAPHICS_MODES@ '__win_get_graphics_modes'(REF,REF,
     *REF,REF,REF)

to the code (having had a look into file dbos.ins of the ftn95 installation). We first added these lines to small test examples where it worked ok meaning that we got rid of the missing symbols and had no other symbol missing.

However, when doing the same to our GUI code, we got rid of the symbols DRAW_LINE@ and GET_GRAPHICS_MODES@, but there were two other symbols missing, namely __WIN_DRAW_LINE and __WIN_GET_GRAPHICS_MODES.

We have no idea, why this happens to our GUI code and **not **to our small test examples and would be grateful for any hint. Maybe it is the size of the GUI app which is much bigger than the sizes of our test examples.

Now we substituted symbol DRAW_LINE@ by DRAW_LINE_BETWEEN@. This helped in so far that we could display a first polygon with our GUI appplication.

However, we do not know how to proceed with symbol GET_GRAPHICS_MODES@.

We did not yet think about how to proceed with all the other missing symbols mentioned above.

Regards, Dietmar

Dietmar,

There's a whole section in the help file about 'Functions ported from DBOS' under the Clearwin+ general heading. Some of them got straight replacements when FTN77 moved from being a DOS-extended system to being Win32. I was only a boy then, and now I am an old age pensioner! (Well, not quite).

There is also a table of alternative functions.

Eddie

Most of these routines require the line 'include 'dbos.ins' when compiling for 64 bits. Let me know if there are any still missing.

Paul,

my concern was not only the problem that the symbols were missing, but that including DCOM.INS works for some symbols in small examples but does **not **for the big GUI appication we would like to port.

Following sample works:

      include <DBOS.INS>
      integer*4 j
      
      j=GET_WKEY1@()
      
      write(*,*) 'GET_WKEY1@: ', j
      
      end

However, including DBOS.INS in the big GUI application still leaves the symbol GET_WKEY1@ undefined in the link step. Do you have any idea why this might happen?

Following symbol is still missing, too: GET_MOUSE_POSITION@ It is not contained in the dbos.ins file.

Regards, Dietmar

Dietmar

You should add 'include <dbos.ins>' to every routine that calls get_wkey1@.

I will add GET_MOUSE_POSITION@ to dbos.ins for the next release.

In the meantime you can edit dbos.ins and add

      C_EXTERNAL GET_MOUSE_POSITION@ '__get_mouse_position'(REF,REF,REF)

Paul,

I am sorry, but the problem with get_wkey1@ was on my side for I copied the dbos.ins include to the wrong file/routine. Sorry for that.

Regards, Dietmar

Paul,

routines set_mouse_bounds@ and set_mouse_position@ are missing, too. I tried to add lines

      C_EXTERNAL SET_MOUSE_POSITION@ '__set_mouse_position'(REF,REF)      
      C_EXTERNAL SET_MOUSE_BOUNDS@ '__set_mouse_bounds'(REF,REF,REF,REF)

to file DBOS.INS but this did not help but produced the error

The following symbols were not defined:

__set_mouse_position __set_mouse_bounds

(unless I did not create any error with copying DBOS.INS to the wrong location 😃

Thanks for the information to include DBOS.INS, which helped in several cases.

Regards, Dietmar

Dietmar

SET_MOUSE_BOUNDS@ is redundant. It no longer does anything. You can comment it out or provide a dummy routine that is empty.

SET_MOUSE_POSITION@ was not being exported by clearwin64.dll. Your interface is correct.

I have added the required export and a new set of DLLs is available for download via...

https://www.dropbox.com/s/xhk4ofgp5g5xcpn/newDLLs6.zip?dl=0

This thread provides food for thought, as clearly Dietmar’s application has its roots in DBOS FTN77, or maybe early Clearwin.

In the helpfile, under** ‘Functions ported from DBOS’ **a category of functions is listed as ‘Functions which have no operation or are not useful under ClearWin+ but can be left in old programs that have been ported from DBOS’. I’ve never delved far into this section, and when I’ve done so, I initially saw routines that had been superceded. However, on deeper investigation I do see routines that would be useful. For example:

SET_MOUSE_BOUNDS@

I can see immediate application for that, although in a DBOS context they are screen coordinates, but in a %gr they would be pixels in the region. It isn’t the only one: although one can draw polygons in the Clearwin+ routines, combining them and/or moving them seems a facility worth having.

I can’t see an immediate application for some functions, e.g.

GET_MOUSE_BUTTON_PRESS_COUNT@

other than as a measure of user impatience or frustration (!), but I’m sure there is a serious application for it. Other routines have clear equivalents in the ordinary set of graphics functions, e.g.

SET_MOUSE_GRAPHICS_CURSOR@

and they can be considered truly obsolete.

SET_MOUSE_BOUNDS@ in particular does not have an equivalent in the ‘Table of alternative routines’, and I suppose that if it actually does nothing, then my perception of its potential usefulness is sadly wrong. What a pity.

It does occur to me that it would be useful to elevate some of these functions to the ‘Graphics’ section of ‘Clearwin+’ in the helpfile, and to mention the replaced function names as obsolete aliases where appropriate, as that would facilitate someone searching for meaning in old code, and it might be more helpful to retitle ‘Functions ported from DBOS’ to ‘Obsolete functions from pre-Windows graphics’.

More to the point, it would seem useful to reflect on the functions once in DBOS graphics to see what might usefully be re-implemented.

Eddie

Don't forget that this particular documentation was written for users porting from (32 bit) DBOS to (32 bit) Windows NT and that was a long long time ago.

What happened to my post?

John, get your copy here: http://www.silverfrost.com/manuals/clearwin.pdf

Symbols are missing because of the fonts on your PC - they may show in the document.

Eddie

There is this document too John:

C:\Program Files (x86)\Silverfrost\FTN95\doc\cwplus.enh

Beat me to it, Simon.

Clearwin.enh is in the installation 'Docs' folder: the online version may be the latest one, and if you don't have the latest compiler release, then there may be a point of two of difference.

Eddie

John,

You are reading a bit of documentary archaeology! The Supplement is the* Clearwin+ Fortran Edition* manual. The latter evolved through several versions from the former. Simon's suggestion of looking in the .ENH file was for a source of additional info.

Eddie

Hello,

one more remark concerning the symbol

DRAW_TEXT@

for which the numbers of parameters changed from 4 to 5 (compiler WARNING - SUBROUTINE DRAW_TEXT@ has been called with too few arguments).

I do not know the interface for the 'new' routine DRAW_TEXT@, however I have learnt that I could use DRAW_CHARACTERS@ instead from one of the pdf files mentioned above.

Maybe it is worthwhile knowing the interface of the 'new' DRAW_TEXT@ , too.

Regards, Dietmar

Dietmar

I think that there are two things that need fixing here.

1. dbos.ins needs changing to

      C_EXTERNAL DRAW_TEXT@ '__win_draw_text'(INSTRING,REF,REF,REF)
   

2. __win_draw_text is not exported correctly from clearwin64.dll.

It should have four arguments. The recommended change is to use DRAW_CHARACHERS@ instead.

You could change dbos.ins but I think that DRAW_TEXT@ will still fail because of (2).

Yes,

I have substituted DRAW_TEXT@ by DRAW_CHARACTERS@ in my GUI app code and this worked fine 😃

For those who are interested: in a remark which I made previously in this post I wondered that a small example containing symbol GET_WKEY1@ could be compiled/linked using ftn95/slink64, our big GUI example, however, left symbol GET_WKEY1@ unresolved. Although meanwhile this problem is solved, I found that you use character ' in C_EXTERNAL definitions of file dbos.ins (ftn95 Version 8.10). When I looked at file clearwin.ins of ftn95 Version 7.10 I saw that C_EXTERNAL definitions of file clearwin.ins used character ' instead. What was the reason for this?

Regards Dietmar

There is no reason for this. You can use either single or double quotes. Perhaps clearwin.ins was written when FTN77 was still in use. dbos.ins was written within the last few months and double quotes was just a random choice. Hopefully, if there are any FTN77 users still around then they won't be porting to 64 bits.

In real life, double quotes allow you to avoid confusion when using the apostrophe for the Saxon Genitive or word contractions without ambiguity.

In programming, being able to use single or double quotes enables use of the other in character strings , but degrees, minutes and seconds are still difficult, as in:

'°  ''//'  ''

(similar for feet and inches)

Still not simple, especially when reading it years after writing the code.

Using both types of quotes is one of the things a committed Fortran-77 user is most likely to pick up and adopt, along with inline comments.

It depends if it is a character constant or in a format statement.

''',''' will only work in a format statement, and would have to be '''//''' in a character - this would work in a format statement too.

I think that '''' would work anywhere, as it is the first character that must be matched to the end of the string.

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

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

Eddie