About your last update: null byte after every byte smells badly of multibyte character encoding... IIRC, XP does Unicode - that should explain the second (always null) byte if you are dealing with standard ASCII chars. Trying to manage Regedit5 strings with Perl Unicode support should work, I guess...
Yes, I have garnered more information since that update. This is the situation:
There is more than one "REGEDIT". The older Regedt32 tool that came with Windows3.x was removed for Windows9x, but restored with WinNT and its decendants. Furthermore the regedit tool with WinXP is a very different creature than the one with 9x: it seems to combine the better features of both Regedit and Regedt32. This is "Registry Editor Version 5".
So the crucial thing is which version of Regedit are we talking about. It's not so much which Windows but which Regedit. After all, just saying "XP does Unicode" isn't stating anything particularly informative or relevent. So does NT, 2K, Me, even 98 and 95 if extra software from Microsoft is added. All M$ OSes "do Unicode" (at least potentially).
What changed with Regedit ver 5 (? - or already existed) is that there came into being a new type of string datum for .REG files, and of course you and others guessed right, it is a multi-byte character Unicode string type. So there are ANSI .REG files and Unicode .REG files.
The thing that's irritating is that even though we can create perfectly valid REG_EXPAND_SZ entries for a .REG file with Perl's help, we cannot enter them into the Registry on 95/98 because of bugs or limitations (reports vary on which this is) in the REGEDIT tool in those OSes. This goes for either ANSI or Unicode entries, BTW, no difference wrt this issue.
Soren A.
|