Randy Galbraith randy.galbraith@cox.net writes:
This proposed patch addresses the concern raised by bug 824. This patch changes the handling of REG_MULTI_SZ from REG_SZ to REG_BINARY.
Do you actually have an app that depends on this? I agree that in theory we should preserve the data exactly, but this means giving up on an easily editable registry format, so it should be done only if something really needs it.
On Mon, Oct 18, 2004 at 05:29:29PM -0700, Alexandre Julliard wrote:
Do you actually have an app that depends on this? I agree that in theory we should preserve the data exactly, but this means giving up on an easily editable registry format, so it should be done only if something really needs it.
What about supporting regular C escaping rules? It would be pretty consistent with the file format, and frankly I'd expect that to be supported (speaking as a Unix user). As for processing overhead, I'd be surprised if it shows on the radar.
"Dimitrie O. Paun" dpaun@rogers.com writes:
What about supporting regular C escaping rules? It would be pretty consistent with the file format, and frankly I'd expect that to be supported (speaking as a Unix user). As for processing overhead, I'd be surprised if it shows on the radar.
It's pretty much supported already. This doesn't really solve the problem of getting rid of the terminating null (except if you want to require always specifying the null explicitly, but that's not backwards compatible).
On Fri, Oct 22, 2004 at 02:59:45PM -0700, Alexandre Julliard wrote:
It's pretty much supported already. This doesn't really solve the problem of getting rid of the terminating null (except if you want to require always specifying the null explicitly, but that's not backwards compatible).
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. <me-thinks> 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?
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.
"Dimitrie O. Paun" dpaun@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.
<me-thinks> 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.
Alexandre Julliard wrote:
"Dimitrie O. Paun" dpaun@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.
<me-thinks> 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:
hex(7):00 hex(7):01,00
Of course inside user.reg Wine has stored...
=str(7):"" =str(7):"\1"
The only way I can see of satisfying the requirements for readability & editability would be to explicitly store the length of multi-strings thusly...
=str(7),len=0:"" =str(7),len=1:"\1"
Yet still allow for an implied length when one was not supplied, such as....
=str(7):"one\0two\0three\0"
Of course this raises the question of what to do when length and data conflict...
=str(7),len=20:"small\0"
Alas, no easy answers it would seem :(
Kind regards, -Randy Galbraith
-
Alexandre Julliard -
Dimitrie O. Paun -
Randy Galbraith