http://bugs.winehq.org/show_bug.cgi?id=17500
Summary: regression: libs/wine: best-fit should be renamed to "not so" best-fit Product: Wine Version: 1.1.15 Platform: Other OS/Version: other Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs@winehq.org ReportedBy: galtgendo@o2.pl CC: julliard@winehq.org
...at least for cp932. But I'm getting ahead of myself.
Just recently I've noticed that a few programs, that required Japanese locale (not every single one, just a few) stopped running, or more exactly, terminated with some conversion error. First, I went through the tarballs. Last good was 1.1.13, but I didn't have an idea at first, what's exactly wrong. So, I've done a bisect. Checking out a whole tree take a long time - really annoying, if you're not planning to keep it, but without it, I wouldn't get so far.
After I've done a few bisects, build process failed suddenly with following error: ../../tools/wrc/wrc --nostdinc -I. -I. -I../../include -I../../include -D__WINESRC__ -D_KERNEL32_ -fokernel.res kernel.rc Source: ¢̤ a2 cc a4 eb Unicode: 5341 6708 Back: ¤Q¤ë a4 51 a4 eb nls/cht.nls:84:16: Error: String ¢Ì¤ë does not convert identically to Unicode and back in codepage 950. Try using a Unicode string instead
It messed something with my locale, while it failed (my normal locale is pl_PL.UTF-8). Luckily, I managed to get far enough, that I could notice the probably buggy commit in webgit and reverted it manually against 1.1.15 tarball. That fixed the regression.
As far as I could check, those programs were doing something like: MultiByteToWideChar(CP_ACP, MB_PRECOMPOSED|MB_ERR_INVALID_CHARS, s, -1, NULL, 0);
The commit I'm talking about is : 8e16e7871063df35ca3a6de6fb165767c00bd087
http://bugs.winehq.org/show_bug.cgi?id=17500
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |regression
--- Comment #1 from Austin English austinenglish@gmail.com 2009-02-22 14:31:49 --- commit 8e16e7871063df35ca3a6de6fb165767c00bd087 Author: Alexandre Julliard julliard@winehq.org Date: Mon Jan 19 19:57:59 2009 +0100
libwine: Re-generate the Windows codepage data using the bestfit files.
http://bugs.winehq.org/show_bug.cgi?id=17500
--- Comment #2 from Alexandre Julliard julliard@winehq.org 2009-02-22 16:15:24 --- (In reply to comment #0)
As far as I could check, those programs were doing something like: MultiByteToWideChar(CP_ACP, MB_PRECOMPOSED|MB_ERR_INVALID_CHARS, s, -1, NULL, 0);
Please attach the exact call sequence that fails (a +relay trace probably helps), and if possible the contents of the string.
http://bugs.winehq.org/show_bug.cgi?id=17500
--- Comment #3 from Philip Nilsson leffeman@gmail.com 2009-02-22 18:33:31 --- Created an attachment (id=19616) --> (http://bugs.winehq.org/attachment.cgi?id=19616) testcase
I believe I am affected by this bug, I managed to get down to this testcase (which fails when run with ja_JP.utf8 and succeeds with en_US.utf8), and reverting the patch makes it succeed.
http://bugs.winehq.org/show_bug.cgi?id=17500
--- Comment #4 from Alexandre Julliard julliard@winehq.org 2009-02-23 03:46:45 --- Created an attachment (id=19617) --> (http://bugs.winehq.org/attachment.cgi?id=19617) Better default char test.
Thanks for the testcase. This should help.
http://bugs.winehq.org/show_bug.cgi?id=17500
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|regression: libs/wine: best-|libs/wine: Japanese |fit should be renamed to |character wrongly reported |"not so" best-fit |as invalid
http://bugs.winehq.org/show_bug.cgi?id=17500
--- Comment #5 from Rafał Mużyło galtgendo@o2.pl 2009-02-23 05:15:04 --- (In reply to comment #4)
Thanks for the testcase. This should help.
Yes, it helps.
http://bugs.winehq.org/show_bug.cgi?id=17500
--- Comment #6 from Philip Nilsson leffeman@gmail.com 2009-02-23 08:07:18 --- (In reply to comment #4) Works fine here as well.
http://bugs.winehq.org/show_bug.cgi?id=17500
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution| |FIXED
--- Comment #7 from Alexandre Julliard julliard@winehq.org 2009-02-24 08:09:43 --- Fixed by b38b207625c36a332a564935af70040e20a2b63e.
http://bugs.winehq.org/show_bug.cgi?id=17500
Rafał Mużyło galtgendo@o2.pl changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #8 from Rafał Mużyło galtgendo@o2.pl 2009-02-24 09:31:00 --- In that case, marking as CLOSED should be OK.
http://bugs.winehq.org/show_bug.cgi?id=17500
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|CLOSED |UNCONFIRMED Resolution|FIXED |
--- Comment #9 from Alexandre Julliard julliard@winehq.org 2009-02-24 09:34:35 --- Please don't, bugs are closed as part of the release process.
http://bugs.winehq.org/show_bug.cgi?id=17500
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution| |FIXED
--- Comment #10 from Alexandre Julliard julliard@winehq.org 2009-02-24 09:34:43 --- Fixed again.
http://bugs.winehq.org/show_bug.cgi?id=17500
--- Comment #11 from Rafał Mużyło galtgendo@o2.pl 2009-02-24 09:45:44 --- OK, I just saw Austin English doing that quite fast, so I thought as it's in the tree, it should be OK (though more often they're closed as abandoned).
And on that note, are those ABANDONED counted among "fixed" in release notes ?
http://bugs.winehq.org/show_bug.cgi?id=17500
--- Comment #12 from Alexandre Julliard julliard@winehq.org 2009-02-24 09:56:14 --- (In reply to comment #11)
OK, I just saw Austin English doing that quite fast, so I thought as it's in the tree, it should be OK (though more often they're closed as abandoned).
It's ok for other resolutions, but not for FIXED.
And on that note, are those ABANDONED counted among "fixed" in release notes ?
No, they are not fixed.
http://bugs.winehq.org/show_bug.cgi?id=17500
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #13 from Alexandre Julliard julliard@winehq.org 2009-02-27 16:31:50 --- Closing bugs fixed in 1.1.16.