Unknown subroutines

Unfortunately the current developer version of clearwin64.dll is not entirely compatible with the last release of FTN95.

Here is a link to the most recent pre-release of the DLLs but

1. the next full release is expected very soon so perhaps you should wait
2. make sure that you backup the existing DLLs before installing the new ones from the link.

https://www.dropbox.com/s/auq9iun0eetwx4h/newDlls18.zip?dl=0

The following code will now work in the next full release...

      CHARACTER*80 line
      INTEGER*2 lc
      CALL GETCL@(line,lc)
      print*, lc
      print*, ':'//trim(line)//':'
      END  

Hi Paul,

these new DLLs lead to a message of my antivirus program:

It has found HEUR/APC (Cloud) and removed salflibc64.dll from the installation directory.

So I will restore the original dlls of FTN95 8.05.

Subroutine CMNAMR seems also to be undefined to 64bit.

The UPCASE problem is solved. In my project I had used CALL UPCASE as well as CALL UPCASE@. Subroutine UPCASE was known for the 32bit linker, but not for SLINK64. I have now changed everything to CALL UPCASE@.

Does CMNAMR@ work? On my machine it is exported by clearwin64.dll.

Yes, CMNAMR@ is working!

SLINK64 has now been extended in order to accept .ocx and .drv files.

Users of version 8.10 of the compiler can download and try the new SLINK64 from...

https://www.dropbox.com/s/h415kgbt92zq5tm/Slink64.zip?dl=0

Please keep a backup of the original SLINK64.

When linking hhctrl.ocx use something like...

SLINK64 lo c:\windows\sysnative\hhctrl.ocx

I have installed the FTN95 Personal Edition 8.10 now, but SLINK64 does not accept HHCTRL.OCX:

SLINK64 D:\FORTRAN64\NETDRAW3\MAKE\NDRW_LI64.LNK [SLINK64 v1.8, Copyright (c) Silverfrost Ltd. 2015-2017] ***SLINK64 does not know what to do with file D:\FORTRAN64\NETDRAW3\LIBRARIES64\HHCTRL.OCX

Also the following symbols are still undefined:

RELEASE_BITMAP_DC@ CLEAR_BITMAP@ FILL_RECTANGLE@ NEW_PAGE@

v8.10 does not include the SLINK64 that accepts .ocx files. You still need to use the download mentioned above.

The 64 bit hhctrl.ocx is normally available in the standard system folder accessed using 'sysnative' as recommended above.

RELEASE_BITMAP_DC@ is in clearwin.ins CLEAR_BITMAP@ is in clearwin.ins FILL_RECTANGLE@ is in dbos.ins NEW_PAGE@ is in dbos.ins

In my source code I have called USE MSWIN ans I thought this would include also clearwin.ins and dbos.ins. All these functions where found with FTN95 7.xx.

I have downloaded and installed SLINK64 and it finds HHCTRL.OCX. So this problem is solved.

Thanks Paul.

In my subroutine calling NEW_PAGE@ I have inserted

include <dbos.ins>

Now SLINK64 finds NEW_PAGE@, but SLINKS reports:

WARNING the following symbols are missing: __win_new_page

I don't understand these differences between SLINK and SLINK64.

'include <dbos.ins>' is only for 64 bits. If you want to compile for both 32 bits and 64 bits then you will need something like the following conditional compilation instructions...

CIF(_WIN64) INCLUDE <dbos.ins> CENDIF

You will also need /FPP on the FTN95 command line.

This is working now.

But for me it seems to be a workaround. Or is there any reason why dbos.ins isn't included automatically, like in 32-bit mode?

I compile my existing sources as well in 32-bit as in 64-bit to detect problems and differences. And there are still a lot of problems and differences.

My main program is a software to calculate power flow conditions in electrical networks and as I see now, the 32-bit solution fails for my test example in calculation and the 64-bit solution calculates exact results.

The last time the 32-bit solution calculated exact results was when I used FTN95 7.xx.

Because there is a lot of mathematics behind I'm not sure how to find the reason of that wrong calculation.

dbos.ins contains very old routines that were usually replaced when porting from the DBOS operating system to Windows NT (20 years or more ago). Some of them are redundant, some have simple alternatives, some have been renamed.

These routines are 'hard-wired' into salflibc.dll so they don't need an interface for Win32. In theory I guess that they could be 'hard-wired' into salflibc64.dll but the work-around seems like a reasonable compromise.

Hey Paul,

INCLUDE <DBOS.INS> solves the problems with NEW_PAGE@ and FILL_RECTANGLE@

But adding INCLUDE <CLEARWIN.INS> to solve the problem with CLEAR_BITMAP_DC@ and RELEASE_BITMAP_DC leads to a lot of error message when compiling. I think the reason is USE MSWIN which contains 'use clrwin'.

1/0033) INTEGER4 CW_HANDLE *** CW_HANDLE has already been declared in MODULE CLRWIN (In include file C:\Program Files (x86)\Silverfrost\FTN95\include\CLEARWIN.INS) 1/0034) PARAMETER (CW_HANDLE=7) *** PARAMETER CW_HANDLE has been referenced before it's definition (In include file C:\Program Files (x86)\Silverfrost\FTN95\include\CLEARWIN.INS) *** Duplicate definition of PARAMETER CLRWIN!CW_HANDLE 1/0035) INTEGER4 Y_PERMANENTLY,Y_TEMPORARILY,Y_NEVER *** Y_PERMANENTLY has already been declared in MODULE CLRWIN (In include file C:\Program Files (x86)\Silverfrost\FTN95\include\CLEARWIN.INS) 1/0036) PARAMETER (Y_PERMANENTLY=Z'0'L,Y_TEMPORARILY=Z'1'L,Y_NEVER=Z'2'L) *** PARAMETER Y_PERMANENTLY has been referenced before it's definition (In include file C:\Program Files (x86)\Silverfrost\FTN95\include\CLEARWIN.INS) *** Duplicate definition of PARAMETER CLRWIN!Y_PERMANENTLY *** PARAMETER Y_TEMPORARILY has been referenced before it's definition *** Duplicate definition of PARAMETER CLRWIN!Y_TEMPORARILY *** PARAMETER Y_NEVER has been referenced before it's definition *** Duplicate definition of PARAMETER CLRWIN!Y_NEVER 1/0038) INTEGER*4 CURSOR_ARROW,CURSOR_IBEAM,CURSOR_WAIT,CURSOR_CROSS, & 1/0039) &CURSOR_UPARROW,CURSOR_SIZE,CURSOR_ICON,CURSOR_SIZENWSE, & 1/0040) &CURSOR_SIZENESW,CURSOR_SIZEWE,CURSOR_SIZENS
*** CURSOR_ARROW has already been declared in MODULE CLRWIN (In include file C:\Program Files (x86)\Silverfrost\FTN95\include\CLEARWIN.INS) 1/0042) PARAMETER(CURSOR_ARROW = 32512) *** PARAMETER CURSOR_ARROW has been referenced before it's definition (In include file C:\Program Files (x86)\Silverfrost\FTN95\include\CLEARWIN.INS) *** Duplicate definition of PARAMETER CLRWIN!CURSOR_ARROW *** Too many errors

What can I do now?

Paul,

I have solved the problem with CLEAR_BITMAP_DC@ and RELEASE_BITMAP_DC@:

In some of my subroutines there was no call of USE MSWIN. I have added this line and it works. I wonder why it worked before without this call.