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

Re: ntdll: Added support for Windows 2008
by Robert Shearman 03 Mar '08

03 Mar '08

Alistair Leslie-Hughes wrote: > sizeof(RTL_OSVERSIONINFOEXW), 6, 0, 0x1770, VER_PLATFORM_WIN32_NT, > {' ',0}, > 0, 0, VER_SUITE_SINGLEUSERTS, VER_NT_WORKSTATION, 0 > + }, > + /* WIN2K8 */ > + { > + sizeof(RTL_OSVERSIONINFOEXW), 6, 0, 0x1771, VER_PLATFORM_WIN32_NT, > + {'S','e','r','v','i','c','e',' ','P','a','c','k',' ','1',0}, > + 0, 0, VER_SUITE_SINGLEUSERTS, VER_NT_SERVER, 0 > } > }; > I see Microsoft are using even more sneaky tactics these days to increase sales. They are releasing new versions of Windows with the first service pack already applied to satisfy the customers who always wait for the first service pack of a version of Windows to come out before upgrading to it. Or could this just be a copy and paste mistake? -- Rob Shearman

3 2

Re: msi: Fix cast-qual warnings
by Robert Shearman 03 Mar '08

03 Mar '08

James Hawkins wrote: > module = LoadLibraryExW( file->TargetPath, NULL, LOAD_LIBRARY_AS_DATAFILE ); > if (module) > { > - LPCWSTR guid; > - guid = MSI_RecordGetString(row,1); > - CLSIDFromString((LPWSTR)guid, &tl_struct.clsid); > + LPWSTR guid; > + guid = strdupW(MSI_RecordGetString(row, 1)); > + CLSIDFromString(guid, &tl_struct.clsid); > + msi_free(guid); > tl_struct.source = strdupW( file->TargetPath ); > tl_struct.path = NULL; I can guarantee you that CLSIDFromString does not change the input string. We should not be adding extra performance costs in the form of extra memory allocations for the sake of getting rid of a fairly harmless warning. We should fix the ones that don't require an extra allocations or other performance penalty and leave the warning off. -- Rob Shearman

1 0

re: winmm/tests: Don't use 0x55 to avoid any confusion when running with +heap.
by Dan Kegel 02 Mar '08

02 Mar '08

Hey, on that topic, there are also a bunch of other possible suspects: ./dlls/ntdll/tests/atom.c: memset(abi->Name, 0x55, 255 * sizeof(WCHAR)); ./dlls/ntdll/tests/atom.c: memset(abi->Name, 0x55, lstrlenW(testAtom1) * sizeof(WCHAR)); ./dlls/user32/tests/menu.c: memset( bmfill, 0x55, sizeof( bmfill)); ./dlls/ntoskrnl.exe/ntoskrnl.c: memset( &irp, 0x55, sizeof(irp) ); ./tools/wrc/utils.c: memset(res, 0x55, size); ./tools/widl/utils.c: memset(res, 0x55, size); ./tools/wmc/utils.c: memset(res, 0x55, size); ./server/object.c: if (ptr) memset( ptr, 0x55, size ); ./server/window.c: memset( win, 0x55, sizeof(*win) + win->nb_extra_bytes - 1 ); And 0xaa can also interfere: ./dlls/kernel32/tests/process.c: memset(&info, 0xaa, sizeof(info)); ./dlls/ddraw/tests/d3d.c: memset(outH, 0xaa, sizeof(outH)); ./dlls/comctl32/tests/listview.c: memset(&column, 0xaa, sizeof(column)); ./dlls/comctl32/tests/listview.c: memset(&item, 0xaa, sizeof (item)); ./dlls/comctl32/tests/listview.c: memset (&item, 0xaa, sizeof (item)); ./dlls/comctl32/tests/listview.c: memset (&item, 0xaa, sizeof (item)); ./dlls/comctl32/tests/listview.c: memset (&item, 0xaa, sizeof (item)); ./dlls/comctl32/tests/listview.c: memset (&item, 0xaa, sizeof (item)); ./dlls/comctl32/tests/listview.c: memset (&item, 0xaa, sizeof (item)); ./dlls/comctl32/tests/listview.c: memset (&item, 0xaa, sizeof (item)); ./dlls/comctl32/tests/listview.c: memset (&item, 0xaa, sizeof (item)); ./dlls/comctl32/tests/listview.c: memset (&item, 0xaa, sizeof (item)); ./dlls/comctl32/tests/listview.c: memset(&column, 0xaa, sizeof(column)); ./server/object.c: memset( obj, 0xaa, obj->ops->size );

3 3

re: kernel32 & winelib: Don't test string size in CompareStringW for null terminated strings
by Dan Kegel 02 Mar '08

02 Mar '08

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

5 7

Heading towards a fixed function pipeline replacement
by Stefan Dösinger 02 Mar '08

02 Mar '08

Hi, Due to the bad weather I had some spare hacking time this weekend, and I've done some work and investigation on a fixed function pipeline replacement. The product of that is a hacky fixed function pipeline replacement via GL_ATI_fragment_shader(*). Functionality wise the code is doing pretty good, it should support everything the current GL_ARB_texture_env_combine supports on ATI cards, although I didn't test it much yet and it is most likely buggy. However, integration-wise it is a disaster at this point, as I've focused on the GL functionality for now. However, I have some roadmap for integrating this in Wine now. Essentially I'm going to modify the state table and shader backends a bit: -> Make the state table a property of the shader model: Each pipeline implementation has its own state dependencies and ways to load states, so it is pointless to use one static table. The table will remain static, but there will be multiple tables, selected at device creation time -> As a consequence, make the current "none" shader backend a backend for the current fixed function state table -> Different state implementations will be able to borrow code from each other. E.g, the ATI_fragment_shader backend can borrow vertex processing from the fixed function implementation or GL_ARB_*_program -> The current "fixed function" state table will still be able to handle d3d shaders of all kinds, at least for now. Somewhen later we might want to split fixed function and shaders up, so that whenever we have shaders we use them for fixed function processing too. But for now we still have the problem that e.g. GLSL has horribly slow shader compilation performance. On top of this work the mentioned SoC project to write a vertex shader replacement pipeline might be doable because the general infrastructure is there, and only the shader generator is needed. Feel free to comment, Stefan (*) Why this odd extension and not GLSL? We'll want it at some point anyway for better support of r200 cards(radeon 8500-9250), and as a counterpart to the GL_NV_register_combiner code on nvidia cards. GLSL has a few other tricky aspects, like per shader uniforms, so this extension is easier for the start.

1 0

Re: winmm/tests: Don't use 0x55 to avoid any confusion when running with+heap.
by Dmitry Timoshkov 02 Mar '08

02 Mar '08

"Francois Gouget" <fgouget(a)free.fr> wrote: > mmioSeek(hmmio, 0, SEEK_SET); > - memset(&ck, 0x55, sizeof(ck)); > + memset(&ck, 0x66, sizeof(ck)); > ret = mmioDescend(hmmio, &ck, NULL, MMIO_FINDCHUNK); > ok(ret == MMIOERR_CHUNKNOTFOUND || > ret == MMIOERR_INVALIDFILE, "mmioDescend returned %u\n", ret); > @@ -162,7 +162,7 @@ static void test_mmioDescend(void) > ok(ck.dwDataOffset != 0x55555555, "wrong dwDataOffset: %04x\n", ck.dwDataOffset); The 'ok' above (and 2 tests before it) will fail with your changes. -- Dmitry.

1 0

Any graphics card y'all like to see tests run on?
by Austin English 02 Mar '08

02 Mar '08

Howdy, I'm about to get a new graphics card, because my current crappy Nvidia FX 5200 doesn't support widescreen, and I just got a shiny nice new 22". So, I'm going to upgrade my graphics card. I don't have a preference, since I don't game at all, just need something that will run 1920x1040 and $200<=. So any of you d3d/ddraw guys, is there some graphics card y'all need tests run on, and don't see around often, because now's your chance... -Austin

4 5

iPod synced with iTunes v7.6!
by Maarten Lankhorst 02 Mar '08

02 Mar '08

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.

2 1

Re: kernel32 & winelib: Don't test string size in CompareStringW for null terminated strings
by Robert Shearman 01 Mar '08

01 Mar '08

Adam Strzelecki wrote: > During playing with installing Visual Studio 2005 with WINE I found > out that WINE's MSI is spending lot of time inside lstrcmpW. With Mac > OS X process sampler I checked that actually 60-70% of CompareStringW > is wine_compare_string, rest is rest of function body, which is in > case 2 strlenW calls (inline). > I believe this isn't necessary, moreover most of compares in MSI are > non-matching on first few characters, however with current > implementation we go trough all strings with strlenW regardless of > anything, which is waste in CPU cucles. > I modified both CompareStringW and wine_compare_string so they work > with -1 strings without strlenW checking before. > This saves in my testing about 20-30% of CPU cycles. 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. However, I think you'll find that this is an algorithm problem in MSI rather than a performance issue in the functions you mention. By that, I mean it is likely that one MSI query is being performed again and again and that the results should be cached. > Note also that WINE's strlenW and lstrcmpW functions are far from > perfect. Normal msvcrt or glibc string functions are far more > optimized at machine code level. This makes strong impact on WINE > parts strongly relaying on string manipulation which is in this case MSI. 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. -- Rob Shearman

3 2

Re: kernel32 & winex11: WaitForMultipleObjectsEx should ignore NULL handles
by Robert Shearman 01 Mar '08

01 Mar '08

Adam Strzelecki wrote: > Hi, > > In MSI dialog.c: msi_dialog_check_messages function it often happens > that is sends: > MsgWaitForMultipleObjects( 1, &handle, 0, INFINITE, QS_ALLINPUT ); > Where handle = NULL. I'm not sure if it is correct behavior. But > tracing it down I found out that kernel32 and winex11 sync functions > are not checking at all if the passes handles are not NULLs. > > So I'm not sure whether this patch is right or not, but I believe we > shouldn't bother wineserver with NULL handles!? > Yet maybe I don't understand clearly the way interserver communication > works, and sending "WaitFor" with NULL handle makes sense. Does it? No, but this is the wrong fix. You're assuming that because MSI code does action A and that causes bad effect when it does action B that the correct action is to fix B so that it doesn't have a bad effect. However, the bug could also be that action A shouldn't be done. In this case, MSI should not be calling MsgWaitForMultipleObjects with an invalid handle and in fact that barring memory corruption, this can't happen: > while (1) > { > msi_process_pending_messages( NULL ); > > if( !handle ) > break; > > /* > * block here until somebody creates a new dialog or > * the handle we're waiting on becomes ready > */ > r = MsgWaitForMultipleObjects( 1, &handle, 0, INFINITE, > QS_ALLINPUT ); > if( r == WAIT_OBJECT_0 ) > break; > } -- Rob Shearman

2 1