October 2013 - Wine-Devel - list.winehq.org

Re: [PATCH 3/3] opengl32: Use opengl xml registry files.

by Rico Schüller

On 31.10.2013 11:37, Henri Verbeet wrote: > On 31 October 2013 11:16, Rico Schüller <kgbricola(a)web.de> wrote: >> I found some other issues and now I think the xml seems not use able for >> us in the state it is now. Sorry for the noise. >> >> E.g. glColorSubTable is listed in the extension GL_ARB_imaging, but not >> as GL 1.2 requirement. All linux drivers support at least 1.2 (and thus >> don't expose GL_ARB_imaging), so there is no way to tell if we should >> support that function or not. We would need a separate list for that ... >> >> Imho this works for glBlendColor which is in GL_ARB_imaging and >> GL_VERSION_1_4, but this seems also wrong as it should be in GL 1.2. >> >> Did I miss anything? >> > If this is just for functions in GL_ARB_imaging, I think this is > correct / intentional. The GL "imaging subset" has always been a bit > special, and not many drivers implement it, although IIRC at least > NVIDIA does. For all the details see section 3.6.2 of the GL 1.2.1 > spec, but the bottom line is that it's not actually available unless > you have GL_ARB_imaging in the extension string, despite being > described in the GL 1.2.1 spec. > Yeah, should be mostly for GL_ARB_imaging... so basically using GL_ARB_imaging is fine then and the previous GL_VERSION_1_2 was wrong. Well there are some other issues like e.g. glVertexAttrib4ubvARB which is added by both extensions (GL_ARB_vertex_shader and GL_ARB_vertex_program) and I'm not sure there is one preferred over the other. Also, there are functions which are added in two ways, e.g. glVertexP2ui (GL_ARB_vertex_type_2_10_10_10_rev and GL_VERSION_3_3). The attached patch would fix both (and the parser needs to add list all versions and extensions). I think, it is fine, if we would have support til here, as that is what's working with the gl.spec file as of now. I'll update the complete series, if there are no other concerns. How do we handle glNamedFramebufferParameteriEXT? It basically needs two extensions (GL_ARB_framebuffer_no_attachments and GL_EXT_direct_state_access), but only a comment in the gl.xml mentions that. Do we need to take care of that case or do most drivers support both extensions anyway together? Cheers Rico

Oct. 31, 2013

Re: [PATCH 3/3] opengl32: Use opengl xml registry files.

by Henri Verbeet

On 31 October 2013 11:16, Rico Schüller <kgbricola(a)web.de> wrote: > I found some other issues and now I think the xml seems not use able for > us in the state it is now. Sorry for the noise. > > E.g. glColorSubTable is listed in the extension GL_ARB_imaging, but not > as GL 1.2 requirement. All linux drivers support at least 1.2 (and thus > don't expose GL_ARB_imaging), so there is no way to tell if we should > support that function or not. We would need a separate list for that ... > > Imho this works for glBlendColor which is in GL_ARB_imaging and > GL_VERSION_1_4, but this seems also wrong as it should be in GL 1.2. > > Did I miss anything? > If this is just for functions in GL_ARB_imaging, I think this is correct / intentional. The GL "imaging subset" has always been a bit special, and not many drivers implement it, although IIRC at least NVIDIA does. For all the details see section 3.6.2 of the GL 1.2.1 spec, but the bottom line is that it's not actually available unless you have GL_ARB_imaging in the extension string, despite being described in the GL 1.2.1 spec.

Oct. 31, 2013

Re: [PATCH 3/3] opengl32: Use opengl xml registry files.

by Rico Schüller

On 29.10.2013 13:10, Alexandre Julliard wrote: > Rico Schüller <kgbricola(a)web.de> writes: > >> --- >> dlls/opengl32/make_opengl | 316 >> +++++++++++++++++++--------------------------- >> dlls/winemac.drv/opengl.c | 8 +- >> dlls/winex11.drv/opengl.c | 8 +- >> 3 Dateien geändert, 136 Zeilen hinzugefügt(+), 196 Zeilen entfernt(-) > > It's not generating quite the same thing as the previous version, and > some of the differences look wrong, for instance: > > -static void WINAPI glBindAttribLocation( GLuint program, GLuint index, const GLchar* name ) { > +static void WINAPI glBindAttribLocation( GLhandleARB programObj, GLuint index, const GLcharARB* name ) { > Yes, they look wrong. Apparently the alias did this. It's fine, when the alias is ignored. I missed this, sorry. This could be fixed. I found some other issues and now I think the xml seems not use able for us in the state it is now. Sorry for the noise. E.g. glColorSubTable is listed in the extension GL_ARB_imaging, but not as GL 1.2 requirement. All linux drivers support at least 1.2 (and thus don't expose GL_ARB_imaging), so there is no way to tell if we should support that function or not. We would need a separate list for that ... Imho this works for glBlendColor which is in GL_ARB_imaging and GL_VERSION_1_4, but this seems also wrong as it should be in GL 1.2. Did I miss anything? Maybe we should provide a list which extension is part of which opengl version? Cheers Rico

Oct. 31, 2013

Re: [PATCH 3/5] ddraw/tests: Use explicit A calls.

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://newtestbot.winehq.org/JobDetails.pl?Key=3136 Your paranoid android. === w8 (32 bit ddraw7) === ddraw7.c:3055: Test failed: SetDisplayMode failed, hr 0x80004001. === wvista (32 bit d3d) === d3d.c:1261: Test failed: Homogeneous output was generated despite UNCLIPPED flag === w2008s64 (32 bit d3d) === d3d.c:1261: Test failed: Homogeneous output was generated despite UNCLIPPED flag === w7pro64 (32 bit d3d) === d3d.c:1261: Test failed: Homogeneous output was generated despite UNCLIPPED flag === w8 (32 bit d3d) === d3d.c:1261: Test failed: Homogeneous output was generated despite UNCLIPPED flag === w864 (32 bit d3d) === d3d.c:1261: Test failed: Homogeneous output was generated despite UNCLIPPED flag === w864 (32 bit visual) === visual.c:2616: Test failed: unexpected colortable on offscreen surface

Oct. 31, 2013

Re: [PATCH 1/5] d3d9/tests: Use color_match() in more places.

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://newtestbot.winehq.org/JobDetails.pl?Key=3134 Your paranoid android. === w8 (32 bit visual) === visual.c:6533: Test failed: Test blendindices returned color 0x00333333, expected 0x00000000. === w864 (32 bit visual) === visual.c:6533: Test failed: Test blendindices returned color 0x00333333, expected 0x00000000. === w864 (64 bit visual) === visual.c:6533: Test failed: Test blendindices returned color 0x00333333, expected 0x00000000.

Oct. 31, 2013

Re: server: Make it possible for WaitCommEvent to detect recursive requests.

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://newtestbot.winehq.org/JobDetails.pl?Key=3133 Your paranoid android. === w7pro64 (32 bit comm) === comm.c:859: Test failed: WaitCommEvent failed with a timeout comm.c:870: recovering after WAIT_TIMEOUT... comm.c:880: Test failed: WaitCommEvent error 0 comm.c:881: Test failed: WaitCommEvent: expected EV_TXEMPTY, got 0 comm.c:885: WaitCommEvent for EV_TXEMPTY took 1513 ms (timeout 1500) comm.c:886: Test failed: WaitCommEvent used 1513 ms for waiting comm.c:1550: test_AbortWaitCts timeout 500 handle 000000F8 comm.c:1517: Changing CommMask on the fly for handle 000000F8 after timeout 500

Oct. 31, 2013

Re: shell32: Check number of bytes returned by ReadFile.

by Alexandre Julliard

Dmitry Timoshkov <dmitry(a)baikal.ru> writes: > What is the reason for setting state of this patch as 'pending'? Think a bit more about how to properly handle errors in that code. -- Alexandre Julliard julliard(a)winehq.org

Oct. 31, 2013

Re: shell32: Check number of bytes returned by ReadFile.

by Dmitry Timoshkov

What is the reason for setting state of this patch as 'pending'? -- Dmitry.

Oct. 31, 2013

Re: [PATCH 2/3] winmm/tests: Use the explicit mciSendCommandA() version.

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://newtestbot.winehq.org/JobDetails.pl?Key=3126 Your paranoid android. === w7pro64 (32 bit mci) === mci.c:988: Test failed: 394ms is not in the expected 400-600ms range mci.c:995: Test failed: 394ms is not even in the expected 400-1000ms range

Oct. 31, 2013

Re: [PATCH 1/3] winmm/tests: Avoid duplicating the tested call in the ok() message.

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://newtestbot.winehq.org/JobDetails.pl?Key=3125 Your paranoid android. === wvista (32 bit mci) === mci.c:987: Test failed: 398ms is not in the expected 400-600ms range mci.c:994: Test failed: 398ms is not even in the expected 400-1000ms range === w864 (32 bit mci) === mci.c:987: Test failed: 398ms is not in the expected 400-600ms range mci.c:994: Test failed: 398ms is not even in the expected 400-1000ms range === w7pro64 (64 bit mci) === mci.c:856: Test failed: mci status mode: playing after play from 0 to 0

Oct. 31, 2013

Re: shlwapi: Test and fix the behaviour of the CopyTo method for file sizes not multiple of the internal buffer size, on SHC

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://newtestbot.winehq.org/JobDetails.pl?Key=3116 Your paranoid android. === wvista (32 bit istream) === istream.c:669: Test failed: SHCreateStreamOnFileEx failed with ret=0x8007007b === w2008s64 (64 bit istream) === istream.c:669: Test failed: SHCreateStreamOnFileEx failed with ret=0x8007007b

Oct. 30, 2013

Re: shlwapi: Test and fix the behaviour of the CopyTo method for file sizes not multiple of the internal buffer size, on SHCreateStreamOnFileEx-returned IStreams. (try 4)

by Alexandre Julliard

"David Quintana (gigaherz)" <gigaherz(a)gmail.com> writes: > +{ > + HRESULT ret; > + IStream* src; > + IStream* dst; > + ULARGE_INTEGER count, read, written; > + > + CHAR srcPathA[MAX_PATH]; > + CHAR dstPathA[MAX_PATH]; > + > + WCHAR srcPath[MAX_PATH]; > + WCHAR dstPath[MAX_PATH]; > + > + const CHAR *srcFileName = "SHCreateStreamOnFileEx-src.dat"; > + const CHAR *dstFileName = "SHCreateStreamOnFileEx-dst.dat"; > + > + GetTempPathA(MAX_PATH, srcPathA); > + lstrcatA(srcPathA, srcFileName); > + MultiByteToWideChar(CP_ACP, 0, srcPathA, -1, srcPath, MAX_PATH); > + > + GetTempPathA(MAX_PATH, dstPathA); > + lstrcatA(dstPathA, dstFileName); > + MultiByteToWideChar(CP_ACP, 0, dstPathA, -1, dstPath, MAX_PATH); There's no reason to use such specific file names, just use GetTempFileName or something like that. -- Alexandre Julliard julliard(a)winehq.org

Oct. 30, 2013

Re: winex11.drv: Add TIMESTAMP to X clipboard TARGETS

by Andrey Vostrikov

Alexandre Julliard wrote: > Andrey Vostrikov <av.linux.dev(a)gmail.com> writes: > >> Alexandre Julliard wrote: >>> Andrey Vostrikov <andrey.vostrikov(a)cogentembedded.com> writes: >>> >>>> + else if(event->target == x11drv_atom(TIMESTAMP)) /* Return event timestamp */ >>>> + { >>>> + /* TIMESTAMP selection request */ >>>> + XChangeProperty(display, request, rprop, event->target, >>>> + 32, PropModeReplace, (unsigned char*)&event->time, 1); >>> That's not the correct timestamp. >>> >> What would be the correct one then? > > The time when we acquired the selection. > Hi Alexandre, This is updated patch. It obtains X server timestamp similar as in GTK+ library, by pinging X window when selection is acquired. Best regards, Andrey

Oct. 30, 2013

Re: [PATCH 3/5] d3d9/tests: Use explicit A calls.

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://newtestbot.winehq.org/JobDetails.pl?Key=3115 Your paranoid android. === w864 (32 bit device) === device: unhandled exception c0000005 at 74C714C8 === w864 (64 bit device) === device: unhandled exception c0000005 at 000007F9366B90EB

Oct. 30, 2013

Re: winex11.drv: Add TIMESTAMP to X clipboard TARGETS

by Alexandre Julliard

Andrey Vostrikov <av.linux.dev(a)gmail.com> writes: > Alexandre Julliard wrote: >> Andrey Vostrikov <andrey.vostrikov(a)cogentembedded.com> writes: >> >>> + else if(event->target == x11drv_atom(TIMESTAMP)) /* Return event timestamp */ >>> + { >>> + /* TIMESTAMP selection request */ >>> + XChangeProperty(display, request, rprop, event->target, >>> + 32, PropModeReplace, (unsigned char*)&event->time, 1); >> That's not the correct timestamp. >> > What would be the correct one then? The time when we acquired the selection. -- Alexandre Julliard julliard(a)winehq.org

Oct. 30, 2013

Re: winex11.drv: Add TIMESTAMP to X clipboard TARGETS

by Andrey Vostrikov

Alexandre Julliard wrote: > Andrey Vostrikov <andrey.vostrikov(a)cogentembedded.com> writes: > >> + else if(event->target == x11drv_atom(TIMESTAMP)) /* Return event timestamp */ >> + { >> + /* TIMESTAMP selection request */ >> + XChangeProperty(display, request, rprop, event->target, >> + 32, PropModeReplace, (unsigned char*)&event->time, 1); > That's not the correct timestamp. > What would be the correct one then? CurrentTime is zero and does not help. event->time is very close to what is needed and fixes an issue.

Oct. 30, 2013

Re: [PATCH 2/5] d3d9/tests: Avoid windowsx.h.

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://newtestbot.winehq.org/JobDetails.pl?Key=3114 Your paranoid android. === w864 (32 bit device) === device: unhandled exception c0000005 at 74C714C8 === w864 (64 bit device) === device: unhandled exception c0000005 at 000007F9366B90EB

Oct. 30, 2013

Re: winex11.drv: Add TIMESTAMP to X clipboard TARGETS

by Alexandre Julliard

Andrey Vostrikov <andrey.vostrikov(a)cogentembedded.com> writes: > + else if(event->target == x11drv_atom(TIMESTAMP)) /* Return event timestamp */ > + { > + /* TIMESTAMP selection request */ > + XChangeProperty(display, request, rprop, event->target, > + 32, PropModeReplace, (unsigned char*)&event->time, 1); That's not the correct timestamp. -- Alexandre Julliard julliard(a)winehq.org

Oct. 30, 2013

Re: crypt32: Check number of bytes returned by ReadFile and avoid a memory leak on error path.

by Dmitry Timoshkov

This patch is marked as superseded in the tracker but it is not. -- Dmitry.

Oct. 30, 2013

Re: [PATCH] quartz/tests: Enable compilation with -D__WINESRC__

by Nikolay Sivov

Hi. No, it's not new. This runs has it already http://test.winehq.org/data/ddd6fd1ecbc4c25cf6c69202934c8bf2a3f01daf/index_… On Tue, Oct 29, 2013 at 6:38 PM, Marvin <testbot(a)winehq.org> wrote: > Hi, > > While running your changed tests on Windows, I think I found new failures. > Being a bot and all I'm not very good at pattern recognition, so I might be > wrong, but could you please double-check? > Full results can be found at > https://newtestbot.winehq.org/JobDetails.pl?Key=3099 > > Your paranoid android. > > > === w864 (32 bit filtergraph) === > filtergraph: unhandled exception c0000005 at 00404347 > > === w864 (64 bit filtergraph) === > filtergraph: unhandled exception c0000005 at 0000000000403DF2 > > >

Oct. 29, 2013

Re: [PATCH] quartz/tests: Enable compilation with -D__WINESRC__

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://newtestbot.winehq.org/JobDetails.pl?Key=3099 Your paranoid android. === w864 (32 bit filtergraph) === filtergraph: unhandled exception c0000005 at 00404347 === w864 (64 bit filtergraph) === filtergraph: unhandled exception c0000005 at 0000000000403DF2

Oct. 29, 2013

Re: [PATCH 3/3] opengl32: Use opengl xml registry files.

by Alexandre Julliard

Rico Schüller <kgbricola(a)web.de> writes: > --- > dlls/opengl32/make_opengl | 316 > +++++++++++++++++++--------------------------- > dlls/winemac.drv/opengl.c | 8 +- > dlls/winex11.drv/opengl.c | 8 +- > 3 Dateien geändert, 136 Zeilen hinzugefügt(+), 196 Zeilen entfernt(-) It's not generating quite the same thing as the previous version, and some of the differences look wrong, for instance: -static void WINAPI glBindAttribLocation( GLuint program, GLuint index, const GLchar* name ) { +static void WINAPI glBindAttribLocation( GLhandleARB programObj, GLuint index, const GLcharARB* name ) { -- Alexandre Julliard julliard(a)winehq.org

Oct. 29, 2013

Re: [PATCH 3/5] d3d8/tests: Use explicit A calls.

by Marvin

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

Oct. 29, 2013

Re: [PATCH 2/5] d3d8/tests: Avoid windowsx.h.

by Marvin

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

Oct. 29, 2013

Re: [PATCH 2/5] ddraw/tests: Allow some flags to fail surface creation in test_rt_caps (try 2).

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://newtestbot.winehq.org/JobDetails.pl?Key=3085 Your paranoid android. === w864 (32 bit ddraw2) === ddraw2.c:3915: Test failed: Test 16: Got unexpected caps 0x22800, expected 0x10026000. ddraw2.c:3915: Test failed: Test 17: Got unexpected caps 0x20800, expected 0x10024000. === w864 (32 bit ddraw1) === ddraw1.c:3289: Test failed: Test 16: Got unexpected caps 0x22800, expected 0x10026000. ddraw1.c:3289: Test failed: Test 17: Got unexpected caps 0x20800, expected 0x10024000.

Oct. 29, 2013

Re: Wine Mono 4.5.0 Release

by Austin English

On Tue, Oct 22, 2013 at 2:22 PM, Vincent Povirk <madewokherd(a)gmail.com> wrote: > I have published version 4.5.0 of Wine Mono on sourceforge. It's been > a little over a year since the last release, and I'm sorry I waited so > long to do it. > > I have also changed the versioning scheme. The major and minor version > numbers will now indicate the highest supported .NET runtime version. > > The source tarball is at > https://sourceforge.net/projects/wine/files/Wine%20Mono/4.5.0/wine-mono-4.5… > > The binary is at > https://sourceforge.net/projects/wine/files/Wine%20Mono/4.5.0/wine-mono-4.5… > > For developers, the source repository is at > https://github.com/madewokherd/wine-mono > > Changes since 0.0.8: > * Fixed build on machines using bash as their sh implementation. > * .NET Framework directories now include mscorlib.dll (fixes wine bug #31888). > * Fixed build on machines running Mac OS X. (Josh DuBois) > * Added a security.config file to the .NET 2.0 directory. (Alistair > Leslie-Hughes) > * Microsoft's Managed C++ compiler sometimes generates broken IL code > ending in an unreachable ret statement. This code would be accepted by > the .NET runtime but rejected by Mono. Mono is correctly following the > spec in this case, but since our goal is compatibility we now accept > code that does this. > * Building with the -t switch will now build runtime tests. > Previously, it only built class library tests. > * Added registry keys to indicate the presence of .NET 4.5. > * Added user-agent strings to the registry, which allow javascript > embedded in web pages to detect .NET. > * Updated Mono from 2.11.4 to 3.2.3 plus some additional commits. I'm > no longer using Mono's release tags, because they don't seem to help > me find revisions that are stable or even buildable. Anyway, here are > some highlights of the changes brought in from Mono: > * The new 'sgen' garbage collector has been greatly improved and is > now the default instead of the old 'boehm' gc, which in our case means > it's the only one shipped. It is an improvement over boehm in many > ways and should be generally more efficient. > * Mono now has support for Portable Class Libraries. > * Beginnings of support for System.Windows.Forms.AxHost. (Alistair > Leslie-Hughes) > * Added support for P/Invoke methods with the thiscall calling > convention, which are used by Managed C++ assemblies. > * Improved IDispatch interface on managed objects. (Alistair Leslie-Hughes) Using wine-1.7.5, wine-mono-4.5.0, and the attached patch, I went through a few of the bugs I've filed against mscoree: http://bugs.winehq.org/show_bug.cgi?id=26020 - no change http://bugs.winehq.org/show_bug.cgi?id=27505 - no change http://bugs.winehq.org/show_bug.cgi?id=31888 - works with wine-mono-4.5.0, but not 0.0.8 http://bugs.winehq.org/show_bug.cgi?id=32738 - no change http://bugs.winehq.org/show_bug.cgi?id=34237 - still fails, output is slightly different http://bugs.winehq.org/show_bug.cgi?id=34384 - works with wine-mono-4.5.0, but not 0.0.8 http://bugs.winehq.org/show_bug.cgi?id=34538 - no change I didn't test the others. -- -Austin

Oct. 29, 2013

Re: [PATCH 1/5] ddraw/tests: Accept nvidia return values in test_rt_caps (try 2).

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://newtestbot.winehq.org/JobDetails.pl?Key=3084 Your paranoid android. === w864 (32 bit ddraw2) === ddraw2: unhandled exception c0000005 at 00420E6B

Oct. 29, 2013

Re: [Patch]try 2: Bug 33164 - row-resize / col-resize cursor is wrong (Listview)‏

by Vincent Povirk

Your patch is being mangled somehow, even in the attachment. The blank line should contain a space. Also, please use your name transliterated to Latin characters when sending patches.

Oct. 28, 2013

Re: shlwapi: Test and fix the behaviour of the CopyTo method for file sizes not multiple of the internal buffer size, on SHCreateStreamOnFileEx-returned IStreams.

by Alexandre Julliard

"David Quintana (gigaherz)" <gigaherz(a)gmail.com> writes: > Hello people, > I fixed Vincent's comment, and submitted the new version of the patch. > It has been quite a few days already so I'd like to know if there is > anything else left to do before the patch is looked at, or if there's > just too much going on at the moment, in which case I can re-submit > the patch in a few days/weeks, so that it can be looked at properly > when there's more time. The test code is quite ugly, it needs more work. -- Alexandre Julliard julliard(a)winehq.org

Oct. 28, 2013

Re: shlwapi: Test and fix the behaviour of the CopyTo method for file sizes not multiple of the internal buffer size, on SHCreateStreamOnFileEx-returned IStreams.

by David Quintana (gigaherz)

Hello people, I fixed Vincent's comment, and submitted the new version of the patch. It has been quite a few days already so I'd like to know if there is anything else left to do before the patch is looked at, or if there's just too much going on at the moment, in which case I can re-submit the patch in a few days/weeks, so that it can be looked at properly when there's more time. Vincent Povirk wrote: > We should probably still exit the loop if fewer bytes were read than > requested, rather than do another read at the end of the file.

Oct. 28, 2013

Re: [3/8] crypt32: Remove unused variable and avoid a memory leak on error path.

by Alexandre Julliard

Dmitry Timoshkov <dmitry(a)baikal.ru> writes: > --- > dlls/crypt32/filestore.c | 5 ++--- > 1 file changed, 2 insertions(+), 3 deletions(-) > > diff --git a/dlls/crypt32/filestore.c b/dlls/crypt32/filestore.c > index 44b9bbb..6084395 100644 > --- a/dlls/crypt32/filestore.c > +++ b/dlls/crypt32/filestore.c > @@ -117,9 +117,8 @@ static BOOL CRYPT_ReadBlobFromFile(HANDLE file, PCERT_BLOB blob) > blob->pbData = CryptMemAlloc(blob->cbData); > if (blob->pbData) > { > - DWORD read; > - > - ret = ReadFile(file, blob->pbData, blob->cbData, &read, NULL); > + ret = ReadFile(file, blob->pbData, blob->cbData, NULL, NULL); > + if (!ret) CryptMemFree(blob->pbData); In general if the read size is not checked that's a bug. -- Alexandre Julliard julliard(a)winehq.org

Oct. 28, 2013

[3/8] crypt32: Remove unused variable and avoid a memory leak on error path.

by Thomas Faber

Hi, On 2013-10-28 09:28, Dmitry Timoshkov wrote: > - ret = ReadFile(file, blob->pbData, blob->cbData, &read, NULL); > + ret = ReadFile(file, blob->pbData, blob->cbData, NULL, NULL); the lpNumberOfBytesRead parameter is not optional on Windows for synchronous I/O, so could you keep it please? I've had to add it back in elsewhere to prevent Wine functions from crashing on Win. Thanks! Best, Thomas

Oct. 28, 2013

Re: [01/02] d3d9: update locked_rect only if wined3d_surface_map succeeds

by Lasse Rasinen

Henri Verbeet <hverbeet(a)gmail.com> writes: >> I've had a look at the logs and as far as I can tell, the failing test >> is not exercising the change I made. If anyone can shed some light on >> this, I'd be happy to resubmit the patch with the improved test failure >> reporting. >> > I think that's from test_rtpatch() that Stefan removed in > 9c19266a247a2f4e1f88a3258026af33c6cd6efc. I think all this patch needs > is to fix the warnings, and the improved failure messages. Looks like it wasn't that: https://newtestbot.winehq.org/JobDetails.pl?Key=3077&log_204=1#k204 Based on this "device.c:6759: this is the last test seen before the exception" it'd be somewhere within test_update_volumetexture or something after that. -- Lasse Rasinen lrasinen(a)iki.fi

Oct. 28, 2013

Re: d3d9: update locked_rect only if wined3d_surface_map succeeds (try 2)

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://newtestbot.winehq.org/JobDetails.pl?Key=3077 Your paranoid android. === w864 (32 bit device) === device: unhandled exception c0000005 at 74C714C8 === w864 (64 bit device) === device: unhandled exception c0000005 at 000007F9366B90EB

Oct. 28, 2013

Re: msvcrt: add support for _chsize_s (try #3)

by Piotr Caban

Hi, On 10/26/13 04:58, Mike Koss wrote: > This patch adds the _chsize_s() to the mscvrt and corresponding mscvr*s. > Incorporates previous feedback and now includes an updated test file. > > --- > dlls/msvcr100/msvcr100.spec | 2 +- > dlls/msvcr110/msvcr110.spec | 2 +- > dlls/msvcr80/msvcr80.spec | 2 +- > dlls/msvcr90/msvcr90.spec | 2 +- > dlls/msvcrt/file.c | 63 > +++++++++++++++++++++++++++++++++++++++++++++ > dlls/msvcrt/msvcrt.spec | 2 +- > dlls/msvcrt/tests/file.c | 37 ++++++++++++++++++++++++++ > 7 files changed, 105 insertions(+), 5 deletions(-) There're few more issues with this patch: - _chsize_s is not defined in headers (please make sure that your code compiles without warnings) - _chsize_s is not available in some versions of msvcrt.dll, you should load it using GetProcAddress like in other *_s functions tests - the tests are failing on windows, it's probably also caused by lack of _chsize_s header Thanks, Piotr

Oct. 28, 2013

Re: [01/02] d3d9: update locked_rect only if wined3d_surface_map succeeds

by Henri Verbeet

On 27 October 2013 14:22, Lasse Rasinen <lrasinen(a)iki.fi> wrote: > Marvin <testbot(a)winehq.org> writes: > >> Full results can be found at >> https://newtestbot.winehq.org/JobDetails.pl?Key=2909 >> [...] >> === w864 (32 bit device) === >> device: unhandled exception c0000005 at 740D14C8 >> >> === w864 (64 bit device) === >> device: unhandled exception c0000005 at 000007F84EDD90EB > > I've had a look at the logs and as far as I can tell, the failing test > is not exercising the change I made. If anyone can shed some light on > this, I'd be happy to resubmit the patch with the improved test failure > reporting. > I think that's from test_rtpatch() that Stefan removed in 9c19266a247a2f4e1f88a3258026af33c6cd6efc. I think all this patch needs is to fix the warnings, and the improved failure messages.

Oct. 28, 2013

Re: [PATCH] wined3d: Use GL_ARB_texture_mirror_clamp_to_edge when available.

by Henri Verbeet

On 26 October 2013 22:23, Rico Schüller <kgbricola(a)web.de> wrote: > Well, I did a small update for the script (it may need some > improvements...). Please see the attached patch for make_opengl. I have > several questions to this: I didn't review the code very closely, but at first sight it looks like you have a couple of unrelated and whitespace only changes that should probably be in separate patches. I think there are also e.g. some comments that should be updated / removed. I can try to answer some of the questions, but ultimately it's up to Alexandre. > 1. Is it the correct way to just change the script or do we prefer > another way? Seems fine to me. Although it's a bit annoying that Khronos doesn't seem to want to make any guarantees about the stability of the XML format. > 2. Is it fine to use XML::Simple as a dependency? I think so, but I also think it's common to just put things like "use XML::Simple;" at the top of the file. > 3. Do we need to support gles functions and enums? Not initially, but we may want to in the future. > 4. Why was $pseudo_to_opengl used in the script? For mapping type. E.g. in gl.spec, ClearColor() takes 4 parameters of "ColorF", which is mapped to GLfloat in gl.tm. In the XML files that information is available as the "group" attribute, but we don't need it for our purposes. (See also https://cvs.khronos.org/svn/repos/ogl/trunk/doc/registry/public/api/readme.…)

Oct. 28, 2013

Re: [PATCH 1/4] comctl32: Set updown control value to min or max in out of range case

by Piotr Caban

On 10/28/13 09:35, Alistair Leslie-Hughes wrote: > On 17/10/2013 1:34 AM, Piotr Caban wrote: >> --- >> dlls/comctl32/updown.c | 9 +++++++-- >> 1 file changed, 7 insertions(+), 2 deletions(-) >> >> - } else return FALSE; >> + } if ((infoPtr->MaxVal > infoPtr->MinVal && >> infoPtr->CurVal+delta > infoPtr->MaxVal) > ^^^ >> + || (infoPtr->MaxVal < infoPtr->MinVal && >> infoPtr->CurVal+delta < infoPtr->MaxVal)) { >> + delta = infoPtr->MaxVal - infoPtr->CurVal; > > Should the "if" be one its own line or was the else missed? The 'else' was missed. I've sent a fix for it. Thanks, Piotr

Oct. 28, 2013

Re: kernel32/tests: Update trace message to report actually used timeout value.

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://newtestbot.winehq.org/JobDetails.pl?Key=3074 Your paranoid android. === w2008s64 (32 bit comm) === comm.c:859: Test failed: WaitCommEvent failed with a timeout comm.c:870: recovering after WAIT_TIMEOUT... comm.c:880: Test failed: WaitCommEvent error 0 comm.c:881: Test failed: WaitCommEvent: expected EV_TXEMPTY, got 0 comm.c:885: WaitCommEvent for EV_TXEMPTY took 1513 ms (timeout 1500) comm.c:886: Test failed: WaitCommEvent used 1513 ms for waiting comm.c:1551: test_AbortWaitCts timeout 500 handle 000000C4 comm.c:1518: Changing CommMask on the fly for handle 000000C4 after timeout 500

Oct. 28, 2013

Re: WineTestBot status update

by Francois Gouget

On Mon, 28 Oct 2013, Dmitry Timoshkov wrote: [...] > When next time I'll be playing with the tests what additional info could > I provide for better diagnosing the problem? I think the simplest would be to save the TestBot's home page and your Job's page as HTML files and send those. -- Francois Gouget <fgouget(a)codeweavers.com>

Oct. 28, 2013

Re: WineTestBot status update

by Francois Gouget

On Sun, 27 Oct 2013, Jeremy White wrote: > And I meant to ask, but did not: does it make sense to throw > hardware at some of the issues? We've got additional systems > we could easily rig as slaves... The current VM host is far from fully utilized. The CPU is over 90% idle. The only point that worries me is the I/O but I hope disabling Windows Defender will have greatly reduced it. To get good performance we need to: * Solve the VM revert issue. * Tweak the self-imposed limits on active VMs and reverts. Currently we only allow up to 2 active VMs and 1 revert, that's 2 running VMs or 1 running VM and one revert. Given that the bos has 8 cores and each VM normally uses at most 2, I think we can go up to 4 running VMs. We can probably also allow up to 2 reverts, though that's likely more disk-limited. I think we can also reduce the post-revert sleep phase (from 30 seconds down to 10 or less). * Defuse 'test-bombs', though these are mostly a corner case really (once the __WINESRC__ work is done it will be some time before we get such patches again). But there's other reasons to do that work anyway (bug 33065). -- Francois Gouget <fgouget(a)codeweavers.com>

Oct. 28, 2013

Re: WineTestBot status update

by Dmitry Timoshkov

Francois Gouget <fgouget(a)codeweavers.com> wrote: > On Mon, 28 Oct 2013, Dmitry Timoshkov wrote: > [...] > > Yes, there are still ways for the new testbot improvements. When time from > > time I send patches for testing I send them to both old and new testbots. > > While old tesbot completes the job in minutes (usually 3-5), the new one > > almost always completes the request several hours later. > > I think that's because of two factors: > * The current __WINESRC__ jobs which I like to call testbot-bombs. > That's because these patches tend to touch multiple tests which > creates one task per test per base VM, so 8 tasks per test, plus the > build one. So for instance a patch fixing the 11 advapi32 tests would > create 89 tasks (1 build + 11 tests * 8 VMs), so 89 reverts. There's > been many such patches lately and that delays the tests coming after > them. When I sent a patch to testbot last time there were no __WINESRC__ related patches in the queue... > * The old TestBot is not processing wine-patches emails anymore. That > means it's essentially has nothing to do but work on your jobs. ... and nightly test run has been finished as well. Also there were no other things related to wine-patches processing running either. > > Looking at the job status it shows that the build is complete and VMs > > are online and ready but nothing happens further on. > > That's strange. It can happen if it's waiting on a VM that's offline or > undergoing maintenance. There can also be cases where the build VM gets > a bit ahead (but normally the TestBot tries to complete the jobs one at > a time). When next time I'll be playing with the tests what additional info could I provide for better diagnosing the problem? -- Dmitry.

Oct. 28, 2013

Re: WineTestBot status update

by Francois Gouget

On Mon, 28 Oct 2013, Dmitry Timoshkov wrote: [...] > Yes, there are still ways for the new testbot improvements. When time from > time I send patches for testing I send them to both old and new testbots. > While old tesbot completes the job in minutes (usually 3-5), the new one > almost always completes the request several hours later. I think that's because of two factors: * The current __WINESRC__ jobs which I like to call testbot-bombs. That's because these patches tend to touch multiple tests which creates one task per test per base VM, so 8 tasks per test, plus the build one. So for instance a patch fixing the 11 advapi32 tests would create 89 tasks (1 build + 11 tests * 8 VMs), so 89 reverts. There's been many such patches lately and that delays the tests coming after them. * The old TestBot is not processing wine-patches emails anymore. That means it's essentially has nothing to do but work on your jobs. Defusing the TestBot bombs will be one of my next TestBot tasks after these two VMs are back online. The way it will work is to build custom WineTest binaries with just the tests we need to run, and to run that binary on each VM. So in the above case we'll only have 1 + 8 tasks. > Looking at the job status it shows that the build is complete and VMs > are online and ready but nothing happens further on. That's strange. It can happen if it's waiting on a VM that's offline or undergoing maintenance. There can also be cases where the build VM gets a bit ahead (but normally the TestBot tries to complete the jobs one at a time). -- Francois Gouget <fgouget(a)codeweavers.com>

Oct. 28, 2013

Re: WineTestBot status update

by Dmitry Timoshkov

Francois Gouget <fgouget(a)codeweavers.com> wrote: > I also uncovered two other potential performance issues: > * Some VMs have Windows Defender and apparently it was starting a full > disk scan as soon as the VM was ready to run the tests. That's > clearly not good so I disabled Windows Defender in all VMs. > > * Most VMs were still using 20% of the CPU when idle. That's fine if > only one VM is running but could impact performance (through > increased interrupt rates) if many are running at once (like on the > WineTestBot). Apparently the culprit is the USB Tablet device that's > added by default. So I removed it from all VMs too (and now the mouse > is even more laggy than before when I work on the VMs :-( But that > does not impact the tests). > > So there is still a lot of work to do on the WineTestBot, and that's > not even counting fixing all the failing tests. Yes, there are still ways for the new testbot improvements. When time from time I send patches for testing I send them to both old and new testbots. While old tesbot completes the job in minutes (usually 3-5), the new one almost always completes the request several hours later. Looking at the job status it shows that the build is complete and VMs are online and ready but nothing happens further on. -- Dmitry.

Oct. 28, 2013

Re: WineTestBot status update

by Jeremy White

And I meant to ask, but did not: does it make sense to throw hardware at some of the issues? We've got additional systems we could easily rig as slaves... Cheers, Jeremy

Oct. 28, 2013

Re: WineTestBot status update

by Jeremy White

This is great, thanks! > msi:action and msi:install went from an average of 99 and 90 seconds > down to 48 and 39 seconds and they are not timing out anymore. The > remaining troublesome tests are now ddraw:ddraw{2,4,7}, shell32:shlexec, > and winspool.drv:info. > Just summarizing: we have a hoped for fix for the XP revert time issue; if that holds, then we have those troublesome tests, and fixing failures to go. Is that about the size of it? Cheers, Jeremy

Oct. 28, 2013

Re: [01/02] d3d9: update locked_rect only if wined3d_surface_map succeeds

by Lasse Rasinen

Marvin <testbot(a)winehq.org> writes: > Full results can be found at > https://newtestbot.winehq.org/JobDetails.pl?Key=2909 > [...] > === w864 (32 bit device) === > device: unhandled exception c0000005 at 740D14C8 > > === w864 (64 bit device) === > device: unhandled exception c0000005 at 000007F84EDD90EB I've had a look at the logs and as far as I can tell, the failing test is not exercising the change I made. If anyone can shed some light on this, I'd be happy to resubmit the patch with the improved test failure reporting. (Although my personal drive for this patch has gone down as the new OS X has a new compiler that doesn't break it on unpatched master) -- Lasse Rasinen lrasinen(a)iki.fi

Oct. 27, 2013

WineTestBot status update

by Francois Gouget

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

Oct. 27, 2013

Re: winspool.drv/tests: Fix the OpenPrinter() tests error reporting.

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://newtestbot.winehq.org/JobDetails.pl?Key=3070 Your paranoid android. === w864 (32 bit info) === info.c:2923: Test failed: AddJobA() failed le=50 info.c:2929: Test failed: GetJobA() failed le=87 info: unhandled exception c0000005 at 0040B24A === w864 (64 bit info) === info.c:2923: Test failed: AddJobA() failed le=50 info.c:2929: Test failed: GetJobA() failed le=87 info.c:2972: Test failed: AddJobA() failed le=50 info.c:2978: Test failed: GetJobA() failed le=87 info: unhandled exception c0000005 at 00000000004099E0

Oct. 27, 2013

Re: Raise the minimum version of FreeBSD to 8.0.

by Gerald Pfeifer

On Mon, 4 Mar 2013, Frédéric Delanoy wrote: >> We've had this as a requirement in the FreeBSD ports for quite a >> while (and the Wiki describes some background). > You should also change the version in the various README.xx > translations (in 'documentation' directory). Done thusly. New patch below. (Had some fun with Japanese on my lowly remote test machine and hope that for more substanial changes I don't have to provide translations for all? ;-) Gerald diff --git a/README b/README index 8dbc614..1627081 100644 --- a/README +++ b/README @@ -29,7 +29,7 @@ especially the wealth of information found at http://www.winehq.org. To compile and run Wine, you must have one of the following: Linux version 2.0.36 or later - FreeBSD 7.0 or later + FreeBSD 8.0 or later Solaris x86 9 or later NetBSD-current Mac OS X 10.5 or later @@ -39,7 +39,7 @@ systems mentioned above are supported. Other operating systems which support kernel threads may be supported in the future. FreeBSD info: - Wine will generally not work properly on versions before FreeBSD 7.0. + Wine will generally not work properly on versions before FreeBSD 8.0. See http://wiki.freebsd.org/Wine for more information. Solaris info: diff --git a/documentation/README.de b/documentation/README.de index f42b30d..ff1ee9c 100644 --- a/documentation/README.de +++ b/documentation/README.de @@ -32,7 +32,7 @@ Um Wine kompilieren und ausführen zu können, brauchen Sie eines der folgenden Betriebssysteme: Linux version 2.0.36 oder neuer - FreeBSD 7.0 oder neuer + FreeBSD 8.0 oder neuer Solaris x86 9 oder neuer NetBSD-current Mac OS X 10.5 oder neuer @@ -43,7 +43,7 @@ Andere Betriebssysteme, die Kernel-Threads unterstützen, werden unter Umständen in der Zukunft unterstützt. FreeBSD-Info: - Wine läuft prinzipiell erst ab FreeBSD 7.0 richtig. Siehe dazu auch + Wine läuft prinzipiell erst ab FreeBSD 8.0 richtig. Siehe dazu auch http://wiki.freebsd.org/Wine für weitere Informationen. Solaris-Info: diff --git a/documentation/README.es b/documentation/README.es index 9497855..c0a318d 100644 --- a/documentation/README.es +++ b/documentation/README.es @@ -30,7 +30,7 @@ http://www.winehq.org. Para compilar y ejecutar Wine, deberá tener uno de los siguientes: Linux versión 2.0.36 o superior - FreeBSD 7.0 o superior + FreeBSD 8.0 o superior Solaris x86 9 o superior NetBSD-current Mac OS X 10.5 o superior @@ -42,7 +42,7 @@ podrían obtener soporte en el futuro. Información sobre FreeBSD: Por lo general Wine no funcionará correctamente en versiones anteriores a - FreeBSD 7.0. Visite http://wiki.freebsd.org/Wine para más información. + FreeBSD 8.0. Visite http://wiki.freebsd.org/Wine para más información. Información sobre Solaris: Lo más probable es que necesite compilar con el conjunto de herramientas GNU diff --git a/documentation/README.fi b/documentation/README.fi index 15b8302..5e03199 100644 --- a/documentation/README.fi +++ b/documentation/README.fi @@ -28,7 +28,7 @@ ennen kaikkea Internetissä osoitteessa http://www.winehq.org/. Winen kääntämiseen tarvitaan jokin seuraavista: Linuxin versio 2.0.36 tai uudempi - FreeBSD 7.0 tai uudempi + FreeBSD 8.0 tai uudempi Solaris x86 9 tai uudempi NetBSD-current Mac OS X 10.5 tai uudempi @@ -38,7 +38,7 @@ mainittuja käyttöjärjestelmiä tuetaan; tulevaisuudessa saatetaan lisätä tu muillekin käyttöjärjestelmille, joissa on tarvittava tuki säikeille. Tietoa FreeBSD:lle: - Pääsääntöisesti Wine ei toimi vanhemmilla versioilla kuin FreeBSD 7.0. + Pääsääntöisesti Wine ei toimi vanhemmilla versioilla kuin FreeBSD 8.0. Osoitteessa http://wiki.freebsd.org/Wine kerrotaan tästä lisää. Tietoa Solarikselle: diff --git a/documentation/README.fr b/documentation/README.fr index 0d0c2ef..3c8ac4e 100644 --- a/documentation/README.fr +++ b/documentation/README.fr @@ -30,7 +30,7 @@ Pour compiler et exécuter Wine, vous devez disposer d'un des systèmes d'exploitation suivants : Linux version 2.0.36 ou ultérieur - FreeBSD 7.0 ou ultérieur + FreeBSD 8.0 ou ultérieur Solaris x86 9 ou ultérieur NetBSD-current Mac OS X 10.5 ou ultérieur diff --git a/documentation/README.it b/documentation/README.it index ad6b692..46ccf7c 100644 --- a/documentation/README.it +++ b/documentation/README.it @@ -31,7 +31,7 @@ si trova all'indirizzo http://www.winehq.org. Per compilare ed eseguire Wine, è necessario avere uno dei seguenti sistemi: Linux versione 2.0.36 o successiva - FreeBSD 7.0 o successiva + FreeBSD 8.0 o successiva Solaris x86 9 o successiva NetBSD-current Mac OS X 10.5 o successiva @@ -42,7 +42,7 @@ che forniscono kernel threads potrebbero essere supportati in futuro. Informazioni per FreeBSD: In generale Wine non funzionerà correttamente con versioni precedenti - a FreeBSD 7.0. + a FreeBSD 8.0. Leggere http://wiki.freebsd.org/Wine per maggiori informazioni. Informazioni per Solaris: diff --git a/documentation/README.ja b/documentation/README.ja index bd9d48a..f44d371 100644 --- a/documentation/README.ja +++ b/documentation/README.ja @@ -30,7 +30,7 @@ READMEというファイル]を含む）Wineソースのトップレベルディ Wineをコンパイルし実行するには、以下のうち一つを持っていなければなりません: Linux バージョン2.0.36以上 - FreeBSD 7.0以降 + FreeBSD 8.0以降 Solaris x86 9以降 NetBSD-current Mac OS X 10.5以降 @@ -41,7 +41,7 @@ Wineをコンパイルし実行するには、以下のうち一つを持って将来サポートされるかもしれません。 FreeBSD情報: - Wineは一般的にFreeBSD 7.0より前のバージョン上で正しく動作しないでしょう。 + Wineは一般的にFreeBSD 8.0より前のバージョン上で正しく動作しないでしょう。詳細については http://wiki.freebsd.org/Wine を参照してください。 Solaris情報: diff --git a/documentation/README.pt_br b/documentation/README.pt_br index 296425b..3e5ec27 100644 --- a/documentation/README.pt_br +++ b/documentation/README.pt_br @@ -31,7 +31,7 @@ encontrada em http://www.winehq.org. Para compilar e executar o Wine, voc?deve ter o seguinte: Linux vers? 2.0.36 ou posterior - FreeBSD 7.0 ou posterior + FreeBSD 8.0 ou posterior Solaris x86 9 ou posterior NetBSD-atual Mac OS X 10.5 ou posterior diff --git a/documentation/README.ru b/documentation/README.ru index 70fc5db..c228fc6 100644 --- a/documentation/README.ru +++ b/documentation/README.ru @@ -29,7 +29,7 @@ Wine Installer для компоновки и установки Wine. В кат Компиляция и запуск Wine поддерживается в следующих операционных системах: Linux версии 2.0.36 или более новой - FreeBSD 7.0 или более новой + FreeBSD 8.0 или более новой Solaris x86 9 или более новой NetBSD-текущей версии Mac OS X 10.5 или более новой @@ -40,7 +40,7 @@ Wine Installer для компоновки и установки Wine. В кат возможно будут поддерживаться Wine в будущем. FreeBSD: - Wine не будет работать как следует на версиях ниже, чем FreeBSD 7.0. + Wine не будет работать как следует на версиях ниже, чем FreeBSD 8.0. Посетите <http://wiki.freebsd.org/Wine> для дополнительной информации. Solaris: diff --git a/documentation/README.sv b/documentation/README.sv index d5fe643..d51a54a 100644 --- a/documentation/README.sv +++ b/documentation/README.sv @@ -27,7 +27,7 @@ information och tips om hur problem kan l F? att kompilera och k?a Wine kr?s ett av f?jande: Linux version 2.0.36 eller senare - FreeBSD 7.0 eller senare + FreeBSD 8.0 eller senare Solaris x86 9 eller senare NetBSD-current Mac OS X 10.5 eller senare

Oct. 27, 2013

Re: ddraw/tests: Fix compilation on systems that don't support nameless unions.

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://newtestbot.winehq.org/JobDetails.pl?Key=3061 Your paranoid android. === w864 (32 bit ddraw2) === ddraw2: unhandled exception c0000005 at 00420E52 === w864 (32 bit ddraw1) === ddraw1: unhandled exception c0000005 at 0041212F

Oct. 26, 2013

Re: [PATCH] wined3d: Use GL_ARB_texture_mirror_clamp_to_edge when available.

by Rico Schüller

On 21.10.2013 21:51, Henri Verbeet wrote: > On 21 October 2013 21:20, Rico Schüller <kgbricola(a)web.de> wrote: >> As wgl.h is a bit out of date, it still uses the >> GL_MIRROR_CLAMP_TO_EDGE_ATI instead of GL_MIRROR_CLAMP_TO_EDGE (which is >> only available in headers for OpenGL 4.4). >> > The wine/wgl.h header is generated from the GL .spec files by > dlls/opengl32/make_opengl, so in principle all you'd have to do would > be to run that script to get the new constant. Unfortunately Khronos > seems to have decided to no longer update the .spec files, since there > are shiny new XML files now. > Well, I did a small update for the script (it may need some improvements...). Please see the attached patch for make_opengl. I have several questions to this: 1. Is it the correct way to just change the script or do we prefer another way? 2. Is it fine to use XML::Simple as a dependency? 3. Do we need to support gles functions and enums? 4. Why was $pseudo_to_opengl used in the script? Cheers Rico

Oct. 26, 2013

Re: shell32/tests: Fix compilation with -D__WINESRC__

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://newtestbot.winehq.org/JobDetails.pl?Key=3060 Your paranoid android. === w2008s64 (32 bit shlexec) === shlexec.c:1539: Test failed: argvA4 expected 'C:/Users/ADMINI~1/AppData/Local/Temp/wt453.tmp/test file.shlexec', got 'C:\Users\Administrator\AppData\Local\Temp\wt453.tmp\test file.shlexec' shlexec.c:2607: Test failed: longPath expected 'C:\Users\ADMINI~1\AppData\Local\Temp\wt453.tmp\test2.exe', got 'C:\Users\Administrator\AppData\Local\Temp\wt453.tmp\test2.exe' shlexec.c:2620: Test failed: longPath expected 'C:\Users\ADMINI~1\AppData\Local\Temp\wt453.tmp\test2.exe', got 'C:\Users\Administrator\AppData\Local\Temp\wt453.tmp\test2.exe' shlexec.c:2632: Test failed: longPath expected 'C:\Users\ADMINI~1\AppData\Local\Temp\wt453.tmp\test2.exe', got 'C:\Users\Administrator\AppData\Local\Temp\wt453.tmp\test2.exe' === w864 (32 bit shlexec) === shlexec.c:138: Test failed: ShellExecute(verb="", file="C:\Users\winetest\AppData\Local\Temp\wt47C8.tmp\test file.noassoc") WaitForSingleObject returned 258 shlexec.c:138: Test failed: ShellExecute(file="C:\Users\winetest\AppData\Local\Temp\wt47C8.tmp\test file.noassoc") WaitForSingleObject returned 258 shlexec.c:1507: Test failed: ShellExecute(file="C:\Users\winetest\AppData\Local\Temp\wt47C8.tmp\test file.noassoc") failed: rc=33 err=2 shlexec.c:1539: Test failed: argvA4 expected 'C:\Users\winetest\AppData\Local\Temp\wt47C8.tmp\test file.noassoc', but key not found or empty shlexec.c:138: Test failed: ShellExecute(verb="", file="C:\Users\winetest\AppData\Local\Temp\wt47C8.tmp\test file.shlexec.noassoc") WaitForSingleObject returned 258 shlexec.c:138: Test failed: ShellExecute(file="C:\Users\winetest\AppData\Local\Temp\wt47C8.tmp\test file.shlexec.noassoc") WaitForSingleObject returned 258 shlexec.c:1507: Test failed: ShellExecute(file="C:\Users\winetest\AppData\Local\Temp\wt47C8.tmp\test file.shlexec.noassoc") failed: rc=33 err=2 shlexec.c:1539: Test failed: argvA4 expected 'C:\Users\winetest\AppData\Local\Temp\wt47C8.tmp\test file.shlexec.noassoc', but key not found or empty shlexec.c:138: Test failed: ShellExecute(verb="", file="C:\Users\winetest\AppData\Local\Temp\wt47C8.tmp\test file.noassoc", params="shlexec "C:\Users\winetest\AppData\Local\Temp\wt47C8.tmp\wt47C9.tmp" Exec") WaitForSingleObject returned 258 shlexec.c:138: Test failed: ShellExecute(file="C:\Users\winetest\AppData\Local\Temp\wt47C8.tmp\test file.noassoc", params="shlexec "C:\Users\winetest\AppData\Local\Temp\wt47C8.tmp\wt47C9.tmp" Exec") WaitForSingleObject returned 258 shlexec.c:2060: Test failed: ShellExecute(file="C:\Users\winetest\AppData\Local\Temp\wt47C8.tmp\test file.noassoc", params="shlexec "C:\Users\winetest\AppData\Local\Temp\wt47C8.tmp\wt47C9.tmp" Exec") succeeded: rc=42 === w2008s64 (64 bit shlexec) === shlexec.c:1539: Test failed: argvA4 expected 'C:/Users/ADMINI~1/AppData/Local/Temp/wt2FC.tmp/test file.shlexec', got 'C:\Users\Administrator\AppData\Local\Temp\wt2FC.tmp\test file.shlexec' shlexec.c:2607: Test failed: longPath expected 'C:\Users\ADMINI~1\AppData\Local\Temp\wt2FC.tmp\test2.exe', got 'C:\Users\Administrator\AppData\Local\Temp\wt2FC.tmp\test2.exe' shlexec.c:2620: Test failed: longPath expected 'C:\Users\ADMINI~1\AppData\Local\Temp\wt2FC.tmp\test2.exe', got 'C:\Users\Administrator\AppData\Local\Temp\wt2FC.tmp\test2.exe' shlexec.c:2632: Test failed: longPath expected 'C:\Users\ADMINI~1\AppData\Local\Temp\wt2FC.tmp\test2.exe', got 'C:\Users\Administrator\AppData\Local\Temp\wt2FC.tmp\test2.exe' === w864 (64 bit shlexec) === shlexec.c:138: Test failed: ShellExecute(verb="", file="C:\Users\winetest\AppData\Local\Temp\wt4597.tmp\test file.noassoc") WaitForSingleObject returned 258 shlexec.c:138: Test failed: ShellExecute(file="C:\Users\winetest\AppData\Local\Temp\wt4597.tmp\test file.noassoc") WaitForSingleObject returned 258 shlexec.c:1507: Test failed: ShellExecute(file="C:\Users\winetest\AppData\Local\Temp\wt4597.tmp\test file.noassoc") failed: rc=33 err=2 shlexec.c:1539: Test failed: argvA4 expected 'C:\Users\winetest\AppData\Local\Temp\wt4597.tmp\test file.noassoc', but key not found or empty shlexec.c:138: Test failed: ShellExecute(verb="", file="C:\Users\winetest\AppData\Local\Temp\wt4597.tmp\test file.shlexec.noassoc") WaitForSingleObject returned 258 shlexec.c:138: Test failed: ShellExecute(file="C:\Users\winetest\AppData\Local\Temp\wt4597.tmp\test file.shlexec.noassoc") WaitForSingleObject returned 258 shlexec.c:1507: Test failed: ShellExecute(file="C:\Users\winetest\AppData\Local\Temp\wt4597.tmp\test file.shlexec.noassoc") failed: rc=33 err=2 shlexec.c:1539: Test failed: argvA4 expected 'C:\Users\winetest\AppData\Local\Temp\wt4597.tmp\test file.shlexec.noassoc', but key not found or empty shlexec.c:138: Test failed: ShellExecute(verb="", file="C:\Users\winetest\AppData\Local\Temp\wt4597.tmp\test file.noassoc", params="shlexec "C:\Users\winetest\AppData\Local\Temp\wt4597.tmp\wt4598.tmp" Exec") WaitForSingleObject returned 258 shlexec.c:138: Test failed: ShellExecute(file="C:\Users\winetest\AppData\Local\Temp\wt4597.tmp\test file.noassoc", params="shlexec "C:\Users\winetest\AppData\Local\Temp\wt4597.tmp\wt4598.tmp" Exec") WaitForSingleObject returned 258 shlexec.c:2060: Test failed: ShellExecute(file="C:\Users\winetest\AppData\Local\Temp\wt4597.tmp\test file.noassoc", params="shlexec "C:\Users\winetest\AppData\Local\Temp\wt4597.tmp\wt4598.tmp" Exec") succeeded: rc=42 === w864 (64 bit shlfolder) === shlfolder: unhandled exception c0000005 at 000007F93936ABDC

Oct. 26, 2013

Re: msvcrt: add support for _chsize_s (try #3)

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://newtestbot.winehq.org/JobDetails.pl?Key=3053 Your paranoid android. === wvista (32 bit file) === Failure running script in VM: timed out waiting for the child process === w2008s64 (32 bit file) === Failure running script in VM: timed out waiting for the child process === w7pro64 (32 bit file) === file.c:1574: Test failed: Wrong file size Timeout === w864 (32 bit file) === Failure running script in VM: timed out waiting for the child process

Oct. 26, 2013

Re: [PATCH 1/2] advapi32: HKCR merge: foundation

by Alexandre Julliard

George Stephanos <gaf.stephanos(a)gmail.com> writes: > On Fri, Oct 25, 2013 at 10:31 AM, Alexandre Julliard > <julliard(a)winehq.org> wrote: > > George Stephanos <gaf.stephanos(a)gmail.com> writes: > > > You need some sort of free list instead of a linear search. > > > > Alright. > > > > Also you can probably avoid one level of pointers and store > > objects directly. > > > > > > I thought about this. If I store objects directly, accessing any > would > > require a lock on the whole table so I guarantee it's not moved > or > > reallocated elsewhere. This would obviously be pretty slow. > > > You already have a lock on the whole table anyway. > > > I do. But it's only used when creating new handles or on table > reallocations. > Earlier I could reallocate the table without worrying about the > handles. > > In your case that same lock would have to be grabbed when > *accessing* any of the handles so I make sure the table is > not being reallocated. > That results in: no two handles can be accessed concurrently as > opposed > to my current code where they can. > I might be missing something though :| You still have to grab the lock on every access; I very much doubt that releasing it a little earlier is going to make a difference. Of course you can make things faster by making them non thread-safe, but that's not a good idea. > > Returning a pointer to the object outside of the critical > section > > is not > > a good idea. > > > > The critical section just protects the table and not the > > handles/structs themselves. > > > Yes, that's the problem. The structs have to be protected too. > > Maybe a lock inside each struct? You would need to demonstrate an real app that shows heavy contention on that lock to make it worth the trouble. -- Alexandre Julliard julliard(a)winehq.org

Oct. 25, 2013

Re: [PATCH 1/5] ddraw/tests: Accept nvidia return values in test_rt_caps.

by Henri Verbeet

On 25 October 2013 17:09, Stefan Dösinger <stefandoesinger(a)gmail.com> wrote: > I was thinking about marking some of those results broken, but in the end I couldn't find an argument why the results from GPU A are more correct than the results from GPU B, especially when considering that the differences between ddraw versions on the same GPU are just as big and strange as the differences between GPUs. Yeah, but broken() is really more about what behaviour we want Wine to follow as opposed to some judgment about what's correct. I think it makes sense to try to be somewhat consistent there. Obviously that doesn't apply for things that depend on e.g. the hardware implementation, but this is for things that are purely in our ddraw/wined3d implementation.

Oct. 25, 2013

Re: [PATCH 1/5] ddraw/tests: Accept nvidia return values in test_rt_caps.

by Stefan Dösinger

Am 25.10.2013 um 14:12 schrieb Henri Verbeet <hverbeet(a)gmail.com>: > This kind of construction doesn't generally make me very happy, but on > the other hand I'm not sure I can come up with something that's much > better either. I do think we should mark the alternative results as > broken. Some of the Evergreen results in later patches in this series > are a bit surprising to me. I wrote the test on Windows 7 / AMD > Cayman, which should be very close to Evergreen hardware. I was thinking about marking some of those results broken, but in the end I couldn't find an argument why the results from GPU A are more correct than the results from GPU B, especially when considering that the differences between ddraw versions on the same GPU are just as big and strange as the differences between GPUs.

Oct. 25, 2013

Re: [PATCH 1/2] advapi32: HKCR merge: foundation

by George Stephanos

On Fri, Oct 25, 2013 at 10:31 AM, Alexandre Julliard <julliard(a)winehq.org>wrote: > George Stephanos <gaf.stephanos(a)gmail.com> writes: > > > You need some sort of free list instead of a linear search. > > > > Alright. > > > > Also you can probably avoid one level of pointers and store > > objects directly. > > > > > > I thought about this. If I store objects directly, accessing any would > > require a lock on the whole table so I guarantee it's not moved or > > reallocated elsewhere. This would obviously be pretty slow. > > You already have a lock on the whole table anyway. > I do. But it's only used when creating new handles or on table reallocations. Earlier I could reallocate the table without worrying about the handles. In your case that same lock would have to be grabbed when *accessing* any of the handles so I make sure the table is not being reallocated. That results in: no two handles can be accessed concurrently as opposed to my current code where they can. I might be missing something though :| > > Returning a pointer to the object outside of the critical section > > is not > > a good idea. > > > > The critical section just protects the table and not the > > handles/structs themselves. > > Yes, that's the problem. The structs have to be protected too. > Maybe a lock inside each struct? > > -- > Alexandre Julliard > julliard(a)winehq.org >

Oct. 25, 2013

Re: [PATCH 1/5] ddraw/tests: Accept nvidia return values in test_rt_caps.

by Henri Verbeet

On 25 October 2013 00:47, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > --- > dlls/ddraw/tests/ddraw2.c | 26 ++++++++++++++++++++++++-- > dlls/ddraw/tests/ddraw7.c | 27 ++++++++++++++++++++++++--- > 2 files changed, 48 insertions(+), 5 deletions(-) > > diff --git a/dlls/ddraw/tests/ddraw2.c b/dlls/ddraw/tests/ddraw2.c > index f4702f1..801135d 100644 > --- a/dlls/ddraw/tests/ddraw2.c > +++ b/dlls/ddraw/tests/ddraw2.c > @@ -3663,6 +3663,7 @@ static void test_rt_caps(void) > DWORD caps_out; > HRESULT create_device_hr; > HRESULT set_rt_hr; > + HRESULT alternative_set_rt_hr; > } > test_data[] = > { This kind of construction doesn't generally make me very happy, but on the other hand I'm not sure I can come up with something that's much better either. I do think we should mark the alternative results as broken. Some of the Evergreen results in later patches in this series are a bit surprising to me. I wrote the test on Windows 7 / AMD Cayman, which should be very close to Evergreen hardware.

Oct. 25, 2013

Re: [PATCH 2/5] ddraw/tests: Allow some flags to fail surface creation in test_rt_caps.

by Stefan Dösinger

Am 25.10.2013 um 02:38 schrieb Marvin <testbot(a)winehq.org>: > === w864 (32 bit ddraw2) === > ddraw2.c:3915: Test failed: Test 16: Got unexpected caps 0x22800, expected 0x10026000. > ddraw2.c:3915: Test failed: Test 17: Got unexpected caps 0x20800, expected 0x10024000. > > === w864 (32 bit ddraw1) === > ddraw1.c:3289: Test failed: Test 16: Got unexpected caps 0x22800, expected 0x10026000. > ddraw1.c:3289: Test failed: Test 17: Got unexpected caps 0x20800, expected 0x10024000. Patch 3 should fix those.

Oct. 25, 2013

Re: [PATCH 1/2] advapi32: HKCR merge: foundation

by Alexandre Julliard

George Stephanos <gaf.stephanos(a)gmail.com> writes: > You need some sort of free list instead of a linear search. > > Alright. > > Also you can probably avoid one level of pointers and store > objects directly. > > > I thought about this. If I store objects directly, accessing any would > require a lock on the whole table so I guarantee it's not moved or > reallocated elsewhere. This would obviously be pretty slow. You already have a lock on the whole table anyway. > Returning a pointer to the object outside of the critical section > is not > a good idea. > > The critical section just protects the table and not the > handles/structs themselves. Yes, that's the problem. The structs have to be protected too. -- Alexandre Julliard julliard(a)winehq.org

Oct. 25, 2013

Re: [3/4] kernel32/tests: WaitCommEvent may sometimes return immediately on a busy system when write operation to a COM-port

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://newtestbot.winehq.org/JobDetails.pl?Key=3039 Your paranoid android. === w2008s64 (64 bit comm) === comm.c:885: WaitCommEvent for EV_TXEMPTY took 1513 ms (timeout 1000) comm.c:886: Test failed: WaitCommEvent used 1513 ms for waiting === w7pro64 (64 bit comm) === comm.c:859: Test failed: WaitCommEvent failed with a timeout comm.c:870: recovering after WAIT_TIMEOUT... comm.c:880: Test failed: WaitCommEvent error 0 comm.c:881: Test failed: WaitCommEvent: expected EV_TXEMPTY, got 0 comm.c:885: WaitCommEvent for EV_TXEMPTY took 1513 ms (timeout 1000) comm.c:886: Test failed: WaitCommEvent used 1513 ms for waiting comm.c:1552: test_AbortWaitCts timeout 500 handle 0000000000000068 comm.c:1519: Changing CommMask on the fly for handle 0000000000000068 after timeout 500

Oct. 25, 2013

Re: [2/4] kernel32/tests: Increase the timeout for completion of write to a COM-port.

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://newtestbot.winehq.org/JobDetails.pl?Key=3038 Your paranoid android. === w2008s64 (64 bit comm) === comm.c:885: WaitCommEvent for EV_TXEMPTY took 1513 ms (timeout 1000) comm.c:886: Test failed: WaitCommEvent used 1513 ms for waiting === w7pro64 (64 bit comm) === comm.c:859: Test failed: WaitCommEvent failed with a timeout comm.c:870: recovering after WAIT_TIMEOUT... comm.c:880: Test failed: WaitCommEvent error 0 comm.c:881: Test failed: WaitCommEvent: expected EV_TXEMPTY, got 0 comm.c:885: WaitCommEvent for EV_TXEMPTY took 1513 ms (timeout 1000) comm.c:886: Test failed: WaitCommEvent used 1513 ms for waiting comm.c:1552: test_AbortWaitCts timeout 500 handle 0000000000000068 comm.c:1519: Changing CommMask on the fly for handle 0000000000000068 after timeout 500

Oct. 25, 2013

Re: [PATCH 5/5] d3d8/tests: Port z_range_test to d3d8.

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://newtestbot.winehq.org/JobDetails.pl?Key=3034 Your paranoid android. === w864 (32 bit visual) === visual.c:1619: Test failed: Failed to create vertex shader, hr 0x8876086c. visual.c:1649: Test failed: Failed to delete vertex shader, hr 0x8876086c. visual.c:1657: Test failed: Z range failed: Got color 0x00ffffff, expected 0x00ff0000. visual.c:1664: Test failed: Z range failed: Got color 0x00ffffff, expected 0x000000ff. visual.c:1666: Test failed: Z range failed: Got color 0x00ffffff, expected 0x000000ff.

Oct. 25, 2013

Re: [PATCH 3/5] ddraw/tests: Make caps checking in test_rt_caps() less strict.

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://newtestbot.winehq.org/JobDetails.pl?Key=3032 Your paranoid android. === w864 (32 bit ddraw7) === The test timed out === w864 (32 bit ddraw4) === The test timed out

Oct. 25, 2013

Re: [PATCH 1/2] advapi32: HKCR merge: foundation

by George Stephanos

On Fri, Sep 27, 2013 at 11:13 AM, Alexandre Julliard <julliard(a)winehq.org>wrote: > George Stephanos <gaf.stephanos(a)gmail.com> writes: > > > @@ -224,13 +248,138 @@ static NTSTATUS open_key( HKEY *retkey, > ACCESS_MASK access, OBJECT_ATTRIBUTES *a > > > > } > > > > +static LSTATUS create_hkcr_struct( HKEY *hkey, opened_hkcr_t **hkcr ) > > +{ > > + UINT_PTR handle = nb_hkcr_handles, i; > > + LSTATUS ret = ERROR_SUCCESS; > > + > > + EnterCriticalSection( &hkcr_handles_cs ); > > + > > + for (i = 0; i < nb_hkcr_handles; i++) > > + { > > + if (!hkcr_handles[i]) > > + { > > + handle = i; > > + break; > > + } > > + } > > You need some sort of free list instead of a linear search. Alright. Also you can probably avoid one level of pointers and store objects > directly. > I thought about this. If I store objects directly, accessing any would require a lock on the whole table so I guarantee it's not moved or reallocated elsewhere. This would obviously be pretty slow. > > Returning a pointer to the object outside of the critical section is not > a good idea. The critical section just protects the table and not the handles/structs themselves. > > > +static HKEY resolve_hkcr( HKEY hkey ) > > +{ > > + HKEY ret; > > + UINT_PTR idx = (UINT_PTR)hkey >> 2; > > + opened_hkcr_t *hkcr; > > + if (idx <= nb_hkcr_handles) > > + { > > + EnterCriticalSection( &hkcr_handles_cs ); > > The count needs to be protected by the critical section too. > > Also please write a better subject line for the commit. > > -- > Alexandre Julliard > julliard(a)winehq.org >

Oct. 25, 2013

Re: [PATCH 2/5] ddraw/tests: Allow some flags to fail surface creation in test_rt_caps.

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://newtestbot.winehq.org/JobDetails.pl?Key=3031 Your paranoid android. === w864 (32 bit ddraw2) === ddraw2.c:3915: Test failed: Test 16: Got unexpected caps 0x22800, expected 0x10026000. ddraw2.c:3915: Test failed: Test 17: Got unexpected caps 0x20800, expected 0x10024000. === w864 (32 bit ddraw1) === ddraw1.c:3289: Test failed: Test 16: Got unexpected caps 0x22800, expected 0x10026000. ddraw1.c:3289: Test failed: Test 17: Got unexpected caps 0x20800, expected 0x10024000.

Oct. 25, 2013

Re: [PATCH 1/5] ddraw/tests: Accept nvidia return values in test_rt_caps.

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://newtestbot.winehq.org/JobDetails.pl?Key=3030 Your paranoid android. === w864 (32 bit ddraw2) === ddraw2: unhandled exception c0000005 at 00420E61 === w864 (32 bit ddraw7) === No test summary line found Failure running script in VM: network read timed out

Oct. 25, 2013

Re: winspool.drv/tests: Fix tests compilation with __WINESRC__ defined (try 2)

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://newtestbot.winehq.org/JobDetails.pl?Key=3019 Your paranoid android. === w864 (32 bit info) === info: unhandled exception c0000005 at 0040B246 === w864 (64 bit info) === info.c:2932: Test failed: got NULL DEVMODEA info: unhandled exception c0000005 at 00000000004099CD

Oct. 24, 2013

Re: [PATCH 6/6] ole32: If an object exposes IExternalConnection then don't take down the stub manager if we have remaining w

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://newtestbot.winehq.org/JobDetails.pl?Key=3010 Your paranoid android. === w864 (32 bit marshal) === marshal.c:3318: Test failed: info->cbSize was -737179689 instead of 48 marshal.c:3319: Test failed: info->dwServerPid was 0x874 instead of 0x904 marshal.c:3335: Test failed: info->cbSize was -737179689 instead of 48 marshal.c:3336: Test failed: info->dwServerPid was 0x874 instead of 0x904 marshal.c:3373: Test failed: info->cbSize was -737179689 instead of 48 marshal.c:3374: Test failed: info->dwServerPid was 0x874 instead of 0x904 marshal.c:3391: Test failed: info->cbSize was -737179689 instead of 48 marshal.c:3392: Test failed: info->dwServerPid was 0x874 instead of 0x904 marshal.c:3355: Test failed: info->cbSize was -737179689 instead of 48 marshal.c:3356: Test failed: info->dwServerPid was 0x874 instead of 0x904 marshal.c:3318: Test failed: info->cbSize was -737179689 instead of 48 marshal.c:3319: Test failed: info->dwServerPid was 0x874 instead of 0x904 marshal.c:3335: Test failed: info->cbSize was -737179689 instead of 48 marshal.c:3336: Test failed: info->dwServerPid was 0x874 instead of 0x904 marshal.c:3373: Test failed: info->cbSize was -737179689 instead of 48 marshal.c:3374: Test failed: info->dwServerPid was 0x874 instead of 0x904 marshal.c:3391: Test failed: info->cbSize was -737179689 instead of 48 marshal.c:3392: Test failed: info->dwServerPid was 0x874 instead of 0x904 marshal.c:3355: Test failed: info->cbSize was -737179689 instead of 48 marshal.c:3356: Test failed: info->dwServerPid was 0x874 instead of 0x904 marshal.c:3318: Test failed: info->cbSize was -737179689 instead of 48 marshal.c:3319: Test failed: info->dwServerPid was 0x874 instead of 0x904 marshal.c:3335: Test failed: info->cbSize was -737179689 instead of 48 marshal.c:3336: Test failed: info->dwServerPid was 0x874 instead of 0x904 marshal.c:3373: Test failed: info->cbSize was -737179689 instead of 48 marshal.c:3374: Test failed: info->dwServerPid was 0x874 instead of 0x904 marshal.c:3391: Test failed: info->cbSize was -737179689 instead of 48 marshal.c:3392: Test failed: info->dwServerPid was 0x874 instead of 0x904 marshal.c:3355: Test failed: info->cbSize was -737179689 instead of 48 marshal.c:3356: Test failed: info->dwServerPid was 0x874 instead of 0x904 === w864 (64 bit marshal) === marshal.c:3318: Test failed: info->cbSize was -588349091 instead of 56 marshal.c:3319: Test failed: info->dwServerPid was 0xaa4 instead of 0xa48 marshal.c:3335: Test failed: info->cbSize was -588349091 instead of 56 marshal.c:3336: Test failed: info->dwServerPid was 0xaa4 instead of 0xa48 marshal.c:3373: Test failed: info->cbSize was -588349091 instead of 56 marshal.c:3374: Test failed: info->dwServerPid was 0xaa4 instead of 0xa48 marshal.c:3391: Test failed: info->cbSize was -588349091 instead of 56 marshal.c:3392: Test failed: info->dwServerPid was 0xaa4 instead of 0xa48 marshal.c:3355: Test failed: info->cbSize was -588349091 instead of 56 marshal.c:3356: Test failed: info->dwServerPid was 0xaa4 instead of 0xa48 marshal.c:3318: Test failed: info->cbSize was -588349091 instead of 56 marshal.c:3319: Test failed: info->dwServerPid was 0xaa4 instead of 0xa48 marshal.c:3335: Test failed: info->cbSize was -588349091 instead of 56 marshal.c:3336: Test failed: info->dwServerPid was 0xaa4 instead of 0xa48 marshal.c:3373: Test failed: info->cbSize was -588349091 instead of 56 marshal.c:3374: Test failed: info->dwServerPid was 0xaa4 instead of 0xa48 marshal.c:3391: Test failed: info->cbSize was -588349091 instead of 56 marshal.c:3392: Test failed: info->dwServerPid was 0xaa4 instead of 0xa48 marshal.c:3355: Test failed: info->cbSize was -588349091 instead of 56 marshal.c:3356: Test failed: info->dwServerPid was 0xaa4 instead of 0xa48 marshal.c:3318: Test failed: info->cbSize was -588349091 instead of 56 marshal.c:3319: Test failed: info->dwServerPid was 0xaa4 instead of 0xa48 marshal.c:3335: Test failed: info->cbSize was -588349091 instead of 56 marshal.c:3336: Test failed: info->dwServerPid was 0xaa4 instead of 0xa48 marshal.c:3373: Test failed: info->cbSize was -588349091 instead of 56 marshal.c:3374: Test failed: info->dwServerPid was 0xaa4 instead of 0xa48 marshal.c:3391: Test failed: info->cbSize was -588349091 instead of 56 marshal.c:3392: Test failed: info->dwServerPid was 0xaa4 instead of 0xa48 marshal.c:3355: Test failed: info->cbSize was -588349091 instead of 56 marshal.c:3356: Test failed: info->dwServerPid was 0xaa4 instead of 0xa48

Oct. 24, 2013

Re: [PATCH 5/6] ole32: Call IExternalConnection_ReleaseConnection with the correct final parameter.

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://newtestbot.winehq.org/JobDetails.pl?Key=3009 Your paranoid android. === w864 (32 bit marshal) === marshal.c:3321: Test failed: info->cbSize was 1527466381 instead of 48 marshal.c:3322: Test failed: info->dwServerPid was 0xb60 instead of 0xa48 marshal.c:3338: Test failed: info->cbSize was 1527466381 instead of 48 marshal.c:3339: Test failed: info->dwServerPid was 0xb60 instead of 0xa48 marshal.c:3376: Test failed: info->cbSize was 1527466381 instead of 48 marshal.c:3377: Test failed: info->dwServerPid was 0xb60 instead of 0xa48 marshal.c:3394: Test failed: info->cbSize was 1527466381 instead of 48 marshal.c:3395: Test failed: info->dwServerPid was 0xb60 instead of 0xa48 marshal.c:3358: Test failed: info->cbSize was 1527466381 instead of 48 marshal.c:3359: Test failed: info->dwServerPid was 0xb60 instead of 0xa48 marshal.c:3321: Test failed: info->cbSize was 1527466381 instead of 48 marshal.c:3322: Test failed: info->dwServerPid was 0xb60 instead of 0xa48 marshal.c:3338: Test failed: info->cbSize was 1527466381 instead of 48 marshal.c:3339: Test failed: info->dwServerPid was 0xb60 instead of 0xa48 marshal.c:3376: Test failed: info->cbSize was 1527466381 instead of 48 marshal.c:3377: Test failed: info->dwServerPid was 0xb60 instead of 0xa48 marshal.c:3394: Test failed: info->cbSize was 1527466381 instead of 48 marshal.c:3395: Test failed: info->dwServerPid was 0xb60 instead of 0xa48 marshal.c:3358: Test failed: info->cbSize was 1527466381 instead of 48 marshal.c:3359: Test failed: info->dwServerPid was 0xb60 instead of 0xa48 marshal.c:3321: Test failed: info->cbSize was 1527466381 instead of 48 marshal.c:3322: Test failed: info->dwServerPid was 0xb60 instead of 0xa48 marshal.c:3338: Test failed: info->cbSize was 1527466381 instead of 48 marshal.c:3339: Test failed: info->dwServerPid was 0xb60 instead of 0xa48 marshal.c:3376: Test failed: info->cbSize was 1527466381 instead of 48 marshal.c:3377: Test failed: info->dwServerPid was 0xb60 instead of 0xa48 marshal.c:3394: Test failed: info->cbSize was 1527466381 instead of 48 marshal.c:3395: Test failed: info->dwServerPid was 0xb60 instead of 0xa48 marshal.c:3358: Test failed: info->cbSize was 1527466381 instead of 48 marshal.c:3359: Test failed: info->dwServerPid was 0xb60 instead of 0xa48 === w864 (64 bit marshal) === marshal.c:3321: Test failed: info->cbSize was -1047396882 instead of 56 marshal.c:3322: Test failed: info->dwServerPid was 0x86c instead of 0xbb0 marshal.c:3338: Test failed: info->cbSize was -1047396882 instead of 56 marshal.c:3339: Test failed: info->dwServerPid was 0x86c instead of 0xbb0 marshal.c:3376: Test failed: info->cbSize was -1047396882 instead of 56 marshal.c:3377: Test failed: info->dwServerPid was 0x86c instead of 0xbb0 marshal.c:3394: Test failed: info->cbSize was -1047396882 instead of 56 marshal.c:3395: Test failed: info->dwServerPid was 0x86c instead of 0xbb0 marshal.c:3358: Test failed: info->cbSize was -1047396882 instead of 56 marshal.c:3359: Test failed: info->dwServerPid was 0x86c instead of 0xbb0 marshal.c:3321: Test failed: info->cbSize was -1047396882 instead of 56 marshal.c:3322: Test failed: info->dwServerPid was 0x86c instead of 0xbb0 marshal.c:3338: Test failed: info->cbSize was -1047396882 instead of 56 marshal.c:3339: Test failed: info->dwServerPid was 0x86c instead of 0xbb0 marshal.c:3376: Test failed: info->cbSize was -1047396882 instead of 56 marshal.c:3377: Test failed: info->dwServerPid was 0x86c instead of 0xbb0 marshal.c:3394: Test failed: info->cbSize was -1047396882 instead of 56 marshal.c:3395: Test failed: info->dwServerPid was 0x86c instead of 0xbb0 marshal.c:3358: Test failed: info->cbSize was -1047396882 instead of 56 marshal.c:3359: Test failed: info->dwServerPid was 0x86c instead of 0xbb0 marshal.c:3321: Test failed: info->cbSize was -1047396882 instead of 56 marshal.c:3322: Test failed: info->dwServerPid was 0x86c instead of 0xbb0 marshal.c:3338: Test failed: info->cbSize was -1047396882 instead of 56 marshal.c:3339: Test failed: info->dwServerPid was 0x86c instead of 0xbb0 marshal.c:3376: Test failed: info->cbSize was -1047396882 instead of 56 marshal.c:3377: Test failed: info->dwServerPid was 0x86c instead of 0xbb0 marshal.c:3394: Test failed: info->cbSize was -1047396882 instead of 56 marshal.c:3395: Test failed: info->dwServerPid was 0x86c instead of 0xbb0 marshal.c:3358: Test failed: info->cbSize was -1047396882 instead of 56 marshal.c:3359: Test failed: info->dwServerPid was 0x86c instead of 0xbb0

Oct. 24, 2013

Re: [PATCH 4/6] ole32: When releasing marshal data of a normal ref ignore any remaining weak refs.

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://newtestbot.winehq.org/JobDetails.pl?Key=3008 Your paranoid android. === w864 (32 bit marshal) === marshal.c:3326: Test failed: info->cbSize was 1527466381 instead of 48 marshal.c:3327: Test failed: info->dwServerPid was 0x5bc instead of 0xac8 marshal.c:3343: Test failed: info->cbSize was 1527466381 instead of 48 marshal.c:3344: Test failed: info->dwServerPid was 0x5bc instead of 0xac8 marshal.c:3381: Test failed: info->cbSize was 1527466381 instead of 48 marshal.c:3382: Test failed: info->dwServerPid was 0x5bc instead of 0xac8 marshal.c:3399: Test failed: info->cbSize was 1527466381 instead of 48 marshal.c:3400: Test failed: info->dwServerPid was 0x5bc instead of 0xac8 marshal.c:3363: Test failed: info->cbSize was 1527466381 instead of 48 marshal.c:3364: Test failed: info->dwServerPid was 0x5bc instead of 0xac8 marshal.c:3326: Test failed: info->cbSize was 1527466381 instead of 48 marshal.c:3327: Test failed: info->dwServerPid was 0x5bc instead of 0xac8 marshal.c:3343: Test failed: info->cbSize was 1527466381 instead of 48 marshal.c:3344: Test failed: info->dwServerPid was 0x5bc instead of 0xac8 marshal.c:3381: Test failed: info->cbSize was 1527466381 instead of 48 marshal.c:3382: Test failed: info->dwServerPid was 0x5bc instead of 0xac8 marshal.c:3399: Test failed: info->cbSize was 1527466381 instead of 48 marshal.c:3400: Test failed: info->dwServerPid was 0x5bc instead of 0xac8 marshal.c:3363: Test failed: info->cbSize was 1527466381 instead of 48 marshal.c:3364: Test failed: info->dwServerPid was 0x5bc instead of 0xac8 marshal.c:3326: Test failed: info->cbSize was 1527466381 instead of 48 marshal.c:3327: Test failed: info->dwServerPid was 0x5bc instead of 0xac8 marshal.c:3343: Test failed: info->cbSize was 1527466381 instead of 48 marshal.c:3344: Test failed: info->dwServerPid was 0x5bc instead of 0xac8 marshal.c:3381: Test failed: info->cbSize was 1527466381 instead of 48 marshal.c:3382: Test failed: info->dwServerPid was 0x5bc instead of 0xac8 marshal.c:3399: Test failed: info->cbSize was 1527466381 instead of 48 marshal.c:3400: Test failed: info->dwServerPid was 0x5bc instead of 0xac8 marshal.c:3363: Test failed: info->cbSize was 1527466381 instead of 48 marshal.c:3364: Test failed: info->dwServerPid was 0x5bc instead of 0xac8 === w864 (64 bit marshal) === marshal.c:3326: Test failed: info->cbSize was -1047396882 instead of 56 marshal.c:3327: Test failed: info->dwServerPid was 0x8e4 instead of 0xb74 marshal.c:3343: Test failed: info->cbSize was -1047396882 instead of 56 marshal.c:3344: Test failed: info->dwServerPid was 0x8e4 instead of 0xb74 marshal.c:3381: Test failed: info->cbSize was -1047396882 instead of 56 marshal.c:3382: Test failed: info->dwServerPid was 0x8e4 instead of 0xb74 marshal.c:3399: Test failed: info->cbSize was -1047396882 instead of 56 marshal.c:3400: Test failed: info->dwServerPid was 0x8e4 instead of 0xb74 marshal.c:3363: Test failed: info->cbSize was -1047396882 instead of 56 marshal.c:3364: Test failed: info->dwServerPid was 0x8e4 instead of 0xb74 marshal.c:3326: Test failed: info->cbSize was -1047396882 instead of 56 marshal.c:3327: Test failed: info->dwServerPid was 0x8e4 instead of 0xb74 marshal.c:3343: Test failed: info->cbSize was -1047396882 instead of 56 marshal.c:3344: Test failed: info->dwServerPid was 0x8e4 instead of 0xb74 marshal.c:3381: Test failed: info->cbSize was -1047396882 instead of 56 marshal.c:3382: Test failed: info->dwServerPid was 0x8e4 instead of 0xb74 marshal.c:3399: Test failed: info->cbSize was -1047396882 instead of 56 marshal.c:3400: Test failed: info->dwServerPid was 0x8e4 instead of 0xb74 marshal.c:3363: Test failed: info->cbSize was -1047396882 instead of 56 marshal.c:3364: Test failed: info->dwServerPid was 0x8e4 instead of 0xb74 marshal.c:3326: Test failed: info->cbSize was -1047396882 instead of 56 marshal.c:3327: Test failed: info->dwServerPid was 0x8e4 instead of 0xb74 marshal.c:3343: Test failed: info->cbSize was -1047396882 instead of 56 marshal.c:3344: Test failed: info->dwServerPid was 0x8e4 instead of 0xb74 marshal.c:3381: Test failed: info->cbSize was -1047396882 instead of 56 marshal.c:3382: Test failed: info->dwServerPid was 0x8e4 instead of 0xb74 marshal.c:3399: Test failed: info->cbSize was -1047396882 instead of 56 marshal.c:3400: Test failed: info->dwServerPid was 0x8e4 instead of 0xb74 marshal.c:3363: Test failed: info->cbSize was -1047396882 instead of 56 marshal.c:3364: Test failed: info->dwServerPid was 0x8e4 instead of 0xb74

Oct. 24, 2013

Re: [PATCH 3/6] ole32/tests: Add some tests for CoReleaseMarshalData with a combination of normal and weak marshals.

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://newtestbot.winehq.org/JobDetails.pl?Key=3007 Your paranoid android. === w864 (32 bit marshal) === marshal.c:3326: Test failed: info->cbSize was 1527466381 instead of 48 marshal.c:3327: Test failed: info->dwServerPid was 0xaa4 instead of 0xb54 marshal.c:3343: Test failed: info->cbSize was 1527466381 instead of 48 marshal.c:3344: Test failed: info->dwServerPid was 0xaa4 instead of 0xb54 marshal.c:3381: Test failed: info->cbSize was 1527466381 instead of 48 marshal.c:3382: Test failed: info->dwServerPid was 0xaa4 instead of 0xb54 marshal.c:3399: Test failed: info->cbSize was 1527466381 instead of 48 marshal.c:3400: Test failed: info->dwServerPid was 0xaa4 instead of 0xb54 marshal.c:3363: Test failed: info->cbSize was 1527466381 instead of 48 marshal.c:3364: Test failed: info->dwServerPid was 0xaa4 instead of 0xb54 marshal.c:3326: Test failed: info->cbSize was 1527466381 instead of 48 marshal.c:3327: Test failed: info->dwServerPid was 0xaa4 instead of 0xb54 marshal.c:3343: Test failed: info->cbSize was 1527466381 instead of 48 marshal.c:3344: Test failed: info->dwServerPid was 0xaa4 instead of 0xb54 marshal.c:3381: Test failed: info->cbSize was 1527466381 instead of 48 marshal.c:3382: Test failed: info->dwServerPid was 0xaa4 instead of 0xb54 marshal.c:3399: Test failed: info->cbSize was 1527466381 instead of 48 marshal.c:3400: Test failed: info->dwServerPid was 0xaa4 instead of 0xb54 marshal.c:3363: Test failed: info->cbSize was 1527466381 instead of 48 marshal.c:3364: Test failed: info->dwServerPid was 0xaa4 instead of 0xb54 marshal.c:3326: Test failed: info->cbSize was 1527466381 instead of 48 marshal.c:3327: Test failed: info->dwServerPid was 0xaa4 instead of 0xb54 marshal.c:3343: Test failed: info->cbSize was 1527466381 instead of 48 marshal.c:3344: Test failed: info->dwServerPid was 0xaa4 instead of 0xb54 marshal.c:3381: Test failed: info->cbSize was 1527466381 instead of 48 marshal.c:3382: Test failed: info->dwServerPid was 0xaa4 instead of 0xb54 marshal.c:3399: Test failed: info->cbSize was 1527466381 instead of 48 marshal.c:3400: Test failed: info->dwServerPid was 0xaa4 instead of 0xb54 marshal.c:3363: Test failed: info->cbSize was 1527466381 instead of 48 marshal.c:3364: Test failed: info->dwServerPid was 0xaa4 instead of 0xb54 === w864 (64 bit marshal) === marshal.c:3326: Test failed: info->cbSize was -1047396882 instead of 56 marshal.c:3327: Test failed: info->dwServerPid was 0x118 instead of 0xba4 marshal.c:3343: Test failed: info->cbSize was -1047396882 instead of 56 marshal.c:3344: Test failed: info->dwServerPid was 0x118 instead of 0xba4 marshal.c:3381: Test failed: info->cbSize was -1047396882 instead of 56 marshal.c:3382: Test failed: info->dwServerPid was 0x118 instead of 0xba4 marshal.c:3399: Test failed: info->cbSize was -1047396882 instead of 56 marshal.c:3400: Test failed: info->dwServerPid was 0x118 instead of 0xba4 marshal.c:3363: Test failed: info->cbSize was -1047396882 instead of 56 marshal.c:3364: Test failed: info->dwServerPid was 0x118 instead of 0xba4 marshal.c:3326: Test failed: info->cbSize was -1047396882 instead of 56 marshal.c:3327: Test failed: info->dwServerPid was 0x118 instead of 0xba4 marshal.c:3343: Test failed: info->cbSize was -1047396882 instead of 56 marshal.c:3344: Test failed: info->dwServerPid was 0x118 instead of 0xba4 marshal.c:3381: Test failed: info->cbSize was -1047396882 instead of 56 marshal.c:3382: Test failed: info->dwServerPid was 0x118 instead of 0xba4 marshal.c:3399: Test failed: info->cbSize was -1047396882 instead of 56 marshal.c:3400: Test failed: info->dwServerPid was 0x118 instead of 0xba4 marshal.c:3363: Test failed: info->cbSize was -1047396882 instead of 56 marshal.c:3364: Test failed: info->dwServerPid was 0x118 instead of 0xba4 marshal.c:3326: Test failed: info->cbSize was -1047396882 instead of 56 marshal.c:3327: Test failed: info->dwServerPid was 0x118 instead of 0xba4 marshal.c:3343: Test failed: info->cbSize was -1047396882 instead of 56 marshal.c:3344: Test failed: info->dwServerPid was 0x118 instead of 0xba4 marshal.c:3381: Test failed: info->cbSize was -1047396882 instead of 56 marshal.c:3382: Test failed: info->dwServerPid was 0x118 instead of 0xba4 marshal.c:3399: Test failed: info->cbSize was -1047396882 instead of 56 marshal.c:3400: Test failed: info->dwServerPid was 0x118 instead of 0xba4 marshal.c:3363: Test failed: info->cbSize was -1047396882 instead of 56 marshal.c:3364: Test failed: info->dwServerPid was 0x118 instead of 0xba4

Oct. 24, 2013

Re: [PATCH 2/6] ole32/tests: Make the two reference marshalling thread more generic.

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://newtestbot.winehq.org/JobDetails.pl?Key=3006 Your paranoid android. === w864 (32 bit marshal) === marshal.c:3230: Test failed: info->cbSize was 1527466381 instead of 48 marshal.c:3231: Test failed: info->dwServerPid was 0x370 instead of 0xa48 marshal.c:3247: Test failed: info->cbSize was 1527466381 instead of 48 marshal.c:3248: Test failed: info->dwServerPid was 0x370 instead of 0xa48 marshal.c:3285: Test failed: info->cbSize was 1527466381 instead of 48 marshal.c:3286: Test failed: info->dwServerPid was 0x370 instead of 0xa48 marshal.c:3303: Test failed: info->cbSize was 1527466381 instead of 48 marshal.c:3304: Test failed: info->dwServerPid was 0x370 instead of 0xa48 marshal.c:3267: Test failed: info->cbSize was 1527466381 instead of 48 marshal.c:3268: Test failed: info->dwServerPid was 0x370 instead of 0xa48 marshal.c:3230: Test failed: info->cbSize was 1527466381 instead of 48 marshal.c:3231: Test failed: info->dwServerPid was 0x370 instead of 0xa48 marshal.c:3247: Test failed: info->cbSize was 1527466381 instead of 48 marshal.c:3248: Test failed: info->dwServerPid was 0x370 instead of 0xa48 marshal.c:3285: Test failed: info->cbSize was 1527466381 instead of 48 marshal.c:3286: Test failed: info->dwServerPid was 0x370 instead of 0xa48 marshal.c:3303: Test failed: info->cbSize was 1527466381 instead of 48 marshal.c:3304: Test failed: info->dwServerPid was 0x370 instead of 0xa48 marshal.c:3267: Test failed: info->cbSize was 1527466381 instead of 48 marshal.c:3268: Test failed: info->dwServerPid was 0x370 instead of 0xa48 marshal.c:3230: Test failed: info->cbSize was 1527466381 instead of 48 marshal.c:3231: Test failed: info->dwServerPid was 0x370 instead of 0xa48 marshal.c:3247: Test failed: info->cbSize was 1527466381 instead of 48 marshal.c:3248: Test failed: info->dwServerPid was 0x370 instead of 0xa48 marshal.c:3285: Test failed: info->cbSize was 1527466381 instead of 48 marshal.c:3286: Test failed: info->dwServerPid was 0x370 instead of 0xa48 marshal.c:3303: Test failed: info->cbSize was 1527466381 instead of 48 marshal.c:3304: Test failed: info->dwServerPid was 0x370 instead of 0xa48 marshal.c:3267: Test failed: info->cbSize was 1527466381 instead of 48 marshal.c:3268: Test failed: info->dwServerPid was 0x370 instead of 0xa48 === w864 (64 bit marshal) === marshal.c:3230: Test failed: info->cbSize was -1047396882 instead of 56 marshal.c:3231: Test failed: info->dwServerPid was 0x738 instead of 0xbb8 marshal.c:3247: Test failed: info->cbSize was -1047396882 instead of 56 marshal.c:3248: Test failed: info->dwServerPid was 0x738 instead of 0xbb8 marshal.c:3285: Test failed: info->cbSize was -1047396882 instead of 56 marshal.c:3286: Test failed: info->dwServerPid was 0x738 instead of 0xbb8 marshal.c:3303: Test failed: info->cbSize was -1047396882 instead of 56 marshal.c:3304: Test failed: info->dwServerPid was 0x738 instead of 0xbb8 marshal.c:3267: Test failed: info->cbSize was -1047396882 instead of 56 marshal.c:3268: Test failed: info->dwServerPid was 0x738 instead of 0xbb8 marshal.c:3230: Test failed: info->cbSize was -1047396882 instead of 56 marshal.c:3231: Test failed: info->dwServerPid was 0x738 instead of 0xbb8 marshal.c:3247: Test failed: info->cbSize was -1047396882 instead of 56 marshal.c:3248: Test failed: info->dwServerPid was 0x738 instead of 0xbb8 marshal.c:3285: Test failed: info->cbSize was -1047396882 instead of 56 marshal.c:3286: Test failed: info->dwServerPid was 0x738 instead of 0xbb8 marshal.c:3303: Test failed: info->cbSize was -1047396882 instead of 56 marshal.c:3304: Test failed: info->dwServerPid was 0x738 instead of 0xbb8 marshal.c:3267: Test failed: info->cbSize was -1047396882 instead of 56 marshal.c:3268: Test failed: info->dwServerPid was 0x738 instead of 0xbb8 marshal.c:3230: Test failed: info->cbSize was -1047396882 instead of 56 marshal.c:3231: Test failed: info->dwServerPid was 0x738 instead of 0xbb8 marshal.c:3247: Test failed: info->cbSize was -1047396882 instead of 56 marshal.c:3248: Test failed: info->dwServerPid was 0x738 instead of 0xbb8 marshal.c:3285: Test failed: info->cbSize was -1047396882 instead of 56 marshal.c:3286: Test failed: info->dwServerPid was 0x738 instead of 0xbb8 marshal.c:3303: Test failed: info->cbSize was -1047396882 instead of 56 marshal.c:3304: Test failed: info->dwServerPid was 0x738 instead of 0xbb8 marshal.c:3267: Test failed: info->cbSize was -1047396882 instead of 56 marshal.c:3268: Test failed: info->dwServerPid was 0x738 instead of 0xbb8

Oct. 24, 2013

Re: [PATCH 1/6] ole32/tests: Extend the lifecycle tests to objects which expose IExternalConnection.

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://newtestbot.winehq.org/JobDetails.pl?Key=3005 Your paranoid android. === w864 (32 bit marshal) === marshal.c:3226: Test failed: info->cbSize was -1846173327 instead of 48 marshal.c:3227: Test failed: info->dwServerPid was 0x870 instead of 0xbac marshal.c:3243: Test failed: info->cbSize was -1846173327 instead of 48 marshal.c:3244: Test failed: info->dwServerPid was 0x870 instead of 0xbac marshal.c:3281: Test failed: info->cbSize was -1846173327 instead of 48 marshal.c:3282: Test failed: info->dwServerPid was 0x870 instead of 0xbac marshal.c:3299: Test failed: info->cbSize was -1846173327 instead of 48 marshal.c:3300: Test failed: info->dwServerPid was 0x870 instead of 0xbac marshal.c:3263: Test failed: info->cbSize was -1846173327 instead of 48 marshal.c:3264: Test failed: info->dwServerPid was 0x870 instead of 0xbac marshal.c:3226: Test failed: info->cbSize was -1846173327 instead of 48 marshal.c:3227: Test failed: info->dwServerPid was 0x870 instead of 0xbac marshal.c:3243: Test failed: info->cbSize was -1846173327 instead of 48 marshal.c:3244: Test failed: info->dwServerPid was 0x870 instead of 0xbac marshal.c:3281: Test failed: info->cbSize was -1846173327 instead of 48 marshal.c:3282: Test failed: info->dwServerPid was 0x870 instead of 0xbac marshal.c:3299: Test failed: info->cbSize was -1846173327 instead of 48 marshal.c:3300: Test failed: info->dwServerPid was 0x870 instead of 0xbac marshal.c:3263: Test failed: info->cbSize was -1846173327 instead of 48 marshal.c:3264: Test failed: info->dwServerPid was 0x870 instead of 0xbac marshal.c:3226: Test failed: info->cbSize was -1846173327 instead of 48 marshal.c:3227: Test failed: info->dwServerPid was 0x870 instead of 0xbac marshal.c:3243: Test failed: info->cbSize was -1846173327 instead of 48 marshal.c:3244: Test failed: info->dwServerPid was 0x870 instead of 0xbac marshal.c:3281: Test failed: info->cbSize was -1846173327 instead of 48 marshal.c:3282: Test failed: info->dwServerPid was 0x870 instead of 0xbac marshal.c:3299: Test failed: info->cbSize was -1846173327 instead of 48 marshal.c:3300: Test failed: info->dwServerPid was 0x870 instead of 0xbac marshal.c:3263: Test failed: info->cbSize was -1846173327 instead of 48 marshal.c:3264: Test failed: info->dwServerPid was 0x870 instead of 0xbac === w864 (64 bit marshal) === marshal.c:3226: Test failed: info->cbSize was -588349091 instead of 56 marshal.c:3227: Test failed: info->dwServerPid was 0x18c instead of 0xa48 marshal.c:3243: Test failed: info->cbSize was -588349091 instead of 56 marshal.c:3244: Test failed: info->dwServerPid was 0x18c instead of 0xa48 marshal.c:3281: Test failed: info->cbSize was -588349091 instead of 56 marshal.c:3282: Test failed: info->dwServerPid was 0x18c instead of 0xa48 marshal.c:3299: Test failed: info->cbSize was -588349091 instead of 56 marshal.c:3300: Test failed: info->dwServerPid was 0x18c instead of 0xa48 marshal.c:3263: Test failed: info->cbSize was -588349091 instead of 56 marshal.c:3264: Test failed: info->dwServerPid was 0x18c instead of 0xa48 marshal.c:3226: Test failed: info->cbSize was -588349091 instead of 56 marshal.c:3227: Test failed: info->dwServerPid was 0x18c instead of 0xa48 marshal.c:3243: Test failed: info->cbSize was -588349091 instead of 56 marshal.c:3244: Test failed: info->dwServerPid was 0x18c instead of 0xa48 marshal.c:3281: Test failed: info->cbSize was -588349091 instead of 56 marshal.c:3282: Test failed: info->dwServerPid was 0x18c instead of 0xa48 marshal.c:3299: Test failed: info->cbSize was -588349091 instead of 56 marshal.c:3300: Test failed: info->dwServerPid was 0x18c instead of 0xa48 marshal.c:3263: Test failed: info->cbSize was -588349091 instead of 56 marshal.c:3264: Test failed: info->dwServerPid was 0x18c instead of 0xa48 marshal.c:3226: Test failed: info->cbSize was -588349091 instead of 56 marshal.c:3227: Test failed: info->dwServerPid was 0x18c instead of 0xa48 marshal.c:3243: Test failed: info->cbSize was -588349091 instead of 56 marshal.c:3244: Test failed: info->dwServerPid was 0x18c instead of 0xa48 marshal.c:3281: Test failed: info->cbSize was -588349091 instead of 56 marshal.c:3282: Test failed: info->dwServerPid was 0x18c instead of 0xa48 marshal.c:3299: Test failed: info->cbSize was -588349091 instead of 56 marshal.c:3300: Test failed: info->dwServerPid was 0x18c instead of 0xa48 marshal.c:3263: Test failed: info->cbSize was -588349091 instead of 56 marshal.c:3264: Test failed: info->dwServerPid was 0x18c instead of 0xa48

Oct. 24, 2013

Re: server: Add support for pending write flag to the serial device. Take 2.

by Wolfgang Walter

Am Donnerstag, 24. Oktober 2013, 11:29:34 schrieb Dmitry Timoshkov: > Wolfgang Walter <wine(a)stwm.de> wrote: > > > > I have no intention to discuss that all again. Please think about the > > > > problem. Hint: writing twice as many bytes with 150 baud needs more > > > > time, > > > > significantly more time then TIMEOUT. > > > > > > Not really. Francois sent an investigation with pretty exhaustive > > > explanation of the behvaiour of COM-port UARTs regarding timings and > > > baud > > > rates. > > > > Have you read it? It says that with a standard UART windows may signals > > after 872ms that the tx queue is empty (though there are still 4 bytes to > > send) when you write 17 bytes. For 34 bytes he gets 1802ms > TIMEOUT. > > Where do you see 34 bytes to be written in that test? Sorry for that. I looked at the 1.7.2 codebase. There was SetLastError(0xdeadbeef); res = WriteFile(hcom, tbuf, sizeof(tbuf), &bytes, NULL); todo_wine ok(!res, "WriteFile on an overlapped handle without ovl structure should fail\n"); todo_wine ok(GetLastError() == ERROR_INVALID_PARAMETER, "expected ERROR_INVALID_PARAMETER, got %d\n", GetLastError()); In 1.7.4 there are no todo_wine's any more so this does not fail any more and there should be no pending bytes from that test. There should only be 17 bytes in the test in question. > > > And I really don't think that we can expect exactly that same behaviour > > when using the linux serial driver, anyway. > > At the time I was reworking the EV_TXEMPTY to use overlapped IO the > reasoning for using 900 ms as the designed time was simple: that was enough > to make the test pass under Windows with real hardware. How the patch we > are discussing makes the test pass for me under Linux with a USB-serial > adapter, which confirms that there is no reasons that it can't work under > Linux as well. > > I understand that there are cases of (really old) hardware where this limit > may not be enough, and Francois has already sent a patch which increases > timeout. The Francois' patch hasn't been accepted, but that's a different > matter. I built 1.7.4 here and I still get a timeout on my machine (with onboard device), though. The board has an Intel "Corporation 6 Series/C200 Series Chipset Family". I mesured the time needed to write with 150 baud on linux and it needs about 1000ms till ioctl(fd, TIOCOUTQ, &out) returns with zero. Sometimes up to 1100ms. When I mesure it I do not use select() or poll() but loop similar as wine does: call ioctl(), sleep for 1ms, ... Regards, -- Wolfgang Walter Studentenwerk München Anstalt des öffentlichen Rechts

Oct. 24, 2013

Re: [5/7] oleaut32/tests: Fix typelib tests compilation with __WINESRC__ defined

by Dmitry Timoshkov

André Hentschel <nerv(a)dawncrow.de> wrote: > - ok(lstrcmp(value, buf) == 0, #expr " expected \"%s\" got \"%s\"\n", value, buf); \ > + ok(lstrcmpA(value, buf) == 0, #expr " expected \"%s\" got \"%s\"\n", value, buf); \ Using simple strcmp() should be preferrable, leaving lstr* versions only for cases when an exception handler is really needed. P.S. Fixing compilation with __WINESRC__ defined gives an opportunity for reviewing the code, this should not be a simple search and replace job. -- Dmitry.

Oct. 24, 2013

Re: winspool.drv/tests: Fix tests compilation with __WINESRC__ defined

by Dmitry Timoshkov

André Hentschel <nerv(a)dawncrow.de> wrote: > @@ -3018,28 +3018,28 @@ START_TEST(info) > test_ConfigurePort(); > test_DeleteMonitor(); > test_DeletePort(); > - test_DeviceCapabilities(); > - test_DocumentProperties(); > + test_DeviceCapabilitiesA(); > + test_DocumentPropertiesA(); > test_EnumForms(NULL); > if (default_printer) test_EnumForms(default_printer); > test_EnumMonitors(); > - test_EnumPorts(); > + test_EnumPortsA(); > test_EnumPrinterDrivers(); > test_EnumPrinters(); > test_EnumPrintProcessors(); > test_GetDefaultPrinter(); > test_GetPrinterDriverDirectory(); > test_GetPrintProcessorDirectory(); > - test_OpenPrinter(); > - test_GetPrinter(); > + test_OpenPrinterA(); > + test_GetPrinterA(); > test_GetPrinterData(); > test_GetPrinterDataEx(); > - test_GetPrinterDriver(); > + test_GetPrinterDriverA(); > test_SetDefaultPrinter(); > test_XcvDataW_MonitorUI(); > test_XcvDataW_PortIsValid(); > test_IsValidDevmodeW(); > - test_OpenPrinter_defaults(); > + test_OpenPRINTER_DEFAULTSA(); Please leave the test names intact, that assumes that adding tests for W version of an API doesn't need a separate body. -- Dmitry.

Oct. 24, 2013

Re: server: Add support for pending write flag to the serial device. Take 2.

by Dmitry Timoshkov

Wolfgang Walter <wine(a)stwm.de> wrote: > > > I have no intention to discuss that all again. Please think about the > > > problem. Hint: writing twice as many bytes with 150 baud needs more time, > > > significantly more time then TIMEOUT. > > > > Not really. Francois sent an investigation with pretty exhaustive > > explanation of the behvaiour of COM-port UARTs regarding timings and baud > > rates. > > Have you read it? It says that with a standard UART windows may signals after > 872ms that the tx queue is empty (though there are still 4 bytes to send) when > you write 17 bytes. For 34 bytes he gets 1802ms > TIMEOUT. Where do you see 34 bytes to be written in that test? > And I really don't think that we can expect exactly that same behaviour when > using the linux serial driver, anyway. At the time I was reworking the EV_TXEMPTY to use overlapped IO the reasoning for using 900 ms as the designed time was simple: that was enough to make the test pass under Windows with real hardware. How the patch we are discussing makes the test pass for me under Linux with a USB-serial adapter, which confirms that there is no reasons that it can't work under Linux as well. I understand that there are cases of (really old) hardware where this limit may not be enough, and Francois has already sent a patch which increases timeout. The Francois' patch hasn't been accepted, but that's a different matter. -- Dmitry.

Oct. 24, 2013

Re: winspool.drv/tests: Fix tests compilation with __WINESRC__ defined

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://newtestbot.winehq.org/JobDetails.pl?Key=2988 Your paranoid android. === w864 (32 bit info) === info.c:2925: Test failed: got 0 info.c:2931: Test failed: got 0 info: unhandled exception c0000005 at 0040B246 === w864 (64 bit info) === info.c:2934: Test failed: got NULL DEVMODEA info: unhandled exception c0000005 at 00000000004099CD

Oct. 24, 2013

Re: winemac: Add registry settings to make Option keys send Alt rather than accessing additional characters from the keyboard layout.

by Ken Thomases

On Oct 21, 2013, at 4:23 AM, Phil Krylov wrote: > On Mon, Oct 21, 2013 at 6:47 AM, Ken Thomases <ken(a)codeweavers.com> wrote: > >> Does the attached patch help? > > Yes it does, thanks! Although the menu still blinks momentarily when I > release Command. I have submitted a tweaked version of that patch which should avoid that flicker. http://source.winehq.org/patches/data/99962 Cheers, Ken

Oct. 24, 2013

Re: [PATCH 2/6] user32: Implement OpenInputDesktop.

by Qian Hong

Hello, Thanks again for the advice. > Probably you could simply return the desktop of the current thread. Simply returning the desktop of current thread breaks one existent test, I adjust the idea to return the desktop of 'current process'. A new version is sent, I appreciate for the review!

Oct. 23, 2013

Re: [PATCH 2/2] user32: Implement OpenInputDesktop.

by Marvin

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

Oct. 23, 2013

Re: [PATCH 2/6] user32: Implement OpenInputDesktop.

by Alexandre Julliard

Qian Hong <qhong(a)codeweavers.com> writes: > Hello, > > On Wed, Oct 23, 2013 at 11:11 PM, Alexandre Julliard > <julliard(a)winehq.org> wrote: >> >> I don't think that makes sense, under Wine every desktop is potentially >> an input desktop, there's no way to decide which one is the "real" one. > > Thanks a lot for reviewing! > I'm not sure I understand what you expect, I attach a draft version > similar to patch 99498 with some improvements, could you have a look? > If that's not what you expect, could you advice a bit more details > what's the preferred way to improve OpenInputDesktop rather than a > stub? Probably you could simply return the desktop of the current thread. -- Alexandre Julliard julliard(a)winehq.org

Oct. 23, 2013

Re: [PATCH] user32/tests: Test SetUserObjectInformation for invisible winstation.

by Qian Hong

Hello, On Wed, Oct 23, 2013 at 1:51 PM, Dmitry Timoshkov <dmitry(a)baikal.ru> wrote: > It looks like that these new winstation tests now leave a reference to > a wineserver object which makes wineserver stay in memory after the tests > have finished. Please fix. Thanks for comment, I noticed this as well, it is an existing Wine bug discovered by my test, I have a comment regarding this bug in my [patch 4/6], I'll try to fix Wine rather than my test. -- Regards, Qian Hong - http://www.codeweavers.com

Oct. 23, 2013

Re: [PATCH 2/6] user32: Implement OpenInputDesktop.

by Qian Hong

Hello, On Wed, Oct 23, 2013 at 11:11 PM, Alexandre Julliard <julliard(a)winehq.org> wrote: > > I don't think that makes sense, under Wine every desktop is potentially > an input desktop, there's no way to decide which one is the "real" one. Thanks a lot for reviewing! I'm not sure I understand what you expect, I attach a draft version similar to patch 99498 with some improvements, could you have a look? If that's not what you expect, could you advice a bit more details what's the preferred way to improve OpenInputDesktop rather than a stub? Thanks again. -- Regards, Qian Hong - http://www.codeweavers.com

Oct. 23, 2013

Re: server: Add support for pending write flag to the serial device. Take 2.

by Wolfgang Walter

Am Mittwoch, 23. Oktober 2013, 20:44:28 schrieben Sie: > Wolfgang Walter <wine(a)stwm.de> wrote: > > I have no intention to discuss that all again. Please think about the > > problem. Hint: writing twice as many bytes with 150 baud needs more time, > > significantly more time then TIMEOUT. > > Not really. Francois sent an investigation with pretty exhaustive > explanation of the behvaiour of COM-port UARTs regarding timings and baud > rates. Have you read it? It says that with a standard UART windows may signals after 872ms that the tx queue is empty (though there are still 4 bytes to send) when you write 17 bytes. For 34 bytes he gets 1802ms > TIMEOUT. Here Francois' mesurements for windows: ================================== On my one Windows PC with a real UART (Intel(R) 82801DBM LPC Interface Controller - 24CC, i.e. ICH4 which emulates a 16550A UART) I get the following results which clearly illustrate the impact of the FIFO/trigger level. comm.c:1100: WaitCommEvent(1 bytes) for EV_TXEMPTY took 0 ms comm.c:1100: WaitCommEvent(2 bytes) for EV_TXEMPTY took 0 ms comm.c:1100: WaitCommEvent(3 bytes) for EV_TXEMPTY took 0 ms comm.c:1100: WaitCommEvent(4 bytes) for EV_TXEMPTY took 0 ms comm.c:1100: WaitCommEvent(5 bytes) for EV_TXEMPTY took 0 ms comm.c:1100: WaitCommEvent(6 bytes) for EV_TXEMPTY took 0 ms comm.c:1100: WaitCommEvent(7 bytes) for EV_TXEMPTY took 0 ms comm.c:1100: WaitCommEvent(8 bytes) for EV_TXEMPTY took 0 ms comm.c:1100: WaitCommEvent(9 bytes) for EV_TXEMPTY took 0 ms comm.c:1100: WaitCommEvent(10 bytes) for EV_TXEMPTY took 0 ms comm.c:1100: WaitCommEvent(11 bytes) for EV_TXEMPTY took 0 ms comm.c:1100: WaitCommEvent(12 bytes) for EV_TXEMPTY took 0 ms comm.c:1100: WaitCommEvent(13 bytes) for EV_TXEMPTY took 0 ms comm.c:1100: WaitCommEvent(14 bytes) for EV_TXEMPTY took 0 ms comm.c:1100: WaitCommEvent(15 bytes) for EV_TXEMPTY took 871 ms comm.c:1100: WaitCommEvent(16 bytes) for EV_TXEMPTY took 872 ms comm.c:1100: WaitCommEvent(17 bytes) for EV_TXEMPTY took 872 ms comm.c:1100: WaitCommEvent(18 bytes) for EV_TXEMPTY took 872 ms comm.c:1100: WaitCommEvent(19 bytes) for EV_TXEMPTY took 871 ms comm.c:1100: WaitCommEvent(20 bytes) for EV_TXEMPTY took 871 ms comm.c:1100: WaitCommEvent(21 bytes) for EV_TXEMPTY took 871 ms comm.c:1100: WaitCommEvent(22 bytes) for EV_TXEMPTY took 871 ms comm.c:1100: WaitCommEvent(23 bytes) for EV_TXEMPTY took 871 ms comm.c:1100: WaitCommEvent(24 bytes) for EV_TXEMPTY took 871 ms comm.c:1100: WaitCommEvent(25 bytes) for EV_TXEMPTY took 871 ms comm.c:1100: WaitCommEvent(26 bytes) for EV_TXEMPTY took 871 ms comm.c:1100: WaitCommEvent(27 bytes) for EV_TXEMPTY took 871 ms comm.c:1100: WaitCommEvent(28 bytes) for EV_TXEMPTY took 871 ms comm.c:1100: WaitCommEvent(29 bytes) for EV_TXEMPTY took 1802 ms comm.c:1100: WaitCommEvent(30 bytes) for EV_TXEMPTY took 1803 ms comm.c:1100: WaitCommEvent(31 bytes) for EV_TXEMPTY took 1803 ms comm.c:1100: WaitCommEvent(32 bytes) for EV_TXEMPTY took 1802 ms comm.c:1100: WaitCommEvent(33 bytes) for EV_TXEMPTY took 1803 ms comm.c:1100: WaitCommEvent(34 bytes) for EV_TXEMPTY took 1802 ms comm.c:1100: WaitCommEvent(35 bytes) for EV_TXEMPTY took 1803 ms comm.c:1100: WaitCommEvent(36 bytes) for EV_TXEMPTY took 1803 ms comm.c:1100: WaitCommEvent(37 bytes) for EV_TXEMPTY took 1803 ms comm.c:1100: WaitCommEvent(38 bytes) for EV_TXEMPTY took 1803 ms comm.c:1100: WaitCommEvent(39 bytes) for EV_TXEMPTY took 1803 ms comm.c:1100: WaitCommEvent(40 bytes) for EV_TXEMPTY took 1803 ms comm.c:1100: WaitCommEvent(41 bytes) for EV_TXEMPTY took 1802 ms comm.c:1100: WaitCommEvent(42 bytes) for EV_TXEMPTY took 1803 ms comm.c:1100: WaitCommEvent(43 bytes) for EV_TXEMPTY took 2734 ms comm.c:1100: WaitCommEvent(44 bytes) for EV_TXEMPTY took 2734 ms comm.c:1100: WaitCommEvent(45 bytes) for EV_TXEMPTY took 2734 ms comm.c:1100: WaitCommEvent(46 bytes) for EV_TXEMPTY took 2734 ms comm.c:1100: WaitCommEvent(47 bytes) for EV_TXEMPTY took 2734 ms comm.c:1100: WaitCommEvent(48 bytes) for EV_TXEMPTY took 2734 ms comm.c:1100: WaitCommEvent(49 bytes) for EV_TXEMPTY took 2734 ms comm.c:1100: WaitCommEvent(50 bytes) for EV_TXEMPTY took 2734 ms ================================= And I really don't think that we can expect exactly that same behaviour when using the linux serial driver, anyway. Regards, -- Wolfgang Walter Studentenwerk München Anstalt des öffentlichen Rechts

Oct. 23, 2013

Re: [PATCH 2/6] user32: Implement OpenInputDesktop.

by Alexandre Julliard

Qian Hong <qhong(a)codeweavers.com> writes: > Hello, > > This patch superseded patch 99498. > Thanks Vincent Povirk for the previous comment, now I try to implement > OpenInputDesktop in user32 and server. I don't think that makes sense, under Wine every desktop is potentially an input desktop, there's no way to decide which one is the "real" one. -- Alexandre Julliard julliard(a)winehq.org

Oct. 23, 2013

Re: ole32: Support activation context in CLSIDFromProgID()

by Alexandre Julliard

Nikolay Sivov <nsivov(a)codeweavers.com> writes: > Support activation context in CLSIDFromProgID() It breaks the tests: ../../../tools/runtest -q -P wine -T ../../.. -M msi.dll -p msi_test.exe.so msi.c && touch msi.ok msi.c:1974: Test failed: expected 0xdeadbeef, got 14007 msi.c:1981: Test failed: expected 0xdeadbeef, got 14007 msi.c:1988: Test failed: expected 0xdeadbeef, got 14007 msi.c:2003: Test failed: expected 0xdeadbeef, got 14007 msi.c:2506: Test failed: expected 0xdeadbeef, got 14007 msi.c:2515: Test failed: expected 0xdeadbeef, got 14007 make: *** [msi.ok] Error 6 -- Alexandre Julliard julliard(a)winehq.org

Oct. 23, 2013

Re: [PATCH 3/3] ddraw/tests: Test DDSCAPS2_D3DTEXTUREMANAGE.

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://newtestbot.winehq.org/JobDetails.pl?Key=2973 Your paranoid android. === w864 (32 bit ddraw7) === No test summary line found Failure running script in VM: network read timed out === w864 (64 bit ddraw7) === ddraw7.c:3695: Test failed: Got unexpected, hr 0x80004002, case 4. ddraw7.c:3695: Test failed: Got unexpected, hr 0x80004002, case 5. ddraw7.c:3695: Test failed: Got unexpected, hr 0x80004002, case 6. ddraw7.c:3695: Test failed: Got unexpected, hr 0x80004002, case 7. === w864 (32 bit ddraw4) === The test timed out

Oct. 23, 2013

Re: [PATCH 1/3] ddraw/tests: Add surface lockability tests.

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2013-10-23 15:10, schrieb Marvin: > === w864 (32 bit ddraw2) === The test timed out > > === w864 (32 bit ddraw1) === ddraw1: unhandled exception c0000005 > at 0041212F > > === w864 (32 bit ddraw7) === Timeout Failure running script in VM: > network read timed out > > === w864 (64 bit ddraw7) === ddraw7.c:3683: Test failed: Got > unexpected, hr 0x80004002, case 2. ddraw7.c:3683: Test failed: Got > unexpected, hr 0x80004002, case 3. ddraw7.c:3683: Test failed: Got > unexpected, hr 0x80004002, case 4. > > === w864 (32 bit ddraw4) === Failure running script in VM: network > read timed out As far as I can see those failures are unrelated to my patch. I'm working on fixing those failures. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSZ9F6AAoJEN0/YqbEcdMw/9kP/RFMHfdekgOOItmPyBDNmVbX 6M8XsjwBtD/VCYWVd/8LuKltT4KJULDlfRviOSjxQrymbLil4eTSM5ejDoW4Axg8 p1Gs6pijZ0M7XVSDyasoW/jxe7mJJx732uWUDDIhtd91nwYKryI+L4c7OhxXMT6Q FpIKfLAtvGdXuqe5qfxkdYGOkq+gwieQIi3TS9Jl+kxmnbkH9sYxrYpE9kt47MeO DUa/OlOB4WZ/zgaAb0N3jeRCF7Ue0quTS+emIIzZ6nT1jHbOzvc9Qy4jsEW0wlWC NEa6dVPl4qzXNMYyJk4/lteHVNkrILwVQPy+3ioanZs85KrpUtwzoEa+/oUvA67F JRqr1XgOpFjw7agur36uG4fSHukx3tTKrBWJEMgy2sXYj8noS9Jc4yPnUk54ZSdi 0xL8Jtze1/iQOIKo0AzqoDqnZbWiVvAHyYAGwNaci6sQQCeaPgDdFYvwh5uMr65Y 4xh+3KQFhgPmaHi8yHCZtKg9OZxWZFACaJITf1qeXDWVAsQnm5QCKo5+mBxO0ny5 MVbaMJO8ta0X8Mjo3KWPH3MMF+ZPvdNsQ+rv1RinGGAofTPJii5/a/1SXqcafB/5 MZkhDRres6O1qQeOBiHbiS/TxH7esvwLON1T5HYEbgKUMQfNnA4UiCRFbgIoYDkR O+mmAKB3S1OLI3nTMu1o =JQ58 -----END PGP SIGNATURE-----

Oct. 23, 2013

Re: [PATCH 1/3] ddraw/tests: Add surface lockability tests.

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://newtestbot.winehq.org/JobDetails.pl?Key=2972 Your paranoid android. === w864 (32 bit ddraw2) === The test timed out === w864 (32 bit ddraw1) === ddraw1: unhandled exception c0000005 at 0041212F === w864 (32 bit ddraw7) === Timeout Failure running script in VM: network read timed out === w864 (64 bit ddraw7) === ddraw7.c:3683: Test failed: Got unexpected, hr 0x80004002, case 2. ddraw7.c:3683: Test failed: Got unexpected, hr 0x80004002, case 3. ddraw7.c:3683: Test failed: Got unexpected, hr 0x80004002, case 4. === w864 (32 bit ddraw4) === Failure running script in VM: network read timed out

Oct. 23, 2013

Re: [23/23] user32/tests: Enable user32 tests compilation with __WINESRC__ defined.

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://newtestbot.winehq.org/JobDetails.pl?Key=2971 Your paranoid android. === wxppro (32 bit) === No test summary line found === wvista (32 bit) === No test summary line found === w2008s64 (32 bit) === No test summary line found === w7pro64 (32 bit) === No test summary line found === w864 (32 bit) === No test summary line found === w2008s64 (64 bit) === No test summary line found === w7pro64 (64 bit) === No test summary line found === w864 (64 bit) === No test summary line found

Oct. 23, 2013

Re: server: Add support for pending write flag to the serial device. Take 2.

by Dmitry Timoshkov

Wolfgang Walter <wine(a)stwm.de> wrote: > I have no intention to discuss that all again. Please think about the problem. > Hint: writing twice as many bytes with 150 baud needs more time, significantly > more time then TIMEOUT. Not really. Francois sent an investigation with pretty exhaustive explanation of the behvaiour of COM-port UARTs regarding timings and baud rates. -- Dmitry.

Oct. 23, 2013

Re: server: Add support for pending write flag to the serial device. Take 2.

by Wolfgang Walter

Am Mittwoch, 23. Oktober 2013, 18:41:15 schrieben Sie: > Wolfgang Walter <wine(a)stwm.de> wrote: > > With privious test I mean the test which starts at line 836: > > S(U(ovl_write)).Offset = 0; > > S(U(ovl_write)).OffsetHigh = 0; > > ovl_write.hEvent = CreateEventW(NULL, TRUE, FALSE, NULL); > > before = GetTickCount(); > > SetLastError(0xdeadbeef); > > res = WriteFile(hcom, tbuf, sizeof(tbuf), &bytes, &ovl_write); > > after = GetTickCount(); > > > > todo_wine > > > > ok(!res && GetLastError() == ERROR_IO_PENDING, "WriteFile returned %d, > > > > error %d\n", res, GetLastError()); > > todo_wine > > > > ok(!bytes, "expected 0, got %u\n", bytes); > > ok(after - before < 30, "WriteFile took %d ms to write %d Bytes at %d > > > > Baud\n", > > > > after - before, bytes, baud); > > > > /* don't wait for WriteFile completion */ > > > > This tests sends 17 bytes but does not wait till all have been sent. > > That's the point of the test. > > > So the > > next test which fails under wine (comm.c:860: Test failed: WaitCommEvent > > failed with a timeout) does not start with a empty tx queue. There should > > be a sleep(TIMEOUT) after this test. > > State of the queue doesn't matter at all, the patch (which is the subject of > this message) is supposed to make this test work in all cases. I have no intention to discuss that all again. Please think about the problem. Hint: writing twice as many bytes with 150 baud needs more time, significantly more time then TIMEOUT. Regards, -- Wolfgang Walter Studentenwerk München Anstalt des öffentlichen Rechts

Oct. 23, 2013

Re: [02/02] d3d8: update locked_rect only if wined3d_surface_map succeeds

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2013-10-21 14:31, schrieb Lasse Rasinen: > On 21.10.2013, at 15.23, Henri Verbeet wrote: > >> On 21 October 2013 14:12, Lasse Rasinen <lrasinen(a)iki.fi> wrote: >>> Buildbot on the previous patch and Stefan Dösinger on Friday. >>> >> https://newtestbot.winehq.org/JobDetails.pl?Key=2784 says it >> passed the test that checked for NULL pBits and 0 Pitch. AFAIK >> Stefan didn't test d3d8 at all. Fyi, I tested the d3d8 behavior, and it consistently sets pBits and pitch to 0 on all tested machines: WinXP, ATI r200 (radeon 9000) WinVista, Nvidia G7x (geforce 7400) Win7, ATI r500 (radeon x1600) Win7, Nvidia Fermi (Geforce 460) Win7, AMD Evergreen (radeon hd 5770) D3D9 left those fields untouched. For d3d9 I only tested WinXP+r200 and Win7+Kepler. Volumes clear pBits and both pitches in d3d9 on those cards and presumably all others. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSZ7BzAAoJEN0/YqbEcdMw7MYP/1DoI3U/sqjvYk/1uH/sYoGg yGo/W0GGsQo1CV8YWsYxZ4oH8dduzJzC91fby05CueLx97Q/l87pwoOebQ1cEyoE aGFOokjNIh9M9Kbi+T/fzhiITK8WRowJ5KoxODl94RcomO6/rhs6XFkTw0CUYzJi Qgv1oMY8kRCmoJh7rwI/qe11M7XiP7NY8LQUcAice7KUL1aj/kKK3l4rwKUU2Yig 5ThlbludmL5+HJIg5z+3azjN0uFYqUU8khsQX+JbmNg8HL07kF/Q6eo2An3jLsnw z2TZz/YTW7Xvo7HzXNHslqulj3NsmtWA5hT/YqDmzpnXjumcKhX7JB36mvjXYYdx 30VXGWwtOORFkoa91W+4/kSmXEjAWiveU6bNSDw0ezRKMAYEDofAPeVahgIc1PfD lUCzDiTksE1gplvM1quqwTXQZNuC3kLQKcVIIXJdAY9ydgNgSuS+MJP9s0xnDLC3 G47+bq5Trs9eLJaAkqGCdSBHYTRzE/pJc7sQTsmcxnKr7aNMZCMC95tcioGL/RH8 8o9tqUjTqsz0kTilwNyRmtJCt4qKVaTbDAk7mb/lCHIlKMidipWMhaxAb9hce0bj PjbeSTKpV7diCl/VvYM+KUDVDsgX32FEQ2OOVabRnQkLET/gVVzTQ8ag4UddloaR vl/dq6dOlAdGMX+R42Yd =ORs7 -----END PGP SIGNATURE-----

Oct. 23, 2013

Re: [20/23] user32/tests: Fix window tests compilation with __WINESRC__ defined.

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://newtestbot.winehq.org/JobDetails.pl?Key=2968 Your paranoid android. === wxppro (32 bit win) === win.c:892: Test failed: wrong dwWindowStatus: 0001 != 0000 active 000700E2 fg 00030040 in hook HCBT_ACTIVATE win.c:2951: Test failed: GetActiveWindow() = 00000000 win.c:2951: Test failed: GetFocus() = 00000000 win.c:2974: Test failed: GetActiveWindow() = 00000000 win.c:2974: Test failed: GetFocus() = 00000000 win.c:3035: Test failed: GetActiveWindow() = 00000000 win.c:3035: Test failed: GetFocus() = 00000000 === wvista (32 bit win) === win.c:892: Test failed: wrong dwWindowStatus: 0001 != 0000 active 000701F6 fg 00010046 in hook HCBT_ACTIVATE win.c:2951: Test failed: GetActiveWindow() = 00000000 win.c:2951: Test failed: GetFocus() = 00000000 win.c:2974: Test failed: GetActiveWindow() = 00000000 win.c:2974: Test failed: GetFocus() = 00000000 win.c:3035: Test failed: GetActiveWindow() = 00000000 win.c:3035: Test failed: GetFocus() = 00000000 === w2008s64 (32 bit win) === win.c:892: Test failed: wrong dwWindowStatus: 0001 != 0000 active 000500F4 fg 0001004E in hook HCBT_ACTIVATE win.c:2951: Test failed: GetActiveWindow() = 00000000 win.c:2951: Test failed: GetFocus() = 00000000 win.c:2974: Test failed: GetActiveWindow() = 00000000 win.c:2974: Test failed: GetFocus() = 00000000 win.c:3035: Test failed: GetActiveWindow() = 00000000 win.c:3035: Test failed: GetFocus() = 00000000 === w7pro64 (32 bit win) === win.c:892: Test failed: wrong dwWindowStatus: 0001 != 0000 active 00090138 fg 00010066 in hook HCBT_ACTIVATE win.c:2951: Test failed: GetActiveWindow() = 00000000 win.c:2951: Test failed: GetFocus() = 00000000 win.c:2974: Test failed: GetActiveWindow() = 00000000 win.c:2974: Test failed: GetFocus() = 00000000 win.c:3035: Test failed: GetActiveWindow() = 00000000 win.c:3035: Test failed: GetFocus() = 00000000 === w864 (32 bit win) === win.c:892: Test failed: wrong dwWindowStatus: 0001 != 0000 active 000601BA fg 00010084 in hook HCBT_ACTIVATE win.c:2951: Test failed: GetActiveWindow() = 00000000 win.c:2951: Test failed: GetFocus() = 00000000 win.c:2974: Test failed: GetActiveWindow() = 00000000 win.c:2974: Test failed: GetFocus() = 00000000 win.c:3035: Test failed: GetActiveWindow() = 00000000 win.c:3035: Test failed: GetFocus() = 00000000 === w2008s64 (64 bit win) === win.c:892: Test failed: wrong dwWindowStatus: 0001 != 0000 active 00000000000500F4 fg 000000000001004E in hook HCBT_ACTIVATE win.c:2951: Test failed: GetActiveWindow() = 0000000000000000 win.c:2951: Test failed: GetFocus() = 0000000000000000 win.c:2974: Test failed: GetActiveWindow() = 0000000000000000 win.c:2974: Test failed: GetFocus() = 0000000000000000 win.c:3035: Test failed: GetActiveWindow() = 0000000000000000 win.c:3035: Test failed: GetFocus() = 0000000000000000 === w7pro64 (64 bit win) === win.c:892: Test failed: wrong dwWindowStatus: 0001 != 0000 active 0000000000090138 fg 0000000000010066 in hook HCBT_ACTIVATE win.c:2951: Test failed: GetActiveWindow() = 0000000000000000 win.c:2951: Test failed: GetFocus() = 0000000000000000 win.c:2974: Test failed: GetActiveWindow() = 0000000000000000 win.c:2974: Test failed: GetFocus() = 0000000000000000 win.c:3035: Test failed: GetActiveWindow() = 0000000000000000 win.c:3035: Test failed: GetFocus() = 0000000000000000

Oct. 23, 2013

Re: [18/23] user32/tests: Fix system parameters tests compilation with __WINESRC__ defined.

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://newtestbot.winehq.org/JobDetails.pl?Key=2966 Your paranoid android. === w864 (32 bit sysparams) === sysparams.c:2792: Test failed: GetSystemMetrics(SM_CXMAXTRACK): expected 1044 or 1036 actual 1040 sysparams.c:2794: Test failed: GetSystemMetrics(SM_CYMAXTRACK): expected 788 or 780 actual 784 sysparams.c:2490: Test failed: Waiting for the WM_DISPLAYCHANGE message timed out sysparams.c:2503: Test failed: Set bpp 32, but WM_DISPLAYCHANGE reported bpp -1 === w864 (64 bit sysparams) === sysparams.c:2792: Test failed: GetSystemMetrics(SM_CXMAXTRACK): expected 1044 or 1036 actual 1040 sysparams.c:2794: Test failed: GetSystemMetrics(SM_CYMAXTRACK): expected 788 or 780 actual 784 Timeout

Oct. 23, 2013

Re: server: Add support for pending write flag to the serial device. Take 2.

by Dmitry Timoshkov

Wolfgang Walter <wine(a)stwm.de> wrote: > With privious test I mean the test which starts at line 836: > > S(U(ovl_write)).Offset = 0; > S(U(ovl_write)).OffsetHigh = 0; > ovl_write.hEvent = CreateEventW(NULL, TRUE, FALSE, NULL); > before = GetTickCount(); > SetLastError(0xdeadbeef); > res = WriteFile(hcom, tbuf, sizeof(tbuf), &bytes, &ovl_write); > after = GetTickCount(); > todo_wine > ok(!res && GetLastError() == ERROR_IO_PENDING, "WriteFile returned %d, > error %d\n", res, GetLastError()); > todo_wine > ok(!bytes, "expected 0, got %u\n", bytes); > ok(after - before < 30, "WriteFile took %d ms to write %d Bytes at %d > Baud\n", > after - before, bytes, baud); > /* don't wait for WriteFile completion */ > > > This tests sends 17 bytes but does not wait till all have been sent. That's the point of the test. > So the > next test which fails under wine (comm.c:860: Test failed: WaitCommEvent > failed with a timeout) does not start with a empty tx queue. There should be a > sleep(TIMEOUT) after this test. State of the queue doesn't matter at all, the patch (which is the subject of this message) is supposed to make this test work in all cases. -- Dmitry.

Oct. 23, 2013

Re: server: Add support for pending write flag to the serial device. Take 2.

by Wolfgang Walter

Am Mittwoch, 23. Oktober 2013, 11:12:26 schrieben Sie: > Wolfgang Walter <wine(a)stwm.de> wrote: > > > ../../../tools/runtest -q -P wine -T ../../.. -M kernel32.dll -p > > > kernel32_test.exe.so comm.c && touch comm.ok comm.c:860: Test failed: > > > WaitCommEvent failed with a timeout > > > comm.c:881: Test failed: WaitCommEvent error 997 > > > comm.c:882: Test failed: WaitCommEvent: expected EV_TXEMPTY, got 0 > > > comm.c:887: Test failed: WaitCommEvent used 1003 ms for waiting > > > comm.c:2226: Tests skipped: interactive tests (set > > > WINETEST_INTERACTIVE=1) > > > make: *** [comm.ok] Error 4 > > > > This is because the previous test fails: in the previous test wine > > actually > > write to the serial device and does not return with > > ERROR_INVALID_PARAMETER. > What is this "previous test" you are talking about? Obviously there is no > a failing test which checks for ERROR_INVALID_PARAMETER in the output posted > by Alexandre above. And it's worth to mention that these tests pass without > failures here with and without an external hardware turned on (with the > patch applied). With privious test I mean the test which starts at line 836: S(U(ovl_write)).Offset = 0; S(U(ovl_write)).OffsetHigh = 0; ovl_write.hEvent = CreateEventW(NULL, TRUE, FALSE, NULL); before = GetTickCount(); SetLastError(0xdeadbeef); res = WriteFile(hcom, tbuf, sizeof(tbuf), &bytes, &ovl_write); after = GetTickCount(); todo_wine ok(!res && GetLastError() == ERROR_IO_PENDING, "WriteFile returned %d, error %d\n", res, GetLastError()); todo_wine ok(!bytes, "expected 0, got %u\n", bytes); ok(after - before < 30, "WriteFile took %d ms to write %d Bytes at %d Baud\n", after - before, bytes, baud); /* don't wait for WriteFile completion */ This tests sends 17 bytes but does not wait till all have been sent. So the next test which fails under wine (comm.c:860: Test failed: WaitCommEvent failed with a timeout) does not start with a empty tx queue. There should be a sleep(TIMEOUT) after this test. The test for ERROR_INVALID_PARAMETER before that one (starting at line 831) does indeed not contribute any more to comm.c:860: Test failed: WaitCommEvent failed with a timeout any more. When we discussed this it did because then the the code still was: SetLastError(0xdeadbeef); res = WriteFile(hcom, tbuf, sizeof(tbuf), &bytes, NULL); todo_wine ok(!res, "WriteFile on an overlapped handle without ovl structure should fail\n"); todo_wine ok(GetLastError() == ERROR_INVALID_PARAMETER, "expected ERROR_INVALID_PARAMETER, got %d\n", GetLastError()); So then there were even more bytes pending in the tx queue. Regards, -- Wolfgang Walter Studentenwerk München Anstalt des öffentlichen Rechts

Oct. 23, 2013

Re: [10/23] user32/tests: Fix input tests compilation with __WINESRC__ defined.

by Dmitry Timoshkov

Saulius Krasuckas <saulius2(a)ar.fi.lt> wrote: > Dmitry, what has changed since? > (now that every test subdir is being migrated to compile with __WINESRC__) Nothing has changed on my part. Obviously the __WINESRC__ enforcement for the tests is not my idea, you need to ask somebody else about it. -- Dmitry.

Oct. 23, 2013

Re: [07/23] user32/tests: Fix DDE tests compilation with __WINESRC__ defined.

by Marvin

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

Oct. 23, 2013

Re: [10/23] user32/tests: Fix input tests compilation with __WINESRC__ defined.

by Saulius Krasuckas

* On Wed, 23 Oct 2013, Dmitry Timoshkov wrote: > --- a/dlls/user32/tests/input.c > +++ b/dlls/user32/tests/input.c > @@ -929,7 +929,7 @@ static void test_Input_blackbox(void) > * key state set by SendInput(). */ > empty_message_queue(); > > - prevWndProc = SetWindowLongPtr(window, GWLP_WNDPROC, (LONG_PTR) WndProc2); > + prevWndProc = SetWindowLongPtrA(window, GWLP_WNDPROC, (LONG_PTR) WndProc2); > ok(prevWndProc != 0 || (prevWndProc == 0 && GetLastError() == 0), > "error: %d\n", (int) GetLastError()); > * On Fri, 8 Jun 2007, Saulius Krasuckas wrote: > --- a/dlls/user32/tests/input.c > +++ b/dlls/user32/tests/input.c > @@ -496,7 +496,7 @@ static void test_Input_blackbox(void) > * key state set by SendInput(). */ > empty_message_queue(); > > - prevWndProc = SetWindowLongPtr(window, GWLP_WNDPROC, (LONG_PTR) WndProc2); > + prevWndProc = SetWindowLongPtrA(window, GWLP_WNDPROC, (LONG_PTR) WndProc2); > ok(prevWndProc != 0 || (prevWndProc == 0 && GetLastError() == 0), > "error: %d\n", (int) GetLastError()); > It's nice to see the change is being offered by it's previous opponent six years later. Since Dmitry was strongly against it, questions go to him: * On Sat, 9 Jun 2007, Dmitry Timoshkov wrote: > "Saulius Krasuckas" <saulius2(a)ar.fi.lt> wrote: > > > Hello. I see some tests call [GS]etWindowLongPtr(..., GWLP_WNDPROC, > > ...). I think this is somewhat confusing. API offers both A- an W- > > versions of this function, while at my first glance I cannot firmly > > decide, what used name does refer to. > > > > Shouldn't occurences be renamed to ...WindowLongPtrA() here (or even > > all occurrences {by not requiring second parameter == GWLP_WNDPROC}) ? > > > > Same question stands for [GS]etWindowLong(). > > The code is correct as it is now, there is no need to change anything. Dmitry, what has changed since? (now that every test subdir is being migrated to compile with __WINESRC__) > > Did that restrict us from using single naming scheme? > > Personally I don't see any point in that. The tests are not forced to > use A/W API suffixes, that's done on purpose. Is the purpose gone now? S.

Oct. 23, 2013

Re: [02/23] user32/tests: Fix class tests compilation with __WINESRC__ defined.

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://newtestbot.winehq.org/JobDetails.pl?Key=2950 Your paranoid android. === w864 (32 bit class) === class.c:692: Test failed: Windows should be Unicode

Oct. 23, 2013

Re: [01/23] user32/tests: Fix broadcast tests compilation with __WINESRC__ defined.

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://newtestbot.winehq.org/JobDetails.pl?Key=2949 Your paranoid android. === w864 (64 bit broadcast) === The test timed out

Oct. 23, 2013

Re: [PATCH] user32/tests: Test SetUserObjectInformation for invisible winstation.

by Dmitry Timoshkov

Qian Hong <qhong(a)codeweavers.com> wrote: > With Francois's great help, I've fixed most winstation failures. There > are still some random failures which seems hard to fix, I think the > tachyon modulation must be wrongly polarised. <grin> It looks like that these new winstation tests now leave a reference to a wineserver object which makes wineserver stay in memory after the tests have finished. Please fix. -- Dmitry.

Oct. 23, 2013

Re: server: Add support for pending write flag to the serial device. Take 2.

by Dmitry Timoshkov

Wolfgang Walter <wine(a)stwm.de> wrote: > > ../../../tools/runtest -q -P wine -T ../../.. -M kernel32.dll -p > > kernel32_test.exe.so comm.c && touch comm.ok comm.c:860: Test failed: > > WaitCommEvent failed with a timeout > > comm.c:881: Test failed: WaitCommEvent error 997 > > comm.c:882: Test failed: WaitCommEvent: expected EV_TXEMPTY, got 0 > > comm.c:887: Test failed: WaitCommEvent used 1003 ms for waiting > > comm.c:2226: Tests skipped: interactive tests (set WINETEST_INTERACTIVE=1) > > make: *** [comm.ok] Error 4 > > This is because the previous test fails: in the previous test wine actually > write to the serial device and does not return with ERROR_INVALID_PARAMETER. What is this "previous test" you are talking about? Obviously there is no a failing test which checks for ERROR_INVALID_PARAMETER in the output posted by Alexandre above. And it's worth to mention that these tests pass without failures here with and without an external hardware turned on (with the patch applied). -- Dmitry.

Oct. 23, 2013

Re: server: Add support for pending write flag to the serial device. Take 2.

by Dmitry Timoshkov

Alexandre Julliard <julliard(a)winehq.org> wrote: > It doesn't work here: > > ../../../tools/runtest -q -P wine -T ../../.. -M kernel32.dll -p kernel32_test.exe.so comm.c && touch comm.ok > comm.c:860: Test failed: WaitCommEvent failed with a timeout > comm.c:881: Test failed: WaitCommEvent error 997 > comm.c:882: Test failed: WaitCommEvent: expected EV_TXEMPTY, got 0 > comm.c:887: Test failed: WaitCommEvent used 1003 ms for waiting Could you please generate a +relay,+tid,+comm,+server log for me? -- Dmitry.

Oct. 23, 2013

Re: comdlg32/tests: Use BOOL type where appropriate

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://newtestbot.winehq.org/JobDetails.pl?Key=2943 Your paranoid android. === w2008s64 (64 bit filedlg) === No test summary line found

Oct. 23, 2013

Re: [PATCH 5/6] user32/tests: Test SetUserObjectInformation for invisible winstation.

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://newtestbot.winehq.org/JobDetails.pl?Key=2941 Your paranoid android. === w2008s64 (32 bit winstation) === winstation.c:927: Test failed: unexpected foreground window 0001004E

Oct. 22, 2013

Re: Wine Mono 4.5.0 Release

by Alistair Leslie-Hughes

Hi Vincent, Thanks for the update. Time to start breaking (fixing) things again. Best Regards Alistair Leslie-Hughes

Oct. 22, 2013

Wine Mono 4.5.0 Release

by Vincent Povirk

I have published version 4.5.0 of Wine Mono on sourceforge. It's been a little over a year since the last release, and I'm sorry I waited so long to do it. I have also changed the versioning scheme. The major and minor version numbers will now indicate the highest supported .NET runtime version. The source tarball is at https://sourceforge.net/projects/wine/files/Wine%20Mono/4.5.0/wine-mono-4.5… The binary is at https://sourceforge.net/projects/wine/files/Wine%20Mono/4.5.0/wine-mono-4.5… For developers, the source repository is at https://github.com/madewokherd/wine-mono Changes since 0.0.8: * Fixed build on machines using bash as their sh implementation. * .NET Framework directories now include mscorlib.dll (fixes wine bug #31888). * Fixed build on machines running Mac OS X. (Josh DuBois) * Added a security.config file to the .NET 2.0 directory. (Alistair Leslie-Hughes) * Microsoft's Managed C++ compiler sometimes generates broken IL code ending in an unreachable ret statement. This code would be accepted by the .NET runtime but rejected by Mono. Mono is correctly following the spec in this case, but since our goal is compatibility we now accept code that does this. * Building with the -t switch will now build runtime tests. Previously, it only built class library tests. * Added registry keys to indicate the presence of .NET 4.5. * Added user-agent strings to the registry, which allow javascript embedded in web pages to detect .NET. * Updated Mono from 2.11.4 to 3.2.3 plus some additional commits. I'm no longer using Mono's release tags, because they don't seem to help me find revisions that are stable or even buildable. Anyway, here are some highlights of the changes brought in from Mono: * The new 'sgen' garbage collector has been greatly improved and is now the default instead of the old 'boehm' gc, which in our case means it's the only one shipped. It is an improvement over boehm in many ways and should be generally more efficient. * Mono now has support for Portable Class Libraries. * Beginnings of support for System.Windows.Forms.AxHost. (Alistair Leslie-Hughes) * Added support for P/Invoke methods with the thiscall calling convention, which are used by Managed C++ assemblies. * Improved IDispatch interface on managed objects. (Alistair Leslie-Hughes)

Oct. 22, 2013

Re: Mono Update

by Alistair Leslie-Hughes

On 14/10/2013 7:57 PM, Alistair Leslie-Hughes wrote: > Hi, > > wine-mono hasn't been updated in nearly a year. Should it be time to > consider a new release? > Any update to getting a new release? Best Regards Alistair

Oct. 22, 2013

Re: [PATCH] user32/tests: Test SetUserObjectInformation for invisible winstation.

by Qian Hong

Hello, With Francois's great help, I've fixed most winstation failures. There are still some random failures which seems hard to fix, I think the tachyon modulation must be wrongly polarised. <grin> The random failures looks like relating to sleeping time, I'm working hard on designing a new kind of Time Machine to help me debug the winstation issue, well, it would take some time before the machine works... Could I ask for reviewing my later patches first, and fix the remaining random failures later? Thanks! (Seriously, I believe simply increasing the sleeping time would help for the random failures, but I want to either find a better way or find stronger evidence to convince you accept a patch which increasing sleeping time if that's hard to be accepted) On Sat, Oct 12, 2013 at 12:07 AM, Qian Hong <qhong(a)codeweavers.com> wrote: > Hmm... It still fails today. I have a better idea to fix it, will send > a patch tomorrow. Sorry for introducing the failures :( -- Regards, Qian Hong - http://www.codeweavers.com

Oct. 22, 2013

Re: server: Add support for pending write flag to the serial device. Take 2.

by Wolfgang Walter

Am Dienstag, 22. Oktober 2013, 16:55:51 schrieb Alexandre Julliard: > Dmitry Timoshkov <dmitry(a)baikal.ru> writes: > > This patch makes WaitCommEvent(EV_TXEMPTY) work when a serial device > > reports that the out queue is empty even after a successful write() > > which is the case for real COM ports and as well as for serial-USB > > adapters. > > > > Take 2 removes special handling of FlushFileBuffers for a serial sevice, > > the tests show that it really should not reset the pending write state. > > > > I'd like to see some feedback for this patch. > > It doesn't work here: > > ../../../tools/runtest -q -P wine -T ../../.. -M kernel32.dll -p > kernel32_test.exe.so comm.c && touch comm.ok comm.c:860: Test failed: > WaitCommEvent failed with a timeout > comm.c:881: Test failed: WaitCommEvent error 997 > comm.c:882: Test failed: WaitCommEvent: expected EV_TXEMPTY, got 0 > comm.c:887: Test failed: WaitCommEvent used 1003 ms for waiting > comm.c:2226: Tests skipped: interactive tests (set WINETEST_INTERACTIVE=1) > make: *** [comm.ok] Error 4 This is because the previous test fails: in the previous test wine actually write to the serial device and does not return with ERROR_INVALID_PARAMETER. These 17 bytes also need some time to be written and therefor this test fails with a timeout. I proposed to add a sleep(TIMEOUT) if the previous test does not pass that is the write actually returns success or with error ERROR_IO_PENDING: if (res || (!res && GetLastError() == ERROR_IO_PENDING)) /* if data has been sent: wait for termination */ Sleep(timeout); This has been rejected because then the test passes even without changing the EV_TXEMPTY handling at all. This is because calling WaitCommEvent() while there are still bytes in the tx queue already works. This does not mean that "Add support for pending write flag to the serial device" is not needed. It is needed to correctly signal EV_TXEMPTY if WaitCommEvent() is called later when the tx queue is already empty. I sent a patch (5 Sep) adding an additional test for this case (the patch was named [PATCH 3/6] add another test for waiting for EV_TXEMPTY with WaitCommEvent(), try 2 It was part of a series of patches which implemented someting similar to Dmitry's patch so I hope Dmitry's patch goes in as it actually fixes an important bug. Independently: TIMEOUT is to short anyway for (see my earlier emails and those of Francois Gouget, I attached the latter one). Regards, -- Wolfgang Walter Studentenwerk München Anstalt des öffentlichen Rechts

Oct. 22, 2013

Re: comctl32/tests: Preparation for switching __WINESRC__ on

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://newtestbot.winehq.org/JobDetails.pl?Key=2934 Your paranoid android. === wvista (32 bit listview) === listview.c:5043: Test failed: NM_HOVER allow test: the msg sequence is not complete: expected 0087 - actual 0000 listview.c:5048: Test failed: NM_HOVER block test: the msg sequence is not complete: expected 0087 - actual 0000 === w2008s64 (32 bit listview) === listview.c:5043: Test failed: NM_HOVER allow test: the msg sequence is not complete: expected 0087 - actual 0000 listview.c:5048: Test failed: NM_HOVER block test: the msg sequence is not complete: expected 0087 - actual 0000 === w7pro64 (32 bit listview) === listview.c:5043: Test failed: NM_HOVER allow test: the msg sequence is not complete: expected 0087 - actual 0000 listview.c:5048: Test failed: NM_HOVER block test: the msg sequence is not complete: expected 0087 - actual 0000 === w864 (32 bit listview) === listview.c:5043: Test failed: NM_HOVER allow test: the msg sequence is not complete: expected 0087 - actual 0000 listview.c:5048: Test failed: NM_HOVER block test: the msg sequence is not complete: expected 0087 - actual 0000 === w2008s64 (64 bit listview) === listview.c:5043: Test failed: NM_HOVER allow test: the msg sequence is not complete: expected 0087 - actual 0000 listview.c:5048: Test failed: NM_HOVER block test: the msg sequence is not complete: expected 0087 - actual 0000 === w7pro64 (64 bit listview) === listview.c:5043: Test failed: NM_HOVER allow test: the msg sequence is not complete: expected 0087 - actual 0000 listview.c:5048: Test failed: NM_HOVER block test: the msg sequence is not complete: expected 0087 - actual 0000

Oct. 22, 2013

Re: server: Add support for pending write flag to the serial device. Take 2.

by Alexandre Julliard

Dmitry Timoshkov <dmitry(a)baikal.ru> writes: > This patch makes WaitCommEvent(EV_TXEMPTY) work when a serial device > reports that the out queue is empty even after a successful write() > which is the case for real COM ports and as well as for serial-USB > adapters. > > Take 2 removes special handling of FlushFileBuffers for a serial sevice, > the tests show that it really should not reset the pending write state. > > I'd like to see some feedback for this patch. It doesn't work here: ../../../tools/runtest -q -P wine -T ../../.. -M kernel32.dll -p kernel32_test.exe.so comm.c && touch comm.ok comm.c:860: Test failed: WaitCommEvent failed with a timeout comm.c:881: Test failed: WaitCommEvent error 997 comm.c:882: Test failed: WaitCommEvent: expected EV_TXEMPTY, got 0 comm.c:887: Test failed: WaitCommEvent used 1003 ms for waiting comm.c:2226: Tests skipped: interactive tests (set WINETEST_INTERACTIVE=1) make: *** [comm.ok] Error 4 -- Alexandre Julliard julliard(a)winehq.org

Oct. 22, 2013

Re: [PATCH 3/3] msvcrt: Don't output __ptr64 when UNDNAME_NO_MS_KEYWORDS is used

by Marvin

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

Oct. 22, 2013

Re: [PATCH 2/3] msvcrt: Output ptr64 when UNDNAME_NO_LEADING_UNDERSCORES flag is used

by Marvin

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

Oct. 22, 2013

Re: [PATCH 1/3] msvcrt: Add support for UNDNAME_NO_THISTYPE flag in __unDName

by Marvin

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

Oct. 22, 2013

Re: oleaut32: Added a preliminary test, for scale overflow, in VarDecCmp. (try 2) (resend)

by Marvin

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

Oct. 22, 2013

Re: oleaut32: Added a preliminary test, for scale overflow, in VarDecCmp. (resend)

by Dmitry Timoshkov

Christopher Cope <ccope3(a)utk.edu> wrote: > --- a/dlls/oleaut32/vartype.c > +++ b/dlls/oleaut32/vartype.c > @@ -5836,7 +5836,9 @@ HRESULT WINAPI VarDecRound(const DECIMAL* pDecIn, int cDecimals, DECIMAL* pDecOu > HRESULT WINAPI VarDecCmp(const DECIMAL* pDecLeft, const DECIMAL* pDecRight) > { > HRESULT hRet; > - DECIMAL result; > + static DECIMAL scaleFactor; Is there a reason to make this variable static? -- Dmitry.

Oct. 22, 2013

Re: shlwapi: Test and fix the behaviour of the CopyTo method for file sizes not multiple of the internal buffer size, on SHCreateStreamOnFileEx-returned IStreams.

by Vincent Povirk

We should probably still exit the loop if fewer bytes were read than requested, rather than do another read at the end of the file.

Oct. 21, 2013

Re: [PATCH] wined3d: Use GL_ARB_texture_mirror_clamp_to_edge when available.

by Henri Verbeet

On 21 October 2013 21:20, Rico Schüller <kgbricola(a)web.de> wrote: > As wgl.h is a bit out of date, it still uses the > GL_MIRROR_CLAMP_TO_EDGE_ATI instead of GL_MIRROR_CLAMP_TO_EDGE (which is > only available in headers for OpenGL 4.4). > The wine/wgl.h header is generated from the GL .spec files by dlls/opengl32/make_opengl, so in principle all you'd have to do would be to run that script to get the new constant. Unfortunately Khronos seems to have decided to no longer update the .spec files, since there are shiny new XML files now.

Oct. 21, 2013

Re: msvcrt: Make first call to fwrite bufferred

by Piotr Caban

Please ignore this patch, it slows down fwrite on unbuffered FILE's. On 10/21/13 15:43, Piotr Caban wrote: > Without this patch fwrite allocates the buffer on first call and doesn't > use it. > --- > dlls/msvcrt/file.c | 125 > +++++++++++++++++++++++------------------------------ > 1 file changed, 54 insertions(+), 71 deletions(-) > > > > >

Oct. 21, 2013

Re: [02/02] d3d8: update locked_rect only if wined3d_surface_map succeeds

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://newtestbot.winehq.org/JobDetails.pl?Key=2910 Your paranoid android. === w864 (32 bit device) === device.c:2481: Test failed: Expected foreground window 000401A4, got 00010084. device.c:3174: Test failed: Expected wndproc 0x4107a0, got 0x4107a0. device.c:4029: Test failed: pBits changed on double lock. device.c:4030: Test failed: Pitch changed on double lock.

Oct. 21, 2013

Re: [01/02] d3d9: update locked_rect only if wined3d_surface_map succeeds

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://newtestbot.winehq.org/JobDetails.pl?Key=2909 Your paranoid android. === w864 (32 bit device) === device: unhandled exception c0000005 at 740D14C8 === w864 (64 bit device) === device: unhandled exception c0000005 at 000007F84EDD90EB

Oct. 21, 2013

Re: [23/23] kernel32/tests: Enable kernel32 tests compilation with __WINESRC__ defined.

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://newtestbot.winehq.org/JobDetails.pl?Key=2908 Your paranoid android. === wxppro (32 bit) === No test summary line found === wvista (32 bit) === No test summary line found === w2008s64 (32 bit) === No test summary line found === w7pro64 (32 bit) === No test summary line found === w864 (32 bit) === No test summary line found === w2008s64 (64 bit) === No test summary line found === w7pro64 (64 bit) === No test summary line found === w864 (64 bit) === No test summary line found

Oct. 21, 2013

Re: [02/02] d3d8: update locked_rect only if wined3d_surface_map succeeds

by Lasse Rasinen

On 21.10.2013, at 15.23, Henri Verbeet wrote: > On 21 October 2013 14:12, Lasse Rasinen <lrasinen(a)iki.fi> wrote: >> Buildbot on the previous patch and Stefan Dösinger on Friday. >> > https://newtestbot.winehq.org/JobDetails.pl?Key=2784 says it passed > the test that checked for NULL pBits and 0 Pitch. AFAIK Stefan didn't > test d3d8 at all. > >> There's the one misbehaving app (Artemis spaceship sim) that cares. Will update test. >> > Isn't that d3d9? > D'oh. I can't read, apparently. Apologies. In that case, yes, this patch can be dropped; let's see what the buildbot thinks about the other one.

Oct. 21, 2013

Re: [02/02] d3d8: update locked_rect only if wined3d_surface_map succeeds

by Henri Verbeet

On 21 October 2013 14:12, Lasse Rasinen <lrasinen(a)iki.fi> wrote: > Buildbot on the previous patch and Stefan Dösinger on Friday. > https://newtestbot.winehq.org/JobDetails.pl?Key=2784 says it passed the test that checked for NULL pBits and 0 Pitch. AFAIK Stefan didn't test d3d8 at all. > There's the one misbehaving app (Artemis spaceship sim) that cares. Will update test. > Isn't that d3d9?

Oct. 21, 2013

Re: [02/02] d3d8: update locked_rect only if wined3d_surface_map succeeds

by Lasse Rasinen

On 21.10.2013, at 15.08, Henri Verbeet wrote: > On 21 October 2013 13:52, Lasse Rasinen <lrasinen(a)iki.fi> wrote: >> On 21.10.2013, at 14.46, Henri Verbeet wrote: >>> This test fails for me on Windows 7: >>> >>> device.c:4029: Test failed: pBits changed on double lock. >>> device.c:4030: Test failed: Pitch changed on double lock. >> >> So on one W7 computer the struct gets cleared, on another it is kept. >> > Is that on your own machine, or did I miss those results? Buildbot on the previous patch and Stefan Dösinger on Friday. >> Any advice on how to continue? For my use case, either solution will work. >> > If the results here really are inconsistent between machines, and no > application cares, you can probably just drop this patch. On the other > hand, if applications expect e.g. either NULL, or the original value, > you could instead write the test as "ok(!locked_rect.pBits || > locked_rect.pBits == (void *)0xdeadbeef, ...);" and add an appropriate > comment. There's the one misbehaving app (Artemis spaceship sim) that cares. Will update test.

Oct. 21, 2013

Re: [02/02] d3d8: update locked_rect only if wined3d_surface_map succeeds

by Henri Verbeet

On 21 October 2013 13:52, Lasse Rasinen <lrasinen(a)iki.fi> wrote: > On 21.10.2013, at 14.46, Henri Verbeet wrote: >> This test fails for me on Windows 7: >> >> device.c:4029: Test failed: pBits changed on double lock. >> device.c:4030: Test failed: Pitch changed on double lock. > > So on one W7 computer the struct gets cleared, on another it is kept. > Is that on your own machine, or did I miss those results? > Any advice on how to continue? For my use case, either solution will work. > If the results here really are inconsistent between machines, and no application cares, you can probably just drop this patch. On the other hand, if applications expect e.g. either NULL, or the original value, you could instead write the test as "ok(!locked_rect.pBits || locked_rect.pBits == (void *)0xdeadbeef, ...);" and add an appropriate comment.

Oct. 21, 2013

Re: [02/02] d3d8: update locked_rect only if wined3d_surface_map succeeds

by Lasse Rasinen

On 21.10.2013, at 14.46, Henri Verbeet wrote: > On 21 October 2013 10:47, Lasse Rasinen <lrasinen(a)iki.fi> wrote: >> diff --git a/dlls/d3d8/tests/device.c b/dlls/d3d8/tests/device.c >> index 7932a7f..52cf27a 100644 >> --- a/dlls/d3d8/tests/device.c >> +++ b/dlls/d3d8/tests/device.c >> @@ -4022,8 +4022,12 @@ static void test_lockrect_invalid(void) >> >> hr = IDirect3DSurface8_LockRect(surface, &locked_rect, NULL, 0); >> ok(SUCCEEDED(hr), "Failed to lock surface with rect NULL, hr %#x.\n", hr); >> + locked_rect.pBits = 0xdeadbeef; >> + locked_rect.Pitch = 1; >> hr = IDirect3DSurface8_LockRect(surface, &locked_rect, NULL, 0); >> ok(hr == D3DERR_INVALIDCALL, "Got unexpected hr %#x.\n", hr); >> + ok(locked_rect.pBits == 0xdeadbeef, "pBits changed on double lock.\n"); >> + ok(locked_rect.Pitch == 1, "Pitch changed on double lock.\n"); >> hr = IDirect3DSurface8_UnlockRect(surface); >> ok(SUCCEEDED(hr), "Failed to unlock surface, hr %#x.\n", hr); >> > This test fails for me on Windows 7: > > device.c:4029: Test failed: pBits changed on double lock. > device.c:4030: Test failed: Pitch changed on double lock. So on one W7 computer the struct gets cleared, on another it is kept. Any advice on how to continue? For my use case, either solution will work. > As an aside, if you had written the messages as "Got unexpected pBits > %p.\n" and "Got unexpected Pitch %d.\n", you would have gotten the > following output instead: > > device.c:4029: Test failed: Got unexpected pBits 00000000. > device.c:4030: Test failed: Got unexpected Pitch 0. Advice taken.

Oct. 21, 2013

Re: [01/02] d3d9: update locked_rect only if wined3d_surface_map succeeds

by Henri Verbeet

On 21 October 2013 10:46, Lasse Rasinen <lrasinen(a)iki.fi> wrote: > diff --git a/dlls/d3d9/tests/device.c b/dlls/d3d9/tests/device.c > index 02b4174..51835c8 100644 > --- a/dlls/d3d9/tests/device.c > +++ b/dlls/d3d9/tests/device.c > @@ -5402,8 +5402,12 @@ static void test_lockrect_invalid(void) > > hr = IDirect3DSurface9_LockRect(surface, &locked_rect, NULL, 0); > ok(SUCCEEDED(hr), "Failed to lock surface with rect NULL, hr %#x.\n", hr); > + locked_rect.pBits = 0xdeadbeef; > + locked_rect.Pitch = 1; > hr = IDirect3DSurface9_LockRect(surface, &locked_rect, NULL, 0); > ok(hr == D3DERR_INVALIDCALL, "Got unexpected hr %#x.\n", hr); > + ok(locked_rect.pBits == 0xdeadbeef, "pBits changed on double lock.\n"); > + ok(locked_rect.Pitch == 1, "Pitch changed on double lock.\n"); > hr = IDirect3DSurface9_UnlockRect(surface); > ok(SUCCEEDED(hr), "Failed to unlock surface, hr %#x.\n", hr); > This introduces warnings: device.c: In function ‘test_lockrect_invalid’: device.c:5405:23: warning: assignment makes pointer from integer without a cast [enabled by default] device.c:5409:26: warning: comparison between pointer and integer [enabled by default] Also applies to the d3d8 test.

Oct. 21, 2013

Re: [02/02] d3d8: update locked_rect only if wined3d_surface_map succeeds

by Henri Verbeet

On 21 October 2013 10:47, Lasse Rasinen <lrasinen(a)iki.fi> wrote: > diff --git a/dlls/d3d8/tests/device.c b/dlls/d3d8/tests/device.c > index 7932a7f..52cf27a 100644 > --- a/dlls/d3d8/tests/device.c > +++ b/dlls/d3d8/tests/device.c > @@ -4022,8 +4022,12 @@ static void test_lockrect_invalid(void) > > hr = IDirect3DSurface8_LockRect(surface, &locked_rect, NULL, 0); > ok(SUCCEEDED(hr), "Failed to lock surface with rect NULL, hr %#x.\n", hr); > + locked_rect.pBits = 0xdeadbeef; > + locked_rect.Pitch = 1; > hr = IDirect3DSurface8_LockRect(surface, &locked_rect, NULL, 0); > ok(hr == D3DERR_INVALIDCALL, "Got unexpected hr %#x.\n", hr); > + ok(locked_rect.pBits == 0xdeadbeef, "pBits changed on double lock.\n"); > + ok(locked_rect.Pitch == 1, "Pitch changed on double lock.\n"); > hr = IDirect3DSurface8_UnlockRect(surface); > ok(SUCCEEDED(hr), "Failed to unlock surface, hr %#x.\n", hr); > This test fails for me on Windows 7: device.c:4029: Test failed: pBits changed on double lock. device.c:4030: Test failed: Pitch changed on double lock. As an aside, if you had written the messages as "Got unexpected pBits %p.\n" and "Got unexpected Pitch %d.\n", you would have gotten the following output instead: device.c:4029: Test failed: Got unexpected pBits 00000000. device.c:4030: Test failed: Got unexpected Pitch 0.

Oct. 21, 2013

Re: winemac: Add registry settings to make Option keys send Alt rather than accessing additional characters from the keyboard layout.

by Phil Krylov

Hello, On Mon, Oct 21, 2013 at 6:47 AM, Ken Thomases <ken(a)codeweavers.com> wrote: > On Oct 10, 2013, at 3:11 AM, Phil Krylov wrote: > >> Every time I press Cmd-Space to switch keyboard layouts, Wine >> activates menu as if I would have pressed Alt, so I have to press >> Command once again to exit it. It does not happen in Windows, though, >> when I use Alt-Shift to switch layouts, so the real problem is not >> related to Alt interpretation of Cmd, but to incorrect emulation of >> Windows behaviour when a keyboard layout switch hotkey is pressed. > > Does the attached patch help? Yes it does, thanks! Although the menu still blinks momentarily when I release Command. > By the way, you should file a bug report about this issue so that it doesn't get lost. Yes I know, but I always want to examine a bug deeper before reporting, providing a patch if possible, and had no time to do it yet. -- Ph.

Oct. 21, 2013

Re: [03/23] kernel32/tests: Fix console tests compilation with __WINESRC__ defined.

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://newtestbot.winehq.org/JobDetails.pl?Key=2889 Your paranoid android. === w864 (32 bit console) === console.c:1113: Test failed: Expected OpenConsoleW to return INVALID_HANDLE_VALUE for index 18, got 00000138 console.c:1113: Test failed: Expected OpenConsoleW to return INVALID_HANDLE_VALUE for index 20, got 0000013C console.c:1113: Test failed: Expected OpenConsoleW to return INVALID_HANDLE_VALUE for index 21, got 0000014C console.c:1113: Test failed: Expected OpenConsoleW to return INVALID_HANDLE_VALUE for index 22, got 00000148 console.c:1113: Test failed: Expected OpenConsoleW to return INVALID_HANDLE_VALUE for index 23, got 00000144 console.c:1113: Test failed: Expected OpenConsoleW to return INVALID_HANDLE_VALUE for index 24, got 00000150 console.c:1113: Test failed: Expected OpenConsoleW to return INVALID_HANDLE_VALUE for index 25, got 00000154 console.c:1113: Test failed: Expected OpenConsoleW to return INVALID_HANDLE_VALUE for index 26, got 00000158 console.c:1113: Test failed: Expected OpenConsoleW to return INVALID_HANDLE_VALUE for index 28, got 0000015C console.c:1113: Test failed: Expected OpenConsoleW to return INVALID_HANDLE_VALUE for index 29, got 00000160 console.c:1113: Test failed: Expected OpenConsoleW to return INVALID_HANDLE_VALUE for index 30, got 00000164 console.c:1113: Test failed: Expected OpenConsoleW to return INVALID_HANDLE_VALUE for index 31, got 00000168 console.c:1113: Test failed: Expected OpenConsoleW to return INVALID_HANDLE_VALUE for index 32, got 0000016C console.c:1113: Test failed: Expected OpenConsoleW to return INVALID_HANDLE_VALUE for index 33, got 00000170 console.c:1421: Test failed: [13] Expected output count to be 0, got 1987557047 console.c:1421: Test failed: [15] Expected output count to be 0, got 1987557047 console.c:1421: Test failed: [18] Expected output count to be 3735928559, got 1987557047 console.c:1664: Test failed: [13] Expected output count to be 0, got 1987557047 console.c:1664: Test failed: [15] Expected output count to be 0, got 1987557047 console.c:1664: Test failed: [18] Expected output count to be 3735928559, got 1987557047 === w864 (64 bit console) === console.c:1113: Test failed: Expected OpenConsoleW to return INVALID_HANDLE_VALUE for index 18, got 0000000000000054 console.c:1113: Test failed: Expected OpenConsoleW to return INVALID_HANDLE_VALUE for index 20, got 0000000000000058 console.c:1113: Test failed: Expected OpenConsoleW to return INVALID_HANDLE_VALUE for index 23, got 0000000000000060

Oct. 21, 2013

Re: server: Implement job objects (try 3)

by Alexandre Julliard

Andrew Cook <ariscop(a)gmail.com> writes: > It's been another 3 weeks with zero response. You keep sending more and more versions of the same patches, so it seems clear that this stuff is not ready yet. -- Alexandre Julliard julliard(a)winehq.org

Oct. 21, 2013

Re: [02/23] kernel32/tests: Fix file change notification tests compilation with __WINESRC__ defined.

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://newtestbot.winehq.org/JobDetails.pl?Key=2888 Your paranoid android. === wvista (32 bit change) === change.c:81: Test failed: Missed notification

Oct. 21, 2013

Re: Clang Static analysis

by Ken Thomases

On Oct 13, 2013, at 11:38 AM, C.W. Betts wrote: > I have been doing a Clang static analysis of Wine on OS X using the one provided at http://clang-analyzer.llvm.org and storing the results on my PogoPlug drive. If someone wants to see the results, please tell me and I'll set up your e-mail. You will need a free PogoPlug account to view them. While the contents are zipped, they expand to about 1.2 GB. They are displayed as basic HTML pages, so you don't need anything special other than a web browser to see the results. > > Or you could click on this link for the analysis of 1.7.4: http://ppl.ug/ND-7PZ3cSzM/ Thanks for these. I've sent 3 patches for leaks it found. Unfortunately, the rate of false positives is pretty bad. I looked at about 25 of the reports and these 3 were the only ones that were real problems. For a few of them, I could tweak the code to help the analyzer understand it, but I don't think we want such patches in the project. :-/ Cheers, Ken

Oct. 21, 2013

Re: winemac: Add registry settings to make Option keys send Alt rather than accessing additional characters from the keyboard layout.

by Ken Thomases

On Oct 10, 2013, at 3:11 AM, Phil Krylov wrote: > Every time I press Cmd-Space to switch keyboard layouts, Wine > activates menu as if I would have pressed Alt, so I have to press > Command once again to exit it. It does not happen in Windows, though, > when I use Alt-Shift to switch layouts, so the real problem is not > related to Alt interpretation of Cmd, but to incorrect emulation of > Windows behaviour when a keyboard layout switch hotkey is pressed. Does the attached patch help? By the way, you should file a bug report about this issue so that it doesn't get lost. Regards, Ken

Oct. 21, 2013

Re: shell32: Avoid leaks and add parameter checks in SHCreateShellFolderView[Ex]. (try 2)

by Thomas Faber

shlfolder.c:229: this is the last test seen before the exception Unrelated to my changes. The new tests succeed in Win8 x64. On 2013-10-20 22:28, Marvin wrote: > Hi, > > While running your changed tests on Windows, I think I found new failures. > Being a bot and all I'm not very good at pattern recognition, so I might be > wrong, but could you please double-check? > Full results can be found at > https://newtestbot.winehq.org/JobDetails.pl?Key=2885 > > Your paranoid android. > > > === w864 (64 bit shlfolder) === > shlfolder: unhandled exception c0000005 at 000007F851EBABDC >

Oct. 20, 2013

Re: shell32: Avoid leaks and add parameter checks in SHCreateShellFolderView[Ex]. (try 2)

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://newtestbot.winehq.org/JobDetails.pl?Key=2885 Your paranoid android. === w864 (64 bit shlfolder) === shlfolder: unhandled exception c0000005 at 000007F851EBABDC

Oct. 20, 2013

Re: shell32: Avoid leaks and add parameter checks in SHCreateShellFolderView[Ex].

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://newtestbot.winehq.org/JobDetails.pl?Key=2880 Your paranoid android. === w864 (64 bit shlfolder) === shlfolder: unhandled exception c0000005 at 000007F851EBABDC

Oct. 20, 2013

Re: shell32: Avoid leaks and add parameter checks in SHCreateShellFolderView[Ex].

by Nikolay Sivov

On 10/20/2013 21:01, Thomas Faber wrote: > + if (0) > + { > + // crash on win7 > + pSHCreateShellFolderViewEx(NULL, NULL); > + pSHCreateShellFolderViewEx(NULL, &psv); > + pSHCreateShellFolderViewEx(&csfv, NULL); > + } Please no cpp comments. > + MAKEFUNC_ORD(SHCreateShellFolderViewEx, 174); > + MAKEFUNC_ORD(SHCreateShellFolderView, 256); These call are exported by name at least on XP, probably 2000 too, so it makes no sense to use ordinals here. > + if (!pSHCreateShellFolderView || !pSHCreateShellFolderViewEx) > + { > + win_skip("SHCreateShellFolderView or SHCreateShellFolderViewEx missing.\n"); > + return; > + } I don't think it's really possible to have *Ex version without non-Ex one. > + hr = SHGetDesktopFolder(&desktop); > + ok(hr == S_OK, "got (0x%08x)\n", hr); > + if (FAILED(hr)) > + { > + skip("No desktop folder\n"); > + return; > + } It's not going to fail, so a ok() test is enough. > + memset(&sfvc, 0, sizeof(sfvc)); > + sfvc.cbSize = sizeof(sfvc); > + sfvc.pshf = desktop; > + psv = (void *)0xdeadbeef; > + hr = pSHCreateShellFolderView(&sfvc, &psv); > + ok(hr == S_OK, "Got 0x%08x\n", hr); > + ok(psv != NULL, "psv = %p\n", psv); > + if (psv && psv != (void *)0xdeadbeef) > + { > + refCount = IShellView_Release(psv); > + ok(refCount == 0, "refCount = %u\n", refCount); > + } It's simpler than that. Set 'psv' to NULL and test for it being set after a call. > + test_SHCreateShellFolderView(); You're testing two calls here, so they probably deserve two separate test functions.

Oct. 20, 2013

Re: shell32/tests: Use BOOL type where appropriate

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://newtestbot.winehq.org/JobDetails.pl?Key=2879 Your paranoid android. === wxppro (32 bit shlexec) === shlexec.c:1197: Test failed: expected 1 args, got 4 shlexec.c:1538: Test failed: argvA4 expected 'C:\DOCUME~1\winetest\LOCALS~1\Temp\wt1.tmp\test file.shlexec', got 'C:\DOCUME~1\winetest\LOCALS~1\Temp\wt1.tmp\TESTFI~1.SHL' shlexec.c:1538: Test failed: argvA4 expected 'C:\DOCUME~1\winetest\LOCALS~1\Temp\wt1.tmp\test file.shlexec.', got 'C:\DOCUME~1\winetest\LOCALS~1\Temp\wt1.tmp\TESTFI~1.SHL' shlexec.c:1538: Test failed: argvA4 expected 'C:\DOCUME~1\winetest\LOCALS~1\Temp\wt1.tmp\%nasty% $file.shlexec', got 'C:\DOCUME~1\winetest\LOCALS~1\Temp\wt1.tmp\%NASTY~1.SHL' shlexec.c:1538: Test failed: argvA4 expected 'C:/DOCUME~1/winetest/LOCALS~1/Temp/wt1.tmp/test file.shlexec', got 'C:\DOCUME~1\winetest\LOCALS~1\Temp\wt1.tmp\TESTFI~1.SHL' shlexec.c:1538: Test failed: argvA4 expected 'C:\DOCUME~1\winetest\LOCALS~1\Temp\wt1.tmp\test file.noassoc.shlexec', got 'C:\DOCUME~1\winetest\LOCALS~1\Temp\wt1.tmp\TESTFI~2.SHL' shlexec.c:1538: Test failed: argvA4 expected 'C:\DOCUME~1\winetest\LOCALS~1\Temp\wt1.tmp\masked file.shlexec', got 'C:\DOCUME~1\winetest\LOCALS~1\Temp\wt1.tmp\MASKED~1.SHL' shlexec.c:1538: Test failed: argvA4 expected 'C:\DOCUME~1\winetest\LOCALS~1\Temp\wt1.tmp\masked file.shlexec', got 'C:\DOCUME~1\winetest\LOCALS~1\Temp\wt1.tmp\MASKED~1.SHL' shlexec.c:1631: Test failed: argvA4 expected 'C:\DOCUME~1\winetest\LOCALS~1\Temp\wt1.tmp\test file.shlexec', got 'C:\DOCUME~1\winetest\LOCALS~1\Temp\wt1.tmp\TESTFI~1.SHL' shlexec.c:1939: Test failed: argvA4 expected 'C:\Documents and Settings\winetest\Local Settings\Temp\wt1.tmp\test file.shlexec', got 'C:\DOCUME~1\winetest\LOCALS~1\Temp\wt1.tmp\TESTFI~1.SHL' shlexec.c:1947: Test failed: argvA4 expected 'C:\Documents and Settings\winetest\Local Settings\Temp\wt1.tmp\test file.shlexec', got 'C:\DOCUME~1\winetest\LOCALS~1\Temp\wt1.tmp\TESTFI~1.SHL' shlexec.c:2250: Test failed: argvA3 expected 'C:\DOCUME~1\winetest\LOCALS~1\Temp\wt1.tmp\test file.sde', got 'C:\DOCUME~1\winetest\LOCALS~1\Temp\wt1.tmp\TESTFI~1.SDE' shlexec.c:2250: Test failed: argvA3 expected 'C:\DOCUME~1\winetest\LOCALS~1\Temp\wt1.tmp\test file.sde', got 'C:\DOCUME~1\winetest\LOCALS~1\Temp\wt1.tmp\TESTFI~1.SDE' shlexec.c:2240: Test failed: argcA expected 5, but got 4 === wvista (32 bit shlexec) === shlexec.c:137: Test failed: ShellExecute(file="C:\Users\winetest\AppData\Local\Temp\wtC34E.tmp\test file.noassoc") WaitForSingleObject returned 258 shlexec.c:1506: Test failed: ShellExecute(file="C:\Users\winetest\AppData\Local\Temp\wtC34E.tmp\test file.noassoc") failed: rc=33 err=2 shlexec.c:1530: Test failed: argvA3 expected 'Open', but key not found or empty shlexec.c:1538: Test failed: argvA4 expected 'C:\Users\winetest\AppData\Local\Temp\wtC34E.tmp\test file.noassoc', but key not found or empty === w2008s64 (32 bit shlexec) === shlexec.c:1538: Test failed: argvA4 expected 'C:/Users/ADMINI~1/AppData/Local/Temp/wt9F4A.tmp/test file.shlexec', got 'C:\Users\Administrator\AppData\Local\Temp\wt9F4A.tmp\test file.shlexec' shlexec.c:2606: Test failed: longPath expected 'C:\Users\ADMINI~1\AppData\Local\Temp\wt9F4A.tmp\test2.exe', got 'C:\Users\Administrator\AppData\Local\Temp\wt9F4A.tmp\test2.exe' shlexec.c:2619: Test failed: longPath expected 'C:\Users\ADMINI~1\AppData\Local\Temp\wt9F4A.tmp\test2.exe', got 'C:\Users\Administrator\AppData\Local\Temp\wt9F4A.tmp\test2.exe' shlexec.c:2631: Test failed: longPath expected 'C:\Users\ADMINI~1\AppData\Local\Temp\wt9F4A.tmp\test2.exe', got 'C:\Users\Administrator\AppData\Local\Temp\wt9F4A.tmp\test2.exe' === w864 (32 bit shlexec) === shlexec.c:137: Test failed: ShellExecute(verb="", file="C:\Users\winetest\AppData\Local\Temp\wt4E1F.tmp\test file.noassoc") WaitForSingleObject returned 258 shlexec.c:137: Test failed: ShellExecute(file="C:\Users\winetest\AppData\Local\Temp\wt4E1F.tmp\test file.noassoc") WaitForSingleObject returned 258 shlexec.c:1506: Test failed: ShellExecute(file="C:\Users\winetest\AppData\Local\Temp\wt4E1F.tmp\test file.noassoc") failed: rc=33 err=2 shlexec.c:1538: Test failed: argvA4 expected 'C:\Users\winetest\AppData\Local\Temp\wt4E1F.tmp\test file.noassoc', but key not found or empty shlexec.c:137: Test failed: ShellExecute(verb="", file="C:\Users\winetest\AppData\Local\Temp\wt4E1F.tmp\test file.shlexec.noassoc") WaitForSingleObject returned 258 shlexec.c:137: Test failed: ShellExecute(file="C:\Users\winetest\AppData\Local\Temp\wt4E1F.tmp\test file.shlexec.noassoc") WaitForSingleObject returned 258 shlexec.c:1506: Test failed: ShellExecute(file="C:\Users\winetest\AppData\Local\Temp\wt4E1F.tmp\test file.shlexec.noassoc") failed: rc=33 err=2 shlexec.c:1538: Test failed: argvA4 expected 'C:\Users\winetest\AppData\Local\Temp\wt4E1F.tmp\test file.shlexec.noassoc', but key not found or empty shlexec.c:137: Test failed: ShellExecute(verb="", file="C:\Users\winetest\AppData\Local\Temp\wt4E1F.tmp\test file.noassoc", params="shlexec "C:\Users\winetest\AppData\Local\Temp\wt4E1F.tmp\wt4E20.tmp" Exec") WaitForSingleObject returned 258 shlexec.c:137: Test failed: ShellExecute(file="C:\Users\winetest\AppData\Local\Temp\wt4E1F.tmp\test file.noassoc", params="shlexec "C:\Users\winetest\AppData\Local\Temp\wt4E1F.tmp\wt4E20.tmp" Exec") WaitForSingleObject returned 258 shlexec.c:2059: Test failed: ShellExecute(file="C:\Users\winetest\AppData\Local\Temp\wt4E1F.tmp\test file.noassoc", params="shlexec "C:\Users\winetest\AppData\Local\Temp\wt4E1F.tmp\wt4E20.tmp" Exec") succeeded: rc=42 === w2008s64 (64 bit shlexec) === shlexec.c:1538: Test failed: argvA4 expected 'C:/Users/ADMINI~1/AppData/Local/Temp/wtDF85.tmp/test file.shlexec', got 'C:\Users\Administrator\AppData\Local\Temp\wtDF85.tmp\test file.shlexec' shlexec.c:2606: Test failed: longPath expected 'C:\Users\ADMINI~1\AppData\Local\Temp\wtDF85.tmp\test2.exe', got 'C:\Users\Administrator\AppData\Local\Temp\wtDF85.tmp\test2.exe' shlexec.c:2619: Test failed: longPath expected 'C:\Users\ADMINI~1\AppData\Local\Temp\wtDF85.tmp\test2.exe', got 'C:\Users\Administrator\AppData\Local\Temp\wtDF85.tmp\test2.exe' shlexec.c:2631: Test failed: longPath expected 'C:\Users\ADMINI~1\AppData\Local\Temp\wtDF85.tmp\test2.exe', got 'C:\Users\Administrator\AppData\Local\Temp\wtDF85.tmp\test2.exe' === w864 (64 bit shlexec) === shlexec.c:137: Test failed: ShellExecute(verb="", file="C:\Users\winetest\AppData\Local\Temp\wt9DA5.tmp\test file.noassoc") WaitForSingleObject returned 258 shlexec.c:137: Test failed: ShellExecute(file="C:\Users\winetest\AppData\Local\Temp\wt9DA5.tmp\test file.noassoc") WaitForSingleObject returned 258 shlexec.c:1506: Test failed: ShellExecute(file="C:\Users\winetest\AppData\Local\Temp\wt9DA5.tmp\test file.noassoc") failed: rc=33 err=2 shlexec.c:1538: Test failed: argvA4 expected 'C:\Users\winetest\AppData\Local\Temp\wt9DA5.tmp\test file.noassoc', but key not found or empty shlexec.c:137: Test failed: ShellExecute(verb="", file="C:\Users\winetest\AppData\Local\Temp\wt9DA5.tmp\test file.shlexec.noassoc") WaitForSingleObject returned 258 shlexec.c:137: Test failed: ShellExecute(file="C:\Users\winetest\AppData\Local\Temp\wt9DA5.tmp\test file.shlexec.noassoc") WaitForSingleObject returned 258 shlexec.c:1506: Test failed: ShellExecute(file="C:\Users\winetest\AppData\Local\Temp\wt9DA5.tmp\test file.shlexec.noassoc") failed: rc=33 err=2 shlexec.c:1538: Test failed: argvA4 expected 'C:\Users\winetest\AppData\Local\Temp\wt9DA5.tmp\test file.shlexec.noassoc', but key not found or empty shlexec.c:137: Test failed: ShellExecute(verb="", file="C:\Users\winetest\AppData\Local\Temp\wt9DA5.tmp\test file.noassoc", params="shlexec "C:\Users\winetest\AppData\Local\Temp\wt9DA5.tmp\wt9DA6.tmp" Exec") WaitForSingleObject returned 258 shlexec.c:137: Test failed: ShellExecute(file="C:\Users\winetest\AppData\Local\Temp\wt9DA5.tmp\test file.noassoc", params="shlexec "C:\Users\winetest\AppData\Local\Temp\wt9DA5.tmp\wt9DA6.tmp" Exec") WaitForSingleObject returned 258 shlexec.c:2059: Test failed: ShellExecute(file="C:\Users\winetest\AppData\Local\Temp\wt9DA5.tmp\test file.noassoc", params="shlexec "C:\Users\winetest\AppData\Local\Temp\wt9DA5.tmp\wt9DA6.tmp" Exec") succeeded: rc=42 === w864 (64 bit shlfolder) === shlfolder: unhandled exception c0000005 at 000007F851EBABDC

Oct. 19, 2013

Re: server: Implement job objects (try 2)

by Andrew Cook

On 17/10/13 15:11, Andrew Cook wrote: > --- > dlls/kernel32/tests/process.c | 172 ++++++++++++++++++++++- > dlls/ntdll/sync.c | 127 +++++++++++++++-- > server/process.c | 313 > ++++++++++++++++++++++++++++++++++++++++++ > server/process.h | 3 + > server/protocol.def | 33 +++++ > 5 files changed, 636 insertions(+), 12 deletions(-) > > Is there something wrong with this patch?

Oct. 18, 2013

Re: [1/2] gdiplus: Reimplement GdipCloneBitmapArea without using GdipBitmapLockBits.

by Vincent Povirk

This series looks good to me.

Oct. 18, 2013

Re: [PATCH 2/2] ole32: Pass last_unlock_releases to IExternalConnection_ReleaseConnection().

by Alexandre Julliard

Huw Davies <huw(a)codeweavers.com> writes: > --- > dlls/ole32/stubmanager.c | 2 +- > dlls/ole32/tests/marshal.c | 2 -- > 2 files changed, 1 insertion(+), 3 deletions(-) It breaks the tests: ../../../tools/runtest -q -P wine -T ../../.. -M oleaut32.dll -p oleaut32_test.exe.so tmarshal.c && touch tmarshal.ok tmarshal.c:191: Test failed: fLastReleaseCloses = 0, expected 1 tmarshal.c:191: Test failed: fLastReleaseCloses = 0, expected 1 make: *** [tmarshal.ok] Error 2 -- Alexandre Julliard julliard(a)winehq.org

Oct. 18, 2013

Re: [PATCH 1/2] ole32/tests: Add tests to show that CoLockObjectExternal() calls ReleaseConnection() with the appropriate va

by Huw Davies

On Fri, Oct 18, 2013 at 07:13:06AM -0500, Marvin wrote: > Hi, > > While running your changed tests on Windows, I think I found new failures. > Being a bot and all I'm not very good at pattern recognition, so I might be > wrong, but could you please double-check? > Full results can be found at > https://newtestbot.winehq.org/JobDetails.pl?Key=2863 Hi Marvin, Looks like you had the same problem running a NOP test: https://newtestbot.winehq.org/JobDetails.pl?Key=2866 The wxppro failure is strange as you seem to be trying to run test 'and'. Huw.

Oct. 18, 2013

Re: [PATCH 2/2] ole32: Pass last_unlock_releases to IExternalConnection_ReleaseConnection().

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://newtestbot.winehq.org/JobDetails.pl?Key=2864 Your paranoid android. === wxppro (32 bit marshal) === marshal.c:2803: Test failed: wait timed out marshal.c:2807: Test failed: CoCreateInstance failed with error 0x80040154 marshal: unhandled exception c0000005 at 00419C4C === w864 (32 bit marshal) === marshal.c:3064: Test failed: info->cbSize was -1799139958 instead of 48 marshal.c:3065: Test failed: info->dwServerPid was 0x674 instead of 0xba8 marshal.c:3081: Test failed: info->cbSize was -1799139958 instead of 48 marshal.c:3082: Test failed: info->dwServerPid was 0x674 instead of 0xba8 marshal.c:3119: Test failed: info->cbSize was -1799139958 instead of 48 marshal.c:3120: Test failed: info->dwServerPid was 0x674 instead of 0xba8 marshal.c:3137: Test failed: info->cbSize was -1799139958 instead of 48 marshal.c:3138: Test failed: info->dwServerPid was 0x674 instead of 0xba8 marshal.c:3101: Test failed: info->cbSize was -1799139958 instead of 48 marshal.c:3102: Test failed: info->dwServerPid was 0x674 instead of 0xba8 marshal.c:3064: Test failed: info->cbSize was -1799139958 instead of 48 marshal.c:3065: Test failed: info->dwServerPid was 0x674 instead of 0xba8 marshal.c:3081: Test failed: info->cbSize was -1799139958 instead of 48 marshal.c:3082: Test failed: info->dwServerPid was 0x674 instead of 0xba8 marshal.c:3119: Test failed: info->cbSize was -1799139958 instead of 48 marshal.c:3120: Test failed: info->dwServerPid was 0x674 instead of 0xba8 marshal.c:3137: Test failed: info->cbSize was -1799139958 instead of 48 marshal.c:3138: Test failed: info->dwServerPid was 0x674 instead of 0xba8 marshal.c:3101: Test failed: info->cbSize was -1799139958 instead of 48 marshal.c:3102: Test failed: info->dwServerPid was 0x674 instead of 0xba8 marshal.c:3064: Test failed: info->cbSize was -1799139958 instead of 48 marshal.c:3065: Test failed: info->dwServerPid was 0x674 instead of 0xba8 marshal.c:3081: Test failed: info->cbSize was -1799139958 instead of 48 marshal.c:3082: Test failed: info->dwServerPid was 0x674 instead of 0xba8 marshal.c:3119: Test failed: info->cbSize was -1799139958 instead of 48 marshal.c:3120: Test failed: info->dwServerPid was 0x674 instead of 0xba8 marshal.c:3137: Test failed: info->cbSize was -1799139958 instead of 48 marshal.c:3138: Test failed: info->dwServerPid was 0x674 instead of 0xba8 marshal.c:3101: Test failed: info->cbSize was -1799139958 instead of 48 marshal.c:3102: Test failed: info->dwServerPid was 0x674 instead of 0xba8 === w864 (64 bit marshal) === marshal.c:3064: Test failed: info->cbSize was -588349091 instead of 56 marshal.c:3065: Test failed: info->dwServerPid was 0x900 instead of 0xad0 marshal.c:3081: Test failed: info->cbSize was -588349091 instead of 56 marshal.c:3082: Test failed: info->dwServerPid was 0x900 instead of 0xad0 marshal.c:3119: Test failed: info->cbSize was -588349091 instead of 56 marshal.c:3120: Test failed: info->dwServerPid was 0x900 instead of 0xad0 marshal.c:3137: Test failed: info->cbSize was -588349091 instead of 56 marshal.c:3138: Test failed: info->dwServerPid was 0x900 instead of 0xad0 marshal.c:3101: Test failed: info->cbSize was -588349091 instead of 56 marshal.c:3102: Test failed: info->dwServerPid was 0x900 instead of 0xad0 marshal.c:3064: Test failed: info->cbSize was -588349091 instead of 56 marshal.c:3065: Test failed: info->dwServerPid was 0x900 instead of 0xad0 marshal.c:3081: Test failed: info->cbSize was -588349091 instead of 56 marshal.c:3082: Test failed: info->dwServerPid was 0x900 instead of 0xad0 marshal.c:3119: Test failed: info->cbSize was -588349091 instead of 56 marshal.c:3120: Test failed: info->dwServerPid was 0x900 instead of 0xad0 marshal.c:3137: Test failed: info->cbSize was -588349091 instead of 56 marshal.c:3138: Test failed: info->dwServerPid was 0x900 instead of 0xad0 marshal.c:3101: Test failed: info->cbSize was -588349091 instead of 56 marshal.c:3102: Test failed: info->dwServerPid was 0x900 instead of 0xad0 marshal.c:3064: Test failed: info->cbSize was -588349091 instead of 56 marshal.c:3065: Test failed: info->dwServerPid was 0x900 instead of 0xad0 marshal.c:3081: Test failed: info->cbSize was -588349091 instead of 56 marshal.c:3082: Test failed: info->dwServerPid was 0x900 instead of 0xad0 marshal.c:3119: Test failed: info->cbSize was -588349091 instead of 56 marshal.c:3120: Test failed: info->dwServerPid was 0x900 instead of 0xad0 marshal.c:3137: Test failed: info->cbSize was -588349091 instead of 56 marshal.c:3138: Test failed: info->dwServerPid was 0x900 instead of 0xad0 marshal.c:3101: Test failed: info->cbSize was -588349091 instead of 56 marshal.c:3102: Test failed: info->dwServerPid was 0x900 instead of 0xad0

Oct. 18, 2013

Re: wined3d: Initialize map_desc in wined3d_surface_map

by Stefan Dösinger

> >> === w864 (32 bit device) === device.c:5409: Test failed: pBits not > >> cleared on double lock. device.c:5410: Test failed: Pitch not > >> cleared on double lock. device: unhandled exception c0000005 at > >> 742814C8 I've tested your tests on two of my Windows 7 machines, one with a Nvidia Geforce 650M, and another with an AMD X1600. Both behave just like the testbot. I guess this means your original implementation of just not touching the output locked_rect was correct all along. Volume::Lock clears pBits and both pitches on a failed lock in all failure cases (resource not lockable, misaligned box, already locked, otherwise incorrect box). I haven't tested d3d8 yet. As far as I can see surfaces keep locked_rect untouched in all error conditions. I also haven't tested Windows XP yet because my Visual Studio 2012 generated .exe files don't run there any more :-\ . Cheers, Stefan

Oct. 18, 2013

Re: [PATCH 1/2] ole32/tests: Add tests to show that CoLockObjectExternal() calls ReleaseConnection() with the appropriate va

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://newtestbot.winehq.org/JobDetails.pl?Key=2863 Your paranoid android. === wxppro (32 bit marshal) === marshal.c:2805: Test failed: wait timed out marshal.c:2809: Test failed: CoCreateInstance failed with error 0x80040154 marshal: unhandled exception c0000005 at 00419C8C === w864 (32 bit marshal) === marshal.c:3066: Test failed: info->cbSize was 1527466381 instead of 48 marshal.c:3067: Test failed: info->dwServerPid was 0xb68 instead of 0xa48 marshal.c:3083: Test failed: info->cbSize was 1527466381 instead of 48 marshal.c:3084: Test failed: info->dwServerPid was 0xb68 instead of 0xa48 marshal.c:3121: Test failed: info->cbSize was 1527466381 instead of 48 marshal.c:3122: Test failed: info->dwServerPid was 0xb68 instead of 0xa48 marshal.c:3139: Test failed: info->cbSize was 1527466381 instead of 48 marshal.c:3140: Test failed: info->dwServerPid was 0xb68 instead of 0xa48 marshal.c:3103: Test failed: info->cbSize was 1527466381 instead of 48 marshal.c:3104: Test failed: info->dwServerPid was 0xb68 instead of 0xa48 marshal.c:3066: Test failed: info->cbSize was 1527466381 instead of 48 marshal.c:3067: Test failed: info->dwServerPid was 0xb68 instead of 0xa48 marshal.c:3083: Test failed: info->cbSize was 1527466381 instead of 48 marshal.c:3084: Test failed: info->dwServerPid was 0xb68 instead of 0xa48 marshal.c:3121: Test failed: info->cbSize was 1527466381 instead of 48 marshal.c:3122: Test failed: info->dwServerPid was 0xb68 instead of 0xa48 marshal.c:3139: Test failed: info->cbSize was 1527466381 instead of 48 marshal.c:3140: Test failed: info->dwServerPid was 0xb68 instead of 0xa48 marshal.c:3103: Test failed: info->cbSize was 1527466381 instead of 48 marshal.c:3104: Test failed: info->dwServerPid was 0xb68 instead of 0xa48 marshal.c:3066: Test failed: info->cbSize was 1527466381 instead of 48 marshal.c:3067: Test failed: info->dwServerPid was 0xb68 instead of 0xa48 marshal.c:3083: Test failed: info->cbSize was 1527466381 instead of 48 marshal.c:3084: Test failed: info->dwServerPid was 0xb68 instead of 0xa48 marshal.c:3121: Test failed: info->cbSize was 1527466381 instead of 48 marshal.c:3122: Test failed: info->dwServerPid was 0xb68 instead of 0xa48 marshal.c:3139: Test failed: info->cbSize was 1527466381 instead of 48 marshal.c:3140: Test failed: info->dwServerPid was 0xb68 instead of 0xa48 marshal.c:3103: Test failed: info->cbSize was 1527466381 instead of 48 marshal.c:3104: Test failed: info->dwServerPid was 0xb68 instead of 0xa48 === w864 (64 bit marshal) === marshal.c:3066: Test failed: info->cbSize was -2120541113 instead of 56 marshal.c:3067: Test failed: info->dwServerPid was 0x9cc instead of 0x9ac marshal.c:3083: Test failed: info->cbSize was -2120541113 instead of 56 marshal.c:3084: Test failed: info->dwServerPid was 0x9cc instead of 0x9ac marshal.c:3121: Test failed: info->cbSize was -2120541113 instead of 56 marshal.c:3122: Test failed: info->dwServerPid was 0x9cc instead of 0x9ac marshal.c:3139: Test failed: info->cbSize was -2120541113 instead of 56 marshal.c:3140: Test failed: info->dwServerPid was 0x9cc instead of 0x9ac marshal.c:3103: Test failed: info->cbSize was -2120541113 instead of 56 marshal.c:3104: Test failed: info->dwServerPid was 0x9cc instead of 0x9ac marshal.c:3066: Test failed: info->cbSize was -2120541113 instead of 56 marshal.c:3067: Test failed: info->dwServerPid was 0x9cc instead of 0x9ac marshal.c:3083: Test failed: info->cbSize was -2120541113 instead of 56 marshal.c:3084: Test failed: info->dwServerPid was 0x9cc instead of 0x9ac marshal.c:3121: Test failed: info->cbSize was -2120541113 instead of 56 marshal.c:3122: Test failed: info->dwServerPid was 0x9cc instead of 0x9ac marshal.c:3139: Test failed: info->cbSize was -2120541113 instead of 56 marshal.c:3140: Test failed: info->dwServerPid was 0x9cc instead of 0x9ac marshal.c:3103: Test failed: info->cbSize was -2120541113 instead of 56 marshal.c:3104: Test failed: info->dwServerPid was 0x9cc instead of 0x9ac marshal.c:3066: Test failed: info->cbSize was -2120541113 instead of 56 marshal.c:3067: Test failed: info->dwServerPid was 0x9cc instead of 0x9ac marshal.c:3083: Test failed: info->cbSize was -2120541113 instead of 56 marshal.c:3084: Test failed: info->dwServerPid was 0x9cc instead of 0x9ac marshal.c:3121: Test failed: info->cbSize was -2120541113 instead of 56 marshal.c:3122: Test failed: info->dwServerPid was 0x9cc instead of 0x9ac marshal.c:3139: Test failed: info->cbSize was -2120541113 instead of 56 marshal.c:3140: Test failed: info->dwServerPid was 0x9cc instead of 0x9ac marshal.c:3103: Test failed: info->cbSize was -2120541113 instead of 56 marshal.c:3104: Test failed: info->dwServerPid was 0x9cc instead of 0x9ac

Oct. 18, 2013

Re: [PATCH 7/9] secur32: Cache certificate context instead of store in schannel handle.

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://newtestbot.winehq.org/JobDetails.pl?Key=2860 Your paranoid android. === w864 (32 bit schannel) === schannel.c:803: Test failed: cert != cert2

Oct. 18, 2013

Re: wintrust/tests: Compile with -D__WINESRC__

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://newtestbot.winehq.org/JobDetails.pl?Key=2850 Your paranoid android. === w864 (32 bit crypt) === crypt.c:289: Test failed: Expected success, got FALSE with 87 crypt.c:293: Test failed: Expected success, got FALSE with 87

Oct. 17, 2013

re: visual studio 2012 pdb support

by Dan Kegel

Hi Roman, it might help if you were to show tiny example programs that wine's pdb support doesn't handle, like I did at http://kegel.com/wine/valgrind/pdbdemo/ Ideally you'd file a new bug report at bugs.winehq.org for this. - Dan

Oct. 17, 2013

Re: winemac: Restore the window title when the window style is changed.

by Ken Thomases

On Oct 17, 2013, at 3:54 AM, Kevin Eaves wrote: > <cocoa_window.patch> Looks good to me. Thanks. Note that this fixes <http://bugs.winehq.org/show_bug.cgi?id=34472>. -Ken

Oct. 17, 2013

Re: [2/3] gdi32: Adjust fake bold outline font metrics.

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://newtestbot.winehq.org/JobDetails.pl?Key=2842 Your paranoid android. === wvista (32 bit font) === The test timed out

Oct. 17, 2013

Re: [1/3] gdi32/tests: Add tests for fake bold outline fonts.

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://newtestbot.winehq.org/JobDetails.pl?Key=2841 Your paranoid android. === wvista (32 bit font) === No test summary line found Failure running script in VM: network read timed out === w2008s64 (32 bit font) === Failure running script in VM: network read timed out

Oct. 17, 2013

Re: [2/2] msxml3: Set referrer header to container url

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://newtestbot.winehq.org/JobDetails.pl?Key=2837 Your paranoid android. === wxppro (32 bit httpreq) === httpreq.c:1700: Test failed: got response text L"<!DOCTYPE HTML PUBLIC \"-//IETF//DTD HTML 2.0//EN\">\n<html><head>\n<title>404 Not Found</title>\n</head><body>\n<h1>Not Found</h1>\n<p>The requested URL /tests/referer.php was not found on this server.</p>\n</body></html>\n" httpreq.c:1171: Test failed: unexpected call site_qi_IServiceProvider httpreq.c:1121: Test failed: unexpected call sp_queryservice_SID_SBindHost httpreq.c:1126: Test failed: unexpected call sp_queryservice_SID_SContainerDispatch_htmldoc2 httpreq.c:1131: Test failed: unexpected call sp_queryservice_SID_secmgr_htmldoc2 httpreq.c:305: Test failed: unexpected call htmldoc2_get_all httpreq.c:210: Test failed: unexpected call collection_get_length httpreq.c:498: Test failed: unexpected call htmldoc2_get_url httpreq.c:1174: Test failed: unexpected call site_qi_IXMLDOMDocument httpreq.c:1177: Test failed: unexpected call site_qi_IOleClientSite httpreq.c:1171: Test failed: unexpected call site_qi_IServiceProvider httpreq.c:1138: Test failed: unexpected call sp_queryservice_SID_secmgr_xmldomdoc httpreq.c:1126: Test failed: unexpected call sp_queryservice_SID_SContainerDispatch_htmldoc2 httpreq.c:1131: Test failed: unexpected call sp_queryservice_SID_secmgr_htmldoc2 httpreq.c:498: Test failed: unexpected call htmldoc2_get_url httpreq.c:1171: Test failed: unexpected call site_qi_IServiceProvider httpreq.c:1151: Test failed: unexpected request: sid {79eac9e4-baf9-11ce-8c82-00aa004ba90b}, riid {79eac9e4-baf9-11ce-8c82-00aa004ba90b} httpreq.c:1171: Test failed: unexpected call site_qi_IServiceProvider httpreq.c:1151: Test failed: unexpected request: sid {4f9f9fcb-e0f4-48eb-b7ab-fa2ea9365cb4}, riid {4f9f9fcb-e0f4-48eb-b7ab-fa2ea9365cb4} httpreq.c:1725: Test failed: got response text L"<!DOCTYPE HTML PUBLIC \"-//IETF//DTD HTML 2.0//EN\">\n<html><head>\n<title>404 Not Found</title>\n</head><body>\n<h1>Not Found</h1>\n<p>The requested URL /tests/referer.php was not found on this server.</p>\n</body></html>\n", expected L"http://test.winehq.org/" === wvista (32 bit httpreq) === httpreq.c:1700: Test failed: got response text L"<!DOCTYPE HTML PUBLIC \"-//IETF//DTD HTML 2.0//EN\">\n<html><head>\n<title>404 Not Found</title>\n</head><body>\n<h1>Not Found</h1>\n<p>The requested URL /tests/referer.php was not found on this server.</p>\n</body></html>\n" httpreq.c:1171: Test failed: unexpected call site_qi_IServiceProvider httpreq.c:1121: Test failed: unexpected call sp_queryservice_SID_SBindHost httpreq.c:1126: Test failed: unexpected call sp_queryservice_SID_SContainerDispatch_htmldoc2 httpreq.c:1131: Test failed: unexpected call sp_queryservice_SID_secmgr_htmldoc2 httpreq.c:305: Test failed: unexpected call htmldoc2_get_all httpreq.c:210: Test failed: unexpected call collection_get_length httpreq.c:498: Test failed: unexpected call htmldoc2_get_url httpreq.c:1174: Test failed: unexpected call site_qi_IXMLDOMDocument httpreq.c:1177: Test failed: unexpected call site_qi_IOleClientSite httpreq.c:1171: Test failed: unexpected call site_qi_IServiceProvider httpreq.c:1138: Test failed: unexpected call sp_queryservice_SID_secmgr_xmldomdoc httpreq.c:1126: Test failed: unexpected call sp_queryservice_SID_SContainerDispatch_htmldoc2 httpreq.c:1131: Test failed: unexpected call sp_queryservice_SID_secmgr_htmldoc2 httpreq.c:498: Test failed: unexpected call htmldoc2_get_url httpreq.c:1171: Test failed: unexpected call site_qi_IServiceProvider httpreq.c:1171: Test failed: unexpected call site_qi_IServiceProvider httpreq.c:1151: Test failed: unexpected request: sid {79eac9e4-baf9-11ce-8c82-00aa004ba90b}, riid {79eac9e4-baf9-11ce-8c82-00aa004ba90b} httpreq.c:1171: Test failed: unexpected call site_qi_IServiceProvider httpreq.c:1151: Test failed: unexpected request: sid {4f9f9fcb-e0f4-48eb-b7ab-fa2ea9365cb4}, riid {4f9f9fcb-e0f4-48eb-b7ab-fa2ea9365cb4} httpreq.c:1725: Test failed: got response text L"<!DOCTYPE HTML PUBLIC \"-//IETF//DTD HTML 2.0//EN\">\n<html><head>\n<title>404 Not Found</title>\n</head><body>\n<h1>Not Found</h1>\n<p>The requested URL /tests/referer.php was not found on this server.</p>\n</body></html>\n", expected L"http://test.winehq.org/" === w2008s64 (32 bit httpreq) === httpreq.c:1700: Test failed: got response text L"<!DOCTYPE HTML PUBLIC \"-//IETF//DTD HTML 2.0//EN\">\n<html><head>\n<title>404 Not Found</title>\n</head><body>\n<h1>Not Found</h1>\n<p>The requested URL /tests/referer.php was not found on this server.</p>\n</body></html>\n" httpreq.c:1171: Test failed: unexpected call site_qi_IServiceProvider httpreq.c:1121: Test failed: unexpected call sp_queryservice_SID_SBindHost httpreq.c:1126: Test failed: unexpected call sp_queryservice_SID_SContainerDispatch_htmldoc2 httpreq.c:1131: Test failed: unexpected call sp_queryservice_SID_secmgr_htmldoc2 httpreq.c:305: Test failed: unexpected call htmldoc2_get_all httpreq.c:210: Test failed: unexpected call collection_get_length httpreq.c:498: Test failed: unexpected call htmldoc2_get_url httpreq.c:1174: Test failed: unexpected call site_qi_IXMLDOMDocument httpreq.c:1177: Test failed: unexpected call site_qi_IOleClientSite httpreq.c:1171: Test failed: unexpected call site_qi_IServiceProvider httpreq.c:1138: Test failed: unexpected call sp_queryservice_SID_secmgr_xmldomdoc httpreq.c:1126: Test failed: unexpected call sp_queryservice_SID_SContainerDispatch_htmldoc2 httpreq.c:1131: Test failed: unexpected call sp_queryservice_SID_secmgr_htmldoc2 httpreq.c:498: Test failed: unexpected call htmldoc2_get_url httpreq.c:1171: Test failed: unexpected call site_qi_IServiceProvider httpreq.c:1171: Test failed: unexpected call site_qi_IServiceProvider httpreq.c:1151: Test failed: unexpected request: sid {79eac9e4-baf9-11ce-8c82-00aa004ba90b}, riid {79eac9e4-baf9-11ce-8c82-00aa004ba90b} httpreq.c:1171: Test failed: unexpected call site_qi_IServiceProvider httpreq.c:1151: Test failed: unexpected request: sid {4f9f9fcb-e0f4-48eb-b7ab-fa2ea9365cb4}, riid {4f9f9fcb-e0f4-48eb-b7ab-fa2ea9365cb4} httpreq.c:1725: Test failed: got response text L"<!DOCTYPE HTML PUBLIC \"-//IETF//DTD HTML 2.0//EN\">\n<html><head>\n<title>404 Not Found</title>\n</head><body>\n<h1>Not Found</h1>\n<p>The requested URL /tests/referer.php was not found on this server.</p>\n</body></html>\n", expected L"http://test.winehq.org/" === w7pro64 (32 bit httpreq) === httpreq.c:1700: Test failed: got response text L"<!DOCTYPE HTML PUBLIC \"-//IETF//DTD HTML 2.0//EN\">\n<html><head>\n<title>404 Not Found</title>\n</head><body>\n<h1>Not Found</h1>\n<p>The requested URL /tests/referer.php was not found on this server.</p>\n</body></html>\n" httpreq.c:1171: Test failed: unexpected call site_qi_IServiceProvider httpreq.c:1121: Test failed: unexpected call sp_queryservice_SID_SBindHost httpreq.c:1126: Test failed: unexpected call sp_queryservice_SID_SContainerDispatch_htmldoc2 httpreq.c:1131: Test failed: unexpected call sp_queryservice_SID_secmgr_htmldoc2 httpreq.c:305: Test failed: unexpected call htmldoc2_get_all httpreq.c:210: Test failed: unexpected call collection_get_length httpreq.c:498: Test failed: unexpected call htmldoc2_get_url httpreq.c:1174: Test failed: unexpected call site_qi_IXMLDOMDocument httpreq.c:1177: Test failed: unexpected call site_qi_IOleClientSite httpreq.c:1171: Test failed: unexpected call site_qi_IServiceProvider httpreq.c:1138: Test failed: unexpected call sp_queryservice_SID_secmgr_xmldomdoc httpreq.c:1126: Test failed: unexpected call sp_queryservice_SID_SContainerDispatch_htmldoc2 httpreq.c:1131: Test failed: unexpected call sp_queryservice_SID_secmgr_htmldoc2 httpreq.c:498: Test failed: unexpected call htmldoc2_get_url httpreq.c:1171: Test failed: unexpected call site_qi_IServiceProvider httpreq.c:1171: Test failed: unexpected call site_qi_IServiceProvider httpreq.c:1151: Test failed: unexpected request: sid {79eac9e4-baf9-11ce-8c82-00aa004ba90b}, riid {79eac9e4-baf9-11ce-8c82-00aa004ba90b} httpreq.c:1171: Test failed: unexpected call site_qi_IServiceProvider httpreq.c:1151: Test failed: unexpected request: sid {4f9f9fcb-e0f4-48eb-b7ab-fa2ea9365cb4}, riid {4f9f9fcb-e0f4-48eb-b7ab-fa2ea9365cb4} httpreq.c:1725: Test failed: got response text L"<!DOCTYPE HTML PUBLIC \"-//IETF//DTD HTML 2.0//EN\">\n<html><head>\n<title>404 Not Found</title>\n</head><body>\n<h1>Not Found</h1>\n<p>The requested URL /tests/referer.php was not found on this server.</p>\n</body></html>\n", expected L"http://test.winehq.org/" === w864 (32 bit httpreq) === httpreq.c:1700: Test failed: got response text L"<!DOCTYPE HTML PUBLIC \"-//IETF//DTD HTML 2.0//EN\">\n<html><head>\n<title>404 Not Found</title>\n</head><body>\n<h1>Not Found</h1>\n<p>The requested URL /tests/referer.php was not found on this server.</p>\n</body></html>\n" httpreq.c:1171: Test failed: unexpected call site_qi_IServiceProvider httpreq.c:1151: Test failed: unexpected request: sid {79eac9e4-baf9-11ce-8c82-00aa004ba90b}, riid {79eac9e4-baf9-11ce-8c82-00aa004ba90b} httpreq.c:1171: Test failed: unexpected call site_qi_IServiceProvider httpreq.c:1151: Test failed: unexpected request: sid {af0ff408-129d-4b20-91f0-02bd23d88352}, riid {af0ff408-129d-4b20-91f0-02bd23d88352} httpreq.c:1171: Test failed: unexpected call site_qi_IServiceProvider httpreq.c:1151: Test failed: unexpected request: sid {79eac9c1-baf9-11ce-8c82-00aa004ba90b}, riid {79eac9c1-baf9-11ce-8c82-00aa004ba90b} httpreq.c:1171: Test failed: unexpected call site_qi_IServiceProvider httpreq.c:1151: Test failed: unexpected request: sid {4f9f9fcb-e0f4-48eb-b7ab-fa2ea9365cb4}, riid {4f9f9fcb-e0f4-48eb-b7ab-fa2ea9365cb4} httpreq.c:1171: Test failed: unexpected call site_qi_IServiceProvider httpreq.c:1151: Test failed: unexpected request: sid {79eac9d5-bafa-11ce-8c82-00aa004ba90b}, riid {79eac9d5-bafa-11ce-8c82-00aa004ba90b} httpreq.c:1725: Test failed: got response text L"<!DOCTYPE HTML PUBLIC \"-//IETF//DTD HTML 2.0//EN\">\n<html><head>\n<title>404 Not Found</title>\n</head><body>\n<h1>Not Found</h1>\n<p>The requested URL /tests/referer.php was not found on this server.</p>\n</body></html>\n", expected L"http://test.winehq.org/" === w2008s64 (64 bit httpreq) === httpreq.c:1700: Test failed: got response text L"<!DOCTYPE HTML PUBLIC \"-//IETF//DTD HTML 2.0//EN\">\n<html><head>\n<title>404 Not Found</title>\n</head><body>\n<h1>Not Found</h1>\n<p>The requested URL /tests/referer.php was not found on this server.</p>\n</body></html>\n" httpreq.c:1171: Test failed: unexpected call site_qi_IServiceProvider httpreq.c:1121: Test failed: unexpected call sp_queryservice_SID_SBindHost httpreq.c:1126: Test failed: unexpected call sp_queryservice_SID_SContainerDispatch_htmldoc2 httpreq.c:1131: Test failed: unexpected call sp_queryservice_SID_secmgr_htmldoc2 httpreq.c:305: Test failed: unexpected call htmldoc2_get_all httpreq.c:210: Test failed: unexpected call collection_get_length httpreq.c:498: Test failed: unexpected call htmldoc2_get_url httpreq.c:1174: Test failed: unexpected call site_qi_IXMLDOMDocument httpreq.c:1177: Test failed: unexpected call site_qi_IOleClientSite httpreq.c:1171: Test failed: unexpected call site_qi_IServiceProvider httpreq.c:1138: Test failed: unexpected call sp_queryservice_SID_secmgr_xmldomdoc httpreq.c:1126: Test failed: unexpected call sp_queryservice_SID_SContainerDispatch_htmldoc2 httpreq.c:1131: Test failed: unexpected call sp_queryservice_SID_secmgr_htmldoc2 httpreq.c:498: Test failed: unexpected call htmldoc2_get_url httpreq.c:1171: Test failed: unexpected call site_qi_IServiceProvider httpreq.c:1171: Test failed: unexpected call site_qi_IServiceProvider httpreq.c:1151: Test failed: unexpected request: sid {79eac9e4-baf9-11ce-8c82-00aa004ba90b}, riid {79eac9e4-baf9-11ce-8c82-00aa004ba90b} httpreq.c:1171: Test failed: unexpected call site_qi_IServiceProvider httpreq.c:1151: Test failed: unexpected request: sid {4f9f9fcb-e0f4-48eb-b7ab-fa2ea9365cb4}, riid {4f9f9fcb-e0f4-48eb-b7ab-fa2ea9365cb4} httpreq.c:1725: Test failed: got response text L"<!DOCTYPE HTML PUBLIC \"-//IETF//DTD HTML 2.0//EN\">\n<html><head>\n<title>404 Not Found</title>\n</head><body>\n<h1>Not Found</h1>\n<p>The requested URL /tests/referer.php was not found on this server.</p>\n</body></html>\n", expected L"http://test.winehq.org/" === w7pro64 (64 bit httpreq) === httpreq.c:1700: Test failed: got response text L"<!DOCTYPE HTML PUBLIC \"-//IETF//DTD HTML 2.0//EN\">\n<html><head>\n<title>404 Not Found</title>\n</head><body>\n<h1>Not Found</h1>\n<p>The requested URL /tests/referer.php was not found on this server.</p>\n</body></html>\n" httpreq.c:1171: Test failed: unexpected call site_qi_IServiceProvider httpreq.c:1121: Test failed: unexpected call sp_queryservice_SID_SBindHost httpreq.c:1126: Test failed: unexpected call sp_queryservice_SID_SContainerDispatch_htmldoc2 httpreq.c:1131: Test failed: unexpected call sp_queryservice_SID_secmgr_htmldoc2 httpreq.c:305: Test failed: unexpected call htmldoc2_get_all httpreq.c:210: Test failed: unexpected call collection_get_length httpreq.c:498: Test failed: unexpected call htmldoc2_get_url httpreq.c:1174: Test failed: unexpected call site_qi_IXMLDOMDocument httpreq.c:1177: Test failed: unexpected call site_qi_IOleClientSite httpreq.c:1171: Test failed: unexpected call site_qi_IServiceProvider httpreq.c:1138: Test failed: unexpected call sp_queryservice_SID_secmgr_xmldomdoc httpreq.c:1126: Test failed: unexpected call sp_queryservice_SID_SContainerDispatch_htmldoc2 httpreq.c:1131: Test failed: unexpected call sp_queryservice_SID_secmgr_htmldoc2 httpreq.c:498: Test failed: unexpected call htmldoc2_get_url httpreq.c:1171: Test failed: unexpected call site_qi_IServiceProvider httpreq.c:1171: Test failed: unexpected call site_qi_IServiceProvider httpreq.c:1151: Test failed: unexpected request: sid {79eac9e4-baf9-11ce-8c82-00aa004ba90b}, riid {79eac9e4-baf9-11ce-8c82-00aa004ba90b} httpreq.c:1171: Test failed: unexpected call site_qi_IServiceProvider httpreq.c:1151: Test failed: unexpected request: sid {4f9f9fcb-e0f4-48eb-b7ab-fa2ea9365cb4}, riid {4f9f9fcb-e0f4-48eb-b7ab-fa2ea9365cb4} httpreq.c:1725: Test failed: got response text L"<!DOCTYPE HTML PUBLIC \"-//IETF//DTD HTML 2.0//EN\">\n<html><head>\n<title>404 Not Found</title>\n</head><body>\n<h1>Not Found</h1>\n<p>The requested URL /tests/referer.php was not found on this server.</p>\n</body></html>\n", expected L"http://test.winehq.org/" === w864 (64 bit httpreq) === httpreq.c:1700: Test failed: got response text L"<!DOCTYPE HTML PUBLIC \"-//IETF//DTD HTML 2.0//EN\">\n<html><head>\n<title>404 Not Found</title>\n</head><body>\n<h1>Not Found</h1>\n<p>The requested URL /tests/referer.php was not found on this server.</p>\n</body></html>\n" httpreq.c:1171: Test failed: unexpected call site_qi_IServiceProvider httpreq.c:1151: Test failed: unexpected request: sid {79eac9e4-baf9-11ce-8c82-00aa004ba90b}, riid {79eac9e4-baf9-11ce-8c82-00aa004ba90b} httpreq.c:1171: Test failed: unexpected call site_qi_IServiceProvider httpreq.c:1151: Test failed: unexpected request: sid {af0ff408-129d-4b20-91f0-02bd23d88352}, riid {af0ff408-129d-4b20-91f0-02bd23d88352} httpreq.c:1171: Test failed: unexpected call site_qi_IServiceProvider httpreq.c:1151: Test failed: unexpected request: sid {79eac9c1-baf9-11ce-8c82-00aa004ba90b}, riid {79eac9c1-baf9-11ce-8c82-00aa004ba90b} httpreq.c:1171: Test failed: unexpected call site_qi_IServiceProvider httpreq.c:1151: Test failed: unexpected request: sid {4f9f9fcb-e0f4-48eb-b7ab-fa2ea9365cb4}, riid {4f9f9fcb-e0f4-48eb-b7ab-fa2ea9365cb4} httpreq.c:1171: Test failed: unexpected call site_qi_IServiceProvider httpreq.c:1151: Test failed: unexpected request: sid {79eac9d5-bafa-11ce-8c82-00aa004ba90b}, riid {79eac9d5-bafa-11ce-8c82-00aa004ba90b} httpreq.c:1725: Test failed: got response text L"<!DOCTYPE HTML PUBLIC \"-//IETF//DTD HTML 2.0//EN\">\n<html><head>\n<title>404 Not Found</title>\n</head><body>\n<h1>Not Found</h1>\n<p>The requested URL /tests/referer.php was not found on this server.</p>\n</body></html>\n", expected L"http://test.winehq.org/"

Oct. 17, 2013

Re: [4/6] kernel32/tests: Fix communication port tests compilation with __WINESRC__ defined.

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://newtestbot.winehq.org/JobDetails.pl?Key=2833 Your paranoid android. === w2008s64 (32 bit comm) === comm.c:861: Test failed: WaitCommEvent failed with a timeout comm.c:872: recovering after WAIT_TIMEOUT... comm.c:883: Test failed: WaitCommEvent error 0 comm.c:885: Test failed: WaitCommEvent: expected EV_TXEMPTY, got 0 comm.c:889: WaitCommEvent for EV_TXEMPTY took 1014 ms (timeout 1000) comm.c:891: Test failed: WaitCommEvent used 1014 ms for waiting comm.c:1558: test_AbortWaitCts timeout 500 handle 000000C4 comm.c:1525: Changing CommMask on the fly for handle 000000C4 after timeout 500

Oct. 17, 2013

Re: [2/2] gdi32/tests: Enable gdi32 tests compilation with __WINESRC__ defined. Resend.

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://newtestbot.winehq.org/JobDetails.pl?Key=2828 Your paranoid android. === wxppro (32 bit) === No test summary line found === wvista (32 bit) === No test summary line found === w2008s64 (32 bit) === No test summary line found === w7pro64 (32 bit) === No test summary line found === w864 (32 bit) === No test summary line found === w2008s64 (64 bit) === No test summary line found === w7pro64 (64 bit) === No test summary line found === w864 (64 bit) === No test summary line found

Oct. 17, 2013

Re: msctf/tests: Compile with -D__WINESRC__

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://newtestbot.winehq.org/JobDetails.pl?Key=2822 Your paranoid android. === w864 (64 bit inputprocessor) === inputprocessor.c:791: Test failed: Deactivation came unexpectedly

Oct. 16, 2013

Re: [PATCH] user32/tests: Skip desktop tests on NT4.

by Qian Hong

On Thu, Oct 17, 2013 at 2:36 AM, Alexandre Julliard <julliard(a)winehq.org> wrote: > ../../../tools/runtest -q -P wine -T ../../.. -M user32.dll -p user32_test.exe.so winstation.c && touch winstation.ok > winstation.c:546: Test succeeded inside todo block: unexpected last error deadbeef > winstation.c:549: Test failed: Skip tests on NT4 My bad, I really should have tested my code even with small change... Shame on me, sorry. Will send a fixed version. -- Regards, Qian Hong - http://www.codeweavers.com

Oct. 16, 2013

Re: [PATCH] user32/tests: Skip desktop tests on NT4.

by Alexandre Julliard

Qian Hong <qhong(a)codeweavers.com> writes: > --- > dlls/user32/tests/winstation.c | 10 +++++++++- > 1 file changed, 9 insertions(+), 1 deletion(-) It doesn't work: ../../../tools/runtest -q -P wine -T ../../.. -M user32.dll -p user32_test.exe.so winstation.c && touch winstation.ok winstation.c:546: Test succeeded inside todo block: unexpected last error deadbeef winstation.c:549: Test failed: Skip tests on NT4 -- Alexandre Julliard julliard(a)winehq.org

Oct. 16, 2013

Re: [PATCH 02/11] crypt32: Don't use links to certs in memory store.

by Alexandre Julliard

Jacek Caban <jacek(a)codeweavers.com> writes: > --- > dlls/crypt32/cert.c | 159 > ++++++++++++++++++++++++----------------- > dlls/crypt32/collectionstore.c | 12 ++-- > dlls/crypt32/context.c | 4 +- > dlls/crypt32/crl.c | 7 +- > dlls/crypt32/crypt32_private.h | 22 +++--- > dlls/crypt32/ctl.c | 9 ++- > dlls/crypt32/provstore.c | 18 ++--- > dlls/crypt32/store.c | 17 +++-- > 8 files changed, 140 insertions(+), 108 deletions(-) It breaks the tests: ../../../tools/runtest -q -P wine -T ../../.. -M cryptui.dll -p cryptui_test.exe.so cryptui.c && touch cryptui.ok wine: Unhandled page fault on read access to 0xfffffff0 at address 0x6865c543 (thread 005d), starting debugger... Unhandled exception: page fault on read access to 0xfffffff0 in 32-bit code (0x6865c543). Register dump: CS:0023 SS:002b DS:002b ES:002b FS:0063 GS:006b EIP:6865c543 ESP:0032fab0 EBP:0032fac8 EFLAGS:00010297( R- -- I S -A-P-C) EAX:ffffffe8 EBX:686bb2fc ECX:00000000 EDX:0013ed38 ESI:0013ed70 EDI:00000001 Stack dump: 0x0032fab0: 00000005 0013eea0 0032fb68 686bb2fc 0x0032fac0: 686bb2fc 00000001 0032fb68 6864f122 0x0032fad0: 0013d6a8 00000000 00000000 0032fb2c 0x0032fae0: 00000000 00000000 0032fb38 6869a1af 0x0032faf0: 00000000 00020000 00000000 6865b7e0 0x0032fb00: 0032fb3c 0013ed50 0032fb38 6869a618 Backtrace: =>0 0x6865c543 Context_CopyProperties+0x43(to=0x13d6a8, from=0x0(nil)) [/home/julliard/wine/wine/dlls/crypt32/context.c:99] in crypt32 (0x0032fac8) 1 0x6864f122 add_cert_to_store+0x3e1(store=<couldn't compute location>, cert=<couldn't compute location>, add_disposition=<couldn't compute location>, use_link=<couldn't compute location>, ret_context=<couldn't compute location>) [/home/julliard/wine/wine/dlls/crypt32/cert.c:270] in crypt32 (0x0032fb68) 2 0x6864f37d CertAddCertificateContextToStore+0x9c(hCertStore=<couldn't compute location>, pCertContext=<couldn't compute location>, dwAddDisposition=<couldn't compute location>, ppStoreContext=<couldn't compute location>) [/home/julliard/wine/wine/dlls/crypt32/cert.c:288] in crypt32 (0x0032fbc8) 3 0x5557563b import_cert+0x14a() in cryptui (0x0032fc38) 4 0x555793ad CryptUIWizImport+0x10c() in cryptui (0x0032fc78) 5 0x6862a5e7 func_cryptui+0x4f6() [/home/julliard/wine/wine/dlls/cryptui/tests/cryptui.c:397] in cryptui_test (0x0032fcf8) 6 0x6862b675 run_test+0x144(name=<is not available>) [/home/julliard/wine/wine/dlls/cryptui/tests/../../../include/wine/test.h:570] in cryptui_test (0x0032fd48) 7 0x68629c23 main+0x152(argc=<is not available>, argv=<is not available>) [/home/julliard/wine/wine/dlls/cryptui/tests/../../../include/wine/test.h:640] in cryptui_test (0x0032fe08) 8 0x6862c0c0 __wine_spec_exe_entry+0x7f(peb=<couldn't compute location>) [/home/julliard/wine/wine/dlls/winecrt0/exe_entry.c:36] in cryptui_test (0x0032fe58) 9 0x7b85f38c call_process_entry+0xb() in kernel32 (0x0032fe78) 10 0x7b86056b start_process+0x6a(peb=<couldn't compute location>) [/home/julliard/wine/wine/dlls/kernel32/process.c:1085] in kernel32 (0x0032feb8) 11 0x7bc7fea0 call_thread_func_wrapper+0xb() in ntdll (0x0032fed8) 12 0x7bc82dad call_thread_func+0x7c(entry=0x7b860500, arg=0x7ffdf000, frame=0x32ffc8) [/home/julliard/wine/wine/dlls/ntdll/signal_i386.c:2602] in ntdll (0x0032ffa8) 13 0x7bc7fe7e call_thread_entry_point+0x11() in ntdll (0x0032ffc8) 14 0x7bc54a2e start_process+0x1d(kernel_start=0x7b860500) [/home/julliard/wine/wine/dlls/ntdll/loader.c:2697] in ntdll (0x0032ffe8) 15 0x6803128d wine_call_on_stack+0x1c() in libwine.so.1 (0x00000000) 16 0x6803134b wine_switch_to_stack+0x2a(func=0x7bc54a10, arg=0x7b860500, stack=0x330000) [/home/julliard/wine/wine/libs/wine/port.c:59] in libwine.so.1 (0xffb103b8) 17 0x7bc5a587 LdrInitializeThunk+0x3a6(kernel_start=<couldn't compute location>, unknown2=<couldn't compute location>, unknown3=<couldn't compute location>, unknown4=<couldn't compute location>) [/home/julliard/wine/wine/dlls/ntdll/loader.c:2753] in ntdll (0xffb10428) 18 0x7b866ae0 __wine_kernel_init+0xbbf() [/home/julliard/wine/wine/dlls/kernel32/process.c:1257] in kernel32 (0xffb11338) 19 0x7bc5ac53 __wine_process_init+0x182() [/home/julliard/wine/wine/dlls/ntdll/loader.c:2962] in ntdll (0xffb113c8) 20 0x6802eeda wine_init+0x2b9(argc=0x3, argv=0xffb11904, error="", error_size=0x400) [/home/julliard/wine/wine/libs/wine/loader.c:952] in libwine.so.1 (0xffb11428) 21 0x7bf00d3b main+0x7a(argc=<is not available>, argv=<is not available>) [/home/julliard/wine/wine/loader/main.c:237] in <wine-loader> (0xffb11868) 22 0x682518c5 __libc_start_main+0xf4() in libc.so.6 (0x00000000) 0x6865c543 Context_CopyProperties+0x43 [/home/julliard/wine/wine/dlls/crypt32/context.c:99] in crypt32: movl 0xfffffff0(%ecx),%edx 99 while (ptr && ptr->linked) -- Alexandre Julliard julliard(a)winehq.org

Oct. 16, 2013

Re: [PATCH 2/6] atl: Avoid duplicate debugging trace for same exported function names from different dlls.

by Qian Hong

On Thu, Oct 17, 2013 at 1:48 AM, Alexandre Julliard <julliard(a)winehq.org> wrote: > I'd suggest to simply print the version in the trace, instead of > renaming all the functions. Thanks for suggestion, sounds like a better idea, I'll resend, please ignore these patches. -- Regards, Qian Hong - http://www.codeweavers.com

Oct. 16, 2013

Re: [PATCH 2/6] atl: Avoid duplicate debugging trace for same exported function names from different dlls.

by Alexandre Julliard

Qian Hong <qhong(a)codeweavers.com> writes: > --- > dlls/atl/atl.spec | 6 +++--- > dlls/atl/atl_main.c | 9 +++++---- > 2 files changed, 8 insertions(+), 7 deletions(-) I'd suggest to simply print the version in the trace, instead of renaming all the functions. -- Alexandre Julliard julliard(a)winehq.org

Oct. 16, 2013

Re: [PATCH try3] atl110: Added new DLL.

by Qian Hong

On Wed, Sep 4, 2013 at 6:46 PM, Jacek Caban <jacek(a)codeweavers.com> wrote: > Yes, that could work as well. I don't have strong opinion, feel free to > submit a patch with solution of your choice. Thanks for the comment, I just sent a serial of patches to improve it as the above solution. -- Regards, Qian Hong - http://www.winehq.org

Oct. 16, 2013

visual studio 2012 pdb support

by Роман Остриков

Hello, dear developes Some times ago I have started porting some system to wine and was disappointed that application hangs. So I have began use dbghelp. I have faced with problem in supporting dpb files in wine which was generated by Visual Studio 2012. I have found an article: http://bugs.winehq.org/show_bug.cgi?id=835 where Dan Kegel public a series of fixes. But support was for VS2008 and post was dated by 2009-11-01. So may be this fix already included in Wine1.6 and debug symbols cant recognized by dbghelp due of another problem? Can anybody explain this? Best Reagrds

Oct. 16, 2013

Re: Video Mixing Renderer 7

by Aric Stewart

Hi, On 10/16/13 3:22 AM, Michael Stefaniuc wrote: > Hello, > > On 10/15/2013 09:52 PM, Michael Müller wrote: >> I am wondering what would be the best way to handle programs which rely >> on the Video Mixing Renderer 7 (quartz.dll) as it's supposed to be >> available on XP and later, but Wine contains only an implementation of >> version 9. Being one of the guy who did the work on vmr9 and generally had a pretty good working knowledge of quartz I am willing to bet that the actual work to be done is fairly small. But there will be a lot of COM wrapping to be written. Not to hard but busy work. Looking briefly at the vmr7 interfaces, they seems basically the same as the vmr9 ones, but with different parameters. I bet you could even get away with renaming vmr9.c to vmr.c and implementing 7/9 both in the file pretty easily. -aric

Oct. 16, 2013

Re: notepad: Use BOOL type where appropriate (try 2)

by Alexandre Julliard

Frédéric Delanoy <frederic.delanoy(a)gmail.com> writes: > try 2: Avoid changing SendMessage calls Dialog procedures return booleans too. -- Alexandre Julliard julliard(a)winehq.org

Oct. 16, 2013

Re: notepad: Use BOOL type where appropriate

by Alexandre Julliard

Frédéric Delanoy <frederic.delanoy(a)gmail.com> writes: > @@ -298,7 +298,7 @@ static SAVE_STATUS DoSaveFile(LPCWSTR szFileName, ENCODING enc) > CloseHandle(hFile); > HeapFree(GetProcessHeap(), 0, pBytes); > > - SendMessageW(Globals.hEdit, EM_SETMODIFY, FALSE, 0); > + SendMessageW(Globals.hEdit, EM_SETMODIFY, 0, 0); Many messages use booleans, even if the actual type is a WPARAM. Please don't change them. -- Alexandre Julliard julliard(a)winehq.org

Oct. 16, 2013

Re: dispex/tests: Compile with -D__WINESRC__

by Alexandre Julliard

Dmitry Timoshkov <dmitry(a)baikal.ru> writes: > Nikolay Sivov <nsivov(a)codeweavers.com> wrote: > >> + PeekMessageA(&msg, NULL, WM_USER, WM_USER, PM_NOREMOVE); > > IMHO it would be much better to use W version of APIs while doing this > cleanup. Same applies to all other your patches that prepare switching > compilation to using -D__WINESRC__. Considering that the A implementation is usually based on the W one, calling the A function enables to test both. When there are differences we would of course want to test both explicitly, but otherwise it's a good idea to have a healthy mix. We definitely don't want a rule that tests always have to call W functions. -- Alexandre Julliard julliard(a)winehq.org

Oct. 16, 2013

Re: Video Mixing Renderer 7

by Michael Stefaniuc

Hello, On 10/15/2013 09:52 PM, Michael Müller wrote: > I am wondering what would be the best way to handle programs which rely > on the Video Mixing Renderer 7 (quartz.dll) as it's supposed to be > available on XP and later, but Wine contains only an implementation of > version 9. > > The program I am speaking of is Silverlight which uses the VMR 7 > Interface to create a filter graph and then queries for the > IAMCertifiedOutputProtection interface. I am currently using a hack fix > to get around this by returning a VMR9 instance when a VMR7 is requested > and implementing the missing subinterfaces (which are only part of > VMR7). This solution is clearly not perfect and I am searching for a > better way to get around this issue. > > The most similar way to Windows would be to completely rewrite the > current implementation of the VMR9 as VMR7 using DirectDraw, which would > take a lot of time and most probably end up in having a lot of duplicate > code. I am wondering whether using d3d9 for VMR7 would also be an > acceptable solution. We could move all the d3d9 related stuff to a > separate file so that VMR7.c and VMR9.c only offer the version specific > interfaces and use the same code internally. This shouldn't be a big > problem since the differences between the VMR7 and VMR9 interfaces are > often only very small. Though it would not completely fit the behavior > of windows. if the differences are small then there are different options to reuse the common parts: - Use the same object (struct) for both VMR7 and 9. Just set the correct vtbl pointers during object creation. - Use a separate struct for the common parts and include it in both objects. Kind off like it is done at the moment with the BaseRenderer and the other Base* stuff. - If it is feasible to have VMR7 implemented in d3d9 you could even make VMR7 a small wrapper around VMR9. Aka COM aggregate the VMR9 object and just implement the parts you can't forward. > I am open for other ideas on how to solve the problem, but as > Silverlight does not even use the VMR7 object for playing the video but > only to check for the graphic driver certificate I don't think it would > justify to rewrite everything using Direct Draw if there are no other > programs needing this interface. I have an old kids education game that uses both ddraw and quartz that doesn't works. I'll check if it uses VMR7. If yes it is worthwhile to do it right as it is a whole class of such multimedia apps from the early days. bye michael

Oct. 16, 2013

Re: [10/10] gdi32/tests: Enable gdi32 tests compilation with __WINESRC__ defined.

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://newtestbot.winehq.org/JobDetails.pl?Key=2808 Your paranoid android. === wxppro (32 bit) === No test summary line found === wvista (32 bit) === No test summary line found === w2008s64 (32 bit) === No test summary line found === w7pro64 (32 bit) === No test summary line found === w864 (32 bit) === No test summary line found === w2008s64 (64 bit) === No test summary line found === w7pro64 (64 bit) === No test summary line found === w864 (64 bit) === No test summary line found

Oct. 16, 2013

Re: [06/10] gdi32/tests: Fix font tests compilation with __WINESRC__ defined.

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://newtestbot.winehq.org/JobDetails.pl?Key=2804 Your paranoid android. === wxppro (32 bit font) === font.c:1545: Test failed: GetGlyphIndicesW should have returned a 20ac not 0080 === wvista (32 bit font) === font.c:1545: Test failed: GetGlyphIndicesW should have returned a 20ac not 0080 No test summary line found Failure running script in VM: network read timed out === w2008s64 (32 bit font) === font.c:1545: Test failed: GetGlyphIndicesW should have returned a 20ac not 0080 Timeout Failure running script in VM: network read timed out === w7pro64 (32 bit font) === font.c:1545: Test failed: GetGlyphIndicesW should have returned a 20ac not 0080 === w864 (32 bit font) === font.c:1545: Test failed: GetGlyphIndicesW should have returned a 20ac not 0080 === w2008s64 (64 bit font) === font.c:1545: Test failed: GetGlyphIndicesW should have returned a 20ac not 0080 === w7pro64 (64 bit font) === font.c:1545: Test failed: GetGlyphIndicesW should have returned a 20ac not 0080 === w864 (64 bit font) === font.c:1545: Test failed: GetGlyphIndicesW should have returned a 20ac not 0080

Oct. 16, 2013

Re: wined3d: Initialize map_desc in wined3d_surface_map

by Lasse Rasinen

Stefan Dösinger <stefandoesinger(a)gmail.com> writes: > Am 2013-10-15 20:34, schrieb Marvin: >> === w864 (32 bit device) === device.c:5409: Test failed: pBits not >> cleared on double lock. device.c:5410: Test failed: Pitch not >> cleared on double lock. device: unhandled exception c0000005 at >> 742814C8 > I'm surprised that the testbot executes those tests. Did you run those > tests on a real Windows machine? If you want I can test them for you > on a variety of windows versions and GPUs here. I can have access to a Windows machine earliest on Friday, and even then it won't be Win8. So yes please. -- Lasse Rasinen lrasinen(a)iki.fi

Oct. 16, 2013

Re: mmdevapi/tests: Compile with -D__WINESRC__.

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://newtestbot.winehq.org/JobDetails.pl?Key=2797 Your paranoid android. === w7pro64 (32 bit render) === render.c:662: Test failed: Wait(event) after Stop gave 102

Oct. 16, 2013

Re: winmm/tests: Use the explicit mciSendStringA() form.

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://newtestbot.winehq.org/JobDetails.pl?Key=2796 Your paranoid android. === w864 (32 bit midi) === midi.c:518: Test failed: midiOutPrepare old size rc=MMSYSERR_INVALPARAM midi.c:519: Test failed: MHDR.dwFlags when prepared 0 midi.c:523: Test failed: midiStreamOut old size rc=MIDIERR_UNPREPARED midi.c:547: Test failed: MHDR.dwFlags 0 no ISSTRM when out of queue midi.c:553: Test failed: MHDR.dwFlags 0 not DONE when out of queue midi.c:554: Test failed: Wait failed: 0102 -559038737 midi.c:554: Test failed: Expect message 3ca from midiStream callback midi.c:555: Test failed: Wait failed: 0102 -559038737 midi.c:555: Test failed: Expect message 3c9 from midiStreamOut midi.c:558: Test failed: play left MIDIHDR.dwOffset at 1234567890 midi.c:561: Test failed: midiOutUnprepare rc=MMSYSERR_INVALPARAM midi.c:563: Test failed: midiOutUnprepare #2 rc=MMSYSERR_INVALPARAM midi.c:566: Test failed: MHDR.dwFlags when done 0 midi.c:580: Test failed: stream set tempo 500000 midi.c:588: Test failed: midiOutPrepare used flags 8 rc=MMSYSERR_INVALPARAM midi.c:590: Test failed: midiOutUnprepare used flags 8 rc=MMSYSERR_INVALPARAM midi.c:518: Test failed: midiOutPrepare old size rc=MMSYSERR_INVALPARAM midi.c:519: Test failed: MHDR.dwFlags when prepared 0 midi.c:523: Test failed: midiStreamOut old size rc=MIDIERR_UNPREPARED midi.c:547: Test failed: MHDR.dwFlags 0 no ISSTRM when out of queue midi.c:553: Test failed: MHDR.dwFlags 0 not DONE when out of queue midi.c:554: Test failed: Wait failed: 0102 -559038737 midi.c:554: Test failed: Expect message 3ca from midiStream callback midi.c:555: Test failed: Wait failed: 0102 -559038737 midi.c:555: Test failed: Expect message 3c9 from midiStreamOut midi.c:558: Test failed: play left MIDIHDR.dwOffset at 1234567890 midi.c:561: Test failed: midiOutUnprepare rc=MMSYSERR_INVALPARAM midi.c:563: Test failed: midiOutUnprepare #2 rc=MMSYSERR_INVALPARAM midi.c:566: Test failed: MHDR.dwFlags when done 0 midi.c:580: Test failed: stream set tempo 500000 midi.c:588: Test failed: midiOutPrepare used flags 8 rc=MMSYSERR_INVALPARAM midi.c:590: Test failed: midiOutUnprepare used flags 8 rc=MMSYSERR_INVALPARAM === wxppro (32 bit mci) === mci.c:1209: Test failed: mci status "C:\Documents and Settings\winetest\My Documents\tempfile.wav" mode returned MCIERR_INVALID_DEVICE_NAME mci.c:1274: Test failed: mci re-auto-open status mode returned MCIERR_INVALID_DEVICE_NAME mci.c:1290: Test failed: mci auto-open pause returned MCIERR_INVALID_DEVICE_NAME === wvista (32 bit mci) === mci.c:986: Test failed: 397ms is not in the expected 400-600ms range mci.c:993: Test failed: 397ms is not even in the expected 400-1000ms range === w7pro64 (64 bit mci) === mci.c:1120: Test failed: got 0001 instead of MCI_NOTIFY_xyz 0004 from command play (aborted by close)

Oct. 16, 2013

Re: cmd/tests: Compile with -D__WINESRC__

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://newtestbot.winehq.org/JobDetails.pl?Key=2794 Your paranoid android. === wxppro (32 bit batch) === batch.c:312: Test failed: unexpected char 0x47 position 0 in line 686 (got 'Got unexpected result: "C:\Documents"', wanted 'Plain directory enumeration from provided root') batch.c:312: Test failed: unexpected char 0x47 position 0 in line 687 (got 'Got unexpected result: "C:\Documents"', wanted 'File enumeration') batch.c:312: Test failed: unexpected char 0x47 position 0 in line 688 (got 'Got unexpected result: "C:\Documents"', wanted 'File enumeration from provided root') batch.c:312: Test failed: unexpected char 0x47 position 0 in line 689 (got 'Got unexpected result: "C:\Documents"', wanted 'Mixed enumeration') batch.c:312: Test failed: unexpected char 0x46 position 0 in line 690 (got 'Found missing result: "C:\Documents and Settings\winetest\My Documents\foobar\."', wanted 'Mixed enumeration from provided root') batch.c:312: Test failed: unexpected char 0x46 position 0 in line 691 (got 'Found missing result: "C:\Documents and Settings\winetest\My Documents\foobar\bar\."', wanted 'With duplicates enumeration') batch.c:312: Test failed: unexpected char 0x46 position 0 in line 692 (got 'Found missing result: "C:\Documents and Settings\winetest\My Documents\foobar\baz\."', wanted 'Strip missing wildcards, keep unwildcarded names') batch.c:312: Test failed: unexpected char 0x46 position 0 in line 693 (got 'Found missing result: "C:\Documents and Settings\winetest\My Documents\foobar\foo\."', wanted 'for /R passed') batch.c:312: Test failed: unexpected char 0x50 position 0 in line 694 (got 'Plain directory enumeration from provided root', wanted '--- Complex wildcards unix and windows slash') batch.c:312: Test failed: unexpected char 0x47 position 0 in line 695 (got 'Got unexpected result: "C:\Documents"', wanted '--- Complex wildcards unix and windows slash') batch.c:312: Test failed: unexpected char 0x47 position 0 in line 696 (got 'Got unexpected result: "C:\Documents"', wanted '--- Complex wildcards unix and windows slash') batch.c:312: Test failed: unexpected char 0x47 position 0 in line 697 (got 'Got unexpected result: "C:\Documents"', wanted '--- Complex wildcards unix and windows slash') batch.c:312: Test failed: unexpected char 0x47 position 0 in line 698 (got 'Got unexpected result: "C:\Documents"', wanted '--- Complex wildcards unix and windows slash') batch.c:312: Test failed: unexpected char 0x46 position 0 in line 699 (got 'Found missing result: "C:\Documents and Settings\winetest\My Documents\foobar\."', wanted '--- Complex wildcards unix and windows slash') batch.c:312: Test failed: unexpected char 0x46 position 0 in line 700 (got 'Found missing result: "C:\Documents and Settings\winetest\My Documents\foobar\bar\."', wanted '--- Complex wildcards unix and windows slash') batch.c:312: Test failed: unexpected char 0x46 position 0 in line 701 (got 'Found missing result: "C:\Documents and Settings\winetest\My Documents\foobar\baz\."', wanted '--- Complex wildcards unix and windows slash') batch.c:312: Test failed: unexpected char 0x46 position 0 in line 702 (got 'Found missing result: "C:\Documents and Settings\winetest\My Documents\foobar\foo\."', wanted '--- Complex wildcards unix and windows slash') batch.c:312: Test failed: unexpected char 0x46 position 0 in line 703 (got 'File enumeration', wanted '--- Complex wildcards unix and windows slash') batch.c:312: Test failed: unexpected char 0x47 position 0 in line 704 (got 'Got unexpected result: "C:\Documents"', wanted '--- Complex wildcards unix and windows slash') batch.c:312: Test failed: unexpected char 0x47 position 0 in line 705 (got 'Got unexpected result: "C:\Documents"', wanted '--- Complex wildcards unix and windows slash') batch.c:312: Test failed: unexpected char 0x46 position 0 in line 706 (got 'Found missing result: "C:\Documents and Settings\winetest\My Documents\foobar\baz\bazbaz"', wanted '--- Complex wildcards unix and windows slash') batch.c:312: Test failed: unexpected char 0x46 position 0 in line 707 (got 'Found missing result: "C:\Documents and Settings\winetest\My Documents\foobar\bazbaz"', wanted '--- Complex wildcards unix and windows slash') batch.c:312: Test failed: unexpected char 0x46 position 0 in line 708 (got 'File enumeration from provided root', wanted '--- Complex wildcards unix and windows slash') batch.c:312: Test failed: unexpected char 0x47 position 0 in line 709 (got 'Got unexpected result: "C:\Documents"', wanted '--- Complex wildcards unix and windows slash') batch.c:312: Test failed: unexpected char 0x47 position 0 in line 710 (got 'Got unexpected result: "C:\Documents"', wanted '--- Complex wildcards unix and windows slash') batch.c:312: Test failed: unexpected char 0x46 position 0 in line 711 (got 'Found missing result: "C:\Documents and Settings\winetest\My Documents\foobar\baz\bazbaz"', wanted '--- Complex wildcards unix and windows slash') batch.c:312: Test failed: unexpected char 0x46 position 0 in line 712 (got 'Found missing result: "C:\Documents and Settings\winetest\My Documents\foobar\bazbaz"', wanted '--- Complex wildcards unix and windows slash') batch.c:312: Test failed: unexpected char 0x4d position 0 in line 713 (got 'Mixed enumeration', wanted '--- Complex wildcards unix and windows slash') batch.c:312: Test failed: unexpected char 0x47 position 0 in line 714 (got 'Got unexpected result: "C:\Documents"', wanted '--- Complex wildcards unix and windows slash') batch.c:312: Test failed: unexpected char 0x47 position 0 in line 715 (got 'Got unexpected result: "C:\Documents"', wanted '--- Complex wildcards unix and windows slash') batch.c:312: Test failed: unexpected char 0x47 position 0 in line 716 (got 'Got unexpected result: "C:\Documents"', wanted '--- Complex wildcards unix and windows slash') batch.c:312: Test failed: unexpected char 0x47 position 0 in line 717 (got 'Got unexpected result: "C:\Documents"', wanted '--- Complex wildcards unix and windows slash') batch.c:312: Test failed: unexpected char 0x47 position 0 in line 718 (got 'Got unexpected result: "C:\Documents"', wanted '--- Complex wildcards unix and windows slash') batch.c:312: Test failed: unexpected char 0x47 position 0 in line 719 (got 'Got unexpected result: "C:\Documents"', wanted '--- Complex wildcards unix and windows slash') batch.c:312: Test failed: unexpected char 0x46 position 0 in line 720 (got 'Found missing result: "C:\Documents and Settings\winetest\My Documents\foobar\."', wanted '--- Complex wildcards unix and windows slash') batch.c:312: Test failed: unexpected char 0x46 position 0 in line 721 (got 'Found missing result: "C:\Documents and Settings\winetest\My Documents\foobar\bar\."', wanted '--- Complex wildcards unix and windows slash') batch.c:312: Test failed: unexpected char 0x46 position 0 in line 722 (got 'Found missing result: "C:\Documents and Settings\winetest\My Documents\foobar\baz\."', wanted '--- Complex wildcards unix and windows slash') batch.c:312: Test failed: unexpected char 0x46 position 0 in line 723 (got 'Found missing result: "C:\Documents and Settings\winetest\My Documents\foobar\baz\bazbaz"', wanted '--- Complex wildcards unix and windows slash') batch.c:312: Test failed: unexpected char 0x46 position 0 in line 724 (got 'Found missing result: "C:\Documents and Settings\winetest\My Documents\foobar\bazbaz"', wanted '--- Complex wildcards unix and windows slash') batch.c:312: Test failed: unexpected char 0x46 position 0 in line 725 (got 'Found missing result: "C:\Documents and Settings\winetest\My Documents\foobar\foo\."', wanted '--- Complex wildcards unix and windows slash') batch.c:312: Test failed: unexpected char 0x4d position 0 in line 726 (got 'Mixed enumeration from provided root', wanted '--- Complex wildcards unix and windows slash') batch.c:312: Test failed: unexpected char 0x47 position 0 in line 727 (got 'Got unexpected result: "C:\Documents"', wanted '--- Complex wildcards unix and windows slash') batch.c:312: Test failed: unexpected char 0x47 position 0 in line 728 (got 'Got unexpected result: "C:\Documents"', wanted '--- Complex wildcards unix and windows slash') batch.c:312: Test failed: unexpected char 0x47 position 0 in line 729 (got 'Got unexpected result: "C:\Documents"', wanted '--- Complex wildcards unix and windows slash') batch.c:312: Test failed: unexpected char 0x47 position 0 in line 730 (got 'Got unexpected result: "C:\Documents"', wanted '--- Complex wildcards unix and windows slash') batch.c:312: Test failed: unexpected char 0x47 position 0 in line 731 (got 'Got unexpected result: "C:\Documents"', wanted '--- Complex wildcards unix and windows slash') batch.c:312: Test failed: unexpected char 0x47 position 0 in line 732 (got 'Got unexpected result: "C:\Documents"', wanted '--- Complex wildcards unix and windows slash') batch.c:312: Test failed: unexpected char 0x46 position 0 in line 733 (got 'Found missing result: "C:\Documents and Settings\winetest\My Documents\foobar\."', wanted '--- Complex wildcards unix and windows slash') batch.c:312: Test failed: unexpected char 0x46 position 0 in line 734 (got 'Found missing result: "C:\Documents and Settings\winetest\My Documents\foobar\bar\."', wanted '--- Complex wildcards unix and windows slash') batch.c:312: Test failed: unexpected char 0x46 position 0 in line 735 (got 'Found missing result: "C:\Documents and Settings\winetest\My Documents\foobar\baz\."', wanted '--- Complex wildcards unix and windows slash') batch.c:312: Test failed: unexpected char 0x46 position 0 in line 736 (got 'Found missing result: "C:\Documents and Settings\winetest\My Documents\foobar\baz\bazbaz"', wanted '--- Complex wildcards unix and windows slash') batch.c:312: Test failed: unexpected char 0x46 position 0 in line 737 (got 'Found missing result: "C:\Documents and Settings\winetest\My Documents\foobar\bazbaz"', wanted '--- Complex wildcards unix and windows slash') batch.c:312: Test failed: unexpected char 0x46 position 0 in line 738 (got 'Found missing result: "C:\Documents and Settings\winetest\My Documents\foobar\foo\."', wanted '--- Complex wildcards unix and windows slash') batch.c:312: Test failed: unexpected char 0x57 position 0 in line 739 (got 'With duplicates enumeration', wanted '--- Complex wildcards unix and windows slash') batch.c:312: Test failed: unexpected char 0x47 position 0 in line 740 (got 'Got unexpected result: "C:\Documents"', wanted '--- Complex wildcards unix and windows slash') batch.c:312: Test failed: unexpected char 0x47 position 0 in line 741 (got 'Got unexpected result: "C:\Documents"', wanted '--- Complex wildcards unix and windows slash') batch.c:312: Test failed: unexpected char 0x47 position 0 in line 742 (got 'Got unexpected result: "C:\Documents"', wanted '--- Complex wildcards unix and windows slash') batch.c:312: Test failed: unexpected char 0x47 position 0 in line 743 (got 'Got unexpected result: "C:\Documents"', wanted '--- Complex wildcards unix and windows slash') batch.c:312: Test failed: unexpected char 0x47 position 0 in line 744 (got 'Got unexpected result: "C:\Documents"', wanted '--- Complex wildcards unix and windows slash') batch.c:312: Test failed: unexpected char 0x47 position 0 in line 745 (got 'Got unexpected result: "C:\Documents"', wanted '--- Complex wildcards unix and windows slash') batch.c:312: Test failed: unexpected char 0x47 position 0 in line 746 (got 'Got unexpected result: "C:\Documents"', wanted '--- Complex wildcards unix and windows slash') batch.c:312: Test failed: unexpected char 0x47 position 0 in line 747 (got 'Got unexpected result: "C:\Documents"', wanted '--- Complex wildcards unix and windows slash') batch.c:312: Test failed: unexpected char 0x47 position 0 in line 748 (got 'Got unexpected result: "C:\Documents"', wanted '--- Complex wildcards unix and windows slash') batch.c:312: Test failed: unexpected char 0x47 position 0 in line 749 (got 'Got unexpected result: "C:\Documents"', wanted '--- Complex wildcards unix and windows slash') batch.c:312: Test failed: unexpected char 0x47 position 0 in line 750 (got 'Got unexpected result: "C:\Documents"', wanted '--- Complex wildcards unix and windows slash') batch.c:312: Test failed: unexpected char 0x47 position 0 in line 751 (got 'Got unexpected result: "C:\Documents"', wanted '--- Complex wildcards unix and windows slash') batch.c:312: Test failed: unexpected char 0x46 position 0 in line 752 (got 'Found missing result: "C:\Documents and Settings\winetest\My Documents\foobar\bar\bazbaz"', wanted '--- Complex wildcards unix and windows slash') batch.c:312: Test failed: unexpected char 0x46 position 0 in line 753 (got 'Found missing result: "C:\Documents and Settings\winetest\My Documents\foobar\bar\fred"', wanted '--- Complex wildcards unix and windows slash') batch.c:312: Test failed: unexpected char 0x46 position 0 in line 754 (got 'Found missing result: "C:\Documents and Settings\winetest\My Documents\foobar\baz\bazbaz"', wanted '--- Complex wildcards unix and windows slash') batch.c:312: Test failed: unexpected char 0x46 position 0 in line 755 (got 'Found missing result: "C:\Documents and Settings\winetest\My Documents\foobar\baz\bazbaz"', wanted '--- Complex wildcards unix and windows slash') batch.c:312: Test failed: unexpected char 0x46 position 0 in line 756 (got 'Found missing result: "C:\Documents and Settings\winetest\My Documents\foobar\baz\bazbaz"', wanted '--- Complex wildcards unix and windows slash') batch.c:312: Test failed: unexpected char 0x46 position 0 in line 757 (got 'Found missing result: "C:\Documents and Settings\winetest\My Documents\foobar\baz\fred"', wanted '--- Complex wildcards unix and windows slash') batch.c:312: Test failed: unexpected char 0x46 position 0 in line 758 (got 'Found missing result: "C:\Documents and Settings\winetest\My Documents\foobar\bazbaz"', wanted '--- Complex wildcards unix and windows slash') batch.c:312: Test failed: unexpected char 0x46 position 0 in line 759 (got 'Found missing result: "C:\Documents and Settings\winetest\My Documents\foobar\bazbaz"', wanted '--- Complex wildcards unix and windows slash') batch.c:312: Test failed: unexpected char 0x46 position 0 in line 760 (got 'Found missing result: "C:\Documents and Settings\winetest\My Documents\foobar\bazbaz"', wanted '--- Complex wildcards unix and windows slash') batch.c:312: Test failed: unexpected char 0x46 position 0 in line 761 (got 'Found missing result: "C:\Documents and Settings\winetest\My Documents\foobar\foo\bazbaz"', wanted '--- Complex wildcards unix and windows slash') batch.c:312: Test failed: unexpected char 0x46 position 0 in line 762 (got 'Found missing result: "C:\Documents and Settings\winetest\My Documents\foobar\foo\fred"', wanted '--- Complex wildcards unix and windows slash') batch.c:312: Test failed: unexpected char 0x46 position 0 in line 763 (got 'Found missing result: "C:\Documents and Settings\winetest\My Documents\foobar\fred"', wanted '--- Complex wildcards unix and windows slash') batch.c:312: Test failed: unexpected char 0x53 position 0 in line 764 (got 'Strip missing wildcards, keep unwildcarded names', wanted '--- Complex wildcards unix and windows slash') batch.c:312: Test failed: unexpected char 0x47 position 0 in line 765 (got 'Got unexpected result: "C:\Documents"', wanted '--- Complex wildcards unix and windows slash') batch.c:312: Test failed: unexpected char 0x47 position 0 in line 766 (got 'Got unexpected result: "C:\Documents"', wanted '--- Complex wildcards unix and windows slash') batch.c:312: Test failed: unexpected char 0x47 position 0 in line 767 (got 'Got unexpected result: "C:\Documents"', wanted '--- Complex wildcards unix and windows slash') batch.c:312: Test failed: unexpected char 0x47 position 0 in line 768 (got 'Got unexpected result: "C:\Documents"', wanted '--- Complex wildcards unix and windows slash') batch.c:312: Test failed: unexpected char 0x47 position 0 in line 769 (got 'Got unexpected result: "C:\Documents"', wanted '--- Complex wildcards unix and windows slash') batch.c:312: Test failed: unexpected char 0x47 position 0 in line 770 (got 'Got unexpected result: "C:\Documents"', wanted '--- Complex wildcards unix and windows slash') batch.c:312: Test failed: unexpected char 0x46 position 0 in line 771 (got 'Found missing result: "C:\Documents and Settings\winetest\My Documents\foobar\bar\jim"', wanted '--- Complex wildcards unix and windows slash') batch.c:312: Test failed: unexpected char 0x46 position 0 in line 772 (got 'Found missing result: "C:\Documents and Settings\winetest\My Documents\foobar\baz\bazbaz"', wanted '--- Complex wildcards unix and windows slash') batch.c:312: Test failed: unexpected char 0x46 position 0 in line 773 (got 'Found missing result: "C:\Documents and Settings\winetest\My Documents\foobar\baz\jim"', wanted '--- Complex wildcards unix and windows slash') batch.c:312: Test failed: unexpected char 0x46 position 0 in line 774 (got 'Found missing result: "C:\Documents and Settings\winetest\My Documents\foobar\bazbaz"', wanted '--- Complex wildcards unix and windows slash') batch.c:312: Test failed: unexpected char 0x46 position 0 in line 775 (got 'Found missing result: "C:\Documents and Settings\winetest\My Documents\foobar\foo\jim"', wanted '--- Complex wildcards unix and windows slash') batch.c:312: Test failed: unexpected char 0x46 position 0 in line 776 (got 'Found missing result: "C:\Documents and Settings\winetest\My Documents\foobar\jim"', wanted '--- Complex wildcards unix and windows slash') batch.c:312: Test failed: unexpected char 0x66 position 0 in line 777 (got 'for /R passed', wanted '--- Complex wildcards unix and windows slash') batch.c:312: Test failed: unexpected char 0x46 position 0 in line 1361 (got 'Finished:', wanted 'value2') batch.c:312: Test failed: unexpected char 0x76 position 0 in line 1362 (got 'value2', wanted '2set1endvalue1') batch.c:312: Test failed: unexpected char 0x43 position 0 in line 1363 (got 'C:\Documents and Settings\winetest\My Documents\foobar\foodir2', wanted '@pwd@\foobar\foodir3') batch.c:312: Test failed: unexpected char 0x76 position 0 in line 1364 (got 'value1', wanted 'Finished:') batch.c:312: Test failed: unexpected char 0x43 position 0 in line 1365 (got 'C:\Documents and Settings\winetest\My Documents\foobar', wanted 'value2') batch.c:312: Test failed: unexpected char 0x2d position 0 in line 1366 (got '--- Extra endlocal in called batch', wanted '@pwd@\foobar\foodir2') batch.c:312: Test failed: unexpected char 0x2d position 0 in line 1367 (got '--- Extra endlocal in called batch', wanted 'value1') batch.c:312: Test failed: unexpected char 0x2d position 0 in line 1368 (got '--- Extra endlocal in called batch', wanted '@pwd@\foobar') batch.c:312: Test failed: unexpected char 0x46 position 0 in line 1370 (got 'Finished:', wanted 'value2') batch.c:312: Test failed: unexpected char 0x76 position 0 in line 1373 (got 'value1', wanted 'value2') batch.c:312: Test failed: unexpected char 0x43 position 0 in line 1374 (got 'C:\Documents and Settings\winetest\My Documents\foobar', wanted '@pwd@\foobar\foodir2') batch.c:312: Test failed: unexpected char 0x2d position 0 in line 1375 (got '--- endlocal in called function rather than batch pgm is ineffective', wanted 'Finished:') batch.c:312: Test failed: unexpected char 0x2d position 0 in line 1376 (got '--- endlocal in called function rather than batch pgm is ineffective', wanted 'value2') batch.c:312: Test failed: unexpected char 0x2d position 0 in line 1377 (got '--- endlocal in called function rather than batch pgm is ineffective', wanted '@pwd@\foobar\foodir2') batch.c:312: Test failed: unexpected char 0x2d position 0 in line 1378 (got '--- endlocal in called function rather than batch pgm is ineffective', wanted 'value1') batch.c:312: Test failed: unexpected char 0x2d position 0 in line 1379 (got '--- endlocal in called function rather than batch pgm is ineffective', wanted '@pwd@\foobar')

Oct. 16, 2013

Re: dispex/tests: Compile with -D__WINESRC__

by Dmitry Timoshkov

Nikolay Sivov <nsivov(a)codeweavers.com> wrote: > + PeekMessageA(&msg, NULL, WM_USER, WM_USER, PM_NOREMOVE); IMHO it would be much better to use W version of APIs while doing this cleanup. Same applies to all other your patches that prepare switching compilation to using -D__WINESRC__. -- Dmitry.

Oct. 16, 2013

Re: ole32/tests: Compile with -D__WINESRC__

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://newtestbot.winehq.org/JobDetails.pl?Key=2791 Your paranoid android. === wxppro (32 bit marshal) === marshal.c:2746: Test failed: wait timed out marshal.c:2750: Test failed: CoCreateInstance failed with error 0x80040154 marshal: unhandled exception c0000005 at 00419A9C === w864 (32 bit marshal) === marshal.c:3007: Test failed: info->cbSize was -1799139958 instead of 48 marshal.c:3008: Test failed: info->dwServerPid was 0x5bc instead of 0xbb8 marshal.c:3024: Test failed: info->cbSize was -1799139958 instead of 48 marshal.c:3025: Test failed: info->dwServerPid was 0x5bc instead of 0xbb8 marshal.c:3062: Test failed: info->cbSize was -1799139958 instead of 48 marshal.c:3063: Test failed: info->dwServerPid was 0x5bc instead of 0xbb8 marshal.c:3080: Test failed: info->cbSize was -1799139958 instead of 48 marshal.c:3081: Test failed: info->dwServerPid was 0x5bc instead of 0xbb8 marshal.c:3044: Test failed: info->cbSize was -1799139958 instead of 48 marshal.c:3045: Test failed: info->dwServerPid was 0x5bc instead of 0xbb8 marshal.c:3007: Test failed: info->cbSize was -1799139958 instead of 48 marshal.c:3008: Test failed: info->dwServerPid was 0x5bc instead of 0xbb8 marshal.c:3024: Test failed: info->cbSize was -1799139958 instead of 48 marshal.c:3025: Test failed: info->dwServerPid was 0x5bc instead of 0xbb8 marshal.c:3062: Test failed: info->cbSize was -1799139958 instead of 48 marshal.c:3063: Test failed: info->dwServerPid was 0x5bc instead of 0xbb8 marshal.c:3080: Test failed: info->cbSize was -1799139958 instead of 48 marshal.c:3081: Test failed: info->dwServerPid was 0x5bc instead of 0xbb8 marshal.c:3044: Test failed: info->cbSize was -1799139958 instead of 48 marshal.c:3045: Test failed: info->dwServerPid was 0x5bc instead of 0xbb8 marshal.c:3007: Test failed: info->cbSize was -1799139958 instead of 48 marshal.c:3008: Test failed: info->dwServerPid was 0x5bc instead of 0xbb8 marshal.c:3024: Test failed: info->cbSize was -1799139958 instead of 48 marshal.c:3025: Test failed: info->dwServerPid was 0x5bc instead of 0xbb8 marshal.c:3062: Test failed: info->cbSize was -1799139958 instead of 48 marshal.c:3063: Test failed: info->dwServerPid was 0x5bc instead of 0xbb8 marshal.c:3080: Test failed: info->cbSize was -1799139958 instead of 48 marshal.c:3081: Test failed: info->dwServerPid was 0x5bc instead of 0xbb8 marshal.c:3044: Test failed: info->cbSize was -1799139958 instead of 48 marshal.c:3045: Test failed: info->dwServerPid was 0x5bc instead of 0xbb8 === w864 (64 bit marshal) === marshal.c:3007: Test failed: info->cbSize was -432292180 instead of 56 marshal.c:3008: Test failed: info->dwServerPid was 0x8ac instead of 0xb44 marshal.c:3024: Test failed: info->cbSize was -432292180 instead of 56 marshal.c:3025: Test failed: info->dwServerPid was 0x8ac instead of 0xb44 marshal.c:3062: Test failed: info->cbSize was -432292180 instead of 56 marshal.c:3063: Test failed: info->dwServerPid was 0x8ac instead of 0xb44 marshal.c:3080: Test failed: info->cbSize was -432292180 instead of 56 marshal.c:3081: Test failed: info->dwServerPid was 0x8ac instead of 0xb44 marshal.c:3044: Test failed: info->cbSize was -432292180 instead of 56 marshal.c:3045: Test failed: info->dwServerPid was 0x8ac instead of 0xb44 marshal.c:3007: Test failed: info->cbSize was -432292180 instead of 56 marshal.c:3008: Test failed: info->dwServerPid was 0x8ac instead of 0xb44 marshal.c:3024: Test failed: info->cbSize was -432292180 instead of 56 marshal.c:3025: Test failed: info->dwServerPid was 0x8ac instead of 0xb44 marshal.c:3062: Test failed: info->cbSize was -432292180 instead of 56 marshal.c:3063: Test failed: info->dwServerPid was 0x8ac instead of 0xb44 marshal.c:3080: Test failed: info->cbSize was -432292180 instead of 56 marshal.c:3081: Test failed: info->dwServerPid was 0x8ac instead of 0xb44 marshal.c:3044: Test failed: info->cbSize was -432292180 instead of 56 marshal.c:3045: Test failed: info->dwServerPid was 0x8ac instead of 0xb44 marshal.c:3007: Test failed: info->cbSize was -432292180 instead of 56 marshal.c:3008: Test failed: info->dwServerPid was 0x8ac instead of 0xb44 marshal.c:3024: Test failed: info->cbSize was -432292180 instead of 56 marshal.c:3025: Test failed: info->dwServerPid was 0x8ac instead of 0xb44 marshal.c:3062: Test failed: info->cbSize was -432292180 instead of 56 marshal.c:3063: Test failed: info->dwServerPid was 0x8ac instead of 0xb44 marshal.c:3080: Test failed: info->cbSize was -432292180 instead of 56 marshal.c:3081: Test failed: info->dwServerPid was 0x8ac instead of 0xb44 marshal.c:3044: Test failed: info->cbSize was -432292180 instead of 56 marshal.c:3045: Test failed: info->dwServerPid was 0x8ac instead of 0xb44

Oct. 16, 2013

Re: Video Mixing Renderer 7

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2013-10-15 22:12, schrieb Henri Verbeet: > I'm not very familiar with quartz / VMR, but I guess the main > question would be how applications can tell the difference between > a d3d9 and a ddraw implementation. It looks like there are some ways an application can create its own DirectDraw object and pass it to VMR-7: http://msdn.microsoft.com/en-us/library/windows/desktop/dd375451(v=vs.85).a… . But that's just my conclusion from reading MSDN for 5 minutes, so I might be wrong. Other things to look for is API methods that accept or return an IDirectDraw* object, or COM aggregation tricks which would allow applications to QueryInterface DirectDraw objects from VMR-7 objects. I could also imagine that VMR-7 supports additional pixel formats like YV12. D3d9 usually supports only YUY2 and UYVY surfaces. In ddraw, support for YV12 overlays is fairly widespread, and some drivers offer additional overlay formats. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSXcdLAAoJEN0/YqbEcdMwOoIP/24iI2LCQrTfbKQbd4Qew4ea HNVTvBLrh1OT7QHVK7dVXbvfbh6PjMJDuHdGv0Pkoex7R3vr+YRYkZJPPZTonNfo l2eQlcCjbSwBxl6Y8SD/CulrEJiL10N1s2Bs9AlNXq0TtM7dbDelyAY6nBWQkZSj oGPpkYfLE20yJQhH+dMlHvD56YICwDO+vGWqV6BDe/93xWBAFUQP8Xyjx1D2QjQO Hfke4Oi9B9Ge8AWg0J7pLp+Z1RfTlbH/akJ8KR/bJQ6LKeCfjkm9Y5Wl8A1U9jVP fJcXP9L44c8MJOyh062yPFrWJlJzev0usDorgxVZATiIsO2M8GgCyTpZBa77fIth TAwHbWKi/0AhV1AWU+Qq4Zi/9A6xfd2jFMVWOJsvviloYwCyOe6pnwAr+tnhewq8 R6dPBP5bDcv4U35sP0+d06rjt8QH7wA0190K9Rc5UusdUAeam7uFe2TB2DyD0Ncl N/vFrBGnN/3HiQl6GxsDvHvyBu87xa8lZJ3GfUHqm7sENRfk312ypurYFtAhi4qN 8d0KjnKRY2wnt1EclL1ZD3qVpfpuFbJTgLi7NfBIE8rrTfbMSDaIJ3d1zwpUn7ms qAgT5jCDanJYsdJZoykPfd/93rOnFzL6IEYMk6Bbjrggv6jlsZCFs6UCXdsHDGvK oz6sXgH4B6xFVXOmDTb/ =e4lK -----END PGP SIGNATURE-----

Oct. 15, 2013

Re: Request for a possible inclusion of the Wineasio driver?

by jordan

Hey Jack, The biggest problem is that the ASIO API is defined in the asio.h > header file distributed by Steinberg in their ASIO SDK, and that the > license explicitly forbids the distribution of any component by a third > party. I imagine that this situation is not new to the Wine project > and similar to other SDKs needed. I have a header file which I have > created by compiling the driver without including asio.h, and then > typing in the needed defines and structures while consulting asio.h. > The header makes the driver work in both 32 and 64 bit wine. > I had read about your header earlier this year in the wine forums and had thought/assumed, judging by this post ~ that you may have decided to put it in your repo (i see you have updated wineasio, recently)...Obviously, that header is not there, so i am curious; could you possibly make it available? I'd like to try out x64 version of wineASIO, being as i avoid 32bit / don't use 32bit applications in Wine. ..and just on a general note: if there is a way to resolve/workaround the asio.h issue, it would be fantastic to see WineASIO included in Wine. cheers jordan

Oct. 15, 2013

Request for a possible inclusion of the Wineasio driver?

by Joakim Hernberg

I am the maintainer of a driver for Wine on Linux called Wineasio. I'd like to find a home for the code and am hoping to convince you of adding it to the Wine codebase. ASIO is an API developed by Steinberg for supporting low latency audio hardware under Windows. Each hardware manufacturer uses Steinberg's SDK to create a driver supporting their own hardware. Software using the API is normally audio related such as Digital Audio Workstations, virtual instruments and other music production software. On Linux, Wineasio interfaces directly with the Jack audio API, and runs on all hardware supported by Jack, which nowdays is the vast majority on audio hardware supported in linux. On OS/X a derrived driver called Coreasio has been created, and is in use by Image-line's FLS port. Jack runs on Linux, Solaris, FreeBSD, OS/X, iOS and Windows, so in theory it ought to be possible to support Wineasio on all platforms supported by Wine. I don't know the details on how Coreasio works, but in the case of Wineasio, the driver links directly to the Jack server's client libs, so there is no need to alter any existing parts of Wine's audiostack nor to reimplement and maintain a Jack driver for Wine itself. The only change needed is to include the driver in the source tree. The driver implements all the core functionality of the API, only some optional and obscure parts of the API are missing. It has been in use for years on 32 bit Wine and does not appear to have any showstopping bugs, if any at all. I've personally used it for over a year on 64 bit Wine, and I know of some other people who use it without problems on 64 bit too. The API is stable and hasn't been changed nor expanded by Steinberg for many years. It has been tested with audio production software like Reaper and FLS, with virtual instruments, amp simulations and other FX software from companies like Native Instruments, Ik Multimedia, Toontracks, Celemony and many others. The biggest problem is that the ASIO API is defined in the asio.h header file distributed by Steinberg in their ASIO SDK, and that the license explicitly forbids the distribution of any component by a third party. I imagine that this situation is not new to the Wine project and similar to other SDKs needed. I have a header file which I have created by compiling the driver without including asio.h, and then typing in the needed defines and structures while consulting asio.h. The header makes the driver work in both 32 and 64 bit wine. I propose to undertake the following: 1. Fix up the Wineasio code to confirm to Wine conventions and coding practices. 2. Merge it into Wine for conditional compilation on linux with Jack as a dependency. 3. Work together with the Wine project to merge in coreasio support for use on OS X. The latest sourcecode of the project is available at: git://git.code.sf.net/p/wineasio/code wineasio-git or as a tarball from: http://sourceforge.net/projects/wineasio/ Is this something that has any chance of getting accepted into Wine? -- Joakim

Oct. 15, 2013

Re: Video Mixing Renderer 7

by Henri Verbeet

On 15 October 2013 21:52, Michael Müller <michael(a)fds-team.de> wrote: > The most similar way to Windows would be to completely rewrite the > current implementation of the VMR9 as VMR7 using DirectDraw, which would > take a lot of time and most probably end up in having a lot of duplicate > code. I am wondering whether using d3d9 for VMR7 would also be an > acceptable solution. We could move all the d3d9 related stuff to a > separate file so that VMR7.c and VMR9.c only offer the version specific > interfaces and use the same code internally. This shouldn't be a big > problem since the differences between the VMR7 and VMR9 interfaces are > often only very small. Though it would not completely fit the behavior > of windows. > I'm not very familiar with quartz / VMR, but I guess the main question would be how applications can tell the difference between a d3d9 and a ddraw implementation. On the other hand, the amount of d3d9 specific code in vmr9.c looks pretty manageable at first sight.

Oct. 15, 2013

FOSDEM '14 Call for Papers

by Jeremy White

Folks, There will a Wine devroom at FOSDEM '14 on Sunday, February 2, 2014. Last year we had a great time, and I think it was valuable for us to connect with the broader Free software community. I'd like to now invite you to submit proposals for talks. I'd really like to encourage everyone to think of something fun to share with the 5,000 geeks that will be swarming Brussels. If you have an topic you'd like to discuss, or an idea you want to present, please submit it to: https://penta.fosdem.org/submission You will create an account (if you don't have one from a previous year), and select the "Wine devroom" as the track. Please either submit for lengths of 30 or 60 minutes. The deadline for submissions is December 1st. I think it would be great if we branched out a bit, and submitting a crazy off the wall proposal will just burn churn a few electrons. So submit it! For further discussion, please follow up to wineconf(a)winehq.org. Cheers, Jeremy

Oct. 15, 2013

Re: wined3d: Initialize map_desc in wined3d_surface_map

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2013-10-15 20:34, schrieb Marvin: > === w864 (32 bit device) === device.c:5409: Test failed: pBits not > cleared on double lock. device.c:5410: Test failed: Pitch not > cleared on double lock. device: unhandled exception c0000005 at > 742814C8 I'm surprised that the testbot executes those tests. Did you run those tests on a real Windows machine? If you want I can test them for you on a variety of windows versions and GPUs here. If the tests pass on a real windows, I'm tempted to call the Windows 8 behavior broken. It's either a change in Windows 8 itself, or the driver that is used in this VM. If you believe that this is a problem in the test VM rather than your patch, you can mark the behavior broken with a construct like this: ok(locked_rect.pBits == NULL || broken(locked_rect.pBits == (void *)0xdeadbeef), ...) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSXZ3FAAoJEN0/YqbEcdMwNTcP/Ry50Jc1DhZE9xmhl3s79EsK 966lSbOpEZvfZMw6rEn9LDf8oDcwCfmSDYDn/Eb4ICh23KNZeiEsGI7Ky8wXEhpF 1FEKxJ4rFTx644mwuxR8NrpE+LTdGV5bYlnL8oVuzJ3uNYtpvvjnUW8Z9azNzzKz 23FMv3TeAcZZXJpWn8Voi8sLVBJwjH/ufA4p/gHTbUyVK1YDXAigW6EEoW0y+ST3 iVqdRAiwVWkiWMBermRuO9/FPe3Kxsyn4nPIO0fd5ndekun9Ejlk9S6/P471xic8 dr2tIsgr41xEDuIxqNXunTf6hJOBuOiIu59DL3wWqh6oT+J8Iy3VVt+HpjwQGpvN fWhWnOv3H+4RPeap1nbVB2Iu1z/QB63xlQBd2fnFpYnyj/4IpF3mS9Gk4nTTVgLd QPeH9XGCOb6V859lO0PBDAvzsMGZ0205SZyDP+IuaxZ5mcAB6/GXbT3bPFXYpk4/ g9QPP5CL/m/43NNR/FmOHB7cxAW9Np/Q3mfA6LLcdUJCDJ9VztzkV+6UtRFEybqw O2vWfYV3mFbJidY0vX1OpaMeb6X35kEy59Cj1PCEDVdeCSjU+eTAqcRd5n7pVtrm /tz6c2fRJrRBJRRsxwZDV9BJhp2WSDlntALiwHvdQjftEuZHw1dtyqLxrYI9Lll2 iXho0aH7S2gvBZY3iZnI =/llD -----END PGP SIGNATURE-----

Oct. 15, 2013

Video Mixing Renderer 7

by Michael Müller

Hi, I am wondering what would be the best way to handle programs which rely on the Video Mixing Renderer 7 (quartz.dll) as it's supposed to be available on XP and later, but Wine contains only an implementation of version 9. The program I am speaking of is Silverlight which uses the VMR 7 Interface to create a filter graph and then queries for the IAMCertifiedOutputProtection interface. I am currently using a hack fix to get around this by returning a VMR9 instance when a VMR7 is requested and implementing the missing subinterfaces (which are only part of VMR7). This solution is clearly not perfect and I am searching for a better way to get around this issue. The most similar way to Windows would be to completely rewrite the current implementation of the VMR9 as VMR7 using DirectDraw, which would take a lot of time and most probably end up in having a lot of duplicate code. I am wondering whether using d3d9 for VMR7 would also be an acceptable solution. We could move all the d3d9 related stuff to a separate file so that VMR7.c and VMR9.c only offer the version specific interfaces and use the same code internally. This shouldn't be a big problem since the differences between the VMR7 and VMR9 interfaces are often only very small. Though it would not completely fit the behavior of windows. I am open for other ideas on how to solve the problem, but as Silverlight does not even use the VMR7 object for playing the video but only to check for the graphic driver certificate I don't think it would justify to rewrite everything using Direct Draw if there are no other programs needing this interface. Best Regards, Michael Müller

Oct. 15, 2013

We're in at FOSDEM!

by Jeremy White

Hey folks, I thought I'd let everyone know that I applied for and we have been granted a room at FOSDEM again this year. I'm going to send a 'Call for Papers' separately. Cheers, Jeremy

Oct. 15, 2013

Video Mixing Renderer 7

by Michael Müller

Hi, I am wondering what would be the best way to handle programs which rely on the Video Mixing Renderer 7 (quartz.dll) as it's supposed to be available on XP and later, but Wine contains only an implementation of version 9. The program I am speaking of is Silverlight which uses the VMR 7 Interface to create a filter graph and then queries for the IAMCertifiedOutputProtection interface. I am currently using a hack fix to get around this by returning a VMR9 instance when a VMR7 is requested and implementing the missing subinterfaces (which are only part of VMR7). This solution is clearly not perfect and I am searching for a better way to get around this issue. The most similar way to Windows would be to completely rewrite the current implementation of the VMR9 as VMR7 using DirectDraw, which would take a lot of time and most probably end up in having a lot of duplicate code. I am wondering whether using d3d9 for VMR7 would also be an acceptable solution. We could move all the d3d9 related stuff to a separate file so that VMR7.c and VMR9.c only offer the version specific interfaces and use the same code internally. This shouldn't be a big problem since the differences between the VMR7 and VMR9 interfaces are often only very small. Though it would not completely fit the behavior of windows. I am open for other ideas on how to solve the problem, but as Silverlight does not even use the VMR7 object for playing the video but only to check for the graphic driver certificate I don't think it would justify to rewrite everything using Direct Draw if there are no other programs needing this interface. Best Regards, Michael Müller

Oct. 15, 2013

Re: wined3d: Initialize map_desc in wined3d_surface_map

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://newtestbot.winehq.org/JobDetails.pl?Key=2785 Your paranoid android. === w864 (32 bit device) === device.c:5409: Test failed: pBits not cleared on double lock. device.c:5410: Test failed: Pitch not cleared on double lock. device: unhandled exception c0000005 at 742814C8 === w864 (64 bit device) === device.c:5409: Test failed: pBits not cleared on double lock. device.c:5410: Test failed: Pitch not cleared on double lock. device: unhandled exception c0000005 at 000007F84EDD90EB

Oct. 15, 2013

Re: wined3d: Initialize map_desc in wined3d_surface_map

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://newtestbot.winehq.org/JobDetails.pl?Key=2784 Your paranoid android. === w864 (32 bit device) === device.c:2481: Test failed: Expected foreground window 000401A6, got 00010084. device.c:3174: Test failed: Expected wndproc 0x4107a0, got 0x4107a0. device: unhandled exception c0000005 at 742F14C8

Oct. 15, 2013

Re: d3d9: update locked_rect only if wined3d_surface_map succeeded (try 3)

by Henri Verbeet

On 15 October 2013 18:10, Nikolay Sivov <bunglehead(a)gmail.com> wrote: >> diff --git a/dlls/d3d9/tests/device.c b/dlls/d3d9/tests/device.c >> index 02b4174..90d5c38 100644 >> --- a/dlls/d3d9/tests/device.c >> +++ b/dlls/d3d9/tests/device.c >> @@ -5404,6 +5404,10 @@ static void test_lockrect_invalid(void) >> ok(SUCCEEDED(hr), "Failed to lock surface with rect NULL, hr >> %#x.\n", hr); >> hr = IDirect3DSurface9_LockRect(surface, &locked_rect, NULL, 0); >> ok(hr == D3DERR_INVALIDCALL, "Got unexpected hr %#x.\n", hr); >> + locked_rect.pBits = (BYTE *)0xdeadbeef; >> + hr = IDirect3DSurface9_LockRect(surface, &locked_rect, NULL, 0); >> + ok(!SUCCEEDED(hr) && locked_rect.pBits == NULL, "Failed to clear >> pBits (%p)\n", >> + locked_rect.pBits); >> hr = IDirect3DSurface9_UnlockRect(surface); >> ok(SUCCEEDED(hr), "Failed to unlock surface, hr %#x.\n", hr); >> > > It looks like you could use existing LockRect() call that's already tested > as failing. Also I think FAILED() is a preferred way to > test HRESULT value for failure, but as existing code does - you could also > test for exact failure code. > Yeah, I think it really just needs the intialization of pBits before the existing LockRect() call, and an extra ok() call after the existing one.

Oct. 15, 2013

Re: d3d9: update locked_rect only if wined3d_surface_map succeeded (try 3)

by Lasse Rasinen

Marvin <testbot(a)winehq.org> writes: > === w864 (32 bit device) === > device.c:5409: Test failed: Failed to clear pBits (DEADBEEF) > device: unhandled exception c0000005 at 742814C8 > > === w864 (64 bit device) === > device.c:5409: Test failed: Failed to clear pBits (00000000DEADBEEF) > device: unhandled exception c0000005 at 000007F84EDD90EB As I'm doing drive-by patching to fix My Favorite App, I have no idea what can possibly be the problem here. If someone could shed some light on why w864 behaves differently from the other systems, that would be appreciated. -- Lasse Rasinen lrasinen(a)iki.fi

Oct. 15, 2013

Re: d3d9: update locked_rect only if wined3d_surface_map succeeded (try 3)

by Nikolay Sivov

On 10/15/2013 18:57, Lasse Rasinen wrote: > According to debugging output, Artemis Spaceship Bridge Simulator 2.0 > calls LockRect twice on the same texture (for whatever reason) and crashes. > > http://bugs.winehq.org/show_bug.cgi?id=34271 > > The return values are cleared explicitly --- game is playable. > > Now with appropriate assignments and test output. > --- > dlls/d3d9/surface.c | 9 +++++++-- > dlls/d3d9/tests/device.c | 4 ++++ > 2 files changed, 11 insertions(+), 2 deletions(-) > > diff --git a/dlls/d3d9/surface.c b/dlls/d3d9/surface.c > index 99f0b0f..20ccc68 100644 > --- a/dlls/d3d9/surface.c > +++ b/dlls/d3d9/surface.c > @@ -293,8 +293,13 @@ static HRESULT WINAPI d3d9_surface_LockRect(IDirect3DSurface9 *iface, > hr = wined3d_surface_map(surface->wined3d_surface, &map_desc, rect, flags); > wined3d_mutex_unlock(); > > - locked_rect->Pitch = map_desc.row_pitch; > - locked_rect->pBits = map_desc.data; > + if (SUCCEEDED(hr)) { > + locked_rect->Pitch = map_desc.row_pitch; > + locked_rect->pBits = map_desc.data; > + } else { > + locked_rect->Pitch = 0; > + locked_rect->pBits = NULL; > + } > > return hr; > } > diff --git a/dlls/d3d9/tests/device.c b/dlls/d3d9/tests/device.c > index 02b4174..90d5c38 100644 > --- a/dlls/d3d9/tests/device.c > +++ b/dlls/d3d9/tests/device.c > @@ -5404,6 +5404,10 @@ static void test_lockrect_invalid(void) > ok(SUCCEEDED(hr), "Failed to lock surface with rect NULL, hr %#x.\n", hr); > hr = IDirect3DSurface9_LockRect(surface, &locked_rect, NULL, 0); > ok(hr == D3DERR_INVALIDCALL, "Got unexpected hr %#x.\n", hr); > + locked_rect.pBits = (BYTE *)0xdeadbeef; > + hr = IDirect3DSurface9_LockRect(surface, &locked_rect, NULL, 0); > + ok(!SUCCEEDED(hr) && locked_rect.pBits == NULL, "Failed to clear pBits (%p)\n", > + locked_rect.pBits); > hr = IDirect3DSurface9_UnlockRect(surface); > ok(SUCCEEDED(hr), "Failed to unlock surface, hr %#x.\n", hr); > It looks like you could use existing LockRect() call that's already tested as failing. Also I think FAILED() is a preferred way to test HRESULT value for failure, but as existing code does - you could also test for exact failure code.

Oct. 15, 2013

Re: d3d9: update locked_rect only if wined3d_surface_map succeeded (try 3)

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://newtestbot.winehq.org/JobDetails.pl?Key=2783 Your paranoid android. === w864 (32 bit device) === device.c:5409: Test failed: Failed to clear pBits (DEADBEEF) device: unhandled exception c0000005 at 742814C8 === w864 (64 bit device) === device.c:5409: Test failed: Failed to clear pBits (00000000DEADBEEF) device: unhandled exception c0000005 at 000007F84EDD90EB

Oct. 15, 2013

Re: d3d9: update locked_rect only if wined3d_surface_map succeeded (try 3)

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2013-10-15 16:57, schrieb Lasse Rasinen: > - locked_rect->Pitch = map_desc.row_pitch; - > locked_rect->pBits = map_desc.data; + if (SUCCEEDED(hr)) { + > locked_rect->Pitch = map_desc.row_pitch; + > locked_rect->pBits = map_desc.data; + } else { + > locked_rect->Pitch = 0; + locked_rect->pBits = NULL; + } You can handle this in wined3d/surface.c, wined3d_surface_map. Also, please follow the code style of the existing code. Curly brackets go in their own line. > + locked_rect.pBits = (BYTE *)0xdeadbeef; + hr = > IDirect3DSurface9_LockRect(surface, &locked_rect, NULL, 0); + > ok(!SUCCEEDED(hr) && locked_rect.pBits == NULL, "Failed to clear > pBits (%p)\n", + locked_rect.pBits); For the sake of completeness, please also test locked_rect.Pitch and port the test to d3d8. Ddraw already has a test in dsurface.c. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSXVwzAAoJEN0/YqbEcdMw1CQP/2Lk2v78Ws8BGh1x4MvaXj/x YhJQ1d44bqP9B8+H7E3NKWuwZ6ywNmxvH+Mq59nbNKdfBrxvTezIA2PDLEsNwWJa hl/Q4St61K1XkExmu+48tyxtT3BS8P2g60Z50V8VIfrUh/3qqquXq79tki9XqYSr vtuFLuJyHECzYq7hQ+BZqbudwSSf42ZQfX0wNpa4wuZ2uX/PzA4ku0R/zvHzaMTh HoOrlIxX9hvCF/y5y7v0SAeYT83nMCkUBOZ8EMoDqv81btLDCqdFedtlFz2gTO0P O2vaGzSH0NPU+umIU9rEXUwq3H2gJdFcTG4FujQNsoVSaliXz24OzVTCEc1PvuWz eo+zMhxfG05xNSsb6Yh+fATnOPP6YDWYukS42kmalZ+V5WGlwxxKd4jgfONjCqzH JsIcqbmlxkWN9bPB9k3mIMMDHZ1PClI3GFm1XVMnc4Vas2/FF/IAAK/yPpIV2O/R fJkz4PKcha8P9V/yNlGJrmHYq/Dy7mW9xANmQ4gKv9wm0iqHoUGrDorX7OptskHL ua0pOFmWIXHRtzFysctZ/w6QkKX/e9Vwh/hRWIBhN2JOliu5AZuqQESbqe/rCwZR Flje6p9RaxlqgIzxxK1GQawpQ05NP3y8oS1MIe+mGr4c6sk8KO5d6aUgNVo4jcdY 4OAnKqN3lNbqDZgNEg91 =32E8 -----END PGP SIGNATURE-----

Oct. 15, 2013

Re: d3d9: update locked_rect only if wined3d_surface_map succeeded (try 2)

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://newtestbot.winehq.org/JobDetails.pl?Key=2776 Your paranoid android. === w864 (32 bit device) === device.c:5409: Test failed: Failed to clear pBits (DEADBEEF)device.c:5588: Tests skipped: Failed to create surface for format D3DFMT_R8G8B8 (hr 0x8876086c), skipping tests. device: unhandled exception c0000005 at 740D14C8 === w864 (64 bit device) === device.c:5409: Test failed: Failed to clear pBits (00000000DEADBEEF)device.c:5588: Tests skipped: Failed to create surface for format D3DFMT_R8G8B8 (hr 0x8876086c), skipping tests. device: unhandled exception c0000005 at 000007F84EDD90EB

Oct. 15, 2013