If you need to do something that requires admin privileges, you should
try to do it and check for an access denied error. If it fails with
access denied, you should skip the test. (Ideally, you should try
running your test with a limited account on Windows.)

Non-admin users lack the proper access rights to change anything in HKLM, so at least on modern systems with active UAC the test won't work.

I would be more worried about the fact that it's changing a global
user preference. Maybe you should just read the key and verify that
the API matches the value there.

It's worse, to fully test both OS variants, the test would have to delete and create subkeys, since Microsoft put the value under a subkey of the name of the former value since Vista. That's nothing I'd like to do on some unsuspecting user's machine.

This is probably more depth than you should be putting into
investigating native's behavior. If it's supposed to be a boolean, and
the expected values are 1 and 0, you can assume it's one of those and
not worry about what happens if it's 256 (unless you know a real
application that sets that value).

Yeah, that's what the documentation states, too. I tested this just out of curiosity.

I'll leave it with my current code for both the implemenation and the test, and submit the patch for reviewing.