November 2013 - Wine-devel - list.winehq.org

Call to action: Windows 8 tests cleanup
by Francois Gouget 14 Nov '13

14 Nov '13

There are still a lot of failing Windows 8 tests. If I only look at tests that fail on every single system we have test results for and further ignore most Direct X tests, I already get 29 tests for a total of 533 individual test failures! cmd.exe:batch (1) crypt32:sip (1) kernel32:console (56) kernel32:heap (20) kernel32:locale (62) mshtml:activex (6) ntdll:pipe (8) ole32:marshal (36) quartz:filtergraph (crash) rpcrt4:cstub (crash) shell32:ebrowser (3) shell32:shellpath (3) shell32:shlexec (13) shell32:shlfolder (1) shlwapi:assoc (1) shlwapi:ordinal (25) urlmon:misc (2) urlmon:protocol (46) urlmon:sec_mgr (20) urlmon:uri (3) urlmon:url (94) user32:cursoricon (55) user32:edit (4) user32:msg (10) user32:win (11) wininet:urlcache (17) winmm:midi (32) wintrust:crypt (2) wintrust:softpub (crash) Overall we have 47 tests that have failures on Windows versions ranging from XP to 8.1. We need a lot more tests to succeed in order for the WineTestBot to be at its best. List collected from: http://test.winehq.org/data/1f8636c5afc9aab85abed759627c1fa25e3b2131/index_… http://test.winehq.org/data/eebc40f2b3935819584a20187af2e6f782270838/index_… -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ I haven't lost my mind, it's backed up on tape around here somewhere...

1 0

WineTestBot status update
by Francois Gouget 14 Nov '13

14 Nov '13

We switched to the new WineTestBot near the start of September. Early on it ran into a problem when it was flooded with tests due to the __WINESRC__ tests work and it failed to keep up. The reason is that as time went on the time it takes to get the VMs back to a clean state ready to run the tests (the revert time) kept increasing as can be seen on this graph: http://fgouget.free.fr/wtb/vm1-revtimes.png There one can see the increased activity in september that what was caused by the surge in test patches. But the most remarkable feature is the Windows XP revert times which increase linearly, reaching over 30 minutes. The revert times for the other VMs are much more random but still seem to increase somewhat (1). The reason for the increase is still unknown. The revert time fell down a few times and now I suspect this corresponds to times when the VM was restored from backup. So at the start of October I upgraded to QEMU 1.6.0 and restored all the VMs from backup, hoping this would solve the problem. The revert times did get much better and the WineTestBot now manages to keep up: http://fgouget.free.fr/wtb/vm1-revtimes-new.png The upgrade happened around the 2nd of october and the revert times fell at that point. But looking at more recent data it's clear that the Windows XP revert times are increasing again, while those of the other VMs remain stable (see vm1-revtimes.xls for the raw data). That XP VM is one of the first ones I created, so it probably was created with a pretty old QEMU version. Futhermore it was only an out of the box SP2 and did not have any of the later updates. So I decided to recreate it from scratch, using QEMU 1.6.0, and to add all the other updates as I was at it. And I'm hoping that this time things will be better. That's why this VM is currently in 'maintenance' mode. I also took down the 32-bit Windows 8 VM for maintenance. It too is missing proper updates and the plan is to upgrade it to Windows 8.1. Another issue has been that the tests are running a bit slow, a particular point of pain was msi:action and msi:install which were regularly timing out. See: http://fgouget.free.fr/wtb/runtimes.htm So while rebuilding the Windows XP VM I did some performance tests. That paid off. I found that switching the emulated disk cache mode from writeback to default roughly halves the msi run times: http://fgouget.free.fr/wtb/runtimes2.htm msi:action and msi:install went from an average of 99 and 90 seconds down to 48 and 39 seconds and they are not timing out anymore. The remaining troublesome tests are now ddraw:ddraw{2,4,7}, shell32:shlexec, and winspool.drv:info. I also uncovered two other potential performance issues: * Some VMs have Windows Defender and apparently it was starting a full disk scan as soon as the VM was ready to run the tests. That's clearly not good so I disabled Windows Defender in all VMs. * Most VMs were still using 20% of the CPU when idle. That's fine if only one VM is running but could impact performance (through increased interrupt rates) if many are running at once (like on the WineTestBot). Apparently the culprit is the USB Tablet device that's added by default. So I removed it from all VMs too (and now the mouse is even more laggy than before when I work on the VMs :-( But that does not impact the tests). So there is still a lot of work to do on the WineTestBot, and that's not even counting fixing all the failing tests. (1) It's almost as if the increasing Windows XP revert times were pulling up the other VM revert times. Yet there's only one revert at a given time, so I don't see how this would be possible. (2) Setting the cache mode to writeback was improving the performance quite a bit with the pre-upgrade QEMU version. But obviously it's not true anymore. Another interesting point is that the Virtio mode improves performance by a factor of 10 (down from 450 seconds to 45 in msi:action). Yet Windows 8 posts the fastest times yet in the basic IDE mode (~23 seconds). I couldn't get Windows 8 working with the Virtio disk yet and I have not verified that it's really doing the same set of tests. So that remains to be confirmed. Here is some performance data taken from the Windows XP VM while the TestBot was idle. From it cache=default looks like it's a completely separate mode! msi:action | msi:install | msi:msi 448 460 520| 487 439 | 238 229 VGA, qcow2 ide disk, cache:default 44 45 42 | 47 49 46 | 24 23 21 VGA, qcow2 virtio disk, cache:default 48 45 50 | 47 48 48 | 23 23 24 VMVGA/VGA, qcow2 virtio disk, cache:default 47 46 | 48 46 | 23 22 22 VMVGA, qcow2 virtio disk, cache:default 47 47 | 49 48 | 24 23 VMVGA, raw virtio disk, cache:default 62 67 67 | 64 60 63 | 29 27 27 VMVGA, raw virtio disk, cache:none 111 92 72 113 | 101 101 | 37 37 40 VMVGA, raw virtio disk, cache:writethrough 61 64 53 | 70 59 58 | 36 28 29 VMVGA, raw virtio disk, cache:writeback 46 44 | | VMVGA, raw virtio disk, cache:default 71 55 68 | | VMVGA, raw virtio disk, cache:writeback 65 71 72 69| | VMVGA, raw virtio disk, cache:none 76 118 111 | | VMVGA, raw virtio disk, cache:writethrough 50 48 47 | | VMVGA, raw virtio disk, cache:default And the preliminary Windows 8 performance. I hope it holds up. msi:action | msi:install | msi:msi 23 22 22 | 16 15 16 | 13 13 15 VGA, qcow2 ide disk, cache:default -- Francois Gouget <fgouget(a)codeweavers.com>

6 12

Re: [PATCH] ddraw: fill dwNumFourCCCodes in ddraw7_GetCaps
by Henri Verbeet 14 Nov '13

14 Nov '13

On 14 November 2013 17:17, Patrick Rudolph <siro(a)das-labor.org> wrote: > hr = IDirectDraw7_GetAvailableVidMem(iface, &ddscaps, &caps.dwVidMemTotal, &caps.dwVidMemFree); > - wined3d_mutex_unlock(); > if(FAILED(hr)) { > WARN("IDirectDraw7::GetAvailableVidMem failed\n"); > return hr; > } You now fail to release the mutex on the error path. Wrt. style, I realize ddraw isn't entirely consistent about this, but you'll want to put a space between the "if" and the '(', and but the '{' on a new line.

1 0

Re: shell32/tests: add a missed init_shfo_tests() call
by Marvin 13 Nov '13

13 Nov '13

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://newtestbot.winehq.org/JobDetails.pl?Key=3354 Your paranoid android. === build (build) === Patch failed to apply

1 0

Potential miss usage of strchr VS strrchr in Wine (was: [PATCH] wscript: Get extension name by strrchrW instead of strchrW.)
by Qian Hong 13 Nov '13

13 Nov '13

Hello, While working on a vbscript bug affects a real world app, I found a potential miss usage of strchr/strrch in Wine. Here is a unfiltered list: $ git grep "= strchr" | grep ext | grep -E "'\.'" dlls/gdi32/freetype.c: ext = strchr( last_part, '.' ); dlls/msi/action.c: extension = strchrW( filename, '.' ); dlls/wineps.drv/type1afm.c: CHAR *file_extension = strchr(dent->d_name, '.'); tools/winebuild/utils.c: if (!(ext = strchr( basename, '.' ))) ext = prefix + strlen(prefix); After basic reviewing, I think all the above codes are potential miss usage, but there is a risk to touch these codes. I don't know any real word app affected by these codes yet, so I have no strong motivation to touch them. Anyone worked on related fields has interesting to review deeper? Thanks! On Tue, Nov 12, 2013 at 4:19 PM, Qian Hong <qhong(a)codeweavers.com> wrote: > --- > programs/wscript/main.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > -- Regards, Qian Hong - http://www.codeweavers.com

2 1

Re: user32/tests: Allow win8 error code
by Marvin 12 Nov '13

12 Nov '13

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://newtestbot.winehq.org/JobDetails.pl?Key=3343 Your paranoid android. === w8 (32 bit sysparams) === sysparams.c:2488: Test failed: Waiting for the WM_DISPLAYCHANGE message timed out sysparams.c:2501: Test failed: Set bpp 32, but WM_DISPLAYCHANGE reported bpp -1 === w864 (32 bit sysparams) === sysparams.c:2488: Test failed: Waiting for the WM_DISPLAYCHANGE message timed out sysparams.c:2501: Test failed: Set bpp 32, but WM_DISPLAYCHANGE reported bpp -1

1 0

WINE CE - getting a program to execute
by Mark Bellmore 12 Nov '13

12 Nov '13

Hello, I have some winCE apps they would like to run on Android. Since WINE for Android will not be out for several months I thought I would investigate how to get applications running under the winece that is currently available. I successfully installed it on a pandaboard and the demo applications that come with the install work (e.g. clock.exe). I downloaded what I thought was a typical application that did not have any additional dlls (putty.exe) but it immediately returns with: wine: Invalid address I am a fairly competent c programmer but I was hoping I could get some pointers on where to get started since there is a lot of codebase to wade through. If you think it cannot be done by a newbie please don't hesitate to say so :) Thanks! = Mark ----------------------- Here is the results from windump putty.exe File Header Machine: 01C0 (ARM) Number of Sections: 5 TimeDateStamp: 45E5F329 (Wed Feb 28 15:24:57 2007) offset 216 PointerToSymbolTable: 00000000 NumberOfSymbols: 00000000 SizeOfOptionalHeader: 00E0 Characteristics: 010F RELOCS_STRIPPED EXECUTABLE_IMAGE LINE_NUMS_STRIPPED LOCAL_SYMS_STRIPPED 32BIT_MACHINE Optional Header (32bit) Magic 0x10B 267 linker version 6.24 size of code 0x53c00 343040 size of initialized data 0x1f200 127488 size of uninitialized data 0x0 0 entrypoint RVA 0x5499c 346524 base of code 0x1000 4096 base of data 0x55000 348160 image base 0x10000 65536 section align 0x1000 4096 file align 0x200 512 required OS version 4.00 image version 0.00 subsystem version 4.20 Win32 Version 0x0 0 size of image 0x75000 479232 size of headers 0x400 1024 checksum 0x0 0 Subsystem 0x9 (Windows CE GUI) DLL characteristics: 0x0 stack reserve size 0x10000 65536 stack commit size 0x1000 4096 heap reserve size 0x100000 1048576 heap commit size 0x1000 4096 loader flags 0x0 0 RVAs & sizes 0x10 16 Data Directory EXPORT rva: 0x0 size: 0x0 IMPORT rva: 0x62258 size: 0x28 RESOURCE rva: 0x73000 size: 0x1f4c EXCEPTION rva: 0x71000 size: 0x1e90 SECURITY rva: 0x0 size: 0x0 BASERELOC rva: 0x0 size: 0x0 DEBUG rva: 0x0 size: 0x0 ARCHITECTURE rva: 0x0 size: 0x0 GLOBALPTR rva: 0x0 size: 0x0 TLS rva: 0x0 size: 0x0 LOAD_CONFIG rva: 0x0 size: 0x0 Bound IAT rva: 0x0 size: 0x0 IAT rva: 0x63000 size: 0x368 Delay IAT rva: 0x0 size: 0x0 CLR Header rva: 0x0 size: 0x0 rva: 0x0 size: 0x0 ----------------- Here is the last several lines from setting WINDEDEBUG=+all 0030: open_key( parent=0010, access=000f003f, attributes=00000000, name=L"Software\\Wine\\DllOverrides" ) 0030: open_key() = OBJECT_NAME_NOT_FOUND { hkey=0000 } 0030: close_handle( handle=0010 ) 0030: close_handle() = 0 0030: get_handle_fd( handle=000c ) 0030: *fd* 000c -> 21 0030: get_handle_fd() = 0 { type=1, cacheable=1, access=00120089, options=00000000 } 0030: create_mapping( access=000f0005, attributes=00000000, protect=00000145, size=00000000, file_handle=000c, objattr={rootdir=0000,sd={},name=L""} ) 0030: create_mapping() = 0 { handle=0010 } 0030: get_mapping_info( handle=0010, access=00000004 ) 0030: get_mapping_info() = 0 { size=00075000, protect=325, header_size=1024, base=00010000, mapping=0014, shared_file=0000 } 0030: get_handle_fd( handle=0010 ) 0030: *fd* 0010 -> 22 0030: get_handle_fd() = 0 { type=1, cacheable=1, access=000f0005, options=00000020 } 0030: close_handle( handle=0014 ) 0030: close_handle() = 0 0030: close_handle( handle=0010 ) 0030: close_handle() = 0 0030: close_handle( handle=000c ) 0030: close_handle() = 0 0030: terminate_process( handle=0000, exit_code=487 ) 0030: terminate_process() = 0 { self=1 } 0030: terminate_process( handle=ffffffff, exit_code=487 ) 0030: terminate_process() = 0 { self=1 } 0030: *killed* exit_code=487 002f: *process killed*

2 1

Re: [PATCH 3/3] ws2_32: Add an interactive test for interface change notifications (rebased).
by Marvin 12 Nov '13

12 Nov '13

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://newtestbot.winehq.org/JobDetails.pl?Key=3330 Your paranoid android. === wxppro (32 bit sock) === sock.c:520: Test failed: oob_server (470): unexpectedly at the OOB mark: 0 === w2008s64 (32 bit sock) === sock.c:510: Test failed: oob_server (7a4): unexpectedly at the OOB mark: 0 sock.c:520: Test failed: oob_server (7a4): unexpectedly at the OOB mark: 0 sock: unhandled exception c0000005 at 757C9799 === w2008s64 (64 bit sock) === sock.c:520: Test failed: oob_server (704): unexpectedly at the OOB mark: 0 === w864 (64 bit sock) === sock.c:1748: Test failed: getservbyname: winsock resized servent buffer when not necessary

1 0

Re: [PATCH 1/5] d3d8: Clear pBits and Pitch when d3d8_surface_LockRect() fails.
by Marvin 12 Nov '13

12 Nov '13

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://newtestbot.winehq.org/JobDetails.pl?Key=3328 Your paranoid android. === w8 (32 bit device) === device.c:2494: Test failed: Expected foreground window 00030196, got 0002004E. device.c:3190: Test failed: Expected wndproc 0x40fff0, got 0x40fff0. === w864 (32 bit device) === device.c:2494: Test failed: Expected foreground window 0004017A, got 0001007A. device.c:3190: Test failed: Expected wndproc 0x40fff0, got 0x40fff0.

1 0

Re: user32/tests: Fix GetSystemMetrics on Win8
by Marvin 11 Nov '13

11 Nov '13

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://newtestbot.winehq.org/JobDetails.pl?Key=3326 Your paranoid android. === w8 (32 bit sysparams) === sysparams.c:2488: Test failed: Waiting for the WM_DISPLAYCHANGE message timed out sysparams.c:2501: Test failed: Set bpp 32, but WM_DISPLAYCHANGE reported bpp -1 === w864 (32 bit sysparams) === sysparams.c:2488: Test failed: Waiting for the WM_DISPLAYCHANGE message timed out sysparams.c:2501: Test failed: Set bpp 32, but WM_DISPLAYCHANGE reported bpp -1

1 0