On 04.07.2009 23:55, Yuriy Kaminskiy wrote:
Yuriy Kaminskiy wrote:
I'm wrong - I don't have working windows installation at hands and cannot
check
that.
Well, no answer so far; I thought should write test, code is more welcomed than
just words, and noticed that such test already present, but
Yuriy Kaminskiy wrote:
I've stumbled over problem with lstrcmpi sorting is still wrong. Some
japanese game engine uses binary search on presorted array, and fails
with a-la object not found errors.
[...]
proper order should be _ 0 (ok) and . _ (fails with vanilla
wine).
Well, after
Hello!
Previous thread on this topic:
http://www.mail-archive.com/wine-devel@winehq.org/msg01080.html
I've stumbled over problem with lstrcmpi sorting is still wrong. Some
japanese game engine uses binary search on presorted array, and fails
with a-la object not found errors.
Judging by
Troy Rollo wrote:
The 2.1.9d8 file seems after a quick look to be closer to the Crossover
version of the table - for example, it has many of the different types of
space characters sorted near 0020, which is an aspect of the Crossover table
not present in the table based on allkeys.txt
Troy Rollo [EMAIL PROTECTED] wrote:
Well right now it's not using any table at all - it's just going through to
strncmpiW, which is essentially a word-by-word comparison. Presumably the
issue now is copyright on the MS version of the table. Do you have anything
written down on the
Uwe Bonnes wrote:
Dmitry The source of all of this is the difference between MS and
Dmitry unicode.org sort weight tables. There is no an easy way to make
Dmitry unicode.org database look like the MS one unfortunately...
Can we perhaps write a tool that dumps those tables on a running MS
--- Dmitry Timoshkov [EMAIL PROTECTED] wrote:
Jakob Eriksson [EMAIL PROTECTED] wrote:
Dmitry The source of all of this is the difference between MS and
Dmitry unicode.org sort weight tables. There is no an easy way to make
Dmitry unicode.org database look like the MS one
Jeff Smith [EMAIL PROTECTED] wrote:
You mean something like:
[skipped]
Exactly. I have something like that here, the only difference is that
I'm dumping full unicode range 0-0x, not only first 96 characters.
--
Dmitry.
On October 2, 2003 10:19 am, Dmitry Timoshkov wrote:
That's the approach we have chosen so far.
So, what's the problem with doing something like so:
For all x,y in Unicode
print x,y,lstrcmpi(x,y)
(It will generate maybe close to 30GB of output, but it's OK)
Run this on Windows and Wine,
Dmitry Timoshkov wrote:
Jeff Smith [EMAIL PROTECTED] wrote:
You mean something like:
[skipped]
Exactly. I have something like that here, the only difference is that
I'm dumping full unicode range 0-0x, not only first 96 characters.
Isn't the full unicode range significantly
On Thu, 2 Oct 2003 19:34, Dmitry Timoshkov wrote:
Can we perhaps write a tool that dumps those tables on a running MS
system as header files that wine can use? Would this be allowable?
I really hope that we could find a solution without doing that.
Indeed - since doing that would compromise
On Thu, 2 Oct 2003 21:49, Jakob Eriksson wrote:
Wouldn't the clean-room way be to write regression tests that pass on
Windows?
This doesn't help avoid the copyright on the table if you in fact reproduce
the table.
On Fri, 3 Oct 2003, Troy Rollo wrote:
This doesn't help avoid the copyright on the table if you in fact reproduce
the table.
Why is that? We're talking here about lstrcmpiA() behaviour, why would a
test for
For all x,y in Unicode:
print x,y,lstrcmpiA(x,y)
violate the copyright?
On Fri, 3 Oct 2003 08:21, Dimitrie O. Paun wrote:
Why is that? We're talking here about lstrcmpiA() behaviour, why would a
test for
For all x,y in Unicode:
print x,y,lstrcmpiA(x,y)
violate the copyright?
I think the suggestion was that the regression tests be used to fabricate
On Fri, 3 Oct 2003, Troy Rollo wrote:
On Fri, 3 Oct 2003 08:21, Dimitrie O. Paun wrote:
Why is that? We're talking here about lstrcmpiA() behaviour, why would a
test for
For all x,y in Unicode:
print x,y,lstrcmpiA(x,y)
violate the copyright?
I think the suggestion was
On Fri, 3 Oct 2003 08:47, Dimitrie O. Paun wrote:
I said to run
the above on Windows and on Wine (which is based on the unicode.org
tables). Compare the results, and generate the differences. Use that as a
'patch' to future unicode.org table updates.
Yes, this is a problem for copyright. The
On October 2, 2003 07:30 pm, Troy Rollo wrote:
Yes, this is a problem for copyright. The result still counts as copied, at
least in Australia, the UK and New Zealand.
This doesn't make any sense. It means that we can _never_ have correct
behaviour, no matter what we do, even if we magically
On Fri, 3 Oct 2003 14:02, Dimitrie O. Paun wrote:
This doesn't make any sense.
Well when the High Court of Australia considered it they said it was
unsatisfactory, which is their way of saying it sucks, but that's the way it
is.
It means that we can _never_ have correct
behaviour, no matter
When lstrcmpiA was moved from ole2nls.c to locale.c, (around 28th June) the
results of comparisons in some cases became reversed. For example, the
underscore now returns as greater than alphabetic characters, whereas it used
to return as less than alphabetic characters. The older behaviour was
Further investigation reveals another problem in lstrcmpiA: MSDN documents
this function as executing what it describes as a word sort, which results
in the words co-op and coop sorting to the same place. This is almost a
correct description of what happens (if the strings come out to be the
On Wed, 1 Oct 2003 18:25, Dmitry Timoshkov wrote:
The older behaviour was
consistent with Win2k.
... and only with Latin1 locale, failing with others.
Yes, but it this also means it worked for ASCII-7. Right now it doesn't even
work for that. This creates problems for some applications,
21 matches
Mail list logo
