Build Version

With FTN95 /ver

good also to provide info about DLL/LIB build version and dates. And also if these are original build DLLs or upgraded.

Currently it shows

Silverfrost FTN95/.NET Copyright (C) 1993-2017 Silverfrost Ltd
---------------------------------------------------------------

Version:          8.10.0
Built:            Sat Feb 11 12:23:39 2017

Operating System: Microsoft .NET on Windows NT 	CPU:              Intel(R) Core(TM) i7-4770K CPU @ 3.50GHz Model 12 Step 3
CPU Features:     MMX, SSE, SSE2, x86-64

Thanks Dan. I have made a note of this.

This turns out to be a non-trivial task (at least for 64 bits which is where the future interest lies).

The FTN95 compiler is a 32 bit application whilst the easy access to the DLL version is via a function call to the 64 bit DLLs. So this information is not easy to provide via FTN95.

However, you could construct your own simple utility from...

program main
C_EXTERNAL GetLibraryVersionInfo '_GetLibraryVersionInfo'():INTEGER(7)
C_EXTERNAL GetLibraryDateInfo '_GetLibraryDateInfo'():INTEGER(7)
C_EXTERNAL GetString 'GET_CSTRING@'(REF,VAL,REF)
CHARACTER(80) info
call GetString(info, GetLibraryVersionInfo(), 80)
!Year since 1998, month, day, hour...
print*, info
call GetString(info, GetLibraryDateInfo(), 80)
print*, info
end

Thanks, Paul, hope in the future the way to trick the system will be found or this start working when compiler become 100% 64bit. We meantime will include this subroutine into our own codes just not to loose.

Paul,

I have the following code which appears to work for /64, but perhaps after reading this thread it should not.

The following bit does not work for a valid date: dll_version = scc_lib_version@ () dll_date = dos_date (ints(dll_version))

Could you suggest any changes, as I would like to get info on salflibc.dll

   subroutine echo_dll_version
!
      include <clearwin.ins>
      C_EXTERNAL SCC_LIB_VERSION@       '_scc_lib_version' :INTEGER*4
      C_EXTERNAL INITLIBRARYFILEINFO@   '_InitLibraryFileInfo'():INTEGER*4
      C_EXTERNAL GetLibraryVersionInfo@ '_GetLibraryVersionInfo'():STRING 
      C_EXTERNAL GetLibraryPath@        '_GetLibraryPath'():STRING 
      C_EXTERNAL GetLibraryDateInfo@    '_GetLibraryDateInfo'():STRING 
!
      integer   dll_version
      character str*256,    ftn95_ver*80
      character dos_date*9, dll_date*9
      external  dos_date
!
      call get_compiler_version ( ftn95_ver )
!
      dll_version = scc_lib_version@ ()
      dll_date    = dos_date (ints(dll_version))
!
      WRITE ( *,1001) trim(ftn95_ver), dll_date, dll_version
      WRITE (98,1001) trim(ftn95_ver), dll_date, dll_version
!
      WRITE ( *,1000) 'get_library_info.f90 /64'
      WRITE (98,1000) 'get_library_info.f90 /64'

      str = GetLibraryVersionInfo@ () 
      WRITE ( *,1000) '  VERSION: ', trim (str) 
      WRITE (98,1000) '  VERSION: ', trim (str) 

      str = GetLibraryPath@ () 
      WRITE ( *,1000) '  PATH   : ', trim (str) 
      WRITE (98,1000) '  PATH   : ', trim (str) 

      str = GetLibraryDateInfo@ () 
      WRITE ( *,1000) '  DATE   : ', trim (str) 
      WRITE (98,1000) '  DATE   : ', trim (str) 

      write ( *,1000) ' '
      write (98,1000) ' '
 1000 FORMAT (a,a)
 1001 FORMAT (/a/' Salford DLL code : ',a,i11/)
!
      RETURN
!
   end subroutine echo_dll_version

   character*9 function dos_date (yymmdd)
!
      integer*2 yymmdd
!
      character temp*9, label(0:12)*3
      integer*4 yy,mm,dd
      intrinsic mod
      data label / '___', 'Jan', 'Feb', 'Mar', 'Apr', 'May', 'Jun',     &
                   'Jul', 'Aug', 'Sep', 'Oct', 'Nov', 'Dec' /
!
!     yyyyyyy mmmm ddddd
      dd = iand (yymmdd,31)             ! 0-31
      mm = iand (ishft(yymmdd,-5),15)   ! 0-15
      yy = ishft (yymmdd,-9)            ! 0-127
!
      yy = mod (yy+1980,100)
      if (mm>12 .OR. mm<0) mm = 0
!
      write (temp,1001) dd,label(mm),yy
 1001 format (i2.2,'-',a3,'-',i2.2)
      dos_date = temp
      return
   end function dos_date

   subroutine get_compiler_version ( version )
      character version*(*)
      character ftn95_ver*80
!
      include <ftn95_ver.ins>
      version = ftn95_ver
   end subroutine get_compiler_version

File ftn95_ver.ins is unique to each FTN95 directory: ftn95_ver = '[FTN95/Win32 Ver. 8.20.0 Nov 17 Copyright (c) Silverfrost Ltd 1993-2017]'

John

You can get version information for salflibc64.dll and clearwin64.dll from GetLibraryVersionInfo and GetLibraryDateInfo (as above).

These two DLLs are always built at the same time and released together with the same version information. There is currently no provision for the possibility that users might try to take salflibc64.dll from one release and use it with a clearwin64.dll from a different release. In this sense users should treat them as twinned DLLs.

Paul,

Thanks for highlighting this old post. I have now rerun the code sample I posted above in 2018 using FTN95 /64.

I am using FTN95 Ver 8.64.0. the following values are reported: scc_lib_version@ () : 18387 GetLibraryVersionInfo@ () : 22.7.17.13 GetLibraryPath@ () : c:\Program Files (x86)\Silverfrost\ftn95_8.64F\CLEARWIN64.DLL GetLibraryDateInfo@ () : 5:56:36 - 22:7:2020

Based on these results:

scc_lib_version@ () is not reporting a valid dos date format expected. as bit format expected was : yyyyyyymmmmddddd I am not sure what the format is.

getLibraryVersionInfo@ () this version number is not 8.64.0 that FTN95 /ver reports, but some other version report. (text string)

GetLibraryPath@ () this is correct (text string)

GetLibraryDateInfo@ () this is probably correct (text string)

This is why I have created an <include file> and return the text string, based on what FTN95 /ver reports. My subroutine get_compiler_version provides a similar report as the F2018 intrinsic routine.

The performance of these routines could be better presented for FTN95 users.

Thanks John. I will take a look at this.

John

It seems OK to me...

get_library_info.f90 /64
  VERSION: 23.6.1.8
  PATH   : C:\CPPLIB\x64\Debug\CLEARWIN64.DLL
  DATE   : 10:53:12 - 9:6:2021

The library version is the same as from File Explorer and Properties. The PATH is right for me. The DLL was built today (9 June 2021) at 11:53 British Summer Time which is 10:53 GMT.

There is no connection between this version number and that for FTN95.

Some of the Silverfrost DLLs may not have all the version/date information filled in. For instance, using the SigCheck utility (https://docs.microsoft.com/en-us/sysinternals/downloads/sigcheck), I find:

c:\UTILS\sigcheck.exe c:\lang\FTN95V87\sdbgdll.dll

Sigcheck v2.81 - File version and signature viewer
Copyright (C) 2004-2021 Mark Russinovich
Sysinternals - www.sysinternals.com

c:\lang\ftn95v87\sdbgdll.dll:
        Verified:       Unsigned
        Link date:      7:00 PM 12/31/1969
        Publisher:      n/a
        Company:        n/a
        Description:    n/a
        Product:        n/a
        Prod version:   n/a
        File version:   n/a
        MachineType:    32-bit

The other Silverfrost DLLs have the missing pieces filled in, except the Link date. I don't know if it matters that any of the entries shown above are not filled in or are incorrect.

No Paul,

The version is not '23.6.1.8' It is 8.7.?? FTN95 /ver gives what should be reported as the version. Anything else is just confusing and wrong.

mecej4 Version information has recently been added for some applications such as the C++ compiler and SLINK64 but there are still exceptions.

John I am missing something here. GetLibraryVersionInfo@ provides the library version number, not the FTN95 version. The compiler version is provided via the iso_fortran_env standard intrinsic compiler_version().

Paul,

My problem is with the different version stamps of GetLibraryVersionInfo@ and FTN95 /ver. I expect them to be the same. If I am asking the question are ftn95.exe and CLEARWIN64.DLL the same version, what is provided does not really help.

However, I have now upgraded my Ver 8.64 to 8.74, using the latest downloads (and an earlier download of iso_fortran_env) I find that compiler_version is working, which is a great improvement.

So the advise is now, if you are using ver 8.7+ then the iso_fortran_env standard intrinsic compiler_version() is available and tidies up most of these issues.

John

The library that is in the DLLs is not only used by FTN95. It is used by SCC and other Silverfrost utilities. Moreover, the the library is often compatible with non-contemporary versions of FTN95. Added to that, library updates are often available between main releases of FTN95.

So, although it is a nice idea, I would hesitate to go down that route.

But the three main DLLs are always released together and have the same version number.