There are quite a few failures in kernel32:locale on Vista+. The attached patch tries to address those. Although any comment on the patch is welcome, I'm particularly interested in feedback on the changes to test_FoldStringW() (the part that starts at "@@ -2081,43 +2136,49 @@ static void test_FoldStringW(void)".)
The problem with this test was that FoldStringW() behaves very differently on Vista+ for the MAP_FOLDCZONE and MAP_EXPAND_LIGATURES cases. The tests were broken off after more than 50 failures, if I remove that then I get 7455 failures for MAP_FOLDCZONE and 1350 failures for MAP_EXPAND_LIGATURES.
Now, it is possible to fix all those failures. However, doing so would require us to duplicate the tables that Microsoft uses. This is basically the same problem that we have with the collation tables. To work around this, I simply skip the test on Vista+, just like we skip the sorting test. Does this sound like the right approach?
Thanks, Ge.
Ge van Geldorp wrote:
Now, it is possible to fix all those failures. However, doing so would require us to duplicate the tables that Microsoft uses. This is basically the same problem that we have with the collation tables. To work around this, I simply skip the test on Vista+, just like we skip the sorting test. Does this sound like the right approach?
I would mark the tests broken for Vista and Windows7 but I would not eliminate them for Windows 2003 and lower. Right now, the conformance is to WindowsXP SP3. Do the tests work there?
Also, are we going to move from WindowsXP to Windows7 anytime soon? We may have 'buy' time to get this fixed without using the tables from M$.
James McKenzie
From: James McKenzie [mailto:jjmckenzie51@earthlink.net]
I would mark the tests broken for Vista and Windows7 but I would not eliminate them for Windows 2003 and lower. Right now, the conformance is to WindowsXP SP3. Do the tests work there?
There are no failures at all on NT4/2000/XP/2003.
Also, are we going to move from WindowsXP to Windows7 anytime soon? We may have 'buy' time to get this fixed without using the tables from M$.
For the record, they also fail on Vista/2008. I'd be surprised if Wine moved to defaulting to Win7 in the next year, but that's not my decision to make :-).
Thanks, Ge.
Greg Geldorp wrote:
From: James McKenzie [mailto:jjmckenzie51@earthlink.net]
I would mark the tests broken for Vista and Windows7 but I would not eliminate them for Windows 2003 and lower. Right now, the conformance is to WindowsXP SP3. Do the tests work there?
There are no failures at all on NT4/2000/XP/2003.
Thank you for the update.
Also, are we going to move from WindowsXP to Windows7 anytime soon? We may have 'buy' time to get this fixed without using the tables from M$.
For the record, they also fail on Vista/2008. I'd be surprised if Wine moved to defaulting to Win7 in the next year, but that's not my decision to make :-).
Vista is something I hope goes away and soon. Unfortunately, I will be stuck with using it in my workplace for a while until they get fed up with all of the complaints and move on to Windows 7.
Is there anything we can do to make the tests pass without using M$ tables? Can we create tables of our own that will pass?
James McKenzie
2009/8/30 James McKenzie jjmckenzie51@earthlink.net:
Greg Geldorp wrote:
From: James McKenzie [mailto:jjmckenzie51@earthlink.net]
I would mark the tests broken for Vista and Windows7 but I would not eliminate them for Windows 2003 and lower. Right now, the conformance is to WindowsXP SP3. Do the tests work there?
There are no failures at all on NT4/2000/XP/2003.
Thank you for the update.
Also, are we going to move from WindowsXP to Windows7 anytime soon? We may have 'buy' time to get this fixed without using the tables from M$.
For the record, they also fail on Vista/2008. I'd be surprised if Wine moved to defaulting to Win7 in the next year, but that's not my decision to make :-).
Vista is something I hope goes away and soon. Unfortunately, I will be stuck with using it in my workplace for a while until they get fed up with all of the complaints and move on to Windows 7.
Is there anything we can do to make the tests pass without using M$ tables? Can we create tables of our own that will pass?
Does anyone understand what these are doing and (in a general sense) what the changes to Vista are?
That leads to the question of whether Wine should be using the locale rules for Windows, or for the system Wine is running on. Ideally, the locale data should be taken from glibc (or the equivalent component where locale data is stored).
That way, the tests should just be behavioural, not data, tests (that is, pick a sample of data from different groups -- such as characters that do compare equal and those that don't for case insensitive comparison (with some that cover casing rules for accented characters)).
I suppose the main questions to ask are: 1/ are there applications that depend on the pre-Vista locale rules? 2/ are the Linux/*BSD/Mac/OpenSolaris (or glibc, uLibc, ...) locale rules *compatible* with Windows?
I haven't seen anything on the locale changes for Vista breaking anything except the Wine tests. As a result, it should (in theory) be possible to use the native version. This would then remove the need for Wine to copy the Microsoft locale tables.
NOTE: If a system does not have the support for this, the existing Wine (i.e. pre-Vista) version can still be used.
- Reece
"Ge van Geldorp" ggeldorp@vmware.com writes:
Now, it is possible to fix all those failures. However, doing so would require us to duplicate the tables that Microsoft uses. This is basically the same problem that we have with the collation tables. To work around this, I simply skip the test on Vista+, just like we skip the sorting test. Does this sound like the right approach?
We don't want to skip the tests. What we should do in those tests is test a few characters that are known to work identically across the board. It doesn't make sense to test the whole character range because that will never match perfectly on Wine anyway.
-
Alexandre Julliard -
Ge van Geldorp -
Greg Geldorp
-
James McKenzie -
Reece Dunn