Frank, I'll need some time to study this change.
-Chris. On 07/11/2012 09:08, Frank Ding wrote:
Hi guys, Could you please take a look at patch below aimed to resolve existing bug http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6512101 ? http://cr.openjdk.java.net/~dingxmin/6512101/webrev.01/ I happen to have a Chinese Win 7 environment. "buggy.png" is current output of test case described in bug system whereas "fixed.png" is the output after the my patch is applied. http://cr.openjdk.java.net/~dingxmin/6512101/buggy.png http://cr.openjdk.java.net/~dingxmin/6512101/fixed.png The patch simply converts to wide chars encoded in CP_OEMCP by calling MultiByteToWideChar. We have confirmed a guy from Microsoft who said that BEGIN QUOTE I'm not sure how common it is to call the Java code that results in calling the GetIfTable API but I would guess it does not happen that often. Additionally, if it's rare that the adapter contains the accented characters, it would definitely be quite easy to miss in testing. I have not found any documentation about the encoding of the bDescr string unfortunately. I did, however, debug through the API and located the place where it is generated. It is getting converted from a UTF-16 string to a single-byte string using a conversion like this: WideCharToMultiByte( CP_OEMCP, WC_NO_BEST_FIT_CHARS, <source string>, -1, IfRow->bDescr, <size>, NULL, NULL); I have checked the source for Windows Vista, 2008, Windows 7, and Windows 2008 R2. It is using CP_OEMCP in all of them. So using the reverse conversion in your code using CP_OEMCP should be safe. Alternatively, you can use the GetIfTable2 function (http://msdn.microsoft.com/en-us/library/windows/desktop/aa365945^(v=vs.85).aspx ) which returns the same information in the original UTF-16 encoding. END QUOTE The link below may be helpful to the second param of WideCharToMultiByte. http://blogs.msdn.com/b/oldnewthing/archive/2012/05/04/10300670.aspx You comments are appreciated. Best regards, Frank
