demerphq wrote:
Can you please clarify what you mean with NT (XP+) based registries?
Ive used Win32::TieRegistry on Win2k and on XP without problems....
---
Win32::TieRegistry is safe for user-created keys, provided they
stay within your local DOS codepage.
Win32::TieRegistry isn't safe for use on *arbitrary*, *pre-existing*
keynames and valuenames as they may contain ~ 2.0039 classes of names not
supported by the 8-bit key handling names:
1) names outside outside your local "codepage" (this will vary by country and
may not exist for some languages requiring more than 8-bit glyphs to
be written, i.e. chinese, korean, japanese, etc.)
2) 16-bit "characters" not in Unicode; ex. 16-bit values 0xfffe, or
non-conforming uses of 16-bit Unicode surrogate "lead-in"s that would normally
describe Unicode characters in the range U+0x10000 and above.
.0039) The rare (thus small "class #") case of non-Win32 strings
containing Null's that are created by rootkits or other special-use
software (.0039 ~= 1/256 + 1/65536; ;-} ).
Isnt this just a matter of caveat emptor? If you are messing around
with the registry you better know what you are doing.
Perls philosophy has always been explicitly to give the programmer
sufficient rope that they can hang themselves. Why do you think that
what youve outlined should be treated differently?
---
_IMO_, "adequate" rope would be handling "case 1" above -- i.e.
simply, Internationalized strings as names.
"Sufficient" rope would also, at least, handle "case 2" above:
keynames that fall into this category can't be manipulated or converted
safely into standard Perl strings, so displaying, referencing or
encoding them isn't something you can do with a UTF-8 or any Unicode string.
True "hanging" length would special-case handle embedded NULLs, since
these can only be manipulated through the native NT-API and will generate
an error when an attempt is made to access them via normal methods (like
regedit). I.e. -- in classic "hanging" sense, you would be able to create keys
that standard registry tools couldn't delete (though could be deleted through
a, "hanging-enhanced", version of the Registry API).
So the module needs a notice that says "Be aware that this module
isn't suitable for storing unicode data in the registry safely."?
---
See exception list above? :-) Than and make note that NT-based
registry names may contain any 16-bit character other than BackSlash ("\").
To make an analogy:
One could create a registry API that handles all registry keys
containing any string of hex characters, including "0-9", "A-F" and "a-f".
Someone encountering such an API _might_ be surprised or find the
API restrictive if they found that an actual registry might contain many names
that are able to be referenced using the API. They might find this more
surprising in a "Core" Perl API, as Perl,
1) is often used for general system maintenance tasks,
2) has built-in Unicode (via UTF-8) support and,
3) is used to work with binary data (not just a Unicode or
ASCII subset).
FWIW, I don't regard non-support of "NULL"-containing strings to be a
big issue since it isn't part of the Win32 interface and such keys can't even be
addressed with Window's native registry tool, "RegEdit".
From the MS Win32 documentation (ex.
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/sysinfo/base/registry_functions.asp
) a programmer would expect wide character support:
"Implemented as RegCreateKeyExW (Unicode [sic]) and
RegCreateKeyExA (ANSI). Note that Unicode support on Windows
Me/98/95 requires Microsoft Layer for Unicode."
That Perl's "Core" registry routines don't provide the same
functionality on NT based systems, would violate the principle of
least surprise.
I'm not trying to say such support needs to go in right now -- just
that I'm uncomfortable with a modern perl providing only "legacy",
win9x-compatible registry support in it's "Core" routines.
Linda
