I did a bit of experimentation on this too and we think it has a heuristic to guess encodings of strings. (Which to be fair isn't a terrible idea - it's very easy and almost entirely reliable to determine if a string is ASCII/UTF-8 or UTF-16LE which are the major encodings found.)
If the data has the REG_SZ, REG_MULTI_SZ or REG_EXPAND_SZ type, and the ANSI version of this function is used (either by explicitly calling RegGetValueA or by not defining UNICODE before including the Windows.h file), this function converts the stored Unicode string to an ANSI string before copying it to the buffer pointed to by pvData.
[1]: https://docs.microsoft.com/en-us/windows/win32/api/winreg/nf...
Anyway, where in the hivex code do you handle these non-Unicode encoded REG_SZ values?
Btw, the comment for hivex_value_multiple_strings is based on a mistaken interpretation of the documentation. There's nothing contradictory to what MoveFileEx does[1], it simply has a list with a single entry in the case of deletions, and a list with two entries in case of renames.
The REG_MULTI_SZ documentation[2] just points out, correctly, that you can't have a zero-length string within a list of other strings (ie with at least one non-empty string after it). This is of course obvious and hence redundant, but they highlight it for novice programmers.
[1]: https://docs.microsoft.com/en-us/windows/win32/api/winbase/n...
[2]: https://docs.microsoft.com/en-us/windows/win32/sysinfo/regis...
One of the critiques in this article is that, because you have to know/guess/assume what encoding is used for various strings, there isn’t one for the registry, either.
If so, both approaches suffer from that (but Unix a bit more because it tends to store multiple items under a file system ‘key’, while Windows programs rarely store multiple items under a single registry key)
I do wonder what RegEdit.exe does here. Does it infer encoding, have a long list of key-to-encoding mappings, or a combination of the two?