March 2008 - Wine-Devel - list.winehq.org

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

by Adam Strzelecki

Hello, > You introduce a lot of complexity into the low-level helper > routines. We don't want to put Win32 quirks, like -1 meaning "until > the null terminator" being put into the low-level functions unless > we have to. In this case, if this is the sole cause of the slowdown > then you would be better off caching the length at the MSI level > since the strings are bound to be accessed more than once. My intention was to fix performance of lstrcmpW, or CompareStringW with null-terminated strings. Currently if we try to compare "1st very long string of blah blah blah blah blah" with "2nd very long string of blah blah blah blah blah", we call non-optimized strlenW (that is simple inline loop with null checking) for both of them, which both do all together around 100 iterations. While 1 comparison (iteration) is enough to tell the result should be -1. So counting length for both string in CompareStringW just because low- lever wine_compare_string expects strings to have always specified length is IMHO CPU hog, that makes impact on WINE MSI performance, on other components using a lot of string comparing. > How do you know that the compiler isn't generating the same assembly > for the functions as that used by msvcrt / glibc? Theories like > these need numbers to back them up. I know that because those msvcrt or glibc routines are written directly in assembler not C and optimized for the 32-bit (or 64-bit) data aligning etc, and DWORD fetching. 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. > ; > ;Purpose: > ; strlen returns the length of a null-terminated string, > ; not including the null byte itself. > ; > ;******************************************************************************* Probably same thing happens with CompareStringW and lstrlenW of kernel, but this time I can't be sure because I don't have the ASM sources. So it has nothing to do with compiler, but care about performance of some often used functions and programming habit to reuse existing far better optimized low level code than cooking generic one believing that GCC will do make it best. Cheers, -- Adam Strzelecki |: nanoant.com :|

March 1, 2008

Re: kernel32 & winex11: WaitForMultipleObjectsEx should ignore NULL handles

by Adam Strzelecki

> In this case, MSI should not be calling MsgWaitForMultipleObjects > with an invalid handle and in fact that barring memory corruption, > this can't happen: You're right, my patch was incorrect, I made bad assumption. I'm still not sure why this X11DRV_MsgWaitForMultipleObjectsEx is testing for "(count || timeout)", rather than "(count && timeout)" or just "count" at: > if (process_events( data->display, mask )) ret = count - 1; > else if (count || timeout) > { > ret = WaitForMultipleObjectsEx( count, handles, flags & > MWMO_WAITALL, > timeout, flags & > MWMO_ALERTABLE ); >> I can see that msi_dialog_run_message_loop calls "MsgWaitForMultipleObjects( 0, NULL, 0, INFINITE, QS_ALLINPUT );" which implies that "WaitForMultipleObjects( 0, NULL, 0, INFINITE, MWMO_ALERTABLE );" can be called if precess_events returns FALSE. I'm pretty sure I saw in gdb some calls with NULL handles to WaitForMultipleObjects related to MSI. Regards, -- Adam Strzelecki |: nanoant.com :|

March 1, 2008

iPod synced with iTunes v7.6!

by Maarten Lankhorst

Hi all, I got an ipod I borrowed to sync: http://www.astro.rug.nl/~lankhorst/ipod.png There are, however, 3 separate issues to work out for this to work with an unpatched version of wine, minus the patches I sent to wine-patches, and one I still need to confirm with rob. 1. I need to add detection in explorer (through hal detection) so that ipods are automatically mounted and appropiate registry keys are created (not that much work). 2. The ioctl's from dlls/ntdll/cdrom.c should really be moved to dlls/mountmgr.sys, so that IOCTL_STORAGE_GET_DEVICE_NUMBER will always be called with a proper implementation. 3. I need to add raw device access (access to /dev/sdb, if the ipod is mounted on /dev/sdb2), through CreateFile(\\USBSTOR#..........) 1&3 won't be too hard to solve within a few days, but I'm not 100% sure how to do 2. Cheers, Maarten.

March 1, 2008

Re: Wine still busted?

by Ben Hodgetts (Enverex)

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dan Kegel wrote: > Even with Alexandre's most recent fix, I'm seeing hangs > on Photoshop CS2 installer, iTunes installer, and Word Perfect Office > X3 installer, > and Susan is seeing hangs on Dragon, all with the suspicious line > > $ err:ntdll:RtlpWaitForCriticalSection section 0x7bc8cf80 "rtl.c: > peb_lock" wait timed out in thread 0014, blocked by 0016, retrying (60 > sec) > > Juliard's patch fixed a few apps and broke considerably more (when he fixed the Fls issue). Currently Wine is a bit FUBAR for the most part. See bug 11779. Ben H. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHyMGguqCUopk11kIRAudSAJ9eLdyU+4mJ9OZxxse0TAl/jTakeQCfRh1D 3JzqN2+BUDltIBINnrkoyUI= =93dU -----END PGP SIGNATURE-----

March 1, 2008

Wine still busted?

by Dan Kegel

Even with Alexandre's most recent fix, I'm seeing hangs on Photoshop CS2 installer, iTunes installer, and Word Perfect Office X3 installer, and Susan is seeing hangs on Dragon, all with the suspicious line $ err:ntdll:RtlpWaitForCriticalSection section 0x7bc8cf80 "rtl.c: peb_lock" wait timed out in thread 0014, blocked by 0016, retrying (60 sec)

March 1, 2008