Hello Alexandre,
Sure, you want to test the sortkeys directly. That doesn't mean you have to test the exact values, only the values relative to each other.
As I said, that will make tests exponentially harder - it's not really different from using CompareStringEx. What I want is a direct comparison of sortkey wine against sortkey windows, that makes testing super easy. Testing possible permutations of a single string is easy compared to testing possible permutations of a string against all other possible permutations. You see what I mean?
Keep in mind that testing the sortkeys against each other might also need different tests for different windows versions, since different windowsversions have different values, and might compare different.
E.g. CompareStringW(0x409, 0x1, L"\u093d", -1, L"\u221a", -1); is 1 on Win7, but 3 on Win10. And that's certainly not the only one.
Yes, it's a problem, particularly since we'll want to support the latest version (win10) in Wine, and potentially all of them. We need a way to test all versions.
I understand you, but my problem is that I want effective and simple tests for the algorithm. I want to make sure the sortkey algorithm works properly, and the best way to achieve that is to make a byte-for-byte comparison for them.
Honestly, I don't understand why an additional set of tests that only runs on win7 would be bad, when the alternative is not having additional tests. I too want to support all windows versions, but I consider that direct test very useful, so I don't get why I should not include it. It's just to prove that the algorithm works correctly, we still can feed different tables into the algorithm for win10.
The only way to really support all windows versions, is to include all different windows tables, and differentiate by windows version. When just the compatibility to win7 is not enough and those details matter, that's what we'll have to do.
Regards, Fabian Maurer