`(BSTR_numeric_over_I4, BSTR_anything_numeric)` — native errors with `DISP_E_OVERFLOW`, current patch silently returns wrong results because the BOOL fallback fires when the BSTR is too big to widen and the other side later bumps `resvt` to `I4`. E.g. `"9999999998" AND "3"` returns 3 here, native overflows.
Added implementation.
Fractional BSTRs use truncation toward zero on native, not banker's rounding: `"1.99" AND 1 = 1` and `"-1.99" AND 1 = 1` natively. Could compute the I4 directly from the parsed `d` (e.g. `(LONG)d` after the `VarR8FromStr` succeeds, when `d` fits I4) instead of round-tripping through `VariantChangeType(BSTR -> I4)`.
I added test cases: 1.49 and 1.59. No changes for now, (LONG)d is used for I4 cases.
Hex BSTRs with the sign bit set: native treats `"&HFFFFFFFF"` as signed `I4(-1)` and computes `-1 & 1 = 1`. Currently `VarR8FromStr` returns the unsigned value `4294967295`, the fits-in-I4 check fails, and the conversion overflows. Maybe special-case `"&H..."` via `VarI4FromStr`.
The Var**FromStr functions all rely on VARIANT_NumberFromBstr. Special handling may be needed for cases such as "&HFFFFFFFF". -- https://gitlab.winehq.org/wine/wine/-/merge_requests/8635#note_139349