[PATCH v4 2/8] reg.exe: Add path_get_key() to remove boilerplate

[Jonathan Vollebregt]

>> +        if (strncmpiW(path, short_HKEY_name[i], strlenW(short_HKEY_name[i])) == 0 ||
>> +            strncmpiW(path, long_HKEY_name[i],  strlenW(long_HKEY_name[i]))  == 0)
> I don't think strncmpi(x, y, strlen(y)) has any advantage over strcmpi(x, y). strlen just counts the number of characters to the first 0 byte, where strcmpi would stop anyway.

The function takes a full key path so we can't just flat compare it to 
the root key strings - this way it stops checking for differences after 
the root key name.

>> +    path = strchrW(path, '\\');
>> +    if (!path)
>> +        return k;
> I expect that this causes trouble with RegCloseKey.

Assuming you expect errors using RegCloseKey on a predefined key like 
HCKU: In practice it works just fine. I imagine it's supposed to work 
this way since testbot doesn't throw any errors either.

> I don't think this is really an improvement. The old code first looked
> at argvW[1], then argvW[2], ..., with clear checks that the argument
> count is big enough. The new code jumps around between the arguments
> without any clear order. As a result it still isn't clear if argv[2]
> is supposed to be a registry key at all when you check it for
> remoting. While it may be true in the current form of reg.exe, it
> won't work if support for e.g. reg import is added.

I've replaced that commit with a simpler one using a function to 
sanitize the path and leaving the flow control as it is in master:
> https://github.com/jnvsor/wine/commit/25acdd930847d86022193ce4cc9cb83be32880b6

>> +static HKEY path_get_rootkey(const WCHAR *path)
>> +{
>> +    if (path_get_rootkey_name(path))
>> +        return HKEYs[(path_get_rootkey_name(path) - long_HKEY_name[0]) / MAX_ROOT_KEY_NAME_LENGTH];
> This searches the array twice.

I've also fixed the duplicate call to path_get_rootkey_name in 
path_get_rootkey, changed the seperator>separator variable spelling, and 
added more detailed commit messages.

What else was there to deal with before re-submitting or is the WCHAR* 
in array of structs issue all that's left? (Oh for a char* to WCHAR* macro!)