re: kernel32 & winelib: Don't test string size in CompareStringW for null terminated strings

[Dan Kegel]

Adam Strzelecki wrote:
> Visual Studio is shipping with complete sources of C CRT so you may have a look.
> ;***
> ;strlen.asm - contains strlen() routine
> ;
> ;       Copyright (c) Microsoft Corporation. All rights reserved.

No, we may not have a look!  And we sure as hell can't
post copyrighted Microsoft source code on this mailing list!
- Dan

kernel32 & winelib: Don't test string size in CompareStringW for null terminated strings

[Adam Strzelecki]

> No, we may not have a look!  And we sure as hell can't
> post copyrighted Microsoft source code on this mailing list!

Argh... I meant you may have a look if you have Visual Studio  
installed, I don't intend to post any copyrighted code there, but I  
just post header copyright information from this file to prove that it  
does exist:)
However you can find with Google + "strlen.asm - contains strlen()  
routine" on M$ forums some ppl that wisely did post full source ;P

Regards,

kernel32 & winelib: Don't test string size in CompareStringW for null terminated strings

[Steven Edwards]

On Sat, Mar 1, 2008 at 10:55 AM, Adam Strzelecki  wrote:
> > No, we may not have a look!  And we sure as hell can't
> > post copyrighted Microsoft source code on this mailing list!
>
> Argh... I meant you may have a look if you have Visual Studio
>  installed, I don't intend to post any copyrighted code there, but I
>  just post header copyright information from this file to prove that it
>  does exist:)
>  However you can find with Google + "strlen.asm - contains strlen()
>  routine" on M$ forums some ppl that wisely did post full source ;P

Wine kind of work on the honor system here. If you've looked at the
CRT sources even though they come with the PSDK and MSVC please don't
start implementing those functions. Ditto for ATL. MSVC ships with the
source code for it also but the developers that work on the ATL don't
go digging in to those sources.

Thanks

kernel32 & winelib: Don't test string size in CompareStringW for null terminated strings

[Adam Strzelecki]

I believe the further discussion is pointless. If you ever dared to  
look how MSVCRT or GLIBC strlen function is implemented you would know  
that it is exactly same algorithm (that just differs in the  
implementation) using 4 byte fetching with magic bits matching, also  
described in few books and articles, let me name one: "Write Great  
Code, Volume 2: Thinking Low-Level, Writing High-Level" ISBN  
1593270658, section 10.1.1.1 about using string manipulation routines,  
so there's nothing about Microsoft's or anybody's else secret invention.

However instead of decent discussion I was pushed aside and then  
taught here not to copy copyrighted materials, so something that I'm  
already very aware and careful about. IMHO this overwhelming paranoia  
of being scared of Microsoft is against sober thinking, and this for  
sure glads greediness of this company. My mistake was I just mentioned  
MSVCRT, that raised your disquiet, while I could point you to GLIBC or  
Linux kernel sources as well, or the book above. Too bad.

To be clear, my only intention was to point you that Wine's  
CompareStringW can be better. IMHO it is very respectable to not only  
write code that is well organized and bug-free that Wine is in my  
opinion, but also to write performance aware code, which IMHO Wine is  
NOT.

Finally I just want to point you there:
http://www.ussg.iu.edu/hypermail/linux/kernel/9907.3/0434.html

Note there that Linux kernel mailing list is bit less paranoiac :P

Cheers,

kernel32 & winelib: Don't test string size in CompareStringW fornull terminated strings

[Dmitry Timoshkov]

"Adam Strzelecki"  wrote:
> I believe the further discussion is pointless. If you ever dared to  
> look how MSVCRT or GLIBC strlen function is implemented you would know  
> that it is exactly same algorithm (that just differs in the  
> implementation) using 4 byte fetching with magic bits matching, also  
> described in few books and articles, let me name one: "Write Great  
> Code, Volume 2: Thinking Low-Level, Writing High-Level" ISBN  
> 1593270658, section 10.1.1.1 about using string manipulation routines,  
> so there's nothing about Microsoft's or anybody's else secret invention.

Wine already had at some point strlen along with some other string functions
implemented in asm, however they have been removed after it was proved that
gcc optimized C code outperforms it.
> To be clear, my only intention was to point you that Wine's  
> CompareStringW can be better. IMHO it is very respectable to not only  
> write code that is well organized and bug-free that Wine is in my  
> opinion, but also to write performance aware code, which IMHO Wine is  
> NOT.

You are welcome to show the results of the benchmark which show how much
your patch improves performance.

kernel32 & winelib: Don't test string size in CompareStringW fornull terminated strings

[Adam Strzelecki]

> Wine already had at some point strlen along with some other string  
> functions
> 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  
OS).
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  
> much
> 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.

Regards,

kernel32 & winelib: Don't test string size in CompareStringWfornull terminated strings

[Vitaliy Margolen]

Adam Strzelecki wrote:
> 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

WCHAR is not the same as wchar_t.
> short? Anyway AFAIK Wine is only Intel (LittleEndian) 32-bit.

Wrong, it compiles and works (for winelib) on SUN.

Vitaliy

kernel32 & winelib: Don't test string size in CompareStringWfornull terminated strings

[Adam Strzelecki]

> > 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
>
> WCHAR is not the same as wchar_t.

You're right, it is means the same only in Windows.
I just checked several discussions already done on this subject, now I  
know that Windows 16-bit UNICODE isn't compatible with UNIX 32-bit one.
Someone have mentioned in old Wine dev list archives also -fshort- 
wchar GCC flag solution, but it seems this makes C library's UNICODE  
function not work at all as expected. Nice to learn something new.
> Wrong, it compiles and works (for winelib) on SUN.

Good to know.

Cheers,