Hugh McMaster hugh.mcmaster@outlook.com writes:
Signed-off-by: Hugh McMaster hugh.mcmaster@outlook.com
programs/regedit/regproc.c | 212 +++++++++++++++++++-------------------------- 1 file changed, 91 insertions(+), 121 deletions(-)
This doesn't seem to be an improvement. The registry can change while you are exporting it, you can't rely on querying things beforehand.
On Tuesday, 18 July 2017 3:18 AM, Alexandre Julliard wrote:
This doesn't seem to be an improvement. The registry can change while you are exporting it, you can't rely on querying things beforehand.
"reg query" uses the index method, although that should probably change.
For regedit, I'll keep calling RegEnumValue() until ERROR_NO_MORE_ITEMS is returned.
I'd also like to keep the call to RegQueryInfoKey(), as the return values tell us how much memory we need to allocate (at that particular time, at least). However, should we get ERROR_MORE_DATA for some reason, we can handle that case too.
Thanks for the review.
Hugh McMaster hugh.mcmaster@outlook.com writes:
On Tuesday, 18 July 2017 3:18 AM, Alexandre Julliard wrote:
This doesn't seem to be an improvement. The registry can change while you are exporting it, you can't rely on querying things beforehand.
"reg query" uses the index method, although that should probably change.
For regedit, I'll keep calling RegEnumValue() until ERROR_NO_MORE_ITEMS is returned.
I'd also like to keep the call to RegQueryInfoKey(), as the return values tell us how much memory we need to allocate (at that particular time, at least). However, should we get ERROR_MORE_DATA for some reason, we can handle that case too.
Since you have to handle that case anyway, you can start with a hardcoded reasonable size. Using RegQueryInfoKey is almost always a bug.