re: kernel32 & winelib: Don't test string size in CompareStringW for null terminated strings
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
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, -- Adam Strzelecki |: nanoant.com :|
On Sat, Mar 1, 2008 at 10:55 AM, Adam Strzelecki <ono(a)java.pl> 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 -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo
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, -- Adam Strzelecki |: nanoant.com :|
"Adam Strzelecki" <ono(a)java.pl> 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. -- Dmitry.
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, -- Adam Strzelecki |: nanoant.com :|
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
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, -- Adam Strzelecki |: nanoant.com :|
participants (5)
-
Adam Strzelecki -
Dan Kegel -
Dmitry Timoshkov -
Steven Edwards -
Vitaliy Margolen