Review: I contemplated ignoring ret/err here entirely, however, in my testing it seems this function usually returns S_FALSE (1). Since I can't find documentation for this behavior, we allow S_OK too. Given positive error values, limiting this to negative doesn't make sense to me: https://learn.microsoft.com/en-us/windows/win32/seccrypto/common-hresult-values

Values like 0x80004001 are negative when interpreted as a signed 32 bit integer because they are encoded in two's compliment

S_FALSE is a "success" code, so I think it's still fine to check ret<0 for in general.

In this specific case, Windows docs say that there is no return value, so my guess is that the Windows syscall libraries, or perhaps the Windows kernel itself is writing S_FALSE for this procedure to indicate that it's not an explicit "OK" because the call has no return value.

We could just drop the whole error handling block here and cite the docs that say this procedure doesn't return any values.

Values like 0x80004001 are negative when interpreted as a signed 32 bit integer because they are encoded in two's compliment

True, however the return value from Call is an uintptr and this ret wasn't being cast to 32-bit. As such the ret < 0 was nonsensical. I don't know enough about Windows syscall internals to know if we can always cast it, that would assume a syscall always returns HRESULT (maybe it does).

In this specific case, Windows docs say that there is no return value, so my guess is that the Windows syscall libraries, or perhaps the Windows kernel itself is writing S_FALSE for this procedure to indicate that it's not an explicit "OK" because the call has no return value.

Sounds plausible, this value is at least not coming from Go and Windows does define success as a positive 32-bit integer.

We could just drop the whole error handling block here and cite the docs that say this procedure doesn't return any values.

I would still like to keep it, just in case. Unless we can confirm that this syscall can't fail in some way or form.

Changed this to int32(ret) < 0 now, to be more generic and self-documenting via a new func winerrorFailed(r1 uintptr) bool function.

Values like 0x80004001 are negative when interpreted as a signed 32 bit integer because they are encoded in two's compliment

S_FALSE is a "success" code, so I think it's still fine to check ret<0 for in general.

In this specific case, Windows docs say that there is no return value, so my guess is that the Windows syscall libraries, or perhaps the Windows kernel itself is writing S_FALSE for this procedure to indicate that it's not an explicit "OK" because the call has no return value.

We could just drop the whole error handling block here and cite the docs that say this procedure doesn't return any values.