[RESEND] regedit: Convert from WCHAR size to maximum required TCHAR size.

Byeong-Sik Jeon wjsqudtlr at gmail.com
Wed Apr 4 19:43:06 CDT 2007


Bill Medland wrote:
> On Thu, 2007-05-04 at 06:17 +0900, Byeong-Sik Jeon wrote:
> > Without UNICODE, sizeof(TCHAR) == 1. This is no effect. CJK multibyte
> > character is 2 byte size. 
> > 
> Yes, but you are getting confused by the term 'character'.  It is being
> used in two different senses.  You are using the wrong method to solve
> the problem.  You are fixing it where it is not broken; it is (probably)
> broken somewhere else.
> 
> AFAIK The value returned by RegQueryInfoKey is (supposed to be) the
> number of TCHARS required to hold the name.  MSDN means TCHARS when it
> says 'character' for this function.  It does not matter that it actually
> requires two (char) TCHARS to hold a (language) character.  After all in
> UTF-8 it could require even more than two.
> 
> > example:
> > string "새 값 #1" has 6 characters. It is  max_val_name_len.
> > w/  UNICODE, this string is 6 * sizeof(WCHAR) bytes.
> > w/o UNICODE, this string is 8 bytes.
> >              8 == space(1) * 2 + #(1) + 1(1) + 새(2) + 값(2)
> > 
> > Currently regedit compiled without UNICODE.
> > RegQueryInfoKey result: max_val_name_len ===> 6;
> > max_val_name_len++  ===> 7
> > max_val_name_len * sizeof(TCHAR) ==> 7 * 1
> > This is bad result. we need 9 or more.
> 
> So what you have to investigate is why RegQueryInfoKey is returning a
> number that is too small.  It should return the number of TCHARS, not
> the number of language characters (I believe)
> 

1. MSDN means TCHARS when it says 'character' for this function.
   ==> No.
2. why RegQueryInfoKey is returning a number that is too small
   ==> No. Currently RegQueryInfoKey returns the right values.

In SBCS or w/ UNICODE case, you are right.
But this case is DBCS. Some characters in a DBCS have a single byte code
value and some have a double byte code value. <== from MSDN

MSDN use "in characters", "in bytes", "in TCHARS", "numbers of wide
characters" representation. it's different.

Did you test the "regedit" in the Japanese or Korean locale? This is
really bug.
If we create the registry value name in the empty registry key,
we can't see any newly created reg value name ( because of RegEnumValue
function failed).

Of cause, we can make another solution to fix this problem.
We can check the return value of RegEnumValue function. but the patch
will complicate more. We just need more big buffer.

another soultion:
 * we can change the "IDS_NEWKEY, IDS_NEWVALUE"  of resource file.
 * define the UNICODE
 but these sulution don't fix the regedit's bug. just bug hide...

Thanks.




More information about the wine-devel mailing list