- wine-devel - winehq.org

Re: [1/5] msi/tests: Use a different product code in the package tests to avoid cascading test failures.
by testbot＠testbot.winehq.org 27 Aug '10

27 Aug '10

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=4818 Your paranoid android. === W7PROX64 (64 bit package) === package.c:8385: Test failed: Expected "C:\winetest\FileName1", got "" package.c:8396: Test failed: Expected "C:\winetest\", got "" package.c:8407: Test failed: Expected "C:\winetest\", got "" package.c:8457: Test failed: Expected "C:\winetest\FileName3.dll", got "" package.c:8468: Test failed: Expected "C:\winetest\FileName5.dll", got "" package.c:8477: Test failed: Expected "C:\", got "" package.c:8483: Test failed: Expected "C:\winetest\", got "" package.c:8504: Test failed: Expected "C:\winetest\FileName1", got "" package.c:8513: Test failed: Expected "C:\winetest\FileName1", got ""

1 0

Re: kernel32: add error text for WSAECONNREFUSED
by Dmitry Timoshkov 27 Aug '10

27 Aug '10

Dan Kegel <dank(a)kegel.com> wrote: > This gets Pando-based installers further, see > http://bugs.winehq.org/show_bug.cgi?id=24019 > > There's obviously more to do here, but this little bit is useful. Please simultaneously add it to all other language files. -- Dmitry.

1 0

Re: windowscodecs: support ICO files with embedded PNGs
by Vincent Povirk 27 Aug '10

27 Aug '10

You mean you're not going to implement IWICStream::InitializeFromIStreamRegion? That's no fun. Also, that read loop is a bit silly. You might as well just lock the HGLOBAL and read into it directly. On Fri, Aug 27, 2010 at 12:30 AM, Damjan Jovanovic <damjan.jov(a)gmail.com> wrote: > Changelog: > * windowscodecs: support ICO files with embedded PNGs > Closes #23708. > Damjan Jovanovic > > > >

2 1

Re: mpr: Fix translations
by James McKenzie 27 Aug '10

27 Aug '10

Amine Khaldi wrote: [nothing] Can you please put some sort of tracking information when resubmitting a patch like [try2]. This will keep those of us who are manually tracking and applying your fixes in sync. Thank you. James McKenzie

1 0

RFC: Resolving a full screen bug
by Erich Hoover 27 Aug '10

27 Aug '10

I've been periodically revisiting a patch I've been using to fix a bug with running Borderlands under Wine at the same resolution as the desktop ( original message: http://www.winehq.org/pipermail/wine-devel/2010-May/083339.html ). Attached is an iteration that appears to resolve the issue without impacting the other applications I normally run. It appears that the problem arises since Borderlands goes straight from being iconified to being exactly the desktop resolution, as a result Wine never turns off the "iconic" flag - so the application window is not sized or positioned properly. I would appreciate it if I could get some feedback on this patch, it doesn't seem to break anything but it would be nice to have an expert opinion. Erich Hoover ehoover(a)mines.edu

2 2

Re: user32: Make GetMessage and PeekMessage patchable
by Henri Verbeet 26 Aug '10

26 Aug '10

On 26 August 2010 15:51, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > From: =?UTF-8?q?Stefan=20D=C3=B6singer?= <stefan(a)macbook.local> Please configure git properly?

2 1

Inviting Mono and pulseaudio to wineconf?
by Dan Kegel 26 Aug '10

26 Aug '10

Would it be appropriate and useful to invite someone from Mono and Pulseaudio to attend Wineconf this year? We do have to work well with those projects, maybe that would help solve a couple current or future problems.

8 15

Re: [PATCH] inetcpl: Add initial applet
by Juan Lang 26 Aug '10

26 Aug '10

Hi Detlef, were you planning to resubmit this patch? [1] A user asked how to import a certificate recently [2], and I directed him to install ie6 to do so, but that has a lot of side effects which may not be wanted. Using our own inetcpl.cpl would allow us to avoid that, by exposing cryptui.CryptUICertMgr without using any native DLLs. Thanks, --Juan [1] http://www.winehq.org/pipermail/wine-patches/2010-May/088373.html [2] http://forum.winehq.org/viewtopic.php?t=9399

2 1

Re: shell32: Add a navigation pane to the ExplorerBrowser control.
by Juan Lang 26 Aug '10

26 Aug '10

Hi David, I know this was committed already, but something caught my eye that I didn't understand: + if(This->navpane.show ^ show_navpane) Is this a cute way to write if(This->navpane.show && show_navpane) ? If so, why ^ rather than &&? Thanks, --Juan

3 3

Re: ddraw/tests: New visual back buffer flipping tests. (try 3)
by Stefan Dösinger 26 Aug '10

26 Aug '10

> + hr = IDirectDrawSurface_AddAttachedSurface(Primary, Backbuffer); > + todo_wine ok(hr == DD_OK || broken(hr == DDERR_CANNOTATTACHSURFACE), > + "Attaching a back buffer to a front buffer returned %08x\n", hr); The patch looks OK. Out of curiosity, which windows system returns DDERR_CANNOTATTACHSURFACE? Allowing this result with broken() is OK since you have an application that depends on this behavior.

2 1

Re: Inviting Mono and pulseaudio to wineconf?
by James Mckenzie 26 Aug '10

26 Aug '10

Vincent Povirk <madewokherd(a)gmail.com> wrote: >Sent: Aug 26, 2010 9:03 AM >To: Dan Kegel <dank(a)kegel.com> >Cc: wine-devel(a)winehq.org, Stefan Dösinger <stefandoesinger(a)gmx.at> >Subject: Re: Inviting Mono and pulseaudio to wineconf? > >> Mono: >> Vincent, what do you think? Probably they're not holding us up, >> but maybe they'd like to see a presentation from you about >> status of Mono integration? > >Oh geez. Um. Well, they are indeed not holding us up. In all my >communication with them, they've been very helpful. > Since Microsoft appears to have taken a hostile turn towards anything released with Windows 7, WMP 10, .NET .3.5 + working with Wine, it would be very interesting to see what the Mono team's stance is on integration with Wine and the path onward. At one time it was very hostile, now it seems to have changed to at least neutral and maybe even what we call 'hallway' friendly. >I don't know that the current status of Mono integration is much to talk about. > >> http://wiki.winehq.org/Mono is looking good. (Think there's a Summer >> of Code 2011 project or two in there?) > >Judging by bugzilla, there don't seem to be any large projects that >would help compatibility enough to be worthwhile. All the mscoree bugs >only affect one app. > Hmmm. Maybe we need to widen the 'gene pool' to see if other applications are affected. James McKenzie

1 0

Re: : Use SUBLANG_NEUTRAL for language-independent resources
by Greg Geldorp 26 Aug '10

26 Aug '10

> From: Francois Gouget <fgouget(a)free.fr> > > According to past Winetest results these platforms could (should?) have > it though. A full log is strange but I don't how it could be cause by my > patch: > > gameux: start - - > Usage: C:\winetest\gameux_test64.exe test_name > > Valid test names: > gameexplorer > gamestatistics > gameux: done (1) > > No test summary line found Your patch only changed the .rc file. TestBot doesn't know what tests to run in that case (it determines the tests to run from the .c files that were changed). Same kind of thing happens when the .js files for the jscript.dll tests are changed. I'll see if I can teach it to just run all tests in these cases. Ge.

1 0

Re: [5/5] d3d10: Implement D3D10CompileShader, forward to d3dcompiler.
by Henri Verbeet 26 Aug '10

26 Aug '10

On 26 August 2010 17:26, Matteo Bruni <matteo.mystral(a)gmail.com> wrote: > +#define COBJMACROS > #include "config.h" > #include "wine/port.h" > - > +#include "objbase.h" > +#include "d3dcompiler.h" > #include "d3d10_private.h" You should probably just include d3dcompiler.h from d3d10_private.h.

1 0

Re: [2/5] d3dcompiler: Stub D3DCompile implementation.
by Henri Verbeet 26 Aug '10

26 Aug '10

On 26 August 2010 17:26, Matteo Bruni <matteo.mystral(a)gmail.com> wrote: > Please stick to the coding style used in the rest of the d3d10 dlls (see e.g. blob.c for reference). This applies to patches 4 and 5 as well.

1 0

Re: gameux: Use SUBLANG_NEUTRAL for language-independent resources.
by testbot＠testbot.winehq.org 26 Aug '10

26 Aug '10

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=4787 Your paranoid android. === W98SE (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 === W7PROX64 (64 bit) === No test summary line found

2 1

Use SUBLANG_NEUTRAL for the Gaelic resources?
by Francois Gouget 26 Aug '10

26 Aug '10

Are SUBLANG_GAELIC, SUBLANG_GAELIC_SCOTTISH and SUBLANG_GAELIC_MANX very different languages? If not it would be better to use SUBLANG_NEUTRAL instead of SUBLANG_GAELIC. For instance: dlls/mapi32/Ga.rc | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/dlls/mapi32/Ga.rc b/dlls/mapi32/Ga.rc index e8aa3c0..104a658 100644 --- a/dlls/mapi32/Ga.rc +++ b/dlls/mapi32/Ga.rc @@ -22,7 +22,7 @@ #include "res.h" -LANGUAGE LANG_GAELIC, SUBLANG_GAELIC +LANGUAGE LANG_GAELIC, SUBLANG_NEUTRAL STRINGTABLE { -- 1.7.1

2 2

Re: [PATCH 4/5] shell32: Add INameSpaceTreeControlEvents stub to the ExplorerBrowser control.
by Nikolay Sivov 26 Aug '10

26 Aug '10

On 8/26/2010 14:53, David Hedberg wrote: > + *ppvObject = NULL; > + if(IsEqualIID(riid,&IID_INameSpaceTreeControlEvents)) > + { > + *ppvObject = iface; > + } > + Why don't you allow IUnknown here?

2 1

Re: [PATCH 1/5] shell32: Check for ICommDlgBrowser from Site and use it in the IExplorerBrowser control.
by Nikolay Sivov 26 Aug '10

26 Aug '10

On 8/26/2010 14:53, David Hedberg wrote: > --- > dlls/shell32/ebrowser.c | 98 +++++++++++++++++++---- > dlls/shell32/tests/ebrowser.c | 174 ++++++++++++++++++++++++++++++++++++++++- > 2 files changed, 251 insertions(+), 21 deletions(-) > > diff --git a/dlls/shell32/ebrowser.c b/dlls/shell32/ebrowser.c > index b243aa0..1137880 100644 > --- a/dlls/shell32/ebrowser.c > +++ b/dlls/shell32/ebrowser.c > @@ -73,6 +73,8 @@ typedef struct _ExplorerBrowserImpl { > LPITEMIDLIST current_pidl; > > IUnknown *punk_site; > + ICommDlgBrowser3 *pcdb3_site; > + UINT cdb_site_supported; > } ExplorerBrowserImpl; I think a better way for this would be to store a pointer for each interface version, instead of having additional switch. When you have separate pointers a call looks more obvious like: if (pcdb_site) ICommDlgBrowser_*(pcdb_site).

2 1

Re: mpr: Fix Czech translation.
by Alexandre Julliard 26 Aug '10

26 Aug '10

Amine Khaldi <amine.khaldi(a)reactos.org> writes: > Regards, > Amine. There's no need to send a separate patch for each language, it's the same change for all. Also make sure your mailer doesn't mangle the high bit chars. -- Alexandre Julliard julliard(a)winehq.org

1 0

[PATCH 1/3] winmm: Fix mciSendString command parsing on 64-bit.
by Joerg-Cyril.Hoehle＠t-systems.com 26 Aug '10

26 Aug '10

Octavian, are you aware of bug http://bugs.winehq.org/show_bug.cgi?id=22146 and the partial patch and additional test cases there? >winmm: Add MCI_INTEGER_PTR return type for DWORD_PTR return values. >+#define MCI_INTEGER_PTR 13 What kind of testing did you perform on native systems to derive the existence of this value? If such value does not exist, then I fear your patch set looses the ability to drop in native dlls for compatibility testing and validation. If it exists, then it's good news you found it. >-static DWORD MCI_ParseOptArgs(DWORD_PTR* data, int _offset, LPCWSTR lpCmd, >+static DWORD MCI_ParseOptArgs(BYTE* data, int _offset, LPCWSTR lpCmd, >- if (!MCI_GetDWord(&(data[offset+0]), &args) || >- !MCI_GetDWord(&(data[offset+1]), &args) || >- !MCI_GetDWord(&(data[offset+2]), &args) || >- !MCI_GetDWord(&(data[offset+3]), &args)) { >+ if (!MCI_GetDWord(data+offset+0*sizeof(DWORD), &args) || >+ !MCI_GetDWord(data+offset+1*sizeof(DWORD), &args) || >+ !MCI_GetDWord(data+offset+2*sizeof(DWORD), &args) || >+ !MCI_GetDWord(data+offset+3*sizeof(DWORD), &args)) { The MCI_XYZ_PARMS structures are neither DWORD_PTR, not BYTE*, they are DWORD with some DWORD_PTR in between. Wouldn't using DWORD* data help avoid such pointer arithmetic and eliminate several hunks of the patch ? Regards, Jörg Höhle

1 0

Re: winetrick & mono dot net 3.5 emmulation.
by Hin-Tak Leung 26 Aug '10

26 Aug '10

apologies - for laziness, I picked one message with Dan Kegel and did a reply and emptied subject/body. I guess that messes up e-mail software that actually uses the invisible headers for threads. -------- Original Message -------- Subject: Re: winetrick & mono dot net 3.5 emmulation. Date: Wed, 25 Aug 2010 21:01:09 -0700 From: James McKenzie <jjmckenzie51(a)earthlink.net> To: Hin-Tak Leung <hintak_leung(a)yahoo.co.uk> Hin-Tak Leung wrote: > The installer of one application I have requires Net 3.5 and refuses > to install > if it is not detected. Yet it runs adequately well with mono 2.6.x > (when installed to Vista then copied over). So I am wondering if there > should be a winetrick "lie about having .net 3.5" registry setting, > and go about seeing what needs to be done - e.g. how is that installer > detecting dot net 3.5 ? > > > > Can you open a separate thread for this? I'm going ahead and deleting all of the messages from the hijacked thread on my system and you have a very good point to make. James McKenzie

1 0

WineConf 2010
by Francois Gouget 25 Aug '10

25 Aug '10

WineConf 2010 is now all set: Where: Hotel Ibis Bastille in Paris When: November, Saturday 20th ~9am to Sunday 21st ~5pm You should book your hotel room directly from the hotel; the sooner the better. Also if you have not booked your plane tickets yet, this is your reminder. All the details should be available on the WineConf 2010 wiki page: http://wiki.winehq.org/WineConf2010 Again, note that most further communication will happen on the wineconf(a)winehq.org mailing list. So subscribe there to be sure not to miss the latest news. This is also the place to go if you have questions, etc. I hope to see you all in Paris! -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ RFC 2549: ftp://ftp.isi.edu/in-notes/rfc2549.txt IP over Avian Carriers with Quality of Service

1 0

Re: [PATCH 2/7] d3dx9_36/tests: Added HLSL test suite
by Henri Verbeet 25 Aug '10

25 Aug '10

On 25 August 2010 09:58, Travis Athougies <iammisc(a)gmail.com> wrote: > +static IDirect3DPixelShader9* compile_pixel_shader(IDirect3DDevice9* device, const char *shader, const char *profile,· > +»······»·······»·······»·······»·······»······· ID3DXConstantTable **constants) You still have basic formatting errors like trailing spaces, mixing tabs and spaces, inconsistent "*" placement, etc. > + hres = IDirect3DDevice9_CreateVertexShader(device_ptr, (DWORD*) ID3DXBuffer_GetBufferPointer(compiled), &vshader_passthru); Here's another unnecessary cast. For the record, I'm not going to point out every single flaw in every single patch. If I find an issue in a patch, you should take that as a hint that perhaps you didn't review your patches careful enough before sending them, and go over them again yourself. Anyway, we've decided to implement the shader assembler and compiler in the d3dcompiler dll. I think it makes sense to move any compiler/assembler tests there as well. Note that I'm going to request that d3dcompiler follows the same general style as used in dxgi/d3d10core/d3d10, this is different from the style used in most of d3dx9. Something else. In my opinion an internship should imply some level of guidance/training, not simply "cheap labor". In particular, while ideally you would have caught the issues mentioned in this and previous reviews yourself, whoever has been mentoring you certainly should have, these are basic C / Wine development issues. The process is supposed to look somewhat like this: 1. Carefully write the patch. 2. Carefully review the patch. 3. If you find any issues, carefully fix them and go back to 2. 4. Run the test suite. 5. If it finds any issues, carefully fix them and go back to 2. 6. Send the patch to your mentor for review. 7. If he finds any issues, carefully fix them and go back to 2. 8. If it's still the same day as on 1, consider waiting a day, so you can give the patch a fresh look in the next step. 9. Repeat steps 2 through 5 before sending the patch to wine-patches. 10. Send the patch to wine-patches. 11. If it finds any issues, carefully fix them and go back to 2. Replace "patch" with "patchset" if you're doing more complicated things. Ideally step 6 would produce something like a "Signed-off-by" or "Reviewed-by" tag. If you're at step 11 for the third or fourth time, and there are still problems with the patch, there are structural failures at 1, 2 and 6. Failures at 1 and 2 are somewhat expected for an internship, depending on what kind of standards a specific organization sets, but that's exactly what step 6 is supposed to catch. I.e., when I find an issue in a patch that means at the very least that you didn't catch it when writing the patch, didn't catch it when reviewing the patch the first time, your mentor didn't catch it, and you didn't catch it during review before sending the patch. The things wine-patches reviews are supposed to catch are non-trivial interactions with other parts of the code, not trivial whitespace errors.

1 0

Re: mscoree: improve GetCORSytemDirectory
by testbot＠testbot.winehq.org 25 Aug '10

25 Aug '10

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=4758 Your paranoid android. === WINEBUILD (build) === Patch failed

1 0

Re: d3dx9: Implement D3DXDeclaratorFromFVF. (try 2)
by Henri Verbeet 25 Aug '10

25 Aug '10

On 24 August 2010 05:05, Misha Koshelev <misha680(a)gmail.com> wrote: > + elements[idx].Stream = 0xFF; > + elements[idx].Offset = D3DXGetDeclVertexSize(elements, 0); > + elements[idx].Stream = 0; That's ugly. > + memcpy(Declaration, elements, size * sizeof(D3DVERTEXELEMENT9)); That's unnecessary.

3 4

"Spanish - Modern Sort_Spain.1252" locale on wine
by GOUJON Alexandre 25 Aug '10

25 Aug '10

Hi everyone, I'm trying to fix msvcrt:locale on wine and it appears "Spanish - Modern Sort_Spain.1252" locale is missing. According to msdn (http://msdn.microsoft.com/en-us/library/39cwe7zf%28v=VS.71%29.aspx), "esn" and "spanish-modern" are equivalent which is false [quoted from msvcrt/tests/locale.c] ret = setlocale(LC_ALL, "esn"); ok(ret != NULL || broken (ret == NULL), "ret == NULL\n"); if(ret) ok(!strcmp(ret, "Spanish_Spain.1252") || broken(!strcmp(ret, "Spanish - Modern Sort_Spain.1252")), "ret = %s\n", ret); and ret = setlocale(LC_ALL, "spanish-modern"); ok(ret != NULL || broken (ret == NULL), "ret == NULL\n"); if(ret) ok(!strcmp(ret, "Spanish - Modern Sort_Spain.1252") || broken(!strcmp(ret, "Spanish_Spain.1252")), "ret = %s\n", ret); If I modify dlls/kernerl32/nls/esn.nls LOCALE_SENGLANGUAGE "Spanish" to LOCALE_SENGLANGUAGE "Spanish - Modern Sort" then it'll fix the second test and break the first one. So I'm wondering what to do. Create another nls file based on esn with a different LOCALE_SENGLANGUAGE ? (and change _country_synonyms[] in locale.c) Hard code this (i.e. if .. == "spanish-modern" .. ) ? Other advice ? Thanks in advance

1 0

Re: ddraw [try 3]: SetCooperativeLevel with Full screen + exclusive + normal is authorized
by Henri Verbeet 25 Aug '10

25 Aug '10

On 25 August 2010 08:48, David Adam <david.adam.cnrs(a)gmail.com> wrote: > + if(cooplevel == (DDSCL_NORMAL | DDSCL_EXCLUSIVE) ) So what happens if you set e.g. "DDSCL_NORMAL | DDSCL_EXCLUSIVE | DDSCL_FPUPRESERVE"? You also still have trailing spaces. The way this would conceptually make sense to me is if you always need either NORMAL or EXCLUSIVE, with NORMAL | EXCLUSIVE -> EXCLUSIVE and EXCLUSIVE requiring FULLSCREEN. (Well, except for SETFOCUSWINDOW, which seems to live in a world of its own.) I.e., something along these lines: if (coop & SETFOCUSWINDOW) { ... return; } if (coop & EXCLUSIVE) { if (!(coop & FULLSCREEN)) fail(); ... } else if (coop & NORMAL) { ... } else fail();

1 0

wined3d and visual studio: The remaining uglyness
by Stefan Dösinger 25 Aug '10

25 Aug '10

Hi, I've spent some time to get wined3d to compile with visual studio on Windows. I sent some code fixes needed for that, but a few hacks are remaining. I'm sending them here for discussion. First, why did I look at Visual Studio: *) mingw on windows a bit messy. Cross Compiling all the time even more so *) msvc is the native toolkit, it opens up many other tools. I was interested in VsPerfKit specifically. Basically I set up a Visual Studio process to compile libport, libwine, wined3d, d3d8 and d3d9 out of tree, referencing the code files via relative paths(../../wine/dlls/wined3d/*.c). This was done manually, there's no integration with Wine's native build system. That's hack #1. Unfortunately I can't attach the project right now, it's on a different computer at home. I think we have a script to generate msvc projects for the tests. Maybe the right way is to extend this to the DLLs and programs. I wrote a hand-written config.h file defining a few HAVE_XXX_H constants. That is hack #2 and relates to Alexandre's concern about the libport isnan and isinf implementations. More specific code issues: *) MIDL uses cdecl as the default calling convention for exported functions. Patch 6 in the archive fixes wined3d.idl to work correctly with midl, but this change causes a segfault in widl. *) Msvc complains that -unsigned_int is still unsigned, and the integer overflow just happens to do what you want. The easiest way is to write 0 - unsigned_int, but I'm not sure about it. *) NaN and Inf generation *) msvc doesn't like the predeclaration of **environ. It causes a unknown symbol error at link time.

1 0

Re: ddraw: SetCooperativeLevel with Full screen + exclusive + normal is authorized
by Stefan Dösinger 25 Aug '10

25 Aug '10

Hi, Your CreateSurface tests are missing in this patch(assuming that paulo lesgaz is your alter ego) There's a comment above the SetCooperativeLevel implementation that needs adjustments. > if(cooplevel & DDSCL_NORMAL) > { > - /* Can't coexist with fullscreen or exclusive */ > - if(cooplevel & (DDSCL_FULLSCREEN | DDSCL_EXCLUSIVE) ) > + /* Can't coexist with exclusive only*/ > + if(cooplevel = DDSCL_NORMAL | DDSCL_EXCLUSIVE ) This check doesn't do what you intend it to do. An application may pass NORMAL | EXCLUSIVE | FPUSETUP for instance Also, your test shows that NORMAL | EXCLUSIVE | FULLSCREEN means fullscreen mode. The CreateSurface test passes because the FULLSCREEN and EXCLUSIVE flags are added, but the window is still set up for windowed rendering. In this flag combination you want to enter the fullscreen setup codepath.

1 0

Re: ddraw [try 3]: SetCooperativeLevel with Full screen + exclusive + normal is authorized
by testbot＠testbot.winehq.org 25 Aug '10

25 Aug '10

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=4741 Your paranoid android. === W98SE (32 bit ddrawmodes) === No test summary line found === W7PROX64 (64 bit ddrawmodes) === Timeout

1 0

Re: [3/3] d3dcompiler: Move D3DAssemble tests from d3dx9_36.
by testbot＠testbot.winehq.org 24 Aug '10

24 Aug '10

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=4740 Your paranoid android. === WINEBUILD (build) === Reconfig failed

1 0

Re: [3/3] d3dcompiler: Move D3DAssemble tests from d3dx9_36.
by testbot＠testbot.winehq.org 24 Aug '10

24 Aug '10

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=4739 Your paranoid android. === WINEBUILD (build) === Reconfig failed

1 0

Re: [4/4] oleaut32/tests: Some tests for IPicture::get_Handle()
by testbot＠testbot.winehq.org 24 Aug '10

24 Aug '10

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=4738 Your paranoid android. === W7PROX64 (64 bit olepicture) === olepicture.c:796: Test failed: got 0 olepicture.c:808: Test failed: got 0

1 0

Re: [3/4] oleaut32/olepicture: Fix ::get_hPal() behaviour for certain picture types
by testbot＠testbot.winehq.org 24 Aug '10

24 Aug '10

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=4737 Your paranoid android. === W7PROX64 (64 bit olepicture) === olepicture.c:765: Test failed: got 0 olepicture.c:777: Test failed: got 0

1 0

Re: ddraw [try 2]: SetCooperativeLevel with Full screen + exclusive + normal is authorized
by Stefan Dösinger 24 Aug '10

24 Aug '10

Hi, Can you add a test that tests in which mode ddraw is after such a call? Specfically, try to create a double buffered primary surface. If this succeeds, ddraw is in fullscreen mode. If ddraw is in normal mode you'll get DDERR_NOEXCLUSIVEMODE (or similar) back. Am 24.08.2010 um 10:00 schrieb David Adam: > Fixed a typo > > A+ > > David > <0001-SetCooperativeLevel-with-Full-screen-exclusive-norma.patch>

2 5

re: wine.inf: added .NET InstallRoot key
by Dan Kegel 24 Aug '10

24 Aug '10

What is our intent with adding all these registry keys? It seems as if they are helpful for installing mono, but might get in the way of installing MS .net. If that's the intent, do y'all want me to make the dotnet20 winetricks verb remove any registry keys that confuse the dotnet20 installer?

5 6

Re: msvcrt:locale Remove todo_wine and add broken when necessary
by Octavian Voicu 24 Aug '10

24 Aug '10

On Tue, Aug 24, 2010 at 12:44 PM, Alexandre Goujon <ale.goujon(a)gmail.com> wrote: > - todo_wine ok(!strcmp(ret, "Chinese (Simplified)_People's Republic of China.936") > + ok(!strcmp(ret, "Chinese (Simplified)_People's Republic of China.936") > + || broken(!strcmp(ret, "Chinese_People's Republic of China.936")) broken() only works for tests that fail on some Windows versions; it has no effect on Wine, see [1]. Proper way to fix this bug is to make setlocale replicate Windows behavior. Octavian [1] http://source.winehq.org/git/wine.git/?a=blob;f=include/wine/test.h;h=1a980…

2 1

Wine Gecko 1.1.0 RC1
by Luca Bennati 24 Aug '10

24 Aug '10

Applied the patch to master, recompiled ok. I put the rc1 cab in /usr/share/wine/gecko/, as always. In the creation of a new prefix, it gave me an err which wasn't there before: err:mshtml:init_xpcom AutoRegister(NULL) failed: 80070057 but 'wine iexplore' works better than before (sites that crashed wine before don't crash it anymore). I investigated it a bit recreating a new prefix with 'WINEDEBUG=+mshtml winecfg' and here's the log: wine: created the configuration directory '/home/luca/.wine' trace:mshtml:register_server (1) trace:mshtml:load_gecko () trace:mshtml:install_cab (L"Z:\\usr\\bin\\..\\share\\wine\\gecko\\wine_gecko-1.1.0-rc1-x86.cab") trace:mshtml:check_version "Wine Gecko 1.1.0-rc1" trace:mshtml:load_xpcom (L"C:\\windows\\system32\\gecko\\1.1.0-rc1\\wine_gecko") fixme:system:SetProcessDPIAware stub! trace:mshtml:nsDirectoryServiceProvider_QueryInterface (IID_nsISupports 0x33d374) trace:mshtml:nsDirectoryServiceProvider_QueryInterface (IID_nsIDirectoryServiceProvider 0x33d214) trace:mshtml:nsDirectoryServiceProvider_GetFile ("GreD" 0x33d2ec 0x33d2e8) trace:mshtml:nsDirectoryServiceProvider_QueryInterface (IID_nsIDirectoryServiceProvider 0x33d214) trace:mshtml:nsDirectoryServiceProvider_GetFile ("XCurProcD" 0x33d2ec 0x33d2e8) trace:mshtml:nsDirectoryServiceProvider_QueryInterface (IID_nsIDirectoryServiceProvider 0x33bfc4) trace:mshtml:nsDirectoryServiceProvider_GetFile ("PrfDef" 0x33c09c 0x33c098) warn:mshtml:nsDirectoryServiceProvider_QueryInterface ({2f977d4b-5485-11d4-87e2-0010a4e75ef2} 0x33bff4) warn:mshtml:nsDirectoryServiceProvider_QueryInterface ({2f977d4b-5485-11d4-87e2-0010a4e75ef2} 0x33bff4) fixme:iphlpapi:NotifyAddrChange (Handle 0xf5e914, overlapped 0xf5e918): stub trace:mshtml:nsDirectoryServiceProvider_QueryInterface (IID_nsIDirectoryServiceProvider 0x33bc64) trace:mshtml:nsDirectoryServiceProvider_GetFile ("AChrom" 0x33bd3c 0x33bd38) err:mshtml:init_xpcom AutoRegister(NULL) failed: 80070057 trace:mshtml:nsIOService_GetProtocolHandler ("file" 0x33cff8) trace:mshtml:nsIOService_NewURI ("file:///C:/windows/system32/gecko/1.1.0-rc1/wine_gecko/components/nsTryToClose.js" (null) (nil) 0x33d15c) trace:mshtml:nsDirectoryServiceProvider_QueryInterface (IID_nsIDirectoryServiceProvider 0x33ccb4) trace:mshtml:nsDirectoryServiceProvider_GetFile ("ProfDS" 0x33cd8c 0x33cd88) trace:mshtml:nsDirectoryServiceProvider_QueryInterface (IID_nsIDirectoryServiceProvider 0x33ccb4) trace:mshtml:nsDirectoryServiceProvider_GetFile ("ProfD" 0x33cd8c 0x33cd88) trace:mshtml:nsDirectoryServiceProvider_QueryInterface (IID_nsIDirectoryServiceProvider 0x33ccb4) trace:mshtml:nsDirectoryServiceProvider_GetFile ("ProfLDS" 0x33cd8c 0x33cd88) trace:mshtml:nsDirectoryServiceProvider_QueryInterface (IID_nsIDirectoryServiceProvider 0x33ccb4) trace:mshtml:nsDirectoryServiceProvider_GetFile ("ProfLD" 0x33cd8c 0x33cd88) trace:mshtml:nsIOService_NewURI ("resource://gre/modules/XPCOMUtils.jsm" (null) (nil) 0x33acb8) trace:mshtml:nsDirectoryServiceProvider_QueryInterface (IID_nsIDirectoryServiceProvider 0x33851c) trace:mshtml:nsDirectoryServiceProvider_GetFile ("CurProcD" 0x3385f4 0x3385f0) trace:mshtml:nsIOService_NewFileURI (0x7613b8 0x338674) trace:mshtml:nsIOService_NewFileURI (0x7613b8 0x338674) trace:mshtml:nsIOService_NewURI ("jar:chrome/toolkit.jar!/res/" (null) 0x75f6c8 0x3386e4) trace:mshtml:nsIOService_ExtractScheme ("jar:chrome/toolkit.jar!/res/" 0x3363d0) trace:mshtml:nsIOService_NewURI ("chrome/toolkit.jar!/res/" "" 0x75f6c8 0x7613cc) trace:mshtml:nsIOService_NewURI not wraping trace:mshtml:nsIOService_NewChannelFromURI (0x75fa90 0x33acb4) trace:mshtml:nsIOService_NewChannelFromURI Could not get nsWineURI: 80004002 trace:mshtml:nsIOService_NewChannel ("file:///C:/windows/system32/gecko/1.1.0-rc1/wine_gecko/modules/XPCOMUtils.jsm" (null) (nil) 0x33acb4) trace:mshtml:close_gecko () wine: configuration in '/home/luca/.wine' has been updated. Hope it helps :)

2 1

Re: mscoree: improve GetCORVersion
by testbot＠testbot.winehq.org 24 Aug '10

24 Aug '10

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=4727 Your paranoid android. === WINEBUILD (build) === Patch failed

1 0

Re: ddraw [try 2]: SetCooperativeLevel with Full screen + exclusive + normal is authorized
by Henri Verbeet 24 Aug '10

24 Aug '10

This looks suspicious to me, you have to assume the code wasn't just added for the hell of it, even though with ddraw you're never quite sure. Do other ddraw versions behave the same? Please don't add trailing spaces, neither in the code nor in TRACEs.

2 1

Re: explorerframe/tests: Add a trailing '\n' to an ok() call.
by testbot＠testbot.winehq.org 24 Aug '10

24 Aug '10

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=4711 Your paranoid android. === W2K8SE (32 bit nstc) === nstc.c:1889: Test failed: Got event 7, count 0 nstc.c:1891: Test failed: Got event 4, count 0 nstc.c:1898: Test failed: Got event 6, count 1 nstc.c:1904: Test failed: Got event 4, count 0 nstc.c:1956: Test failed: Got event 7, count 0 nstc.c:1965: Test failed: Item not expanded. nstc.c:1968: Test failed: itemstate is 0x00000000 nstc.c:1985: Test failed: itemstate is 0x00000000 nstc.c:2111: Test failed: Got event 7, count 0 nstc.c:2118: Test failed: itemstate is 0x00000000 nstc.c:2142: Test failed: itemstate is 0x0000000c nstc.c:2157: Test failed: itemstate is 0x0000000c nstc.c:2171: Test failed: itemstate is 0x00000004 nstc.c:2183: Test failed: itemstate is 0x00000004 nstc.c:2240: Test failed: Got event 7, count 0 nstc.c:2245: Test failed: Got (0x80004005) nstc.c:2246: Test failed: psi is 00000000

1 0

Re: ddraw [try 2]: SetCooperativeLevel with Full screen + exclusive + normal is authorized
by testbot＠testbot.winehq.org 24 Aug '10

24 Aug '10

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=4710 Your paranoid android. === W98SE (32 bit ddrawmodes) === No test summary line found === W7PROX64 (64 bit ddrawmodes) === Timeout

1 0

Re: [PATCH 1/5] server: move is_removeable to fd_ops
by Mike Kaplinskiy 24 Aug '10

24 Aug '10

2 1

How managing crashing tests ?
by GOUJON Alexandre 24 Aug '10

24 Aug '10

Hi guys, A patch has been committed today saying "Make .. crashing like it does on native". I know we have to follow (genuine) Windows behavior but I'm wondering how to handle these cases. For instance, how to add a test crashing on every Windows ? Is it useful ? I mean, none program can rely on it .. since it crashes. Anyway, I've seen mainly two approaches - if(0) - /* comment the crashing ok() */ What's the difference ? And why not #if 0 ? I maybe lack some basic C knowledges but I think that /**/ and #if 0 are not added to the executable (from preprocessing stage). If it's right, it means we can then 'enable' these blocks maybe with (gdb) edit something And what about a test crashing on a specific Windows ? I guess #ifdef CRASHES_ON_NT40 is not an elegant way (even if it's currently used). Commenting such tests prevent us to check wine behavior on 'working' Windows. I attempted to use __TRY ... __EXCEPT_PAGE_FAULT in a test but it got rejected. Any advice ? Thanks

2 2

Re: ddraw/tests: New visual back buffer flipping tests. (resend)
by Octavian Voicu 24 Aug '10

24 Aug '10

2010/8/23 Oldřich Jedlička <oldium.pro(a)seznam.cz>: > + // Check it out You have a C++ style comment in this patch and I don't think it's allowed. Octavian

3 2

Re: user32: Optimize the storage of default values
by Dmitry Timoshkov 24 Aug '10

24 Aug '10

André Hentschel <nerv(a)dawncrow.de> wrote: > -static const char * const DefSysColors[] = > +static struct { > + const char *name; > + const COLORREF rgb; > +} DefSysColors[] = It should be 'static const struct {'. -- Dmitry.

1 0

RFC: test of 16 bit wine (DOS)
by Morten Rønne 24 Aug '10

24 Aug '10

Hi I have been working on creating tests for the 16 bit implementation of wine, and now I have come so far that I would like some comments on the way I have chosen to do it. 16 bit programs require a compiler that is able to create the old style address method in order to be able to test those parts of wine. I have been told by Dmitry Timoshkov that I should use OpenWatcom for that. So that is what I have done. OpenWatcom also supports building DOS32 (using a number of extenders) and WIN 3.x programs. Since the DOS program can't run in the current test enviroment, because that is new style 32 bit address method, I am using a wrapper program which start the old style program from the 32 bit environment. The wrapper also makes it possible to do a skip message in case the needed DOS program is missing (due to no OpenWatcom compiler). In order to be able to create a stand-alone DOS program I have modified the wine/test.h file so that certain parts got omitted, while others were added. This means that writing a DOS test will be the same as writing normal 32 bit tests, except that you include a different test include file. The current version uses the define __WINE_WINE_DOS16_TEST_H from the include file that defines the DOS environment, since I haven't been able to find a better name. Suggestions for a better name are most welcome. The DOS test it self, is only a very simple one because I consider this more a proof of concept than a full test. Also a full test will require a number of changes in the current 16 bit tree to move a number of definitions from .c files to .h files so the test can reference them. Once this have been commited work can start towards making more complete test of the 16 bit environment. I hope that the naming will make Wine Testbot able to detect changes to the test suite. As can be seen above the OpenWatcom compiler is needed to build the DOS 16 bit programs. Currently only Linux 32 bit platform is supported. The compiler can't be built on 64 bit yet, this includes Mac. The easiest way to install the compiler is to download the binary installer from: http://www.openwatcom.org/index.php/Download Select one of the mirrors and download the file: open-watcom-c-linux-1.9 Ignore the fact that the main download page points to other places to get the linux version. This is a binary program that you have to run. It will ask you were to install OpenWatcom and all files will be installed under that tree. After that you must add a definition of WATCOM to your shell profile, pointing it to the directory you selected. After that change PATH to search in $WATCOM/binl as the LAST thing. Watcom includes programs that are called the same as some wine programs (wrc for one), so be sure you don't find these by searching OpenWatcom last. As a note I can tell that Debian have rejected the Sybase license (under which OpenWatcom is released) as not being free, and therefore there will be no official debian packages of OpenWatcom. Best Regards Morten Rønne

2 1

Re: ddraw/tests: New visual back buffer flipping tests. (try 2)
by Octavian Voicu 24 Aug '10

24 Aug '10

2010/8/24 Oldřich Jedlička <oldium.pro(a)seznam.cz>: > + ok((GetRValue(color) == 0xFF && GetGValue(color) == 0xFF && GetBValue(color) == 0xFF) || > + broken(GetRValue(color) == 0xFF && GetGValue(color) == 0 && GetBValue(color) == 0), // broken driver > + "got R %02X G %02X B %02X, expected R FF G FF B FF\n", > + GetRValue(color), GetGValue(color), GetBValue(color)); I hate to be the bearer of bad news, but you missed one :)

2 1

Re: [PATCH 1/2] quartz/tests: move shareable code to a separate file
by testbot＠testbot.winehq.org 24 Aug '10

24 Aug '10

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=4626 Your paranoid android. === WINEBUILD (build) === Make failed

3 3

Re: ddraw: SetCooperativeLevel with Full screen + exclusive + normal is authorized
by testbot＠testbot.winehq.org 23 Aug '10

23 Aug '10

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=4696 Your paranoid android. === W98SE (32 bit ddrawmodes) === No test summary line found === W7PROX64 (64 bit ddrawmodes) === Timeout

1 0

Re: gdiplus: add a stub for GdipWindingModeOutline
by Vincent Povirk 23 Aug '10

23 Aug '10

You need to add it to the .spec file too. On Mon, Aug 23, 2010 at 4:45 PM, Austin English <austinenglish(a)gmail.com> wrote: > -- > -Austin > > > >

2 1

Re: d3dx9: Implement D3DXDeclaratorFromFVF.
by Henri Verbeet 23 Aug '10

23 Aug '10

On 20 August 2010 21:16, Misha Koshelev <misha680(a)gmail.com> wrote: > Thank you for your helpful feedback on my tests. > > This is based mostly on dlls/d3d9/vertexdeclaration.c with some > changes specific to D3DXDeclaratorFromFVF. > > Again, if there are any suggested changes please let me know. > As you already mentioned, this is pretty much another copy/paste implementation, including e.g. the useless macros and typedef.

2 4

re: New winetricks 20100822: new verb lucida
by Dan Kegel 23 Aug '10

23 Aug '10

Jacek wrote: > I still hope that gecko will be removed from winetricks at some point. > It clearly doesn't belong to winetricks. That would be nice. Does every distro install wine-gecko yet? > Also fakeie6 doesn't make sense anymore. We set these registries > by default for over 2.5 years now. OK, deleted. - Dan

2 1

Re: configure: Enable prelink on x86_64
by Alexandre Julliard 23 Aug '10

23 Aug '10

Stefan Dösinger <stefan(a)codeweavers.com> writes: > From 98e8cc5d0b5b2d397c1d904d2537c326ed36d43c Mon Sep 17 00:00:00 2001 > From: =?UTF-8?q?Stefan=20D=C3=B6singer?= <stefan(a)codeweavers.com> > Date: Sun, 22 Aug 2010 19:49:58 +0200 > Subject: [PATCH 4/4] Enable prelink on x86_64 Which app needs this? -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: avifil32: Removed sign comparison warning (sizeof expresions)
by Michael Stefaniuc 23 Aug '10

23 Aug '10

Marko Nikolic wrote: > sizeof expresion always return unsigned type, so it is casted > when comparing with signed values. This is ugly. > --- > dlls/avifil32/wavfile.c | 4 ++-- > 1 files changed, 2 insertions(+), 2 deletions(-) > > diff --git a/dlls/avifil32/wavfile.c b/dlls/avifil32/wavfile.c > index fd6d9ec..3fc934c 100644 > --- a/dlls/avifil32/wavfile.c > +++ b/dlls/avifil32/wavfile.c > @@ -803,7 +803,7 @@ static HRESULT WINAPI IAVIStream_fnSetFormat(IAVIStream *iface, LONG pos, > TRACE("(%p,%d,%p,%d)\n", iface, pos, format, formatsize); > > /* check parameters */ > - if (format == NULL || formatsize <= sizeof(PCMWAVEFORMAT)) > + if (format == NULL || formatsize <= (LONG)sizeof(PCMWAVEFORMAT)) IMHO gcc is *wrong* in emitting a warning there. sizeof(PCMWAVEFORMAT) is a compile time constant and gcc can see that sizeof(PCMWAVEFORMAT) falls well inside the number range expressible by a LONG. Logically there is no difference between formatsize <= sizeof(PCMWAVEFORMAT) and formatsize <= 16 One gives a bogus warning and the other doesn't. bye michael

4 6

Re: [PATCH 1/3] msvcp90/tests: Added basic_string<char> tests (try2)
by testbot＠testbot.winehq.org 23 Aug '10

23 Aug '10

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=4681 Your paranoid android. === WINEBUILD (build) === Make failed

1 0

Re: New winetricks 20100822: new verb lucida
by James Mckenzie 23 Aug '10

23 Aug '10

Scott Ritchie <scott(a)open-vote.org> wrote: >Sent: Aug 23, 2010 6:37 AM >To: Wine Devel <wine-devel(a)winehq.org> >Subject: Re: New winetricks 20100822: new verb lucida > >On 08/23/2010 05:01 AM, Jacek Caban wrote: >> Hi Dan, >> >> On 8/22/10 8:57 PM, Dan Kegel wrote: >>> Dan Kegel: >>> gecko: make it work even if WINE isn't set. (How did this get >>> through?) >> >> I still hope that gecko will be removed from winetricks at some point. >> It clearly doesn't belong to winetricks. >> >> Also fakeie6 doesn't make sense anymore. We set these registries by >> default for over 2.5 years now. >> > >Well on Ubuntu at least installing the Wine package will pull in the >wine-gecko package and all will be well in the world. This is the >ultimate path forward, I think. > Any word from the RedHat/CentOS/Fedora crowd? I have to fix the video on my laptop (it's just messed up) and then I can check if this happens on CentOS 5.5 as well. James McKenzie

1 0

Re: [PATCH] ntdll: set correct protection flags on sections in builtin DLLs
by Alexandre Julliard 23 Aug '10

23 Aug '10

Marcus Meissner <marcus(a)jet.franken.de> writes: > @@ -1406,7 +1409,18 @@ static void load_builtin_callback( void *module, const char *filename ) > } > virtual_create_system_view( module, nt->OptionalHeader.SizeOfImage, > VPROT_SYSTEM | VPROT_IMAGE | VPROT_COMMITTED | > - VPROT_READ | VPROT_WRITECOPY | VPROT_EXEC ); > + VPROT_READ | VPROT_WRITECOPY | VPROT_EXEC, &view ); > + > + sec = (IMAGE_SECTION_HEADER*)((char*)&nt->OptionalHeader+nt->FileHeader.SizeOfOptionalHeader); > + for (i=0;i<nt->FileHeader.NumberOfSections;i++) { > + DWORD flags = VPROT_SYSTEM | VPROT_IMAGE | VPROT_COMMITTED; > + > + if (sec[i].Characteristics & IMAGE_SCN_MEM_EXECUTE) flags |= VPROT_EXEC; > + if (sec[i].Characteristics & IMAGE_SCN_MEM_READ) flags |= VPROT_READ; > + if (sec[i].Characteristics & IMAGE_SCN_MEM_WRITE) flags |= VPROT_WRITE; > + if (sec[i].Characteristics & IMAGE_SCN_MEM_SHARED) flags |= VPROT_WRITECOPY; > + VIRTUAL_SetProt( view, (char*)module + sec[i].VirtualAddress, sec[i].Misc.VirtualSize, flags ); I don't think you want to actually change the permissions, our headers don't necessarily match the real ELF sections. (BTW, could you please convince your mailer to set a valid Message-Id?) -- Alexandre Julliard julliard(a)winehq.org

2 2

New winetricks 20100822: new verb lucida
by Dan Kegel 23 Aug '10

23 Aug '10

Another fortnight, another Winetricks. Online as always at http://kegel.com/wine/winetricks or http://winezeug.googlecode.com (Bug reports to the issue tracker at the above URL, please.) Changes: Austin English mdac26: can't download anymore, so make it a synonym for mdac27 firefox: fix install. (filenames can have spaces. Patch by depesz. Issue 153.) lucida: add new font verb lucida mingw: fix PATH Andrew Nguyen wsh57: Fix the wsh57 dependency check and remove calls to load_wsh56 helper. Dan Kegel: gecko: make it work even if WINE isn't set. (How did this get through?)

4 3

Re: [PATCH 4/6] shell32: Implement IExplorerBrowser::Advise and IExplorerBrowser::Unadvise.
by Alexandre Julliard 23 Aug '10

23 Aug '10

David Hedberg <david.hedberg(a)gmail.com> writes: > +#define EBE_IMPL(iface) \ > + ((IExplorerBrowserEventsImpl*)iface) > [...] > +static ULONG WINAPI IExplorerBrowserEvents_fnAddRef(IExplorerBrowserEvents *iface) > +{ > + return InterlockedIncrement(&(EBE_IMPL(iface)->ref)); That's ugly, declare a proper This pointer instead. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [5/5] libport: Add msvc isnan and isinf implementations
by Alexandre Julliard 23 Aug '10

23 Aug '10

Stefan Dösinger <stefan(a)codeweavers.com> writes: > @@ -31,6 +31,14 @@ int isinf(double x) > return (!(finite(x) || isnand(x))); > } > > +#elif defined(HAVE_FLOAT_H) && defined(_MSC_VER) > +#include <float.h> You should use proper configure checks instead of _MSC_VER, like we do for other similar cases. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 3/3] gameux/tests: verifying registry values created by GameExplorer
by testbot＠testbot.winehq.org 23 Aug '10

23 Aug '10

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=4676 Your paranoid android. === WVISTAADM (32 bit gameexplorer) === gameexplorer.c:450: Test failed: cannot find expected registry value gameexplorer.c:468: Test failed: cannot find expected registry value

1 0

Re: [2/6] wincodec.idl: invent an ICNS encoder CLSID
by Alexandre Julliard 23 Aug '10

23 Aug '10

Damjan Jovanovic <damjan.jov(a)gmail.com> writes: > Changelog: > * wincodec.idl: invent an ICNS encoder CLSID If it's invented it shouldn't be in a public header. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: comctl32: Remove unused last parameter from TOOLTIPS_EnumToolsT.
by Nikolay Sivov 23 Aug '10

23 Aug '10

On 8/23/2010 00:51, Gerald Pfeifer wrote: > --- > dlls/comctl32/tooltips.c | 6 ++---- > 1 files changed, 2 insertions(+), 4 deletions(-) > > diff --git a/dlls/comctl32/tooltips.c b/dlls/comctl32/tooltips.c > index 688d3b5..d17f067 100644 > --- a/dlls/comctl32/tooltips.c > +++ b/dlls/comctl32/tooltips.c > @@ -1177,8 +1177,7 @@ TOOLTIPS_DelToolT (TOOLTIPS_INFO *infoPtr, const TTTOOLINFOW *ti, BOOL isW) > } > > static LRESULT > -TOOLTIPS_EnumToolsT (const TOOLTIPS_INFO *infoPtr, UINT uIndex, TTTOOLINFOW *ti, > - BOOL isW) > +TOOLTIPS_EnumToolsT (const TOOLTIPS_INFO *infoPtr, UINT uIndex, TTTOOLINFOW *ti) > { > TTTOOL_INFO *toolPtr; > > @@ -2176,8 +2175,7 @@ TOOLTIPS_WindowProc (HWND hwnd, UINT uMsg, WPARAM wParam, LPARAM lParam) > uMsg == TTM_DELTOOLW); > case TTM_ENUMTOOLSA: > case TTM_ENUMTOOLSW: > - return TOOLTIPS_EnumToolsT (infoPtr, (UINT)wParam, (LPTTTOOLINFOW)lParam, > - uMsg == TTM_ENUMTOOLSW); > + return TOOLTIPS_EnumToolsT (infoPtr, (UINT)wParam, (LPTTTOOLINFOW)lParam); > case TTM_GETBUBBLESIZE: > return TOOLTIPS_GetBubbleSize (infoPtr, (LPTTTOOLINFOW)lParam); > This needs to be implemented properly instead of being removed. Significant part is here: --- /* ti->lpszText = toolPtr->lpszText; */ ti->lpszText = NULL; /* FIXME */ --- which needs some tests. It's really doubtful that text is not returned when A/W messages exist.

1 0

Re: [5/5] gdiplus: Test flags of loaded images.
by testbot＠testbot.winehq.org 22 Aug '10

22 Aug '10

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=4650 Your paranoid android. === WVISTAADM (32 bit image) === No test summary line found === W7PRO (32 bit image) === image.c:103: Test failed: Expected 00012010, got 00013010 image.c:103: Test failed: Expected 00013088, got 00013010 === W7PROX64 (32 bit image) === image.c:103: Test failed: Expected 00012010, got 00013010 image.c:103: Test failed: Expected 00013088, got 00013010 === W7PROX64 (64 bit image) === image.c:103: Test failed: Expected 00012010, got 00013010 image.c:103: Test failed: Expected 00013088, got 00013010

2 1

Re: msvideo: Forward MCIWndCreate16 to MCIWndCreateA (2nd)
by Alexandre Julliard 22 Aug '10

22 Aug '10

Stefan Leichter <Stefan.Leichter(a)camline.com> writes: > + HINSTANCE hinst32; > + if (hinst16 == GetModuleHandle16("msvideo.dll")) > + hinst32 = GetModuleHandleA("msvfw32.dll"); > + else > + hinst32 = HINSTANCE_32(GetExePtr( hinst16 )); This doesn't seem right. Why do you need this? -- Alexandre Julliard julliard(a)winehq.org

2 2

Re: appwiz.cpl: Removed sign comparison warning
by Nikolay Sivov 22 Aug '10

22 Aug '10

On 8/20/2010 20:04, Marko Nikolic wrote: > Changed variable type to match function return type. > --- > dlls/appwiz.cpl/appwiz.c | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/dlls/appwiz.cpl/appwiz.c b/dlls/appwiz.cpl/appwiz.c > index ffd2b24..1b3370b 100644 > --- a/dlls/appwiz.cpl/appwiz.c > +++ b/dlls/appwiz.cpl/appwiz.c > @@ -406,7 +406,7 @@ static void UpdateButtons(HWND hWnd) > { > APPINFO *iter; > LVITEMW lvItem; > - DWORD selitem = SendDlgItemMessageW(hWnd, IDL_PROGRAMS, LVM_GETNEXTITEM, -1, > + LRESULT selitem = SendDlgItemMessageW(hWnd, IDL_PROGRAMS, LVM_GETNEXTITEM, -1, > LVNI_FOCUSED | LVNI_SELECTED); > BOOL enable_modify = FALSE; > There's no need for that, return value means integer item index. What are you fixing with that?

2 3

Re: [4/5] gdiplus: Set bitmap has alpha flag based on format.
by testbot＠testbot.winehq.org 22 Aug '10

22 Aug '10

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=4649 Your paranoid android. === WVISTAADM (32 bit image) === No test summary line found

1 0

Re: wineboot: More architectures and vendorIDs in create_hardware_registry_keys
by André Hentschel 22 Aug '10

22 Aug '10

> +#ifdef __i386__ > + /* get VendorID from CPUID, eax = 0 */ > + unsigned int regs[3]; Hello Konrad, you are generating declerations after some code here. -- Best Regards, André Hentschel

2 2

problem with ./configure & libGLU vs. libice-dev
by wylda＠volny.cz 22 Aug '10

22 Aug '10

Hi, isn't there a problem with wine's configure script? I'm running on new Debian Squezee and noticed (luckily), that when libice-dev is installed, than ./configure can't find "-lGLU". But libice-dev doesn't have any influence on file "libGLU.so.1". So why configure says me "-lGLU... not found" when file "/usr/lib/libGLU.so.1" is present? Desperate W.

4 5

Re: [PATCH 2/5] ddraw/tests: New visual back buffer flipping tests. (try 5, resend)
by Stefan Dösinger 21 Aug '10

21 Aug '10

This test contains a C++ comment, please remove it. Otherwise it looks ok, as does patch 1 Am 18.08.2010 um 22:01 schrieb Oldřich Jedlička: > --- > dlls/ddraw/tests/visual.c | 123 +++++++++++++++++++++++++++++++++++++++++++++ > 1 files changed, 123 insertions(+), 0 deletions(-) > > diff --git a/dlls/ddraw/tests/visual.c b/dlls/ddraw/tests/visual.c > index 290cb76..aecc2ab 100644 > --- a/dlls/ddraw/tests/visual.c > +++ b/dlls/ddraw/tests/visual.c > @@ -2920,6 +2920,128 @@ static void depth_clamp_test(IDirect3DDevice7 *device) > ok(SUCCEEDED(hr), "SetViewport failed, hr %#x.\n", hr); > } > > +static void DX1_BackBufferFlipTest(void) > +{ > + HRESULT hr; > + int ret; > + IDirectDraw *DirectDraw1 = NULL; > + IDirectDrawSurface *Primary = NULL; > + IDirectDrawSurface *Backbuffer = NULL; > + WNDCLASS wc = {0}; > + DDSURFACEDESC ddsd; > + DDBLTFX ddbltfx; > + COLORREF color; > + const DWORD white = 0xffffff; > + const DWORD red = 0xff0000; > + BOOL attached = FALSE; > + > + wc.lpfnWndProc = DefWindowProc; > + wc.lpszClassName = "DX1_BackBufferFlipTest_wc"; > + RegisterClass(&wc); > + window = CreateWindow("DX1_BackBufferFlipTest_wc", "DX1_BackBufferFlipTest", > + WS_MAXIMIZE | WS_VISIBLE | WS_CAPTION , 0, 0, 640, 480, 0, 0, 0, 0); > + > + hr = DirectDrawCreate( NULL, &DirectDraw1, NULL ); > + ok(hr==DD_OK || hr==DDERR_NODIRECTDRAWSUPPORT, "DirectDrawCreate returned: %x\n", hr); > + if(FAILED(hr)) goto out; > + > + hr = IDirectDraw_SetCooperativeLevel(DirectDraw1, window, DDSCL_EXCLUSIVE | DDSCL_FULLSCREEN); > + ok(hr==DD_OK, "SetCooperativeLevel returned: %x\n", hr); > + if(FAILED(hr)) goto out; > + > + hr = IDirectDraw_SetDisplayMode(DirectDraw1, 640, 480, 32); > + if(FAILED(hr)) { > + /* 24 bit is fine too */ > + hr = IDirectDraw_SetDisplayMode(DirectDraw1, 640, 480, 24); > + } > + ok(hr==DD_OK || hr == DDERR_UNSUPPORTED, "SetDisplayMode returned: %x\n", hr); > + if (FAILED(hr)) { > + goto out; > + } > + > + memset(&ddsd, 0, sizeof(DDSURFACEDESC)); > + ddsd.dwSize = sizeof(DDSURFACEDESC); > + ddsd.dwFlags = DDSD_CAPS; > + ddsd.ddsCaps.dwCaps = DDSCAPS_PRIMARYSURFACE; > + > + hr = IDirectDraw_CreateSurface(DirectDraw1, &ddsd, &Primary, NULL); > + ok(hr==DD_OK, "IDirectDraw_CreateSurface returned: %08x\n", hr); > + > + memset(&ddsd, 0, sizeof(DDSURFACEDESC)); > + ddsd.dwSize = sizeof(DDSURFACEDESC); > + ddsd.dwFlags = DDSD_CAPS | DDSD_WIDTH | DDSD_HEIGHT | DDSD_PIXELFORMAT; > + ddsd.ddsCaps.dwCaps = DDSCAPS_BACKBUFFER; > + ddsd.dwWidth = 640; > + ddsd.dwHeight = 480; > + ddsd.ddpfPixelFormat.dwSize = sizeof(ddsd.ddpfPixelFormat); > + ddsd.ddpfPixelFormat.dwFlags = DDPF_RGB; > + U1(ddsd.ddpfPixelFormat).dwRGBBitCount = 32; > + U2(ddsd.ddpfPixelFormat).dwRBitMask = 0x00ff0000; > + U3(ddsd.ddpfPixelFormat).dwGBitMask = 0x0000ff00; > + U4(ddsd.ddpfPixelFormat).dwBBitMask = 0x000000ff; > + > + hr = IDirectDraw_CreateSurface(DirectDraw1, &ddsd, &Backbuffer, NULL); > + todo_wine ok(hr==DD_OK, "IDirectDraw_CreateSurface returned: %08x\n", hr); > + if(FAILED(hr)) goto out; > + > + hr = IDirectDrawSurface_AddAttachedSurface(Primary, Backbuffer); > + todo_wine ok(hr == DD_OK || broken(hr == DDERR_CANNOTATTACHSURFACE), > + "Attaching a back buffer to a front buffer returned %08x\n", hr); > + if (FAILED(hr)) goto out; > + > + attached = TRUE; > + > + memset(&ddbltfx, 0, sizeof(ddbltfx)); > + ddbltfx.dwSize = sizeof(ddbltfx); > + U5(ddbltfx).dwFillColor = red; > + hr = IDirectDrawSurface_Blt(Backbuffer, NULL, NULL, NULL, DDBLT_COLORFILL | DDBLT_WAIT, &ddbltfx); > + ok(hr == DD_OK, "IDirectDrawSurface_Blt returned: %x\n", hr); > + > + U5(ddbltfx).dwFillColor = white; > + hr = IDirectDrawSurface_Blt(Primary, NULL, NULL, NULL, DDBLT_COLORFILL | DDBLT_WAIT, &ddbltfx); > + ok(hr == DD_OK, "IDirectDrawSurface_Blt returned: %x\n", hr); > + > + // Check it out > + color = getPixelColor_GDI(Primary, 5, 5); > + ok(GetRValue(color) == 0xFF && GetGValue(color) == 0xFF && GetBValue(color) == 0xFF, > + "got R %02X G %02X B %02X, expected R FF G FF B FF\n", > + GetRValue(color), GetGValue(color), GetBValue(color)); > + > + color = getPixelColor_GDI(Backbuffer, 5, 5); > + ok(GetRValue(color) == 0xFF && GetGValue(color) == 0 && GetBValue(color) == 0, > + "got R %02X G %02X B %02X, expected R FF G 00 B 00\n", > + GetRValue(color), GetGValue(color), GetBValue(color)); > + > + hr = IDirectDrawSurface_Flip(Primary, NULL, DDFLIP_WAIT); > + todo_wine ok(hr == DD_OK, "IDirectDrawSurface_Flip returned 0x%08x\n", hr); > + > + if (hr == DD_OK) > + { > + color = getPixelColor_GDI(Primary, 5, 5); > + ok(GetRValue(color) == 0xFF && GetGValue(color) == 0 && GetBValue(color) == 0, > + "got R %02X G %02X B %02X, expected R FF G 00 B 00\n", > + GetRValue(color), GetGValue(color), GetBValue(color)); > + > + color = getPixelColor_GDI(Backbuffer, 5, 5); > + ok((GetRValue(color) == 0xFF && GetGValue(color) == 0xFF && GetBValue(color) == 0xFF) || > + broken(GetRValue(color) == 0xFF && GetGValue(color) == 0 && GetBValue(color) == 0), // broken driver > + "got R %02X G %02X B %02X, expected R FF G FF B FF\n", > + GetRValue(color), GetGValue(color), GetBValue(color)); > + } > + > + out: > + > + if (Backbuffer) > + { > + if (attached) > + IDirectDrawSurface_DeleteAttachedSurface(Primary, 0, Backbuffer); > + IDirectDrawSurface_Release(Backbuffer); > + } > + if (Primary) IDirectDrawSurface_Release(Primary); > + if (DirectDraw1) IDirectDraw_Release(DirectDraw1); > + if (window) DestroyWindow(window); > +} > + > START_TEST(visual) > { > HRESULT hr; > @@ -2983,6 +3105,7 @@ START_TEST(visual) > > D3D3_ViewportClearTest(); > p8_primary_test(); > + DX1_BackBufferFlipTest(); > > return ; > > -- > 1.7.2 > > >

2 1

Specifying Reply-To header in patches email using git-send-email?
by Frédéric Delanoy 21 Aug '10

21 Aug '10

I've tried for some time to specify the wine-devel Reply-To using git-send-email, with little success so far Any idea how this might be done? Here's how my git config looks like: [sendemail] <smtp server config> from = user <email> to = wine-patches <wine-patches(a)winehq.org> assume8bitEncoding = UTF-8 suppresscc = self chainreplyto = false thread = false suppressfrom = true Frédéric

3 5

Re: [PATCH 2/2] quartz: implement IBaseFilter_FindPin
by testbot＠testbot.winehq.org 21 Aug '10

21 Aug '10

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=4627 Your paranoid android. === WINEBUILD (build) === Make failed

1 0

dlls/d3dx9_36/bytecodewriter.c oddity
by Gerald Pfeifer 21 Aug '10

21 Aug '10

Metteo et al, I noticed d3dx9_36/bytecodewriter.c can be simplified as follows, but somewhat tells me this may rather point out a problem somewhere in that code, so I am not sending this to wine-patches. (The only functional difference should be the missing WARN in some cases, and I could restore that if desired, but...see above.) Thoughts? Guidance? Gerald diff --git a/dlls/d3dx9_36/bytecodewriter.c b/dlls/d3dx9_36/bytecodewriter.c index 07f96e7..e7bd8a5 100644 --- a/dlls/d3dx9_36/bytecodewriter.c +++ b/dlls/d3dx9_36/bytecodewriter.c @@ -1035,7 +1035,7 @@ static const struct bytecode_backend vs_1_x_backend = { static void instr_ps_1_0123_texld(struct bc_writer *This, const struct instruction *instr, struct bytecode_buffer *buffer) { - DWORD idx, srcidx; + DWORD idx; struct shader_reg reg; DWORD swizzlemask; @@ -1074,17 +1074,6 @@ static void instr_ps_1_0123_texld(struct bc_writer *This, /* map the temp dstreg to the ps_1_3 texture temporary register */ This->funcs->dstreg(This, &instr->dst, buffer, instr->shift, instr->dstmod); } else if(instr->src[0].type == BWRITERSPR_TEMP) { - if(instr->src[0].regnum == T0_REG) { - srcidx = 0; - } else if(instr->src[0].regnum == T1_REG) { - srcidx = 1; - } else if(instr->src[0].regnum == T2_REG) { - srcidx = 2; - } else if(instr->src[0].regnum == T3_REG) { - srcidx = 3; - } else { - WARN("Invalid address data source register r%u\n", instr->src[0].regnum); - } swizzlemask = (3 << BWRITERVS_SWIZZLE_SHIFT) | (3 << (BWRITERVS_SWIZZLE_SHIFT + 2)) |

2 2

Re: crypt32: Correct CryptVerifyMessageSignature's use of pcbDecoded
by testbot＠testbot.winehq.org 21 Aug '10

21 Aug '10

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=4624 Your paranoid android. === WINEBUILD (build) === Patch failed

1 0

Re: [PATCH 5/5] shell32: Implement IExplorerBrowser::SetRect.
by testbot＠testbot.winehq.org 21 Aug '10

21 Aug '10

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=4604 Your paranoid android. === WINEBUILD (build) === Patch failed

1 0

Re: [PATCH 4/5] shell32: Implement IExplorerBrowser::Initialize.
by testbot＠testbot.winehq.org 21 Aug '10

21 Aug '10

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=4603 Your paranoid android. === WINEBUILD (build) === Patch failed

1 0

Re: [PATCH 3/5] shell32: Add IShellBrowser stub.
by testbot＠testbot.winehq.org 21 Aug '10

21 Aug '10

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=4602 Your paranoid android. === WINEBUILD (build) === Patch failed

1 0

Re: [PATCH 2/5] shell32/tests: Add initial tests for the IExplorerBrowser control.
by testbot＠testbot.winehq.org 21 Aug '10

21 Aug '10

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=4601 Your paranoid android. === WINEBUILD (build) === Patch failed

1 0

Re: [PATCH] ntdll/tests: Add tests for RtlIpv4AddressToString / RtlIpv4AddressToStringEx [try 5]
by testbot＠testbot.winehq.org 21 Aug '10

21 Aug '10

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=4600 Your paranoid android. === WINEBUILD (build) === Patch failed

1 0

Re: advpakc/tests: Removed sign comparison warning in advpack tests
by testbot＠testbot.winehq.org 21 Aug '10

21 Aug '10

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=4599 Your paranoid android. === WINEBUILD (build) === Patch failed

1 0

Re: [PATCH 7/8] msvcp90/tests: Added basic_string<char> tests
by testbot＠testbot.winehq.org 21 Aug '10

21 Aug '10

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=4597 Your paranoid android. === WINEBUILD (build) === Patch failed

1 0

Re: [PATCH 2/2] d3dcompiler: Add D3DCreateBlob() test.
by testbot＠testbot.winehq.org 21 Aug '10

21 Aug '10

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=4596 Your paranoid android. === WINEBUILD (build) === Patch failed

1 0

Re: [PATCH try 2] ntdll: IMAGE_REL_BASED_HIGH, IMAGE_REL_BASED_LOW and IMAGE_REL_BASED_HIGHLOW should be supported on win64.
by testbot＠testbot.winehq.org 21 Aug '10

21 Aug '10

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=4595 Your paranoid android. === WINEBUILD (build) === Patch failed

1 0

Re: [7/7] comctl32/imagelist: Fail to create imagelist with zero or negative image dimensions
by testbot＠testbot.winehq.org 21 Aug '10

21 Aug '10

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=4594 Your paranoid android. === WINEBUILD (build) === Patch failed

1 0

Re: [6/7] comctl32/imagelist: Fail in ImageList_GetIconSize on null parameters
by testbot＠testbot.winehq.org 21 Aug '10

21 Aug '10

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=4593 Your paranoid android. === WINEBUILD (build) === Patch failed

1 0

Re: [5/7] comctl32/tests: More imagelist tests to show broken parameter validation
by testbot＠testbot.winehq.org 21 Aug '10

21 Aug '10

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=4592 Your paranoid android. === WINEBUILD (build) === Patch failed

1 0

Re: [4/7] comctl32/imagelist: Fix failure code for IImageList_Remove()
by testbot＠testbot.winehq.org 21 Aug '10

21 Aug '10

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=4591 Your paranoid android. === WINEBUILD (build) === Patch failed

1 0

Re: [3/7] comctl32/imagelist: Fix failure code for IImageList_Draw()
by testbot＠testbot.winehq.org 21 Aug '10

21 Aug '10

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=4590 Your paranoid android. === WINEBUILD (build) === Patch failed

1 0

Re: [2/7] comctl32/tests: Use reduced IMAGELISTDRAWPARAMS structure size for tests
by testbot＠testbot.winehq.org 21 Aug '10

21 Aug '10

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=4589 Your paranoid android. === WINEBUILD (build) === Patch failed

1 0

Re: [1/7] comctl32/tests: Use better names for test functions, discover some new test failures
by testbot＠testbot.winehq.org 21 Aug '10

21 Aug '10

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=4588 Your paranoid android. === WINEBUILD (build) === Patch failed

1 0

Re: oleau32: Try both SYS_WIN64 and SYS_WIN32 syskind in QueryPathOfRegTypeLib on win64.
by testbot＠testbot.winehq.org 21 Aug '10

21 Aug '10

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=4582 Your paranoid android. === WINEBUILD (build) === Patch failed

1 0

Re: gdi32: Properly set ERROR_NOACCESS when GetObject receives invalid arguments
by testbot＠testbot.winehq.org 21 Aug '10

21 Aug '10

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=4581 Your paranoid android. === WINEBUILD (build) === Patch failed

1 0

Re: [PATCH 4/4] explorerframe: Some additional basic tests.
by testbot＠testbot.winehq.org 21 Aug '10

21 Aug '10

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=4578 Your paranoid android. === WINEBUILD (build) === Patch failed

1 0

Re: [PATCH 3/4] explorerframe: Implement EnsureItemVisible.
by testbot＠testbot.winehq.org 21 Aug '10

21 Aug '10

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=4577 Your paranoid android. === WINEBUILD (build) === Patch failed

1 0

Re: [PATCH 2/4] explorerframe: Implement HitTest
by testbot＠testbot.winehq.org 21 Aug '10

21 Aug '10

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=4576 Your paranoid android. === WINEBUILD (build) === Patch failed

1 0

Re: [PATCH] comctl32/tests: DateTimePicker and MonthCalendar controls only support Gregorian calendar.
by testbot＠testbot.winehq.org 21 Aug '10

21 Aug '10

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=4574 Your paranoid android. === WINEBUILD (build) === Patch failed

1 0

Re: [5/5] urlmon/tests: Added tests for IUriBuilder_GetFragment
by testbot＠testbot.winehq.org 21 Aug '10

21 Aug '10

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=4571 Your paranoid android. === WINEBUILD (build) === Patch failed

1 0

Re: [website]Japanese Translation for "About Wine" page
by Jeremy Newman 20 Aug '10

20 Aug '10

I'll accept this patch when we also have a JA translation of the Front landing page. No point having other pages translated without at least that. -Newman On 08/17/2010 11:00 PM, kikuchy.h(a)gmail.com wrote: > From: Hiroshi Kikuchi<kikuchy.h(a)gmail.com> > > I want to join wine project. Nice to meet you. > Hiroshi Kikuchi > --- > templates/ja/about.template | 27 +++++++++++++++++++++++++++ > 1 files changed, 27 insertions(+), 0 deletions(-) > create mode 100644 templates/ja/about.template > > diff --git a/templates/ja/about.template b/templates/ja/about.template > new file mode 100644 > index 0000000..b83fad7 > --- /dev/null > +++ b/templates/ja/about.template > @@ -0,0 +1,27 @@ > + > + > + > +<h1 class="title">Wine について</h1> > + > +<p>Wine は、 Windows のソフトウェアを Windows 以外のOSで動作させるものです。Wine を使えば、Windows でするように Windows アプリケーションのインストールと実行が出来るようになります。</p> > + > +<p>Wine は現在活発に開発されています。まだ全てのプログラムが動作する訳ではありませんが、すでに<a href="http://wiki.winehq.org/UsageStatistics" title="Wine Usage Statistics">何人もの人たちが</a> Wine を使ってソフトウェアを動かしています。</p> > + > +<h3>オープンソース、そしてユーザーによる支援</h3> > + > +<p>Wine は未来永劫<a href="http://wiki.winehq.org/Licensing" title="Wine licensing">フリーソフト</a>です。Wine のソースコードのおよそ半分がボランティアによって書かれています。残り半分は商業的利潤のため、特にサポートがあるバージョンの Wine を発売している<a href="http://www.codeweavers.com/products/" title="Codeweavers Crossover Office">Codeweavers</a>によって支えられています。</p> > + > +<p>Wine はユーザーコミュニティに大きく頼っています。ユーザーのテストが私たちの、プログラムの動作状況を記録した<a href="http://appdb.winehq.org/" title="Wine Application Database">アプリケーションデータベース</a>を埋めてくれていますし、<a href="http://forums.winehq.org/" title="WineHQ Forums">フォーラム</a>の質問に対する答えも全てボランティアによるものです。</p> > + > +<h3>こちらもご覧ください:</h3> > +<ul> > +<li><a href="http://wiki.winehq.org/ImportanceOfWine">Wine が重要な理由</a></li> > +<li><a href="http://wiki.winehq.org/Debunking_Wine_Myths">Wine にまつわるウソ・ホント</a></li> > +<li><a href="http://wiki.winehq.org/WineHistory">Wine プロジェクトの歴史</a></li> > +<li><a href="http://wiki.winehq.org/ProjectOrganization">Organization and Leadership</a></li> > +</ul> > + > +<hr> > +<div class="link-container"> > +<p class="right-link">Wine の歴史:<a href="{$root}/history">次へ</a></p> > +</div> > > > >

1 0

RE: The Test Bot seems to be having issues
by Greg Geldorp 20 Aug '10

20 Aug '10

Hi Thomas, > From: Thomas Mallaly > > First off, I'm not sure who should be contacted about this, but, it appears > that the test bot has got itself stuck while trying to run tests on a patch > submitted last night. Sorry, hadn't noticed it got stuck. Usually it doesn't need much baby-sitting, so I don't keep a close look on it. You can always use the "Feedback" link on the TestBot home page. > The job in question is here [1], it's been over 12 > hours since any progress has been made on it and no other submissions have > run since then. Also, the Windows 98SE has been "reverting" this whole time, > so I'm not sure if this is the culprit or not. > > I also hate to admit that the job in question is from one of my patches I > sent in last night (although I'm pretty sure it doesn't have anything to do > with the quality of the code in the patch ;-) ). The Win9x VMs are on a different (physical) machine, it appears there was a network problem between the Test Bot host and the machine hosting the Win9x VMs. The Win98SE VM getting stuck in the "reverting" state is the cause of the problems, nothing to do with your patch. > Anyways, I'm hoping that somebody in charge of the test bot might be able to > fix the traffic jam it's causing. It's back up and running again, trying to catch up. Ge.

2 1

CVS gateway down for good
by Alexandre Julliard 20 Aug '10

20 Aug '10

Folks, The git->CVS gateway broke again, so I'm going to pull the plug on it. It doesn't make sense for me to spend more time fixing something that sees so little usage at this point. If you are still using CVS, you'll have to switch to git (or volunteer to host the gateway yourself...) Sorry about the inconvenience. -- Alexandre Julliard julliard(a)winehq.org

1 0

The Test Bot seems to be having issues
by Thomas Mullaly 20 Aug '10

20 Aug '10

Hi all, First off, I'm not sure who should be contacted about this, but, it appears that the test bot has got itself stuck while trying to run tests on a patch submitted last night. The job in question is here [1], it's been over 12 hours since any progress has been made on it and no other submissions have run since then. Also, the Windows 98SE has been "reverting" this whole time, so I'm not sure if this is the culprit or not. I also hate to admit that the job in question is from one of my patches I sent in last night (although I'm pretty sure it doesn't have anything to do with the quality of the code in the patch ;-) ). Anyways, I'm hoping that somebody in charge of the test bot might be able to fix the traffic jam it's causing. [1] https://testbot.winehq.org/JobDetails.pl?Key=4570 <https://testbot.winehq.org/JobDetails.pl?Key=4570> -- Thomas Mullaly thomas.mullaly(a)gmail.com

2 2

Re: user32/dialog.c: GetNextDlgTabItem returns hwndDlg if it does not contain controls. [try 2]
by Alexandre Julliard 20 Aug '10

20 Aug '10

"Mikhail Maroukhine" <mikolg(a)yandex.ru> writes: > GetNextDlgTabItem returns hwndDlg if it does not contain controls and > searching next item. > GetNextDlgTabItem returns the first child if next TABSTOP control not > found. > > And returns 0 in both cases if searching prev item It breaks the tests: ../../../tools/runtest -q -P wine -M comctl32.dll -T ../../.. -p comctl32_test.exe.so propsheet.c && touch propsheet.ok propsheet.c:312: Test failed: Focus should have been set to the Next button. Expected: 12324, Found: 65535 propsheet.c:363: Test failed: Focus should have been set to the Next button. Expected: 12324, Found: 65535 make[1]: *** [propsheet.ok] Error 2 -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH] gdi32/enhmfdrv: Do not leak a HDC
by Alexandre Julliard 20 Aug '10

20 Aug '10

Detlef Riekenberg <wine.dev(a)web.de> writes: > --- > dlls/gdi32/enhmfdrv/init.c | 14 ++++++++------ > 1 files changed, 8 insertions(+), 6 deletions(-) It would be cleaner to move the CreateDCW call where it's needed. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: cmd: Improved a FIXME in WCMD_filesize64
by Alexandre Julliard 20 Aug '10

20 Aug '10

"Konrad Wartke" <kwartke(a)googlemail.com> writes: > cmd: Improved a FIXME in WCMD_filesize64 by using a better algorithm. It's not much better. Anyway, this should be done by using one of the existing formatting functions, maybe VarFormatNumber. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 7/8] msvcp90/tests: Added basic_string<char> tests
by Alexandre Julliard 20 Aug '10

20 Aug '10

Piotr Caban <piotr(a)codeweavers.com> writes: > @@ -0,0 +1,30 @@ > +/* > + * Copyright 2010 Piotr Caban for CodeWeavers > + * > + * This library is free software; you can redistribute it and/or > + * modify it under the terms of the GNU Lesser General Public > + * License as published by the Free Software Foundation; either > + * version 2.1 of the License, or (at your option) any later version. > + * > + * This library is distributed in the hope that it will be useful, > + * but WITHOUT ANY WARRANTY; without even the implied warranty of > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > + * Lesser General Public License for more details. > + * > + * You should have received a copy of the GNU Lesser General Public > + * License along with this library; if not, write to the Free Software > + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301, USA > + */ > + > +/* basic_string<char, char_traits<char>, allocator<char>> */ > +#define BUF_SIZE_CHAR 16 > +typedef struct _basic_string_char > +{ > + void *allocator; > + union _data { > + char buf[BUF_SIZE_CHAR]; > + char *ptr; > + } data; > + size_t size; > + size_t res; > +} basic_string_char; Unless there's going to be a ton of definitions in there used by many different files, it's better to put that sort of thing directly in the C file to make it easier to build stand-alone. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: gdi32: Properly set ERROR_NOACCESS when GetObject receives invalid arguments
by Octavian Voicu 19 Aug '10

19 Aug '10

On Thu, Aug 19, 2010 at 4:56 PM, Jerome Leclanche <adys.wh(a)gmail.com> wrote: > Broken programs will crash on wine if they, for example, pass > arguments to GetObject in the wrong order. > This fixes bug #18864. > + if (buffer && ((ULONG_PTR)buffer >> 16) == 0) Wouldn't a __TRY ... __EXCEPT_PAGE_FAULT be better / safer? Octavian

2 1

PDB files generated by Intel C++ Compiler
by Peter Urbanec 19 Aug '10

19 Aug '10

I have some x64 binaries and associated PDBs that have been generated using Intel C++ Compiler 11.1. These PDBs cause issues such as this: 1 0x00000000781cc1ba in msvcr80 (+0x9c1b9) (0x00007ff047a4c840) fixme:dbghelp_msc:codeview_fetch_type Cannot locate type 670 err:dbghelp_msc:pe_load_debug_directory Got a page fault while loading symbols 2 0x000000006189a00d in lua5.1 (+0xa00c) (0x00007ff047a4c840) Now, from a quick look at mscvpdb.h, it looks like these PDBs contain datatypes with 64-bit near pointers, however wine does not seem to understand this mode. How would one go about adding support for this type of PDB? I actually don't have access to the Intel C++ Compiler to do much testing. :-(

2 1

winepath bug without arguments?
by Jerome Leclanche 19 Aug '10

19 Aug '10

Hi After fixing a bug in MPQEdit related to opening directories, I noticed winepath returns a different result with and without quotes: adys@azura:~/.wine/drive_c$ winepath -w adys@azura:~/.wine/drive_c$ winepath -w "" C:\ With quotes it returns the current directory. Is that intended? If not I'll open a bug... J. Leclanche

3 2

Re: [01/11] d3dx10: Add stub for d3dx10_43
by Henri Verbeet 19 Aug '10

19 Aug '10

On 18 August 2010 23:01, Owen Rudge <orudge(a)codeweavers.com> wrote: > +BOOL WINAPI D3DX10CheckVersion(UINT d3dsdkvers, UINT d3dxsdkvers) > +{ > + if ((d3dsdkvers == D3D10_SDK_VERSION) && (d3dxsdkvers == 43)) > + return TRUE; > + > + return FALSE; > +} Is it really safe to assume D3D10_SDK_VERSION will always keep the same value? (I know d3dx9 does it as well.) For d3d9 the SDK version changed between d3d9b and d3d9c, for example.

2 2

Re: [PATCH 3/5] ddraw/tests: New CreateSurface for 3D DDSCAPS_BACKBUFFER tests. (try 5, resend)
by Stefan Dösinger 19 Aug '10

19 Aug '10

Hi, Can you try to create a d3d device with this surface? In the first d3d version this works by querying the d3d device ID from the surface. Patch 4 looks OK. Thank you for your persistence with the patches by the way! Cheers, Stefan Am 18.08.2010 um 22:01 schrieb Oldřich Jedlička: > --- > dlls/ddraw/tests/d3d.c | 82 ++++++++++++++++++++++++++++++++++++++++++++++++ > 1 files changed, 82 insertions(+), 0 deletions(-) > > diff --git a/dlls/ddraw/tests/d3d.c b/dlls/ddraw/tests/d3d.c > index 53ef04b..a83b0d5 100644 > --- a/dlls/ddraw/tests/d3d.c > +++ b/dlls/ddraw/tests/d3d.c > @@ -3536,6 +3536,87 @@ static void FindDevice(void) > "Expected IDirect3D1::FindDevice to return D3D_OK, got 0x%08x\n", hr); > } > > +static void BackBuffer3DCreateSurfaceTest(void) > +{ > + DDSURFACEDESC ddsd; > + DDSURFACEDESC created_ddsd; > + DDSURFACEDESC2 ddsd2; > + IDirectDrawSurface *surf; > + IDirectDrawSurface4 *surf4; > + IDirectDrawSurface7 *surf7; > + HRESULT hr; > + IDirectDraw2 *dd2; > + IDirectDraw4 *dd4; > + IDirectDraw7 *dd7; > + DDCAPS ddcaps; > + > + const DWORD caps = DDSCAPS_BACKBUFFER | DDSCAPS_3DDEVICE; > + const DWORD expected_caps = DDSCAPS_BACKBUFFER | DDSCAPS_3DDEVICE | DDSCAPS_VIDEOMEMORY | DDSCAPS_LOCALVIDMEM; > + > + memset(&ddcaps, 0, sizeof(ddcaps)); > + ddcaps.dwSize = sizeof(DDCAPS); > + hr = IDirectDraw_GetCaps(DirectDraw1, &ddcaps, NULL); > + if (!(ddcaps.ddsCaps.dwCaps & DDSCAPS_VIDEOMEMORY)) > + { > + skip("DDraw reported no VIDEOMEMORY cap. Broken video driver? Skipping surface caps tests.\n"); > + return ; > + } > + > + memset(&ddsd, 0, sizeof(ddsd)); > + ddsd.dwSize = sizeof(ddsd); > + ddsd.dwFlags = DDSD_CAPS | DDSD_WIDTH | DDSD_HEIGHT; > + ddsd.dwWidth = 64; > + ddsd.dwHeight = 64; > + ddsd.ddsCaps.dwCaps = caps; > + memset(&ddsd2, 0, sizeof(ddsd2)); > + ddsd2.dwSize = sizeof(ddsd2); > + ddsd2.dwFlags = DDSD_CAPS | DDSD_WIDTH | DDSD_HEIGHT; > + ddsd2.dwWidth = 64; > + ddsd2.dwHeight = 64; > + ddsd2.ddsCaps.dwCaps = caps; > + memset(&created_ddsd, 0, sizeof(created_ddsd)); > + created_ddsd.dwSize = sizeof(DDSURFACEDESC); > + > + hr = IDirectDraw_CreateSurface(DirectDraw1, &ddsd, &surf, NULL); > + todo_wine ok(SUCCEEDED(hr), "IDirectDraw_CreateSurface failed: 0x%08x\n", hr); > + if (surf != NULL) > + { > + hr = IDirectDrawSurface_GetSurfaceDesc(surf, &created_ddsd); > + ok(SUCCEEDED(hr), "IDirectDraw_GetSurfaceDesc failed: 0x%08x\n", hr); > + todo_wine ok(created_ddsd.ddsCaps.dwCaps == expected_caps, > + "GetSurfaceDesc returned caps %x, expected %x\n", created_ddsd.ddsCaps.dwCaps, > + expected_caps); > + IDirectDrawSurface_Release(surf); > + } > + > + hr = IDirectDraw_QueryInterface(DirectDraw1, &IID_IDirectDraw2, (void **) &dd2); > + ok(SUCCEEDED(hr), "IDirectDraw_QueryInterface failed: 0x%08x\n", hr); > + > + hr = IDirectDraw2_CreateSurface(dd2, &ddsd, &surf, NULL); > + ok(hr == DDERR_INVALIDCAPS, "IDirectDraw2_CreateSurface didn't return %x08x, but %x08x\n", > + DDERR_INVALIDCAPS, hr); > + > + IDirectDraw2_Release(dd2); > + > + hr = IDirectDraw_QueryInterface(DirectDraw1, &IID_IDirectDraw4, (void **) &dd4); > + ok(SUCCEEDED(hr), "IDirectDraw_QueryInterface failed: 0x%08x\n", hr); > + > + hr = IDirectDraw4_CreateSurface(dd4, &ddsd2, &surf4, NULL); > + ok(hr == DDERR_INVALIDCAPS, "IDirectDraw4_CreateSurface didn't return %x08x, but %x08x\n", > + DDERR_INVALIDCAPS, hr); > + > + IDirectDraw4_Release(dd4); > + > + hr = IDirectDraw_QueryInterface(DirectDraw1, &IID_IDirectDraw7, (void **) &dd7); > + ok(SUCCEEDED(hr), "IDirectDraw_QueryInterface failed: 0x%08x\n", hr); > + > + hr = IDirectDraw7_CreateSurface(dd7, &ddsd2, &surf7, NULL); > + ok(hr == DDERR_INVALIDCAPS, "IDirectDraw7_CreateSurface didn't return %x08x, but %x08x\n", > + DDERR_INVALIDCAPS, hr); > + > + IDirectDraw7_Release(dd7); > +} > + > START_TEST(d3d) > { > init_function_pointers(); > @@ -3571,6 +3652,7 @@ START_TEST(d3d) > TextureLoadTest(); > ViewportTest(); > FindDevice(); > + BackBuffer3DCreateSurfaceTest(); > D3D1_releaseObjects(); > } > > -- > 1.7.2 > > >

1 0

Re: user32/dialog.c: GetNextDlgTabItem returns hwndDlg if it does not contain controls.
by Alexandre Julliard 19 Aug '10

19 Aug '10

"Mikhail Maroukhine" <mikolg(a)yandex.ru> writes: > @@ -1695,7 +1696,19 @@ HWND WINAPI GetNextDlgTabItem( HWND hwndDlg, HWND hwndCtrl, > */ > if (!hwndCtrl && fPrevious) return 0; > > - return DIALOG_GetNextTabItem(hwndDlg,hwndDlg,hwndCtrl,fPrevious); > + nextItem = DIALOG_GetNextTabItem(hwndDlg,hwndDlg,hwndCtrl,fPrevious); > + > + /* if next tab item not found return the first child even if it does not have TABSTOP > + Checked on XP > + */ > + if (!nextItem && !fPrevious) nextItem = GetWindow(hwndDlg,GW_CHILD); > + > + /* if there is no controls on hwndDlg return hwndDlg > + Checked on XP > + */ > + if (!nextItem && !fPrevious) nextItem = hwndDlg; > + > + return nextItem; You should test the fPrevious case too, it's probably similar. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: oleau32: Use correct sysking in QueryPathOfRegTypeLib.
by Alexandre Julliard 19 Aug '10

19 Aug '10

Jacek Caban <jacek(a)codeweavers.com> writes: > --- > dlls/oleaut32/typelib.c | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) It breaks the 64-bit tests: ../../../../wine/tools/runtest -q -P wine -M oleaut32.dll -T ../../.. -p oleaut32_test.exe.so ../../../../wine/dlls/oleaut32/tests/typelib.c && touch typelib.ok typelib.c:784: Test failed: QueryPathOfRegTypeLib(3.0) returned 8002801d typelib.c:784: Test failed: QueryPathOfRegTypeLib(3.1) returned 8002801d typelib.c:784: Test failed: QueryPathOfRegTypeLib(3.22) returned 8002801d typelib.c:784: Test failed: QueryPathOfRegTypeLib(3.37) returned 8002801d typelib.c:784: Test failed: QueryPathOfRegTypeLib(3.40) returned 8002801d typelib.c:784: Test failed: QueryPathOfRegTypeLib(65535.65535) returned 8002801d make: *** [typelib.ok] Error 6 -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 5/5] ddraw: Allow creating back buffer for DirectX 1 interfaces. (try 5, resend)
by Stefan Dösinger 19 Aug '10

19 Aug '10

Am 18.08.2010 um 22:01 schrieb Oldřich Jedlička: > + if(DDSD->ddsCaps.dwCaps & DDSCAPS_FRONTBUFFER) { > + WARN("Application tried to create an explicit front buffer\n"); > LeaveCriticalSection(&ddraw_cs); > return DDERR_INVALIDCAPS; > } This test seems redundant now. The ddraw1 thunk removes the flag, and all other thunks check for the frontbuffer flag on their own.

1 0

have all MCI tests in winmm/tests/ or distributed across mci*/tests/?
by Joerg-Cyril.Hoehle＠t-systems.com 19 Aug '10

19 Aug '10

Hi, although my patch creates mcicda/tests/ I'd like to query whether it would make more sense to have all mci tests grouped in winmm/tests/. Pro: + Future fixes to winmm/mci.c would affect winmm/tests/*.c only. E.g. when I'll make "stop all" work I'd have to touch mcicda/tests/mcicda.c as well to eliminate the todo_wine there. Same when I'll patch mciparse to accept [TT:]MM:SS:FF format. + When Maarten will write mciqtz tests, perhaps resources could be reused to execute mciavi tests as well (the file creation code need not be duplicated). Similar tests could be written for: "open foo.avi" (mciavi) and "open foo.avi type mpegvideo" (mciqtz) or "open foo.wav" (micwave) and "open foo.wav type mpegvideo" although there's some difference in behaviour. + The functions test_notification could be in one file only, not repeated. I can rewrite my current mcicda/tests/mcicda.c patch to live in winmm/tests/. What do you think? Jörg Höhle

2 1

Re: [1/2] user32: add a way to poll for messages on extra handles
by Alexandre Julliard 19 Aug '10

19 Aug '10

Damjan Jovanovic <damjan.jov(a)gmail.com> writes: > diff --git a/dlls/user32/driver.c b/dlls/user32/driver.c > index f2f9892..05c83d4 100644 > --- a/dlls/user32/driver.c > +++ b/dlls/user32/driver.c > @@ -126,6 +126,7 @@ static const USER_DRIVER *load_driver(void) > GET_USER_FUNC(WindowMessage); > GET_USER_FUNC(WindowPosChanging); > GET_USER_FUNC(WindowPosChanged); > + GET_USER_FUNC(GetExtraMessageHandles); That's ugly, it doesn't correspond to anything in the Windows API. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 2/2] ntdll/tests: Add tests for RtlIpv4AddressToString / RtlIpv4AddressToStringEx [try 4]
by Alexandre Julliard 19 Aug '10

19 Aug '10

Detlef Riekenberg <wine.dev(a)web.de> writes: > + ok( (res == (void *)~0) || > + broken(res == (NULL + len)), /* XP and w2003 */ You can't do that. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH] comctl32/tests: DateTimePicker and MonthCalendar controls only support Gregorian calendar.
by Nikolay Sivov 19 Aug '10

19 Aug '10

On Thu, Aug 19, 2010 at 9:50 AM, Austin Lund <austin.lund(a)gmail.com> wrote: > http://www.microsoft.com/middleeast/msdn/ArabicCalendar.aspx Hi, Austin. This information is outdated probably. There's a message to set a calendar for MonthCal at least, see: http://msdn.microsoft.com/en-us/library/bb760995%28VS.85%29.aspx Not sure about DateTimePicker, it uses Monthcal internally so a calendar could still be switched. Anyway this won't work on pre-Vista and without a manifest for v6, but you could enable tests using V6 loading helpers that we have already and MCM_SETCALID message, so tests will run on Arabic or some Asian boxes.

2 1

Re: [PATCH 5/5] ddraw: Allow creating back buffer for DirectX 1 interfaces. (try 5, resend)
by testbot＠testbot.winehq.org 19 Aug '10

19 Aug '10

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=4557 Your paranoid android. === W2KPROSP4 (32 bit visual) === visual.c:1619: Test failed: Got color 000a246a, expected 00ff0040 or near visual.c:1625: Test failed: Got color 006b8bbd, expected 00ff0080 or near === W98SE (32 bit dsurface) === No test summary line found

1 0

Re: [PATCH 1/5] ddraw/tests: Add test for bad size of surface caps in CreateSurface. (try 5, resend)
by testbot＠testbot.winehq.org 19 Aug '10

19 Aug '10

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=4553 Your paranoid android. === W98SE (32 bit dsurface) === No test summary line found

1 0

Re: [PATCH 2/2] gameux/tests: verifying registry values created by GameExplorer (try 2)
by testbot＠testbot.winehq.org 19 Aug '10

19 Aug '10

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=4552 Your paranoid android. === W98SE (32 bit gameexplorer) === Failure running script in VM: Exceeded timeout limit of 315 sec === W2KPROSP4 (32 bit gameexplorer) === Timeout === WXPPROSP3 (32 bit gameexplorer) === Timeout

1 0

Re: ntdll: IMAGE_REL_BASED_HIGH, IMAGE_REL_BASED_HIGH and IMAGE_REL_BASED_HIGHLOW are supported on win64.
by testbot＠testbot.winehq.org 19 Aug '10

19 Aug '10

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=4548 Your paranoid android. === W98SE (32 bit rtl) === Failure running script in VM: Exceeded timeout limit of 315 sec

1 0

Re: [PATCH 1/3] gameux: Add definitions of resource identifiers to header file
by Vincent Povirk 18 Aug '10

18 Aug '10

> @@ -32,7 +33,6 @@ > > #include "wine/test.h" > > - > static void test_create(BOOL* gameExplorerAvailable, BOOL* gameExplorer2Available) > { > HRESULT hr; Don't put formatting changes in functional patches, please. I think it would be helpful if you passed a string description to your _validate functions so that in case of failure, you can tell where the original call to _validateGameRegistryKey was, instead of just the line containing the ok() call.

3 3

Re: [PATCH 3/3] gameux/tests: verifying registry values created by GameExplorer
by testbot＠testbot.winehq.org 18 Aug '10

18 Aug '10

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=4540 Your paranoid android. === W98SE (32 bit gameexplorer) === Failure running script in VM: Exceeded timeout limit of 315 sec === W2KPROSP4 (32 bit gameexplorer) === Timeout === WXPPROSP3 (32 bit gameexplorer) === Timeout

4 5

Re: [PATCH 5/6] gameux: Add initial implementation of IGameExplorer2::CheckAccess method
by Mariusz Pluciński 18 Aug '10

18 Aug '10

Hello W dniu 16.08.2010 10:00, Mariusz Pluciński pisze: > --- > dlls/gameux/gameexplorer.c | 7 +++++-- > 1 files changed, 5 insertions(+), 2 deletions(-) > > This is patch I sent to wine-patches yesterday. It was marked as "Pending". I know that what I sent is not proper solution. But as I wrote in FIXME, it's in my opinion impossible to implement it properly, cause from what I know Wine does not support parental control. So, instead of doing real check, my function simply always grants access. My question is: what should I do with it? It cannot be left stub, as there's already bug caused by this (bug #23850). And probably every game which uses Game Explorer will behave that same. Should I write test case to demonstrate that native works that same in most cases?

1 0

Re: [PATCH 1/1] d3dx9: Add tests for FVF <-> declaration conversion.
by Alexandre Julliard 18 Aug '10

18 Aug '10

Misha Koshelev <misha680(a)gmail.com> writes: > +#define VDECL_CHECK(fcall) \ > + if(fcall != S_OK) \ > + trace(" Test failed on line #%d\n", __LINE__); > + > +#define VDECL_CHECK_FAIL(fcall) \ > + if(fcall != E_FAIL) \ > + trace(" Test failed on line #%d\n", __LINE__); That's ugly. If the goal is to print the line number, you should pass it to the test function. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 1/2] ntdll: Implement RtlIpv4AddressToString / RtlIpv4AddressToStringEx [try 3]
by Alexandre Julliard 18 Aug '10

18 Aug '10

Detlef Riekenberg <wine.dev(a)web.de> writes: > + in = *pin; What is this for? -- Alexandre Julliard julliard(a)winehq.org

1 0

Wine64 debugger
by Peter Urbanec 18 Aug '10

18 Aug '10

Hi, I'm trying to get a fairly complex Win64 application to work with wine. I'm seeing crashes in FindNextFileW/FindNextFileA due to what looks like a 64 bit HANDLE value being truncated to 32 bits. I thought that I would employ winedbg to help me, but I can't get very far. I don't have any luck with winedbg even on a simple x64 Win32 app. For my simplified test, I used MSVC2005 to generate an x64 executable created from the standard MSVC2005 template Win32 application. This is a simple app that just creates an empty window. As simple as one could get for a Win32 test and it executes correctly when run as "./wine Test1.exe". When I try to execute this test app under winedbg, I get an assert failure: ./wine winedbg Test1.exe WineDbg starting on pid 001a ./programs/winedbg/memory.c:37: be_cpu_linearize: Assertion `addr->Mode == AddrModeFlat' failed. wine: Assertion failed at address 0x7fec2fa657c5 (thread 0009), starting debugger... Unhandled exception: assertion failed in 64-bit code (0x00007fec2fa657c5). Any ideas about why I can not use winedbg to run Win32 x64 code? Thanks, Peter Urbanec

4 4

Re: [PATCH] advapi32: Add magic codes to HCRYPTKEY and HCRYPTHASH.
by Hans Leidekker 18 Aug '10

18 Aug '10

On Wed, 2010-08-18 at 10:14 +1000, Austin Lund wrote: > #define MAGIC_CRYPTPROV 0xA39E741F > +#define MAGIC_CRYPTKEY 0xA39E741F > +#define MAGIC_CRYPTHASH 0xA39E741F The app might pass a crypto handle of the wrong type, so it would be better to use different magic values.

3 4

Re: wldap32: Fix handling of zero timeout value in ldap_search_extW. (try 2)
by testbot＠testbot.winehq.org 18 Aug '10

18 Aug '10

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=4530 Your paranoid android. === W2KPROSP4 (32 bit parse) === parse.c:101: Test failed: ldap_search_extW failed 0x00000034 parse.c:105: Test failed: ldap_search_extW failed 0x00000051

2 1

Re: [4/5] msi: Handle signature filenames in short|long notation.
by testbot＠testbot.winehq.org 18 Aug '10

18 Aug '10

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=4528 Your paranoid android. === W7PROX64 (32 bit package) === package.c:8348: Test failed: Expected "C:\Program Files\VMware\VMware Tools\;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\", got "C:\Program Files (x86)\VMware\VMware Tools\;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\" === W7PROX64 (64 bit package) === package.c:8385: Test failed: Expected "C:\winetest\FileName1", got "" package.c:8396: Test failed: Expected "C:\winetest\", got "" package.c:8407: Test failed: Expected "C:\winetest\", got "" package.c:8457: Test failed: Expected "C:\winetest\FileName3.dll", got "" package.c:8468: Test failed: Expected "C:\winetest\FileName5.dll", got "" package.c:8477: Test failed: Expected "C:\", got "" package.c:8483: Test failed: Expected "C:\winetest\", got "" package.c:8504: Test failed: Expected "C:\winetest\FileName1", got "" package.c:8513: Test failed: Expected "C:\winetest\FileName1", got ""

1 0

Re: [3/5] msi/tests: Skip SourceDir tests on win9x.
by testbot＠testbot.winehq.org 18 Aug '10

18 Aug '10

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=4527 Your paranoid android. === W2K3R2SESP2 (32 bit install) === Timeout

1 0

Re: [2/5] msi/tests: Use HKEY_CURRENT_USER instead of HKEY_LOCAL_MACHINE for registry tests.
by testbot＠testbot.winehq.org 18 Aug '10

18 Aug '10

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=4526 Your paranoid android. === W2K3R2SESP2 (32 bit install) === Timeout

1 0

Re: [1/5] msi/tests: Fix some WoW64 test failures.
by testbot＠testbot.winehq.org 18 Aug '10

18 Aug '10

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=4525 Your paranoid android. === W7PROX64 (32 bit package) === package.c:8329: Test failed: Expected "C:\Program Files\VMware\VMware Tools\;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\", got "C:\Program Files (x86)\VMware\VMware Tools\;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\" === W7PROX64 (64 bit package) === package.c:8366: Test failed: Expected "C:\winetest\FileName1", got "" package.c:8377: Test failed: Expected "C:\winetest\", got "" package.c:8388: Test failed: Expected "C:\winetest\", got "" package.c:8438: Test failed: Expected "C:\winetest\FileName3.dll", got "" package.c:8449: Test failed: Expected "C:\winetest\FileName5.dll", got "" package.c:8458: Test failed: Expected "C:\", got "" package.c:8464: Test failed: Expected "C:\winetest\", got "" package.c:8485: Test failed: Expected "C:\winetest\FileName1", got "" package.c:8494: Test failed: Expected "C:\winetest\FileName1", got ""

1 0

kernel32/tests: GetVolumeInformationA X: succeeds iff drive's default dir is root. (try 2)
by Joerg-Cyril.Hoehle＠t-systems.com 18 Aug '10

18 Aug '10

Hi, what happened to this patch? It's still marked new. Is the discovery too surprising? (Maybe it's the wrong time to ask with AJ still on vacation) Is it not robust enough (lacking testing with network drives)? It explains bugs #20887 and #23355. It may explain intermittent failures in test.winehq/kernel/volume.ok, as success depends on where the test was launched from. >Tests pass on w95,w98,w2k,xp,7. I forgot to add "without skipping the one relevant section", i.e. when started from another drive than C: Of course I invite people here to also perform the test on native. Regards, Jörg Höhle

2 2

Re: wldap32: Fix handling of zero timeout value in ldap_search_extW.
by testbot＠testbot.winehq.org 18 Aug '10

18 Aug '10

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=4524 Your paranoid android. === W98SE (32 bit parse) === parse.c:108: Test failed: ldap_search_extW failed 0x00000059 === WNT4WSSP6 (32 bit parse) === parse.c:108: Test failed: ldap_search_extW failed 0x00000059

1 0

Re: [PATCH 2/3] winex11.drv: set global key state
by Alexandre Julliard 18 Aug '10

18 Aug '10

Rafał Miłecki <zajec5(a)gmail.com> writes: > @@ -1250,6 +1250,21 @@ void X11DRV_send_keyboard_input( WORD wVk, WORD wScan, DWORD event_flags, DWORD > key_state_table[wVkStripped] = key_state_table[wVkL] | key_state_table[wVkR]; > } > > + SERVER_START_REQ( set_global_key_state ) > + { > + req->key = wVk; > + req->state = key_state_table[wVk]; > + wine_server_call( req ); > + } > + SERVER_END_REQ; > + SERVER_START_REQ( set_global_key_state ) > + { > + req->key = wVkStripped; > + req->state = key_state_table[wVkStripped]; > + wine_server_call( req ); > + } > + SERVER_END_REQ; > + You don't want to add 2 extra server calls for every key, especially since the server already receives the necessary information through the key event. -- Alexandre Julliard julliard(a)winehq.org

3 2

re: winex11.drv: Fix uninitialised values. (valgrind) (try 2)
by Dan Kegel 17 Aug '10

17 Aug '10

That's for http://bugs.winehq.org/show_bug.cgi?id=20335 , right? Alexandre's reply to that was "It sounds like it's hashing padding bytes. Probably should be reported to the X.org folks." X is old code, and I don't think anyone has cleaned it up for valgrind yet. That's why I use suppression files like http://winezeug.googlecode.com/svn/trunk/valgrind/valgrind-suppressions which contain blanket suppressions like { bogus_X11_1 Memcheck:Param write(buf) obj:* obj:/usr/lib*/libX11.so.6.2.0 } { bogus_X11_2 Memcheck:Param write(buf) obj:* obj:* obj:/usr/lib*/libX11.so.6.2.0 }

2 1

Re: Should we expect Liberation fonts to be installed?
by Scott Ritchie 17 Aug '10

17 Aug '10

On 08/08/2010 06:56 AM, James McKenzie wrote: > Scott Ritchie wrote: >> I was looking through our fairly large collection of open font bugs and >> realized that things might be a lot simpler if we took some opinionated >> positions and just declared certain fonts to be dependencies and >> expected all packagers to provide them. >> >> This is similar to bundling our own Tahoma, except much less work. >> > This might work for Linux, but these fonts are not installed on any > MacOSX version that I'm aware of. This might break Wine useage for > Macs. It might also break it for Solaris as well. > > James McKenzie > It should only break in a way that makes it as bad as it currently is. Thanks, Scott Ritchie

4 5

Re: kernel32: add stub for SetFileValidData
by Alexandre Julliard 17 Aug '10

17 Aug '10

Austin English <austinenglish(a)gmail.com> writes: > @@ -1001,6 +1001,16 @@ error: > } > > /*********************************************************************** > + * SetFileValidData (KERNEL32.@) > + */ > +BOOL WINAPI SetFileValidData( HANDLE hFile, LONGLONG ValidDataLength ) > +{ > + FIXME("stub: %p, %llu\n", hFile, ValidDataLength); You can't use %ll formats. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: user32, GetUserObjectInformation implementation with index=UOI_USER_SID (try2, resend)
by Alexandre Julliard 17 Aug '10

17 Aug '10

Wolfgang Schwotzer <wolfgang.schwotzer(a)gmx.net> writes: > New patch after rebase. > Always checks return values. > Tested with Polar Protrainer 5, updater.exe > From dcb91595b33513f8df2cf4d439221d3143c8fac1 Mon Sep 17 00:00:00 2001 > From: Wolfgang Schwotzer <wolfgang.schwotzer(a)gmx.net> > Date: Sat, 24 Jul 2010 17:12:05 +0200 > Subject: GetUserObjectInformation UOI_USER_SID (try 2) This should be retrieved from the server, based on the object security token or something along those lines. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: shdocvw: Remove useless menu separator
by Octavian Voicu 17 Aug '10

17 Aug '10

Not sure if it's useless. I thing it's intended to separate the static part of the menu (Add to favorites) from the dynamically generated list of favorite items that follows (which isn't implemented yet). Octavian

3 2

Re: [PATCH 1/4] msvcp90: Added allocator<char> 64-bit exports
by Alexandre Julliard 17 Aug '10

17 Aug '10

Piotr Caban <piotr(a)codeweavers.com> writes: > @@ -35,6 +35,12 @@ char* __stdcall MSVCP_allocator_char_address(void *this, char *ptr) > return ptr; > } > > +/* ?address@?$allocator@D@std@@QEBAPEADAEAD@Z */ > +char* __cdecl MSVCP64_allocator_char_address(void *this, char *ptr) > +{ > + return MSVCP_allocator_char_address(this, ptr); > +} > + stdcall and cdecl are equivalent on 64-bit, so you don't need the extra wrappers. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: avifil32: Fix EditStreamSetInfo wine checks [try 2]
by Alexandre Julliard 17 Aug '10

17 Aug '10

Alexandre Goujon <ale.goujon(a)gmail.com> writes: > +#define TEST_SETINFO_(m) \ > + hres = EditStreamSetInfo(stream, &info, sizeof(AVISTREAMINFO) ); \ > + ok( hres == 0, "got 0x%08X, expected 0\n", hres); \ > + hres = AVIStreamInfo(stream, &info2, sizeof(AVISTREAMINFO) ); \ > + ok( hres == 0, "got 0x%08X, expected 0\n", hres); \ > + ok( info2.m == info.m, "EditStreamSetInfo did not update "#m" parameter\n" ); > + > +#define TEST_SETINFO(m) \ > + info.m++; \ > + TEST_SETINFO_(m); \ > + \ > + info.m = 0; \ > + TEST_SETINFO_(m); Please avoid that sort of macros. Add a helper function if necessary, or just spell things out explicitly. -- Alexandre Julliard julliard(a)winehq.org

1 0

iPod synced with iTunes v7.6!
by Russ Mannex 17 Aug '10

17 Aug '10

Hello Maarten! I read your post on the WineHQ site. I was wondering if you know whether I am attempting something that simply will not work yet. I am running iTunes 7.7.1 on Wine 1.1.42. These are running on Ubuntu 10.04. iTunes is not showing my iPod. I have tried setting an autodetect drive E: to /media/IPOD, but iTunes seems to not see it there. Any help will be greatly appreciated, even if the answer is "will not work." Thanks. -- Russ Mannex Russ(a)Mannex.com

3 2

Re: [PATCH 1/5] wined3d: separate driver info from GPU info
by Henri Verbeet 17 Aug '10

17 Aug '10

On 17 August 2010 03:52, Roderick Colenbrander <thunderbird2k(a)gmail.com> wrote: > --- > dlls/wined3d/directx.c | 276 +++++++++++++++++++++------------------ > dlls/wined3d/wined3d_private.h | 14 ++ > 2 files changed, 163 insertions(+), 127 deletions(-) > This will return inconsistent driver version numbers for Vista, Win7 and 95/98/NT4.

1 0

Re: [2/2] gdiplus: Implement multi-frame image loading.
by testbot＠testbot.winehq.org 17 Aug '10

17 Aug '10

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=4486 Your paranoid android. === WVISTAADM (32 bit image) === No test summary line found

1 0

Re: [4/6] ipconfig: Partially implement basic adapter information output.
by Juan Lang 16 Aug '10

16 Aug '10

Hi Andrew, + static const WCHAR ethernetW[] = {'E','t','h','e','r','n','e','t',0}; + static const WCHAR unknownW[] = {'U','n','k','n','o','w','n',0}; shouldn't these be resources instead? --Juan

2 1

Re: [PATCH 1/5] d3d10: Fix d3dcommon.h inclusion.
by James Mckenzie 16 Aug '10

16 Aug '10

Henri Verbeet <hverbeet(a)gmail.com> wrote: >Sent: Aug 16, 2010 11:06 AM >To: Rico Schüller <kgbricola(a)web.de> >Cc: wine-devel(a)winehq.org >Subject: Re: [PATCH 1/5] d3d10: Fix d3dcommon.h inclusion. > >2010/8/16 Rico Schüller <kgbricola(a)web.de>: >> Yes, this replaces the earlier patch series. I thought this was clear from >> the discussion for try 2. >> >At the very least it's obvious that the other series isn't going to >happen. Whether this series replaces it or is independent doesn't >matter a whole lot at that point. > If the other series is cancelled, it would be nice to state so as well. This conserves AJ's time and efforts. This has happened to me (I found that my code was seriously broken.) James McKenzie

1 0

WineAPI structure plans
by Max TenEyck Woodbury 16 Aug '10

16 Aug '10

I think I have a usable structure for the pages on the WineAPI wiki which I am about to lay before you, but first a discussion of the project name... ---- I understand that some people do not particularly approve of the name I have given this project. It is on Sourceforge and a short relevant name was needed. Much of the information to be presented is specific to Wine and will be based on the contents of the Wine repository. The name reflects that dependence. Other projects may want to use the information presented. They are welcome to do so as far as I am concerned. They may also wish to present information specific to their projects. That is an excellent idea and I will help where I can, but I have two reservations: First, I am unlikely to be familiar with the structure of other projects; I will not be able to maintain those contributions. Someone from the other projects will have to take responsibility for maintaining those contributions and coordinate with the members of the project from Wine. Second, where there are differences between the projects, and the other projects are invited to provide their information but not at the expense of the Wine information. I also included a reference to 'API'. More than just the API will be covered, but the API will definitely be included. While Wine is intended to provide an interface functionally equivalent to the Microsoft products, it will differ from their interface in small ways. One of the most important differences will be that this API is open and *not* particularly designed to promote Microsoft's products. References to the Microsoft documentation will be included, but infringement of Microsoft's copyrights is *not* intended and will be corrected as quickly as it can be verified. The project name can be changed if really necessary, but requests to change it should be constructive with an emphasis on how the new name meets the projects needs. ---- There are two major types of information that will be presented. One type of information is annotation, opinion, discussion, description and so on. This will be managed by people. Another type of information is technical and is tied directly to the contents of the Wine project (and other projects when the details have been worked out). My intention is to write scripts that extract and report this kind of information. This information will change as Wine changes. It will be difficult for the scripts to work around the human generated content. To allow the two major kinds of information to mix, they will be kept on separate pages. Specifically, the editable information will be kept on what MediaWiki calls 'sub-pages'. The places where sub-pages are included will be controlled by the scripts. The script writers will need to be informed of where these inclusions should be placed. Also, to keep the number of 'red-links' under control, The scripts will generate initial versions of the sub-pages. Some structure is needed to make the scripts work and to allow people to check the scripts. For that reason, all script generated pages will start with a comment describing the main script responsible for generating the page along with revision information for the script and script components. The comment will also identify the revision of the repository used to generate the page. (Note, the revision information will be for the last time the page content has to be changed, and will not be updated unless the page content, and not the revision information, is changed. Some structure will also be needed for sub-pages and will be set up in the generated initial versions of those pages. That structure consists of a link back to the article that included the sub-page, markings that the page is editable and at least one section header to serve as a handle to enable easy editing of the sub-page. -Max

1 0

Re: [PATCH 1/5] d3d10: Fix d3dcommon.h inclusion.
by James McKenzie 16 Aug '10

16 Aug '10

Rico Schüller wrote: > Hi, > > this patch series implements the ID3DBlob interface. This time the > interface is implemented in the d3dcompiler_43.dll. The function > D3D10CreateBlob from d3d10 is forwarded to the D3DCreateBlob function > in the d3dcompiler_43.dll. Does this replace the ten patch series you submitted on 8/11? This is not clear here. James McKenzie

3 2

Re: [PATCH 1/5] d3d10: Fix d3dcommon.h inclusion.
by James Mckenzie 16 Aug '10

16 Aug '10

Rico Schüller <kgbricola(a)web.de> wrote: >Sent: Aug 16, 2010 10:21 AM >To: wine-devel(a)winehq.org >Subject: Re: [PATCH 1/5] d3d10: Fix d3dcommon.h inclusion. > >Am 15.08.2010 18:26, schrieb James McKenzie: >> Rico Schüller wrote: >>> Hi, >>> >>> this patch series implements the ID3DBlob interface. This time the >>> interface is implemented in the d3dcompiler_43.dll. The function >>> D3D10CreateBlob from d3d10 is forwarded to the D3DCreateBlob function >>> in the d3dcompiler_43.dll. >> >> Does this replace the ten patch series you submitted on 8/11? This is >> not clear here. >> >Yes, this replaces the earlier patch series. I thought this was clear >from the discussion for try 2. > I've learned the hard way to never assume anything and to document everything. If something can be misunderstood it will and will in the most damaging manner. James McKenzie James McKenzie

1 0

RE: Wine users with a CD-ROM drive, please test
by Ge van Geldorp 16 Aug '10

16 Aug '10

> From: Joerg Hoehle > > There's no mention of win95/98 in the attachment so I assume these > were not included, or was that because there was no error? Right, they were not included. I ran into some problems trying to attach the .iso to those VMs and gave up. Win9x should die :-). Ge.

1 0

RE: Wine users with a CD-ROM drive, please test
by Greg Geldorp 16 Aug '10

16 Aug '10

Hi Joerg, > From: Joerg Hoehle > > I found out that some machines ignore > set c audio all off > which was in the testsuite, while others react to it and even > update the system preferences volume mixer control if > it happens to be open. > > I don't know whether that difference depends on the HW (CD-ROM > driver) or the OS. You can find it out by posting your results here. > > I'm now using > set c audio all on > (which should be the default) > such that all users running the testsuite get to hear something. > > https://testbot.winehq.org/JobDetails.pl?Key=4434 > mcicda.c:612: Test failed: STOP all returned MCIERR_HARDWARE > (I fixed that, but not yet on testbot). I ran mcicda_test from TestBot job 4436 on the TestBot VMs, with a data .iso connected as CD-ROM. Full results in attachment. In short: On NT4, Win2000: mcicda.c:318: Test failed: resume without play: 0=NOERROR On NT4, Win2000, XP, W2K3 mcicda.c:397: Test failed: STATUS position: MCIERR_HARDWARE Ge.

2 1

Re: [3/3] wined3d: Remove isInDraw hack from context_setup_target.
by Henri Verbeet 16 Aug '10

16 Aug '10

On 16 August 2010 13:25, Matteo Bruni <matteo.mystral(a)gmail.com> wrote: > It is conceptually wrong and actually broken too (as the comment there > said). Just remove the hack now and properly fix any regression > that may come up later by explicitely acquiring the right context where > needed (so, in surface_internal_preload and its callees). Note that isInDraw is mildly awful in itself, and we should probably get rid of it eventually. In most places where it's used it's probably an artifact of the old context management, but that needs to be checked.

2 1

Re: [1/3] wined3d: Call set_render_offscreen at the end of context_setup_target.
by Henri Verbeet 16 Aug '10

16 Aug '10

I'm ok with this, but for future reference, if the change isn't entirely obvious a small comment is usually appropriate.

1 0

Re: [PATCH 2/2] jscript: Throw TypeError in in_eval.
by testbot＠testbot.winehq.org 16 Aug '10

16 Aug '10

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=4470 Your paranoid android. === W98SE (32 bit) === No test summary line found === 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 === W7PROX64 (64 bit) === No test summary line found

1 0

Re: urlmon: Return failures from progress callback
by Jacek Caban 16 Aug '10

16 Aug '10

Hi Juan, On 8/4/10 11:44 PM, Juan Lang wrote: > Partial fix for bug 21032. > --Juan if(!This->callback) - return; + return E_POINTER; This doesn't seem right. It's fine to call URLDownloadToFile without callback AFAIR. Thanks, Jacek

1 0

Re: [PATCH 1/2] jscript: Throw TypeError in instanceof_expression_eval.
by testbot＠testbot.winehq.org 16 Aug '10

16 Aug '10

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=4469 Your paranoid android. === W98SE (32 bit) === No test summary line found === 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 === W7PROX64 (64 bit) === No test summary line found

1 0

Some statistics about the 1.0->1.2 development cycle
by Wolfram Sang 16 Aug '10

16 Aug '10

Hello, I am going to speak about my "getting into wine development" at FrosCon (near Bonn/Germany) next weekend. During preparation, I was interested in some numbers, so I roughly modified 'kps' (kernel patch statistics) for wine. The outcome for the 1.0->1.2 cycle can be found here, if somebody is interested (just make sure you read the README first): http://www.the-dreams.de/wine/winekpsstats10-12.tar.gz So far, not too surprising IMHO, although I probably missed a number of people. I am open for comments, if there are some. Have a nice sunday, Wolfram

6 7

Re: [PATCH 1/1] d3dx9: Add tests for FVF <-> declaration conversion.
by Henri Verbeet 16 Aug '10

16 Aug '10

This is for the most part just a copy of the corresponding d3d9 test, so I guess it should work, but it also contains most of the flaws from that test, like e.g. returning E_FAIL from a function returning int. There's probably room for improvement in the test setup itself as well.

1 0

Re: kernel32/tests: GetVolumeInformationA X: succeeds iff drive's default dir is root. (try 2)
by Greg Geldorp 16 Aug '10

16 Aug '10

Hi Joerg, I temporarily attached a second disk to all TestBot VMs and ran the test, both from the C: drive and from the (new) E: drive. Full results attached. In short: everything passes. Ge.

2 1

Re: comctl32: Simplify is_textT by omitting isW.
by Nikolay Sivov 15 Aug '10

15 Aug '10

On 5/9/2010 16:43, Gerald Pfeifer wrote: > isW is not actually used by is_textT, so we can simplify listview.c a > bit by omitting the useless parameter. > > > > -static inline BOOL is_textT(LPCWSTR text, BOOL isW) > +static inline BOOL is_textT(LPCWSTR text) > > There's no reason to keep this helper then. It's better to rename is_textW() to is_text() and remove is_textT().

2 1

Re: Wine users with a CD-ROM drive, please test
by Greg Geldorp 15 Aug '10

15 Aug '10

> From: <Joerg-Cyril.Hoehle(a)t-systems.com> > > this is my second call for participation, as only Jeff Zaroyko responded to the first one. > > I wrote a testsuite for mcicda (play music from CD-ROM using the MCI). > Wine's testbot job #4330 at > https://testbot.winehq.org/JobDetails.pl?Key=4330 > contains both a patch and binary of what I'd initially want to test about mcida.dll, > solely lacking compatibility fixes that testing on YOUR machine will show to be necessary. I can attach a .iso to each VM and run your tests. Would that help? Keep in mind that almost none of the VMs have sound support. Ge.

8 14

Re: [7/13] comctl32/imagelist: Fail to create imagelist with zero or negative image dimensions
by testbot＠testbot.winehq.org 15 Aug '10

15 Aug '10

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=4453 Your paranoid android. === WVISTAADM (32 bit imagelist) === imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 === W2K8SE (32 bit imagelist) === imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 === W7PRO (32 bit imagelist) === imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 === W7PROX64 (32 bit imagelist) === imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 === W7PROX64 (64 bit imagelist) === imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000

1 0

Re: [6/13] comctl32/imagelist: Fail in ImageList_GetIconSize on null parameters
by testbot＠testbot.winehq.org 15 Aug '10

15 Aug '10

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=4452 Your paranoid android. === WVISTAADM (32 bit imagelist) === imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 === W2K8SE (32 bit imagelist) === imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 === W7PRO (32 bit imagelist) === imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 === W7PROX64 (32 bit imagelist) === imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 === W7PROX64 (64 bit imagelist) === imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000

1 0

Re: [5/13] comctl32/tests: More imagelist tests to show broken parameter validation
by testbot＠testbot.winehq.org 15 Aug '10

15 Aug '10

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=4451 Your paranoid android. === WVISTAADM (32 bit imagelist) === imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 === W2K8SE (32 bit imagelist) === imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 === W7PRO (32 bit imagelist) === imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 === W7PROX64 (32 bit imagelist) === imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 === W7PROX64 (64 bit imagelist) === imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000

1 0

Re: [4/13] comctl32/imagelist: Fix failure code for IImageList_Remove()
by testbot＠testbot.winehq.org 15 Aug '10

15 Aug '10

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=4450 Your paranoid android. === WVISTAADM (32 bit imagelist) === imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 === W2K8SE (32 bit imagelist) === imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 === W7PRO (32 bit imagelist) === imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 === W7PROX64 (32 bit imagelist) === imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 === W7PROX64 (64 bit imagelist) === imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000

1 0

Re: [3/13] comctl32/imagelist: Fix failure code for IImageList_Draw()
by testbot＠testbot.winehq.org 15 Aug '10

15 Aug '10

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=4449 Your paranoid android. === WVISTAADM (32 bit imagelist) === imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 === W2K8SE (32 bit imagelist) === imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 === W7PRO (32 bit imagelist) === imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 === W7PROX64 (32 bit imagelist) === imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 === W7PROX64 (64 bit imagelist) === imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000

1 0

Re: [2/13] comctl32/tests: Use reduced IMAGELISTDRAWPARAMS structure size for tests
by testbot＠testbot.winehq.org 15 Aug '10

15 Aug '10

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=4448 Your paranoid android. === WVISTAADM (32 bit imagelist) === imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 === W2K8SE (32 bit imagelist) === imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 === W7PRO (32 bit imagelist) === imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 === W7PROX64 (32 bit imagelist) === imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 === W7PROX64 (64 bit imagelist) === imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 imagelist.c:1433: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000

1 0

Re: [1/13] comctl32/tests: Use better names for test functions, discover some new test failures
by testbot＠testbot.winehq.org 15 Aug '10

15 Aug '10

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=4447 Your paranoid android. === WVISTAADM (32 bit imagelist) === imagelist.c:1438: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1438: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1438: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1438: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1438: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1438: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1438: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1438: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1438: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1438: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1438: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1438: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1438: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 imagelist.c:1438: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 imagelist.c:1438: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 imagelist.c:1438: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 === W2K8SE (32 bit imagelist) === imagelist.c:1438: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1438: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1438: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1438: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1438: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1438: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1438: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1438: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1438: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1438: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1438: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1438: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1438: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 imagelist.c:1438: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 imagelist.c:1438: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 imagelist.c:1438: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 === W7PRO (32 bit imagelist) === imagelist.c:1438: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1438: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1438: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1438: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1438: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1438: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1438: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1438: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1438: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1438: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1438: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1438: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1438: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 imagelist.c:1438: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 imagelist.c:1438: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 imagelist.c:1438: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 === W7PROX64 (32 bit imagelist) === imagelist.c:1438: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1438: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1438: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1438: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1438: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1438: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1438: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1438: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1438: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1438: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1438: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1438: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1438: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 imagelist.c:1438: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 imagelist.c:1438: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 imagelist.c:1438: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 === W7PROX64 (64 bit imagelist) === imagelist.c:1438: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1438: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1438: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1438: Test failed: BeginDrag failed for { 10, 7 }, 0x00000000 imagelist.c:1438: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1438: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1438: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1438: Test failed: BeginDrag failed for { 47, 31 }, 0x00000000 imagelist.c:1438: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1438: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1438: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1438: Test failed: BeginDrag failed for { -9, -8 }, 0x00000000 imagelist.c:1438: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 imagelist.c:1438: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 imagelist.c:1438: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000 imagelist.c:1438: Test failed: BeginDrag failed for { -7, 35 }, 0x00000000

1 0

Re: avifil32: Fix EditStreamSetInfo wine checks
by testbot＠testbot.winehq.org 15 Aug '10

15 Aug '10

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=4442 Your paranoid android. === W98SE (32 bit api) === No test summary line found === WNT4WSSP6 (32 bit api) === No test summary line found === W2KPROSP4 (32 bit api) === No test summary line found === W2K3R2SESP2 (32 bit api) === No test summary line found === WVISTAADM (32 bit api) === No test summary line found === W2K8SE (32 bit api) === No test summary line found === W7PRO (32 bit api) === No test summary line found === W7PROX64 (32 bit api) === No test summary line found === W7PROX64 (64 bit api) === Timeout

1 0

Re: [2/2] ws2_32, WS2_sendto: Avoid error when sending zero byte buffer (try 2)
by Mike Kaplinskiy 14 Aug '10

14 Aug '10

Several things: - Don't set errno. For good practice it's more or less read-only. - All the tests have to pass after each patch, so if your tests fail (which they probably should) without your patch, add todo_wine and then remove them in the followup patch (or just send the tests second). - The tests you provided pass without this patch so I'm not convinced that your fix is necessary. errno 107 = ENOTCONN, so while 0 length sends work just fine, they only work when non-zero sends also work. i.e. invalid sends get turned to valid sends on windows when the length is 0. It might be better to test calling WSASendTo with 0 length on unconnected tcp (or udp if tcp doesn't work) sockets. Good luck, Mike. On Sat, Aug 14, 2010 at 5:45 AM, Wolfgang Schwotzer <wolfgang.schwotzer(a)gmx.net> wrote: > This solves #19397. > > > > >

1 0

Re: [(try 2) 02/11] d3d10: Implement D3D10CreateBlob().
by Stefan Dösinger 13 Aug '10

13 Aug '10

Am 11.08.2010 um 21:51 schrieb Rico Schüller: > --- a/dlls/d3d10/d3d10_private.h > +++ b/dlls/d3d10/d3d10_private.h > @@ -212,6 +212,17 @@ struct d3d10_effect > struct d3d10_effect_technique *techniques; > }; > > > +extern const struct ID3D10BlobVtbl d3d10_blob_vtbl DECLSPEC_HIDDEN; Do you need the declaration of the vtable in the header? As far as I can see you're not using it anywhere outside d3d10_main.c.

3 2

Fwd: Should we expect Liberation fonts to be installed?
by Paul "TBBle" Hampson 12 Aug '10

12 Aug '10

Sorry, I failed at Gmail again. >_< ---------- Forwarded message ---------- From: Paul "TBBle" Hampson <Paul.Hampson(a)pobox.com> Date: 12 August 2010 13:52 Subject: Re: Should we expect Liberation fonts to be installed? To: Scott Ritchie <scott(a)open-vote.org> On 8 August 2010 13:02, Scott Ritchie <scott(a)open-vote.org> wrote: > On 08/03/2010 01:57 PM, Scott Ritchie wrote: >> I was looking through our fairly large collection of open font bugs and >> realized that things might be a lot simpler if we took some opinionated >> positions and just declared certain fonts to be dependencies and >> expected all packagers to provide them. >> >> This is similar to bundling our own Tahoma, except much less work. >> >> >> This bug, for instance, prevents Photoshop from working unless there is >> an Arial font installed: http://bugs.winehq.org/show_bug.cgi?id=9623 >> >> Wine doesn't seem to respect system-level fontconfig aliases, so even >> though Liberation Sans is installed on the system Photoshop won't try to >> use it in place of Arial. >> >> But if however we assumed that Liberation Sans was installed, we could >> make things much better: a link/substitution for Arial->Liberation Sans >> could be provided in our own registry (and similarly for Times New Roman >> and Courier). An alternative is to simply symlink to the Liberation >> Fonts in /usr/share/wine/fonts as though they were our own shipped fonts >> (like Tahoma). >> >> This would make Photoshop think Arial was present and keep it >> functional. Ideally the real Arial would be displayed if it was >> installed (eg through winetricks corefonts or by installing the >> distro-provided corefonts package). >> >> >> A related question is whether to show "Arial" in the list of fonts (eg >> notepad) when we're actually just providing a substituted Arial. My >> inclination says no, however I'm not sure how it works internally and >> what an application would expect. >> > > Assuming for a moment this is a good idea, what's the best > implementation? My inclination is to say some registry font links, but > I'm not completely familiar with how that works. > > Will font links in the registry be ignored when the real font is present? (Wine-specific) Font Replacements will be ignored when the real font is present. Those're the ones in HKCU\Software\Wine\Fonts\Replacements and probably the ones you want to use. (Which could be supplanted or supplemented by working FontConfig alias support...) (GDI) Font Links (ie. the same registry entries Windows uses) are fallbacks for missing glyphs. Those're the ones in HKLM\SOFTWARE\Microsoft\FontLink\SystemLink Font Substitutes _probably_ don't get ignored if a real font with that name exists. Those're the ones in HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\FontSubstitutes and they're pretty purpose-specific. The only entries we want for them in Wine are the ones described at http://blogs.msdn.com/b/michkap/archive/2005/03/20/399322.aspx (which should probably be the default in Wine anyway, at least the Tahoma entry.) (Which by-the-by highlights a mistake in my previous suggestion towards bug 13829) -- Paul "TBBle" Hampson, Paul.Hampson(a)Pobox.com On 12 August 2010 13:52, Paul "TBBle" Hampson <Paul.Hampson(a)pobox.com> wrote: > (Wine-specific) Font Replacements will be ignored when the real font > is present. Those're the ones in HKCU\Software\Wine\Fonts\Replacements > and probably the ones you want to use. (Which could be supplanted or > supplemented by working FontConfig alias support...) To be clear, I think the best first-step solution for this bug is for Wine's Font Replacements code to read the aliases from FontConfig as well as its own registry keys when building its list. (The latter being taken over the former) That would make the problem magically go away on systems that do include appropriately-substitutable fonts. -- Paul "TBBle" Hampson, Paul.Hampson(a)Pobox.com

2 2

Re: Windows Imaging Component
by Roderick Colenbrander 12 Aug '10

12 Aug '10

On Thu, Aug 12, 2010 at 4:54 AM, Georgij Kirichenko <kirichenkoga(a)gmail.com> wrote: > This patch add support for decoding Dds, Ppm(and pgm, pbm) and Tga files th > Windows Imaging Component. Each format you are adding requires its own patch. > This patch use dynamic linked FreeImage library, but i'am can't static link > this library. First of all, I'm not so sure we want to use FreeImage. The initial thing about which I'm not sure is the license. You can use it under either a commercial license or under the GPL. The last one at least is usable for us as it would make all of Wine GPL when you link to it. I'm not sure about the 'free image public license terms'. It is not something like a BSD license, but more complicated. Someone would have to look at it whether that would even be usable (commercial versions like Crossover would have issues). >From what I remember TGA, and the PPM family are at least easy (not sure about DDS though, but I believe it is easy as well). If there are good standalone libs like libjpeg, libpng and friends for such libraries which are either BSD or LGPL licensed (or something similar that would be fine). We might also want to do them ourselves if we wanted (and they are relatively trivial). Lets wait for what others are saying. Roderick

1 1

Re: Windows Imaging Component
by Kirill K. Smirnov 12 Aug '10

12 Aug '10

1 0

Re: [PATCH 1/2] dmime/tests: Added tests for IDirectMusicPerformance.
by David Adam 12 Aug '10

12 Aug '10

Hello, some comments about this patch + if (hr != S_OK) return FALSE; + else return TRUE; could be simplified as return SUCCEEDED(hr); + trace("HRESULT when creating instance (%x)\n", hr); Since tests are assumed to pass, we dont care about debug informations. So, traces are useless in tests. [It is my opinion. Better developpers could give an opposite opinion] + todo_wine ok(*(ULONG *)pDirectMusicPort != 0, "IDirectMusicPort not set\n"); Why is this cast useful? A+ David 2010/8/9 Austin Lund <austin.lund(a)gmail.com> > > > > >

6 9

Re: [PATCH 1/2] dmime/tests: Added tests for IDirectMusicPerformance. (try 2)
by Vitaliy Margolen 12 Aug '10

12 Aug '10

On 08/11/2010 08:58 PM, Austin Lund wrote: > > > +static BOOL test_InitAudio(void) > +{ > + hr = IDirectMusicPerformance8_InitAudio(idmusicperformance,NULL,&pDirectSound,NULL,1,128,0x3f,NULL); > + if (hr != S_OK) return FALSE; > + else return TRUE; > +} Please put spaces after comas, as you do in the rest of the file. What are those magic numbers? Please use constants. If they are missing, add them to appropriate header file first. Same thing with return as in prior function.. > +static void test_PChannelInfo(void) Already covered in another thread. Vitaliy.

2 2

Re: [PATCH 1/2] dmime/tests: Added tests for IDirectMusicPerformance. (try 2)
by James McKenzie 12 Aug '10

12 Aug '10

Austin Lund wrote: Why the try2? It is always nice to put why you are doing this in the git commit notes. AJ is on vakay and will not be back until next week so there are NO reviews ongoing this week, except developer peer ones. James McKenzie

2 1

Re: [PATCH] qmgr/tests: Detect, when the service is disabled
by testbot＠testbot.winehq.org 11 Aug '10

11 Aug '10

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=4405 Your paranoid android. === W98SE (32 bit qmgr) === qmgr.c:46: Test failed: CoCreateInstance failed: 80040154

1 0

Wine users with a CD-ROM drive, please test
by Joerg-Cyril.Hoehle＠t-systems.com 11 Aug '10

11 Aug '10

Hi, No more MCIERR_HARDWARE in David's latest test result, hurray! The difference with prior tests is that I temporarily eliminated 3 commands a) resume c b) set c video audio all off c) set c door closed notify We are not done yet. Users who saw that error please feed the following scripts into the mcishell to see which of those 3 commands causes the failure. The mcishell is attached to bug #20232 at http://bugs.winehq.org/show_bug.cgi?id=20232#c10 http://bugs.winehq.org/attachment.cgi?id=24529 wintest.exe mcishell mci.c:1363: Type your commands to the MCI, end with Ctrl-Z The 5 test failures in David's report are unrelated to MCIERR_HARDWARE. >mcicda.c:540: Test failed: status mode after play is playing Weird. I'd have expected Play to terminate within Sleep(3900ms) time. >mcicda.c:297: Test failed: status position initially 00:02:33 I'll take care of that another day. For now I'll just remember that there are disks that don't start at position 00:02:00. Please copy&paste these lines as one piece into a cmd shell so that there's as little delay as possible between commands. # a) resume open cdaudio alias c notify shareable status c mode status c position play c from 00:02:00 to 00:01:00 notify resume c status c mode seek c to start notify status c mode seek c to end # # testsuite uses seek c to MM:SS:FF instead set c time format tmsf play c from 1 stop c Don't forget after each one close c # b) set video audio open cdaudio alias c notify shareable status c mode status c position play c from 00:02:00 to 00:01:00 notify seek c to start notify set c video audio all off status c mode seek c to end # # testsuite uses seek c to MM:SS:FF instead set c time format tmsf play c from 1 stop c # c) set door closed open cdaudio alias c notify shareable status c mode status c position play c from 00:02:00 to 00:01:00 notify seek c to start notify set c door closed notify status c mode seek c to end # # testsuite uses seek c to MM:SS:FF instead set c time format tmsf play c from 1 stop c Thank you for testing, Jörg Höhle

1 0

Request for comments - d3dx9: Add tests for FVF <-> declaration conversion.
by misha680 10 Aug '10

10 Aug '10

Dear All: I have become more busy with schoolwork than I had imagined. However, I would still like, if possible, to finish work on http://bugs.winehq.org/show_bug.cgi?id=22918 It has been suggested that I send patches to the wine-devel list first for feedback. This way, I hope to be able to get developer expertise in these areas, and to be able to understand exactly what is necessary for a given patch. I have, per this comment from Henri: http://bugs.winehq.org/show_bug.cgi?id=22918#c51 written a draft patch for FVF <-> declaration conversion tests. It can be found at the Nabble link below. I will appreciate comments as to what is necessary for this patch (or a similar one) to get accepted. http://wine.1045685.n5.nabble.com/file/n2471306/0001-d3dx9-Add-tests-for-FV… 0001-d3dx9-Add-tests-for-FVF-declaration-conversion.txt I realize there are already three tests for conversion in one direction. I have decided at the moment to leave those as is and focus on getting necessary feedback for getting an appropriate patch accepted. If you have any guidance with regards to this, much appreciated. Thank you Misha p.s. I have uploaded some shell scripts that I use for Wine development here: http://groups.google.com/group/misha680-wine/files I don't know how useful they will be to anyone else, but if anything, it provides an nice backup for my computer. -- View this message in context: http://wine.1045685.n5.nabble.com/Request-for-comments-d3dx9-Add-tests-for-… Sent from the Wine - Devel mailing list archive at Nabble.com.

2 2

Re: [PATCH 1/5] ddraw/tests: Add test for bad size of surface caps in CreateSurface. (try 5)
by Stefan Dösinger 10 Aug '10

10 Aug '10

Diff -u doesn't find any difference between try 4 and try 5, and probably older tries. If you're resending them because the older ones weren't applied, that's futile - Alexandre is on vacation. Also it is generally a bad idea to keep resending a unchanged patch. If you think the patch has been lost(e.g. Alexandre is waiting for my review and I am not at home, etc) it is better to ask on Wine-devel what is up with the patches. Am Sonntag 08 August 2010, 07:09:24 schrieb Oldřich Jedlička: > --- > dlls/ddraw/tests/dsurface.c | 138 > +++++++++++++++++++++++++++++++++++++++++++ 1 files changed, 138 > insertions(+), 0 deletions(-) > > diff --git a/dlls/ddraw/tests/dsurface.c b/dlls/ddraw/tests/dsurface.c > index 76bfc7e..8cdcd92 100644 > --- a/dlls/ddraw/tests/dsurface.c > +++ b/dlls/ddraw/tests/dsurface.c > @@ -25,6 +25,7 @@ > > #include <assert.h> > #include "wine/test.h" > +#include "wine/exception.h" > #include "ddraw.h" > #include "d3d.h" > #include "unknwn.h" > @@ -3569,6 +3570,142 @@ static void BackBufferAttachmentFlipTest(void) > DestroyWindow(window); > } > > +static void CreateSurfaceBadCapsSizeTest(void) > +{ > + DDSURFACEDESC ddsd_ok; > + DDSURFACEDESC ddsd_bad1; > + DDSURFACEDESC ddsd_bad2; > + DDSURFACEDESC ddsd_bad3; > + DDSURFACEDESC ddsd_bad4; > + DDSURFACEDESC2 ddsd2_ok; > + DDSURFACEDESC2 ddsd2_bad1; > + DDSURFACEDESC2 ddsd2_bad2; > + DDSURFACEDESC2 ddsd2_bad3; > + DDSURFACEDESC2 ddsd2_bad4; > + IDirectDrawSurface *surf; > + IDirectDrawSurface4 *surf4; > + IDirectDrawSurface7 *surf7; > + HRESULT hr; > + IDirectDraw2 *dd2; > + IDirectDraw4 *dd4; > + IDirectDraw7 *dd7; > + > + const DWORD caps = DDSCAPS_OFFSCREENPLAIN; > + > + memset(&ddsd_ok, 0, sizeof(ddsd_ok)); > + ddsd_ok.dwSize = sizeof(ddsd_ok); > + ddsd_ok.dwFlags = DDSD_CAPS | DDSD_WIDTH | DDSD_HEIGHT; > + ddsd_ok.dwWidth = 64; > + ddsd_ok.dwHeight = 64; > + ddsd_ok.ddsCaps.dwCaps = caps; > + memcpy(&ddsd_bad1, &ddsd_ok, sizeof(ddsd_bad1)); > + ddsd_bad1.dwSize--; > + memcpy(&ddsd_bad2, &ddsd_ok, sizeof(ddsd_bad2)); > + ddsd_bad2.dwSize++; > + memcpy(&ddsd_bad3, &ddsd_ok, sizeof(ddsd_bad3)); > + ddsd_bad3.dwSize = 0; > + memcpy(&ddsd_bad4, &ddsd_ok, sizeof(ddsd_bad4)); > + ddsd_bad4.dwSize = sizeof(DDSURFACEDESC2); > + > + memset(&ddsd2_ok, 0, sizeof(ddsd2_ok)); > + ddsd2_ok.dwSize = sizeof(ddsd2_ok); > + ddsd2_ok.dwFlags = DDSD_CAPS | DDSD_WIDTH | DDSD_HEIGHT; > + ddsd2_ok.dwWidth = 64; > + ddsd2_ok.dwHeight = 64; > + ddsd2_ok.ddsCaps.dwCaps = caps; > + memcpy(&ddsd2_bad1, &ddsd2_ok, sizeof(ddsd2_bad1)); > + ddsd2_bad1.dwSize--; > + memcpy(&ddsd2_bad2, &ddsd2_ok, sizeof(ddsd2_bad2)); > + ddsd2_bad2.dwSize++; > + memcpy(&ddsd2_bad3, &ddsd2_ok, sizeof(ddsd2_bad3)); > + ddsd2_bad3.dwSize = 0; > + memcpy(&ddsd2_bad4, &ddsd2_ok, sizeof(ddsd2_bad4)); > + ddsd2_bad4.dwSize = sizeof(DDSURFACEDESC); > + > + hr = IDirectDraw_CreateSurface(lpDD, &ddsd_ok, &surf, NULL); > + ok(SUCCEEDED(hr), "IDirectDraw_CreateSurface failed: 0x%08x\n", hr); > + IDirectDrawSurface_Release(surf); > + > + hr = IDirectDraw_CreateSurface(lpDD, &ddsd_bad1, &surf, NULL); > + todo_wine ok(hr == DDERR_INVALIDPARAMS, "IDirectDraw_CreateSurface > didn't return 0x%08x, but 0x%08x\n", + DDERR_INVALIDPARAMS, hr); > + hr = IDirectDraw_CreateSurface(lpDD, &ddsd_bad2, &surf, NULL); > + todo_wine ok(hr == DDERR_INVALIDPARAMS, "IDirectDraw_CreateSurface > didn't return 0x%08x, but 0x%08x\n", + DDERR_INVALIDPARAMS, hr); > + hr = IDirectDraw_CreateSurface(lpDD, &ddsd_bad3, &surf, NULL); > + ok(hr == DDERR_INVALIDPARAMS, "IDirectDraw_CreateSurface didn't return > 0x%08x, but 0x%08x\n", + DDERR_INVALIDPARAMS, hr); > + hr = IDirectDraw_CreateSurface(lpDD, &ddsd_bad4, &surf, NULL); > + todo_wine ok(hr == DDERR_INVALIDPARAMS, "IDirectDraw_CreateSurface > didn't return 0x%08x, but 0x%08x\n", + DDERR_INVALIDPARAMS, hr); > + > + hr = IDirectDraw_QueryInterface(lpDD, &IID_IDirectDraw2, (void **) > &dd2); + ok(SUCCEEDED(hr), "IDirectDraw_QueryInterface failed: > 0x%08x\n", hr); + > + hr = IDirectDraw2_CreateSurface(dd2, &ddsd_ok, &surf, NULL); > + ok(SUCCEEDED(hr), "IDirectDraw2_CreateSurface failed: 0x%08x\n", hr); > + IDirectDrawSurface_Release(surf); > + > + hr = IDirectDraw2_CreateSurface(dd2, &ddsd_bad1, &surf, NULL); > + todo_wine ok(hr == DDERR_INVALIDPARAMS, "IDirectDraw2_CreateSurface > didn't return 0x%08x, but 0x%08x\n", + DDERR_INVALIDPARAMS, hr); > + hr = IDirectDraw2_CreateSurface(dd2, &ddsd_bad2, &surf, NULL); > + todo_wine ok(hr == DDERR_INVALIDPARAMS, "IDirectDraw2_CreateSurface > didn't return 0x%08x, but 0x%08x\n", + DDERR_INVALIDPARAMS, hr); > + hr = IDirectDraw2_CreateSurface(dd2, &ddsd_bad3, &surf, NULL); > + ok(hr == DDERR_INVALIDPARAMS, "IDirectDraw2_CreateSurface didn't > return 0x%08x, but 0x%08x\n", + DDERR_INVALIDPARAMS, hr); > + hr = IDirectDraw2_CreateSurface(dd2, &ddsd_bad4, &surf, NULL); > + todo_wine ok(hr == DDERR_INVALIDPARAMS, "IDirectDraw2_CreateSurface > didn't return 0x%08x, but 0x%08x\n", + DDERR_INVALIDPARAMS, hr); > + > + IDirectDraw2_Release(dd2); > + > + hr = IDirectDraw_QueryInterface(lpDD, &IID_IDirectDraw4, (void **) > &dd4); + ok(SUCCEEDED(hr), "IDirectDraw_QueryInterface failed: > 0x%08x\n", hr); + > + hr = IDirectDraw4_CreateSurface(dd4, &ddsd2_ok, &surf4, NULL); > + ok(SUCCEEDED(hr), "IDirectDraw4_CreateSurface failed: 0x%08x\n", hr); > + IDirectDrawSurface4_Release(surf4); > + > + hr = IDirectDraw4_CreateSurface(dd4, &ddsd2_bad1, &surf4, NULL); > + todo_wine ok(hr == DDERR_INVALIDPARAMS, "IDirectDraw4_CreateSurface > didn't return 0x%08x, but 0x%08x\n", + DDERR_INVALIDPARAMS, hr); > + hr = IDirectDraw4_CreateSurface(dd4, &ddsd2_bad2, &surf4, NULL); > + todo_wine ok(hr == DDERR_INVALIDPARAMS, "IDirectDraw4_CreateSurface > didn't return 0x%08x, but 0x%08x\n", + DDERR_INVALIDPARAMS, hr); > + hr = IDirectDraw4_CreateSurface(dd4, &ddsd2_bad3, &surf4, NULL); > + ok(hr == DDERR_INVALIDPARAMS, "IDirectDraw4_CreateSurface didn't > return 0x%08x, but 0x%08x\n", + DDERR_INVALIDPARAMS, hr); > + hr = IDirectDraw4_CreateSurface(dd4, &ddsd2_bad4, &surf4, NULL); > + todo_wine ok(hr == DDERR_INVALIDPARAMS, "IDirectDraw4_CreateSurface > didn't return 0x%08x, but 0x%08x\n", + DDERR_INVALIDPARAMS, hr); > + > + IDirectDraw4_Release(dd4); > + > + hr = IDirectDraw_QueryInterface(lpDD, &IID_IDirectDraw7, (void **) > &dd7); + ok(SUCCEEDED(hr), "IDirectDraw_QueryInterface failed: > 0x%08x\n", hr); + > + hr = IDirectDraw7_CreateSurface(dd7, &ddsd2_ok, &surf7, NULL); > + ok(SUCCEEDED(hr), "IDirectDraw7_CreateSurface failed: 0x%08x\n", hr); > + IDirectDrawSurface7_Release(surf7); > + > + hr = IDirectDraw7_CreateSurface(dd7, &ddsd2_bad1, &surf7, NULL); > + todo_wine ok(hr == DDERR_INVALIDPARAMS, "IDirectDraw7_CreateSurface > didn't return 0x%08x, but 0x%08x\n", + DDERR_INVALIDPARAMS, hr); > + hr = IDirectDraw7_CreateSurface(dd7, &ddsd2_bad2, &surf7, NULL); > + todo_wine ok(hr == DDERR_INVALIDPARAMS, "IDirectDraw7_CreateSurface > didn't return 0x%08x, but 0x%08x\n", + DDERR_INVALIDPARAMS, hr); > + hr = IDirectDraw7_CreateSurface(dd7, &ddsd2_bad3, &surf7, NULL); > + ok(hr == DDERR_INVALIDPARAMS, "IDirectDraw7_CreateSurface didn't > return 0x%08x, but 0x%08x\n", + DDERR_INVALIDPARAMS, hr); > + hr = IDirectDraw7_CreateSurface(dd7, &ddsd2_bad4, &surf7, NULL); > + todo_wine ok(hr == DDERR_INVALIDPARAMS, "IDirectDraw7_CreateSurface > didn't return 0x%08x, but 0x%08x\n", + DDERR_INVALIDPARAMS, hr); > + > + IDirectDraw7_Release(dd7); > +} > + > START_TEST(dsurface) > { > HRESULT ret; > @@ -3624,5 +3761,6 @@ START_TEST(dsurface) > GetDCFormatTest(); > BackBufferCreateSurfaceTest(); > BackBufferAttachmentFlipTest(); > + CreateSurfaceBadCapsSizeTest(); > ReleaseDirectDraw(); > }

2 2

X Presentation and Synchronization - will it help Wine performance
by Groeschel, Volker 10 Aug '10

10 Aug '10

Hi, I wonder if Wine will profit from the new X Presentation and Synchronization feature NVIDIA is working on: http://people.freedesktop.org/~aplattner/x-presentation-and-synchronization… According to the Phoronix article the feature is planed for X.Org Server 1.10: http://www.phoronix.com/scan.php?page=news_item&px=ODM3Ng e.g. when I start several instances of my game with Wine on my computer (AMD X2 with Ubuntu and proprietary NVIDIA graphic drivers), performance breaks down dramatically. As of three instances the third windows freezes or gets near 0 FPS while the same computer with Win XP can run up to eight instances. Many thanks for your good work which helps me to get rid of Windows in my home office ☺

3 2

New and subtle ddraw:dsurface test failure
by wylda＠volny.cz 10 Aug '10

10 Aug '10

Hi, i just noticed some new and subtle failure in ddraw:dsurface tests. I don't know how closely you watch and study tests results, so i thought it might be a good idea bring it the the light. Sorry if not ;-) Compared WinXP 277040d92454 vs 8b2a403a7dc3 (latest vs last Friday). Interestingly does not happen on Intel and nVidia 64bit. So the only affected is nVidia 32bit. (For my education) Generally, when the test fails in Windows world, it means that the test is wrongly written or not supported under the tested Windows version? (not blaming anyone, just asking how things work;) And the last question is about MSI failures and timeouts which some boxes suffers... In my case the "powerful" succeeds and the "weak" timeouts here (and not just mine). Shouldn't be the timeout prolonged? Regards, W. PS: I probably missed "gratulation time" for v1.2, so at least i wish all the goodness to 1.3.xx line! And hope i find another free time for buzilla soon.

5 6

Re: winex11.drv: Fix uninitialised values. (valgrind) (try 2)
by Michael Stefaniuc 10 Aug '10

10 Aug '10

Hello Austin, Austin Lund wrote: > > ------------------------------------------------------------------------ > From 07bc18edc35c68c8e0da58a70ccd5c8f03584a1a Mon Sep 17 00:00:00 2001 > From: Austin Lund <austin.lund(a)gmail.com> > Date: Tue, 10 Aug 2010 13:03:14 +1000 > Subject: [PATCH] winex11.drv: Fix uninitialised values. (valgrind) > > --- > dlls/winex11.drv/bitmap.c | 2 +- > dlls/winex11.drv/dib.c | 2 +- > 2 files changed, 2 insertions(+), 2 deletions(-) > > diff --git a/dlls/winex11.drv/bitmap.c b/dlls/winex11.drv/bitmap.c > index 4683fd9..af6c00b 100644 > --- a/dlls/winex11.drv/bitmap.c > +++ b/dlls/winex11.drv/bitmap.c > @@ -351,7 +351,7 @@ LONG CDECL X11DRV_SetBitmapBits( HBITMAP hbitmap, const void *bits, LONG count ) > wine_tsx11_lock(); > image = XCreateImage( gdi_display, visual, physBitmap->pixmap_depth, ZPixmap, 0, NULL, > bitmap.bmWidth, height, 32, 0 ); > - if (!(image->data = HeapAlloc( GetProcessHeap(), 0, image->bytes_per_line * height ))) > + if (!(image->data = HeapAlloc( GetProcessHeap(), HEAP_ZERO_MEMORY, image->bytes_per_line * height ))) > { > WARN("No memory to create image data.\n"); > XDestroyImage( image ); > diff --git a/dlls/winex11.drv/dib.c b/dlls/winex11.drv/dib.c > index 11157f1..eda064e 100644 > --- a/dlls/winex11.drv/dib.c > +++ b/dlls/winex11.drv/dib.c > @@ -3535,7 +3535,7 @@ static int X11DRV_DIB_SetImageBits( const X11DRV_DIB_IMAGEBITS_DESCR *descr ) > else { > bmpImage = XCreateImage( gdi_display, visual, descr->depth, ZPixmap, 0, NULL, > descr->infoWidth, lines, 32, 0 ); > - bmpImage->data = HeapAlloc( GetProcessHeap(), 0, lines * bmpImage->bytes_per_line ); > + bmpImage->data = HeapAlloc( GetProcessHeap(), HEAP_ZERO_MEMORY, lines * bmpImage->bytes_per_line ); > if(bmpImage->data == NULL) { > ERR("Out of memory!\n"); > XDestroyImage( bmpImage ); > both functions are heavily used and you don't want to waste time HEAP_ZERO_MEMORY just to please valgrind. I even wonder why valgrind complains as e.g. in X11DRV_SetBitmapBits() only the default switch case won't initialize the memory at all. bye michael

2 2

Re: [PATCH] quartz: implement AsyncReader_FindPin
by David Adam 09 Aug '10

09 Aug '10

Hi, what about if ppPin is NULL? I think that this patch needs test cases to prove that it is correct? David 2010/8/6 Anton Khirnov <wyskas(a)gmail.com> > --- > dlls/quartz/filesource.c | 32 ++++++++++++++++++++++++++++++-- > 1 files changed, 30 insertions(+), 2 deletions(-) > > diff --git a/dlls/quartz/filesource.c b/dlls/quartz/filesource.c > index 110415d..00a91c8 100644 > --- a/dlls/quartz/filesource.c > +++ b/dlls/quartz/filesource.c > @@ -548,9 +548,37 @@ static HRESULT WINAPI AsyncReader_EnumPins(IBaseFilter > * iface, IEnumPins **ppEn > > static HRESULT WINAPI AsyncReader_FindPin(IBaseFilter * iface, LPCWSTR Id, > IPin **ppPin) > { > - FIXME("(%s, %p)\n", debugstr_w(Id), ppPin); > + IEnumPins *enumpins; > + HRESULT hr; > > - return E_NOTIMPL; > + hr = AsyncReader_EnumPins(iface, &enumpins); > + if (FAILED(hr)) > + return S_FALSE; > + > + while (hr == S_OK) { > + IPin *pin; > + LPWSTR pinname; > + > + hr = IEnumPins_Next(enumpins, 1, &pin, NULL); > + if (FAILED(hr)) > + break; > + > + hr = IPin_QueryId(pin, &pinname); > + if (SUCCEEDED(hr)) { > + if (!strcmpW(pinname, Id)) { > + *ppPin = pin; > + IPin_AddRef(*ppPin); > + CoTaskMemFree(pinname); > + break; > + } > + CoTaskMemFree(pinname); > + } > + } > + > + IEnumPins_Release(enumpins); > + if (SUCCEEDED(hr)) > + return S_OK; > + return S_FALSE; > } > > static HRESULT WINAPI AsyncReader_QueryFilterInfo(IBaseFilter * iface, > FILTER_INFO *pInfo) > -- > 1.7.1 > > > >

2 1

'winetricks python' and user-submitted small testcases
by Dan Kegel 08 Aug '10

08 Aug '10

Waaaay back in 2002, the wine project experimented with writing win32 conformance tests in Perl. Nobody liked it; it was dropped in favor of conformance tests in C, and there was much rejoicing. Today I noticed http://bugs.winehq.org/show_bug.cgi?id=23940 which has a simple win32 test case written in Python. Surprisingly, with 'winetricks python', the test case ran and demonstrated the problem (though since the python script expected you to start another app first, and edit the python to have the other app's window title, it wasn't an unattended test). That particular bug isn't anything special, but I was happy to see that a user who preferred Python was able to successfully send a minimal test case for a win32 problem written in his favorite language, and have someone else successfully run it.

1 0

Re: [PATCH 5/5] ddraw: Allow creating back buffer for DirectX 1 interfaces. (try 5)
by testbot＠testbot.winehq.org 08 Aug '10

08 Aug '10

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=4356 Your paranoid android. === W2KPROSP4 (32 bit visual) === visual.c:1742: Test failed: Got color 000a246a, expected 00000000 visual.c:1748: Test failed: Got color 006b8bbd, expected 00ff0000 or near visual.c:1751: Test failed: Got color 00ffffff, expected 00000000 visual.c:1757: Test failed: Got color 00ffffff, expected 00800000 or near === W98SE (32 bit dsurface) === No test summary line found

1 0

Re: gdi32: use usp10 to optionally generate glyphs for bidi strings
by Dmitry Timoshkov 08 Aug '10

08 Aug '10

Aric Stewart <aric(a)codeweavers.com> wrote: > allows us to be able to make use of the mirroring code and eventually > the shaping code when it is in place. This should be done the other way around. gdi32 should not depend on a high level dll (that creates circular dependencies), gdi32 in Windows doesn't use usp10 either. -- Dmitry.

4 5

Re: [PATCH 1/5] ddraw/tests: Add test for bad size of surface caps in CreateSurface. (try 5)
by testbot＠testbot.winehq.org 08 Aug '10

08 Aug '10

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=4352 Your paranoid android. === W98SE (32 bit dsurface) === No test summary line found

1 0

Should we expect Liberation fonts to be installed?
by Scott Ritchie 08 Aug '10

08 Aug '10

I was looking through our fairly large collection of open font bugs and realized that things might be a lot simpler if we took some opinionated positions and just declared certain fonts to be dependencies and expected all packagers to provide them. This is similar to bundling our own Tahoma, except much less work. This bug, for instance, prevents Photoshop from working unless there is an Arial font installed: http://bugs.winehq.org/show_bug.cgi?id=9623 Wine doesn't seem to respect system-level fontconfig aliases, so even though Liberation Sans is installed on the system Photoshop won't try to use it in place of Arial. But if however we assumed that Liberation Sans was installed, we could make things much better: a link/substitution for Arial->Liberation Sans could be provided in our own registry (and similarly for Times New Roman and Courier). An alternative is to simply symlink to the Liberation Fonts in /usr/share/wine/fonts as though they were our own shipped fonts (like Tahoma). This would make Photoshop think Arial was present and keep it functional. Ideally the real Arial would be displayed if it was installed (eg through winetricks corefonts or by installing the distro-provided corefonts package). A related question is whether to show "Arial" in the list of fonts (eg notepad) when we're actually just providing a substituted Arial. My inclination says no, however I'm not sure how it works internally and what an application would expect. Thanks, Scott Ritchie

2 3

Re: [PATCH 5/5] ddraw: Allow creating back buffer for DirectX 1 interfaces. (try 4)
by testbot＠testbot.winehq.org 07 Aug '10

07 Aug '10

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=4348 Your paranoid android. === W2KPROSP4 (32 bit visual) === visual.c:2970: Test failed: IDirectDraw_CreateSurface returned: 80070057 visual.c:2986: Test failed: IDirectDraw_CreateSurface returned: 88760091 === W98SE (32 bit dsurface) === No test summary line found

1 0

Re: [PATCH 2/5] ddraw/tests: New visual back buffer flipping tests. (try 4)
by testbot＠testbot.winehq.org 07 Aug '10

07 Aug '10

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=4345 Your paranoid android. === W2KPROSP4 (32 bit visual) === visual.c:2970: Test failed: IDirectDraw_CreateSurface returned: 80070057 visual.c:2986: Test failed: IDirectDraw_CreateSurface returned: 88760091

1 0

Re: [PATCH 1/5] ddraw/tests: Add test for bad size of surface caps in CreateSurface. (try 4)
by testbot＠testbot.winehq.org 07 Aug '10

07 Aug '10

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=4344 Your paranoid android. === W98SE (32 bit dsurface) === No test summary line found

1 0

Re: user32: Don't crash for unknown button styles
by Nikolay Sivov 07 Aug '10

07 Aug '10

On 8/6/2010 22:22, André Hentschel wrote: > got that case with an MFC application which had a 3state radiobutton with buttonstyle 15(decimal) > with this fix everything is fine as the painting of the button is handled elsewhere, without that fix it crashes as it reads bad data behind the array. > > --- > dlls/user32/button.c | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/dlls/user32/button.c b/dlls/user32/button.c > index 54d54dc..4f629f0 100644 > --- a/dlls/user32/button.c > +++ b/dlls/user32/button.c > @@ -197,7 +197,7 @@ static inline UINT get_button_type( LONG window_style ) > /* paint a button of any type */ > static inline void paint_button( HWND hwnd, LONG style, UINT action ) > { > - if (btnPaintFunc[style]&& IsWindowVisible(hwnd)) > + if (style<= MAX_BTN_TYPE&& btnPaintFunc[style]&& IsWindowVisible(hwnd)) > { > HDC hdc = GetDC( hwnd ); > btnPaintFunc[style]( hwnd, hdc, action ); This needs a test to see what happens visually for style 0xf, maybe we need just to duplicate an entry in paint function table; also while you're at it: static inline UINT get_button_type( LONG window_style ) { return (window_style & 0x0f); } here BS_TYPEMASK should be used instead of 0xf.

2 4

Re: Configuring with -Werror
by André Hentschel 07 Aug '10

07 Aug '10

> Configuring with -Werror used to work a while back for me; now that > -Wno-unused-result has been fixed I gave it another try and got this: > > configure: libxrandr 32-bit development files not found, XRandr won't > be supported. > configure: WARNING: Old Mesa headers detected. Consider upgrading your > Mesa libraries. > OpenGL and Direct3D won't be supported. > configure: WARNING: No sound system was found. Windows applications > will be silent. > > After a quick investigation, turns out many configure checks produce > warnings; patch below hacks around it, but I've never dealt with > configure before and apparently fixes need to go in configure.ac -- > anyone wants to give it a proper shot? Sorry for the noise on wine-patches, this should have been gone here... Patch looks ok, but that should only be changed in configure.ac... And the chance to get that in is not very high because AJ not always suppports different compilerflags. -- Best Regards, André Hentschel

1 0

Wine 1.3 packaged for Ubuntu, must be installed explicitly
by Scott Ritchie 07 Aug '10

07 Aug '10

I have added a new series of Wine 1.3 packages to the Wine PPA: https://launchpad.net/~ubuntu-wine/+archive/ppa These are for 10.04 (Lucid) only and must be explicitly installed: sudo apt-get install wine1.3 Users who simply install the wine or wine1.2 packages (as in, all existing users) will instead get the stable Wine 1.2 release, which is still packaged there. Thanks, Scott Ritchie

1 0

Configuring with -Werror
by Jerome Leclanche 07 Aug '10

07 Aug '10

Configuring with -Werror used to work a while back for me; now that -Wno-unused-result has been fixed I gave it another try and got this: configure: libxrandr 32-bit development files not found, XRandr won't be supported. configure: WARNING: Old Mesa headers detected. Consider upgrading your Mesa libraries. OpenGL and Direct3D won't be supported. configure: WARNING: No sound system was found. Windows applications will be silent. After a quick investigation, turns out many configure checks produce warnings; patch below hacks around it, but I've never dealt with configure before and apparently fixes need to go in configure.ac -- anyone wants to give it a proper shot? Jerome L. diff --git a/configure b/configure index 05a9317..ae29fe4 100755 --- a/configure ++ J. Leclanche / Adys+ b/configure @@ -8430,7 +8430,7 @@ int main () { static typeof(XRRSetScreenConfigAndRate) * func; - ; + if(func); return 0; } _ACEOF @@ -8685,7 +8685,7 @@ int main () { GLenum test = GL_UNSIGNED_SHORT_5_6_5; - ; + if(test); return 0; } _ACEOF @@ -10517,8 +10517,8 @@ if test "x$ac_cv_lib_asound_snd_pcm_hw_params_get_access" = x""yes; then : int main () { -int ret = snd_pcm_hw_params_get_access(NULL, NULL) - ; +int ret = snd_pcm_hw_params_get_access(NULL, NULL); + if(ret); return 0; } _ACEOF

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel