Based on the documentation[1], it seems clear that strings are stored in Unicode (which should be UTF-16LE).

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...

The first thing to know about Microsoft documentation is it's almost always wrong.

I've been coding against the Win32 API since Windows 95. While I won't argue it's perfect, it's certainly nowhere near "almost always wrong".

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...

This is categorically incorrect. The documentation for the function is entirely accurate. What is true is that the regedit program is more than a featureless wrapper around the API functions (unlike the first thing to know about Linux desktop software). The heuristic is performed for the user who probably doesn't know what they want; the straight exactly-as-you-asked-for-it conversion is performed for the programmer who does. (And it's only a heuristic for values; the encoding for keys is assumed from the file like TFA says, but which one it is is stored in a flag bit.)

To be more precise, like most of Windows, it just stores 16-bit codepoints as such, meaning that it's not necessarily always valid UTF-16LE (in the presence of invalid surrogate pairs).