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.
So that dependents have more freedom in choosing versions in their dependency tree.
I've run the tests using the oldest versions allowed by the new specifiers, and they all pass.
The current release of esplugin unnecessarily requires at least unicase v2.8.1, but with that fixed, unicase v2.0.0 is fine.
It didn't work correctly for OpenMW or for additional data paths, fixing it would be significantly more complicated, and it doesn't really add any value.
Since they only contain cached values, it's reasonable to overwrite the
value with a new empty map and go from there.
This doesn't affect the lock used in the FFI layer because that protects
caller-provided state, and it doesn't change the function return types
to avoid breaking backwards compatibility.
I don't think this actually matters since evaluation just returns true and only exits early on success, but if the evaluator has side effects then it could matter.
This doesn't really have any effect, as since ghosting is disabled for OpenMW the extension is only checked when evaluating a version() function, and .omwscripts plugins don't have a version field, so there's no reason for that version() call to exist in the first place.
Unfortunately std::ffi::c_size_t is currently experimental, and if I
define c_size_t = usize myself then cbindgen doesn't recognise it
properly and makes c_size_t a typedef of uintptr_t instead of just
replacing it with size_t.
To match the types used by the actual error mappers. c_int is a type alias of i32 on the platforms that this library is used on, so there's no practical difference.
- Disable support for plugin ghosting for OpenMW, it's not clear if it's useful and it increases complexity.
- Search additional data paths in reverse order.
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.
The ubuntu-20.04 runner is due to be deprecated on 2025-02-01 and
unsupported by 2025-04-01.
The ubuntu-24.04 runner doesn't include cbindgen so install it using
apt.
Oliver Hamlet