I think that the Windows function's bug is about differencing the numbers by its length, instead of the value, when the value is the same, which occurs only for zeroes, BTW.

No, I don't think Windows looks at the length of the string in the case the numbers are equal. It looks at the individual numbers at their position.

And of course it only happens with the zero's before numbers. Otherwise the numbers wouldn't be the same:

`111`

11

1

These are not the same. Only if the (same) numbers are prefixed with zero they could be the same.

I still think there is an argument for the way Windows sorts them.

Like I said:

`001`

01

1

^^

||-----look at the 0, 1

--------[b]look at the 0, 0, 1[/b]

And I think Microsoft sees that when these 3 numbers are in value equal (which they are) they look at the individual numbers themselves at their respective position and in that case the order would be correct.

`1`

01

001

This would be wrong in that case. Because the 1 is before the 0.

I haven't found any real official document describing this kind of sorting (but will continue looking). Maybe there isn't any and it's just "open" to interpretation.

I'm also still hopeful to get that naturalstrcmp going. (haven't tried passing a UCS4 to that one yet)

B.T.W. I think Linux also sorts the filenames the way the Windows-sort works:

`-rw-r--r-- 1 root root 0 May 17 00:17 001`

-rw-r--r-- 1 root root 0 May 17 00:17 01

-rw-r--r-- 1 root root 0 May 17 00:17 1

-rw-r--r-- 1 root root 0 May 17 00:17 11

I also have found this definition:

Natural Order uses the following rule to sort strings:

- The space character sorts before numbers; numbers sort before non-numbers.
- Numbers sort in numerical order; leading zeroes and spaces on numbers are ignored,
**except as a tie-breaker for numbers that have the same numerical value**. - Non-numbers sort in the Mac's System sorting order.

So in case of a tie braker (numbers with same numerical value) you need to look at the leading zeros and spaces. And in that case a zero becomes before the 1.

So... maybe this isn't a bug at all.