New 'listWindowsRegistry' OS API method for enumerating content of single registry subkey #1345
Conversation
There was a problem hiding this comment.
Camel case is good, we’re moving in that direction anyway. But please use it consistently: you’re using a mix of camelCase and snake_case in the C code. FWIW, I’d personally prefer getWindowsRegistry to listWindowsRegistry. And we’ll need to get the AppVeyor CI tests passing, if you get a chance to check the output and see what’s failing.
This is a nice addition, thanks so much for the contribution!
|
Found a registry value for a DWORD test which should be around there for some time already, so hopefully should make the test passing on all supported Windows versions. What do you mean by "I’d personally prefer |
src/host/os_listWindowsRegistry.c
Outdated
| typedef void (*ListCallback)(const RegNodeInfo * info, void * user); | ||
| extern HKEY get_registry_key(const char** path); | ||
|
|
||
| static const char* get_type_string(DWORD type) |
There was a problem hiding this comment.
Can you make this getTypeString?
|
Looking good. If you could rebase against the latest master branch (and if you could squash the commits too, that would be a bonus), this looks ready to merge. |
…ngle Windows registry subkey
|
Merged. Thanks for this! |
What does this PR do?
This PR is extending the 'os' API by adding new method called 'listWindowsRegistry' which returns table of all subkeys and values in the specified path. Nil is returned in the case of failure.
How does this PR change Premake's behavior?
No breaking changes, just extended API.
Anything else we should know?
Did you check all the boxes?
Yes I did with single exception. Method name is in camel-case. I did it on purpose to keep it consistent with existing 'getWindowsRegistry' method.