Re^2: possible perl bug or, at least, Win32::[TieRegistry|Registry] bug with difficult keynames (limitation)

Someone else already had a version similar to mine that printed the error values. The error value didn't seem to make much sense:

ERR: open CUser\AppEvents\Schemes\Apps\.Default\AppGPFault\current0?: 
+The system
 could not find the environment option that was entered
[download]

The problem may be that the TieRegistry routines can't handle MS UCS-16 characters -- i.e. perhaps, somehow, such characters are being returned. I know that UTF-16 encoding doesn't require the 16th bit to be set -- you can see it when you dump a UCS-16 file -- if it was "ascii", then it has a "zero" in the high byte. It seems any value other than 0 in the high byte would indicate something other than a simple ascii char.

In looking at my sample reg file, it looks like the "difficult" characters are simply UCS-16 encodings for \r and \n.

Any idea of who owns "TieRegistry" or "Registry" who might update them?. I "guess"...this seems kludgey, but on NT platforms, UCS-16 encoding should be used for registry terms. This would seem to be bad if one wants to use UTF-8 locale settings as an attempt at conversion would need to be done (UCS16<->UTF8). Regardless, in non-ascii locale's (i.e. most installations), a translation would need to be attempted to USC-16 and vice-versa. Then errors would have to be returned fo 'encoding errors').

Grumble...since any character is valid in a registry key/value name except "\", one can't just try to store user strings as binary data (might collide with a "\").

Note -- I tried my program without the "use UTF8;" It fails as well. It's most likely the use of the "W" API's that is central to the problem.

Thanks & thanks in advance if you know where to find the Win32 Tiereg & Registry maintainers...will try reposting this info in module-authors...

Linda

Comment on Re^2: possible perl bug or, at least, Win32::[TieRegistry\|Registry] bug with difficult keynames (limitation) Download Code

Replies are listed 'Best First'.
Re^3: possible perl bug or, at least, Win32::[TieRegistry\|Registry] bug with difficult keynames (limitation) by tye (Sage) on May 18, 2005 at 21:40 UTC
Please reread my note. The problem is that the A APIs are used, RegOpenKeyExA() not RegOpenKeyExW(). It is simply a limitation that only 8-bit characters are supported by these Microsoft APIs. The problem has nothing to do with Perl or the Perl modules, except in that those modules choose to use the A APIs. The error you get is exactly as expected given how the A APIs work. Switching Win32::TieRegistry to support the W APIs would be quite a bit of work, would add conversion overhead quite a few places, and would need to only be done optionally (due to overhead and because I don't trust Perl to prevent people from noticing that they are suddenly getting UTF-8 strings instead of 8-bit strings). From what you've written, it sounds like you don't have a real need for this functionality anyway, it just being a limitation that you discovered more out of curiosity than pressing need. I've seen no other requests for supporting out-of-locale characters in Win32::TieRegistry to date. That doesn't mean it shouldn't be done or that it won't be done, it just affects what priority I'm likely to assign to it. Win32API::Registry already supports the W APIs, but you'll have to do some extra work, as I noted. pack and unpack should handle it, if you've got a version of Perl that supports Unicode well. Probably: `my $utf8 = pack "U", unpack "S", $ucs16; my $ucs16 = pack "S", unpack( "U*", $utf8 ), 0;` [download] Except you'll probably need to chop the "\0" of the end of $utf8 after that first line. But I haven't tested any of that code. - tye	[reply] [d/l]

Replies are listed 'Best First'.

Re^3: possible perl bug or, at least, Win32::[TieRegistry|Registry] bug with difficult keynames (limitation)
by tye (Sage) on May 18, 2005 at 21:40 UTC

Please reread my note. The problem is that the *A APIs are used, RegOpenKeyExA() not RegOpenKeyExW(). It is simply a limitation that only 8-bit characters are supported by these Microsoft APIs. The problem has nothing to do with Perl or the Perl modules, except in that those modules choose to use the *A APIs. The error you get is exactly as expected given how the *A APIs work.

Switching Win32::TieRegistry to support the *W APIs would be quite a bit of work, would add conversion overhead quite a few places, and would need to only be done optionally (due to overhead and because I don't trust Perl to prevent people from noticing that they are suddenly getting UTF-8 strings instead of 8-bit strings).

From what you've written, it sounds like you don't have a real need for this functionality anyway, it just being a limitation that you discovered more out of curiosity than pressing need. I've seen no other requests for supporting out-of-locale characters in Win32::TieRegistry to date. That doesn't mean it shouldn't be done or that it won't be done, it just affects what priority I'm likely to assign to it.

Win32API::Registry already supports the *W APIs, but you'll have to do some extra work, as I noted. pack and unpack should handle it, if you've got a version of Perl that supports Unicode well. Probably:

my $utf8 = pack "U*", unpack "S*", $ucs16;
my $ucs16 = pack "S*", unpack( "U*", $utf8 ), 0;
[download]

Except you'll probably need to chop the "\0" of the end of $utf8 after that first line. But I haven't tested any of that code.

- tye

[reply]
[d/l]