Regression in lstrcmpiA (occurred in late June, NLS related)

[Troy Rollo]

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 what we do, even if we magically come up with the
> same table. This is insane.

In some cases it amounts to that.  This is why it's important to try to come 
up with some way of expressing the contents of the table without the table, 
or of finding objective rules that can generate the table.

Having compared a few versions of the allkeys database it seems that there 
have been some changes to the ordering of characters between versions, which 
leads me to wonder if Microsoft were just using an earlier version of the 
table. Microsoft's documentation suggests they adhere to version 2.0 of the 
Unicode standard, whereas the allkeys.txt file immediately accessible on the 
unicode.org web site is version 3.1.1.

Here's the versions I can find: 

2.1.9d8	http://www.unicode.org/reports/tr10/basekeys.txt
2.1.9d8	http://www.unicode.org/reports/tr10/compkeys.txt
3.1.1	http://www.unicode.org/reports/tr10/allkeys-3.1.1.txt
3.1.1d3	http://www.unicode.org/reports/tr10/allkeys-3.1.1d3.txt
3.0.0d5	http://www.unicode.org/reports/tr10/allkeys-4.0.0d5.txt

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 (3.1.1), so the theory that 
Microsoft's results are just based on an earlier version of the standard 
table is starting to look like it has merit.