It was only used for a single type alias that's currently usize on all platforms, so using it was overkill. This removes libc from the dependency tree on Windows, but not on Linux, though there it's only needed for dev dependencies.
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.
Oliver Hamlet
Oliver HamletandGitHub
dependabot[bot]andGitHub