The advantages of using the built-in implementation instead of pelite are:
- It's much faster on average: for Starfield.exe (~ 100 MB) it is 2.8x
faster and 4% slower reading file and product versions respectively,
and for sfse_1_15_222.dll it is 3.35x faster and < 1% slower
respectively.
- It reduces the transitive dependency count by 8
- It uses ~ 700 lines of first-party code that only depends on the
standard library, instead of 240715 lines of unaudited third-party code
- pelite hasn't had a release in 3 years, and my PR for replacing winapi
hasn't had any response in the month and a half it's been open, so the
built-in implementation is probably less of a maintenance risk.
Using only the standard library (i.e. without pelite).
This commit keeps the pelite dependency and uses it to check that the
new parser gives the same result. The next commit will remove pelite.
I've verified that both parsers give the same result for the following
files that are referenced in the masterlists' version conditions:
Starfield.exe
sfse_1_15_222.dll
SkyrimSE.exe
skse64_loader.exe
skseVR_loader.exe
ENBHelperSE.dll
d3d11.dll
EngineFixes.dll
QuickLootEE.dll
FalloutNV.exe
nvse_1_4.dll
nvse_1_4ng.dll
nvse_1_1.dll
Fallout3.exe
fose_1_7.dll
fose_1_7ng.dll
nvac.dll
Fallout4.exe
f4se_loader.exe
f4sevr_loader.exe
place.dll
obse_1_2_416.dll
TESV.exe
skse_loader.exe
The only referenced files that I couldn't test against were SkyrimVR.exe
and Fallout4VR.exe, because I don't own those games.
To guard against calling product_version() or version() on (non-plugin) files that unexpectedly aren't executables, e.g. Starfield.exe from the Microsoft Store.
They're not reliably available and are now causing CI failures. Instead
use libloot for the test cases that used 7z, and update it because older
versions of libloot incorrectly use "ProductVERSION " instead of
"ProductVersion".
This makes the comparison between a numeric and a non-numeric release ID
more granular, by trying to parse leading digits in a non-numeric
release ID as a number and comparing it against the numeric ID. If the
two differ, their ordering is used as the ID ordering. If they're equal,
the non-numeric ID is considered greater so long as it has a non-zero
length suffix after the numeric leading digits. This means that
the version
0.78b is correctly considered to be less than the version 0.86, which
was not previously the case.
Pre-release IDs are not affected to avoid not conforming to the Semver
spec, which states that numeric pre-release IDs are always less than
non-numeric pre-release IDs. As non-numeric release IDs are not allowed
in semver, this commit's changes don't change the behaviour for semver
version comparisons.