forums.silverfrost.com

DanRRight · Posted: Tue Aug 29, 2017 9:17 am Post subject: 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

PaulLaidler · Posted: Tue Aug 29, 2017 5:26 pm Post subject:

Thanks Dan. I have made a note of this.

PaulLaidler · Posted: Sat Dec 16, 2017 2:24 pm Post subject:

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...

DanRRight · Posted: Sun Dec 17, 2017 7:32 pm Post subject:

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.

JohnCampbell · Joined: 16 Feb 2006 Posts: 2584 Location: Sydney

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

PaulLaidler · Posted: Fri Feb 02, 2018 9:27 am Post subject:

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.

JohnCampbell · Joined: 16 Feb 2006 Posts: 2584 Location: Sydney

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.

PaulLaidler · Posted: Wed Jun 09, 2021 7:40 am Post subject:

Thanks John. I will take a look at this.

PaulLaidler · Posted: Wed Jun 09, 2021 2:17 pm Post subject:

John

It seems OK to me...

mecej4 · Joined: 31 Oct 2006 Posts: 1896

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:

JohnCampbell · Joined: 16 Feb 2006 Posts: 2584 Location: Sydney

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.

PaulLaidler · Posted: Wed Jun 09, 2021 4:42 pm Post subject:

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().

JohnCampbell · Joined: 16 Feb 2006 Posts: 2584 Location: Sydney

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.

PaulLaidler · Posted: Fri Jun 11, 2021 7:17 am Post subject:

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.