Bug in Agetfileversion() ?

[JackTheC]

AGETFILEVERSION(ArrayName, cFileName)

I have downloaded some files where the manufacturer/developer has made a mistake in the version details of the file properties.
The File Version is 87 (being the last version) but the Product Version mistakenly still reads 86.
I mean it actually states 87 and 86 in Windows Explorer file properties.

In VFP's Agetfileversion() you should be able to read both versions in an array, elements 4 and 11.
But both 4 and 11 say it's version 86. So it seems the Agetfileversions() doesn't actually read the File Version.

 

[Chris Miller]

No, there is no bug in AGETFILEVERSION. It just works on an EXE, so the obvious reason is you're not checking the EXE you think you check. I'd recommend to specify the EXE parameter as full path, not relying on current path or SET PETH.

Chriss

 

[JackTheC]

Nope. I tested on several computers, Windows 8.1 and Windows 10 with fullpath to the exe. Agetfileversion also works on other type of files like DLL by the way. And with the same strange outcome.

I tested a bit more. Literally the first file I took from my C:\Windows folder gave an even stranger result:
It was jview.exe, a Microsoft file I couldn't find on my other computers but it seems to be a Microsoft Command Line Interpreter for Java.

Windows explorer says:
File version=4.79.0.2339 and Product version=4.79.2404.

AgetFileversion reports: Element 4: File version 4.79.2660 !!! Where does that come from?
Element 11, Product version is right 4.79.2404

It looks like VFP uses another source for element 4, file version than Windows Explorer.
Element 11, Product version no discripancies yet.

If you want to test it with the original 86/87 files you can download and install version 87, 32 bit, of the Iron Browser from SRWARE.NET.

https://www.srware.net/iron/

chrome.exe and chrome.dll (in "C:\Program Files (x86)\SRWare Iron\") and many other files have this 86/87 difference.

Maybe it has something to do with 32 bits programs. It occurs on 32 and on 64 bit computers. When Windows shows different file and product versions, Agetfileversion() shows the product version in element 4 instead of the file version. Most of the time, but not always like in the jview example.
In the meantime I also found this behaviour in the 64 bit C:\Program Files\ folder in DLL's from companies like Google and Avast.

 

[JackTheC]

I think I got it:

I found a website that shows all kind of file information if you upload your file for examination:

https://www.metadata2go.com/

This site shows that there are 4 kind of versions in a file:
A. File version number ---> (4 numbers)
B. Product version number ---> (4 numbers)
C. File version ---> (String composed by the maker)
D. Product version. ---> (String composed by the maker)

The numbers in A and B are put together in a string and formatted depending on the program that you use to show these versions.

Windows Explorer shows A as File Version and D as Product Version
Agetfileversion() shows C as File Version and D as Product Version.

And indeed in Jview.exe:
A and B are 4.79.0.2339
C = 4.79.2660
D = 4.79.2404

So VFP uses another source for the File Version than Windows.

I just found a file with a different Product Version number (B) that is neither shown in Windows Explorer nor in Agetfileversion. Only to be found through that website mentioned above or with a Windows API,

https://docs.microsoft.com/en-us/windows/win32/api/winver/nf-winver-getfileversioninfoa