The probe table you have looks good for the I4-fit cases. Native + Wine-with-this-patch diverge on three classes I'd suggest covering: 1. `(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. 2. 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)`. 3. 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`. Test cases that would pin all three: ```c BSTR bstr9999999998 = SysAllocString(L"9999999998"); BSTR bstr3 = SysAllocString(L"3"); BSTR bstrfloat1p99 = SysAllocString(L"1.99"); BSTR bstrfloatm1p99 = SysAllocString(L"-1.99"); BSTR bstrhexFFFFFFFF = SysAllocString(L"&HFFFFFFFF"); /* (BSTR, BSTR) numeric-but-outside-I4: native overflows */ hres = pVarAnd_with(BSTR, bstr9999999998, BSTR, bstr3, &result); ok(hres == DISP_E_OVERFLOW, "expected DISP_E_OVERFLOW, got %08lx\n", hres); /* float-BSTR: truncation toward zero (not banker's rounding) */ VARAND(BSTR, bstrfloat1p99, I2, 1, I4, 1); VARAND(BSTR, bstrfloatm1p99, I2, 1, I4, 1); /* hex with sign bit: signed I4 interpretation */ VARAND(BSTR, bstrhexFFFFFFFF, I2, 1, I4, 1); ``` -- https://gitlab.winehq.org/wine/wine/-/merge_requests/8635#note_139186