kernel32 & winelib: Don't test string size in CompareStringW fornull terminated strings
ono at java.pl
Sun Mar 2 10:59:21 CST 2008
> Wine already had at some point strlen along with some other string
> implemented in asm, however they have been removed after it was
> proved that
> gcc optimized C code outperforms it.
Let me ask this way, why Wine don't use standard C library functions
for lstringsomething kernel32 implementation? Current GLIBC, OSX LIBC
are Unicode libraries since quite long time. Is Wine supposed to work
on platforms where wchar_t is unimplemented or differs from unsigned
short? Anyway AFAIK Wine is only Intel (LittleEndian) 32-bit.
So why Wine does re-implement all the string manipulation functions
that are already present in C runtimes (heavily optimized for GCC and
I know that some of Windows functions differ, but Wine may keep just
the implementation of those that differ? What do you think?
> You are welcome to show the results of the benchmark which show how
> your patch improves performance.
Please have a look at my patch, is just an easiest try to remove IMHO
unnecessary requirement to count null-terminated string lengths before
comparison, as most of comparisons are made with null-terminated
strings (-1 length).
I don't want anyone to accept my patch straight-ahead, but just to
review this string manipulation matter in Wine.
Probably the best way it would be to have CompareStringW having to
versions (function branches), one for 2 null-terminated params (most
of cases), 2nd for one, or two strings with named length.
Adam Strzelecki |: nanoant.com :|
More information about the wine-devel