September 2012 - Wine-Devel

Re: jscript: Fixed empty cases in the end of switch statement

by Marvin

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 http://testbot.winehq.org/JobDetails.pl?Key=21379 Your paranoid android. === WNT4WSSP6 (32 bit) === No test summary line found === W2KPROSP4 (32 bit) === No test summary line found === WXPPROSP3 (32 bit) === No test summary line found === W2K3R2SESP2 (32 bit) === No test summary line found === WVISTAADM (32 bit) === No test summary line found === W2K8SE (32 bit) === No test summary line found === W7PRO (32 bit) === No test summary line found === W7PROX64 (32 bit) === No test summary line found === TEST64_W7SP1 (32 bit) === No test summary line found === W7PROX64 (64 bit) === No test summary line found === TEST64_W7SP1 (64 bit) === No test summary line found

Sept. 4, 2012

Re: d3dx9_36 [try 3]: Implement D3DXSHRotate

by Rico Schüller

On 04.09.2012 13:19, Nozomi Kodama wrote: + FLOAT expected, in[100], out[100], ... + for (i = 0; i < 49; i++) + in[i] = i + 1.01f; I guess this belongs together. I'd like to make some suggestions, please don't take it personally. When you got a comment on a patch, read it carefully. Think about it, if it makes sens to do the change (just adding what I've said is not always the best, it just gives you a hint, that you may improve some things, the list is not always complete and different people may have different suggestions) and try to improve your patch. After you are done, read your patch. Well mistakes happen, especially when you try to get something done really fast. (1) Take you some time and read it again and see if you've done that as best as possible and if you are happy with the code you've done, then submit it. If you've found a bug don't submit, fix it and go to #1. The earlier a bug is found the cheaper is it to solve it. I hope this helps a bit and it hopefully saves you some time to get a patch in the feature accepted. Thought I'd like to thank you for your patience and hopefully I haven't annoyed you and we'll see some good quality patches in the feature from you. :-) Cheers Rico

Sept. 4, 2012

Re: [PATCH 1/4] mshtml: Properly expose frame and iframe element's windows to scripts

by Marvin

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 http://testbot.winehq.org/JobDetails.pl?Key=21376 Your paranoid android. === W2KPROSP4 (32 bit) === No test summary line found === WXPPROSP3 (32 bit) === No test summary line found === W2K3R2SESP2 (32 bit) === No test summary line found === WVISTAADM (32 bit) === No test summary line found === W2K8SE (32 bit) === No test summary line found === W7PRO (32 bit) === No test summary line found === W7PROX64 (32 bit) === No test summary line found === TEST64_W7SP1 (32 bit) === No test summary line found === W7PROX64 (64 bit) === No test summary line found === TEST64_W7SP1 (64 bit) === No test summary line found

Sept. 4, 2012

Re: Wine Gecko 1.8-beta1

by Dmitry Timoshkov

Vincent Povirk <madewokherd(a)gmail.com> wrote: > > On related note, I seriously consider dropping debug builds and replace > > them by unstripped release build or even just a separated package > > containing only debug symbols for the release build. > > No one has complained about the debugging symbols in Wine Mono yet. > They are included mostly because I don't know how to get rid of them, > and it seems silly to put effort into that given the debug symbols > have proven useful so far. So, I decided to have a look at ~/.wine/drive_c/windows/mono sizes, and was pretty surprized by the result: cd ~/.wine/drive_c/windows du -h ./mono 121M ./mono find ./mono -type f -exec strip {} \; du -h ./mono 104M ./mono So, it's not the debug symbols that creates all that bloat in mono. -- Dmitry.

Sept. 4, 2012

Re: d3dx9_36 [try 2]: Implement D3DXSHRotate

by Rico Schüller

On 03.09.2012 20:59, Nozomi Kodama wrote: > Thanks Rico and Henri for your help. > > Nozomi > > > The patch looks much better now. But I have some minor things which I didn't mention last time... + ok(received_ptr == out, "order %u, Expected %p, received %p\n", order, out, received_ptr); We may write the variables all starting with upper or lower char, maybe the first word will start with a upper char and the rest with a lower char. The mixture as is looks a bit ugly, doesn't it? Please have a look at the surrounding code, but not at test_D3DXSHRotateZ. ;-) And of course only going til 7 we won't need the in/out array till 100. 49 should fit, shouldn't it? That would be reducing the time spend in the for loops, even if it's only the test... Cheers Rico

Sept. 4, 2012

Re: Building winetest-latest.exe?

by Dan Kegel

On Mon, Sep 3, 2012 at 2:28 PM, Austin English <austinenglish(a)gmail.com> wrote: > On Sun, Sep 2, 2012 at 9:52 PM, Vincent Povirk <madewokherd(a)gmail.com> wrote: >> As I understand it, you need to set up a mingw build as in >> http://wiki.winehq.org/CompilingDLLsUsingMingw > > Sort of. You don't need a separate build tree for building the tests. > Just have mingw32 installed, run ./configure, then 'make crosstest'. I've done 'make crosstest' many times, but building winetest.exe itself does seem to require the two trees as described by that page. (But as it turns out, the code I needed to fix was in buildbot, not winetest.) - Dan

Sept. 3, 2012

Re: Building winetest-latest.exe?

by Austin English

On Sun, Sep 2, 2012 at 9:52 PM, Vincent Povirk <madewokherd(a)gmail.com> wrote: > As I understand it, you need to set up a mingw build as in > http://wiki.winehq.org/CompilingDLLsUsingMingw Sort of. You don't need a separate build tree for building the tests. Just have mingw32 installed, run ./configure, then 'make crosstest'. -- -Austin

Sept. 3, 2012

Re: wined3d: Use backup swapchain DC for devices created with desktop window. (try 2)

by Adam Jakubek

On Mon, Sep 3, 2012 at 6:29 PM, Stefan Dösinger <stefandoesinger(a)gmx.at>wrote: > I skimmed bug #18490, and I'm wondering about two things: Does the app > create > a D3DDEVTYPE_REF or D3DDEVTYPE_NULLREF device? Once the device is created, > what does it to with it? A +d3d log would provide some answers. > Ok, this needs a little correction on my part. The game actually creates D3DEVTYPE_HAL (I somehow previously concluded it wouldn't work, since on my test machine it required software vertex processing). Here is the relevant log line: trace:d3d:wined3d_device_create wined3d 0x235ce558, adapter_idx 0, device_type 0x1, focus_window 0x20026, flags 0x22, device_parent 0x2284cc0c, device 0x2284cc14. Focus window is the desktop handle. Presentation parameters specify windowed mode and hDeviceWindow=NULL, so in the end it uses the desktop window. It seems to be some kind of short-lived auxiliary device for texture operations. It's not used for rendering at all. The only operations on that device I could find is a series of CreateTexture calls: trace:d3d9:d3d9_device_CreateTexture iface 0x2284cc08, width 2048, height 2048, levels 1, usage 0, format 0x15, pool 0x2, texture 0x33be40, shared_handle (nil). They are followed by several LockRect/UnlockRect calls, after which the textures are released. The device is released immediately after that. Originally I suspected this might be used to generate mip-maps or load textures with d3dx, but the presence of D3DPOOL_SYSTEMMEM excludes both. I admit that it's a very non-standard way of creating a D3D device, since it can't render anything. However it seems to work for this particular use case. Regards, Adam Jakubek

Sept. 3, 2012

Re: vcomp.dll, vcomp90.dll missing on testbot?

by Dan Kegel

On Sun, Sep 2, 2012 at 1:14 PM, Dan Kegel <dank(a)kegel.com> wrote: > On Wed, Aug 8, 2012 at 7:27 AM, Dan Kegel <dank(a)kegel.com> wrote: >> Testing vcomp100 does work, but I shouldn't need to >> do that until there's some vcomp100-specific code. >> >> msvcr90/tests just adds a manifest, and that works. > > Heh. It does add a manifest, but I don't think it works. > See http://bugs.winehq.org/show_bug.cgi?id=31603 And I found the problem on testbot, too: http://bugs.winehq.org/show_bug.cgi?id=31609

Sept. 3, 2012

Re: wined3d: Use backup swapchain DC for devices created with desktop window. (try 2)

by Stefan Dösinger

Am Montag, 3. September 2012, 04:06:01 schrieb Adam Jakubek: > Previous version failed on test bots. > Added test case skipping when no device can be created with normal > (non-desktop) window. I skimmed bug #18490, and I'm wondering about two things: Does the app create a D3DDEVTYPE_REF or D3DDEVTYPE_NULLREF device? Once the device is created, what does it to with it? A +d3d log would provide some answers. This is some guesswork: I don't think the game creates a _REF device because REF devices require the user to install the reference rasterizer dll, as Matteo already mentioned. If it's a NULLREF device I wonder what the game is able to do with it. The bug report has a link which promises some clues, but the link is dead. Stefan

Sept. 3, 2012