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.ERR: open CUser\AppEvents\Schemes\Apps\.Default\AppGPFault\current0?: +The system could not find the environment option that was entered
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
In reply to Re^2: possible perl bug or, at least, Win32::[TieRegistry|Registry] bug with difficult keynames (limitation)
by perl-diddler
in thread possible perl bug or, at least, Win32::[TieRegistry|Registry] bug with difficult keynames
by perl-diddler
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |