@the-trooper, this issue arises for other applications too and does not appear to be an issue with the GlassWire User Interface.
It is hard to see where the version numbers are derived
If you look at the version numbers GlassWire uses it is difficult to see where they are being derived:
- The executable image File Version? Not used for all applications - but appears to be for Waterfox
- The executable image Product Version? Doesn’t appear to be used at all.
- The registry Display Version for the installed application? Not used for all applications - but appears to be for
CCleaner
- Somewhere else or in some other way? GlassWire probably gets the data from somewhere else as 360 Total Security didn’t match any of the above options. However, GlassWire might use more than one method to determine the version, which could explain the “inconsistency”.
Waterfox is an example where the complete version is displayed by GlassWire e.g. 48.0.1.6070
The executable file properties show that the version GlassWire uses matches the File Version 48.0.1.6070 but not the Product Version 48.0.1:
The Product Version does match the Display Version for the installed application in the Windows registry, i.e. 48.0.1
CCleaner is an example where the complete version is not displayed by GlassWire
The executable file properties show that the version GlassWire uses does not match the File Version or the Product Version, i.e. 5.20.00.5668:
GlassWire does match the Display Version for the installed application in the Windows registry, i.e. 5.20:
360 Total Security is a more complicated example where the the complete version number is displayed by GlassWire but is different than the executable file properties
The difference in the revision numbers doesn’t matter much in practice because Microsoft say that:
Assemblies with the same name, major, and minor version numbers but different revisions are intended to be fully interchangeable
The executable file properties show that the version GlassWire uses does not match the File Version or the Product Version i.e. 8.8 versus 8.8.0.1001:
Interestingly enough, the version that 360TS displays itself is 8.8.0.1020.
This is also the Display Version stored in the Windows registry for the installed application, i.e. 8.8.0.1020:
Process Explorer displays it as different again 8.8.0.1001:
FYI, Windows executable version numbering
Here’s how Microsoft expects version numbers to work:
Version numbers consist of two to four components: major, minor, build, and revision. The major and minor components are required; the build and revision components are optional, but the build component is required if the revision component is defined. All defined components must be integers greater than or equal to 0. The format of the version number is as follows (optional components are shown in square brackets ([ and ]):
major.minor[.build[.revision]]
The components are used by convention as follows:
Major: Assemblies with the same name but different major versions are not interchangeable. A higher version number might indicate a major rewrite of a product where backward compatibility cannot be assumed.
Minor: If the name and major version number on two assemblies are the same, but the minor version number is different, this indicates significant enhancement with the intention of backward compatibility. This higher minor version number might indicate a point release of a product or a fully backward-compatible new version of a product.
Build: A difference in build number represents a recompilation of the same source. Different build numbers might be used when the processor, platform, or compiler changes.
Revision: Assemblies with the same name, major, and minor version numbers but different revisions are intended to be fully interchangeable. A higher revision number might be used in a build that fixes a security hole in a previously released assembly.