Fix for bug 824 - proper handling of REG_MULTI_SZ
randy.galbraith at cox.net
Sat Oct 23 00:30:08 CDT 2004
Alexandre Julliard wrote:
>"Dimitrie O. Paun" <dpaun at rogers.com> writes:
>>I must be missing something, but I thought regular strings can not
>>contain embedded nulls, so we can have a simple rule: don't store
>>terminating nulls for simple strings, but store them for multi-strings.
>>Aha -- you mean that if we follow this rule, all is good, but we
>>will not be backwards compatible because currently multi-strings
>>don't have the embedded nulls, right?
>Right; though the problem happens for regular strings too, they don't
>necessarily have to be null terminated. And of course it would require
>everybody editing the file to always remember to add terminating
>nulls, which is much less user-friendly than what we have now.
>>In that case, I guess we already have a versioning mechanism for
>>the registry files, so we'll just have to go to the next version,
>>and convert the old files to the new format.
>That's a major PITA, certainly not justified for such a minor problem
>that hasn't been demonstrated to cause any trouble in practice.
What does PITA stand for?
I assumed bug 824 was on the "tasklets" list because it was a
requirement for Wine 0.9 and/or 1.0. Going back to the original
comments the complaint was Wine's instance on storing the last \0
regardless. Hence certain REG_MULTI_SZ values can not be reliably
stored and retrieved...
hex(7): <-- length = 0
hex(7):01 <-- length = 1
They come out as:
Of course inside user.reg Wine has stored...
The only way I can see of satisfying the requirements for readability &
editability would be to explicitly store the length of multi-strings
Yet still allow for an implied length when one was not supplied, such as....
Of course this raises the question of what to do when length and data
Alas, no easy answers it would seem :(
More information about the wine-devel