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

Re: vbscript: Added support for hex literals not ending with '&'

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=14970 Your paranoid android. === WNT4WSSP6 (32 bit) === No test summary line found === W2KPROSP4 (32 bit) === No test summary line found === WXPPROSP3 (32 bit) === No test summary line found === W2K3R2SESP2 (32 bit) === No test summary line found === WVISTAADM (32 bit) === No test summary line found === W2K8SE (32 bit) === No test summary line found === W7PRO (32 bit) === No test summary line found === W7PROX64 (32 bit) === No test summary line found === TEST64_W7SP1 (32 bit) === No test summary line found === W7PROX64 (64 bit) === No test summary line found === TEST64_W7SP1 (64 bit) === No test summary line found

Oct. 18, 2011

Re: Regression testing breakthrough

by Henri Verbeet

On 18 October 2011 10:45, Damjan Jovanovic <damjan.jov(a)gmail.com> wrote: > (especially during "reverse regression testing"), users find it too long and > technical, and only a small minority of regressions are ever bisected. And Not true. Even for the regressions that are still open it's currently 276 bisected vs. 99 not bisected, and Alexandre said about 90% of opened regressions get fixed. > I haven't figured out how to make the binaries available to users. Few users > can clone a 26 gigabyte repository, and even fewer places can serve that > much to multiple users. Maybe Git can compress it further? The other idea I > had is that users should be able to regression test through a GUI tool. > Maybe the GUI tool can just download and run the +/- 122 MB binary snapshots > for specific commits, instead of having the entire binary repository > locally? > > Any other ideas? Would you like to see this tool? Can I send an attachment > with it? > Scripts for making old versions compile may be useful, but for the most part it sounds like you're essentially duplicating ccache.

Oct. 18, 2011

Re: Regression testing breakthrough

by Ferenc Gergely Szilagyi

On Tue, Oct 18, 2011 at 10:45 AM, Damjan Jovanovic <damjan.jov(a)gmail.com>wrote: > Hi > > Since the beginning, I've had issues with regression testing. Despite the > fact it's very useful, it takes forever, it's easy to make a mistake > (especially during "reverse regression testing"), users find it too long and > technical, and only a small minority of regressions are ever bisected. And > several patches need backporting to allow older versions of Wine to compile > and run on today's make, gcc, and libraries - this is the case even for the > 1.0.x releases from less than 3 years ago! > > The problem is of course compilation. "configure" takes at least 40 > seconds, without any way to speed it up on multi-core CPUs. "make" takes > 5 > minutes, and it's only taking longer as Wine gets bigger. Compilation is > fundamentally complex and technical to users. > > But what if we had precompiled binaries, and regression testing consisted > of just running different versions of Wine? > > Wine binaries take up about 122 MB and take over 5 minutes to compile. > There's now 35770 commits between 36def4af0ca85a1d0e66b5207056775bcb3b09ff > (Release 1.0) and "origin". That's about 4.4 terrabytes of storage and over > 4 months of compilation, if each of those versions had to be compiled and > installed into its own prefix, way beyond what most users are willing or > able to store or do. Most patches however end up affecting only a few binary > files in the end, and compiling successive versions allows "make" to be very > quick. > > So I've written a tool that compiles Wine and adds each commit's binaries > into a Git repository. It knows how to compile old versions of Wine > (currently as far back as 1.0). It knows that commits affecting only > ANNOUNCE, .gitignore, and files in dll/ or programs/ ending with .c and such > don't need to go through the endlessly slow "configure", only "make". It is > stateless: if interrupted, it can resume from the last successful commit. It > works around bugs in GNU make (you won't believe how many there are...). > > This tool compiled all 35000 or so commits from Wine 1.0 to around 4th > October 2011 in only 7 days, generating a Git repository of Wine binaries > that's only 26 gigabytes in size. Regression testing with binaries is a > pleasure: it takes only a few seconds :-) on each bisection. I bisected a 16 > step regression in just 20 minutes, and most of that time was spent running > the application and dealing with 2 X-server crashes. > > I haven't figured out how to make the binaries available to users. Few > users can clone a 26 gigabyte repository, and even fewer places can serve > that much to multiple users. Maybe Git can compress it further? The other > idea I had is that users should be able to regression test through a GUI > tool. Maybe the GUI tool can just download and run the +/- 122 MB binary > snapshots for specific commits, instead of having the entire binary > repository locally? > > Any other ideas? Would you like to see this tool? Can I send an attachment > with it? > > Thank you > Damjan Jovanovic > > Hi, while I agree that 26 GB is a lot for most people, it would be no problem for me. Long compilation times were exactly the most important factor that kept me away from testing regressions so far. And I think I am not the only one on this side, so even if the repository is that huge, I think it might still worth to grant at least a few people the possibility to clone it. If I could arrange with my VPS provider to buy more disk space, I would even be willing to hold a mirror of it online. I would also definiately like to see how it is all achieved. Regards, Ferenc Gergely Szilagyi

Oct. 18, 2011

Regression testing breakthrough

by Damjan Jovanovic

Hi Since the beginning, I've had issues with regression testing. Despite the fact it's very useful, it takes forever, it's easy to make a mistake (especially during "reverse regression testing"), users find it too long and technical, and only a small minority of regressions are ever bisected. And several patches need backporting to allow older versions of Wine to compile and run on today's make, gcc, and libraries - this is the case even for the 1.0.x releases from less than 3 years ago! The problem is of course compilation. "configure" takes at least 40 seconds, without any way to speed it up on multi-core CPUs. "make" takes > 5 minutes, and it's only taking longer as Wine gets bigger. Compilation is fundamentally complex and technical to users. But what if we had precompiled binaries, and regression testing consisted of just running different versions of Wine? Wine binaries take up about 122 MB and take over 5 minutes to compile. There's now 35770 commits between 36def4af0ca85a1d0e66b5207056775bcb3b09ff (Release 1.0) and "origin". That's about 4.4 terrabytes of storage and over 4 months of compilation, if each of those versions had to be compiled and installed into its own prefix, way beyond what most users are willing or able to store or do. Most patches however end up affecting only a few binary files in the end, and compiling successive versions allows "make" to be very quick. So I've written a tool that compiles Wine and adds each commit's binaries into a Git repository. It knows how to compile old versions of Wine (currently as far back as 1.0). It knows that commits affecting only ANNOUNCE, .gitignore, and files in dll/ or programs/ ending with .c and such don't need to go through the endlessly slow "configure", only "make". It is stateless: if interrupted, it can resume from the last successful commit. It works around bugs in GNU make (you won't believe how many there are...). This tool compiled all 35000 or so commits from Wine 1.0 to around 4th October 2011 in only 7 days, generating a Git repository of Wine binaries that's only 26 gigabytes in size. Regression testing with binaries is a pleasure: it takes only a few seconds :-) on each bisection. I bisected a 16 step regression in just 20 minutes, and most of that time was spent running the application and dealing with 2 X-server crashes. I haven't figured out how to make the binaries available to users. Few users can clone a 26 gigabyte repository, and even fewer places can serve that much to multiple users. Maybe Git can compress it further? The other idea I had is that users should be able to regression test through a GUI tool. Maybe the GUI tool can just download and run the +/- 122 MB binary snapshots for specific commits, instead of having the entire binary repository locally? Any other ideas? Would you like to see this tool? Can I send an attachment with it? Thank you Damjan Jovanovic

Oct. 18, 2011

Re: [4/7] wined3d: YUY2 and UYVY are block based

by Stefan Dösinger

On Monday 17 October 2011 20:32:43 Henri Verbeet wrote: > That's mostly a limitation of the individual blitters. You could > certainly make YUY2 and UYVY work with e.g. FBO blits as long as you > only blit on block boundaries, and I wouldn't be all that surprised if > you have to blit on block boundaries anyway in D3D. Only as long as you don't have to filter. When the sizes don't match even point filters break, even if you're reading and writing on block boundaries. But you could handle that in a fragment shader if the circumstances allow you to calculate the values for the whole block in each shader run. Should be possible for blits at least.

Oct. 17, 2011

Re: Still need patch review please (wineps.drv)

by Daniel Santos

Oh, but I forgot to add that it does fix the problem (Finale 2010 prints dashed lines correctly now). http://bugs.winehq.org/show_bug.cgi?id=26091 On 10/17/2011 03:53 PM, Daniel Santos wrote: > Of particular concern is making sure my dynamically allocated memory is > being freed. The new data is stored in PSPEN and is allocated when > SelectObject (on a wineps.drv device of course) passing a pen and is > freed whenever a subsequent pen is selected or the device context is > deleted. > > I'm just not intimately familiar enough with this part of the API to > know for certain that this eliminates all room for leaks. > > Thanks! > Daniel

Oct. 17, 2011

Still need patch review please (wineps.drv)

by Daniel Santos

Of particular concern is making sure my dynamically allocated memory is being freed. The new data is stored in PSPEN and is allocated when SelectObject (on a wineps.drv device of course) passing a pen and is freed whenever a subsequent pen is selected or the device context is deleted. I'm just not intimately familiar enough with this part of the API to know for certain that this eliminates all room for leaks. Thanks! Daniel

Oct. 17, 2011

Re: [4/7] wined3d: YUY2 and UYVY are block based

by Henri Verbeet

On 17 October 2011 19:54, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > The fixup is a separate issue. We can write to formats with fixups just fine if > the input is in the correct format or we have a shader that can convert TO > that format. The problem with the blocks is that if one pixel is modified the > entire block may have to be modified, and we can't do that even with shaders. > So we can't blit to e.g. YUY2 surfaces even if the input is YUY2 as well and > the underlying luminance-alpha textures may be fbo attachable. > That's mostly a limitation of the individual blitters. You could certainly make YUY2 and UYVY work with e.g. FBO blits as long as you only blit on block boundaries, and I wouldn't be all that surprised if you have to blit on block boundaries anyway in D3D. YV12 would be harder, but at least d3d10/11 hardware could probably do it.

Oct. 17, 2011

Re: [4/7] wined3d: YUY2 and UYVY are block based

by Stefan Dösinger

On Monday 17 October 2011 15:38:18 Henri Verbeet wrote: > I think the "gl_" prefix is somewhat questionable since the format > being compressed or not is a property of the D3D format, it doesn't > depend on what GL format we use, at least in the way the flag is > currently used. You can change the meaning of the flag to be specific > to the GL format, but then you'd have to set it in the > format_texture_info[] table. The idea is to mark formats that need glCompressedTexImage2D instead of glTexImage2D, so format_texture_info sounds about right. > > + /* Block-based formats can't be rendered to with FBOs even if GL > > accepts them + * (e.g. WINED3DFMT_YV12, which is just a GL_ALPHA > > texture). Even fragment shaders + * can't account for that if a > > block is partially drawn. > > There's no such restriction on the GL side, the internal format just > has to be color-renderable. The reason we can't render directly to > these is because there a fixup associated with the format, but that > has nothing to do with either being FBO-attachable or being > block-based, and applies to e.g. P8 as well. The fixup is a separate issue. We can write to formats with fixups just fine if the input is in the correct format or we have a shader that can convert TO that format. The problem with the blocks is that if one pixel is modified the entire block may have to be modified, and we can't do that even with shaders. So we can't blit to e.g. YUY2 surfaces even if the input is YUY2 as well and the underlying luminance-alpha textures may be fbo attachable. But following the logic of the compressed flag above, that should also be part of the format defintion in format_texture_info[]. When a native GL format is used(e.g. GL_APPLE_ycbcr_422 or standard s3tc) the check if the format is FBO attachable should be used. I can also move this to a separate patch. On a somewhat related note, Windows 7 has overlay d3dx9 swapchains. The SDK claims that those may support YUV primaries, but according to http://www.virtualdub.org/blog/pivot/entry.php?id=282 and a follow-up post HW drivers only support RGB formats.

Oct. 17, 2011

Re: ntdll: avoid buffer overrun in lookup_manifest_file

by Alexandre Julliard

Dan Kegel <dank(a)kegel.com> writes: > @@ -1877,7 +1877,7 @@ static WCHAR *lookup_manifest_file( HANDLE dir, struct assembly_identity *ai ) > if (build == min_build && revision < min_revision) continue; > tmp = strchrW(tmp, '_') + 1; > tmp = strchrW(tmp, '_') + 1; > - if (!strcmpiW( tmp, wine_trailerW )) > + if (!strncmpiW( tmp, wine_trailerW, dir_info->FileNameLength/sizeof(WCHAR) - (tmp - dir_info->FileName) )) That doesn't do the same thing. -- Alexandre Julliard julliard(a)winehq.org

Oct. 17, 2011

Re: vbscript: Added lexer support for '_'

by Bruno Jesus

Hi, Jacek. On Mon, Oct 17, 2011 at 10:30, Jacek Caban <jacek(a)codeweavers.com> wrote: > Hi Bruno, > > On 10/14/11 20:07, Bruno Jesus wrote: > ... > I've tested it and that doesn't seem to be true. You're right, in a vbs file the limit does not exist, it looks like to be a Visual Basic 6 editor limit. Sorry for the noise. >> And this is another test that must pass too (there is no new operand >> after the last _ ) : >> x = _ >> 3 _ >> + 3 _ >> + 3 _ >> + 3 _ > > This will work only if the next line is empty (exactly like my > implementation does). Great =) > Jacek > Best wishes, Bruno

Oct. 17, 2011

Re: [4/7] wined3d: YUY2 and UYVY are block based

by Henri Verbeet

On 16 October 2011 23:05, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > + BOOL gl_compressed; I think the "gl_" prefix is somewhat questionable since the format being compressed or not is a property of the D3D format, it doesn't depend on what GL format we use, at least in the way the flag is currently used. You can change the meaning of the flag to be specific to the GL format, but then you'd have to set it in the format_texture_info[] table. > static const struct wined3d_format_compression_info format_compression_info[] = > { > - {WINED3DFMT_DXT1, 4, 4, 8}, > - {WINED3DFMT_DXT2, 4, 4, 16}, > - {WINED3DFMT_DXT3, 4, 4, 16}, > - {WINED3DFMT_DXT4, 4, 4, 16}, > - {WINED3DFMT_DXT5, 4, 4, 16}, > - {WINED3DFMT_ATI2N, 4, 4, 16}, > + {WINED3DFMT_DXT1, 4, 4, 8, TRUE }, > + {WINED3DFMT_DXT2, 4, 4, 16, TRUE }, > + {WINED3DFMT_DXT3, 4, 4, 16, TRUE }, > + {WINED3DFMT_DXT4, 4, 4, 16, TRUE }, > + {WINED3DFMT_DXT5, 4, 4, 16, TRUE }, > + {WINED3DFMT_ATI2N, 4, 4, 16, TRUE }, > + > + {WINED3DFMT_YUY2, 2, 1, 4, FALSE }, > + {WINED3DFMT_UYVY, 2, 1, 4, FALSE }, > }; If you decouple "block-based" and "compressed", it doesn't make sense anymore to set them in the same table like this. The "compressed" property should go to either the format_texture_info[] or the format_base_flags[] table, depending on whether it's considered a basic property of the format, or specific to the GL format we use for it. > + /* Block-based formats can't be rendered to with FBOs even if GL accepts them > + * (e.g. WINED3DFMT_YV12, which is just a GL_ALPHA texture). Even fragment shaders > + * can't account for that if a block is partially drawn. There's no such restriction on the GL side, the internal format just has to be color-renderable. The reason we can't render directly to these is because there a fixup associated with the format, but that has nothing to do with either being FBO-attachable or being block-based, and applies to e.g. P8 as well. > + * > + * Furthermore some drivers crash instead of generating an error if we attempt to > + * attach s3tc textures to an FBO */ This was an issue with some versions of fglrx, but should be fixed in current versions.

Oct. 17, 2011

Re: [3/7] d3d9/tests: Add a test for locking partial blocks with different pools

by Henri Verbeet

On 16 October 2011 23:01, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > + hr = IDirect3DDevice9_CreateTexture(device, 4, 4, 1, > + pools[i].pool == D3DPOOL_DEFAULT ? D3DUSAGE_DYNAMIC : 0, > + D3DFMT_DXT5, pools[i].pool, &texture, NULL); Same comment about dynamic textures as for patch 2/7. > + rect.left = 0; rect.top = 0; rect.right = 2; rect.bottom = 2; I don't care strongly about this, but note that SetRect() exists.

Oct. 17, 2011

Re: [2/7] wined3d: Locking partial blocks is not allowed in DEFAULT pool resources

by Henri Verbeet

On 16 October 2011 22:56, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > + hr = IDirect3DDevice9_CreateTexture(device, 128, 128, 1, D3DUSAGE_DYNAMIC, dxt_formats[i].fmt, > + D3DPOOL_DEFAULT, &texture, NULL); You should check D3DCAPS2_DYNAMICTEXTURES before using dynamic textures. Also, wouldn't it be more appropriate to make this part of the test in patch 3/7?

Oct. 17, 2011

Re: vbscript: Added lexer support for '_'

by Jacek Caban

Hi Bruno, On 10/14/11 20:07, Bruno Jesus wrote: > On Fri, Oct 14, 2011 at 13:44, Jacek Caban<jacek(a)codeweavers.com> wrote: >> --- >> dlls/vbscript/lex.c | 10 ++++++++++ >> dlls/vbscript/tests/lang.vbs | 7 +++++++ >> dlls/vbscript/tests/run.c | 2 ++ >> 3 files changed, 19 insertions(+), 0 deletions(-) >> > Hi, Jacek, I'm far away from my linux box and I'm just passing by to > remember that there is a 24 continuation limit. > > Here is an invalid operation because it has 26 continuations: > x = _ > 3 _ > + 3 _ > + 3 _ > + 3 _ > + 3 - _ > 3 + _ > 3 _ > + 3 _ > + 3 _ > + 3 _ > + 3 _ > + 3 _ > + 3 _ > + 3 _ > + 3 _ > + 3 _ > + 3 _ > + 3 _ > + 3 _ > + 3 _ > + 3 _ > + 3 _ > + 3 _ > + 3 _ > + 3 _ > + 3 I've tested it and that doesn't seem to be true. > And this is another test that must pass too (there is no new operand > after the last _ ) : > x = _ > 3 _ > + 3 _ > + 3 _ > + 3 _ This will work only if the next line is empty (exactly like my implementation does). Jacek

Oct. 17, 2011

Re: d3dx9_36: Buffer size does not depend on the size of the created buffer

by Henri Verbeet

This is because the buffer is supposed to be created by D3DXCreateBox().

Oct. 17, 2011

Re: riched20: Prevent setting an invalid default format rect

by Thomas Faber

Hey, On 2011-10-15 12:10, Thomas Faber wrote: > The patch fixes this by adding checks to ME_SetDefaultFormatRect to > use the minimal rectangle that is still valid in this case. I've made some tests (will post them later) and it turns out this rectangle is also invalid in Windows in this case, so this is not the correct solution. Please ignore the patch, I will try to come up with a better one soon. Regards, Tom

Oct. 17, 2011

Re: [patch] Support NULL puLen in VerQueryValue

by Rafael Espíndola

>> You should write some tests to examine the behavior of VerQueryValue >> with NULL puLen. >> > > I just found out that wine has a test for it, but it has been commented out: The attached patch also uncomment the tests. Cheers, Rafael

Oct. 15, 2011

Fwd: [Announce] Google Code-in 2011

by Austin English

---------- Forwarded message ---------- From: Carol Smith <carols(a)google.com> Date: Fri, Oct 14, 2011 at 15:28 Subject: [Announce] Google Code-in 2011 To: Google Summer of Code Mentors List <google-summer-of-code-mentors-list(a)googlegroups.com> Hi everyone, We’re pleased to announce that we are planning to run the Google Code-in contest again this November. We had a successful contest last year with 20 mentoring organizations and 361 participating students. We will again be giving 13-17 year old students around the world an opportunity to get involved with open source projects doing tasks ranging from documentation to outreach to coding programs. We’re looking forward to a fun contest this year and hope you’ll consider participating as a mentor and/or org admin yourself, and spreading the word to friends, family, and colleagues about the program. Please check out the timeline [0] for more details on the program. We will soon be accepting applications for open source organizations to become mentoring organizations for this year’s contest. There will be a separate email thread to this list inviting you to apply to be a mentoring organization on Monday, 17 October. Please take some time to discuss with your respective organizations about whether you feel you have the time and mentor capacity to participate this year. We won’t kid you: working with teengers can be demanding. It’s important that your mentors/org be prepared to put the time in over the holiday, but if you participate you will all have the satisfaction of sharing your project and your passion for open source with a truly amazing collection of young people, and getting them started in our community. We've put together an Information Page [1] for this year's program to give you some lessons learned from last year's program. *Please* look this over before deciding to apply to participate in the program. We encourage you to join the Google Code-in contest discussion list [2] and announcement list [3]. Please see our blog post [4] for further details and contact us directly if you have specific questions that aren’t answered in the FAQs [5]. [0] - http://www.google-melange.com/gci/events/google/gci2011 [1] - http://code.google.com/p/google-code-in/wiki/GCIAdminMentorInformation [2] - http://groups.google.com/group/gci-discuss [3] - http://groups.google.com/group/gci-announce [4] - http://google-opensource.blogspot.com/2011/10/google-code-in-are-you-in.html [5] - http://www.google-melange.com/gci/document/show/gci_program/google/gci2011/… Cheers, The Google OSPO Team -- You received this message because you are subscribed to the Google Groups "Google Summer of Code Mentors List" group. To post to this group, send email to google-summer-of-code-mentors-list(a)googlegroups.com. To unsubscribe from this group, send email to google-summer-of-code-mentors-list+unsubscribe(a)googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-summer-of-code-mentors-list?hl=en. -- -Austin

Oct. 14, 2011

Re: [6/6] wined3d: Catch nop palette updates

by Stefan Dösinger

On Thursday 13 October 2011 22:27:46 Henri Verbeet wrote: > What makes it slow? Is it purely the upload of the palette itself, or > is this because e.g. realize_palette() causes a download + upload of > the surface? It's the upload in realize_palette. On my system it isn't really an issue with the opengl renderer, even though the color conversion is done only in software. The gdi renderer profits more from eliminating the redundant changes(The game calls SetPaletteEntries with the same entries about 4 times per second)

Oct. 14, 2011

Re: vbscript: Added lexer support for '_'

by Bruno Jesus

On Fri, Oct 14, 2011 at 13:44, Jacek Caban <jacek(a)codeweavers.com> wrote: > --- > dlls/vbscript/lex.c | 10 ++++++++++ > dlls/vbscript/tests/lang.vbs | 7 +++++++ > dlls/vbscript/tests/run.c | 2 ++ > 3 files changed, 19 insertions(+), 0 deletions(-) > Hi, Jacek, I'm far away from my linux box and I'm just passing by to remember that there is a 24 continuation limit. Here is an invalid operation because it has 26 continuations: x = _ 3 _ + 3 _ + 3 _ + 3 _ + 3 - _ 3 + _ 3 _ + 3 _ + 3 _ + 3 _ + 3 _ + 3 _ + 3 _ + 3 _ + 3 _ + 3 _ + 3 _ + 3 _ + 3 _ + 3 _ + 3 _ + 3 _ + 3 _ + 3 _ + 3 _ + 3 And this is another test that must pass too (there is no new operand after the last _ ) : x = _ 3 _ + 3 _ + 3 _ + 3 _ As I said I can't test in wine but maybe you will find this information useful. Best wishes, Bruno -- universe* god::bigbang (void); //and then it all began...

Oct. 14, 2011

Re: 79927: [3/3] cmd: Make RENAME work for read-only files

by Frédéric Delanoy

2011/10/14 Dan Kegel <dank(a)kegel.com>: > gcc complains here: > builtins.c: In function 'WCMD_rename': > builtins.c:1782:9: error: unused variable 'attribs' [-Werror=unused-variable] > OK resent Thx

Oct. 14, 2011

Re: 79927: [3/3] cmd: Make RENAME work for read-only files

by Dan Kegel

gcc complains here: builtins.c: In function 'WCMD_rename': builtins.c:1782:9: error: unused variable 'attribs' [-Werror=unused-variable] On Fri, Oct 14, 2011 at 2:27 AM, <buildbot(a)kegel.com> wrote: > This is an experimental automated build and test service. > Please feel free to ignore this email while we work the kinks out. > > For more info about this message, see http://wiki.winehq.org/BuildBot > > The Buildbot has detected a failed build on builder runtests-default while building Wine. > Full details are available at: http://buildbot.kegel.com/builders/runtests-default/builds/383 (though maybe not for long, as I'm still reinstalling the buildbot periodically while experimenting) > BUILD FAILED: failed shell_2 > > Errors: > builtins.c: In function 'WCMD_rename': > builtins.c:1782:9: error: unused variable 'attribs' [-Werror=unused-variable] > make[1]: *** [builtins.o] Error 1 > make: *** [programs/cmd] Error 2 > make: *** Waiting for unfinished jobs.... > >

Oct. 14, 2011

Re: ddraw: Keep track of interface attached by AddAttachedSurface and detach correct interface when parent is released. (try 3)

by Octavian Voicu

On Thu, Oct 13, 2011 at 11:12 AM, Saulius Krasuckas <saulius2(a)ar.fi.lt> wrote: > I am troubled by seeing (via test.winehq.org) your ddraw:refcount tests to > account only results for "VMware SVGA 3D" adapter/driver (and only those > with 3D acceleration disabled), I guess. > > But if this driver is 3D-enabled or just present real physical adapter > (with no 3d acceleration) then ddraw:refcount contains 6 static failuDDSCAPS_3DDEVICEres > such as: Hi Saulius, Thanks for pointing this out. I only tested with testbot and I guess all of the machines use that adapter (at least the default ones do), so that's why I didn't catch the error. The application that I was debugging used stencil buffers, so I sticked with those -- although I did have a feeling it's not a good idea to test using DDSCAPS_3DDEVICE. I'm going to write a patch to fix the tests by switching to more general surface types and maybe also move the tests to dsurface.c. @Henri: I was in doubt between refcount.c and dsurface.c when writing the tests, but refcount.c allowed me to write the tests for both IDirectDrawSurface and IDirectDrawSurface7 in the same function and so reuse the caps for them. Now that I QI the v1 interface, maybe I can still combine them somehow. Octavian

Oct. 14, 2011

Re: [2/6] wined3d: Pass the destination surface to blitters

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 13.10.2011 um 22:27 schrieb Henri Verbeet: > It's mostly a matter of getting rid of set_shader() / unset_shader() > and introducing calls for doing color and depth blits. This shouldn't > be much of a surprise, I'm pretty sure we looked at this when Roderick > was still working on the blit code. No surprise there. The main question I have is, how do you handle blitting offscreen back/frontbuffers to the screen, and how do you select the correct color fixup shader for this? > On 13 October 2011 20:58, Stefan Dösinger <stefan(a)codeweavers.com> wrote: >> initiates the data transfer(That could include blitters that call >> glTexSubImage2D when blitting from sysmem->vidmem) >> > That's not necessarily something that belongs in individual blitters > either. The idea is to make the blitters do GPU -> GPU transfers only, > and do CPU <-> GPU mostly as uploads / downloads. I have some patches > that go in that direction already. Do you mean catch it in wined3d_surface_blt with checks that test for those operations? Or do you mean keep the current software blt then upload the entire destination surface? In the end CPU <-> GPU blits should call surface_upload_data/surface_download_data, no question about that. I'd just use wined3d_select_blitter to select a blitter that calls those functions instead of explicit checks in wined3d_surface_blit. -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) iQIcBAEBAgAGBQJOmARJAAoJEN0/YqbEcdMw+HsP/21icwJaEUXEFdDdVGGffmb0 dqnyH29cnV7do24OH44ABtv+4cq35oepg0NyRLxcPjTqSLsQgiQnCTB80oRZVw+J 4TuaXPTn+FH+eIzJRp1lpjO8LhY78iTMwqZE+ZlRGz/fST3z0kHSuXQTFVZKnME/ RfVrmRn/0xULM6Ey0rf63iPhcmXdmgshE/vV3mX2/j5yTakwjoV0FmpRz4eibbpq 2OdaNcYHXXdtFqBArLZp6y5DslQUWTjqc0U41t8XndCL2g0xxr5uEXcSxqd+hbgA 4KVubj/13ni86BGavCxoQI+fjosYLdZ1kQ2J/u4jXK9lfOvQw5ESl895d+yrblyR kyfRhZBKlmfT94jAfGaClqsAVKWcPf52hc8uBljhjwfTGB6TpdaTZSSPmny4eGVi b8uN9146HbkboYMiyKZvxSLwBzhVcngFCRJgpbvKm4has8G4m1NjL15OCLL3pfu9 Xleq3czqvrNLgx2kq+gXDPlOeeyyeElsYebfA5wigh7Ioxo7ZyX3cqexacPuFOMN oMt2q4QgkMdmVzvIyLfRh5kOdjkEfYzOAniqPDDGKqLZXl3d8ndCiIAI3aITLEW2 AFEvxHrughwxac9PBQv3UTazlHJwg5/R7B5LuGbD/N09m5axs02Pz0k+N7fUBztk zwJ9JqrChMlbW6BDrlZF =kBZI -----END PGP SIGNATURE-----

Oct. 14, 2011

Update: One more review: wineps.drv: Implement PS_USERSTYLE on printers

by Daniel Santos

Sorry, I left an fprintf in that last patch. On 10/14/2011 02:57 AM, Daniel Santos wrote: > Is anybody intimately familiar with the life cycle of device context and > pens? I don't necessarily mean that you went to bed with either of > them, but that would be OK too. I mean, this is the 2010s, we're > supposed to be modern here. Specifically, I want to make sure I'm not > leaking my dynamically allocated memory block. This block is allocated > when the pen is selected (not when it's created). > > Thanks in advance > Daniel

Oct. 14, 2011

One more review: wineps.drv: Implement PS_USERSTYLE on printers

by Daniel Santos

Is anybody intimately familiar with the life cycle of device context and pens? I don't necessarily mean that you went to bed with either of them, but that would be OK too. I mean, this is the 2010s, we're supposed to be modern here. Specifically, I want to make sure I'm not leaking my dynamically allocated memory block. This block is allocated when the pen is selected (not when it's created). Thanks in advance Daniel

Oct. 14, 2011

Re: 79921: ntdll: Move adding VPROT_READ for Solaris to the same place where it's done for FreeBSD. Take 2.

by Dmitry Timoshkov

Dan Kegel <dank(a)kegel.com> wrote: > Fails to apply here: > $ patch -p1 < vprot.patch > patching file dlls/ntdll/virtual.c > Hunk #1 FAILED at 187. > 1 out of 2 hunks FAILED -- saving rejects to file dlls/ntdll/virtual.c.rej Becuase it depends on the 1/2 patch sent before. -- Dmitry.

Oct. 14, 2011

Re: 79921: ntdll: Move adding VPROT_READ for Solaris to the same place where it's done for FreeBSD. Take 2.

by Dan Kegel

Fails to apply here: $ patch -p1 < vprot.patch patching file dlls/ntdll/virtual.c Hunk #1 FAILED at 187. 1 out of 2 hunks FAILED -- saving rejects to file dlls/ntdll/virtual.c.rej On Thu, Oct 13, 2011 at 10:02 PM, <buildbot(a)kegel.com> wrote: > This is an experimental automated build and test service. > Please feel free to ignore this email while we work the kinks out. > > For more info about this message, see http://wiki.winehq.org/BuildBot > > The Buildbot has detected a failed build on builder runtests-default while building Wine. > Full details are available at: http://buildbot.kegel.com/builders/runtests-default/builds/373 (though maybe not for long, as I'm still reinstalling the buildbot periodically while experimenting) > BUILD FAILED: failed git > > Errors: > error: patch failed: dlls/ntdll/virtual.c:187 > error: dlls/ntdll/virtual.c: patch does not apply > >

Oct. 14, 2011

Re: [6/6] wined3d: Catch nop palette updates

by Henri Verbeet

On 13 October 2011 20:40, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > On Thursday 13 October 2011 14:40:23 Henri Verbeet wrote: >> This looks questionable. Which applications does this help? > Age of Empires 2. It uploads the same palette regularly, which makes the main > menu quite unresponsive. > What makes it slow? Is it purely the upload of the palette itself, or is this because e.g. realize_palette() causes a download + upload of the surface?

Oct. 13, 2011

Re: [3/6] wined3d: Use the destination palette when blitting between P8 surfaces

by Henri Verbeet

On 13 October 2011 21:15, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > On Thursday 13 October 2011 14:40:09 Henri Verbeet wrote: >> Which makes much more sense. > And is the plan for offscreen P8 surfaces. It won't work for blits to the > frontbuffer(at the moment) or for the non-shader P8 surface conversion. > The point is mostly that don't see much point in extending the existing hacks (with all the potential for regressions associated with that) when it's clear that it's not the way it's supposed to work.

Oct. 13, 2011

Re: [2/6] wined3d: Pass the destination surface to blitters

by Henri Verbeet

On 13 October 2011 20:58, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > What does the interface you plan look like? > It's mostly a matter of getting rid of set_shader() / unset_shader() and introducing calls for doing color and depth blits. This shouldn't be much of a surprise, I'm pretty sure we looked at this when Roderick was still working on the blit code. > initiates the data transfer(That could include blitters that call > glTexSubImage2D when blitting from sysmem->vidmem) > That's not necessarily something that belongs in individual blitters either. The idea is to make the blitters do GPU -> GPU transfers only, and do CPU <-> GPU mostly as uploads / downloads. I have some patches that go in that direction already.

Oct. 13, 2011

Re: [1/6] wined3d: YUV formats are block-based

by Stefan Dösinger

On Thursday 13 October 2011 14:39:38 Henri Verbeet wrote: > On 13 October 2011 01:07, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > > diff --git a/dlls/d3d9/tests/surface.c b/dlls/d3d9/tests/surface.c > > diff --git a/dlls/ddraw/tests/overlay.c b/dlls/ddraw/tests/overlay.c > > These tests don't prove anything, they pass on current Wine as well. Because height=1 blocks are quite uninteresting. You notice the 2x1 blocks when you try to lock a rectangle with an odd left or right coordinate. But only with DEFAULT pool surfaces and not SCRATCH ones. There are no DXTN default pool surfaces, and textures break the double unlock test. So the test needs splitting into a texture and surface part. Detours ftw. > > + {WINED3DFMT_YUY2, 2, 1, 4, FALSE }, > > + {WINED3DFMT_UYVY, 2, 1, 4, FALSE }, > > + /* YV12 actually has 2x2 blocks with 6 bytes per block, but the > > blocks + * are spread across the surface. */ > > + {WINED3DFMT_YV12, 1, 1, 1, FALSE}, > > Blocks with 1 height aren't really blocks. YV12 is a strange format in many ways. What I care about is that we don't write to it. I'll write some more tests for YV12. If Windows rejects 1:1 blits, or blits only the luminance data that'd make things much simpler.

Oct. 13, 2011

Re: [3/6] wined3d: Use the destination palette when blitting between P8 surfaces

by Stefan Dösinger

On Thursday 13 October 2011 14:40:09 Henri Verbeet wrote: > On 13 October 2011 01:07, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > > Native transfers the 8 bit data without modifications to the destination > > surface and does the palette lookup when showing the final front buffer > > contents on the screen. > > Which makes much more sense. And is the plan for offscreen P8 surfaces. It won't work for blits to the frontbuffer(at the moment) or for the non-shader P8 surface conversion.

Oct. 13, 2011

Re: [2/6] wined3d: Pass the destination surface to blitters

by Stefan Dösinger

On Thursday 13 October 2011 14:39:58 Henri Verbeet wrote: > On 13 October 2011 01:07, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > > -static HRESULT arbfp_blit_set(void *blit_priv, struct wined3d_context > > *context, struct wined3d_surface *surface) + static HRESULT > > arbfp_blit_set(void *blit_priv, struct wined3d_context *context, struct > > wined3d_surface *src, + const struct wined3d_surface *dst) > > Whitespace error. The parameter you're adding isn't used anywhere, not > even in the same patchset. Patch 3: - upload_palette(src, context); + upload_palette(src, dst, context); > Perhaps more important though is the point > that "set_shader" is pretty much the wrong interface for blitters and > should go away. Note that the blitter interface is something I'm > actually working on as part of the ddraw work, it's just that other > things keep coming up. What does the interface you plan look like? I had a short look at this and my proposal is to separate the blitters into two interfaces: One that sets the shader for the color conversion(blit_shader without colorfill and depthfill), and one that does the drawable setup and initiates the data transfer(That could include blitters that call glTexSubImage2D when blitting from sysmem->vidmem) The shader setup blitter could be hidden behind a quad draw blitter if you find a way to integrate swapchain_blit and surface_blt_to_drawable(especially frontbuffer texture -> frontbuffer drawable blit)

Oct. 13, 2011

Re: [6/6] wined3d: Catch nop palette updates

by Stefan Dösinger

On Thursday 13 October 2011 14:40:23 Henri Verbeet wrote: > This looks questionable. Which applications does this help? Age of Empires 2. It uploads the same palette regularly, which makes the main menu quite unresponsive.

Oct. 13, 2011

Re: wined3d: Refuse to create a shader unsupported by the backend.

by Alexandre Julliard

Matteo Bruni <mbruni(a)codeweavers.com> writes: > --- > dlls/d3d9/tests/shader.c | 22 ++++++++++++++++++++-- > dlls/wined3d/device.c | 2 ++ > dlls/wined3d/shader.c | 19 +++++++++++++++++++ > dlls/wined3d/wined3d_private.h | 1 + > 4 files changed, 42 insertions(+), 2 deletions(-) It breaks the tests here: ../../../tools/runtest -q -P wine -M d3d10.dll -T ../../.. -p d3d10_test.exe.so effect.c && touch effect.ok effect.c:2661: Test failed: D3D10CreateEffectFromMemory failed! wine: Unhandled page fault on read access to 0x00000000 at address 0x6869a2a3 (thread 0024), starting debugger... -- Alexandre Julliard julliard(a)winehq.org

Oct. 13, 2011

Re: [6/6] wined3d: Catch nop palette updates

by Henri Verbeet

This looks questionable. Which applications does this help?

Oct. 13, 2011

Re: [3/6] wined3d: Use the destination palette when blitting between P8 surfaces

by Henri Verbeet

On 13 October 2011 01:07, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > Native transfers the 8 bit data without modifications to the destination > surface and does the palette lookup when showing the final front buffer > contents on the screen. Which makes much more sense.

Oct. 13, 2011

Re: [2/6] wined3d: Pass the destination surface to blitters

by Henri Verbeet

On 13 October 2011 01:07, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > -static HRESULT arbfp_blit_set(void *blit_priv, struct wined3d_context *context, struct wined3d_surface *surface) > + static HRESULT arbfp_blit_set(void *blit_priv, struct wined3d_context *context, struct wined3d_surface *src, > + const struct wined3d_surface *dst) Whitespace error. The parameter you're adding isn't used anywhere, not even in the same patchset. Perhaps more important though is the point that "set_shader" is pretty much the wrong interface for blitters and should go away. Note that the blitter interface is something I'm actually working on as part of the ddraw work, it's just that other things keep coming up.

Oct. 13, 2011

Re: [1/6] wined3d: YUV formats are block-based

by Henri Verbeet

On 13 October 2011 01:07, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > diff --git a/dlls/d3d9/tests/surface.c b/dlls/d3d9/tests/surface.c > diff --git a/dlls/ddraw/tests/overlay.c b/dlls/ddraw/tests/overlay.c These tests don't prove anything, they pass on current Wine as well. > + {WINED3DFMT_YUY2, 2, 1, 4, FALSE }, > + {WINED3DFMT_UYVY, 2, 1, 4, FALSE }, > + /* YV12 actually has 2x2 blocks with 6 bytes per block, but the blocks > + * are spread across the surface. */ > + {WINED3DFMT_YV12, 1, 1, 1, FALSE}, Blocks with 1 height aren't really blocks.

Oct. 13, 2011

Re: [PATCH 5/5] server/named_pipe.c: remove the ps_disconnected_server state, if DisconnectNamedPipe is called, the server i

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=14877 Your paranoid android. === WXPPROSP3 (32 bit pipe) === pipe.c:1605: Test failed: expected ERROR_CANNOT_IMPERSONATE, got 1368 === W2K3R2SESP2 (32 bit pipe) === pipe.c:1605: Test failed: expected ERROR_CANNOT_IMPERSONATE, got 1368 === WVISTAADM (32 bit pipe) === pipe.c:1605: Test failed: expected ERROR_CANNOT_IMPERSONATE, got 1368 === W2K8SE (32 bit pipe) === pipe.c:1605: Test failed: expected ERROR_CANNOT_IMPERSONATE, got 1368 === W7PRO (32 bit pipe) === pipe.c:1605: Test failed: expected ERROR_CANNOT_IMPERSONATE, got 1368 === W7PROX64 (32 bit pipe) === pipe.c:1605: Test failed: expected ERROR_CANNOT_IMPERSONATE, got 1368 === TEST64_W7SP1 (32 bit pipe) === pipe.c:1605: Test failed: expected ERROR_CANNOT_IMPERSONATE, got 1368 === W7PROX64 (64 bit pipe) === pipe.c:1605: Test failed: expected ERROR_CANNOT_IMPERSONATE, got 1368 === TEST64_W7SP1 (64 bit pipe) === pipe.c:1605: Test failed: expected ERROR_CANNOT_IMPERSONATE, got 1368

Oct. 13, 2011

Re: [PATCH 4/5] kernel32, ntdll: implement most of GetNamedPipeHandleState (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 http://testbot.winehq.org/JobDetails.pl?Key=14876 Your paranoid android. === WXPPROSP3 (32 bit pipe) === pipe.c:1561: Test failed: expected ERROR_CANNOT_IMPERSONATE, got 1368 === W2K3R2SESP2 (32 bit pipe) === pipe.c:1561: Test failed: expected ERROR_CANNOT_IMPERSONATE, got 1368 === WVISTAADM (32 bit pipe) === pipe.c:1561: Test failed: expected ERROR_CANNOT_IMPERSONATE, got 1368 === W2K8SE (32 bit pipe) === pipe.c:1561: Test failed: expected ERROR_CANNOT_IMPERSONATE, got 1368 === W7PRO (32 bit pipe) === pipe.c:1561: Test failed: expected ERROR_CANNOT_IMPERSONATE, got 1368 === W7PROX64 (32 bit pipe) === pipe.c:1561: Test failed: expected ERROR_CANNOT_IMPERSONATE, got 1368 === TEST64_W7SP1 (32 bit pipe) === pipe.c:1561: Test failed: expected ERROR_CANNOT_IMPERSONATE, got 1368 === W7PROX64 (64 bit pipe) === pipe.c:1561: Test failed: expected ERROR_CANNOT_IMPERSONATE, got 1368 === TEST64_W7SP1 (64 bit pipe) === pipe.c:1561: Test failed: expected ERROR_CANNOT_IMPERSONATE, got 1368

Oct. 13, 2011

Re: For review please: wineps.drv: Implement PS_USERSTYLE on printers

by Bruno Jesus

Hi, Daniel. On Thu, Oct 13, 2011 at 06:14, Daniel <danielfsantos(a)att.net> wrote: > Hello guys. I would like to get a little review on this patch, a follow > up to the patches that fix this problem on the screen. Specifically, > I'm most concerned about making sure my dynamically allocated memory is > freed under all conditions and there's no potential snafus that I'm not > aware of. Then, of course, if somebody sees something off, please do > comment. + int i; + EXTLOGPEN *elp = NULL; + INT size = GetObjectW( hpen, 0, NULL ); + + if (!size) return 0; + else if (size == sizeof(logpen)) { + GetObjectW( hpen, sizeof(logpen), &logpen ); + } else { Alexandre replied in your patch email regarding this part of the patch, take a look at it. + const char *pattern = "%d"; /* don't put a space in front of the 1st number */ Are you sure const is doing what you think it is? + pattern = " %d"; You're setting the pattern var inside the loop, isn't it better to start with "%d " and trim the string after the for loop? + if (elp) HeapFree( GetProcessHeap(), 0, elp ); There is no need to check elp before calling HeapFree, it takes care of null pointers. + BOOL own_dash; /* TRUE if we need to free dash */ You are using spaces, the rest of the variable declarations use tabs. I usually don't feel safe about reviewing patches so I would appreciate if anyone care to review my review. Best wishes, Bruno -- universe* god::bigbang (void); //and then it all began...

Oct. 13, 2011

Re: wined3d: recognize "Brian Paul" as a mesa card vendor

by Henri Verbeet

On 13 October 2011 02:23, Austin English <austinenglish(a)gmail.com> wrote: > See http://bugs.winehq.org/show_bug.cgi?id=28684 / > http://cgit.freedesktop.org/mesa/mesa/tree/src/mesa/main/getstring.c#n88 > Yeah, this makes sense. You'd probably mostly run into this if you're not using the regular dri based drivers, but that's valid, if somewhat obscure.

Oct. 13, 2011

Re: ddraw: Keep track of interface attached by AddAttachedSurface and detach correct interface when parent is released. (try 3)

by Henri Verbeet

On 13 October 2011 10:12, Saulius Krasuckas <saulius2(a)ar.fi.lt> wrote: > refcount.c:214: Test failed: AddAttachedSurface returned 8876000a > refcount.c:235: Test failed: AddAttachedSurface returned 8876000a > refcount.c:237: Test failed: Got refcount 1, expected 2 > refcount.c:262: Test failed: AddAttachedSurface returned 8876000a > refcount.c:275: Test failed: AddAttachedSurface returned 8876000a > refcount.c:277: Test failed: Got refcount 1, expected 2 > refcount: 112 tests executed (0 marked as todo, 6 failures), 0 skipped > It probably doesn't make sense to attach a depth buffer to a P8 offscreenplain surface. I think it would make more sense to move these tests to the existing tests for AddAttachedSurface() in dsurface.c.

Oct. 13, 2011

Re: [1/4] winex11.drv: Add on-screen PS_USERSTYLE support to pens (take 4)

by Frédéric Delanoy

On Thu, Oct 13, 2011 at 06:08, Daniel <danielfsantos(a)att.net> wrote: > Fixes on-screen portion of http://bugs.winehq.org/show_bug.cgi?id=26091 You should configure your mail/git config so your real name appears in patches, and not just your first name "Daniel"

Oct. 13, 2011

Re: mscoree: Register interfaces

by Alexandre Julliard

Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> writes: > @@ -10,4 +10,6 @@ C_SRCS = \ > metahost.c \ > mscoree_main.c > > +IDL_R_SRCS = mscoree_v1.idl There's no reason to name the file v1, that's a leftover from stdole.tlb but it doesn't make sense here. -- Alexandre Julliard julliard(a)winehq.org

Oct. 13, 2011

Re: [1/3] winex11.drv: Add on-screen PS_USERSTYLE support to pens (bugbot feeding #5)

by Alexandre Julliard

Daniel <danielfsantos(a)att.net> writes: > @@ -42,29 +42,23 @@ HPEN X11DRV_SelectPen( PHYSDEV dev, HPEN hpen ) > X11DRV_PDEVICE *physDev = get_x11drv_dev( dev ); > LOGPEN logpen; > int i; > + EXTLOGPEN *elp = NULL; > + INT size = GetObjectW( hpen, 0, NULL ); > > - if (!GetObjectW( hpen, sizeof(logpen), &logpen )) > - { > - /* must be an extended pen */ > - EXTLOGPEN *elp; > - INT size = GetObjectW( hpen, 0, NULL ); > - > - if (!size) return 0; > - > + if (!size) return 0; > + else if (size == sizeof(logpen)) { > + GetObjectW( hpen, sizeof(logpen), &logpen ); > + physDev->pen.ext = 0; > + } else { You are changing too much here, there's no reason to duplicate the GetObject call for the standard case. Also please make sure to include your full name in your mail headers. -- Alexandre Julliard julliard(a)winehq.org

Oct. 13, 2011

Re: [msi] initialize variable to placate static analyzers

by Michael Stefaniuc

Hello Dan, Dan Kegel wrote: > Avoids the spurious compiler warning > > msi.c: In function 'MSI_ApplyPatchW': > msi.c:353:10: error: 'r' may be used uninitialized in this function > > Hans says "It's compiler confusion but I'm fine with a patch that initializes > r with ERROR_FUNCTION_FAILED." why don't you just initialize r in the declaration of r? It's the standard way of doing it and doesn't require a suboptimal comment (that warning is gcc version dependent). bye michael

Oct. 13, 2011

For review please: wineps.drv: Implement PS_USERSTYLE on printers

by Daniel

Hello guys. I would like to get a little review on this patch, a follow up to the patches that fix this problem on the screen. Specifically, I'm most concerned about making sure my dynamically allocated memory is freed under all conditions and there's no potential snafus that I'm not aware of. Then, of course, if somebody sees something off, please do comment. It does indeed completely fix http://bugs.winehq.org/show_bug.cgi?id=26091 (printed a cute piece of music with dashed lines). Thanks all! Daniel

Oct. 13, 2011

Re: [Wine] WineHQ database compromise

by Maarten Lankhorst

Hey, On 10/12/2011 12:46 AM, Josh Juran wrote: > On Oct 11, 2011, at 3:37 PM, Conan Kudo (ニール・ゴンパ) wrote: > >> On Tue, Oct 11, 2011 at 3:39 PM, Josh Juran <josh(a)iswifter.net> wrote: >> >>> Since bugzilla passwords were sent in cleartext anyway, I sincerely hope none of them were otherwise valuable. (Remember FireSheep?) >> Wait, what? Bugzilla sends passwords in cleartext? That isn't very smart... Is there no way to replace this with some sort of client based hashing or something? > To clarify, your browser sends your password to bugzilla in cleartext, since HTTPS isn't an option. > > Firesheep was a lesson that even once passwords are secure, session credentials are still vulnerable to sniffing. Some sites went to HTTPS-only sessions after that. > If I go to any https://*.winehq.org website I get the certificate for test.winehq.org , otherwise you could use the firefox https anywhere to force https on. Or better yet, force automatic redirect to https, with Strict-Transport-Security: https://hacks.mozilla.org/2010/08/firefox-4-http-strict-transport-security-… If winehq can't get more ips for every subdomain (ssl sucks), would the solution be moving it to https://winehq.org/{bugs,appdb,test,source} ? Cheers, Maarten

Oct. 13, 2011

Re: ddraw: Keep track of interface attached by AddAttachedSurface and detach correct interface when parent is released. (try 3)

by Saulius Krasuckas

Hello, Octavian. * On Tue, 11 Oct 2011, Octavian Voicu wrote: > > try 3: > - fix test failure by moving error check from *_DeleteAttachedSurface to > ddraw_surface_delete_attached_surface, after another check (thanks Henri). > > try 2: > - use IUnknown_Release(attached_iface) instead of manual dispatch, > as suggested by Henri; > - change type of attached_iface from void* to IUnknown* to reflect > fact that it's a pointer to an interface; > - add test to show that attaching a surface only attaches a specific > interface and return error if DeleteAttachedSurface is called with > another interface than the attached one (instead of detaching the > surface anyway). > > Fixes a bug that causes a stencil buffer leak in the game The Longest Journey. > Problem can be seen in the console output log attached to bug #11819. > This patch doesn't fix the original bug, but now game exits cleanly. > > The root of the problem is that when releasing a surface, its attached > surfaces are detached using IDirectDraw7_DeleteAttachedSurface, regardless > of what interface was originally attached. I am troubled by seeing (via test.winehq.org) your ddraw:refcount tests to account only results for "VMware SVGA 3D" adapter/driver (and only those with 3D acceleration disabled), I guess. But if this driver is 3D-enabled or just present real physical adapter (with no 3d acceleration) then ddraw:refcount contains 6 static failures such as: refcount.c:214: Test failed: AddAttachedSurface returned 8876000a refcount.c:235: Test failed: AddAttachedSurface returned 8876000a refcount.c:237: Test failed: Got refcount 1, expected 2 refcount.c:262: Test failed: AddAttachedSurface returned 8876000a refcount.c:275: Test failed: AddAttachedSurface returned 8876000a refcount.c:277: Test failed: Got refcount 1, expected 2 refcount: 112 tests executed (0 marked as todo, 6 failures), 0 skipped This relation can be easily tracked by looking at d3d9:visual or (if they aren't present) at opengl32:opgenl tests. Eg. failures occuring here: * Intel(R) 82865G Graphics Controller http://test.winehq.org/data/d0c38ece9db657431559024abb34285cd8b717b6/xp_af-… http://test.winehq.org/data/d0c38ece9db657431559024abb34285cd8b717b6/xp_af-… * NVIDIA GeForce FX 5200 http://test.winehq.org/data/d0c38ece9db657431559024abb34285cd8b717b6/win7_s… http://test.winehq.org/data/d0c38ece9db657431559024abb34285cd8b717b6/win7_s… http://test.winehq.org/data/d0c38ece9db657431559024abb34285cd8b717b6/xp_s2-… http://test.winehq.org/data/d0c38ece9db657431559024abb34285cd8b717b6/xp_s2-… * ATI Radeon HD 4800 Series (telling it has no IDirect3D[7] support for DDraw) http://test.winehq.org/data/a843acef5567bc30901612ce5013da543259b21b/win7_w… http://test.winehq.org/data/a843acef5567bc30901612ce5013da543259b21b/win7_w… * VMware SVGA II http://test.winehq.org/data/d0c38ece9db657431559024abb34285cd8b717b6/2000_f… http://test.winehq.org/data/d0c38ece9db657431559024abb34285cd8b717b6/2000_f… http://test.winehq.org/data/d0c38ece9db657431559024abb34285cd8b717b6/2000_f… http://test.winehq.org/data/d0c38ece9db657431559024abb34285cd8b717b6/2000_f… * VMware SVGA 3D (telling it has not IDirect3D[7] support for DDraw) http://test.winehq.org/data/d0c38ece9db657431559024abb34285cd8b717b6/win7_f… http://test.winehq.org/data/d0c38ece9db657431559024abb34285cd8b717b6/win7_f… All other cases succeed. AFAICS all of them represent the only driver (with 3D support turned off): * VMware SVGA 3D http://test.winehq.org/data/d0c38ece9db657431559024abb34285cd8b717b6/win7_w… visual.c:194: Driver string: "vm3dum.dll" visual.c:195: Description string: "VMware SVGA 3D (Microsoft Corporation - WDDM)" visual.c:197: Device name string: "\\.\DISPLAY1" visual.c:199: Driver version 7.14.1.40 visual.c:12627: Tests skipped: Creating the device failed visual: 5 tests executed (0 marked as todo, 0 failures), 1 skipped. with following results: http://test.winehq.org/data/d0c38ece9db657431559024abb34285cd8b717b6/win7_w… refcount: 121 tests executed (0 marked as todo, 0 failures), 0 skipped. IMHO, it would be nice to conform to real world configuration. Wish you best luck with fixing your tests:) S.

Oct. 13, 2011

Re: 79869: [2/4] gdi32: remove PS_USERSTYLE FIXME and work-arounds (take 4)

by Dan Kegel

Still fails tests here. Sorry if I wasn't clear before. The wine tests are supposed to pass after *every* patch in your series. That means you have to merge patches 2 and 3 together, I think. On Wed, Oct 12, 2011 at 9:27 PM, <buildbot(a)kegel.com> wrote: > This is an experimental automated build and test service. > Please feel free to ignore this email while we work the kinks out. > > For more info about this message, see http://wiki.winehq.org/BuildBot > > The Buildbot has detected a failed build on builder runtests-default while building Wine. > Full details are available at: http://buildbot.kegel.com/builders/runtests-default/builds/297 (though maybe not for long, as I'm still reinstalling the buildbot periodically while experimenting) > BUILD FAILED: failed shell_3 > > Errors: > alarum: failed command was ../../../wine gdi32_test.exe.so pen.c > pen.c:317: Test succeeded inside todo block: expected 7, got 7 > make: *** [pen.ok] Error 1 > * Call to xpconnect wrapped JSObject produced this error: * > * Call to xpconnect wrapped JSObject produced this error: * > GnuTLS error: GnuTLS internal error. > >

Oct. 12, 2011

Re: ntdll: Define PATH_MAX when needed

by Dmitry Timoshkov

André Hentschel <nerv(a)dawncrow.de> wrote: > Am 12.10.2011 23:53, schrieb Dan Kegel: > > When is PATH_MAX not defined? > > > > It's part of posix (see > > http://pubs.opengroup.org/onlinepubs/009695399/basedefs/limits.h.html > > ) > > > > Are you trying to build on Gnu Hurd? > > Yes that's for Hurd. Austin already pointed out dynamic allocation might be a better solution, so... Notice that PATH_MAX and MAX_PATH are completely different things going from different sources which can't be replaced by each other. -- Dmitry.

Oct. 12, 2011

Re: [Wine] WineHQ database compromise

by Marcus Meissner

On Thu, Oct 13, 2011 at 10:23:58AM +0200, Maarten Lankhorst wrote: > Hey, > > On 10/12/2011 12:46 AM, Josh Juran wrote: > > On Oct 11, 2011, at 3:37 PM, Conan Kudo (ニール・ゴンパ) wrote: > > > >> On Tue, Oct 11, 2011 at 3:39 PM, Josh Juran <josh(a)iswifter.net> wrote: > >> > >>> Since bugzilla passwords were sent in cleartext anyway, I sincerely hope none of them were otherwise valuable. (Remember FireSheep?) > >> Wait, what? Bugzilla sends passwords in cleartext? That isn't very smart... Is there no way to replace this with some sort of client based hashing or something? > > To clarify, your browser sends your password to bugzilla in cleartext, since HTTPS isn't an option. > > > > Firesheep was a lesson that even once passwords are secure, session credentials are still vulnerable to sniffing. Some sites went to HTTPS-only sessions after that. > > > If I go to any https://*.winehq.org website I get the certificate for test.winehq.org , otherwise you could use the firefox https anywhere to force https on. > > Or better yet, force automatic redirect to https, with Strict-Transport-Security: > https://hacks.mozilla.org/2010/08/firefox-4-http-strict-transport-security-… > > If winehq can't get more ips for every subdomain (ssl sucks), would the solution be moving it to https://winehq.org/{bugs,appdb,test,source} ? Or a wildcard SSL cert for *.winehq.org. Ciao, Marcus

Oct. 12, 2011

Re: [4/3] gdi32/tests: update test for PS_USERSTYLE

by Daniel

Yeah, I'll recombine them in a bit, but I didn't really remove the test, per-se, I removed the if/else that performs the test with todo_wine when the style is PS_USERSTYLE (see the line below, that, of course, is improperly indented -- why I don't allow single statements in if, else, while, etc. without a {} block in my own projects). Daniel On 10/12/2011 07:12 PM, Austin English wrote: > On Wed, Oct 12, 2011 at 19:06, Daniel <danielfsantos(a)att.net> wrote: >> OK, I hope [4/3] is acceptable. These are the test updates I forgot >> (removes a todo_wine). > Two problems: > A) It needs to be combined with the original patch, so that it passes make test. > B) Why remove the test? Just remove 'todo_wine' itself, since the test > now passes on wine.. >

Oct. 12, 2011

re: [4/3] gdi32/tests: update test for PS_USERSTYLE

by Dan Kegel

> OK, I hope [4/3] is acceptable. It's fine for humans, but for buildbot, you really need to send the whole patch series again, with the test fixes right in the same patch as the code that fixes them (so that the wine tree passes all tests after each patch in the series). Otherwise your code will not be tested.

Oct. 12, 2011

Re: [4/3] gdi32/tests: update test for PS_USERSTYLE

by Austin English

On Wed, Oct 12, 2011 at 19:06, Daniel <danielfsantos(a)att.net> wrote: > OK, I hope [4/3] is acceptable. These are the test updates I forgot > (removes a todo_wine). Two problems: A) It needs to be combined with the original patch, so that it passes make test. B) Why remove the test? Just remove 'todo_wine' itself, since the test now passes on wine.. -- -Austin

Oct. 12, 2011

Re: 79857: [2/3] gdi32: remove PS_USERSTYLE FIXME and work-arounds (take 3)

by Daniel

> Fails the gdi32/pen.ok test here, with error > pen.c:317: Test succeeded inside todo block: expected 7, got 7 > > Looks like you need to update a test. whoops, I forgot about my tests. Will do.

Oct. 12, 2011

Re: 79857: [2/3] gdi32: remove PS_USERSTYLE FIXME and work-arounds (take 3)

by Dan Kegel

Fails the gdi32/pen.ok test here, with error pen.c:317: Test succeeded inside todo block: expected 7, got 7 Looks like you need to update a test. On Wed, Oct 12, 2011 at 4:00 PM, <buildbot(a)kegel.com> wrote: > This is an experimental automated build and test service. > Please feel free to ignore this email while we work the kinks out. > > For more info about this message, see http://wiki.winehq.org/BuildBot > > The Buildbot has detected a failed build on builder runtests-default while building Wine. > Full details are available at: http://buildbot.kegel.com/builders/runtests-default/builds/280 (though maybe not for long, as I'm still reinstalling the buildbot periodically while experimenting) > BUILD FAILED: failed shell_3 > > Errors: > alarum: failed command was ../../../wine gdi32_test.exe.so pen.c > pen.c:317: Test succeeded inside todo block: expected 7, got 7 > make: *** [pen.ok] Error 1 > * Call to xpconnect wrapped JSObject produced this error: * > * Call to xpconnect wrapped JSObject produced this error: * > GnuTLS error: GnuTLS internal error. > >

Oct. 12, 2011

[RFC] Use ICU in wine ?

by Rafał Mużyło

On Mon Oct 10 12:48:27 CDT 2011, André Hentschel wrote a few things: Well, in the bug you've mentioned (#5163) there was a link to that file in mono, but while it seems nice, just looking at mono code makes my eyes bleed and the perspective of rewriting it in perl would fill me with terror. There's also the question of how close did mono get to Windows in this case. Still, that would at most fixed the default table, the tailoring needs to be implemented anyway.

Oct. 12, 2011

Re: ntdll: Define PATH_MAX when needed

by André Hentschel

Am 12.10.2011 23:53, schrieb Dan Kegel: > When is PATH_MAX not defined? > > It's part of posix (see > http://pubs.opengroup.org/onlinepubs/009695399/basedefs/limits.h.html > ) > > Are you trying to build on Gnu Hurd? Yes that's for Hurd. Austin already pointed out dynamic allocation might be a better solution, so... -- Best Regards, André Hentschel

Oct. 12, 2011

Re: wined3d: Report every texture format as filterable and blendable.

by Matteo Bruni

2011/10/12 Dan Kegel <dank(a)kegel.com>: > Fails d3d9's visual tests here. > > os: Linux 3.0.0-12-generic, Ubuntu 11.10 > gpu: GeForce GT 240/PCI/SSE2 3.3.0 NVIDIA 280.13 > > On Wed, Oct 12, 2011 at 2:52 PM, <buildbot(a)kegel.com> wrote: >> This is an experimental automated build and test service. >> Please feel free to ignore this email while we work the kinks out. >> >> For more info about this message, see http://wiki.winehq.org/BuildBot >> >> The Buildbot has detected a failed build on builder runtests-default while building Wine. >> Full details are available at: http://buildbot.kegel.com/builders/runtests-default/builds/273 (though maybe not for long, as I'm still reinstalling the buildbot periodically while experimenting) >> BUILD FAILED: failed shell_3 >> >> Errors: >> alarum: failed command was ../../../wine d3d9_test.exe.so visual.c >> fixme:win:EnumDisplayDevicesW ((null),0,0x33f0cc,0x00000000), stub! >> fixme:d3d_draw:drawPrimitive Using software emulation because manual fog coordinates are provided >> fixme:d3d:state_shademode WINED3DSHADE_PHONG isn't supported >> fixme:d3d:state_shademode WINED3DSHADE_PHONG isn't supported >> visual.c:9147: Tests skipped: D3DFMT_G16R16 textures not supported as render targets. >> visual.c:9239: Test failed: Offscreen failed for D3DFMT_R16F: Got color 0x20ffff, expected 0x18ffff. >> visual.c:9239: Test failed: Offscreen failed for D3DFMT_G16R16F: Got color 0x2010ff, expected 0x1818ff. >> visual.c:9239: Test failed: Offscreen failed for D3DFMT_R32F: Got color 0x20ffff, expected 0x18ffff. >> visual.c:9239: Test failed: Offscreen failed for D3DFMT_G32R32F: Got color 0x2010ff, expected 0x1818ff. >> visual.c:9239: Test failed: Offscreen failed for D3DFMT_A32B32G32R32F: Got color 0x201000, expected 0x181800. >> visual.c:7741: Tests skipped: Card has unconditional pow2 support, skipping conditional NP2 tests >> make: *** [visual.ok] Error 5 >> * Call to xpconnect wrapped JSObject produced this error: * >> * Call to xpconnect wrapped JSObject produced this error: * >> GnuTLS error: GnuTLS internal error. >> >> > Interesting. I didn't test on your kind of GPUs but I understood that it should support the feature I'm enabling. I'm not sure right now if it really doesn't support it or it is a driver bug of some kind. Thank you for catching it, if you have Windows installed on that machine I'll probably ask you to run a small testcase soon...

Oct. 12, 2011

Re: wined3d: Report every texture format as filterable and blendable.

by Dan Kegel

Fails d3d9's visual tests here. os: Linux 3.0.0-12-generic, Ubuntu 11.10 gpu: GeForce GT 240/PCI/SSE2 3.3.0 NVIDIA 280.13 On Wed, Oct 12, 2011 at 2:52 PM, <buildbot(a)kegel.com> wrote: > This is an experimental automated build and test service. > Please feel free to ignore this email while we work the kinks out. > > For more info about this message, see http://wiki.winehq.org/BuildBot > > The Buildbot has detected a failed build on builder runtests-default while building Wine. > Full details are available at: http://buildbot.kegel.com/builders/runtests-default/builds/273 (though maybe not for long, as I'm still reinstalling the buildbot periodically while experimenting) > BUILD FAILED: failed shell_3 > > Errors: > alarum: failed command was ../../../wine d3d9_test.exe.so visual.c > fixme:win:EnumDisplayDevicesW ((null),0,0x33f0cc,0x00000000), stub! > fixme:d3d_draw:drawPrimitive Using software emulation because manual fog coordinates are provided > fixme:d3d:state_shademode WINED3DSHADE_PHONG isn't supported > fixme:d3d:state_shademode WINED3DSHADE_PHONG isn't supported > visual.c:9147: Tests skipped: D3DFMT_G16R16 textures not supported as render targets. > visual.c:9239: Test failed: Offscreen failed for D3DFMT_R16F: Got color 0x20ffff, expected 0x18ffff. > visual.c:9239: Test failed: Offscreen failed for D3DFMT_G16R16F: Got color 0x2010ff, expected 0x1818ff. > visual.c:9239: Test failed: Offscreen failed for D3DFMT_R32F: Got color 0x20ffff, expected 0x18ffff. > visual.c:9239: Test failed: Offscreen failed for D3DFMT_G32R32F: Got color 0x2010ff, expected 0x1818ff. > visual.c:9239: Test failed: Offscreen failed for D3DFMT_A32B32G32R32F: Got color 0x201000, expected 0x181800. > visual.c:7741: Tests skipped: Card has unconditional pow2 support, skipping conditional NP2 tests > make: *** [visual.ok] Error 5 > * Call to xpconnect wrapped JSObject produced this error: * > * Call to xpconnect wrapped JSObject produced this error: * > GnuTLS error: GnuTLS internal error. > >

Oct. 12, 2011

re: ntdll: Define PATH_MAX when needed

by Dan Kegel

When is PATH_MAX not defined? It's part of posix (see http://pubs.opengroup.org/onlinepubs/009695399/basedefs/limits.h.html ) Are you trying to build on Gnu Hurd?

Oct. 12, 2011

Please Test again, user32: use uniscribe in the single line edit control

by Aric Stewart

Apologies I sent this to the wrong list just now. Ok, Thanks to Dan I have found and corrected the issues that this created with the tests. I believe all the tests should continue to pass with this version of the patch. Has anyone tried it live in any applications? -aric --- dlls/user32/edit.c | 252 +++++++++++++++++++++++++++++----------------------- 1 files changed, 142 insertions(+), 110 deletions(-)

Oct. 12, 2011

Re: shell32/tests: Better check the result of SHGetDesktopFolder

by Austin English

2011/10/12 André Hentschel <nerv(a)dawncrow.de>: > Might fix the crash in some NT4 systems > --- > dlls/shell32/tests/brsfolder.c | 3 ++- > 1 files changed, 2 insertions(+), 1 deletions(-) > > diff --git a/dlls/shell32/tests/brsfolder.c b/dlls/shell32/tests/brsfolder.c > index 7b87967..6e5e73b 100644 > --- a/dlls/shell32/tests/brsfolder.c > +++ b/dlls/shell32/tests/brsfolder.c > @@ -331,7 +331,8 @@ static void test_selection(void) > > hr = SHGetDesktopFolder(&desktop_object); > ok (SUCCEEDED(hr), "SHGetDesktopFolder failed with hr 0x%08x\n", hr); > - if (FAILED(hr)) { > + ok (desktop_object, "Expected desktop_object to be a valid interface\n"); > + if (FAILED(hr) || !desktop_object) { > skip("SHGetDesktopFolder failed - skipping\n"); > return; > } > -- > > Best Regards, André Hentschel Causes a compiler warning on Buildbot: Errors: brsfolder.c: In function 'test_selection': brsfolder.c:334:5: error: passing argument 1 of 'winetest_ok' makes integer from pointer without a cast [-Werror] make[1]: *** [brsfolder.o] Error 1 -- -Austin

Oct. 12, 2011

Re: Warning report for wine-1.3.30-55-g583e887

by Josh Juran

On Oct 12, 2011, at 1:31 PM, Octavian Voicu wrote: > On Wed, Oct 12, 2011 at 11:22 PM, Josh Juran <josh(a)iswifter.net> wrote: >> My understanding is that accessing element n or greater in an array[n] >> is undefined behavior, but declaring a huge array and allocating only >> part of it is valid. > > It's a commonly used pattern in C. Agreed. > You declare a size-one array at the > end of a structure, then you allocate enough memory to hold the > structure plus (n-1) extra elements of the array. In wine size is > usually calculated with the macro FIELD_OFFSET(struct, member[size]). I understand. I'm just passing on what I read on another mailing list, which is that the construction is non-portable (even if it happens to work everywhere), and that might be the justification for the warning. A purist approach would call for avoiding this idiom, but pragmatically, disabling the warning is sufficient. Josh

Oct. 12, 2011

Re: Warning report for wine-1.3.30-55-g583e887

by Octavian Voicu

On Wed, Oct 12, 2011 at 11:22 PM, Josh Juran <josh(a)iswifter.net> wrote: > My understanding is that accessing element n or greater in an array[n] > is undefined behavior, but declaring a huge array and allocating only > part of it is valid. It's a commonly used pattern in C. You declare a size-one array at the end of a structure, then you allocate enough memory to hold the structure plus (n-1) extra elements of the array. In wine size is usually calculated with the macro FIELD_OFFSET(struct, member[size]). Octavian

Oct. 12, 2011

Re: Warning report for wine-1.3.30-55-g583e887

by Josh Juran

On Oct 12, 2011, at 10:11 AM, Dmitry Timoshkov wrote: > Jerome Leclanche <adys.wh(a)gmail.com> wrote: > >> It would be nice to fix the "array subscript is above array bounds" >> warning spam for 1.4.0. They make up 90% of the warnings. > > The compiler is misguided, you can safely ignore those warnings. My understanding is that accessing element n or greater in an array[n] is undefined behavior, but declaring a huge array and allocating only part of it is valid. Josh

Oct. 12, 2011

Re: Warning report for wine-1.3.30-55-g583e887

by Michael Stefaniuc

On 10/12/2011 02:29 PM, Jerome Leclanche wrote: > It would be nice to fix the "array subscript is above array bounds" > warning spam for 1.4.0. They make up 90% of the warnings. The fix would be to add a configure check for that bogus warning on access to the array[n]; n > 1 struct _tag { ... array[1]; } and to add -Wno-array-bounds in that case. bye michael

Oct. 12, 2011

Re: [Corrected^2] dlls/ntdll/serial.c: Generate a single EV_TXEMPTY when the\ TX buffer turns empty

by Alexandre Julliard

Uwe Bonnes <bon(a)elektron.ikp.physik.tu-darmstadt.de> writes: > @@ -807,8 +808,22 @@ typedef struct async_commio > static NTSTATUS get_irq_info(int fd, serial_irq_info *irq_info) > { > NTSTATUS status = STATUS_NOT_IMPLEMENTED; > -#ifdef TIOCGICOUNT > struct serial_icounter_struct einfo; You can't move this out of the #idef. -- Alexandre Julliard julliard(a)winehq.org

Oct. 12, 2011

Re: WineHQ database compromise

by GOUJON Alexandre

On 10/11/2011 09:13 PM, Jeremy White wrote: > I am sad to say that there was a compromise of the WineHQ database system. "Nothing Is Invulnerable" So, now or later, your system will be compromised. The only thing you have to do is to be prepared to face an incident and of course secure your systems to slow the attacker(s) down. The bugzilla case does not really worry me because it's only bugs. But as CEO, you have to protect your company and your customers. I'm of course a simple "user" of wine and I have absolutely not the right to tell you what to do. But something was open, broken or whatever .. and now you have to spend time and energy to try to repair the breach. Just don't let it happen again. There are lots of methods to analyse risk. Depending on what level of security you want, it will cost more or less. Just think about it. Anyway, thanks for the quick reply, communication is really important in this situation.

Oct. 12, 2011

Re: Warning report for wine-1.3.30-55-g583e887

by Dmitry Timoshkov

Jerome Leclanche <adys.wh(a)gmail.com> wrote: > It would be nice to fix the "array subscript is above array bounds" > warning spam for 1.4.0. They make up 90% of the warnings. The compiler is misguided, you can safely ignore those warnings. -- Dmitry.

Oct. 12, 2011

Re: d3d8/tests: skip the visual test if d3d cannot be initialized

by Austin English

On Wed, Oct 12, 2011 at 04:39, Henri Verbeet <hverbeet(a)gmail.com> wrote: > On 12 October 2011 01:51, Austin English <austinenglish(a)gmail.com> wrote: >> Current d3d8 does a win_skip(), while d3d9 does a skip(). This unifies >> the behavior to match the d3d9 behavior. >> > I seem to recall this being intentional, so that you get a failure if > your setup has e.g. no OpenGL. If the goal is to ensure some test fails with that setup, opengl32/tests/opengl.c already ensures that: ../../../tools/runtest -q -P wine -M opengl32.dll -T ../../.. -p opengl32_test.exe.so opengl.c && touch opengl.ok err:wgl:X11DRV_WineGL_InitOpenglInfo couldn't initialize OpenGL, expect problems opengl.c:1295: Test failed: Unable to find pixel format. *** Error code 1 I was looking to make d3d8/d3d9 consistent. Instead we could make d3d9 fail if OpenGL isn't available, as d3d8 does now. -- -Austin

Oct. 12, 2011

Re: [4/4] wined3d: Don't allow fbo blits to frontbuffers that need fixups.

by Stefan Dösinger

On Wednesday 12 October 2011 11:35:48 Henri Verbeet wrote: > On 11 October 2011 22:31, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > > static BOOL fbo_blit_supported(const struct wined3d_gl_info *gl_info, > > enum wined3d_blit_op blit_op, > > > > const RECT *src_rect, DWORD src_usage, WINED3DPOOL src_pool, > > const struct wined3d_format *src_format, > > > > - const RECT *dst_rect, DWORD dst_usage, WINED3DPOOL dst_pool, > > const struct wined3d_format *dst_format) + const RECT *dst_rect, > > DWORD dst_usage, WINED3DPOOL dst_pool, const struct wined3d_format > > *dst_format, + const struct wined3d_surface *dst_surface) > > I don't think we want this. Does this actually ever happen? I had to double-check this. It used to be a problem before you introduced the shadow ddraw frontbuffer. Now it works by luck because the shadow frontbuffer has a palette set and is converted on upload time, so it is a RGB surface that doesn't need read-time conversion. There are two things that make the fbo blit work correctly although it should be broken: *) The offscreen P8 surfaces should be converted with the destination's palette. The palette happens to be the same for the shadow frontbuffer, but for no other surface. *) The shadow frontbuffer has SFLAG_CONVERTED set. Thus blits to it happen in software, otherwise we'd write P8 data to it that had no palette when it was converted to RGB(the ERR in d3dfmt_p8_init_palette). So in the end we never happen to have a P8 surface that only has GL_ALPHA8 data right now. No surface uses COMPLEX_FIXUP_P8 right now. It will be a problem again once we load offscreen surfaces(render target or just offscreenplain) with GL_ALPHA8 textures that require COMPLEX_FIXUP_P8. I'll send the patch again with the patchset that re-enables shader P8 conversion. And yeah, we don't actually want to pass the destination surface to fbo_blit_supported. It can go away again once we have the shadow frontbuffers in wined3d instead of ddraw. The ARB and FFP blitter have a similar problem when blitting to onscreen P8 surfaces, but unlike the FBO blitter they can do the palette lookup. They can accept the blit no matter what the destination is, but they have to make sure to select the right color fixup and palette.

Oct. 12, 2011

Re: 79794: Help Test Please: use uniscribe in the single line edit control

by Aric Stewart

Thank Dan, I had not gotten to a full test run. I will look into those. -aric On 10/11/11 8:01 PM, Dan Kegel wrote: > Hi Aric, > failed again on second run, > http://buildbot.kegel.com:8010/builders/runtests-default/builds/209 > > Failing tests are > comctl32_test.exe.so listview.c > comctl32_test.exe.so updown.c > user32_test.exe.so edit.c > > On Tue, Oct 11, 2011 at 1:26 PM, Dan Kegel<dank(a)kegel.com> wrote: >> Hey Aric, >> don't know if I trust the bot at the moment, but it says the tests >> failed here... >> I'll rerun them to see if the failure is repeatable. >> >> ---------- Forwarded message ---------- >> From:<buildbot(a)kegel.com> >> Date: Tue, Oct 11, 2011 at 1:21 PM >> Subject: Re: 79794: Help Test Please: use uniscribe in the single line >> edit control >> To: dank(a)kegel.com, wine-tests-results(a)winehq.org >> >> >> This is an experimental automated build and test service. >> Please feel free to ignore this email while we work the kinks out. >> >> For more info about this message, see http://wiki.winehq.org/BuildBot >> >> The Buildbot has detected a failed build on builder runtests-default >> while building Wine. >> Full details are available at: >> http://buildbot.kegel.com/builders/runtests-default/builds/186 (though >> maybe not for long, as I'm still reinstalling the buildbot >> periodically while experimenting) >> BUILD FAILED: failed shell_3 >> >> Errors: >> alarum: Timeout! Killing child ../../../wine. >> alarum: failed command was ../../../wine comctl32_test.exe.so listview.c >> alarum: ../../../wine terminated abnormally >> make: *** [listview.ok] Error 99 >> alarum: Timeout! Killing child ../../../wine. >> alarum: failed command was ../../../wine comctl32_test.exe.so updown.c >> alarum: ../../../wine terminated abnormally >> make: *** [updown.ok] Error 99 >> * Call to xpconnect wrapped JSObject produced this error: * >> * Call to xpconnect wrapped JSObject produced this error: * >> alarum: failed command was ../../../wine user32_test.exe.so edit.c >> edit.c:1138: Test failed: expected 1 got 0 >> edit.c:1156: Test failed: expected 1 got 0 >> edit.c:1174: Test failed: expected 1 got 0 >> make: *** [edit.ok] Error 3 >> GnuTLS error: GnuTLS internal error. >>

Oct. 12, 2011

Re: [PATCH 5/5] server/named_pipe.c: remove the ps_disconnected_server state, if DisconnectNamedPipe is called, the server i

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=14844 Your paranoid android. === WNT4WSSP6 (32 bit pipe) === pipe.c:1603: Test failed: expected ERROR_CANNOT_IMPERSONATE, got 203 === W2KPROSP4 (32 bit pipe) === pipe.c:1603: Test failed: expected ERROR_CANNOT_IMPERSONATE, got 997

Oct. 12, 2011

Re: [PATCH 4/5] kernel32, ntdll: implement most of GetNamedPipeHandleState (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 http://testbot.winehq.org/JobDetails.pl?Key=14843 Your paranoid android. === WNT4WSSP6 (32 bit pipe) === pipe.c:1559: Test failed: expected ERROR_CANNOT_IMPERSONATE, got 203 === W2KPROSP4 (32 bit pipe) === pipe.c:1559: Test failed: expected ERROR_CANNOT_IMPERSONATE, got 997

Oct. 12, 2011

Re: [2/4] wined3d: reject ARB shader blits if the destination is not fbo attachable

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 12.10.2011 um 11:26 schrieb Henri Verbeet: > On 11 October 2011 22:30, Stefan Dösinger <stefan(a)codeweavers.com> wrote: >> + if (wined3d_settings.offscreen_rendering_mode == ORM_FBO) >> + { >> + if (!((dst_format->flags & WINED3DFMT_FLAG_FBO_ATTACHABLE) || (dst_usage & WINED3DUSAGE_RENDERTARGET))) >> + return FALSE; >> + } >> + else if (!(dst_usage & WINED3DUSAGE_RENDERTARGET)) >> + { >> + return FALSE; >> + } > Formats are never FBO-attachable if we don't have > FBOs. It's not clear this is what you want either way though. This > pretty much looks like a copy/paste from fbo_blit_supported(), and the > WINED3DUSAGE_RENDERTARGET check there is to allow formats that don't > have a FBO-attachable internal format, but were created with the > rtInternal format (which should always be attachable). There's really > no equivalent check for backbuffer ORM, it just renders something and > hopes we can read it back. I'm not sure I see what you mean. What I want is to make sure the blitter doesn't draw to a surface that GL can't draw to. In the FBO ORM case the fbo_attachable || rendertarget case seems just right, for the reasons you mention. With backbuffer ORM we don't really know where we can draw(e.g. stuff like surface size vs framebuffer size comes into play), but I think RENDERTARGET usage is a decent heuristic since we'll probably have to be able to draw to it anyways, or things fails. I could add some surface_is_drawable() function or equivalent surface flag. That might be a good idea on its own, but I don't see a better way to define if a surface can be rendered to than the above statement. -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) iQIcBAEBAgAGBQJOlYhaAAoJEN0/YqbEcdMwpxgQAJTF3i75QLb+gosDaGkFODbk nhNUt/PHRw7k8yTVFBHp5aBWNCROdcr9yFANMj4AD74ii1HGNj9jzGISyfogvfqv RNHHHvwdff7b8Ev8MtKBEY3w9fTPvl7w0FzdzoSTFBF2SxkeEMc6QnecaHIfcepr SCf69/FFeVkPniOiVa3RCbLXyvrWG6ifMpJpXV8DFw23NTqb/JGyQIjodW2hc+Qy Gpgz4hwBw/jywOeFPCyOXtpR0bTBdD03mix3XWeYYaZg1Ukm+jyARQOvBSFU0dgB xhEcVTR0aNGA5WAgpKxUT1f3jRQc9f36U7HS5jTZemFR71wAXFPO0pMm7RNNrMXQ imhzE9+56OS7o96Vk4Rz8UdFYDBgDvTjO8nlp9j5aDOi8ylsX9TstDdRi2kh3ILI Satb83g0brU6JZaDqsLd5xZI8ZTPL55MniKRGvXJ1EEepViC0isgvMmrM1b/I2Wo N0FSoLkukXAfJHcal9YD6nAQeoI1HbM9HNNmAMPMCtDb9Y8Q0VSSWoeh71iP8cGF DziZZ3uSnX90kDrt7q6maXDFSWUS8YKZz2lviRxupb2LzwaSMAP2Aw1XEQz/YImH HxZkPuY4kZdQNShcYOyv9ZqNKUBrD5geFhmErYqxSL+Ede1nM7Lcp52NhbVRnTLI 9ksujocgWYGZYbzbhwym =04xu -----END PGP SIGNATURE-----

Oct. 12, 2011

Warning report for wine-1.3.30-55-g583e887

by Jerome Leclanche

It would be nice to fix the "array subscript is above array bounds" warning spam for 1.4.0. They make up 90% of the warnings. Apart from those, theres 25 more warning blocks to fix, most of them unused-but-set-variables. JL

Oct. 12, 2011

Re: [1/4] wined3d: Use an rbtree for the blit programs

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 12.10.2011 um 11:57 schrieb Henri Verbeet: > You already have the P8 shader. My bad. What will actually be added is the NONE conversion with color keying. But adding a color keying flag is what makes the current approach unsustainable because it's orthogonal to the other properties. > In the case of color keying it should > probably at least be in the same series as the code that uses it, I can resend the patch later, but IMO getting rid of the current spaghetti shader selection code makes sense on its own. > but > I'm not sure an rbtree would really have a lot of advantages over a > simple array there. I chose the rbtree for consistency with the ffp and pshader/vshader selection, but an array is probably more efficient because I don't expect to have more than 4 different blit shaders at a time. -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) iQIcBAEBAgAGBQJOlXiYAAoJEN0/YqbEcdMwXLMP/0OUs1gZK6lJDmTOo7/HJRqt xh0+4pTZqWfQsPOePPJ9Erz5wtPSToKayShimwpbdvsmfdUgsGuWGqR22MipgADJ Q7t8muOEe8K9tFb5QgLwNhK39VQMASh+WohuUNFazMmBXbRIETT2UaGkh/VipihK gkI/7JnA8ju/Y41golqiEdnYShnmSTcnTXgaQp4NZDYZDgkT9IFHOmdd+uE4NvE2 ngYciZywyA8Rt37On4DjEMw9Jv32NKpnfoocXx7sPWFFpcqeDejCqIj32yVbWZBo Wj8gi4IbfAE+xdMWFBS2PIlCR1rbv6wwfaC9jB9rAYVpKin4hvk7DDPr4fqCTJ5q eTi5w1ehoH4MOeH8YPnu9BtxrKkrUwXYGKsivKB2jDBTzjm0G+IiZxKT00rvBrmL WpId1Y3Zau7TkTKeoy/W6LThjZzLeyw48Mmf5XTUabp8U/TBIwbPHzn5bHuYZJle AFt/74iWwbIfMVgeRGgSbXXCk56aV1+ykK9HT7DrH4Ne/74tZjZM4+kf54s/H9T+ hjj9lmR3mdm6wCnJqPdX+9+DyiYLSCgkdVa3Cd9TDaElsoMaggJIraxU8PFidU7c 3tzyg5AE+7QjqjKgv1ZZQhyYUWK85Z29iij5BWpzlqvaqfsKQD0fC6inaRhbkLG6 t5j6zcErEey2yeNttNas =3kLs -----END PGP SIGNATURE-----

Oct. 12, 2011

Re: [1/4] wined3d: Use an rbtree for the blit programs

by Henri Verbeet

On 12 October 2011 11:47, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > Because when we add more conversions(P8) and settings(color keying) the current approach will result ugly unmaintainable if blocks. > You already have the P8 shader. In the case of color keying it should probably at least be in the same series as the code that uses it, but I'm not sure an rbtree would really have a lot of advantages over a simple array there.

Oct. 12, 2011

Re: [1/4] wined3d: Use an rbtree for the blit programs

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 12.10.2011 um 11:26 schrieb Henri Verbeet: > Why do you need this? Because when we add more conversions(P8) and settings(color keying) the current approach will result ugly unmaintainable if blocks. -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) iQIcBAEBAgAGBQJOlWIoAAoJEN0/YqbEcdMwdsoP/1FWotm97eiLNanErb/fXL6C t9dlTzVVXbcUboFSw9uBhSY+GQNj+sjZ3sQ5wLJSsQbsypW4MMOYjoBIUD4n+N91 6QY2xK5Bys7DnE7l8T9k3jCss5Fi93TpOkrQjDi0I7C0OreL7/yueM3NJQwn4PiS PJE9C5upvARhPII158NqYtVrd5TmImpLes6yshI9k4gQc4XfDZt9n0x0ERWmL8ag zS8nVR2Zaa3HaRuk/BMnf5X8FWiImwT/JapK9AyroWV4Lcg4MlKaOLGl43KaRTjQ 8IbMDPxFdWOFyU4yOfu8MEwLPDj1g7wG/CxCDNrKXMgRxgTmam9mtogM+e/dGWFX H8x+Td7h56syIU9l7g+L/4ODVugIKBxBlDdeJVUYbjOOpxuaUjsiQXG5aUcfYLf2 +1hVoKXuk7XfobCF3XKRW0hQIZGW9iJ2NAfLQ6OWK/tCZIsQ+GQafjJRPSAMgC7E y/WQ6YuuTA9eGo9si8wiuzJ5xCJoqjG7Y4oB7aih/l0DjG8MwKwWuxk85kcMg6xF 9Hnkz7738HyXhb6Y2cyUtPVsJTao5DZkBFXKs+SiCQhOnLFKPrXyIB8Zk2R4uLl3 9v+OU9khdzjTvu+f8uRw+V3HW4X+inDdS2UueGNlRHh/rYFMHX8GIYKeVK+8PS/C 1ZEjQ+1hE7S664QuNv3g =Ptfk -----END PGP SIGNATURE-----

Oct. 12, 2011

Re: d3d8/tests: skip the visual test if d3d cannot be initialized

by Henri Verbeet

On 12 October 2011 01:51, Austin English <austinenglish(a)gmail.com> wrote: > Current d3d8 does a win_skip(), while d3d9 does a skip(). This unifies > the behavior to match the d3d9 behavior. > I seem to recall this being intentional, so that you get a failure if your setup has e.g. no OpenGL.

Oct. 12, 2011

Re: [4/4] wined3d: Don't allow fbo blits to frontbuffers that need fixups.

by Henri Verbeet

On 11 October 2011 22:31, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > static BOOL fbo_blit_supported(const struct wined3d_gl_info *gl_info, enum wined3d_blit_op blit_op, > const RECT *src_rect, DWORD src_usage, WINED3DPOOL src_pool, const struct wined3d_format *src_format, > - const RECT *dst_rect, DWORD dst_usage, WINED3DPOOL dst_pool, const struct wined3d_format *dst_format) > + const RECT *dst_rect, DWORD dst_usage, WINED3DPOOL dst_pool, const struct wined3d_format *dst_format, > + const struct wined3d_surface *dst_surface) I don't think we want this. Does this actually ever happen?

Oct. 12, 2011

Re: [3/4] wined3d: reject ffp blits if the destination is not fbo attachable

by Henri Verbeet

On 11 October 2011 22:30, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > + if (wined3d_settings.offscreen_rendering_mode == ORM_FBO) > + { > + if (!((dst_format->flags & WINED3DFMT_FLAG_FBO_ATTACHABLE) || (dst_usage & WINED3DUSAGE_RENDERTARGET))) > + return FALSE; > + } > + else if (!(dst_usage & WINED3DUSAGE_RENDERTARGET)) > + { > + return FALSE; > + } Same consideration as for 2/4. Guess I should have caught this when bccfd7cc introduced it.

Oct. 12, 2011

Re: [1/4] wined3d: Use an rbtree for the blit programs

by Henri Verbeet

Why do you need this?

Oct. 12, 2011

Re: [2/4] wined3d: reject ARB shader blits if the destination is not fbo attachable

by Henri Verbeet

On 11 October 2011 22:30, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > + if (wined3d_settings.offscreen_rendering_mode == ORM_FBO) > + { > + if (!((dst_format->flags & WINED3DFMT_FLAG_FBO_ATTACHABLE) || (dst_usage & WINED3DUSAGE_RENDERTARGET))) > + return FALSE; > + } > + else if (!(dst_usage & WINED3DUSAGE_RENDERTARGET)) > + { > + return FALSE; > + } This is redundant. Formats are never FBO-attachable if we don't have FBOs. It's not clear this is what you want either way though. This pretty much looks like a copy/paste from fbo_blit_supported(), and the WINED3DUSAGE_RENDERTARGET check there is to allow formats that don't have a FBO-attachable internal format, but were created with the rtInternal format (which should always be attachable). There's really no equivalent check for backbuffer ORM, it just renders something and hopes we can read it back.

Oct. 12, 2011

Re: 79794: Help Test Please: use uniscribe in the single line edit control

by Dan Kegel

Hi Aric, failed again on second run, http://buildbot.kegel.com:8010/builders/runtests-default/builds/209 Failing tests are comctl32_test.exe.so listview.c comctl32_test.exe.so updown.c user32_test.exe.so edit.c On Tue, Oct 11, 2011 at 1:26 PM, Dan Kegel <dank(a)kegel.com> wrote: > Hey Aric, > don't know if I trust the bot at the moment, but it says the tests > failed here... > I'll rerun them to see if the failure is repeatable. > > ---------- Forwarded message ---------- > From: <buildbot(a)kegel.com> > Date: Tue, Oct 11, 2011 at 1:21 PM > Subject: Re: 79794: Help Test Please: use uniscribe in the single line > edit control > To: dank(a)kegel.com, wine-tests-results(a)winehq.org > > > This is an experimental automated build and test service. > Please feel free to ignore this email while we work the kinks out. > > For more info about this message, see http://wiki.winehq.org/BuildBot > > The Buildbot has detected a failed build on builder runtests-default > while building Wine. > Full details are available at: > http://buildbot.kegel.com/builders/runtests-default/builds/186 (though > maybe not for long, as I'm still reinstalling the buildbot > periodically while experimenting) > BUILD FAILED: failed shell_3 > > Errors: > alarum: Timeout! Killing child ../../../wine. > alarum: failed command was ../../../wine comctl32_test.exe.so listview.c > alarum: ../../../wine terminated abnormally > make: *** [listview.ok] Error 99 > alarum: Timeout! Killing child ../../../wine. > alarum: failed command was ../../../wine comctl32_test.exe.so updown.c > alarum: ../../../wine terminated abnormally > make: *** [updown.ok] Error 99 > * Call to xpconnect wrapped JSObject produced this error: * > * Call to xpconnect wrapped JSObject produced this error: * > alarum: failed command was ../../../wine user32_test.exe.so edit.c > edit.c:1138: Test failed: expected 1 got 0 > edit.c:1156: Test failed: expected 1 got 0 > edit.c:1174: Test failed: expected 1 got 0 > make: *** [edit.ok] Error 3 > GnuTLS error: GnuTLS internal error. >

Oct. 11, 2011

Re: [Wine] WineHQ database compromise

by Josh Juran

On Oct 11, 2011, at 3:54 PM, Conan Kudo (ニール・ゴンパ) wrote: > 2011/10/11 Josh Juran <josh(a)iswifter.net> > >> To clarify, your browser sends your password to bugzilla in cleartext, since HTTPS isn't an option. > > Shouldn't it be possible to modify the login environment so that a salted hash of the password is produced before sending it to the server, to strengthen the security a little bit? That protects the password itself, but not the privilege it guards. It also essentially makes Javascript a requirement, which currently it isn't. Josh

Oct. 11, 2011

Re: [Wine] WineHQ database compromise

by Conan Kudo (ニール・ゴンパ)

2011/10/11 Josh Juran <josh(a)iswifter.net> > On Oct 11, 2011, at 3:37 PM, Conan Kudo (ニール・ゴンパ) wrote: > > > On Tue, Oct 11, 2011 at 3:39 PM, Josh Juran <josh(a)iswifter.net> wrote: > > > >> Since bugzilla passwords were sent in cleartext anyway, I sincerely hope > none of them were otherwise valuable. (Remember FireSheep?) > > > > Wait, what? Bugzilla sends passwords in cleartext? That isn't very > smart... Is there no way to replace this with some sort of client based > hashing or something? > > To clarify, your browser sends your password to bugzilla in cleartext, > since HTTPS isn't an option. > > Firesheep was a lesson that even once passwords are secure, session > credentials are still vulnerable to sniffing. Some sites went to HTTPS-only > sessions after that. > > Josh > > > Shouldn't it be possible to modify the login environment so that a salted hash of the password is produced before sending it to the server, to strengthen the security a little bit?

Oct. 11, 2011

Re: [Wine] WineHQ database compromise

by Austin English

2011/10/11 Josh Juran <josh(a)iswifter.net>: > On Oct 11, 2011, at 3:37 PM, Conan Kudo (ニール・ゴンパ) wrote: > >> On Tue, Oct 11, 2011 at 3:39 PM, Josh Juran <josh(a)iswifter.net> wrote: >> >>> Since bugzilla passwords were sent in cleartext anyway, I sincerely hope none of them were otherwise valuable. (Remember FireSheep?) >> >> Wait, what? Bugzilla sends passwords in cleartext? That isn't very smart... Is there no way to replace this with some sort of client based hashing or something? > > To clarify, your browser sends your password to bugzilla in cleartext, since HTTPS isn't an option. > > Firesheep was a lesson that even once passwords are secure, session credentials are still vulnerable to sniffing. Some sites went to HTTPS-only sessions after that. http://bugs.winehq.org/show_bug.cgi?id=23791 -- -Austin

Oct. 11, 2011

Re: [Wine] WineHQ database compromise

by Josh Juran

On Oct 11, 2011, at 3:37 PM, Conan Kudo (ニール・ゴンパ) wrote: > On Tue, Oct 11, 2011 at 3:39 PM, Josh Juran <josh(a)iswifter.net> wrote: > >> Since bugzilla passwords were sent in cleartext anyway, I sincerely hope none of them were otherwise valuable. (Remember FireSheep?) > > Wait, what? Bugzilla sends passwords in cleartext? That isn't very smart... Is there no way to replace this with some sort of client based hashing or something? To clarify, your browser sends your password to bugzilla in cleartext, since HTTPS isn't an option. Firesheep was a lesson that even once passwords are secure, session credentials are still vulnerable to sniffing. Some sites went to HTTPS-only sessions after that. Josh

Oct. 11, 2011

Re: [Wine] WineHQ database compromise

by Conan Kudo (ニール・ゴンパ)

On Tue, Oct 11, 2011 at 3:39 PM, Josh Juran <josh(a)iswifter.net> wrote: > On Oct 11, 2011, at 12:13 PM, Jeremy White wrote: > > > Unfortunately, the attackers were able to download the full login > > database for both the appdb and bugzilla. This means that they have all > > of those emails, as well as the passwords. The passwords are stored > > encrypted, but with enough effort and depending on the quality of the > > password, they can be cracked. > > > > This, I'm afraid, is a serious threat; it means that anyone who uses the > > same email / password on other systems is now vulnerable to a malicious > > attacker using that information to access their account. > > Since bugzilla passwords were sent in cleartext anyway, I sincerely hope > none of them were otherwise valuable. (Remember FireSheep?) > > Josh > > Wait, what? Bugzilla sends passwords in cleartext? That isn't very smart... Is there no way to replace this with some sort of client based hashing or something?

Oct. 11, 2011

Re: WineHQ database compromise

by Jeremy White

> Almost 2 years ago I have sent you an email privately about a security > hole with the database. To be exactly, the date of the email is Wed, > Jul 29, 2009, 12:00 AM (GMT +02:00). I guess that's probably the same > trick the bad guys have used... Hmm. I can't find any such email in my archives - can you resend it to me? Are you sure it was me, and not the other Jeremy? I'd be curious to see if it matches up to the forensics we have. Cheers, Jeremy

Oct. 11, 2011

Re: [PATCH] dsound: Don't claim to support hardware buffers

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=14829 Your paranoid android. === W2K3R2SESP2 (32 bit dsound) === dsound.c:329: Test failed: IDirectSound_CreateSoundBuffer() failed to create a secondary buffer 88780032

Oct. 11, 2011

Re: WineHQ database compromise

by Matijn Woudt

On Tue, Oct 11, 2011 at 9:13 PM, Jeremy White <jwhite(a)codeweavers.com> wrote: > Hi, > > I am sad to say that there was a compromise of the WineHQ database system. > > What we know at this point that someone was able to obtain unauthorized > access to the phpmyadmin utility. We do not exactly how they obtained > access; it was either by compromising an admins credentials, or by > exploiting an unpatched vulnerability in phpmyadmin. > Jeremy, Almost 2 years ago I have sent you an email privately about a security hole with the database. To be exactly, the date of the email is Wed, Jul 29, 2009, 12:00 AM (GMT +02:00). I guess that's probably the same trick the bad guys have used... Kind regards, Matijn Woudt

Oct. 11, 2011

Re: [PATCH] dsound: Don't claim to support hardware buffers

by Chris Robinson

Hi. On Tuesday, October 11, 2011 3:31:59 PM Andrew Eikum wrote: > The specific drvcaps values and error code were tested against Windows > 7. How does this affect the primary buffer? Is it not allowed to be a hardware buffer either?

Oct. 11, 2011

Re: [Wine] WineHQ database compromise

by Josh Juran

On Oct 11, 2011, at 12:13 PM, Jeremy White wrote: > What we know at this point that someone was able to obtain unauthorized > access to the phpmyadmin utility. We do not exactly how they obtained > access; it was either by compromising an admins credentials, or by > exploiting an unpatched vulnerability in phpmyadmin. Insecure HTTP access? > Unfortunately, the attackers were able to download the full login > database for both the appdb and bugzilla. This means that they have all > of those emails, as well as the passwords. The passwords are stored > encrypted, but with enough effort and depending on the quality of the > password, they can be cracked. > > This, I'm afraid, is a serious threat; it means that anyone who uses the > same email / password on other systems is now vulnerable to a malicious > attacker using that information to access their account. Since bugzilla passwords were sent in cleartext anyway, I sincerely hope none of them were otherwise valuable. (Remember FireSheep?) > We are going to be resetting every password and sending a private email > to every affected user. You might also consider expiring old login cookies. > This is again another reminder to never use a common username / password > pair. This web site provides further advice as well: > http://asiknews.wordpress.com/2011/03/02/best-practice-password-management-… Josh

Oct. 11, 2011

Re: WineHQ database compromise

by Per Johansson

On Tue, Oct 11, 2011 at 9:13 PM, Jeremy White <jwhite(a)codeweavers.com>wrote: > Hi, > > I am sad to say that there was a compromise of the WineHQ database system. > <snip> Hi, one question. I'm not worried about my current account, but I had an old email with an old password recorded in my keychain store. I tried that email at appdb.winehq.org but it said "user does not exist". Can I assume it was completely deleted? Regards, -- Per Johansson

Oct. 11, 2011

Re: [PATCH 1/7] msi/custom.c: unify thread handling of different custom action types (resend)

by Bernhard Loos

On Tue, Oct 11, 2011 at 2:29 PM, Hans Leidekker <hans(a)codeweavers.com> wrote: > On Tue, 2011-10-11 at 13:20 +0200, Bernhard Loos wrote: > +static HRESULT get_action_info( msi_custom_action_info *info, INT *type, > + BSTR *source, BSTR *target, BSTR *name, > + IWineMsiRemotePackage **package ) > { > - IClassFactory *cf = NULL; > - IWineMsiRemoteCustomAction *rca = NULL; > - HRESULT r; > - > - r = DllGetClassObject( &CLSID_WineMsiRemoteCustomAction, > - &IID_IClassFactory, (LPVOID *)&cf ); > - if (FAILED(r)) > - { > - ERR("failed to get IClassFactory interface\n"); > - return ERROR_FUNCTION_FAILED; > - } > - > - r = IClassFactory_CreateInstance( cf, NULL, &IID_IWineMsiRemoteCustomAction, (LPVOID *)&rca ); > - if (FAILED(r)) > - { > - ERR("failed to get IWineMsiRemoteCustomAction interface\n"); > - return ERROR_FUNCTION_FAILED; > - } > - > - r = IWineMsiRemoteCustomAction_GetActionInfo( rca, guid, type, handle, dll, funcname, package ); > - IWineMsiRemoteCustomAction_Release( rca ); > - if (FAILED(r)) > - { > - ERR("GetActionInfo failed\n"); > - return ERROR_FUNCTION_FAILED; > + IWineMsiRemotePackage *rp; > + HRESULT res; > + *source = *target = *name = NULL; > + > + res = create_msi_remote_package( NULL, (void **) &rp ); > + if (FAILED( res )) > + return res; > + res = IWineMsiRemotePackage_SetMsiHandle( rp, alloc_msihandle( &info->package->hdr ) ); > > You should check for failure from alloc_msihandle. In my defence, it currently also doesn't get checked, but I will add something. > + if (FAILED( res )) > + goto error; > + > + *source = SysAllocString( info->source ); > + *target = SysAllocString( info->target ); > + *name = SysAllocString( info->action ); > + if (!*source || !*target || !*name) { > + res = E_OUTOFMEMORY; > + goto error; > } > - > + > + *package = rp; > + *type = info->type; > + > return ERROR_SUCCESS; > > This should become S_OK. You are mixing up return types in more places.

Oct. 11, 2011

Re: [PATCH 5/7] msi/custom.c: get rid of MSIRUNNINGACTION

by Bernhard Loos

On Tue, Oct 11, 2011 at 3:22 PM, Hans Leidekker <hans(a)codeweavers.com> wrote: > >> -static UINT HANDLE_CustomType50(MSIPACKAGE *package, LPCWSTR source, >> +static msi_custom_action_info *HANDLE_CustomType50(MSIPACKAGE *package, LPCWSTR source, >> LPCWSTR target, const INT type, LPCWSTR action) >> { >> WCHAR *exe, *arg; >> msi_custom_action_info *info; >> >> - if (!(exe = msi_dup_property( package->db, source ))) return ERROR_SUCCESS; >> + if (!(exe = msi_dup_property( package->db, source ))) return NULL; > > Are you sure this should be an error? Native might ignore a missing property. Well, it can't continue with executing the custom action, so it fails (tried this). I will try to add a test for it. >> -static UINT HANDLE_CustomType53_54(MSIPACKAGE *package, LPCWSTR source, >> +static msi_custom_action_info *HANDLE_CustomType53_54(MSIPACKAGE *package, LPCWSTR source, >> LPCWSTR target, const INT type, LPCWSTR action) >> { >> msi_custom_action_info *info; >> WCHAR *prop; >> - UINT r; >> >> TRACE("%s %s\n", debugstr_w(source), debugstr_w(target)); >> >> prop = msi_dup_property( package->db, source ); >> - if (!prop) return ERROR_SUCCESS; >> + if (!prop) return NULL; > > Same here. I never got script actions working (is there any documentation on this?!?), but I would be really surprised, if it silently drops the action and continues with the installation.

Oct. 11, 2011

Re: WineHQ database compromise

by Nicolas Le Cam

2011/10/11 Jerome Leclanche <adys.wh(a)gmail.com>: > Thank you so much for letting the users know so early on. > > Bugzilla/forum passwords should probably be reset as well for appdb > users, there's no doubt most people share passwords with the appdb. > > On Tue, Oct 11, 2011 at 8:13 PM, Jeremy White <jwhite(a)codeweavers.com> wrote: >> Hi, >> >> I am sad to say that there was a compromise of the WineHQ database system. >> >> What we know at this point that someone was able to obtain unauthorized >> access to the phpmyadmin utility. We do not exactly how they obtained >> access; it was either by compromising an admins credentials, or by >> exploiting an unpatched vulnerability in phpmyadmin. >> >> We had reluctantly provided access to phpmyadmin to the appdb developers >> (it is a very handy tool, and something they very much wanted). But it >> is a prime target for hackers, and apparently our best efforts at >> obscuring it and patching it were not sufficient. >> >> So we have removed all access to phpmyadmin from the outside world. >> >> We do not believe the attackers obtained any other form of access to the >> system. >> >> On the one hand, we saw no evidence of harm to any database. We saw no >> evidence of any attempt to change the database (and candidly, using the >> real appdb or bugzilla is the easy way to change the database). >> >> Unfortunately, the attackers were able to download the full login >> database for both the appdb and bugzilla. This means that they have all >> of those emails, as well as the passwords. The passwords are stored >> encrypted, but with enough effort and depending on the quality of the >> password, they can be cracked. >> >> This, I'm afraid, is a serious threat; it means that anyone who uses the >> same email / password on other systems is now vulnerable to a malicious >> attacker using that information to access their account. >> >> We are going to be resetting every password and sending a private email >> to every affected user. >> >> This is again another reminder to never use a common username / password >> pair. This web site provides further advice as well: >> http://asiknews.wordpress.com/2011/03/02/best-practice-password-management-… >> >> I am very sad to have to report this. We have so many challenges in our >> world today that this is a particularly painful form of salt for our wounds. >> >> However, I think it is urgent for everyone to know what happened. >> >> Cheers, >> >> Jeremy >> >> >> > > > Thanks for the early notice ! Testbot passwords should also be reset as it seems it doesn't allow password reset / change ATM. (At least I wasn't able to find that possibility) -- Nicolas Le Cam

Oct. 11, 2011

Re: WineHQ database compromise

by Jerome Leclanche

On Tue, Oct 11, 2011 at 8:46 PM, Jerome Leclanche <adys.wh(a)gmail.com> wrote: > Thank you so much for letting the users know so early on. > > Bugzilla/forum passwords should probably be reset as well for appdb > users, there's no doubt most people share passwords with the appdb. > > On Tue, Oct 11, 2011 at 8:13 PM, Jeremy White <jwhite(a)codeweavers.com> wrote: >> Hi, >> >> I am sad to say that there was a compromise of the WineHQ database system. >> >> What we know at this point that someone was able to obtain unauthorized >> access to the phpmyadmin utility. We do not exactly how they obtained >> access; it was either by compromising an admins credentials, or by >> exploiting an unpatched vulnerability in phpmyadmin. >> >> We had reluctantly provided access to phpmyadmin to the appdb developers >> (it is a very handy tool, and something they very much wanted). But it >> is a prime target for hackers, and apparently our best efforts at >> obscuring it and patching it were not sufficient. >> >> So we have removed all access to phpmyadmin from the outside world. >> >> We do not believe the attackers obtained any other form of access to the >> system. >> >> On the one hand, we saw no evidence of harm to any database. We saw no >> evidence of any attempt to change the database (and candidly, using the >> real appdb or bugzilla is the easy way to change the database). >> >> Unfortunately, the attackers were able to download the full login >> database for both the appdb and bugzilla. This means that they have all >> of those emails, as well as the passwords. The passwords are stored >> encrypted, but with enough effort and depending on the quality of the >> password, they can be cracked. >> >> This, I'm afraid, is a serious threat; it means that anyone who uses the >> same email / password on other systems is now vulnerable to a malicious >> attacker using that information to access their account. >> >> We are going to be resetting every password and sending a private email >> to every affected user. >> >> This is again another reminder to never use a common username / password >> pair. This web site provides further advice as well: >> http://asiknews.wordpress.com/2011/03/02/best-practice-password-management-… >> >> I am very sad to have to report this. We have so many challenges in our >> world today that this is a particularly painful form of salt for our wounds. >> >> However, I think it is urgent for everyone to know what happened. >> >> Cheers, >> >> Jeremy >> >> >> > Nevermind... had not received the other emails yet. Best of luck sorting it all out. JL

Oct. 11, 2011

Re: WineHQ database compromise

by Maarten Lankhorst

Hey everyone, On 10/11/2011 09:13 PM, Jeremy White wrote: > Hi, > > I am sad to say that there was a compromise of the WineHQ database system. > > What we know at this point that someone was able to obtain unauthorized > access to the phpmyadmin utility. We do not exactly how they obtained > access; it was either by compromising an admins credentials, or by > exploiting an unpatched vulnerability in phpmyadmin. > > We had reluctantly provided access to phpmyadmin to the appdb developers > (it is a very handy tool, and something they very much wanted). But it > is a prime target for hackers, and apparently our best efforts at > obscuring it and patching it were not sufficient. > > So we have removed all access to phpmyadmin from the outside world. > > We do not believe the attackers obtained any other form of access to the > system. > > On the one hand, we saw no evidence of harm to any database. We saw no > evidence of any attempt to change the database (and candidly, using the > real appdb or bugzilla is the easy way to change the database). > > Unfortunately, the attackers were able to download the full login > database for both the appdb and bugzilla. This means that they have all > of those emails, as well as the passwords. The passwords are stored > encrypted, but with enough effort and depending on the quality of the > password, they can be cracked. > > This, I'm afraid, is a serious threat; it means that anyone who uses the > same email / password on other systems is now vulnerable to a malicious > attacker using that information to access their account. > You may also want to change your testbot password if you re-used your password.. https://testbot.winehq.org/ForgotPassword.pl Cheers, Maarten

Oct. 11, 2011

Re: WineHQ database compromise

by Jerome Leclanche

Thank you so much for letting the users know so early on. Bugzilla/forum passwords should probably be reset as well for appdb users, there's no doubt most people share passwords with the appdb. On Tue, Oct 11, 2011 at 8:13 PM, Jeremy White <jwhite(a)codeweavers.com> wrote: > Hi, > > I am sad to say that there was a compromise of the WineHQ database system. > > What we know at this point that someone was able to obtain unauthorized > access to the phpmyadmin utility. We do not exactly how they obtained > access; it was either by compromising an admins credentials, or by > exploiting an unpatched vulnerability in phpmyadmin. > > We had reluctantly provided access to phpmyadmin to the appdb developers > (it is a very handy tool, and something they very much wanted). But it > is a prime target for hackers, and apparently our best efforts at > obscuring it and patching it were not sufficient. > > So we have removed all access to phpmyadmin from the outside world. > > We do not believe the attackers obtained any other form of access to the > system. > > On the one hand, we saw no evidence of harm to any database. We saw no > evidence of any attempt to change the database (and candidly, using the > real appdb or bugzilla is the easy way to change the database). > > Unfortunately, the attackers were able to download the full login > database for both the appdb and bugzilla. This means that they have all > of those emails, as well as the passwords. The passwords are stored > encrypted, but with enough effort and depending on the quality of the > password, they can be cracked. > > This, I'm afraid, is a serious threat; it means that anyone who uses the > same email / password on other systems is now vulnerable to a malicious > attacker using that information to access their account. > > We are going to be resetting every password and sending a private email > to every affected user. > > This is again another reminder to never use a common username / password > pair. This web site provides further advice as well: > http://asiknews.wordpress.com/2011/03/02/best-practice-password-management-… > > I am very sad to have to report this. We have so many challenges in our > world today that this is a particularly painful form of salt for our wounds. > > However, I think it is urgent for everyone to know what happened. > > Cheers, > > Jeremy > > >

Oct. 11, 2011

WineHQ database compromise

by Jeremy White

Hi, I am sad to say that there was a compromise of the WineHQ database system. What we know at this point that someone was able to obtain unauthorized access to the phpmyadmin utility. We do not exactly how they obtained access; it was either by compromising an admins credentials, or by exploiting an unpatched vulnerability in phpmyadmin. We had reluctantly provided access to phpmyadmin to the appdb developers (it is a very handy tool, and something they very much wanted). But it is a prime target for hackers, and apparently our best efforts at obscuring it and patching it were not sufficient. So we have removed all access to phpmyadmin from the outside world. We do not believe the attackers obtained any other form of access to the system. On the one hand, we saw no evidence of harm to any database. We saw no evidence of any attempt to change the database (and candidly, using the real appdb or bugzilla is the easy way to change the database). Unfortunately, the attackers were able to download the full login database for both the appdb and bugzilla. This means that they have all of those emails, as well as the passwords. The passwords are stored encrypted, but with enough effort and depending on the quality of the password, they can be cracked. This, I'm afraid, is a serious threat; it means that anyone who uses the same email / password on other systems is now vulnerable to a malicious attacker using that information to access their account. We are going to be resetting every password and sending a private email to every affected user. This is again another reminder to never use a common username / password pair. This web site provides further advice as well: http://asiknews.wordpress.com/2011/03/02/best-practice-password-management-… I am very sad to have to report this. We have so many challenges in our world today that this is a particularly painful form of salt for our wounds. However, I think it is urgent for everyone to know what happened. Cheers, Jeremy

Oct. 11, 2011

Re: [PATCH 1/2] ntdll: windows refuses to load an image; if sections overlap the header size as given in the SizeOfHeaders field

by Stefan Dösinger

On Tuesday 11 October 2011 18:15:29 Dan Kegel wrote: > On Tue, Oct 11, 2011 at 9:10 AM, Bernhard Loos > > <bernhardloos(a)googlemail.com> wrote: > > It gets used in patch 2/2, that's why I overlooked it. Should I still > > resubmit it, as it would be only broken for a single revision? > > It would be nice; that way the tree is a bit easier to bisect, etc, > but mostly that way your patch series will actually be tested by the > buildbot. I think Alexandre builds with -Werror, so he wouldn't apply your patches anyway.

Oct. 11, 2011

Re: [3/3] ddraw: Keep track of interface attached by AddAttachedSurface and detach correct interface when parent is released. (try 2)

by Alexandre Julliard

Octavian Voicu <octavian.voicu(a)gmail.com> writes: > Fixes a bug that causes a stencil buffer leak in the game The Longest Journey. > Problem can be seen in the console output log attached to bug #11819. > This patch doesn't fix the original bug, but now game exits cleanly. > > The root of the problem is that when releasing a surface, its attached > surfaces are detached using IDirectDraw7_DeleteAttachedSurface, regardless > of what interface was originally attached. It doesn't work here: ../../../tools/runtest -q -P wine -M ddraw.dll -T ../../.. -p ddraw_test.exe.so dsurface.c && touch dsurface.ok dsurface.c:1603: Test failed: DeleteAttachedSurface returned 887601cc dsurface.c:3534: Tests skipped: IDirectDraw7_CreateSurface failed, hr = 0x88760091, format D3DFMT_X8B8G8R8 dsurface.c:3534: Tests skipped: IDirectDraw7_CreateSurface failed, hr = 0x88760091, format D3DFMT_X8B8G8R8 dsurface.c:3534: Tests skipped: IDirectDraw7_CreateSurface failed, hr = 0x88760091, format D3DFMT_A2R10G10B10 dsurface.c:3534: Tests skipped: IDirectDraw7_CreateSurface failed, hr = 0x88760091, format D3DFMT_A8L8 make[1]: *** [dsurface.ok] Error 1 -- Alexandre Julliard julliard(a)winehq.org

Oct. 11, 2011

Re: [PATCH 1/2] ntdll: windows refuses to load an image; if sections overlap the header size as given in the SizeOfHeaders field

by Dan Kegel

Incidentally, the reason no automatic email was sent was that gcc still has those nonascii characters in its output, even though I set LANG=C. I'm now adding more logging to see what's up. On Tue, Oct 11, 2011 at 9:06 AM, Dan Kegel <dank(a)kegel.com> wrote: > Hi Bernhard, > Build fails here: > > loader.c: In function ‘test_section_mapping’: > loader.c:706:9: error: unused variable ‘i’ [-Werror=unused-variable] > cc1: all warnings being treated as errors > make[1]: *** [loader.o] Error 1 > make[1]: Leaving directory > `/home/bob/wineslave.dir/sandbox/slave/runtests-default/build/dlls/kernel32/tests' > make: *** [dlls/kernel32/tests] Error 2 > > http://buildbot.kegel.com:8010/builders/runtests-default/builds/159 > > Can you fix and resubmit the series? >

Oct. 11, 2011

Re: [PATCH 1/2] ntdll: windows refuses to load an image; if sections overlap the header size as given in the SizeOfHeaders field

by Dan Kegel

On Tue, Oct 11, 2011 at 9:10 AM, Bernhard Loos <bernhardloos(a)googlemail.com> wrote: > It gets used in patch 2/2, that's why I overlooked it. Should I still > resubmit it, as it would be only broken for a single revision? It would be nice; that way the tree is a bit easier to bisect, etc, but mostly that way your patch series will actually be tested by the buildbot.

Oct. 11, 2011

Re: [PATCH 1/2] ntdll: windows refuses to load an image; if sections overlap the header size as given in the SizeOfHeaders field

by Bernhard Loos

On Tue, Oct 11, 2011 at 6:06 PM, Dan Kegel <dank(a)kegel.com> wrote: > Hi Bernhard, > Build fails here: > > loader.c: In function ‘test_section_mapping’: > loader.c:706:9: error: unused variable ‘i’ [-Werror=unused-variable] > cc1: all warnings being treated as errors > make[1]: *** [loader.o] Error 1 > make[1]: Leaving directory > `/home/bob/wineslave.dir/sandbox/slave/runtests-default/build/dlls/kernel32/tests' > make: *** [dlls/kernel32/tests] Error 2 > > http://buildbot.kegel.com:8010/builders/runtests-default/builds/159 > > Can you fix and resubmit the series? It gets used in patch 2/2, that's why I overlooked it. Should I still resubmit it, as it would be only broken for a single revision?

Oct. 11, 2011

re: [PATCH 1/2] ntdll: windows refuses to load an image; if sections overlap the header size as given in the SizeOfHeaders field

by Dan Kegel

Hi Bernhard, Build fails here: loader.c: In function ‘test_section_mapping’: loader.c:706:9: error: unused variable ‘i’ [-Werror=unused-variable] cc1: all warnings being treated as errors make[1]: *** [loader.o] Error 1 make[1]: Leaving directory `/home/bob/wineslave.dir/sandbox/slave/runtests-default/build/dlls/kernel32/tests' make: *** [dlls/kernel32/tests] Error 2 http://buildbot.kegel.com:8010/builders/runtests-default/builds/159 Can you fix and resubmit the series?

Oct. 11, 2011

Re: [PATCH 4/4] kernel32, ntdll: implement most of GetNamedPipeHandleState

by Bernhard Loos

On Tue, Oct 11, 2011 at 5:12 PM, Juan Lang <juan.lang(a)gmail.com> wrote: > Hi Bernhard, > > nit: > - todo_wine > - ok(!ret && GetLastError() == ERROR_INVALID_PARAMETER, > + todo_wine ok(!ret && GetLastError() == ERROR_INVALID_PARAMETER, > > This change is a no-op. > --Juan > I think I removed it first but had to re-add it later.

Oct. 11, 2011

Re: [PATCH 4/4] kernel32, ntdll: implement most of GetNamedPipeHandleState

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=14813 Your paranoid android. === WNT4WSSP6 (32 bit pipe) === pipe.c:1559: Test failed: expected ERROR_CANNOT_IMPERSONATE, got 203 === W2KPROSP4 (32 bit pipe) === pipe.c:1559: Test failed: expected ERROR_CANNOT_IMPERSONATE, got 997

Oct. 11, 2011

Re: [PATCH 4/4] kernel32, ntdll: implement most of GetNamedPipeHandleState

by Juan Lang

Hi Bernhard, nit: - todo_wine - ok(!ret && GetLastError() == ERROR_INVALID_PARAMETER, + todo_wine ok(!ret && GetLastError() == ERROR_INVALID_PARAMETER, This change is a no-op. --Juan

Oct. 11, 2011

Re: [PATCH 5/7] msi/custom.c: get rid of MSIRUNNINGACTION

by Hans Leidekker

> -static UINT HANDLE_CustomType50(MSIPACKAGE *package, LPCWSTR source, > +static msi_custom_action_info *HANDLE_CustomType50(MSIPACKAGE *package, LPCWSTR source, > LPCWSTR target, const INT type, LPCWSTR action) > { > WCHAR *exe, *arg; > msi_custom_action_info *info; > > - if (!(exe = msi_dup_property( package->db, source ))) return ERROR_SUCCESS; > + if (!(exe = msi_dup_property( package->db, source ))) return NULL; Are you sure this should be an error? Native might ignore a missing property. > -static UINT HANDLE_CustomType53_54(MSIPACKAGE *package, LPCWSTR source, > +static msi_custom_action_info *HANDLE_CustomType53_54(MSIPACKAGE *package, LPCWSTR source, > LPCWSTR target, const INT type, LPCWSTR action) > { > msi_custom_action_info *info; > WCHAR *prop; > - UINT r; > > TRACE("%s %s\n", debugstr_w(source), debugstr_w(target)); > > prop = msi_dup_property( package->db, source ); > - if (!prop) return ERROR_SUCCESS; > + if (!prop) return NULL; Same here.

Oct. 11, 2011

Re: [PATCH 3/3] vbscript: Added Hex function 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 http://testbot.winehq.org/JobDetails.pl?Key=14804 Your paranoid android. === WNT4WSSP6 (32 bit) === No test summary line found === W2KPROSP4 (32 bit) === No test summary line found === WXPPROSP3 (32 bit) === No test summary line found === W2K3R2SESP2 (32 bit) === No test summary line found === WVISTAADM (32 bit) === No test summary line found === W2K8SE (32 bit) === No test summary line found === W7PRO (32 bit) === No test summary line found === W7PROX64 (32 bit) === No test summary line found === TEST64_W7SP1 (32 bit) === No test summary line found === W7PROX64 (64 bit) === No test summary line found === TEST64_W7SP1 (64 bit) === No test summary line found

Oct. 11, 2011

Re: [PATCH 1/7] msi/custom.c: unify thread handling of different custom action types (resend)

by Hans Leidekker

On Tue, 2011-10-11 at 13:20 +0200, Bernhard Loos wrote: +static HRESULT get_action_info( msi_custom_action_info *info, INT *type, + BSTR *source, BSTR *target, BSTR *name, + IWineMsiRemotePackage **package ) { - IClassFactory *cf = NULL; - IWineMsiRemoteCustomAction *rca = NULL; - HRESULT r; - - r = DllGetClassObject( &CLSID_WineMsiRemoteCustomAction, - &IID_IClassFactory, (LPVOID *)&cf ); - if (FAILED(r)) - { - ERR("failed to get IClassFactory interface\n"); - return ERROR_FUNCTION_FAILED; - } - - r = IClassFactory_CreateInstance( cf, NULL, &IID_IWineMsiRemoteCustomAction, (LPVOID *)&rca ); - if (FAILED(r)) - { - ERR("failed to get IWineMsiRemoteCustomAction interface\n"); - return ERROR_FUNCTION_FAILED; - } - - r = IWineMsiRemoteCustomAction_GetActionInfo( rca, guid, type, handle, dll, funcname, package ); - IWineMsiRemoteCustomAction_Release( rca ); - if (FAILED(r)) - { - ERR("GetActionInfo failed\n"); - return ERROR_FUNCTION_FAILED; + IWineMsiRemotePackage *rp; + HRESULT res; + *source = *target = *name = NULL; + + res = create_msi_remote_package( NULL, (void **) &rp ); + if (FAILED( res )) + return res; + res = IWineMsiRemotePackage_SetMsiHandle( rp, alloc_msihandle( &info->package->hdr ) ); You should check for failure from alloc_msihandle. + if (FAILED( res )) + goto error; + + *source = SysAllocString( info->source ); + *target = SysAllocString( info->target ); + *name = SysAllocString( info->action ); + if (!*source || !*target || !*name) { + res = E_OUTOFMEMORY; + goto error; } - + + *package = rp; + *type = info->type; + return ERROR_SUCCESS; This should become S_OK. You are mixing up return types in more places.

Oct. 11, 2011

Re: winex11.drv/keyboard: MAPVK_VK_TO_CHAR correction (Bug 28168)

by Frédéric Delanoy

On Mon, Oct 10, 2011 at 22:46, <sebastian.riemer(a)gmx.de> wrote: > --- > dlls/winex11.drv/keyboard.c | 563 ++++++++++++++++++++++++++++++++++++++----- > 1 files changed, 499 insertions(+), 64 deletions(-) Please follow patch submission rules from http://wiki.winehq.org/SubmittingPatches

Oct. 10, 2011

winex11.drv/keyboard: MAPVK_VK_TO_CHAR direct mapping

by Sebastian Riemer

Hi developers, I've just sent my first patch I would like to see in mainline. I did quite some efforts to verify that my patch is correct by doing extensive compares with Windows, the wine before and the patched wine as well as a special testing version of wine. I want to fix this bug http://bugs.winehq.org/show_bug.cgi?id=28168 and I've attached my verification data there, because this is difficult to integrate into the test suite. Could someone please look at my files and help me with some tips and advice or want to become my mentor? I'm really tired of just writing test data into the AppDB and only little changes over the time for the applications I maintain. So, I want to improve wine for the applications I like. Cheers, Sebastian

Oct. 10, 2011

Re: mscoree: Implement ICorDebug SetManagedHandler (try 3)

by Vincent Povirk

Can we have a WARN message in case of .NET 1 applications? On Mon, Oct 10, 2011 at 2:36 PM, Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> wrote: > On 11/10/2011 2:07 AM, Vincent Povirk wrote: >> >> Should SetManagedHandler really fail if the given object doesn't >> support ICorDebugManagedCallback2 ? > > Yes, this is a requirement for debugging .NET 2 applications. > > Best Regards > Alistair Leslie-Hughes >

Oct. 10, 2011

Re: mscoree: Implement ICorDebug SetManagedHandler (try 3)

by Alistair Leslie-Hughes

On 11/10/2011 2:07 AM, Vincent Povirk wrote: > Should SetManagedHandler really fail if the given object doesn't > support ICorDebugManagedCallback2 ? Yes, this is a requirement for debugging .NET 2 applications. Best Regards Alistair Leslie-Hughes

Oct. 10, 2011

[RFC] Use ICU in wine ?

by Rafał Mużyło

On Mon, Oct 10, 2011 at 07:47:32PM +0200, Shachar Shemesh wrote: > ICU is impossible to dynamically link with, and it's size is quite huge > if statically linked. > Huh ? /usr/lib/libicudata.so.48 /usr/lib/libiculx.so.48 /usr/lib/libicutest.so.48 /usr/lib/libicui18n.so.48 /usr/lib/libicutu.so.48 /usr/lib/libicuio.so.48 /usr/lib/libicuuc.so.48 /usr/lib/libicule.so.48 Care to elaborate ? Yes, it has an annoying habit of ABI breaks, but so does i.e. poppler.

Oct. 10, 2011

Re: [RFC] Use ICU in wine ?

by André Hentschel

Am 10.10.2011 17:33, schrieb Rafał Mużyło: > Anyway, if DUCET and Windows default differ is dumping that default even > allowed ? I don't think so... I once was hacking on our collation stuff too to fix http://bugs.winehq.org/show_bug.cgi?id=5163 but i guess dumping the windows stuff wouldn't even have helped me. -- Best Regards, André Hentschel

Oct. 10, 2011

Re: [RFC] Use ICU in wine ?

by Shachar Shemesh

On 10/10/2011 02:48 AM, Rafał Mużyło wrote: > Right now, wine claims to use DUCET data for lingustic sorting, but by > section 1.9.2 of that document (as of version 6.0.0), uses it in a wrong > way. The result of it are bugs such as #10767 and #9583. > > A possible way around it would beby using ICU to get language specific > tailoring and applying some of wine-specific for the parts addressed by > #10767. I will not go into the part of the discussion that has to do with whether ICU will or will not resolve the issues. I will point out that Wine used to have a soft dependency on ICU (introduced, for my sins, by me) for the sake of BiDi processing. Everyone involved, myself included, were all too happy to see it go. ICU is impossible to dynamically link with, and it's size is quite huge if statically linked. The good news is that ICU's license seems to be compatible with Wine's LGPL, so if needed, the relevant part can be copied into Wine. Shachar -- Shachar Shemesh Lingnu Open Source Consulting Ltd. http://www.lingnu.com

Oct. 10, 2011

[RFC] Use ICU in wine ?

by Rafał Mużyło

On Mon, Oct 10, 2011 at 04:16:26PM +0900, Dmitry Timoshkov wrote (and contradicted himself): > What's DUCET and where do you see Wine does claim to use it? > DUCET: Default Unicode Collation Element Table http://bugs.winehq.org/show_bug.cgi?id=10767#c1 > > but by > > section 1.9.2 of that document (as of version 6.0.0), uses it in a wrong > > way. > http://www.unicode.org/reports/tr10/#Non-Goals, point 6 "...DUCET does not and cannot actually provide linguistically correct sorting for every language without further tailoring...." > Could you please be slightly more specific? > > Looks like that you don't understand what those bugs are about. > Is the above link specific enough ? Anyway, if DUCET and Windows default differ is dumping that default even allowed ? Besides, the only proper way to fix bug #9583 is to implement some kind of language tailoring.

Oct. 10, 2011

Re: mscoree: Implement ICorDebug SetManagedHandler (try 3)

by Vincent Povirk

Should SetManagedHandler really fail if the given object doesn't support ICorDebugManagedCallback2 ? You've got a stray whitespace change in RuntimeHost_Destroy. Otherwise, this looks good to me. On Mon, Oct 10, 2011 at 5:12 AM, Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> wrote: > Hi, > > Only Release the interfaces after we have a valid callback. > Allow multiple Interfaces per runtime. > > > Changelog: > mscoree: Implement ICorDebug SetManagedHandler > > > Best Regards > Alistair Leslie-Hughes > > > > > >

Oct. 10, 2011

DEVELOPMENTAL: use uniscribe in the edit control

by Aric Stewart

This patch is experimental but people had some interest in testing it and I would love some more testing. What is currently known not to be working: * Tabs * Font Fallback * Complex composed glyphs are not breaking or highlighting properly. Testing is appreceated. Send me crashes or incorrect behavior. It should work with both native and builtin usp10. The patch will be cleaned and broken up before being send it this is just for testing. thanks! -aric --- dlls/user32/edit.c | 495 +++++++++++++++++++++++++++------------------------- 1 files changed, 256 insertions(+), 239 deletions(-)

Oct. 10, 2011

[RFC] Use ICU in wine ?

by Rafał Mużyło

On Mon, Oct 10, 2011 at 04:16:26PM +0900, Dmitry Timoshkov wrote (and contradicted himself): > What's DUCET and where do you see Wine does claim to use it? > DUCET: Default Unicode Collation Element Table http://bugs.winehq.org/show_bug.cgi?id=10767#c1 > > but by > > section 1.9.2 of that document (as of version 6.0.0), uses it in a wrong > > way. > http://www.unicode.org/reports/tr10/#Non-Goals, point 6 "...DUCET does not and cannot actually provide linguistically correct sorting for every language without further tailoring...." > Could you please be slightly more specific? > > Looks like that you don't understand what those bugs are about. > Is the above link specific enough ?

Oct. 10, 2011

Re: [1/5] d3d8: Never announce support for palettized textures

by Stefan Dösinger

On Monday 10 October 2011 10:20:15 Henri Verbeet wrote: > It's not really clear to me that refusing to create P8 surfaces in > d3d8/9 really gains us much, or that it's really a prerequisite for > the other patches. I guess you've got a point here, if we just allow the surfaces we'll end up with the same behavior as windows for probably the same reason - functionality for ddraw is exposed via d3d8/9, but because d3d8/9 don't have P8 primaries it is useless. I'll still return D3DERR_INVALIDCALL from the palette setters/getters to remove the d3d8/9 palette API from wined3d, which simplifies the code there. We could implement them via the ddraw palette API, but without test cases showing how they're supposed to work it would be a shot in the dark and most likely dead code.

Oct. 10, 2011

Re: [ 3/3] ddraw: Keep track of interface attached by AddAttachedSurface and detach correct interface when parent is released.

by Octavian Voicu

On Mon, Oct 10, 2011 at 10:04 AM, Henri Verbeet <hverbeet(a)gmail.com> wrote: > Can't you just handle this in ddraw_surface_delete_attached_surface()? > I.e., replace the Release calls in > ddraw_surface?_DeleteAttachedSurface() with a > IUnknown_Release(Surf->attached_iface) in > ddraw_surface_delete_attached_surface(), and then just call > ddraw_surface_delete_attached_surface() where you're using > delete_attached_surface_helper() now. This is much clever! I'll resend the patches, thanks. Octavian

Oct. 10, 2011

Re: [1/5] d3d8: Never announce support for palettized textures

by Henri Verbeet

On 9 October 2011 17:31, Stefan Dösinger <stefan(a)codeweavers.com> wrote: >> - I can't say I find e.g. sprinkling d3dformat_is_palettized() over >> the code particularly elegant. > I suppose I could check for it in IDirect3DDevice8Impl_CreateSurface(and the > d3d9 equivalent), if all calls that create surfaces run through it. > >> - Do you have tests for the D3DERR_INVALIDCALL returns? > I tested that and Windows returns D3D_OK. Windows also allows creating P8 > offscreen plain surfaces, and it allows StretchRect operations between those > surfaces. It doesn't allow StretchRect operations between P8 and non- > Palettized surfaces. In the end I could not find any way to make use of those > surfaces I could create. > > I prefer to return INVALIDCALL over the half-baked implementation Windows has > to find applications that try to use P8 surfaces in a way I may have missed. > It's not really clear to me that refusing to create P8 surfaces in d3d8/9 really gains us much, or that it's really a prerequisite for the other patches. If you want to go that way though, you should probably just map D3DFORMAT_P8 to something that's not WINED3DFMT_P8_UINT, perhaps WINED3DFMT_UNSUPPORTED, and just let wined3d fail resource creation.

Oct. 10, 2011

Re: [RFC] Use ICU in wine ?

by Dmitry Timoshkov

Rafał Mużyło <galtgendo(a)o2.pl> wrote: > Right now, wine claims to use DUCET data for lingustic sorting, What's DUCET and where do you see Wine does claim to use it? > but by > section 1.9.2 of that document (as of version 6.0.0), uses it in a wrong > way. Could you please be slightly more specific? > The result of it are bugs such as #10767 and #9583. Looks like that you don't understand what those bugs are about. > A possible way around it would beby using ICU to get language specific > tailoring and applying some of wine-specific for the parts addressed by > #10767. Once you uderstand the problems you may see that adding ICU to Wine depencies will create much more problems than it's supposedly will solve. -- Dmitry.

Oct. 10, 2011

Re: [ 3/3] ddraw: Keep track of interface attached by AddAttachedSurface and detach correct interface when parent is released.

by Henri Verbeet

On 10 October 2011 08:07, Octavian Voicu <octavian.voicu(a)gmail.com> wrote: > +static HRESULT delete_attached_surface_helper(IDirectDrawSurfaceImpl *root, IDirectDrawSurfaceImpl *detach) > +{ > + if (detach->attached_iface == &detach->IDirectDrawSurface4_iface) > + return IDirectDrawSurface4_DeleteAttachedSurface(&root->IDirectDrawSurface4_iface, 0, > + &detach->IDirectDrawSurface4_iface); > + else if (detach->attached_iface == &detach->IDirectDrawSurface3_iface) > + return IDirectDrawSurface3_DeleteAttachedSurface(&root->IDirectDrawSurface3_iface, 0, > + &detach->IDirectDrawSurface3_iface); > + else if (detach->attached_iface == &detach->IDirectDrawSurface2_iface) > + return IDirectDrawSurface2_DeleteAttachedSurface(&root->IDirectDrawSurface2_iface, 0, > + &detach->IDirectDrawSurface2_iface); > + else if (detach->attached_iface == &detach->IDirectDrawSurface_iface) > + return IDirectDrawSurface_DeleteAttachedSurface(&root->IDirectDrawSurface_iface, 0, > + &detach->IDirectDrawSurface_iface); > + else if (detach->attached_iface != &detach->IDirectDrawSurface7_iface) > + FIXME("attached_iface %p is invalid for surface %p\n", detach->attached_iface, detach); > + > + return IDirectDrawSurface7_DeleteAttachedSurface(&root->IDirectDrawSurface7_iface, 0, > + &detach->IDirectDrawSurface7_iface); > +} > + Can't you just handle this in ddraw_surface_delete_attached_surface()? I.e., replace the Release calls in ddraw_surface?_DeleteAttachedSurface() with a IUnknown_Release(Surf->attached_iface) in ddraw_surface_delete_attached_surface(), and then just call ddraw_surface_delete_attached_surface() where you're using delete_attached_surface_helper() now.

Oct. 10, 2011

Re: [PATCH] ntdll: deal with images which override the section table during mapping

by Marcus Meissner

On Mon, Oct 10, 2011 at 11:36:33AM +0200, Bernhard Loos wrote: > --- > dlls/ntdll/virtual.c | 38 ++++++++++++++++++++++++++++++++++---- > 1 files changed, 34 insertions(+), 4 deletions(-) I think this needs tests, the algorithms are very fragile. Ciao, Marcus > diff --git a/dlls/ntdll/virtual.c b/dlls/ntdll/virtual.c > index 5e69eb9..7841d9c 100644 > --- a/dlls/ntdll/virtual.c > +++ b/dlls/ntdll/virtual.c > @@ -1114,6 +1114,7 @@ static NTSTATUS map_image( HANDLE hmapping, int fd, char *base, SIZE_T total_siz > IMAGE_DOS_HEADER *dos; > IMAGE_NT_HEADERS *nt; > IMAGE_SECTION_HEADER *sec; > + IMAGE_SECTION_HEADER *section_table = NULL; > IMAGE_DATA_DIRECTORY *imports; > NTSTATUS status = STATUS_CONFLICTING_ADDRESSES; > int i; > @@ -1123,6 +1124,7 @@ static NTSTATUS map_image( HANDLE hmapping, int fd, char *base, SIZE_T total_siz > struct file_view *view = NULL; > char *ptr, *header_end; > INT_PTR delta = 0; > + DWORD SizeOfHeaders; > > /* zero-map the whole range */ > > @@ -1158,8 +1160,11 @@ static NTSTATUS map_image( HANDLE hmapping, int fd, char *base, SIZE_T total_siz > header_end = ptr + ROUND_SIZE( 0, header_size ); > memset( ptr + header_size, 0, header_end - (ptr + header_size) ); > if ((char *)(nt + 1) > header_end) goto error; > - sec = (IMAGE_SECTION_HEADER*)((char*)&nt->OptionalHeader+nt->FileHeader.SizeOfOptionalHeader); > - if ((char *)(sec + nt->FileHeader.NumberOfSections) > header_end) goto error; > + section_table = (IMAGE_SECTION_HEADER*)((char*)&nt->OptionalHeader+nt->FileHeader.SizeOfOptionalHeader); > + /* make sure we mapped enough memory */ > + if ((char *)(section_table + nt->FileHeader.NumberOfSections) > header_end) goto error; > + /* windows is only interested in the size as given by OptionalHeader.SizeOfHeaders */ > + SizeOfHeaders = ROUND_SIZE( 0, nt->OptionalHeader.SizeOfHeaders ); > > imports = nt->OptionalHeader.DataDirectory + IMAGE_DIRECTORY_ENTRY_IMPORT; > if (!imports->Size || !imports->VirtualAddress) imports = NULL; > @@ -1180,7 +1185,7 @@ static NTSTATUS map_image( HANDLE hmapping, int fd, char *base, SIZE_T total_siz > if (nt->OptionalHeader.FileAlignment != nt->OptionalHeader.SectionAlignment) goto error; > for (i = 0; i < nt->FileHeader.NumberOfSections; i++) > { > - if (sec[i].VirtualAddress != sec[i].PointerToRawData) > + if (section_table[i].VirtualAddress != section_table[i].PointerToRawData) > goto error; /* Windows refuses to load in that case too */ > } > > @@ -1192,6 +1197,24 @@ static NTSTATUS map_image( HANDLE hmapping, int fd, char *base, SIZE_T total_siz > goto done; > } > > + if ((char *)(section_table + nt->FileHeader.NumberOfSections) > ptr + SizeOfHeaders) > + { > + /* part of the section table is outside of SizeOfHeaders > + * at this point, it's likely that a section will get mapped over > + * the section table (Borderlands does this) > + * Not sure how it works on Windows, but we make a copy of the > + * table at this point */ > + sec = RtlAllocateHeap( virtual_heap, 0, sizeof(*sec) * nt->FileHeader.NumberOfSections); > + if (!sec) > + { > + status = STATUS_NO_MEMORY; > + goto error; > + } > + memcpy( sec, section_table, sizeof(*sec) * nt->FileHeader.NumberOfSections); > + section_table = sec; > + } > + else > + sec = section_table; > > /* map all the sections */ > > @@ -1200,6 +1223,9 @@ static NTSTATUS map_image( HANDLE hmapping, int fd, char *base, SIZE_T total_siz > static const SIZE_T sector_align = 0x1ff; > SIZE_T map_size, file_start, file_size, end; > > + if (sec->VirtualAddress < SizeOfHeaders) > + goto error; > + > if (!sec->Misc.VirtualSize) > map_size = ROUND_SIZE( 0, sec->SizeOfRawData ); > else > @@ -1329,7 +1355,7 @@ static NTSTATUS map_image( HANDLE hmapping, int fd, char *base, SIZE_T total_siz > > VIRTUAL_SetProt( view, ptr, ROUND_SIZE( 0, header_size ), VPROT_COMMITTED | VPROT_READ ); > > - sec = (IMAGE_SECTION_HEADER*)((char *)&nt->OptionalHeader+nt->FileHeader.SizeOfOptionalHeader); > + sec = section_table; > for (i = 0; i < nt->FileHeader.NumberOfSections; i++, sec++) > { > SIZE_T size; > @@ -1361,6 +1387,8 @@ static NTSTATUS map_image( HANDLE hmapping, int fd, char *base, SIZE_T total_siz > } > > done: > + if (section_table && (char *)section_table != (char *)&nt->OptionalHeader+nt->FileHeader.SizeOfOptionalHeader) > + RtlFreeHeap( virtual_heap, 0, section_table ); > view->mapping = dup_mapping; > server_leave_uninterrupted_section( &csVirtual, &sigset ); > > @@ -1373,6 +1401,8 @@ static NTSTATUS map_image( HANDLE hmapping, int fd, char *base, SIZE_T total_siz > > error: > if (view) delete_view( view ); > + if (section_table && (char *)section_table != (char *)&nt->OptionalHeader+nt->FileHeader.SizeOfOptionalHeader) > + RtlFreeHeap( virtual_heap, 0, section_table ); > server_leave_uninterrupted_section( &csVirtual, &sigset ); > if (dup_mapping) NtClose( dup_mapping ); > return status; >

Oct. 9, 2011

[RFC] Use ICU in wine ?

by Rafał Mużyło

Right now, wine claims to use DUCET data for lingustic sorting, but by section 1.9.2 of that document (as of version 6.0.0), uses it in a wrong way. The result of it are bugs such as #10767 and #9583. A possible way around it would beby using ICU to get language specific tailoring and applying some of wine-specific for the parts addressed by #10767. In a way, wine already *indirectly* depends on icu on many distros (a potential libxml2 dep) - they were quite a few patches already addressing build failures caused by this in recent past. I've cooked up a patch, that's unfortunately isn't working properly yet, it's more of a draft on where to go, if such road were to be taken. Main issue with this patch ain't it's not ignoring the proper list of symbols, as this would be easy to fix, if not for one problem: the part that I put inside 'if (0)' block. For some reason (threading, perhaps ?), if I pass a non-zero lenght string to ucol_openRules, wineboot hangs. Oddly, if the string lenght is 0, the hang doesn't happen. I can't really tell, what going wrong, as the almost same code works in native linux testcase. Also, while in this patch UCOL_ALTERNATE_HANDLING would have been used for NORM_IGNORESYMBOLS, it would be much better to manipulate some of the settings by a custom rule and VariableTop value, but to do that, first such rule would have to be passed and that odd hang prevents it at the moment. It would also be nice, if it was possible to initialize the collator only once for an app instance - after all, in Windows locale change requires a reboot, so while (AFAIK) one wineserver instance can have apps in different locales running, locale can't change for an already running app. So if you have any idea of why exactly the hang happens and how to get around it or know any *technical* reasons of why ICU couldn't be used in wine, CC me with comments.

Oct. 9, 2011

Re: [PATCH] server: if a debugger is attached to a process, child processes shouldn't get debugged (resend)

by Bernhard Loos

On Sat, Oct 8, 2011 at 10:05 AM, David Laight <david(a)l8s.co.uk> wrote: > On Fri, Oct 07, 2011 at 08:32:27PM +0200, Marcus Meissner wrote: >> On Fri, Oct 07, 2011 at 11:44:24AM +0900, Dmitry Timoshkov wrote: >> > Bernhard Loos <bernhardloos(a)googlemail.com> wrote: >> > >> > > + int debug_childs:1; /* also debug all child processes */ >> > >> > 'debug_children' would be a better name. >> >> also >> unsigned int foo:1; >> please. (int foo:1 works, but is semidefined only ;) > > Why the bitfield anyway? > Unless you are allocating a lot of copies of the structure > it is likely to generate more code than the saved memory. Actually, the generated code is pretty much exactly the same size or even smaller for one function. Also, it makes it clear that this is a boolean flag. > David > > -- > David Laight: david(a)l8s.co.uk >

Oct. 9, 2011

Re: The major mmdevapi and winmm audio bugs

by Austin English

On Fri, Oct 7, 2011 at 09:24, <Joerg-Cyril.Hoehle(a)t-systems.com> wrote: > Hi, > > Bugzilla admins, please set the 1.4 milestone on all bugs mentioned here. > > I'm not yet looking at dsound issues since I first want a correct > foundation upon which to build to upper layers. > > o #28039 IAudioClock_GetPosition must ignore underruns (MacOS) > Here I've no idea how to solve this. My initial query remained unanswered: > http://lists.apple.com/archives/coreaudio-api//2011/Sep/msg00024.html > Ken? Andrew's yesterday patch (using GetCurrentPadding) is an interim > work-around. GetPosition (speaker) is unrelated to padding which is > solely about buffering. > > o #28093 GetCurrentPadding must slowly decrease (MacOS) > may cause an app to play audio using a single buffer, causing > underruns and audio drop outs. > > o #28056 Problems with sound under FreeBSD > which became "blocking calls with OSS" > recently addressed by Andrew. > > o snd_pcm_drop causes incorrect GetPosition after mmdevapi Stop > which I believe to be the cause of: > #27901 winmm tests timing out waiting for hevent after waveOutRestart > May get solved by Andrew's work in: > #28517 Pikachu Volleyball stops playing sound effects > > Every snd_pcm_drop and reset must be inspected with care w.r.t. its > effect on GetPosition. Wine must ensure that after playing ends, > GetPosition == sum of written samples for both mmdevapi and winmm. > > o #27937 winmm kept busy playing silence after play finishes > IIRC because winmm writes silence. Once mmdevapi handles underruns > correctly, my patch "winmm: Never write silence, mmdevapi must handle > underruns." will become applicable: > http://www.winehq.org/pipermail/wine-patches/2011-September/107108.html > > Playing silence causes: > #28027 μ-law rendering with pauses and repetitions (MacOS) > as well as presumably: > #28413 Sound play in games and programs causes brief "pauses" > at the time dsound used winmm prior to 1.3.29. > > o #28047 IAudioClock_GetPosition must not depend on buffering (ALSA/Pulse) > ALSA must derive GetPosition from snd_pcm_delay, not snd_pcm_avail_update > > > There are other issues not associated with a bug entry. I'm off for > vacation, but here's a snippet from my TODO list: > - OSS GetPosition from DSP_GETODELAY > - ALSA+OSS: ReleaseBuffer: check method ordering and max size > - GetStreamLatency = Xms + SHAREDMODE:period > Stream latency is a static property of the audio graph's components. > - wineoss GetStreamLatency must be constant, and SNDCTL_DSP_GETODELAY > is only usable once running > - Check WHDR_BEGIN/ENDLOOP code and write tests > - WINMM_GetPosition is simply written_frames, not even minus padding > (as the old alsa driver did), later use mmdevapi:GetPosition. > - winmm PushData without IAC_Reset or last_clock_pos=0 in case of underrun > - Investigate OSS4 underrun behaviour > - Align wineOSS on newest ALSA code improvements > - Submit CoreAudio memory leak fix to #28023; Write error handling patch > - Check ALSA laptop suspend w.r.t. GetPosition > - Add run-time consistency checks in renderer and > abort audio stream (GetData) upon trouble instead of hanging. > > and finally: > > - Test compatibility with native DSound and file bug if unusable. > There are several reports in bugzilla mentioning that this work-around > ceased to work since 1.3.25. Loss of interoperability is not acceptable. > > Regards, > Jörg Höhle Done. In the future, please post full urls, makes my job easier :). I've also given you bug editing/confirming privileges in bugzilla. Cheers, Austin

Oct. 9, 2011

Re: [PATCH] server: Use syscall(2) instead of inline assembly on Mac OS, too.

by Charles Davis

On Oct 9, 2011, at 1:42 PM, David Laight wrote: > On Sat, Oct 08, 2011 at 07:48:40PM +0200, Alexandre Julliard wrote: >> Charles Davis <cdavis(a)mymail.mines.edu> writes: >> >>> @@ -268,9 +256,9 @@ int send_thread_signal( struct thread *thread, int sig ) >>> if (!mach_port_extract_right( process_port, thread->unix_tid, >>> MACH_MSG_TYPE_COPY_SEND, &port, &type )) >>> { >>> - if ((ret = pthread_kill_syscall( port, sig )) < 0) >>> + if ((ret = syscall( SYS___pthread_kill, port, sig )) != 0) >>> { >>> - errno = -ret; >>> + errno = ret; >> >> syscall is supposed to take care of errno. > > I'm also not at all sure of the portability of using syscall() in > application code. > > What happens when you try to run the above on anything other than Linux? > (Eg aone of the BSDs) That's just it. None of that code is portable. It was designed specifically to work on Darwin (Mac OS X/iOS). (It was even worse before. It used x86 assembly to make the syscall, so it would only work on an Intel Mac--and only in 32-bit mode at that. So if anything, this is making it *more* portable.) It doesn't get compiled anywhere else anyway. For this particular file, the only other system I would be worried about is the HURD (the only other OS I know of that's based on Mach), which hardly anyone uses in practice anyway. Also, if you'll look at Wine's development history, you'll notice similar patches by Maarten Lankhorst and, yes, by AJ himself, for Linux. Chip

Oct. 9, 2011

Re: [PATCH] server: Use syscall(2) instead of inline assembly on Mac OS, too.

by David Laight

On Sat, Oct 08, 2011 at 07:48:40PM +0200, Alexandre Julliard wrote: > Charles Davis <cdavis(a)mymail.mines.edu> writes: > > > @@ -268,9 +256,9 @@ int send_thread_signal( struct thread *thread, int sig ) > > if (!mach_port_extract_right( process_port, thread->unix_tid, > > MACH_MSG_TYPE_COPY_SEND, &port, &type )) > > { > > - if ((ret = pthread_kill_syscall( port, sig )) < 0) > > + if ((ret = syscall( SYS___pthread_kill, port, sig )) != 0) > > { > > - errno = -ret; > > + errno = ret; > > syscall is supposed to take care of errno. I'm also not at all sure of the portability of using syscall() in application code. What happens when you try to run the above on anything other than Linux? (Eg aone of the BSDs) David -- David Laight: david(a)l8s.co.uk

Oct. 9, 2011

valgrind and buildbot

by Dan Kegel

As always, http://buildbot.kegel.com is just now starting to look stable (kind of like fusion power is always nearly practical). So I'm starting to look at adding valgrind to the buildbot. I won't check for memory leaks at all, since those are too numerous to count. And I'll only valgrind the tests immediately related to each proposed patch. First, though, I need a complete suppressions file for all existing wine valgrind warnings. That's going to take a while to put together, since some of the warnings don't show up on every run. And before I bother to automate anything, I'm taking a little detour, looking at the existing warnings, and trying to see if we can make a little progress on some of them. The script http://code.google.com/p/winezeug/source/browse/trunk/buildbot/runval.sh is how I'm starting to do a manual sweep for valgrind errors. I'm going DLL by DLL, starting with advapi32, looking carefully at each valgrind error. For each error that looks spurious or expected, I will add a suppression to the existing global suppressions file, http://code.google.com/p/winezeug/source/browse/trunk/valgrind/valgrind-sup… For each error that looks real, I'll try to understand it and fix it if the error is not deep, or file a wine bug and add a matching suppression to http://code.google.com/p/winezeug/source/browse/trunk/buildbot/valgrind-bla… When bugs get fixed, I'll remove the matching suppressions from that file. This morning I looked at a grand total of one valgrind warning (in advapi32/security.c), and filed http://bugs.winehq.org/show_bug.cgi?id=28628 for it. I did glance at a couple more; advapi32/crypt.c has a bunch of expected errors (which I'll probably add to valgrind-suppressions), and atl/atl_ax has a bunch of what look like real errors (which I'll probably file a bug for and add to valgrind-blacklist). It'll probably take quite a while to catalog the baseline errors and get a complete blacklist. If it takes too long (more than a few weeks), I'll chuck it and do a dumb blanket suppression of all existing warnings.

Oct. 9, 2011

Re: [1/5] d3d8: Never announce support for palettized textures

by Stefan Dösinger

On Sunday 09 October 2011 16:40:11 Henri Verbeet wrote: > I thought you asked me not to look at these patches yet because you > still had some issues to fix. Regardless, I gave this a cursory look: Yeah, those were the ones that implemented blitting in a different way in wined3d and had issues with palette changes and SFLAG_CONVERTED. The patches I sent to wine-devel have this fixed, and the patches I sent to wine-patches aren't affected by this. > - I can't say I find e.g. sprinkling d3dformat_is_palettized() over > the code particularly elegant. I suppose I could check for it in IDirect3DDevice8Impl_CreateSurface(and the d3d9 equivalent), if all calls that create surfaces run through it. > - Do you have tests for the D3DERR_INVALIDCALL returns? I tested that and Windows returns D3D_OK. Windows also allows creating P8 offscreen plain surfaces, and it allows StretchRect operations between those surfaces. It doesn't allow StretchRect operations between P8 and non- Palettized surfaces. In the end I could not find any way to make use of those surfaces I could create. I prefer to return INVALIDCALL over the half-baked implementation Windows has to find applications that try to use P8 surfaces in a way I may have missed. > - In patch 5 you remove wined3d_device_get_current_texture_palette() > from the spec but not from the public header. Oops, thanks for catching that.

Oct. 9, 2011

Re: [1/5] d3d8: Never announce support for palettized textures

by Henri Verbeet

On 9 October 2011 15:21, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > This is the first set of my P8 patches, they remove dead code that is left over > from d3d8/9 style palettized texture support. See > http://www.winehq.org/pipermail/wine-devel/2011-October/092744.html for the > entire patchset. > I thought you asked me not to look at these patches yet because you still had some issues to fix. Regardless, I gave this a cursory look: - I can't say I find e.g. sprinkling d3dformat_is_palettized() over the code particularly elegant. - Do you have tests for the D3DERR_INVALIDCALL returns? - In patch 5 you remove wined3d_device_get_current_texture_palette() from the spec but not from the public header.

Oct. 9, 2011

Palettized ddraw surface patches

by Stefan Dösinger

Hi, I'll start sending my patches for blitting palettized surfaces with opengl. There are quite a few patches and I won't send them all in one, so this mail shows where I am headed. Palettized surfaces are in a bad shape right now, both in terms of code quality and functionality. My patches will not fix all issues because this would require a shadow frontbuffer in wined3d, and Henri and I agreed that this should wait until after Wine 1.4. However, my patches fix a number of issues and eliminate a lot of dead code and hacks. Other work that needs to be done, but is separate from those patches: *) Emulate color keying in the ARBfp fragment pipeline. That way the upload- time color keying conversion can be limited to situations where shaders are not available and the alpha = 0.0 hack in patch 20 removed. *) Finish the blit infrastructure cleanup. Mainly, get rid of the hardcoded arbfp_blit backend in wined3d_surface_blt, get rid of arbfp_blit_surface and the remains of IWineD3DSurfaceImpl_BltOverride. *) Investigate if there's any point in P8 blitting with ATIfs and nvrc. The fixed function pipeline replacements would profit from proper 3D color keying, but that only works if we have blitters that can blit without color keying during texture upload. *) Make overlays work properly again. The overlay tests work, but the d3d7 sdk samples refuse to run for some reason. With the GL ddraw renderer as default we can also look into games like Settlers 3 that use overlays to draw the mouse pointer. @Henri and Matteo: The difference between this patchset and the one I sent you a few days ago is that my old patchset made onscreen surfaces as a whole a special case, while this one only has special handling for blits to onscreen surfaces. The new way needs less infrastructure changes, works better with palette changes and is a lot closer to how things should work with a shadow frontbuffer in wined3d. Stefan

Oct. 9, 2011

Re: The major mmdevapi and winmm audio bugs

by Ken Thomases

On Oct 7, 2011, at 9:24 AM, Joerg-Cyril.Hoehle(a)t-systems.com wrote: > o #28039 IAudioClock_GetPosition must ignore underruns (MacOS) > Here I've no idea how to solve this. My initial query remained unanswered: > http://lists.apple.com/archives/coreaudio-api//2011/Sep/msg00024.html > Ken? Andrew's yesterday patch (using GetCurrentPadding) is an interim > work-around. GetPosition (speaker) is unrelated to padding which is > solely about buffering. It is expected that the queue's time keeps incrementing even when no buffers are enqueued. For example, see <https://developer.apple.com/library/ios/#qa/qa1718/_index.html>. Here's one possible solution: Enqueue the buffers with AudioQueueEnqueueBufferWithParameters() to get back the actual start time (in the queue's time frame) at which each buffer is scheduled to start. Then, compare AudioQueueGetCurrentTime() with the scheduled start time of the enqueued buffer(s) to see how far into which buffer the queue has played. The code will have to track the position (in the desired sense) separately from the queue time. There will be a scalar value containing the sum of the lengths of all buffers known to have been completely played. There will also be a list of time ranges for those buffers which have been queued but are not known to have been completely played yet. For each buffer, the time range consists of its scheduled start time and its length. At certain points -- ca_out_buffer_cb() and GetPosition() -- AudioQueueGetCurrentTime() will be called. The buffer list will be scanned. All the buffers whose end time (i.e. start time + length) is less than the queue time will be removed from the list, with their lengths added into the sum. That's all that's necessary for ca_out_buffer_cb() and is only done in that function to make sure the buffer list doesn't keep growing if GetPosition() is rarely or never called. For GetPosition(), the queue time will be compared to the first buffer that remains in the list, if any. If there are no buffers or the queue time is before the start time of the first buffer, then GetPosition() returns the sum. Otherwise, it will return the sum plus the queue time minus the buffer start time. AudioClient_Reset() will clear the buffer list (and the sum?). There's another approach that came to mind, but I don't think it's feasible: only run the queue when there are actually buffers to play. Don't start the queue until a buffer has been enqueued and stop it when there are no more ready. Basically, during the callback when the queue is requesting another buffer, if there's nothing to enqueue, call AudioQueueStop(..., FALSE). You may also need to use AudioQueueAddPropertyListener() to observe kAudioQueueProperty_IsRunning to learn when it has actually stopped, since the queue's time will reset to 0 at that point. During each period of the queue running, its time will reflect actual queued samples being played. Timeline discontinuities occur when the sample rate changes, the output device is switched, the DSP has to be reset, or that sort of thing, I believe. They don't have anything to do with underruns of the kind you're considering. Regards, Ken

Oct. 9, 2011

Re: inetmib1: Avoid idempotent operation in findSupportedQuery function (Clang)

by Octavian Voicu

2011/10/2 Frédéric Delanoy <frederic.delanoy(a)gmail.com> > - for (i = (indexLow + indexHigh) / 2; !impl && indexLow <= indexHigh; > - i = (indexLow + indexHigh) / 2) > + for (i = indexHigh / 2; !impl && indexLow <= indexHigh; i = (indexLow + indexHigh) / 2) How about following code: while (!impl && indexLow <= indexHigh) { /* ... */ i = (indexLow + indexHigh) / 2; /* ... */ } Octavian

Oct. 8, 2011

Re: jscript: Mark some fall-throughs in switch statements

by Andrew Talbot

> Isn't it that way just to save the use of an extra return S_OK? > Instead a break could be used too because that function returns S_OK > by default. > > http://source.winehq.org/source/dlls/jscript/regexp.c#L4025 > > Best regards, > Bruno A fall-through would indeed be lazy and not in the spirit of the fact that DISPATCH_PROPERTYGET and DISPATCH_PROPERTYPUT are kind of the opposite of each other. It either requires a break in both places (for consistency) to the common "return S_OK" or two immediate such returns, instead. -- Andy.

Oct. 8, 2011

Re: jscript: Mark some fall-throughs in switch statements

by Bruno Jesus

On Sat, Oct 8, 2011 at 14:58, Alexandre Julliard <julliard(a)winehq.org> wrote: > Andrew Talbot <andrew.talbot(a)talbotville.com> writes: > >> @@ -4037,6 +4037,7 @@ static HRESULT RegExpConstr_leftContext(script_ctx_t *ctx, vdisp_t *jsthis, WORD >> >> V_VT(retv) = VT_BSTR; >> V_BSTR(retv) = ret; >> + /* fall through */ >> } >> case DISPATCH_PROPERTYPUT: >> return S_OK; > > I don't think that PROPERTYGET is supposed to fall through to > PROPERTYPUT. > Isn't it that way just to save the use of an extra return S_OK? Instead a break could be used too because that function returns S_OK by default. http://source.winehq.org/source/dlls/jscript/regexp.c#L4025 Best regards, Bruno

Oct. 8, 2011

Re: trunk build

by Charles Davis

This can't be related to my syscall patch. On Oct 8, 2011, at 12:12 PM, buildbot(a)kegel.com wrote: > This is an experimental automated build and test service. > Please feel free to ignore this email while we work the kinks out. > > For more info about this message, see http://wiki.winehq.org/BuildBot > > The Buildbot has detected a failed build on builder runtests-default while building Wine. > Full details are available at: http://buildbot.kegel.com/builders/runtests-default/builds/74 (though maybe not for long, as I'm still reinstalling the buildbot periodically while experimenting) > BUILD FAILED: failed shell_3 > > Errors: > alarum: failed command was ../../../wine ddraw_test.exe.so visual.c > fixme:win:EnumDisplayDevicesW ((null),0,0x32f54c,0x00000000), stub! > fixme:d3d_draw:drawPrimitive Using software emulation because manual fog coordinates are provided > err:d3d:wined3d_device_uninit_3d Something is still holding a reference to depth/stencil buffer 0x15f090. > fixme:win:EnumDisplayDevicesW ((null),0,0x32f53c,0x00000000), stub! > visual.c:1903: Tests skipped: device has no P8 texture support, skipping test > fixme:ddraw:IDirect3DDeviceImpl_7_Release Texture handle 0x2 (0x1aff68) not unset properly. > fixme:win:EnumDisplayDevicesW ((null),0,0x32f47c,0x00000000), stub! > fixme:win:EnumDisplayDevicesW ((null),0,0x32ecbc,0x00000000), stub! > err:d3d_surface:d3dfmt_p8_init_palette This code should never get entered for DirectDraw!, expect problems > err:d3d_surface:d3dfmt_p8_init_palette This code should never get entered for DirectDraw!, expect problems > err:d3d_surface:d3dfmt_p8_init_palette This code should never get entered for DirectDraw!, expect problems > XIO: fatal IO error 11 (Resource temporarily unavailable) on X server ":0.0" > after 1272 requests (1271 known processed) with 0 events remaining. > make: *** [visual.ok] Error 1 > alarum: failed command was ../../../wine ddrawex_test.exe.so surface.c > Application tried to create a window, but no driver could be loaded. > Make sure that your X server is running and that $DISPLAY is set correctly. > err:d3d_caps:WineD3D_CreateFakeGLContext Failed to create a window. > err:d3d:InitAdapters Failed to get a gl context for default adapter > err:ddraw:PixelFormat_WineD3DtoDD Can't translate this Pixelformat 0 > surface.c:87: Test failed: IDirectDraw_CreateSurface failed: 0x88760091 > wine: Unhandled page fault on read access to 0x00000000 at address 0x684b5510 (thread 003b), starting debugger... > Unhandled exception: page fault on read access to 0x00000000 in 32-bit code (0x684b5510). > Register dump: > CS:0073 SS:007b DS:007b ES:007b FS:0033 GS:003b > EIP:684b5510 ESP:0032fa40 EBP:0032fb68 EFLAGS:00210206( R- -- I - -P- ) > EAX:00000000 EBX:684bbff4 ECX:00000078 EDX:0032fae8 > ESI:0032fe38 EDI:00000000 > Stack dump: > 0x0032fa40: 0032fa6c 00000000 0000007c 40013497 > 0x0032fa50: 00000000 00004800 88760091 00124ce8 > 0x0032fa60: 0011ce9c 40027ff4 0032fb38 0000007c > 0x0032fa70: 00000000 00000000 00000000 00000000 > 0x0032fa80: 00000000 00000000 00000000 00000000 > 0x0032fa90: 00000000 00000000 00000000 00000000 > Backtrace: > =>0 0x684b5510 dctest_surf+0x69(surf=(nil), ddsdver=0x1) [/home/bob/wineslave.dir/sandbox/slave/runtests-default/build/dlls/ddrawex/tests/surface.c:54] in ddrawex_test (0x0032fb68) > 1 0x684b57ef GetDCTest_main+0xc3(ddsd=0x32fc54, ddsd2=0x32fbd8, testfunc=0x684b54a7) [/home/bob/wineslave.dir/sandbox/slave/runtests-default/build/dlls/ddrawex/tests/surface.c:88] in ddrawex_test (0x0032fbb8) > 2 0x684b5ce4 GetDCTest+0xc1() [/home/bob/wineslave.dir/sandbox/slave/runtests-default/build/dlls/ddrawex/tests/surface.c:153] in ddrawex_test (0x0032fcc8) > 3 0x684b732c func_surface+0x1e0() [/home/bob/wineslave.dir/sandbox/slave/runtests-default/build/dlls/ddrawex/tests/surface.c:436] in ddrawex_test (0x0032fcf8) > 4 0x684b8073 run_test+0x9e(name="surface.c") [/home/bob/wineslave.dir/sandbox/slave/runtests-default/build/dlls/ddrawex/tests/../../../include/wine/test.h:556] in ddrawex_test (0x0032fd58) > 5 0x684b8488 main+0x23a(argc=<couldn't compute location>, argv=0x1103d0) [/home/bob/wineslave.dir/sandbox/slave/runtests-default/build/dlls/ddrawex/tests/../../../include/wine/test.h:624] in ddrawex_test (0x0032fe28) > 6 0x684b8516 __wine_spec_exe_entry+0x69(peb=0x7ffdf000) [/home/bob/wineslave.dir/sandbox/slave/runtests-default/build/dlls/winecrt0/exe_entry.c:36] in ddrawex_test (0x0032fe60) > 7 0x7b85fe84 call_process_entry+0xb() in kernel32 (0x0032fe78) > 8 0x7b85ffca start_process+0x143(peb=0x7ffdf000) [/home/bob/wineslave.dir/sandbox/slave/runtests-default/build/dlls/kernel32/process.c:1091] in kernel32 (0x0032fec8) > 9 0x7bc7c104 call_thread_func+0xb() in ntdll (0x0032fed8) > 10 0x7bc7c142 call_thread_entry_point+0x33(entry=0x7b85fe86, arg=0x7ffdf000) [/home/bob/wineslave.dir/sandbox/slave/runtests-default/build/dlls/ntdll/signal_i386.c:2499] in ntdll (0x0032ffb8) > 11 0x7bc53699 start_process+0x23(kernel_start=0x7b85fe86) [/home/bob/wineslave.dir/sandbox/slave/runtests-default/build/dlls/ntdll/loader.c:2612] in ntdll (0x0032ffe8) > 12 0x680280b9 wine_call_on_stack+0x1c() in libwine.so.1 (0x00000000) > 0x684b5510 dctest_surf+0x69 [/home/bob/wineslave.dir/sandbox/slave/runtests-default/build/dlls/ddrawex/tests/surface.c:54] in ddrawex_test: movl 0x0(%eax),%eax > 54 hr = IDirectDrawSurface_GetDC(surf, &dc); > Modules: > Module Address Debug info Name (38 modules) > ELF 40000000-40029000 Deferred ddrawex<elf> > \-PE 40010000-40029000 \ ddrawex > ELF 40029000-40096000 Deferred ddraw<elf> > \-PE 40030000-40096000 \ ddraw > ELF 40096000-40201000 Deferred wined3d<elf> > \-PE 400a0000-40201000 \ wined3d > ELF 40201000-40355000 Deferred user32<elf> > \-PE 40210000-40355000 \ user32 > ELF 40355000-40370000 Deferred version<elf> > \-PE 40360000-40370000 \ version > ELF 4045f000-4046f000 Deferred libxext.so.6 > ELF 4046f000-4058c000 Deferred libx11.so.6 > ELF 40591000-405ab000 Deferred libxcb.so.1 > ELF 405ab000-405af000 Deferred libxau.so.6 > ELF 405af000-405b5000 Deferred libxdmcp.so.6 > ELF 68000000-6801d000 Deferred ld-linux.so.2 > ELF 6801f000-68160000 Dwarf libwine.so.1 > ELF 68172000-6818b000 Deferred libpthread.so.0 > ELF 6818b000-682e5000 Deferred libc.so.6 > ELF 682e6000-682ea000 Deferred libdl.so.2 > ELF 682eb000-68311000 Deferred libm.so.6 > ELF 68311000-68319000 Deferred libnss_compat.so.2 > ELF 68319000-68330000 Deferred libnsl.so.1 > ELF 68330000-6833a000 Deferred libnss_nis.so.2 > ELF 6833a000-68346000 Deferred libnss_files.so.2 > ELF 684a3000-684bd000 Dwarf ddrawex_test<elf> > \-PE 684b0000-684bd000 \ ddrawex_test > ELF 684bd000-68579000 Deferred gdi32<elf> > \-PE 684d0000-68579000 \ gdi32 > ELF 68579000-685df000 Deferred advapi32<elf> > \-PE 68590000-685df000 \ advapi32 > ELF 685f1000-68667000 Deferred libfreetype.so.6 > ELF 68667000-6867c000 Deferred libz.so.1 > ELF 7b800000-7b9b1000 Dwarf kernel32<elf> > \-PE 7b810000-7b9b1000 \ kernel32 > ELF 7bc00000-7bccd000 Dwarf ntdll<elf> > \-PE 7bc10000-7bccd000 \ ntdll > ELF 7bf00000-7bf04000 Deferred <wine-loader> > Threads: > process tid prio (all id:s are in hex) > 0000000e services.exe > 0000001f 0 > 0000001e 0 > 00000015 0 > 00000010 0 > 0000000f 0 > 00000012 winedevice.exe > 0000001a 0 > 00000019 0 > 00000014 0 > 00000013 0 > 0000001b plugplay.exe > 00000020 0 > 0000001d 0 > 0000001c 0 > 0000003d explorer.exe > 0000003e 0 > 0000003c (D) Z:\home\bob\wineslave.dir\sandbox\slave\runtests-default\build\dlls\ddrawex\tests\ddrawex_test.exe > 0000003b 0 <== > Backtrace: > =>0 0x684b5510 dctest_surf+0x69(surf=(nil), ddsdver=0x1) [/home/bob/wineslave.dir/sandbox/slave/runtests-default/build/dlls/ddrawex/tests/surface.c:54] in ddrawex_test (0x0032fb68) > 1 0x684b57ef GetDCTest_main+0xc3(ddsd=0x32fc54, ddsd2=0x32fbd8, testfunc=0x684b54a7) [/home/bob/wineslave.dir/sandbox/slave/runtests-default/build/dlls/ddrawex/tests/surface.c:88] in ddrawex_test (0x0032fbb8) > 2 0x684b5ce4 GetDCTest+0xc1() [/home/bob/wineslave.dir/sandbox/slave/runtests-default/build/dlls/ddrawex/tests/surface.c:153] in ddrawex_test (0x0032fcc8) > 3 0x684b732c func_surface+0x1e0() [/home/bob/wineslave.dir/sandbox/slave/runtests-default/build/dlls/ddrawex/tests/surface.c:436] in ddrawex_test (0x0032fcf8) > 4 0x684b8073 run_test+0x9e(name="surface.c") [/home/bob/wineslave.dir/sandbox/slave/runtests-default/build/dlls/ddrawex/tests/../../../include/wine/test.h:556] in ddrawex_test (0x0032fd58) > 5 0x684b8488 main+0x23a(argc=<couldn't compute location>, argv=0x1103d0) [/home/bob/wineslave.dir/sandbox/slave/runtests-default/build/dlls/ddrawex/tests/../../../include/wine/test.h:624] in ddrawex_test (0x0032fe28) > 6 0x684b8516 __wine_spec_exe_entry+0x69(peb=0x7ffdf000) [/home/bob/wineslave.dir/sandbox/slave/runtests-default/build/dlls/winecrt0/exe_entry.c:36] in ddrawex_test (0x0032fe60) > 7 0x7b85fe84 call_process_entry+0xb() in kernel32 (0x0032fe78) > 8 0x7b85ffca start_process+0x143(peb=0x7ffdf000) [/home/bob/wineslave.dir/sandbox/slave/runtests-default/build/dlls/kernel32/process.c:1091] in kernel32 (0x0032fec8) > 9 0x7bc7c104 call_thread_func+0xb() in ntdll (0x0032fed8) > 10 0x7bc7c142 call_thread_entry_point+0x33(entry=0x7b85fe86, arg=0x7ffdf000) [/home/bob/wineslave.dir/sandbox/slave/runtests-default/build/dlls/ntdll/signal_i386.c:2499] in ntdll (0x0032ffb8) > 11 0x7bc53699 start_process+0x23(kernel_start=0x7b85fe86) [/home/bob/wineslave.dir/sandbox/slave/runtests-default/build/dlls/ntdll/loader.c:2612] in ntdll (0x0032ffe8) > 12 0x680280b9 wine_call_on_stack+0x1c() in libwine.so.1 (0x00000000) > make: *** [surface.ok] Error 5 > alarum: failed command was ../../../wine dinput_test.exe.so device.c > Application tried to create a window, but no driver could be loaded. > Make sure that your X server is running and that $DISPLAY is set correctly. > device.c:195: Test failed: err: 2 > make: *** [device.ok] Error 1 > alarum: failed command was ../../../wine dinput_test.exe.so keyboard.c > Application tried to create a window, but no driver could be loaded. > Make sure that your X server is running and that $DISPLAY is set correctly. > keyboard.c:174: Test failed: err: 2 > make: *** [keyboard.ok] Error 1 > alarum: failed command was ../../../wine dinput_test.exe.so mouse.c > Application tried to create a window, but no driver could be loaded. > Make sure that your X server is running and that $DISPLAY is set correctly. > mouse.c:140: Test failed: err: 2 > make: *** [mouse.ok] Error 1 > alarum: failed command was ../../../wine dinput8_test.exe.so device.c > fixme:dinput:IDirectInput8AImpl_EnumDevicesBySemantics (this=0x1251e8,(null),0x32fb84,0x684b59f4,0x32fb50,0000): semi-stub > fixme:dinput:_dump_diactionformatA diaf.dwSize = 328 > fixme:dinput:_dump_diactionformatA diaf.dwActionSize = 40 > fixme:dinput:_dump_diactionformatA diaf.dwDataSize = 20 > fixme:dinput:_dump_diactionformatA diaf.dwNumActions = 5 > fixme:dinput:_dump_diactionformatA diaf.rgoAction = 0x684bd400 > fixme:dinput:_dump_diactionformatA diaf.guidActionMap = {00000001-0002-0003-0405-060708090a0b} > fixme:dinput:_dump_diactionformatA diaf.dwGenre = 0x01000000 > fixme:dinput:_dump_diactionformatA diaf.dwBufferSize = 32 > fixme:dinput:_dump_diactionformatA diaf.lAxisMin = 0 > fixme:dinput:_dump_diactionformatA diaf.lAxisMax = 0 > fixme:dinput:_dump_diactionformatA diaf.hInstString = (nil) > fixme:dinput:_dump_diactionformatA diaf.ftTimeStamp ... > fixme:dinput:_dump_diactionformatA diaf.dwCRC = 0x0 > fixme:dinput:_dump_diactionformatA diaf.tszActionMap = "" > fixme:dinput:_dump_diactionformatA diaf.rgoAction[0]: > fixme:dinput:_dump_diactionformatA uAppData=0x0 > fixme:dinput:_dump_diactionformatA dwSemantic=0x01008a01 > fixme:dinput:_dump_diactionformatA dwFlags=0x0 > fixme:dinput:_dump_diactionformatA szActionName="Steer" > fixme:dinput:_dump_diactionformatA guidInstance={00000000-0000-0000-0000-000000000000} > fixme:dinput:_dump_diactionformatA dwObjID=0x0 > fixme:dinput:_dump_diactionformatA dwHow=0x0 > fixme:dinput:_dump_diactionformatA diaf.rgoAction[1]: > fixme:dinput:_dump_diactionformatA uAppData=0x1 > fixme:dinput:_dump_diactionformatA dwSemantic=0x01000c01 > fixme:dinput:_dump_diactionformatA dwFlags=0x0 > fixme:dinput:_dump_diactionformatA szActionName="Upshift" > fixme:dinput:_dump_diactionformatA guidInstance={00000000-0000-0000-0000-000000000000} > fixme:dinput:_dump_diactionformatA dwObjID=0x0 > fixme:dinput:_dump_diactionformatA dwHow=0x0 > fixme:dinput:_dump_diactionformatA diaf.rgoAction[2]: > fixme:dinput:_dump_diactionformatA uAppData=0x2 > fixme:dinput:_dump_diactionformatA dwSemantic=0x81000439 > fixme:dinput:_dump_diactionformatA dwFlags=0x0 > fixme:dinput:_dump_diactionformatA szActionName="Missile" > fixme:dinput:_dump_diactionformatA guidInstance={00000000-0000-0000-0000-000000000000} > fixme:dinput:_dump_diactionformatA dwObjID=0x0 > fixme:dinput:_dump_diactionformatA dwHow=0x0 > fixme:dinput:_dump_diactionformatA diaf.rgoAction[3]: > fixme:dinput:_dump_diactionformatA uAppData=0x3 > fixme:dinput:_dump_diactionformatA dwSemantic=0x8200040c > fixme:dinput:_dump_diactionformatA dwFlags=0x0 > fixme:dinput:_dump_diactionformatA szActionName="Select" > fixme:dinput:_dump_diactionformatA guidInstance={00000000-0000-0000-0000-000000000000} > fixme:dinput:_dump_diactionformatA dwObjID=0x0 > fixme:dinput:_dump_diactionformatA dwHow=0x0 > fixme:dinput:_dump_diactionformatA diaf.rgoAction[4]: > fixme:dinput:_dump_diactionformatA uAppData=0x4 > fixme:dinput:_dump_diactionformatA dwSemantic=0x82000304 > fixme:dinput:_dump_diactionformatA dwFlags=0x0 > fixme:dinput:_dump_diactionformatA szActionName="Y Axis" > fixme:dinput:_dump_diactionformatA guidInstance={00000000-0000-0000-0000-000000000000} > fixme:dinput:_dump_diactionformatA dwObjID=0x0 > fixme:dinput:_dump_diactionformatA dwHow=0x0 > fixme:dinput:IDirectInput8AImpl_EnumDevicesBySemantics (this=0x1251e8,(null),0x32fb84,0x684b59f4,0x32fb50,0100): semi-stub > fixme:dinput:IDirectInput8AImpl_EnumDevicesBySemantics dwFlags |= DIEDBSFL_FORCEFEEDBACK > fixme:dinput:_dump_diactionformatA diaf.dwSize = 328 > fixme:dinput:_dump_diactionformatA diaf.dwActionSize = 40 > fixme:dinput:_dump_diactionformatA diaf.dwDataSize = 20 > fixme:dinput:_dump_diactionformatA diaf.dwNumActions = 5 > fixme:dinput:_dump_diactionformatA diaf.rgoAction = 0x684bd400 > fixme:dinput:_dump_diactionformatA diaf.guidActionMap = {00000001-0002-0003-0405-060708090a0b} > fixme:dinput:_dump_diactionformatA diaf.dwGenre = 0x01000000 > fixme:dinput:_dump_diactionformatA diaf.dwBufferSize = 32 > fixme:dinput:_dump_diactionformatA diaf.lAxisMin = 0 > fixme:dinput:_dump_diactionformatA diaf.lAxisMax = 0 > fixme:dinput:_dump_diactionformatA diaf.hInstString = (nil) > fixme:dinput:_dump_diactionformatA diaf.ftTimeStamp ... > fixme:dinput:_dump_diactionformatA diaf.dwCRC = 0x0 > fixme:dinput:_dump_diactionformatA diaf.tszActionMap = "" > fixme:dinput:_dump_diactionformatA diaf.rgoAction[0]: > fixme:dinput:_dump_diactionformatA uAppData=0x0 > fixme:dinput:_dump_diactionformatA dwSemantic=0x01008a01 > fixme:dinput:_dump_diactionformatA dwFlags=0x0 > fixme:dinput:_dump_diactionformatA szActionName="Steer" > fixme:dinput:_dump_diactionformatA guidInstance={00000000-0000-0000-0000-000000000000} > fixme:dinput:_dump_diactionformatA dwObjID=0x0 > fixme:dinput:_dump_diactionformatA dwHow=0x0 > fixme:dinput:_dump_diactionformatA diaf.rgoAction[1]: > fixme:dinput:_dump_diactionformatA uAppData=0x1 > fixme:dinput:_dump_diactionformatA dwSemantic=0x01000c01 > fixme:dinput:_dump_diactionformatA dwFlags=0x0 > fixme:dinput:_dump_diactionformatA szActionName="Upshift" > fixme:dinput:_dump_diactionformatA guidInstance={00000000-0000-0000-0000-000000000000} > fixme:dinput:_dump_diactionformatA dwObjID=0x0 > fixme:dinput:_dump_diactionformatA dwHow=0x0 > fixme:dinput:_dump_diactionformatA diaf.rgoAction[2]: > fixme:dinput:_dump_diactionformatA uAppData=0x2 > fixme:dinput:_dump_diactionformatA dwSemantic=0x81000439 > fixme:dinput:_dump_diactionformatA dwFlags=0x0 > fixme:dinput:_dump_diactionformatA szActionName="Missile" > fixme:dinput:_dump_diactionformatA guidInstance={00000000-0000-0000-0000-000000000000} > fixme:dinput:_dump_diactionformatA dwObjID=0x0 > fixme:dinput:_dump_diactionformatA dwHow=0x0 > fixme:dinput:_dump_diactionformatA diaf.rgoAction[3]: > fixme:dinput:_dump_diactionformatA uAppData=0x3 > fixme:dinput:_dump_diactionformatA dwSemantic=0x8200040c > fixme:dinput:_dump_diactionformatA dwFlags=0x0 > fixme:dinput:_dump_diactionformatA szActionName="Select" > fixme:dinput:_dump_diactionformatA guidInstance={00000000-0000-0000-0000-000000000000} > fixme:dinput:_dump_diactionformatA dwObjID=0x0 > fixme:dinput:_dump_diactionformatA dwHow=0x0 > fixme:dinput:_dump_diactionformatA diaf.rgoAction[4]: > fixme:dinput:_dump_diactionformatA uAppData=0x4 > fixme:dinput:_dump_diactionformatA dwSemantic=0x82000304 > fixme:dinput:_dump_diactionformatA dwFlags=0x0 > fixme:dinput:_dump_diactionformatA szActionName="Y Axis" > fixme:dinput:_dump_diactionformatA guidInstance={00000000-0000-0000-0000-000000000000} > fixme:dinput:_dump_diactionformatA dwObjID=0x0 > fixme:dinput:_dump_diactionformatA dwHow=0x0 > fixme:dinput:IDirectInput8AImpl_EnumDevicesBySemantics (this=0x1251e8,(null),0x32fb84,0x684b59f4,0x32fb50,1000): semi-stub > fixme:dinput:IDirectInput8AImpl_EnumDevicesBySemantics dwFlags |= DIEDBSFL_AVAILABLEDEVICES > fixme:dinput:_dump_diactionformatA diaf.dwSize = 328 > fixme:dinput:_dump_diactionformatA diaf.dwActionSize = 40 > fixme:dinput:_dump_diactionformatA diaf.dwDataSize = 20 > fixme:dinput:_dump_diactionformatA diaf.dwNumActions = 5 > fixme:dinput:_dump_diactionformatA diaf.rgoAction = 0x684bd400 > fixme:dinput:_dump_diactionformatA diaf.guidActionMap = {00000001-0002-0003-0405-060708090a0b} > fixme:dinput:_dump_diactionformatA diaf.dwGenre = 0x01000000 > fixme:dinput:_dump_diactionformatA diaf.dwBufferSize = 32 > fixme:dinput:_dump_diactionformatA diaf.lAxisMin = 0 > fixme:dinput:_dump_diactionformatA diaf.lAxisMax = 0 > fixme:dinput:_dump_diactionformatA diaf.hInstString = (nil) > fixme:dinput:_dump_diactionformatA diaf.ftTimeStamp ... > fixme:dinput:_dump_diactionformatA diaf.dwCRC = 0x0 > fixme:dinput:_dump_diactionformatA diaf.tszActionMap = "" > fixme:dinput:_dump_diactionformatA diaf.rgoAction[0]: > fixme:dinput:_dump_diactionformatA uAppData=0x0 > fixme:dinput:_dump_diactionformatA dwSemantic=0x01008a01 > fixme:dinput:_dump_diactionformatA dwFlags=0x0 > fixme:dinput:_dump_diactionformatA szActionName="Steer" > fixme:dinput:_dump_diactionformatA guidInstance={00000000-0000-0000-0000-000000000000} > fixme:dinput:_dump_diactionformatA dwObjID=0x0 > fixme:dinput:_dump_diactionformatA dwHow=0x0 > fixme:dinput:_dump_diactionformatA diaf.rgoAction[1]: > fixme:dinput:_dump_diactionformatA uAppData=0x1 > fixme:dinput:_dump_diactionformatA dwSemantic=0x01000c01 > fixme:dinput:_dump_diactionformatA dwFlags=0x0 > fixme:dinput:_dump_diactionformatA szActionName="Upshift" > fixme:dinput:_dump_diactionformatA guidInstance={00000000-0000-0000-0000-000000000000} > fixme:dinput:_dump_diactionformatA dwObjID=0x0 > fixme:dinput:_dump_diactionformatA dwHow=0x0 > fixme:dinput:_dump_diactionformatA diaf.rgoAction[2]: > fixme:dinput:_dump_diactionformatA uAppData=0x2 > fixme:dinput:_dump_diactionformatA dwSemantic=0x81000439 > fixme:dinput:_dump_diactionformatA dwFlags=0x0 > fixme:dinput:_dump_diactionformatA szActionName="Missile" > fixme:dinput:_dump_diactionformatA guidInstance={00000000-0000-0000-0000-000000000000} > fixme:dinput:_dump_diactionformatA dwObjID=0x0 > fixme:dinput:_dump_diactionformatA dwHow=0x0 > fixme:dinput:_dump_diactionformatA diaf.rgoAction[3]: > fixme:dinput:_dump_diactionformatA uAppData=0x3 > fixme:dinput:_dump_diactionformatA dwSemantic=0x8200040c > fixme:dinput:_dump_diactionformatA dwFlags=0x0 > fixme:dinput:_dump_diactionformatA szActionName="Select" > fixme:dinput:_dump_diactionformatA guidInstance={00000000-0000-0000-0000-000000000000} > fixme:dinput:_dump_diactionformatA dwObjID=0x0 > fixme:dinput:_dump_diactionformatA dwHow=0x0 > fixme:dinput:_dump_diactionformatA diaf.rgoAction[4]: > fixme:dinput:_dump_diactionformatA uAppData=0x4 > fixme:dinput:_dump_diactionformatA dwSemantic=0x82000304 > fixme:dinput:_dump_diactionformatA dwFlags=0x0 > fixme:dinput:_dump_diactionformatA szActionName="Y Axis" > fixme:dinput:_dump_diactionformatA guidInstance={00000000-0000-0000-0000-000000000000} > fixme:dinput:_dump_diactionformatA dwObjID=0x0 > fixme:dinput:_dump_diactionformatA dwHow=0x0 > fixme:dinput:IDirectInput8AImpl_EnumDevicesBySemantics (this=0x1251e8,(null),0x32fb84,0x684b54fe,0x32fb64,0000): semi-stub > fixme:dinput:_dump_diactionformatA diaf.dwSize = 328 > fixme:dinput:_dump_diactionformatA diaf.dwActionSize = 40 > fixme:dinput:_dump_diactionformatA diaf.dwDataSize = 20 > fixme:dinput:_dump_diactionformatA diaf.dwNumActions = 5 > fixme:dinput:_dump_diactionformatA diaf.rgoAction = 0x684bd400 > fixme:dinput:_dump_diactionformatA diaf.guidActionMap = {00000001-0002-0003-0405-060708090a0b} > fixme:dinput:_dump_diactionformatA diaf.dwGenre = 0x01000000 > fixme:dinput:_dump_diactionformatA diaf.dwBufferSize = 32 > fixme:dinput:_dump_diactionformatA diaf.lAxisMin = 0 > fixme:dinput:_dump_diactionformatA diaf.lAxisMax = 0 > fixme:dinput:_dump_diactionformatA diaf.hInstString = (nil) > fixme:dinput:_dump_diactionformatA diaf.ftTimeStamp ... > fixme:dinput:_dump_diactionformatA diaf.dwCRC = 0x0 > fixme:dinput:_dump_diactionformatA diaf.tszActionMap = "" > fixme:dinput:_dump_diactionformatA diaf.rgoAction[0]: > fixme:dinput:_dump_diactionformatA uAppData=0x0 > fixme:dinput:_dump_diactionformatA dwSemantic=0x01008a01 > fixme:dinput:_dump_diactionformatA dwFlags=0x0 > fixme:dinput:_dump_diactionformatA szActionName="Steer" > fixme:dinput:_dump_diactionformatA guidInstance={00000000-0000-0000-0000-000000000000} > fixme:dinput:_dump_diactionformatA dwObjID=0x0 > fixme:dinput:_dump_diactionformatA dwHow=0x0 > fixme:dinput:_dump_diactionformatA diaf.rgoAction[1]: > fixme:dinput:_dump_diactionformatA uAppData=0x1 > fixme:dinput:_dump_diactionformatA dwSemantic=0x01000c01 > fixme:dinput:_dump_diactionformatA dwFlags=0x0 > fixme:dinput:_dump_diactionformatA szActionName="Upshift" > fixme:dinput:_dump_diactionformatA guidInstance={00000000-0000-0000-0000-000000000000} > fixme:dinput:_dump_diactionformatA dwObjID=0x0 > fixme:dinput:_dump_diactionformatA dwHow=0x0 > fixme:dinput:_dump_diactionformatA diaf.rgoAction[2]: > fixme:dinput:_dump_diactionformatA uAppData=0x2 > fixme:dinput:_dump_diactionformatA dwSemantic=0x81000439 > fixme:dinput:_dump_diactionformatA dwFlags=0x0 > fixme:dinput:_dump_diactionformatA szActionName="Missile" > fixme:dinput:_dump_diactionformatA guidInstance={00000000-0000-0000-0000-000000000000} > fixme:dinput:_dump_diactionformatA dwObjID=0x0 > fixme:dinput:_dump_diactionformatA dwHow=0x0 > fixme:dinput:_dump_diactionformatA diaf.rgoAction[3]: > fixme:dinput:_dump_diactionformatA uAppData=0x3 > fixme:dinput:_dump_diactionformatA dwSemantic=0x8200040c > fixme:dinput:_dump_diactionformatA dwFlags=0x0 > fixme:dinput:_dump_diactionformatA szActionName="Select" > fixme:dinput:_dump_diactionformatA guidInstance={00000000-0000-0000-0000-000000000000} > fixme:dinput:_dump_diactionformatA dwObjID=0x0 > fixme:dinput:_dump_diactionformatA dwHow=0x0 > fixme:dinput:_dump_diactionformatA diaf.rgoAction[4]: > fixme:dinput:_dump_diactionformatA uAppData=0x4 > fixme:dinput:_dump_diactionformatA dwSemantic=0x82000304 > fixme:dinput:_dump_diactionformatA dwFlags=0x0 > fixme:dinput:_dump_diactionformatA szActionName="Y Axis" > fixme:dinput:_dump_diactionformatA guidInstance={00000000-0000-0000-0000-000000000000} > fixme:dinput:_dump_diactionformatA dwObjID=0x0 > fixme:dinput:_dump_diactionformatA dwHow=0x0 > fixme:dinput:SysKeyboardWImpl_BuildActionMap (0x12b81c)->(0x32f570,(null),00000002): semi-stub ! > fixme:dinput:SysKeyboardWImpl_SetActionMap (0x12b81c)->(0x32f570,(null),00000000): semi-stub ! > fixme:dinput:SysMouseWImpl_BuildActionMap (0x12c9fc)->(0x32f570,(null),00000002): semi-stub ! > fixme:dinput:IDirectInputDevice8WImpl_BuildActionMap (0x12c9fc)->(0x32f570,(null),00000002): semi-stub ! > fixme:dinput:IDirectInputDevice8WImpl_BuildActionMap dwFlags =|DIDBAM_INITIALIZE > fixme:dinput:SysMouseWImpl_SetActionMap (0x12c9fc)->(0x32f570,(null),00000000): semi-stub ! > fixme:dinput:IDirectInputDevice8WImpl_SetActionMap (0x12c9fc)->(0x32f570,(null),00000000): semi-stub ! > fixme:dinput:SysMouseWImpl_SetActionMap (0x12c9fc)->(0x32f570,(null),00000000): semi-stub ! > fixme:dinput:IDirectInput8AImpl_EnumDevicesBySemantics (this=0x1251e8,(null),0x32fb84,0x684b59f4,0x32fb50,1000): semi-stub > fixme:dinput:IDirectInput8AImpl_EnumDevicesBySemantics dwFlags |= DIEDBSFL_AVAILABLEDEVICES > fixme:dinput:_dump_diactionformatA diaf.dwSize = 328 > fixme:dinput:_dump_diactionformatA diaf.dwActionSize = 40 > fixme:dinput:_dump_diactionformatA diaf.dwDataSize = 20 > fixme:dinput:_dump_diactionformatA diaf.dwNumActions = 5 > fixme:dinput:_dump_diactionformatA diaf.rgoAction = 0x684bd400 > fixme:dinput:_dump_diactionformatA diaf.guidActionMap = {00000001-0002-0003-0405-060708090a0b} > fixme:dinput:_dump_diactionformatA diaf.dwGenre = 0x01000000 > fixme:dinput:_dump_diactionformatA diaf.dwBufferSize = 32 > fixme:dinput:_dump_diactionformatA diaf.lAxisMin = 0 > fixme:dinput:_dump_diactionformatA diaf.lAxisMax = 0 > fixme:dinput:_dump_diactionformatA diaf.hInstString = (nil) > fixme:dinput:_dump_diactionformatA diaf.ftTimeStamp ... > fixme:dinput:_dump_diactionformatA diaf.dwCRC = 0x0 > fixme:dinput:_dump_diactionformatA diaf.tszActionMap = "" > fixme:dinput:_dump_diactionformatA diaf.rgoAction[0]: > fixme:dinput:_dump_diactionformatA uAppData=0x0 > fixme:dinput:_dump_diactionformatA dwSemantic=0x01008a01 > fixme:dinput:_dump_diactionformatA dwFlags=0x0 > fixme:dinput:_dump_diactionformatA szActionName="Steer" > fixme:dinput:_dump_diactionformatA guidInstance={00000000-0000-0000-0000-000000000000} > fixme:dinput:_dump_diactionformatA dwObjID=0x0 > fixme:dinput:_dump_diactionformatA dwHow=0x0 > fixme:dinput:_dump_diactionformatA diaf.rgoAction[1]: > fixme:dinput:_dump_diactionformatA uAppData=0x1 > fixme:dinput:_dump_diactionformatA dwSemantic=0x01000c01 > fixme:dinput:_dump_diactionformatA dwFlags=0x0 > fixme:dinput:_dump_diactionformatA szActionName="Upshift" > fixme:dinput:_dump_diactionformatA guidInstance={00000000-0000-0000-0000-000000000000} > fixme:dinput:_dump_diactionformatA dwObjID=0x0 > fixme:dinput:_dump_diactionformatA dwHow=0x0 > fixme:dinput:_dump_diactionformatA diaf.rgoAction[2]: > fixme:dinput:_dump_diactionformatA uAppData=0x2 > fixme:dinput:_dump_diactionformatA dwSemantic=0x81000439 > fixme:dinput:_dump_diactionformatA dwFlags=0x0 > fixme:dinput:_dump_diactionformatA szActionName="Missile" > fixme:dinput:_dump_diactionformatA guidInstance={00000000-0000-0000-0000-000000000000} > fixme:dinput:_dump_diactionformatA dwObjID=0x0 > fixme:dinput:_dump_diactionformatA dwHow=0x0 > fixme:dinput:_dump_diactionformatA diaf.rgoAction[3]: > fixme:dinput:_dump_diactionformatA uAppData=0x3 > fixme:dinput:_dump_diactionformatA dwSemantic=0x8200040c > fixme:dinput:_dump_diactionformatA dwFlags=0x0 > fixme:dinput:_dump_diactionformatA szActionName="Select" > fixme:dinput:_dump_diactionformatA guidInstance={6f1d2b60-d5a0-11cf-bfc7-444553540000} > fixme:dinput:_dump_diactionformatA dwObjID=0x304 > fixme:dinput:_dump_diactionformatA dwHow=0x20 > fixme:dinput:_dump_diactionformatA diaf.rgoAction[4]: > fixme:dinput:_dump_diactionformatA uAppData=0x4 > fixme:dinput:_dump_diactionformatA dwSemantic=0x82000304 > fixme:dinput:_dump_diactionformatA dwFlags=0x0 > fixme:dinput:_dump_diactionformatA szActionName="Y Axis" > fixme:dinput:_dump_diactionformatA guidInstance={6f1d2b60-d5a0-11cf-bfc7-444553540000} > fixme:dinput:_dump_diactionformatA dwObjID=0x101 > fixme:dinput:_dump_diactionformatA dwHow=0x20 > fixme:dinput:SysKeyboardWImpl_BuildActionMap (0x12b81c)->(0x32f630,(null),00000002): semi-stub ! > device.c:120: Test failed: Action was not set dwHow=00000000 > device.c:121: Test failed: Action not mapped correctly instance=00000000 expected=00000039 > device.c:122: Test failed: Action type not mapped correctly type=00000000 expected=00000004 > device.c:123: Test failed: Action and device GUID do not match action=2 > device.c:74: Test failed: Failed to acquire device hr=80070057 > device.c:91: Test failed: Retrieval of action failed uAppData=0 expected=2 > fixme:dinput:SysKeyboardWImpl_BuildActionMap (0x12b81c)->(0x32f8d0,(null),00000002): semi-stub ! > fixme:dinput:SysKeyboardWImpl_SetActionMap (0x12b81c)->(0x32f8d0,(null),00000000): semi-stub ! > fixme:dinput:SysMouseWImpl_BuildActionMap (0x12c9fc)->(0x32f630,(null),00000002): semi-stub ! > fixme:dinput:IDirectInputDevice8WImpl_BuildActionMap (0x12c9fc)->(0x32f630,(null),00000002): semi-stub ! > fixme:dinput:IDirectInputDevice8WImpl_BuildActionMap dwFlags =|DIDBAM_INITIALIZE > fixme:dinput:SysMouseWImpl_BuildActionMap (0x12c9fc)->(0x32f630,(null),00000002): semi-stub ! > fixme:dinput:IDirectInputDevice8WImpl_BuildActionMap (0x12c9fc)->(0x32f630,(null),00000002): semi-stub ! > fixme:dinput:IDirectInputDevice8WImpl_BuildActionMap dwFlags =|DIDBAM_INITIALIZE > fixme:dinput:IDirectInput8AImpl_EnumDevicesBySemantics (this=0x1251e8,(null),0x32fb84,0x684b54fe,(nil),0000): semi-stub > fixme:dinput:_dump_diactionformatA diaf.dwSize = 328 > fixme:dinput:_dump_diactionformatA diaf.dwActionSize = 40 > fixme:dinput:_dump_diactionformatA diaf.dwDataSize = 20 > fixme:dinput:_dump_diactionformatA diaf.dwNumActions = 5 > fixme:dinput:_dump_diactionformatA diaf.rgoAction = 0x684bd400 > fixme:dinput:_dump_diactionformatA diaf.guidActionMap = {00000000-0000-0000-0000-000000000000} > fixme:dinput:_dump_diactionformatA diaf.dwGenre = 0x01000000 > fixme:dinput:_dump_diactionformatA diaf.dwBufferSize = 32 > fixme:dinput:_dump_diactionformatA diaf.lAxisMin = 0 > fixme:dinput:_dump_diactionformatA diaf.lAxisMax = 0 > fixme:dinput:_dump_diactionformatA diaf.hInstString = (nil) > fixme:dinput:_dump_diactionformatA diaf.ftTimeStamp ... > fixme:dinput:_dump_diactionformatA diaf.dwCRC = 0x0 > fixme:dinput:_dump_diactionformatA diaf.tszActionMap = "" > fixme:dinput:_dump_diactionformatA diaf.rgoAction[0]: > fixme:dinput:_dump_diactionformatA uAppData=0x0 > fixme:dinput:_dump_diactionformatA dwSemantic=0x01008a01 > fixme:dinput:_dump_diactionformatA dwFlags=0x0 > fixme:dinput:_dump_diactionformatA szActionName="Steer" > fixme:dinput:_dump_diactionformatA guidInstance={00000000-0000-0000-0000-000000000000} > fixme:dinput:_dump_diactionformatA dwObjID=0x0 > fixme:dinput:_dump_diactionformatA dwHow=0x0 > fixme:dinput:_dump_diactionformatA diaf.rgoAction[1]: > fixme:dinput:_dump_diactionformatA uAppData=0x1 > fixme:dinput:_dump_diactionformatA dwSemantic=0x01000c01 > fixme:dinput:_dump_diactionformatA dwFlags=0x0 > fixme:dinput:_dump_diactionformatA szActionName="Upshift" > fixme:dinput:_dump_diactionformatA guidInstance={00000000-0000-0000-0000-000000000000} > fixme:dinput:_dump_diactionformatA dwObjID=0x0 > fixme:dinput:_dump_diactionformatA dwHow=0x0 > fixme:dinput:_dump_diactionformatA diaf.rgoAction[2]: > fixme:dinput:_dump_diactionformatA uAppData=0x2 > fixme:dinput:_dump_diactionformatA dwSemantic=0x81000439 > fixme:dinput:_dump_diactionformatA dwFlags=0x0 > fixme:dinput:_dump_diactionformatA szActionName="Missile" > fixme:dinput:_dump_diactionformatA guidInstance={00000000-0000-0000-0000-000000000000} > fixme:dinput:_dump_diactionformatA dwObjID=0x0 > fixme:dinput:_dump_diactionformatA dwHow=0x0 > fixme:dinput:_dump_diactionformatA diaf.rgoAction[3]: > fixme:dinput:_dump_diactionformatA uAppData=0x3 > fixme:dinput:_dump_diactionformatA dwSemantic=0x8200040c > fixme:dinput:_dump_diactionformatA dwFlags=0x0 > fixme:dinput:_dump_diactionformatA szActionName="Select" > fixme:dinput:_dump_diactionformatA guidInstance={6f1d2b60-d5a0-11cf-bfc7-444553540000} > fixme:dinput:_dump_diactionformatA dwObjID=0x304 > fixme:dinput:_dump_diactionformatA dwHow=0x20 > fixme:dinput:_dump_diactionformatA diaf.rgoAction[4]: > fixme:dinput:_dump_diactionformatA uAppData=0x4 > fixme:dinput:_dump_diactionformatA dwSemantic=0x82000304 > fixme:dinput:_dump_diactionformatA dwFlags=0x0 > fixme:dinput:_dump_diactionformatA szActionName="Y Axis" > fixme:dinput:_dump_diactionformatA guidInstance={6f1d2b60-d5a0-11cf-bfc7-444553540000} > fixme:dinput:_dump_diactionformatA dwObjID=0x101 > fixme:dinput:_dump_diactionformatA dwHow=0x20 > make: *** [device.ok] Error 6 > alarum: failed command was ../../../wine dsound_test.exe.so capture.c > XOpenDisplay() failed > fixme:alsa:AudioClient_GetMixFormat Don't know what to do with 10000 channels, pretending there's only 2 channels > fixme:alsa:AudioClient_GetMixFormat Don't know what to do with 10000 channels, pretending there's only 2 channels > fixme:alsa:AudioClient_GetMixFormat Don't know what to do with 10000 channels, pretending there's only 2 channels > fixme:alsa:AudioClient_GetMixFormat Don't know what to do with 10000 channels, pretending there's only 2 channels > fixme:alsa:AudioClient_GetMixFormat Don't know what to do with 10000 channels, pretending there's only 2 channels > fixme:alsa:AudioClient_GetMixFormat Don't know what to do with 10000 channels, pretending there's only 2 channels > fixme:ole:CoCreateInstance no instance created for interface {11ab3ec0-25ec-11d1-a4d8-00c04fc28aca} of class {b0210780-89cd-11d0-af08-00a0c925cd16}, hres is 0x80004002 > ALSA lib pcm_direct.c:1117:(snd1_pcm_direct_initialize_poll_fd) unable to open timer 'hw:CLASS=3,SCLASS=0,CARD=0,DEV=0,SUBDEV=1' > ALSA lib pcm_dsnoop.c:662:(snd_pcm_dsnoop_open) unable to initialize poll_fd > capture.c:618: Test failed: Should not fail for 8 or 16 bits per sample > ALSA lib confmisc.c:768:(parse_card) cannot find card '0' > ALSA lib conf.c:4154:(_snd_config_evaluate) function snd_func_card_driver returned error: No such file or directory > ALSA lib confmisc.c:392:(snd_func_concat) error evaluating strings > ALSA lib conf.c:4154:(_snd_config_evaluate) function snd_func_concat returned error: No such file or directory > ALSA lib confmisc.c:1251:(snd_func_refer) error evaluating name > ALSA lib conf.c:4154:(_snd_config_evaluate) function snd_func_refer returned error: No such file or directory > ALSA lib conf.c:4633:(snd_config_expand) Evaluate error: No such file or directory > ALSA lib pcm.c:2211:(snd_pcm_open_noupdate) Unknown PCM default > ALSA lib confmisc.c:768:(parse_card) cannot find card '0' > ALSA lib conf.c:4154:(_snd_config_evaluate) function snd_func_card_driver returned error: No such file or directory > ALSA lib confmisc.c:392:(snd_func_concat) error evaluating strings > ALSA lib conf.c:4154:(_snd_config_evaluate) function snd_func_concat returned error: No such file or directory > ALSA lib confmisc.c:1251:(snd_func_refer) error evaluating name > ALSA lib conf.c:4154:(_snd_config_evaluate) function snd_func_refer returned error: No such file or directory > ALSA lib conf.c:4633:(snd_config_expand) Evaluate error: No such file or directory > ALSA lib pcm.c:2211:(snd_pcm_open_noupdate) Unknown PCM default > ALSA lib confmisc.c:768:(parse_card) cannot find card '0' > ALSA lib conf.c:4154:(_snd_config_evaluate) function snd_func_card_driver returned error: No such file or directory > ALSA lib confmisc.c:392:(snd_func_concat) error evaluating strings > ALSA lib conf.c:4154:(_snd_config_evaluate) function snd_func_concat returned error: No such file or directory > ALSA lib confmisc.c:1251:(snd_func_refer) error evaluating name > ALSA lib conf.c:4154:(_snd_config_evaluate) function snd_func_refer returned error: No such file or directory > ALSA lib conf.c:4633:(snd_config_expand) Evaluate error: No such file or directory > ALSA lib pcm.c:2211:(snd_pcm_open_noupdate) Unknown PCM default > ALSA lib confmisc.c:768:(parse_card) cannot find card '0' > ALSA lib conf.c:4154:(_snd_config_evaluate) function snd_func_card_driver returned error: No such file or directory > ALSA lib confmisc.c:392:(snd_func_concat) error evaluating strings > ALSA lib conf.c:4154:(_snd_config_evaluate) function snd_func_concat returned error: No such file or directory > ALSA lib confmisc.c:1251:(snd_func_refer) error evaluating name > ALSA lib conf.c:4154:(_snd_config_evaluate) function snd_func_refer returned error: No such file or directory > ALSA lib conf.c:4633:(snd_config_expand) Evaluate error: No such file or directory > ALSA lib pcm.c:2211:(snd_pcm_open_noupdate) Unknown PCM default > ALSA lib confmisc.c:768:(parse_card) cannot find card '0' > ALSA lib conf.c:4154:(_snd_config_evaluate) function snd_func_card_driver returned error: No such file or directory > ALSA lib confmisc.c:392:(snd_func_concat) error evaluating strings > ALSA lib conf.c:4154:(_snd_config_evaluate) function snd_func_concat returned error: No such file or directory > ALSA lib confmisc.c:1251:(snd_func_refer) error evaluating name > ALSA lib conf.c:4154:(_snd_config_evaluate) function snd_func_refer returned error: No such file or directory > ALSA lib conf.c:4633:(snd_config_expand) Evaluate error: No such file or directory > ALSA lib pcm.c:2211:(snd_pcm_open_noupdate) Unknown PCM default > ALSA lib pcm_hw.c:1401:(_snd_pcm_hw_open) Invalid value for card > make: *** [capture.ok] Error 1 > alarum: failed command was ../../../wine dsound_test.exe.so duplex.c > fixme:ole:CoCreateInstance no instance created for interface {11ab3ec0-25ec-11d1-a4d8-00c04fc28aca} of class {fea4300c-7959-4147-b26a-2377b9e7a91d}, hres is 0x80004002 > XOpenDisplay() failed > ALSA lib confmisc.c:768:(parse_card) cannot find card '0' > ALSA lib conf.c:4154:(_snd_config_evaluate) function snd_func_card_driver returned error: No such file or directory > ALSA lib confmisc.c:392:(snd_func_concat) error evaluating strings > ALSA lib conf.c:4154:(_snd_config_evaluate) function snd_func_concat returned error: No such file or directory > ALSA lib confmisc.c:1251:(snd_func_refer) error evaluating name > ALSA lib conf.c:4154:(_snd_config_evaluate) function snd_func_refer returned error: No such file or directory > ALSA lib conf.c:4633:(snd_config_expand) Evaluate error: No such file or directory > ALSA lib pcm.c:2211:(snd_pcm_open_noupdate) Unknown PCM default > ALSA lib confmisc.c:768:(parse_card) cannot find card '0' > ALSA lib conf.c:4154:(_snd_config_evaluate) function snd_func_card_driver returned error: No such file or directory > ALSA lib confmisc.c:392:(snd_func_concat) error evaluating strings > ALSA lib conf.c:4154:(_snd_config_evaluate) function snd_func_concat returned error: No such file or directory > ALSA lib confmisc.c:1251:(snd_func_refer) error evaluating name > ALSA lib conf.c:4154:(_snd_config_evaluate) function snd_func_refer returned error: No such file or directory > ALSA lib conf.c:4633:(snd_config_expand) Evaluate error: No such file or directory > ALSA lib pcm.c:2211:(snd_pcm_open_noupdate) Unknown PCM default > duplex.c:187: Test failed: DirectSoundFullDuplexCreate(NULL,NULL) failed: 80070057 > duplex.c:197: Test failed: DirectSoundFullDuplexCreate(DSDEVID_DefaultCapture,DSDEVID_DefaultPlayback) failed: 80070057 > duplex.c:208: Test failed: DirectSoundFullDuplexCreate(DSDEVID_DefaultVoiceCapture,DSDEVID_DefaultVoicePlayback) failed: 80070057 > make: *** [duplex.ok] Error 3 > ALSA lib conf.c:4154:(_snd_config_evaluate) function snd_func_card_driver returned error: No such file or directory > ALSA lib conf.c:4154:(_snd_config_evaluate) function snd_func_concat returned error: No such file or directory > ALSA lib conf.c:4154:(_snd_config_evaluate) function snd_func_refer returned error: No such file or directory > ALSA lib conf.c:4633:(snd_config_expand) Evaluate error: No such file or directory > ALSA lib conf.c:4154:(_snd_config_evaluate) function snd_func_card_driver returned error: No such file or directory > ALSA lib conf.c:4154:(_snd_config_evaluate) function snd_func_concat returned error: No such file or directory > ALSA lib conf.c:4154:(_snd_config_evaluate) function snd_func_refer returned error: No such file or directory > ALSA lib conf.c:4633:(snd_config_expand) Evaluate error: No such file or directory > alarum: failed command was ../../../wine gdi32_test.exe.so clipping.c > Application tried to create a window, but no driver could be loaded. > Make sure that your X server is running and that $DISPLAY is set correctly. > clipping.c:35: Test failed: CreateWindow failed > clipping.c:115: Test failed: GetRandomRgn 0,0 - 0,0 > clipping.c:435: Test failed: expected SIMPLEREGION, got 1 > clipping.c:441: Test failed: expected SIMPLEREGION, got 1 > clipping.c:442: Test failed: expected 0,0-640,480, got 0,0-0,0 > make: *** [clipping.ok] Error 5 > alarum: failed command was ../../../wine gdi32_test.exe.so dc.c > Application tried to create a window, but no driver could be loaded. > Make sure that your X server is running and that $DISPLAY is set correctly. > dc.c:66: test_savedc_2: Assertion `hwnd != 0' failed. > wine: Assertion failed at address 0x68000832 (thread 0032), starting debugger... > Unhandled exception: assertion failed in 32-bit code (0x68000832). > Register dump: > CS:0073 SS:007b DS:007b ES:007b FS:0033 GS:003b > EIP:68000832 ESP:0032fa8c EBP:0032fa98 EFLAGS:00200202( - -- I - - - ) > EAX:00000000 EBX:0000356b ECX:0000356b EDX:00000006 > ESI:682bc8df EDI:682e0ff4 > Stack dump: > 0x0032fa8c: 681b5651 682e0ff4 0032fbb8 0032fbc0 > 0x0032fa9c: 681b8a82 00000006 0032fb38 00000000 > 0x0032faac: 0032fae0 681fbf9d 00000068 00000040 > 0x0032fabc: 0032fbd0 0032fafc 00000068 00000040 > 0x0032facc: 00000037 7caf9570 682e0ff4 00000037 > 0x0032fadc: 00000036 0032fba8 681eb182 7caf9578 > Backtrace: > =>0 0x68000832 GLIBC_2+0x832() in ld-linux.so.2 (0x0032fa98) > 1 0x681b8a82 abort+0x181() in libc.so.6 (0x0032fbc0) > 2 0x681ae718 __assert_fail+0xf7() in libc.so.6 (0x0032fc08) > 3 0x684dfce4 test_savedc_2+0xb4() [/home/bob/wineslave.dir/sandbox/slave/runtests-default/build/dlls/gdi32/tests/dc.c:66] in gdi32_test (0x0032fcd8) > 4 0x684e4510 func_dc+0x47() [/home/bob/wineslave.dir/sandbox/slave/runtests-default/build/dlls/gdi32/tests/dc.c:790] in gdi32_test (0x0032fcf8) > 5 0x68520bd7 run_test+0x9e(name="dc.c") [/home/bob/wineslave.dir/sandbox/slave/runtests-default/build/dlls/gdi32/tests/../../../include/wine/test.h:556] in gdi32_test (0x0032fd58) > 6 0x68520fec main+0x23a(argc=<couldn't compute location>, argv=0x1103c8) [/home/bob/wineslave.dir/sandbox/slave/runtests-default/build/dlls/gdi32/tests/../../../include/wine/test.h:624] in gdi32_test (0x0032fe28) > 7 0x6852107a __wine_spec_exe_entry+0x69(peb=0x7ffdf000) [/home/bob/wineslave.dir/sandbox/slave/runtests-default/build/dlls/winecrt0/exe_entry.c:36] in gdi32_test (0x0032fe60) > 8 0x7b85fe84 call_process_entry+0xb() in kernel32 (0x0032fe78) > 9 0x7b85ffca start_process+0x143(peb=0x7ffdf000) [/home/bob/wineslave.dir/sandbox/slave/runtests-default/build/dlls/kernel32/process.c:1091] in kernel32 (0x0032fec8) > 10 0x7bc7c104 call_thread_func+0xb() in ntdll (0x0032fed8) > 11 0x7bc7c142 call_thread_entry_point+0x33(entry=0x7b85fe86, arg=0x7ffdf000) [/home/bob/wineslave.dir/sandbox/slave/runtests-default/build/dlls/ntdll/signal_i386.c:2499] in ntdll (0x0032ffb8) > 12 0x7bc53699 start_process+0x23(kernel_start=0x7b85fe86) [/home/bob/wineslave.dir/sandbox/slave/runtests-default/build/dlls/ntdll/loader.c:2612] in ntdll (0x0032ffe8) > 13 0x680280b9 wine_call_on_stack+0x1c() in libwine.so.1 (0x00000000) > 0x68000832 GLIBC_2+0x832 in ld-linux.so.2: ret > Modules: > Module Address Debug info Name (32 modules) > ELF 68000000-6801d000 Dwarf ld-linux.so.2 > ELF 6801f000-68160000 Dwarf libwine.so.1 > ELF 68172000-6818b000 Deferred libpthread.so.0 > ELF 6818b000-682e5000 Dwarf libc.so.6 > ELF 682e6000-682ea000 Deferred libdl.so.2 > ELF 682eb000-68311000 Deferred libm.so.6 > ELF 68311000-68319000 Deferred libnss_compat.so.2 > ELF 68319000-68330000 Deferred libnsl.so.1 > ELF 68330000-6833a000 Deferred libnss_nis.so.2 > ELF 6833a000-68346000 Deferred libnss_files.so.2 > ELF 684a3000-6853b000 Dwarf gdi32_test<elf> > \-PE 684b0000-6853b000 \ gdi32_test > ELF 6853b000-6868f000 Deferred user32<elf> > \-PE 68550000-6868f000 \ user32 > ELF 6868f000-6874b000 Deferred gdi32<elf> > \-PE 686a0000-6874b000 \ gdi32 > ELF 6874b000-687b1000 Deferred advapi32<elf> > \-PE 68760000-687b1000 \ advapi32 > ELF 687b1000-687cc000 Deferred version<elf> > \-PE 687c0000-687cc000 \ version > ELF 687de000-68854000 Deferred libfreetype.so.6 > ELF 68854000-68869000 Deferred libz.so.1 > ELF 68946000-68956000 Deferred libxext.so.6 > ELF 68956000-68a73000 Deferred libx11.so.6 > ELF 68a78000-68a92000 Deferred libxcb.so.1 > ELF 68a92000-68a96000 Deferred libxau.so.6 > ELF 68a96000-68a9c000 Deferred libxdmcp.so.6 > ELF 7b800000-7b9b1000 Dwarf kernel32<elf> > \-PE 7b810000-7b9b1000 \ kernel32 > ELF 7bc00000-7bccd000 Dwarf ntdll<elf> > \-PE 7bc10000-7bccd000 \ ntdll > ELF 7bf00000-7bf04000 Deferred <wine-loader> > Threads: > process tid prio (all id:s are in hex) > 0000000e services.exe > 0000001f 0 > 0000001e 0 > 00000015 0 > 00000010 0 > 0000000f 0 > 00000012 winedevice.exe > 0000001a 0 > 00000019 0 > 00000014 0 > 00000013 0 > 0000001b plugplay.exe > 00000020 0 > 0000001d 0 > 0000001c 0 > 0000003d explorer.exe > 0000003e 0 > 0000002f (D) Z:\home\bob\wineslave.dir\sandbox\slave\runtests-default\build\dlls\gdi32\tests\gdi32_test.exe > 00000032 0 <== > Backtrace: > =>0 0x68000832 GLIBC_2+0x832() in ld-linux.so.2 (0x0032fa98) > 1 0x681b8a82 abort+0x181() in libc.so.6 (0x0032fbc0) > 2 0x681ae718 __assert_fail+0xf7() in libc.so.6 (0x0032fc08) > 3 0x684dfce4 test_savedc_2+0xb4() [/home/bob/wineslave.dir/sandbox/slave/runtests-default/build/dlls/gdi32/tests/dc.c:66] in gdi32_test (0x0032fcd8) > 4 0x684e4510 func_dc+0x47() [/home/bob/wineslave.dir/sandbox/slave/runtests-default/build/dlls/gdi32/tests/dc.c:790] in gdi32_test (0x0032fcf8) > 5 0x68520bd7 run_test+0x9e(name="dc.c") [/home/bob/wineslave.dir/sandbox/slave/runtests-default/build/dlls/gdi32/tests/../../../include/wine/test.h:556] in gdi32_test (0x0032fd58) > 6 0x68520fec main+0x23a(argc=<couldn't compute location>, argv=0x1103c8) [/home/bob/wineslave.dir/sandbox/slave/runtests-default/build/dlls/gdi32/tests/../../../include/wine/test.h:624] in gdi32_test (0x0032fe28) > 7 0x6852107a __wine_spec_exe_entry+0x69(peb=0x7ffdf000) [/home/bob/wineslave.dir/sandbox/slave/runtests-default/build/dlls/winecrt0/exe_entry.c:36] in gdi32_test (0x0032fe60) > 8 0x7b85fe84 call_process_entry+0xb() in kernel32 (0x0032fe78) > 9 0x7b85ffca start_process+0x143(peb=0x7ffdf000) [/home/bob/wineslave.dir/sandbox/slave/runtests-default/build/dlls/kernel32/process.c:1091] in kernel32 (0x0032fec8) > 10 0x7bc7c104 call_thread_func+0xb() in ntdll (0x0032fed8) > 11 0x7bc7c142 call_thread_entry_point+0x33(entry=0x7b85fe86, arg=0x7ffdf000) [/home/bob/wineslave.dir/sandbox/slave/runtests-default/build/dlls/ntdll/signal_i386.c:2499] in ntdll (0x0032ffb8) > 12 0x7bc53699 start_process+0x23(kernel_start=0x7b85fe86) [/home/bob/wineslave.dir/sandbox/slave/runtests-default/build/dlls/ntdll/loader.c:2612] in ntdll (0x0032ffe8) > 13 0x680280b9 wine_call_on_stack+0x1c() in libwine.so.1 (0x00000000) > alarum: ../../../wine terminated abnormally > make: *** [dc.ok] Error 99 > alarum: failed command was ../../../wine gdi32_test.exe.so font.c > font.c:279: Test failed: tm.tmDescent should be > 0 > font.c:291: Test failed: height 2288: expected scale_x 1, scale_y 1, got cx -2375535, cy -938585 > font.c:293: Test failed: height -2147483648 != 2288 > font.c:294: Test failed: ascent -2147483648 != 1854 > font.c:295: Test failed: descent -2147483648 != 434 > font.c:296: Test failed: ave width -2147483648 != 904 > font.c:297: Test failed: max width -2147483648 != 5515 > font.c:310: Test failed: cx -2147483648 != 9902 > font.c:311: Test failed: cy -2147483648 != 2288 > font.c:315: Test failed: width A -2147483648 != 1366 > font.c:610: Test failed: incX 0 != -2147483648 > font.c:620: Test failed: incX -32768 != -1073741823 > font.c:621: Test failed: incY -32768 != 0 > Application tried to create a window, but no driver could be loaded. > Make sure that your X server is running and that $DISPLAY is set correctly. > font.c:3543: Tests skipped: Unable to locate and load font sserife.fon > font.c:2249: Tests skipped: Font KacstOne doesn't contain 'x', skipping the test > font.c:2249: Tests skipped: Font Kedage doesn't contain 'x', skipping the test > font.c:2249: Tests skipped: Font Lohit Bengali doesn't contain 'x', skipping the test > font.c:2249: Tests skipped: Font Lohit Gujarati doesn't contain 'x', skipping the test > font.c:2249: Tests skipped: Font Lohit Hindi doesn't contain 'x', skipping the test > font.c:2249: Tests skipped: Font Lohit Punjabi doesn't contain 'x', skipping the test > font.c:2249: Tests skipped: Font Lohit Tamil doesn't contain 'x', skipping the test > font.c:2249: Tests skipped: Font Mallige doesn't contain 'x', skipping the test > font.c:2249: Tests skipped: Font OpenSymbol doesn't contain 'x', skipping the test > font.c:2249: Tests skipped: Font Pothana2000 doesn't contain 'x', skipping the test > font.c:2249: Tests skipped: Font Purisa doesn't contain 'x', skipping the test > font.c:2249: Tests skipped: Font Saab doesn't contain 'x', skipping the test > font.c:2249: Tests skipped: Font UnBatang doesn't contain 'x', skipping the test > font.c:2249: Tests skipped: Font UnDotum doesn't contain 'x', skipping the test > font.c:2249: Tests skipped: Font utkal doesn't contain 'x', skipping the test > font.c:2249: Tests skipped: Font Vemana2000 doesn't contain 'x', skipping the test > fixme:font:WineEngRealizationInfo (0x11ecb0, 0x32fc70): stub! > fixme:font:WineEngRealizationInfo (0x12b8e8, 0x32fc70): stub! > fixme:font:WineEngCreateFontInstance Untranslated charset 255 > font.c:3786: Tests skipped: Lucida Sans Demibold Roman is not installed > font.c:3786: Tests skipped: Lucida Sans Italic is not installed > font.c:3786: Tests skipped: Lucida Sans Regular is not installed > fixme:font:CreateScalableFontResourceW (0,L"C:\\users\\bob\\Temp\\fotedc.tmp",L"C:\\users\\bob\\Temp\\ttfedb.tmp",(null)): stub > fixme:font:CreateScalableFontResourceW (0,L"C:\\users\\bob\\Temp\\fotedc.tmp",L"C:\\users\\bob\\Temp\\ttfedb.tmp",L""): stub > fixme:font:CreateScalableFontResourceW (0,L"C:\\users\\bob\\Temp\\fotedc.tmp",L"\\ttfedb.tmp",L"C:\\users\\bob\\Temp\\"): stub > fixme:font:CreateScalableFontResourceW (0,L"C:\\users\\bob\\Temp\\fotedc.tmp",L"random file name",L"C:\\users\\bob\\Temp\\"): stub > fixme:font:CreateScalableFontResourceW (0,L"C:\\users\\bob\\Temp\\fotedc.tmp",(null),L"C:\\users\\bob\\Temp\\ttfedb.tmp"): stub > fixme:font:WineEngRemoveFontResourceEx (L"C:\\users\\bob\\Temp\\fotedc.tmp", 0, (nil)): stub > make: *** [font.ok] Error 13 > alarum: failed command was ../../../wine gdi32_test.exe.so gdiobj.c > gdiobj.c:173: Test failed: GetDeviceCaps(TECHNOLOGY) should return DT_RASDISPLAY not 0 > make: *** [gdiobj.ok] Error 1 > alarum: failed command was ../../../wine gdi32_test.exe.so icm.c > icm.c:64: Test failed: expected size > 0 > icm.c:66: Test failed: got -559038737, expected ERROR_INSUFFICIENT_BUFFER > icm.c:73: Test failed: GetICMProfileA failed -559038737 > icm.c:116: Test failed: expected size > 0 > icm.c:117: Test failed: got -559038737, expected ERROR_INSUFFICIENT_BUFFER > icm.c:121: Test failed: GetICMProfileW failed -559038737 > fixme:icm:SetICMProfileA (nil) (null) stub > icm.c:229: Test failed: GetICMProfileA failed 87 > fixme:icm:SetICMProfileA (nil) (null) stub > fixme:icm:SetICMProfileA (nil) "\xf8\xfb2" stub > fixme:icm:SetICMProfileA 0x1b8 (null) stub > fixme:icm:SetICMProfileA 0x1b8 "\xf8\xfb2" stub > fixme:icm:SetICMProfileW (nil) (null) stub > icm.c:272: Test failed: GetICMProfileW failed 87 > fixme:icm:SetICMProfileW (nil) (null) stub > fixme:icm:SetICMProfileW (nil) L"\0017" stub > fixme:icm:SetICMProfileW 0x1b8 (null) stub > fixme:icm:SetICMProfileW 0x1b8 L"\0017" stub > make: *** [icm.ok] Error 8 > alarum: failed command was ../../../wine gdi32_test.exe.so mapping.c > mapping.c:454: Test failed: Viewport extents have not been properly adjusted: Expected 6400x-4800, got 6400x-2147483648 > mapping.c:428: Test failed: Viewport extents have not been properly adjusted: Expected 6400x-4800, got 6400x-2147483648 > mapping.c:428: Test failed: Viewport extents have not been properly adjusted: Expected 6400x-2400, got 6400x-2147483648 > mapping.c:428: Test failed: Viewport extents have not been properly adjusted: Expected 3200x-2400, got 6400x-2147483648 > mapping.c:454: Test failed: Viewport extents have not been properly adjusted: Expected 1280x-960, got 2560x-2147483648 > mapping.c:454: Test failed: Viewport extents have not been properly adjusted: Expected 1280x-960, got 2560x-2147483648 > mapping.c:428: Test failed: Viewport extents have not been properly adjusted: Expected 1280x-480, got 2560x-2147483648 > mapping.c:428: Test failed: Viewport extents have not been properly adjusted: Expected -640x480, got -1280x-2147483648 > mapping.c:614: Test failed: 663: got inf expect inf > mapping.c:617: Test failed: 663: got -inf expect -inf > mapping.c:618: Test failed: 663: got -nan expect 0.000000 > mapping.c:619: Test failed: 663: got -nan expect 0.000000 > mapping.c:614: Test failed: 667: got inf expect inf > mapping.c:615: Test failed: 667: got -nan expect 0.000000 > mapping.c:616: Test failed: 667: got -nan expect 0.000000 > mapping.c:617: Test failed: 667: got -inf expect -inf > mapping.c:618: Test failed: 667: got -nan expect 0.000000 > mapping.c:619: Test failed: 667: got -nan expect 0.000000 > mapping.c:614: Test failed: 673: got -nan expect 0.000000 > mapping.c:615: Test failed: 673: got nan expect 0.000000 > mapping.c:616: Test failed: 673: got nan expect 0.000000 > mapping.c:617: Test failed: 673: got -nan expect -0.000000 > mapping.c:618: Test failed: 673: got nan expect 0.000000 > mapping.c:619: Test failed: 673: got nan expect 0.000000 > mapping.c:614: Test failed: 689: got inf expect inf > mapping.c:617: Test failed: 689: got -inf expect -inf > mapping.c:618: Test failed: 689: got -nan expect 0.000000 > mapping.c:619: Test failed: 689: got -nan expect 0.000000 > mapping.c:614: Test failed: 695: got inf expect inf > mapping.c:615: Test failed: 695: got -nan expect 0.000000 > mapping.c:616: Test failed: 695: got -nan expect 0.000000 > mapping.c:617: Test failed: 695: got -inf expect -inf > mapping.c:618: Test failed: 695: got -nan expect 0.000000 > mapping.c:619: Test failed: 695: got -nan expect 0.000000 > mapping.c:614: Test failed: 701: got -nan expect 0.000000 > mapping.c:615: Test failed: 701: got nan expect 0.000000 > mapping.c:616: Test failed: 701: got nan expect 0.000000 > mapping.c:617: Test failed: 701: got -nan expect -0.000000 > mapping.c:618: Test failed: 701: got nan expect 0.000000 > mapping.c:619: Test failed: 701: got nan expect 0.000000 > fixme:dc:GetTransform Unknown code 102 > fixme:dc:GetTransform Unknown code 103 > fixme:dc:GetTransform Unknown code 104 > fixme:dc:GetTransform Unknown code 202 > fixme:dc:GetTransform Unknown code 302 > fixme:dc:GetTransform Unknown code 303 > fixme:dc:GetTransform Unknown code 403 > fixme:dc:GetTransform Unknown code 404 > fixme:dc:GetTransform Unknown code ffff > make: *** [mapping.ok] Error 40 > alarum: failed command was ../../../wine gdi32_test.exe.so metafile.c > Application tried to create a window, but no driver could be loaded. > Make sure that your X server is running and that $DISPLAY is set correctly. > metafile.c:174: Test failed: CreateWindowExA error 2 > metafile.c:209: Test failed: GetDeviceCaps(TECHNOLOGY) has to return DT_RASDISPLAY for a display based EMF > metafile.c:318: Test failed: CreateWindowExA failed > metafile.c:327: Test failed: GetDeviceCaps failed > metafile.c:293: Test failed: Got exScale -nan, expected -nan > metafile.c:295: Test failed: Got eyScale -nan, expected -nan > metafile.c:293: Test failed: Got exScale -nan, expected -nan > metafile.c:295: Test failed: Got eyScale -nan, expected -nan > metafile.c:293: Test failed: Got exScale -nan, expected -nan > metafile.c:295: Test failed: Got eyScale -nan, expected -nan > metafile.c:293: Test failed: Got exScale -nan, expected -nan > metafile.c:295: Test failed: Got eyScale -nan, expected -nan > metafile.c:293: Test failed: Got exScale -nan, expected -nan > metafile.c:295: Test failed: Got eyScale -nan, expected -nan > metafile.c:641: Test failed: CreateWindowExA error 5 > metafile.c:2161: Test failed: CreateWindowExA error 13 > metafile.c:2398: Test failed: CreateWindowExA error -559038737 > err:enhmetafile:EMF_Update_MF_Xform World transform failed! > err:enhmetafile:EMF_Update_MF_Xform World transform failed! > err:enhmetafile:EMF_Update_MF_Xform World transform failed! > err:enhmetafile:EMF_Update_MF_Xform World transform failed! > err:enhmetafile:EMF_Update_MF_Xform World transform failed! > err:enhmetafile:EMF_Update_MF_Xform World transform failed! > metafile.c:2460: Test failed: (0,0)->(10,10), expected (0,0)->(0,0) > err:enhmetafile:EMF_Update_MF_Xform World transform failed! > err:enhmetafile:EMF_Update_MF_Xform World transform failed! > err:enhmetafile:EMF_Update_MF_Xform World transform failed! > err:enhmetafile:EMF_Update_MF_Xform World transform failed! > err:enhmetafile:EMF_Update_MF_Xform World transform failed! > err:enhmetafile:EMF_Update_MF_Xform World transform failed! > metafile.c:2460: Test failed: (0,0)->(10,10), expected (0,0)->(18,67) > metafile.c:2460: Test failed: (0,0)->(10,10), expected (0,0)->(18,67) > metafile.c:2713: Test failed: SetWinMetaFileBits: Reference bounds: Left and top bound must be zero > metafile.c:2724: Test failed: SetWinMetaFileBits (MM_ISOTROPIC): Reference bounds are not isotropic > metafile.c:2747: Test succeeded inside todo block: SetWinMetaFileBits (MM_ANISOTROPIC): Reference frame: The whole device surface must be used (0x0), but got (0x0) > metafile.c:2781: Test failed: SetWinMetaFileBits (MM_ANISOTROPIC): rclBounds contains invalid values > wine: Unhandled division by zero at address 0x68721d5b (thread 0026), starting debugger... > Unhandled exception: divide by zero in 32-bit code (0x68721d5b). > Register dump: > CS:0073 SS:007b DS:007b ES:007b FS:0033 GS:003b > EIP:68721d5b ESP:0032f970 EBP:0032f998 EFLAGS:00210246( R- -- I Z- -P- ) > EAX:00000001 EBX:68735ff4 ECX:00000000 EDX:00000000 > ESI:00000000 EDI:00000000 > Stack dump: > 0x0032f970: 0000034c 68735ff4 0032f998 68701559 > 0x0032f980: 68739e40 00000000 000ea600 00000000 > 0x0032f990: 00000000 00000000 0032fa08 6870861e > 0x0032f9a0: 000ea600 00000000 00000000 00000000 > 0x0032f9b0: 00000026 00000000 000ea600 00000000 > 0x0032f9c0: ffffffff 00132194 00132194 00000000 > Backtrace: > =>0 0x68721d5b __divdi3+0x8b() in gdi32 (0x0032f998) > 1 0x6870861e muldiv+0x8a(m1=0x7d0, m2=0x1e0, d=0) [/home/bob/wineslave.dir/sandbox/slave/runtests-default/build/dlls/gdi32/metafile.c:1234] in gdi32 (0x0032fa08) > 2 0x687087d8 set_window+0xde(hdc=0x6c4, emf=0x6c0, ref_dc=0x34c, map_mode=0x1) [/home/bob/wineslave.dir/sandbox/slave/runtests-default/build/dlls/gdi32/metafile.c:1269] in gdi32 (0x0032fac8) > 3 0x68708b3b GetWinMetaFileBits+0xfa(hemf=0x6c0, cbBuffer=0, lpbBuffer=0x0(nil), map_mode=0x1, hdcRef=0x34c) [/home/bob/wineslave.dir/sandbox/slave/runtests-default/build/dlls/gdi32/metafile.c:1325] in gdi32 (0x0032fb48) > 4 0x6851848a getwinmetafilebits+0x3f3(mode=0x1, scale=0x1, rc=0x32fc28) [/home/bob/wineslave.dir/sandbox/slave/runtests-default/build/dlls/gdi32/tests/metafile.c:2869] in gdi32_test (0x0032fbf8) > 5 0x68519287 test_GetWinMetaFileBits+0xd7() [/home/bob/wineslave.dir/sandbox/slave/runtests-default/build/dlls/gdi32/tests/metafile.c:3007] in gdi32_test (0x0032fce8) > 6 0x68519bca func_metafile+0x64() [/home/bob/wineslave.dir/sandbox/slave/runtests-default/build/dlls/gdi32/tests/metafile.c:3140] in gdi32_test (0x0032fcf8) > 7 0x68520bd7 run_test+0x9e(name="metafile.c") [/home/bob/wineslave.dir/sandbox/slave/runtests-default/build/dlls/gdi32/tests/../../../include/wine/test.h:556] in gdi32_test (0x0032fd58) > 8 0x68520fec main+0x23a(argc=<couldn't compute location>, argv=0x1103d0) [/home/bob/wineslave.dir/sandbox/slave/runtests-default/build/dlls/gdi32/tests/../../../include/wine/test.h:624] in gdi32_test (0x0032fe28) > 9 0x6852107a __wine_spec_exe_entry+0x69(peb=0x7ffdf000) [/home/bob/wineslave.dir/sandbox/slave/runtests-default/build/dlls/winecrt0/exe_entry.c:36] in gdi32_test (0x0032fe60) > 10 0x7b85fe84 call_process_entry+0xb() in kernel32 (0x0032fe78) > 11 0x7b85ffca start_process+0x143(peb=0x7ffdf000) [/home/bob/wineslave.dir/sandbox/slave/runtests-default/build/dlls/kernel32/process.c:1091] in kernel32 (0x0032fec8) > 12 0x7bc7c104 call_thread_func+0xb() in ntdll (0x0032fed8) > 13 0x7bc7c142 call_thread_entry_point+0x33(entry=0x7b85fe86, arg=0x7ffdf000) [/home/bob/wineslave.dir/sandbox/slave/runtests-default/build/dlls/ntdll/signal_i386.c:2499] in ntdll (0x0032ffb8) > 14 0x7bc53699 start_process+0x23(kernel_start=0x7b85fe86) [/home/bob/wineslave.dir/sandbox/slave/runtests-default/build/dlls/ntdll/loader.c:2612] in ntdll (0x0032ffe8) > 15 0x680280b9 wine_call_on_stack+0x1c() in libwine.so.1 (0x00000000) > 0x68721d5b __divdi3+0x8b in gdi32: divl %esi,%eax > Modules: > Module Address Debug info Name (32 modules) > ELF 68000000-6801d000 Deferred ld-linux.so.2 > ELF 6801f000-68160000 Dwarf libwine.so.1 > ELF 68172000-6818b000 Deferred libpthread.so.0 > ELF 6818b000-682e5000 Deferred libc.so.6 > ELF 682e6000-682ea000 Deferred libdl.so.2 > ELF 682eb000-68311000 Deferred libm.so.6 > ELF 68311000-68319000 Deferred libnss_compat.so.2 > ELF 68319000-68330000 Deferred libnsl.so.1 > ELF 68330000-6833a000 Deferred libnss_nis.so.2 > ELF 6833a000-68346000 Deferred libnss_files.so.2 > ELF 684a3000-6853b000 Dwarf gdi32_test<elf> > \-PE 684b0000-6853b000 \ gdi32_test > ELF 6853b000-6868f000 Deferred user32<elf> > \-PE 68550000-6868f000 \ user32 > ELF 6868f000-6874b000 Dwarf gdi32<elf> > \-PE 686a0000-6874b000 \ gdi32 > ELF 6874b000-687b1000 Deferred advapi32<elf> > \-PE 68760000-687b1000 \ advapi32 > ELF 687b1000-687cc000 Deferred version<elf> > \-PE 687c0000-687cc000 \ version > ELF 687de000-68854000 Deferred libfreetype.so.6 > ELF 68854000-68869000 Deferred libz.so.1 > ELF 68946000-68956000 Deferred libxext.so.6 > ELF 68956000-68a73000 Deferred libx11.so.6 > ELF 68a78000-68a92000 Deferred libxcb.so.1 > ELF 68a92000-68a96000 Deferred libxau.so.6 > ELF 68a96000-68a9c000 Deferred libxdmcp.so.6 > ELF 7b800000-7b9b1000 Dwarf kernel32<elf> > \-PE 7b810000-7b9b1000 \ kernel32 > ELF 7bc00000-7bccd000 Dwarf ntdll<elf> > \-PE 7bc10000-7bccd000 \ ntdll > ELF 7bf00000-7bf04000 Deferred <wine-loader> > Threads: > process tid prio (all id:s are in hex) > 0000000e services.exe > 0000001f 0 > 0000001e 0 > 00000015 0 > 00000010 0 > 0000000f 0 > 00000012 winedevice.exe > 0000001a 0 > 00000019 0 > 00000014 0 > 00000013 0 > 0000001b plugplay.exe > 00000020 0 > 0000001d 0 > 0000001c 0 > 0000003d explorer.exe > 0000003e 0 > 00000009 (D) Z:\home\bob\wineslave.dir\sandbox\slave\runtests-default\build\dlls\gdi32\tests\gdi32_test.exe > 00000026 0 <== > Backtrace: > =>0 0x68721d5b __divdi3+0x8b() in gdi32 (0x0032f998) > 1 0x6870861e muldiv+0x8a(m1=0x7d0, m2=0x1e0, d=0) [/home/bob/wineslave.dir/sandbox/slave/runtests-default/build/dlls/gdi32/metafile.c:1234] in gdi32 (0x0032fa08) > 2 0x687087d8 set_window+0xde(hdc=0x6c4, emf=0x6c0, ref_dc=0x34c, map_mode=0x1) [/home/bob/wineslave.dir/sandbox/slave/runtests-default/build/dlls/gdi32/metafile.c:1269] in gdi32 (0x0032fac8) > 3 0x68708b3b GetWinMetaFileBits+0xfa(hemf=0x6c0, cbBuffer=0, lpbBuffer=0x0(nil), map_mode=0x1, hdcRef=0x34c) [/home/bob/wineslave.dir/sandbox/slave/runtests-default/build/dlls/gdi32/metafile.c:1325] in gdi32 (0x0032fb48) > 4 0x6851848a getwinmetafilebits+0x3f3(mode=0x1, scale=0x1, rc=0x32fc28) [/home/bob/wineslave.dir/sandbox/slave/runtests-default/build/dlls/gdi32/tests/metafile.c:2869] in gdi32_test (0x0032fbf8) > 5 0x68519287 test_GetWinMetaFileBits+0xd7() [/home/bob/wineslave.dir/sandbox/slave/runtests-default/build/dlls/gdi32/tests/metafile.c:3007] in gdi32_test (0x0032fce8) > 6 0x68519bca func_metafile+0x64() [/home/bob/wineslave.dir/sandbox/slave/runtests-default/build/dlls/gdi32/tests/metafile.c:3140] in gdi32_test (0x0032fcf8) > 7 0x68520bd7 run_test+0x9e(name="metafile.c") [/home/bob/wineslave.dir/sandbox/slave/runtests-default/build/dlls/gdi32/tests/../../../include/wine/test.h:556] in gdi32_test (0x0032fd58) > 8 0x68520fec main+0x23a(argc=<couldn't compute location>, argv=0x1103d0) [/home/bob/wineslave.dir/sandbox/slave/runtests-default/build/dlls/gdi32/tests/../../../include/wine/test.h:624] in gdi32_test (0x0032fe28) > 9 0x6852107a __wine_spec_exe_entry+0x69(peb=0x7ffdf000) [/home/bob/wineslave.dir/sandbox/slave/runtests-default/build/dlls/winecrt0/exe_entry.c:36] in gdi32_test (0x0032fe60) > 10 0x7b85fe84 call_process_entry+0xb() in kernel32 (0x0032fe78) > 11 0x7b85ffca start_process+0x143(peb=0x7ffdf000) [/home/bob/wineslave.dir/sandbox/slave/runtests-default/build/dlls/kernel32/process.c:1091] in kernel32 (0x0032fec8) > 12 0x7bc7c104 call_thread_func+0xb() in ntdll (0x0032fed8) > 13 0x7bc7c142 call_thread_entry_point+0x33(entry=0x7b85fe86, arg=0x7ffdf000) [/home/bob/wineslave.dir/sandbox/slave/runtests-default/build/dlls/ntdll/signal_i386.c:2499] in ntdll (0x0032ffb8) > 14 0x7bc53699 start_process+0x23(kernel_start=0x7b85fe86) [/home/bob/wineslave.dir/sandbox/slave/runtests-default/build/dlls/ntdll/loader.c:2612] in ntdll (0x0032ffe8) > 15 0x680280b9 wine_call_on_stack+0x1c() in libwine.so.1 (0x00000000) > make: *** [metafile.ok] Error 148 > alarum: failed command was ../../../wine gdi32_test.exe.so palette.c > palette.c:90: Test failed: getColor=00000000 > palette.c:97: Test failed: getColor=00000000 > palette.c:112: Test failed: getColor=00000000 > make: *** [palette.ok] Error 3 > alarum: failed command was ../../../wine gdi32_test.exe.so pen.c > fixme:gdi:ExtCreatePen PS_COSMETIC | PS_USERSTYLE not handled > fixme:gdi:ExtCreatePen PS_COSMETIC | PS_USERSTYLE not handled > pen.c:505: Test failed: Expected 00000080, got 00000000 > pen.c:506: Test failed: Expected 00000080, got 00000000 > pen.c:507: Test failed: Expected 000000a0, got 00000000 > pen.c:508: Test failed: Expected 000000a0, got 00000000 > pen.c:509: Test failed: Expected 00000050, got 00000000 > pen.c:510: Test failed: Expected 00000050, got 00000000 > pen.c:511: Test failed: Expected 0000000a, got 00000000 > make: *** [pen.ok] Error 7 > ALSA lib conf.c:4154:(_snd_config_evaluate) function snd_func_card_driver returned error: No such file or directory > ALSA lib conf.c:4154:(_snd_config_evaluate) function snd_func_concat returned error: No such file or directory > ALSA lib conf.c:4154:(_snd_config_evaluate) function snd_func_refer returned error: No such file or directory > ALSA lib conf.c:4633:(snd_config_expand) Evaluate error: No such file or directory > ALSA lib conf.c:4154:(_snd_config_evaluate) function snd_func_card_driver returned error: No such file or directory > ALSA lib conf.c:4154:(_snd_config_evaluate) function snd_func_concat returned error: No such file or directory > ALSA lib conf.c:4154:(_snd_config_evaluate) function snd_func_refer returned error: No such file or directory > ALSA lib conf.c:4633:(snd_config_expand) Evaluate error: No such file or directory > ALSA lib conf.c:4154:(_snd_config_evaluate) function snd_func_card_driver returned error: No such file or directory > ALSA lib conf.c:4154:(_snd_config_evaluate) function snd_func_concat returned error: No such file or directory > ALSA lib conf.c:4154:(_snd_config_evaluate) function snd_func_refer returned error: No such file or directory > ALSA lib conf.c:4633:(snd_config_expand) Evaluate error: No such file or directory > ALSA lib conf.c:4154:(_snd_config_evaluate) function snd_func_card_driver returned error: No such file or directory > ALSA lib conf.c:4154:(_snd_config_evaluate) function snd_func_concat returned error: No such file or directory > ALSA lib conf.c:4154:(_snd_config_evaluate) function snd_func_refer returned error: No such file or directory > ALSA lib conf.c:4633:(snd_config_expand) Evaluate error: No such file or directory > ALSA lib conf.c:4154:(_snd_config_evaluate) function snd_func_card_driver returned error: No such file or directory > ALSA lib conf.c:4154:(_snd_config_evaluate) function snd_func_concat returned error: No such file or directory > ALSA lib conf.c:4154:(_snd_config_evaluate) function snd_func_refer returned error: No such file or directory > ALSA lib conf.c:4633:(snd_config_expand) Evaluate error: No such file or directory > ALSA lib conf.c:4154:(_snd_config_evaluate) function snd_func_card_driver returned error: No such file or directory > ALSA lib conf.c:4154:(_snd_config_evaluate) function snd_func_concat returned error: No such file or directory > ALSA lib conf.c:4154:(_snd_config_evaluate) function snd_func_refer returned error: No such file or directory > ALSA lib conf.c:4633:(snd_config_expand) Evaluate error: No such file or directory > ALSA lib conf.c:4154:(_snd_config_evaluate) function snd_func_card_driver returned error: No such file or directory > ALSA lib conf.c:4154:(_snd_config_evaluate) function snd_func_concat returned error: No such file or directory > ALSA lib conf.c:4154:(_snd_config_evaluate) function snd_func_refer returned error: No such file or directory > ALSA lib conf.c:4633:(snd_config_expand) Evaluate error: No such file or directory > ALSA lib conf.c:4154:(_snd_config_evaluate) function snd_func_card_driver returned error: No such file or directory > ALSA lib conf.c:4154:(_snd_config_evaluate) function snd_func_concat returned error: No such file or directory > ALSA lib conf.c:4154:(_snd_config_evaluate) function snd_func_refer returned error: No such file or directory > ALSA lib conf.c:4633:(snd_config_expand) Evaluate error: No such file or directory > ALSA lib conf.c:4154:(_snd_config_evaluate) function snd_func_card_driver returned error: No such file or directory > ALSA lib conf.c:4154:(_snd_config_evaluate) function snd_func_concat returned error: No such file or directory > ALSA lib conf.c:4154:(_snd_config_evaluate) function snd_func_refer returned error: No such file or directory > ALSA lib conf.c:4633:(snd_config_expand) Evaluate error: No such file or directory > ALSA lib conf.c:4154:(_snd_config_evaluate) function snd_func_card_driver returned error: No such file or directory > ALSA lib conf.c:4154:(_snd_config_evaluate) function snd_func_concat returned error: No such file or directory > ALSA lib conf.c:4154:(_snd_config_evaluate) function snd_func_refer returned error: No such file or directory > ALSA lib conf.c:4633:(snd_config_expand) Evaluate error: No such file or directory > * Call to xpconnect wrapped JSObject produced this error: * > * Call to xpconnect wrapped JSObject produced this error: * > alarum: failed command was ../../../wine opengl32_test.exe.so opengl.c > Xlib: extension "GLX" missing on display ":0.0". > err:wgl:X11DRV_WineGL_InitOpenglInfo couldn't initialize OpenGL, expect problems > opengl.c:1295: Test failed: Unable to find pixel format. > fixme:event:wait_for_withdrawn_state window 0x2300d2/800001 wait timed out > make: *** [opengl.ok] Error 1 > ALSA lib conf.c:4154:(_snd_config_evaluate) function snd_func_card_driver returned error: No such file or directory > ALSA lib conf.c:4154:(_snd_config_evaluate) function snd_func_concat returned error: No such file or directory > ALSA lib conf.c:4154:(_snd_config_evaluate) function snd_func_refer returned error: No such file or directory > ALSA lib conf.c:4633:(snd_config_expand) Evaluate error: No such file or directory > ALSA lib conf.c:4154:(_snd_config_evaluate) function snd_func_card_driver returned error: No such file or directory > ALSA lib conf.c:4154:(_snd_config_evaluate) function snd_func_concat returned error: No such file or directory > ALSA lib conf.c:4154:(_snd_config_evaluate) function snd_func_refer returned error: No such file or directory > ALSA lib conf.c:4633:(snd_config_expand) Evaluate error: No such file or directory > ALSA lib conf.c:4154:(_snd_config_evaluate) function snd_func_card_driver returned error: No such file or directory > ALSA lib conf.c:4154:(_snd_config_evaluate) function snd_func_concat returned error: No such file or directory > ALSA lib conf.c:4154:(_snd_config_evaluate) function snd_func_refer returned error: No such file or directory > ALSA lib conf.c:4633:(snd_config_expand) Evaluate error: No such file or directory > ALSA lib conf.c:4154:(_snd_config_evaluate) function snd_func_card_driver returned error: No such file or directory > ALSA lib conf.c:4154:(_snd_config_evaluate) function snd_func_concat returned error: No such file or directory > ALSA lib conf.c:4154:(_snd_config_evaluate) function snd_func_refer returned error: No such file or directory > ALSA lib conf.c:4633:(snd_config_expand) Evaluate error: No such file or directory > ALSA lib conf.c:4154:(_snd_config_evaluate) function snd_func_card_driver returned error: No such file or directory > ALSA lib conf.c:4154:(_snd_config_evaluate) function snd_func_concat returned error: No such file or directory > ALSA lib conf.c:4154:(_snd_config_evaluate) function snd_func_refer returned error: No such file or directory > ALSA lib conf.c:4633:(snd_config_expand) Evaluate error: No such file or directory > ALSA lib conf.c:4154:(_snd_config_evaluate) function snd_func_card_driver returned error: No such file or directory > ALSA lib conf.c:4154:(_snd_config_evaluate) function snd_func_concat returned error: No such file or directory > ALSA lib conf.c:4154:(_snd_config_evaluate) function snd_func_refer returned error: No such file or directory > ALSA lib conf.c:4633:(snd_config_expand) Evaluate error: No such file or directory > alarum: failed command was ../../../wine user32_test.exe.so sysparams.c > sysparams.c:2399: Test failed: Waiting for the WM_DISPLAYCHANGE message timed out > sysparams.c:2399: Test failed: Waiting for the WM_DISPLAYCHANGE message timed out > err:x11settings:X11DRV_ChangeDisplaySettingsEx No matching mode found 800x600x24 @0! (XRandR) > sysparams.c:2404: Tests skipped: Setting depth 24 failed(ret = -2) > sysparams.c:2399: Test failed: Waiting for the WM_DISPLAYCHANGE message timed out > sysparams.c:2412: Test failed: Set bpp 32, but WM_DISPLAYCHANGE reported bpp -1 > make: *** [sysparams.ok] Error 4 > alarum: failed command was ../../../wine shell32_test.exe.so ebrowser.c > fixme:shell:IShellBrowser_fnSendControlMsg stub, 0x12d030 (1, 0, 0, 0, 0x32fcb8) > fixme:shell:IShellBrowser_fnSendControlMsg stub, 0x12d030 (2, 1026, a003, 1, 0x32fcb8) > fixme:shell:IShellBrowser_fnSendControlMsg stub, 0x12d030 (1, 0, 0, 0, (nil)) > fixme:shell:IShellBrowser_fnSendControlMsg stub, 0x12d030 (3, 0, 0, 0, (nil)) > fixme:shell:IShellBrowser_fnSendControlMsg stub, 0x12d030 (8, 0, 0, 0, (nil)) > fixme:shell:IShellBrowser_fnSendControlMsg stub, 0x12d030 (1, 0, 0, 0, (nil)) > fixme:shell:IShellBrowser_fnSendControlMsg stub, 0x12d030 (2, 0, 0, 0, 0x32fcb8) > fixme:shell:IShellBrowser_fnSendControlMsg stub, 0x12d030 (1, 0, 0, 0, 0x32fcb8) > fixme:shell:IShellBrowser_fnSendControlMsg stub, 0x12d030 (1234, 0, 0, 0, 0x32fcb8) > fixme:shell:IShellBrowser_fnSetStatusTextSB stub, 0x12d030 ((null)) > fixme:shell:IShellBrowser_fnContextSensitiveHelp stub, 0x12d030 (0) > fixme:shell:IShellBrowser_fnEnableModelessSB stub, 0x12d030 (1) > fixme:shell:IShellBrowser_fnSetToolbarItems stub, 0x12d030 ((nil), 1, 0x1) > fixme:shell:IShellBrowser_fnSendControlMsg stub, 0x12d030 (2, 1026, a003, 0, 0x32f9fc) > fixme:shell:IShellBrowser_fnSendControlMsg stub, 0x12d030 (2, 1026, a004, 1, 0x32f9fc) > fixme:shell:IShellBrowser_fnSendControlMsg stub, 0x12d030 (2, 1025, a003, 1, 0x32f9fc) > fixme:shell:IShellBrowser_fnSendControlMsg stub, 0x12d030 (2, 1025, a004, 1, 0x32f9fc) > fixme:win:DeferWindowPos other process handle 0xdeadbeef? > fixme:shell:IExplorerBrowser_fnSetOptions Flags 0xdeadbeef contains unsupported options. > fixme:nstc:NSTC2_fnSetControlStyle2 mask & style (0x00000004) contains unsupported style(s): 0x00000004 > fixme:shell:IExplorerBrowser_fnSetPropertyBag stub, 0x12d030 ((null)) > fixme:shell:IExplorerBrowser_fnSetPropertyBag stub, 0x12d030 (L"WineTest") > fixme:shell:IShellBrowser_fnSendControlMsg stub, 0x12d030 (2, 1026, a003, 0, 0x32f9ec) > fixme:shell:IShellBrowser_fnSendControlMsg stub, 0x12d030 (2, 1026, a004, 1, 0x32f9ec) > fixme:shell:IShellBrowser_fnSendControlMsg stub, 0x12d030 (2, 1025, a003, 1, 0x32f9ec) > fixme:shell:IShellBrowser_fnSendControlMsg stub, 0x12d030 (2, 1025, a004, 1, 0x32f9ec) > err:shell:IExplorerBrowser_fnBrowseToIDList Failed to get absolute pidl. > err:shell:IExplorerBrowser_fnBrowseToIDList Failed to get absolute pidl. > err:shell:IExplorerBrowser_fnBrowseToIDList Failed to get absolute pidl. > err:shell:IExplorerBrowser_fnBrowseToIDList Failed to get absolute pidl. > err:shell:IExplorerBrowser_fnBrowseToIDList Failed to get parent pidl. > err:shell:IExplorerBrowser_fnBrowseToIDList Failed to get parent pidl. > fixme:shell:IShellBrowser_fnSendControlMsg stub, 0x12d030 (2, 1026, a003, 0, 0x32f5ac) > fixme:shell:IShellBrowser_fnSendControlMsg stub, 0x12d030 (2, 1026, a004, 1, 0x32f5ac) > fixme:shell:IShellBrowser_fnSendControlMsg stub, 0x12d030 (2, 1025, a003, 1, 0x32f5ac) > fixme:shell:IShellBrowser_fnSendControlMsg stub, 0x12d030 (2, 1025, a004, 1, 0x32f5ac) > fixme:shell:IShellBrowser_fnSendControlMsg stub, 0x12f388 (2, 1026, a003, 0, 0x32f56c) > fixme:shell:IShellBrowser_fnSendControlMsg stub, 0x12f388 (2, 1026, a004, 1, 0x32f56c) > fixme:shell:IShellBrowser_fnSendControlMsg stub, 0x12f388 (2, 1025, a003, 1, 0x32f56c) > fixme:shell:IShellBrowser_fnSendControlMsg stub, 0x12f388 (2, 1025, a004, 1, 0x32f56c) > fixme:shell:IShellBrowser_fnSendControlMsg stub, 0x12d030 (2, 1026, a003, 0, 0x32f5ac) > fixme:shell:IShellBrowser_fnSendControlMsg stub, 0x12d030 (2, 1026, a004, 1, 0x32f5ac) > fixme:shell:IShellBrowser_fnSendControlMsg stub, 0x12d030 (2, 1025, a003, 1, 0x32f5ac) > fixme:shell:IShellBrowser_fnSendControlMsg stub, 0x12d030 (2, 1025, a004, 1, 0x32f5ac) > fixme:shell:IShellBrowser_fnSendControlMsg stub, 0x12f388 (2, 1026, a003, 0, 0x32f56c) > fixme:shell:IShellBrowser_fnSendControlMsg stub, 0x12f388 (2, 1026, a004, 1, 0x32f56c) > fixme:shell:IShellBrowser_fnSendControlMsg stub, 0x12f388 (2, 1025, a003, 1, 0x32f56c) > fixme:shell:IShellBrowser_fnSendControlMsg stub, 0x12f388 (2, 1025, a004, 1, 0x32f56c) > fixme:shell:IShellBrowser_fnSendControlMsg stub, 0x12d030 (2, 1026, a003, 0, 0x32f5ac) > fixme:shell:IShellBrowser_fnSendControlMsg stub, 0x12d030 (2, 1026, a004, 1, 0x32f5ac) > fixme:shell:IShellBrowser_fnSendControlMsg stub, 0x12d030 (2, 1025, a003, 1, 0x32f5ac) > fixme:shell:IShellBrowser_fnSendControlMsg stub, 0x12d030 (2, 1025, a004, 1, 0x32f5ac) > fixme:shell:IShellBrowser_fnSendControlMsg stub, 0x12f388 (2, 1026, a003, 0, 0x32f56c) > fixme:shell:IShellBrowser_fnSendControlMsg stub, 0x12f388 (2, 1026, a004, 1, 0x32f56c) > fixme:shell:IShellBrowser_fnSendControlMsg stub, 0x12f388 (2, 1025, a003, 1, 0x32f56c) > fixme:shell:IShellBrowser_fnSendControlMsg stub, 0x12f388 (2, 1025, a004, 1, 0x32f56c) > fixme:shell:IShellBrowser_fnSendControlMsg stub, 0x12d030 (2, 1026, a003, 0, 0x32f5ac) > fixme:shell:IShellBrowser_fnSendControlMsg stub, 0x12d030 (2, 1026, a004, 1, 0x32f5ac) > fixme:shell:IShellBrowser_fnSendControlMsg stub, 0x12d030 (2, 1025, a003, 1, 0x32f5ac) > fixme:shell:IShellBrowser_fnSendControlMsg stub, 0x12d030 (2, 1025, a004, 1, 0x32f5ac) > fixme:shell:IShellBrowser_fnSendControlMsg stub, 0x12f388 (2, 1026, a003, 0, 0x32f56c) > fixme:shell:IShellBrowser_fnSendControlMsg stub, 0x12f388 (2, 1026, a004, 1, 0x32f56c) > fixme:shell:IShellBrowser_fnSendControlMsg stub, 0x12f388 (2, 1025, a003, 1, 0x32f56c) > fixme:shell:IShellBrowser_fnSendControlMsg stub, 0x12f388 (2, 1025, a004, 1, 0x32f56c) > fixme:shell:IShellBrowser_fnSendControlMsg stub, 0x12d030 (2, 1026, a003, 0, 0x32f5ac) > fixme:shell:IShellBrowser_fnSendControlMsg stub, 0x12d030 (2, 1026, a004, 1, 0x32f5ac) > fixme:shell:IShellBrowser_fnSendControlMsg stub, 0x12d030 (2, 1025, a003, 1, 0x32f5ac) > fixme:shell:IShellBrowser_fnSendControlMsg stub, 0x12d030 (2, 1025, a004, 1, 0x32f5ac) > fixme:shell:IShellBrowser_fnSendControlMsg stub, 0x12f388 (2, 1026, a003, 0, 0x32f56c) > fixme:shell:IShellBrowser_fnSendControlMsg stub, 0x12f388 (2, 1026, a004, 1, 0x32f56c) > fixme:shell:IShellBrowser_fnSendControlMsg stub, 0x12f388 (2, 1025, a003, 1, 0x32f56c) > fixme:shell:IShellBrowser_fnSendControlMsg stub, 0x12f388 (2, 1025, a004, 1, 0x32f56c) > fixme:shell:IShellBrowser_fnSendControlMsg stub, 0x12d030 (2, 1026, a003, 0, 0x32f5ac) > fixme:shell:IShellBrowser_fnSendControlMsg stub, 0x12d030 (2, 1026, a004, 1, 0x32f5ac) > fixme:shell:IShellBrowser_fnSendControlMsg stub, 0x12d030 (2, 1025, a003, 1, 0x32f5ac) > fixme:shell:IShellBrowser_fnSendControlMsg stub, 0x12d030 (2, 1025, a004, 1, 0x32f5ac) > fixme:shell:IShellBrowser_fnSendControlMsg stub, 0x12f388 (2, 1026, a003, 0, 0x32f56c) > fixme:shell:IShellBrowser_fnSendControlMsg stub, 0x12f388 (2, 1026, a004, 1, 0x32f56c) > fixme:shell:IShellBrowser_fnSendControlMsg stub, 0x12f388 (2, 1025, a003, 1, 0x32f56c) > fixme:shell:IShellBrowser_fnSendControlMsg stub, 0x12f388 (2, 1025, a004, 1, 0x32f56c) > fixme:shell:IShellBrowser_fnSendControlMsg stub, 0x12f388 (2, 1026, a003, 0, 0x32f5ac) > fixme:shell:IShellBrowser_fnSendControlMsg stub, 0x12f388 (2, 1026, a004, 1, 0x32f5ac) > fixme:shell:IShellBrowser_fnSendControlMsg stub, 0x12f388 (2, 1025, a003, 1, 0x32f5ac) > fixme:shell:IShellBrowser_fnSendControlMsg stub, 0x12f388 (2, 1025, a004, 1, 0x32f5ac) > fixme:shell:IExplorerBrowser_fnSetOptions Flags 0x00000004 contains unsupported options. > fixme:shell:IShellBrowser_fnSendControlMsg stub, 0x12f388 (2, 1026, a003, 0, 0x32f5ac) > fixme:shell:IShellBrowser_fnSendControlMsg stub, 0x12f388 (2, 1026, a004, 1, 0x32f5ac) > fixme:shell:IShellBrowser_fnSendControlMsg stub, 0x12f388 (2, 1025, a003, 1, 0x32f5ac) > fixme:shell:IShellBrowser_fnSendControlMsg stub, 0x12f388 (2, 1025, a004, 1, 0x32f5ac) > fixme:shell:IShellBrowser_fnSendControlMsg stub, 0x12f388 (2, 1026, a003, 0, 0x32f5ac) > fixme:shell:IShellBrowser_fnSendControlMsg stub, 0x12f388 (2, 1026, a004, 1, 0x32f5ac) > fixme:shell:IShellBrowser_fnSendControlMsg stub, 0x12f388 (2, 1025, a003, 1, 0x32f5ac) > fixme:shell:IShellBrowser_fnSendControlMsg stub, 0x12f388 (2, 1025, a004, 1, 0x32f5ac) > fixme:shell:IShellBrowser_fnSendControlMsg stub, 0x12e808 (2, 1026, a003, 0, 0x32fa0c) > fixme:shell:IShellBrowser_fnSendControlMsg stub, 0x12e808 (2, 1026, a004, 1, 0x32fa0c) > fixme:shell:IShellBrowser_fnSendControlMsg stub, 0x12e808 (2, 1025, a003, 1, 0x32fa0c) > fixme:shell:IShellBrowser_fnSendControlMsg stub, 0x12e808 (2, 1025, a004, 1, 0x32fa0c) > fixme:nstc:NSTC2_fnSetControlStyle2 mask & style (0x00000004) contains unsupported style(s): 0x00000004 > fixme:shell:IShellBrowser_fnSendControlMsg stub, 0x12e808 (2, 1026, a003, 0, 0x32f7ac) > fixme:shell:IShellBrowser_fnSendControlMsg stub, 0x12e808 (2, 1026, a004, 1, 0x32f7ac) > fixme:shell:IShellBrowser_fnSendControlMsg stub, 0x12e808 (2, 1025, a003, 1, 0x32f7ac) > fixme:shell:IShellBrowser_fnSendControlMsg stub, 0x12e808 (2, 1025, a004, 1, 0x32f7ac) > XIO: fatal IO error 104 (Connection reset by peer) on X server ":0.0" > after 2790 requests (1173 known processed) with 0 events remaining. > make: *** [ebrowser.ok] Error 1 > alarum: failed command was ../../../wine shell32_test.exe.so shlexec.c > fixme:exec:SHELL_execute flags ignored: 0x00004000 > fixme:exec:SHELL_execute flags ignored: 0x00004000 > fixme:exec:SHELL_execute flags ignored: 0x00004000 > fixme:exec:SHELL_execute flags ignored: 0x00004000 > fixme:exec:SHELL_execute flags ignored: 0x00004000 > fixme:exec:SHELL_execute flags ignored: 0x00004000 > fixme:exec:SHELL_execute flags ignored: 0x00004000 > fixme:exec:SHELL_execute flags ignored: 0x00000100 > fixme:exec:SHELL_execute flags ignored: 0x00000100 > fixme:exec:SHELL_execute flags ignored: 0x00000100 > Application tried to create a window, but no driver could be loaded. > Make sure that your X server is running and that $DISPLAY is set correctly. > Application tried to create a window, but no driver could be loaded. > Make sure that your X server is running and that $DISPLAY is set correctly. > shlexec.c:1767: Test failed: ShellExecuteEx(null, "C:\users\bob\Temp\wt1ff9.tmp\test file.sde", null, null) failed: rc=30 err=32 > fixme:exec:SHELL_execute flags ignored: 0x00000100 > shlexec.c:1767: Test failed: ShellExecuteEx(null, "C:\users\bob\Temp\wt1ff9.tmp\test file.sde", null, null) failed: rc=30 err=0 > fixme:exec:SHELL_execute flags ignored: 0x00000100 > shlexec.c:1767: Test failed: ShellExecuteEx(null, "C:\users\bob\Temp\wt1ff9.tmp\test file.sde", null, null) failed: rc=30 err=32 > fixme:exec:SHELL_execute flags ignored: 0x00000100 > shlexec.c:1767: Test failed: ShellExecuteEx(null, "C:\users\bob\Temp\wt1ff9.tmp\test file.sde", null, null) failed: rc=30 err=0 > fixme:exec:SHELL_execute flags ignored: 0x00000100 > shlexec.c:1767: Test failed: ShellExecuteEx(null, "C:\users\bob\Temp\wt1ff9.tmp\test file.sde", null, null) failed: rc=30 err=32 > fixme:exec:SHELL_execute flags ignored: 0x00000100 > shlexec.c:1767: Test failed: ShellExecuteEx(null, "C:\users\bob\Temp\wt1ff9.tmp\test file.sde", null, null) failed: rc=30 err=0 > fixme:exec:SHELL_execute flags ignored: 0x00000100 > shlexec.c:1946: Tests skipped: Default DDE application test does not match any available results, using first expected data set. > shlexec.c:1951: Test failed: ShellExecuteEx(null, "C:\users\bob\Temp\wt1ff9.tmp\test file.sde", null, null) failed: rc=11 err=87 > fixme:exec:SHELL_execute flags ignored: 0x00000100 > shlexec.c:1951: Test failed: ShellExecuteEx(null, "C:\users\bob\Temp\wt1ff9.tmp\test file.sde", null, null) failed: rc=11 err=87 > fixme:exec:SHELL_execute flags ignored: 0x00000100 > shlexec.c:1951: Test failed: ShellExecuteEx(null, "C:\users\bob\Temp\wt1ff9.tmp\test file.sde", null, null) failed: rc=11 err=87 > fixme:exec:SHELL_execute flags ignored: 0x00000100 > shlexec.c:1951: Test failed: ShellExecuteEx(null, "C:\users\bob\Temp\wt1ff9.tmp\test file.sde", null, null) failed: rc=11 err=87 > fixme:exec:SHELL_execute flags ignored: 0x00000100 > shlexec.c:1951: Test failed: ShellExecuteEx(null, "C:\users\bob\Temp\wt1ff9.tmp\test file.sde", null, null) failed: rc=11 err=87 > fixme:exec:SHELL_execute flags ignored: 0x00000100 > shlexec.c:1951: Test failed: ShellExecuteEx(null, "C:\users\bob\Temp\wt1ff9.tmp\test file.sde", null, null) failed: rc=11 err=87 > fixme:exec:SHELL_execute flags ignored: 0x00000100 > err:exec:dde_connect Unable to find application path for command L"\"C:\\users\\bob\\Temp\\wt1ff9.tmp\\test2 file.exe\"" > fixme:exec:SHELL_execute flags ignored: 0x00000100 > err:exec:dde_connect Unable to find application path for command L"\"C:\\users\\bob\\Temp\\wt1ff9.tmp\\test2 file.exe\" param" > fixme:exec:SHELL_execute flags ignored: 0x00000100 > shlexec.c:1951: Test failed: ShellExecuteEx(null, "C:\users\bob\Temp\wt1ff9.tmp\test file.sde", null, null) failed: rc=11 err=87 > fixme:exec:SHELL_execute flags ignored: 0x00000100 > shlexec.c:1951: Test failed: ShellExecuteEx(null, "C:\users\bob\Temp\wt1ff9.tmp\test file.sde", null, null) failed: rc=11 err=87 > fixme:exec:SHELL_execute flags ignored: 0x00000100 > err:exec:dde_connect Unable to find application path for command L"C:\\users\\bob\\Temp\\wt1ff9.tmp\\notexist.exe" > fixme:exec:SHELL_execute flags ignored: 0x00000100 > err:exec:dde_connect Unable to find application path for command L"C:\\users\\bob\\Temp\\wt1ff9.tmp\\notexist.exe param" > fixme:exec:SHELL_execute flags ignored: 0x00000100 > shlexec.c:1951: Test failed: ShellExecuteEx(null, "C:\users\bob\Temp\wt1ff9.tmp\test file.sde", null, null) failed: rc=30 err=87 > fixme:exec:SHELL_execute flags ignored: 0x00000100 > shlexec.c:1951: Test failed: ShellExecuteEx(null, "C:\users\bob\Temp\wt1ff9.tmp\test file.sde", null, null) failed: rc=30 err=87 > fixme:exec:SHELL_execute flags ignored: 0x00000100 > err:exec:dde_connect Unable to find application path for command L"xyzwxyzwxyz" > fixme:exec:SHELL_execute flags ignored: 0x00000100 > err:exec:dde_connect Unable to find application path for command L"xyzwxyzwxyz param" > CMD Version 1.3.29 > > Z:\home\bob\wineslave.dir\sandbox\slave\runtests-default\build\dlls\shell32\tests>CMD Version 1.3.29 > > Z:\home\bob\wineslave.dir\sandbox\slave\runtests-default\build\dlls\shell32\tests>alarum: elapsed time 96 seconds > make: *** [shlexec.ok] Error 16 > alarum: failed command was ../../../wine shell32_test.exe.so systray.c > systray.c:52: Test failed: NIM_DELETE failed! > systray.c:55: Test failed: The icon was not deleted > systray.c:66: Test failed: NIM_ADD failed! > systray.c:73: Test failed: NIM_DELETE failed! > systray.c:76: Test failed: The icon was not deleted > fixme:event:wait_for_withdrawn_state window 0x160076/c00001 wait timed out > make: *** [systray.ok] Error 5 > ALSA lib conf.c:4154:(_snd_config_evaluate) function snd_func_card_driver returned error: No such file or directory > ALSA lib conf.c:4154:(_snd_config_evaluate) function snd_func_concat returned error: No such file or directory > ALSA lib conf.c:4154:(_snd_config_evaluate) function snd_func_refer returned error: No such file or directory > ALSA lib conf.c:4633:(snd_config_expand) Evaluate error: No such file or directory > ALSA lib conf.c:4154:(_snd_config_evaluate) function snd_func_card_driver returned error: No such file or directory > ALSA lib conf.c:4154:(_snd_config_evaluate) function snd_func_concat returned error: No such file or directory > ALSA lib conf.c:4154:(_snd_config_evaluate) function snd_func_refer returned error: No such file or directory > ALSA lib conf.c:4633:(snd_config_expand) Evaluate error: No such file or directory > > _______________________________________________ > wine-tests-results mailing list > wine-tests-results(a)winehq.org > http://www.winehq.org/mailman/listinfo/wine-tests-results

Oct. 8, 2011

Re: inetmib1: Avoid idempotent operation in findSupportedQuery function (Clang)

by Alexandre Julliard

Frédéric Delanoy <frederic.delanoy(a)gmail.com> writes: > indexLow is always 0 at that point This makes it harder to understand what the code is doing here. Probably needs some restructuring. -- Alexandre Julliard julliard(a)winehq.org

Oct. 8, 2011

Re: jscript: Mark some fall-throughs in switch statements

by Alexandre Julliard

Andrew Talbot <andrew.talbot(a)talbotville.com> writes: > @@ -4037,6 +4037,7 @@ static HRESULT RegExpConstr_leftContext(script_ctx_t *ctx, vdisp_t *jsthis, WORD > > V_VT(retv) = VT_BSTR; > V_BSTR(retv) = ret; > + /* fall through */ > } > case DISPATCH_PROPERTYPUT: > return S_OK; I don't think that PROPERTYGET is supposed to fall through to PROPERTYPUT. -- Alexandre Julliard julliard(a)winehq.org

Oct. 8, 2011

Re: [PATCH] server: Use syscall(2) instead of inline assembly on Mac OS, too.

by Alexandre Julliard

Charles Davis <cdavis(a)mymail.mines.edu> writes: > @@ -268,9 +256,9 @@ int send_thread_signal( struct thread *thread, int sig ) > if (!mach_port_extract_right( process_port, thread->unix_tid, > MACH_MSG_TYPE_COPY_SEND, &port, &type )) > { > - if ((ret = pthread_kill_syscall( port, sig )) < 0) > + if ((ret = syscall( SYS___pthread_kill, port, sig )) != 0) > { > - errno = -ret; > + errno = ret; syscall is supposed to take care of errno. -- Alexandre Julliard julliard(a)winehq.org

Oct. 8, 2011

re: Governance of Wine with respect to the Software Freedom Conservancy (update October 2011)

by Dan Kegel

The real way to mount a revolt, of course, would be to fork wine and maintain a better version of it. The likelihood of that ever happening seems slim, but perhaps in 15 years, after HTML 5 takes over and users no longer run win32 apps, it's possible that something like that would happen naturally (say, some computer museum might become the maintainer).

Oct. 8, 2011

Re: mpr: Remove DllCanUnloadNow and DllGetClassObject

by André Hentschel

Am 08.10.2011 12:13, schrieb Alistair Leslie-Hughes: > Hi, > The native mpr.DLL doesn't have these functions. > > > Changelog: > mpr: Remove DllCanUnloadNow and DllGetClassObject > > > Best Regards > Alistair Leslie-Hughes > > no patch? -- Best Regards, André Hentschel

Oct. 8, 2011

Re: user32: Add support for iPaddedBorderWidth in NONCLIENTMETRICS structure.

by Marvin

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

Oct. 8, 2011

Re: [PATCH] server: if a debugger is attached to a process, child processes shouldn't get debugged (resend)

by David Laight

On Fri, Oct 07, 2011 at 08:32:27PM +0200, Marcus Meissner wrote: > On Fri, Oct 07, 2011 at 11:44:24AM +0900, Dmitry Timoshkov wrote: > > Bernhard Loos <bernhardloos(a)googlemail.com> wrote: > > > > > + int debug_childs:1; /* also debug all child processes */ > > > > 'debug_children' would be a better name. > > also > unsigned int foo:1; > please. (int foo:1 works, but is semidefined only ;) Why the bitfield anyway? Unless you are allocating a lot of copies of the structure it is likely to generate more code than the saved memory. David -- David Laight: david(a)l8s.co.uk

Oct. 8, 2011

Re: [PATCH] server: Use syscall(2) instead of inline assembly on Mac OS; too.

by Charles Davis

On Oct 7, 2011, at 1:50 PM, Dan Kegel wrote: > Probably a spurious failure Yeah... especially considering that: - That change only affects Mac OS X, and I haven't added my buildslave yet ;). (That file shouldn't even get built on non-Darwin.) - Wine won't even build 64-bit on Mac OS yet (and might never). Chip > - I was running rpcrt4 tests on > that machine, and they may both have wanted the same port number. > Shame on me. > > On Fri, Oct 7, 2011 at 12:48 PM, Dan Kegel <dank(a)kegel.com> wrote: >> Fails tests on x86_64? >> >> On Fri, Oct 7, 2011 at 11:52 AM, <buildbot(a)kegel.com> wrote: >>> This is an experimental automated build and test service. >>> Please feel free to ignore this email while we work the kinks out. >>> >>> For more info about this message, see http://wiki.winehq.org/BuildBot >>> >>> The Buildbot has detected a failed build on builder runtests-default-x86_64 while building Wine. >>> Full details are available at: http://buildbot.kegel.com/builders/runtests-default-x86_64/builds/35 (though maybe not for long, as I'm still reinstalling the buildbot periodically while experimenting) >>> BUILD FAILED: failed shell_3 >>> >>> Errors: >>> alarum: failed command was ../../../wine rpcrt4_test.exe.so rpc.c >>> fixme:rpc:RpcNetworkIsProtseqValidW Unknown protseq L"foo" >>> err:rpc:rpcrt4_protseq_ncacn_ip_tcp_open_endpoint couldn't listen on port 4114 >>> rpc.c:238: Test failed: RpcServerUseProtseqEp failed (1740) >>> fixme:rpc:RpcBindingInqAuthInfoExW authorization service not implemented >>> make: *** [rpc.ok] Error 1 >>> >>> >>

Oct. 7, 2011

Solved: Problems with drawing text in 1.3.29

by Damian Dixon

I have narrowed the issue down to a difference in behaviour between Windows and Wine. The problem boils down to the following code: NONCLIENTMETRICS ncm; memset(&ncm, 0, sizeof(NONCLIENTMETRICS)); ncm.cbSize = sizeof(NONCLIENTMETRICS); VERIFY(SystemParametersInfo(SPI_GETNONCLIENTMETRICS, sizeof(NONCLIENTMETRICS), &ncm, 0)); I used the font's returned from this call for drawing text and this caused the crash. The problem is that I upgraded to VS2010 and changed the target to WINVER=0x600. This means that I needed to change my code to the following. NONCLIENTMETRICS ncm; memset(&ncm, 0, sizeof(NONCLIENTMETRICS)); ncm.cbSize = sizeof(NONCLIENTMETRICS); #if(WINVER >= 0x0600) OSVERSIONINFO osvi; memset(&osvi,0,sizeof(osvi)); osvi.dwOSVersionInfoSize = sizeof(osvi); GetVersionEx(&osvi); if (osvi.dwMajorVersion < 6) ncm.cbSize -= sizeof(ncm.iPaddedBorderWidth); #endif VERIFY(SystemParametersInfo(SPI_GETNONCLIENTMETRICS, sizeof(NONCLIENTMETRICS), &ncm, 0)); Note: On windows my application does not actually crash or stop working with my original code and the text is displayed at a size I would kind of expect it to be. I will raise a bug for this one... as a difference in behaviour. On 7 October 2011 08:50, Damian Dixon <damian.dixon(a)gmail.com> wrote: > Thanks for the suggestions. > > I've narrowed one of the issues down to WineEngGetGlyphOutline > in dlls/gdi32/freetype.c. > > The pitch is 6640 and the height is 53003. This means that a buffer of > ~335Mb has been allocated and then memset. > > This is where the slow down is occurring (because of the memset). I suspect > the resultant crash is also because of this. > > I would suggest that limits need to be placed on the maximum pitch and > height. > > > I do not however believe that this is the root cause just one of the > symptoms. > > > > On 5 October 2011 18:37, Marcus Meissner <marcus(a)jet.franken.de> wrote: > >> On Wed, Oct 05, 2011 at 04:53:18PM +0100, Damian Dixon wrote: >> > Hi, >> > >> > I was attempting to use Wine 1.3.29 (in OpenSUSE 11.4 x86) and because >> of >> > issues pulled the source from git last night and still have problems. >> > >> > I am having performance issues with DrawText (5 odd seconds to draw a >> simple >> > string) and the occasional X Error and crash. >> > >> > The X Error is consistent and is as follows: >> > >> > fixme:advapi:SetSecurityInfo stub >> > X Error of failed request: BadLength (poly request too large or >> internal >> > Xlib length error) >> > Major opcode of failed request: 151 (RENDER) >> > Minor opcode of failed request: 17 (RenderCreateGlyphSet) >> > Serial number of failed request: 41091 >> > Current serial number in output stream: 41571 >> > Process of pid=0023 has terminated >> > >> > >> > The crash less consistent but is dependent upon the amount of text I >> attempt >> > to draw. >> > >> > The last version I know this worked in was 1.1.39. >> > >> > I've a few things to still try out before I attempt to create an RBT. >> >> To get a backtrace and be able to dump some datastructures, run with >> >> WINEDEBUG=+synchronous wine foo.exe >> >> This will bring it into the debugger once the condition happens. >> >> CIao, MArcus >> > >

Oct. 7, 2011

Re: [PATCH] server: Use syscall(2) instead of inline assembly on Mac OS; too.

by Dan Kegel

Probably a spurious failure - I was running rpcrt4 tests on that machine, and they may both have wanted the same port number. Shame on me. On Fri, Oct 7, 2011 at 12:48 PM, Dan Kegel <dank(a)kegel.com> wrote: > Fails tests on x86_64? > > On Fri, Oct 7, 2011 at 11:52 AM, <buildbot(a)kegel.com> wrote: >> This is an experimental automated build and test service. >> Please feel free to ignore this email while we work the kinks out. >> >> For more info about this message, see http://wiki.winehq.org/BuildBot >> >> The Buildbot has detected a failed build on builder runtests-default-x86_64 while building Wine. >> Full details are available at: http://buildbot.kegel.com/builders/runtests-default-x86_64/builds/35 (though maybe not for long, as I'm still reinstalling the buildbot periodically while experimenting) >> BUILD FAILED: failed shell_3 >> >> Errors: >> alarum: failed command was ../../../wine rpcrt4_test.exe.so rpc.c >> fixme:rpc:RpcNetworkIsProtseqValidW Unknown protseq L"foo" >> err:rpc:rpcrt4_protseq_ncacn_ip_tcp_open_endpoint couldn't listen on port 4114 >> rpc.c:238: Test failed: RpcServerUseProtseqEp failed (1740) >> fixme:rpc:RpcBindingInqAuthInfoExW authorization service not implemented >> make: *** [rpc.ok] Error 1 >> >> >

Oct. 7, 2011

Re: Governance of Wine with respect to the Software Freedom Conservancy (update October 2011)

by Juan Lang

> As I said, our overlords are kind and benevolent and I'm sure that the > mention of "evil plans" was simply a joke as such wise and noble > developers could need harbor a malevolent thought. But, unless I've > been misreading this mailing list, all patches have to go through our > current enlightened leader before becoming part of the patch count in > the wine tree. Not that the powers that be are susceptible to > temptation, but lesser mortals might find that being more selective > about whose patches are accepted during periods of discontent as an > easy way to influence such a vote. Likewise, even if such a mortal > didn't give into temptation, if the usurpers lose the vote they could > always claim such impropriety did take place. My point is that the math isn't in your argument's favor. It would take a long period of rejection by the current overlords before being able to squelch any hypothetical usurpers, given that a) the current overlords' contributions consist of Alexandre's, and b) he does not constitute a controlling majority of contributions, nor anywhere close to it. --Juan

Oct. 7, 2011

Re: [PATCH] server: Use syscall(2) instead of inline assembly on Mac OS; too.

by Dan Kegel

Fails tests on x86_64? On Fri, Oct 7, 2011 at 11:52 AM, <buildbot(a)kegel.com> wrote: > This is an experimental automated build and test service. > Please feel free to ignore this email while we work the kinks out. > > For more info about this message, see http://wiki.winehq.org/BuildBot > > The Buildbot has detected a failed build on builder runtests-default-x86_64 while building Wine. > Full details are available at: http://buildbot.kegel.com/builders/runtests-default-x86_64/builds/35 (though maybe not for long, as I'm still reinstalling the buildbot periodically while experimenting) > BUILD FAILED: failed shell_3 > > Errors: > alarum: failed command was ../../../wine rpcrt4_test.exe.so rpc.c > fixme:rpc:RpcNetworkIsProtseqValidW Unknown protseq L"foo" > err:rpc:rpcrt4_protseq_ncacn_ip_tcp_open_endpoint couldn't listen on port 4114 > rpc.c:238: Test failed: RpcServerUseProtseqEp failed (1740) > fixme:rpc:RpcBindingInqAuthInfoExW authorization service not implemented > make: *** [rpc.ok] Error 1 > >

Oct. 7, 2011

Re: [PATCH] server: if a debugger is attached to a process, child processes shouldn't get debugged (resend)

by Marcus Meissner

On Fri, Oct 07, 2011 at 11:44:24AM +0900, Dmitry Timoshkov wrote: > Bernhard Loos <bernhardloos(a)googlemail.com> wrote: > > > + int debug_childs:1; /* also debug all child processes */ > > 'debug_children' would be a better name. also unsigned int foo:1; please. (int foo:1 works, but is semidefined only ;) Ciao, Marcus

Oct. 7, 2011

Re: Governance of Wine with respect to the Software Freedom Conservancy (update October 2011)

by Michael Curran

On Fri, Oct 7, 2011 at 1:27 PM, Juan Lang <juan.lang(a)gmail.com> wrote: > Hi Michael, > >> Not that I have any problems with our benevolent overlords, and not >> that I would likely achieve franchise with a scant 2 patches under my >> belt, but I can't help wondering how such a revolt would succeed >> seeing as the only method to achieve franchise-hood is controlled by >> the same people one would be revolting against. > > You are new around here, we bottom-post ;) > > Not true, of course. Alexandre is at the top of the list of > contributors, naturally, but he doesn't constitute a controlling > majority. (I'm discounting Jeremy's contributions, which is correct > within tolerable error <snarky grin>.) > --Juan > My bad, gmail makes it easy to make that mistake. ;) As I said, our overlords are kind and benevolent and I'm sure that the mention of "evil plans" was simply a joke as such wise and noble developers could need harbor a malevolent thought. But, unless I've been misreading this mailing list, all patches have to go through our current enlightened leader before becoming part of the patch count in the wine tree. Not that the powers that be are susceptible to temptation, but lesser mortals might find that being more selective about whose patches are accepted during periods of discontent as an easy way to influence such a vote. Likewise, even if such a mortal didn't give into temptation, if the usurpers lose the vote they could always claim such impropriety did take place. I only bring it up because tempers tend to run pretty hot over topics like ousting a project's leadership in open revolt and the last thing you want is the losing side posting ream after ream of git commit logs trying to show to that several of their supporters should have received franchise, but their patches were blocked to prevent it. Rules like that should be designed to end a conflict with creating new sources of it. .

Oct. 7, 2011

Re: Governance of Wine with respect to the Software Freedom Conservancy (update October 2011)

by Juan Lang

Hi Michael, > Not that I have any problems with our benevolent overlords, and not > that I would likely achieve franchise with a scant 2 patches under my > belt, but I can't help wondering how such a revolt would succeed > seeing as the only method to achieve franchise-hood is controlled by > the same people one would be revolting against. You are new around here, we bottom-post ;) Not true, of course. Alexandre is at the top of the list of contributors, naturally, but he doesn't constitute a controlling majority. (I'm discounting Jeremy's contributions, which is correct within tolerable error <snarky grin>.) --Juan

Oct. 7, 2011

Re: Governance of Wine with respect to the Software Freedom Conservancy (update October 2011)

by Michael Curran

Not that I have any problems with our benevolent overlords, and not that I would likely achieve franchise with a scant 2 patches under my belt, but I can't help wondering how such a revolt would succeed seeing as the only method to achieve franchise-hood is controlled by the same people one would be revolting against. On Thu, Oct 6, 2011 at 4:30 PM, Jeremy White <jwhite(a)codeweavers.com> wrote: > Hi Folks, > > I try to send out a periodic message to the wine-devel mailing list > outlining the 'corporate' structure of Wine and how some decisions are made. > > We work with the Software Freedom Conservancy. They manage the pieces > of Wine that benefit from a formal organization, such as managing money, > holding Trademarks, and so on. > > The primary activity we have conducted with them over the past several > years is managing money - about $3,000 each year. They manage all funds > donated to Wine - the donate button goes into a bank account they manage > and any larger private donations go there as well. > > For decisions on how to spend funds, we've adopted a loose set of > guidelines. That is, we have a decision group and we require a majority > of members to approve any spending. Alexandre and I are the current > members of that group. We also claim the right to appoint anyone else > to replace or augment the decision group. > > We CC all decisions to an auditor. We have recently asked Michael > Stefanuic to replace Zachary Goldberg in that role. A critical > requirement, we feel, is that a non CodeWeavers staff member be fully > aware of all decisions made. > > We choose this strategy rather than a fully public process so that we > can apply discretion and protect privacy of people that ask for help > with travel funding. > > The SFC will recognize a 'revolt' by the Wine project. That is, the > designated decision group can be overthrown, once you figure out our > evil plans, if the SFC is persuaded that the majority of Wine > contributors agree on that point. Patch count in the Wine tree will be > the primary mechanism to recognize a contributor. > > Finally, all spending by the SFC on Wine's behalf for the last few years > has been related to Wineconf. That has primarily been to help > defray travel costs for Wine contributors to come to Wineconf. > > Wine's income has been around $3,000 / year for the past few years; we > tend to spend down much of the balance each year for Wineconf. > > Cheers, > > Jeremy > > p.s. One note - the SFC also manages the GSOC payments, although I > believe that they ostensibly manage that on behalf of Google, not really > Wine. That is generally coordinated by Wine's GSOC coordinator, and > Alexandre and I have nothing to do with it. > > >

Oct. 7, 2011

Re: Wine Gecko 1.4-beta1

by Jerome Leclanche

Nevermind, apparently the patch was too large and got corrupt. It's fine when downloaded off gmail. J On Fri, Oct 7, 2011 at 5:35 PM, Jacek Caban <jacek(a)codeweavers.com> wrote: > On 10/7/11 3:57 AM, Jerome Leclanche wrote: >> >> I'm unable to apply the patch: >> patching file dlls/appwiz.cpl/addons.c >> patching file dlls/mshtml/editor.c >> patching file dlls/mshtml/htmldoc.c >> patching file dlls/mshtml/htmldoc3.c >> patching file dlls/mshtml/htmldoc5.c >> patching file dlls/mshtml/htmlimg.c >> patching file dlls/mshtml/htmlwindow.c >> patching file dlls/mshtml/nsevents.c >> patching file dlls/mshtml/nsiface.idl >> Hunk #1 FAILED at 16. >> 1 out of 47 hunks FAILED -- saving rejects to file >> dlls/mshtml/nsiface.idl.rej >> patching file dlls/mshtml/nsio.c >> patch unexpectedly ends in middle of line >> Hunk #2 succeeded at 2579 with fuzz 1. > > I've retested and it works fine here. Are you using current Wine Git > version? Which part of nsiface.idl conflict (look at the content of > dlls/mshtml/nsiface.idl.rej file)? > > Jacek >

Oct. 7, 2011

Re: Wine Gecko 1.4-beta1

by Jacek Caban

On 10/7/11 3:57 AM, Jerome Leclanche wrote: > I'm unable to apply the patch: > patching file dlls/appwiz.cpl/addons.c > patching file dlls/mshtml/editor.c > patching file dlls/mshtml/htmldoc.c > patching file dlls/mshtml/htmldoc3.c > patching file dlls/mshtml/htmldoc5.c > patching file dlls/mshtml/htmlimg.c > patching file dlls/mshtml/htmlwindow.c > patching file dlls/mshtml/nsevents.c > patching file dlls/mshtml/nsiface.idl > Hunk #1 FAILED at 16. > 1 out of 47 hunks FAILED -- saving rejects to file dlls/mshtml/nsiface.idl.rej > patching file dlls/mshtml/nsio.c > patch unexpectedly ends in middle of line > Hunk #2 succeeded at 2579 with fuzz 1. I've retested and it works fine here. Are you using current Wine Git version? Which part of nsiface.idl conflict (look at the content of dlls/mshtml/nsiface.idl.rej file)? Jacek

Oct. 7, 2011

Re: mshtml: Implement IHTMLDOMNode replaceChild

by Jacek Caban

Hi Alistair, On 10/7/11 4:50 AM, Alistair Leslie-Hughes wrote: > + HTMLDOMNode *nodeNew; > + HTMLDOMNode *nodeOld; Please use names consistent with the rest of the file. + if(NS_FAILED(nsres)) { + nsnode = nodeNew->nsnode; + } That seems questionable, why do you pretend to success on failure? Jacek

Oct. 7, 2011

Re: [2/5] urlmon: Improved MapUrlToZone{Ex2} and GetSecurityId support

by Jacek Caban

Hi Thomas, On 10/6/11 6:42 PM, Thomas Mullaly wrote: > --- > dlls/urlmon/sec_mgr.c | 41 +++++++++++++++++++++++++++++++++++++++-- > dlls/urlmon/tests/sec_mgr.c | 30 +++++++++++++++++++++++++++++- > 2 files changed, 68 insertions(+), 3 deletions(-) + if(hres == S_FALSE){ + DWORD scheme_type; + BOOL has_host; + + hres = IUri_GetScheme(uri,&scheme_type); + if(FAILED(hres)) { + SysFreeString(scheme); + return hres; + } + + hres = IUri_HasProperty(uri, Uri_PROPERTY_HOST,&has_host); + if(FAILED(hres)) { + SysFreeString(scheme); + return hres; + } + + /* Known hierarchical scheme types must have a host. If they don't Windows + * assigns URLZONE_INVALID to the zone. + */ + if((scheme_type != URL_SCHEME_UNKNOWN&& scheme_type != URL_SCHEME_FILE) +&& is_hierarchical_scheme(scheme_type)&& !has_host) { + *zone = URLZONE_INVALID; It looks like get_zone_from_domains would be more logical place for this. It already does GetScheme call and you could just handle differently GetHost returning empty host. if(FAILED(hres)) return hres == 0x80041001 ? E_INVALIDARG : hres; + else if(zone == URLZONE_INVALID) + return E_INVALIDARG; You don't need 'else' here since if the previous if expression is true, we return anyways. Jacek

Oct. 7, 2011

Re: todo_wine, broken() and a SW anti-pattern

by Juan Lang

Hi Joerg, > hr = IAudioClient_GetService(ac, &IID_IAudioStreamVolume, (void**)&out); > ok(hr == AUDCLNT_E_NOT_INITIALIZED, "... call returns %08x\n", hr); > todo_wine ok(broken(out != NULL), "GetService %08x &out pointer %p\n", hr, out); > > 1. broken() documents that I consider native's observable behaviour > broken because I judge it unsafe not to zero the out pointer in case > of failure. Furthermore, MSDN documents that it should be zeroed. > http://msdn.microsoft.com/en-us/library/windows/desktop/dd370873%28v=vs.85%… I think, philosophically, you're correct. On the other hand, Wine isn't meant to be a "philosophically correct" implementation of the Win32 API. And, the whole point of regression tests is that MSDN isn't to be trusted. So, while Microsoft says that the out pointer must be NULL on failure, both in this case and more generally for COM (specifically for QueryInterface), our guide has always been to trust what Microsoft does more than what it says. Our guideline for using broken() is to mark as broken the things that Microsoft has changed. Older implementations often had bugs that have subsequently been fixed, so we mark those as broken and conform to the newer behavior. On the other hand, if Windows has always had a specific behavior, than that behavior is, by definition, correct. broken() isn't appropriate in this case. Again, we must do as Microsoft does, not as it says. So I believe the correct behavior here is not to use broken(), irrespective of what MSDN says. A comment stating that MSDN is incorrect might be in order. --Juan

Oct. 7, 2011

todo_wine, broken() and a SW anti-pattern

by Joerg-Cyril.Hoehle＠t-systems.com

Hi, The question about how to use todo_wine and broken() comes up from time to time. Here's new light on it, as I'm suggesting in mmdevapi/tests/render.c: hr = IAudioClient_GetService(ac, &IID_IAudioStreamVolume, (void**)&out); ok(hr == AUDCLNT_E_NOT_INITIALIZED, "... call returns %08x\n", hr); todo_wine ok(broken(out != NULL), "GetService %08x &out pointer %p\n", hr, out); 1. broken() documents that I consider native's observable behaviour broken because I judge it unsafe not to zero the out pointer in case of failure. Furthermore, MSDN documents that it should be zeroed. http://msdn.microsoft.com/en-us/library/windows/desktop/dd370873%28v=vs.85%… 2. Not writing ok(broken(...) || <other condition>) allows to detect should MS ever change behaviour. Currently, neither Vista, w2k8 nor w7 implement the documented behavior. 3. By using todo_wine, I acknowledge that Wine should continue to disagree with native's behavior and safely reset the out pointer. I mentioned "wine_dont" in http://www.winehq.org/pipermail/wine-devel/2011-August/091764.html That's not "100% bug compatible", but there's a small chance that it helps apps *not* crash in Wine when Wine's GetService returns E_NOTIMPL or some such that might never occur in native, hence the app is not prepared for it. More generally, a function with both a return code and an out pointer is often misused. Typically, the specification says: "The out pointer is only set when the return code indicates success". But actually, many program(mer)s use: "The pointer is non-NULL if and only if the return code indicates success." Here's an example of broken code that follows: /* When FAILED(hr), it is *not* the case that out == NULL. * Hence the anti-pattern: */ hr = GetService(..., &out); if (SUCCEEDED(hr)) { ... if (!...) goto exit; ... } exit: if (out) { Release(out); } /* bogus */ I once found such a case in Wine but I forgot where... (not just in mmdevapi/tests/render.c which after all is "only" test code) Michael, a challenge for your static analysis tools? Bogus too: set out = NULL prior to calling the function, because you don't know whether the function may write something initially, only to bail out later with an error code such as OUTOFMEMORY. Regards, Jörg Höhle

Oct. 7, 2011

mmdevapi/tests: Add format tests.

by Joerg-Cyril.Hoehle＠t-systems.com

Hi, Andrew Eikum wrote: > + todo_wine ok(broken(unk != NULL), ... I'll comment on that separately. >> +static void test_formats(AUDCLNT_SHAREMODE mode) >The code in this function is very difficult to follow. Indeed, it became more and more convoluted as I dug into native's "exclusive mode disabled" and other exceptions to the rule. And it's not even handling 5:1 cards correctly! Luckily, I needn't add todo_wine on top of that... For instance, winmm:wave.ok is so convoluted that one cannot tell any more what it actually checks. I'll think about a different approach with better expressiveness. For now, I consider it's time to get more tests into git and to gather results on test.winehq.org. >> + ok((hr == S_FALSE)^(pwfx2 == NULL), "hr %x<->suggest %p\n", hr, pwfx2); >> + if (pwfx2 == (WAVEFORMATEX*)0xDEADF00D) /* bug in Wine */ >Would be nicer to both fix the bug in Wine and have a test showing the correct behavior. That is the correct behavior AFAICT: S_FALSE <=> set pwfx2 I've not yet submitted all of my patches about IsFormatSupported but you're right, that's an easy patch away. I forgot that one. For sure 5:1 needs more testing and I have no such HW. You have. >> + win_skip("mmdevapi not available: 0x%08x\n", hr); >I think that's valid behavior, so we shouldn't fail. Ouch. I thought "Wine has dlls/mmdevapi, so it should always load", but test.winehq.org shows that Solaris doesn't appear to have mmdevapi. Why? Regards, Jörg Höhle

Oct. 7, 2011

The major mmdevapi and winmm audio bugs

by Joerg-Cyril.Hoehle＠t-systems.com

Hi, Bugzilla admins, please set the 1.4 milestone on all bugs mentioned here. I'm not yet looking at dsound issues since I first want a correct foundation upon which to build to upper layers. o #28039 IAudioClock_GetPosition must ignore underruns (MacOS) Here I've no idea how to solve this. My initial query remained unanswered: http://lists.apple.com/archives/coreaudio-api//2011/Sep/msg00024.html Ken? Andrew's yesterday patch (using GetCurrentPadding) is an interim work-around. GetPosition (speaker) is unrelated to padding which is solely about buffering. o #28093 GetCurrentPadding must slowly decrease (MacOS) may cause an app to play audio using a single buffer, causing underruns and audio drop outs. o #28056 Problems with sound under FreeBSD which became "blocking calls with OSS" recently addressed by Andrew. o snd_pcm_drop causes incorrect GetPosition after mmdevapi Stop which I believe to be the cause of: #27901 winmm tests timing out waiting for hevent after waveOutRestart May get solved by Andrew's work in: #28517 Pikachu Volleyball stops playing sound effects Every snd_pcm_drop and reset must be inspected with care w.r.t. its effect on GetPosition. Wine must ensure that after playing ends, GetPosition == sum of written samples for both mmdevapi and winmm. o #27937 winmm kept busy playing silence after play finishes IIRC because winmm writes silence. Once mmdevapi handles underruns correctly, my patch "winmm: Never write silence, mmdevapi must handle underruns." will become applicable: http://www.winehq.org/pipermail/wine-patches/2011-September/107108.html Playing silence causes: #28027 μ-law rendering with pauses and repetitions (MacOS) as well as presumably: #28413 Sound play in games and programs causes brief "pauses" at the time dsound used winmm prior to 1.3.29. o #28047 IAudioClock_GetPosition must not depend on buffering (ALSA/Pulse) ALSA must derive GetPosition from snd_pcm_delay, not snd_pcm_avail_update There are other issues not associated with a bug entry. I'm off for vacation, but here's a snippet from my TODO list: - OSS GetPosition from DSP_GETODELAY - ALSA+OSS: ReleaseBuffer: check method ordering and max size - GetStreamLatency = Xms + SHAREDMODE:period Stream latency is a static property of the audio graph's components. - wineoss GetStreamLatency must be constant, and SNDCTL_DSP_GETODELAY is only usable once running - Check WHDR_BEGIN/ENDLOOP code and write tests - WINMM_GetPosition is simply written_frames, not even minus padding (as the old alsa driver did), later use mmdevapi:GetPosition. - winmm PushData without IAC_Reset or last_clock_pos=0 in case of underrun - Investigate OSS4 underrun behaviour - Align wineOSS on newest ALSA code improvements - Submit CoreAudio memory leak fix to #28023; Write error handling patch - Check ALSA laptop suspend w.r.t. GetPosition - Add run-time consistency checks in renderer and abort audio stream (GetData) upon trouble instead of hanging. and finally: - Test compatibility with native DSound and file bug if unusable. There are several reports in bugzilla mentioning that this work-around ceased to work since 1.3.25. Loss of interoperability is not acceptable. Regards, Jörg Höhle

Oct. 7, 2011

Re: mmdevapi/tests: Add format tests.

by Andrew Eikum

Hi J�rg, Thanks for adding these tests. It would have been nicer to split the patch up into discrete chunks. That would make the patch much easier to review. Overall it looks pretty good. Some remarks follow... > BTW, I've not touched > render.c:223: Test failed: IsFormatSupported(0xffffffff) call returns 8889000e > capture.ok has a similar random failure. I believe that test is bogus. It > should avoid ending up calling the exclusive mode "audio endpoint" and hope/show > that the shared mode mixer aka. "audio engine" reports E_INVALIDARG. Perhaps > using ~AUDCLNT_SHAREMODE_EXCLUSIVE is a means to enforce this, even though > that's actually an enum, not a flag. Yeah, that's a pretty uninteresting test. If it's flaky, I don't see any compelling reason to keep it around. > + unk = (void*)0xDEADF00D; > hr = IAudioClient_GetService(ac, &IID_IAudioStreamVolume, (void**)&unk); > ok(hr == AUDCLNT_E_NOT_INITIALIZED, "Uninitialized GetService call returns %08x\n", hr); > + todo_wine ok(broken(unk != NULL), "GetService %08x &out pointer %p\n", hr, unk); This test is strange. broken() basically means "should fail on Windows, should not fail in Wine." It's used when some particular version of Windows does something unexpected which we are uninterested in duplicating. Do you expect unk to always be non-NULL? If so, then just test for that without the broken() macro. > > +static void test_formats(AUDCLNT_SHAREMODE mode) The code in this function is very difficult to follow. I wonder if it couldn't be written more clearly with explicit conditions and a bit more code duplication. > + ok((hr == S_FALSE)^(pwfx2 == NULL), "hr %x<->suggest %p\n", hr, pwfx2); > + if (pwfx2 == (WAVEFORMATEX*)0xDEADF00D) /* bug in Wine */ > + pwfx2 = NULL; Would be nicer to both fix the bug in Wine and have a test showing the correct behavior. > @@ -1378,7 +1535,7 @@ START_TEST(render) > hr = CoCreateInstance(&CLSID_MMDeviceEnumerator, NULL, CLSCTX_INPROC_SERVER, &IID_IMMDeviceEnumerator, (void**)&mme); > if (FAILED(hr)) > { > - skip("mmdevapi not available: 0x%08x\n", hr); > + win_skip("mmdevapi not available: 0x%08x\n", hr); If the user has an invalid driver, CoCreateInstance() will fail to create the enumerator object. I think that's valid behavior, so we shouldn't fail. Andrew

Oct. 7, 2011

Re: DLLCanUnloadNow Question

by Paul Chitescu

On Friday 07 October 2011 11:50:17 am Alistair Leslie-Hughes wrote: > Hi, > > The Following sample code causes a crash under WINE, but not in windows. > > IUnknown *p > > LoadLibrary("mscoree.dll") > GetProcAddress("CreateDebuggingInterfaceFromVersion") > CreateDebuggingInterfaceFromVersion(..., (void**)&p) <-- Com Reference > > FreeLibrary("mscoree.dll") > > p->QueryInterface(....); <-- Cause Crash under WINE. > > > The DLL shouldn't be unloaded since mscoree.DLLCanUnloadNow() return > S_FALSE; > > Is this a bug with the unloading of DLL's? Is there way to stop the > unloading of a DLL? > > I know the logic isn't the best, but I'm seeing this type of behavior in an > application. > > Best Regards > Alistair Leslie-Hughes Hi! It doesn't seem your test is correct. You are not supposed to use LoadLibrary directly but use COM methods that will call FreeLibrary internally when DLLCanUnloadNow returns true. The fact it doesn't crash on Windows is probably caused by mscoree.dll being kept loaded by some other components. I don't know, maybe on Windows mscoree is never unloaded - this can be verified easily. If there are actually programs that crash that way because they depend on the Windows behavior we can work around by making internally a LoadLibrary call when the first object is created and a FreeLibrary call after the last object is destroyed. Paul

Oct. 7, 2011

Re: Wine Gecko 1.4-beta1

by Jerome Leclanche

I'm unable to apply the patch: patching file dlls/appwiz.cpl/addons.c patching file dlls/mshtml/editor.c patching file dlls/mshtml/htmldoc.c patching file dlls/mshtml/htmldoc3.c patching file dlls/mshtml/htmldoc5.c patching file dlls/mshtml/htmlimg.c patching file dlls/mshtml/htmlwindow.c patching file dlls/mshtml/nsevents.c patching file dlls/mshtml/nsiface.idl Hunk #1 FAILED at 16. 1 out of 47 hunks FAILED -- saving rejects to file dlls/mshtml/nsiface.idl.rej patching file dlls/mshtml/nsio.c patch unexpectedly ends in middle of line Hunk #2 succeeded at 2579 with fuzz 1. On Thu, Oct 6, 2011 at 8:57 PM, Jacek Caban <jacek(a)codeweavers.com> wrote: > Hi all, > > I've just uploaded new Gecko builds [1]. To use it, you need the attached > patch and the build installed to the right place [2]. As usually, everything > that uses MSHTML is worth testing. All testing and feedback will be > appreciated. > > Thanks, > Jacek > > [1] http://sourceforge.net/projects/wine/files/Wine%20Gecko/1.4-beta1/ > [2] http://wiki.winehq.org/Gecko > > > >

Oct. 7, 2011

DLLCanUnloadNow Question

by Alistair Leslie-Hughes

Hi, The Following sample code causes a crash under WINE, but not in windows. IUnknown *p LoadLibrary("mscoree.dll") GetProcAddress("CreateDebuggingInterfaceFromVersion") CreateDebuggingInterfaceFromVersion(..., (void**)&p) <-- Com Reference FreeLibrary("mscoree.dll") p->QueryInterface(....); <-- Cause Crash under WINE. The DLL shouldn't be unloaded since mscoree.DLLCanUnloadNow() return S_FALSE; Is this a bug with the unloading of DLL's? Is there way to stop the unloading of a DLL? I know the logic isn't the best, but I'm seeing this type of behavior in an application. Best Regards Alistair Leslie-Hughes

Oct. 7, 2011

Re: Problems with drawing text in 1.3.29

by Damian Dixon

Thanks for the suggestions. I've narrowed one of the issues down to WineEngGetGlyphOutline in dlls/gdi32/freetype.c. The pitch is 6640 and the height is 53003. This means that a buffer of ~335Mb has been allocated and then memset. This is where the slow down is occurring (because of the memset). I suspect the resultant crash is also because of this. I would suggest that limits need to be placed on the maximum pitch and height. I do not however believe that this is the root cause just one of the symptoms. On 5 October 2011 18:37, Marcus Meissner <marcus(a)jet.franken.de> wrote: > On Wed, Oct 05, 2011 at 04:53:18PM +0100, Damian Dixon wrote: > > Hi, > > > > I was attempting to use Wine 1.3.29 (in OpenSUSE 11.4 x86) and because of > > issues pulled the source from git last night and still have problems. > > > > I am having performance issues with DrawText (5 odd seconds to draw a > simple > > string) and the occasional X Error and crash. > > > > The X Error is consistent and is as follows: > > > > fixme:advapi:SetSecurityInfo stub > > X Error of failed request: BadLength (poly request too large or internal > > Xlib length error) > > Major opcode of failed request: 151 (RENDER) > > Minor opcode of failed request: 17 (RenderCreateGlyphSet) > > Serial number of failed request: 41091 > > Current serial number in output stream: 41571 > > Process of pid=0023 has terminated > > > > > > The crash less consistent but is dependent upon the amount of text I > attempt > > to draw. > > > > The last version I know this worked in was 1.1.39. > > > > I've a few things to still try out before I attempt to create an RBT. > > To get a backtrace and be able to dump some datastructures, run with > > WINEDEBUG=+synchronous wine foo.exe > > This will bring it into the debugger once the condition happens. > > CIao, MArcus >

Oct. 7, 2011

Re: [PATCH] server: if a debugger is attached to a process, child processes shouldn't get debugged (resend)

by Dmitry Timoshkov

Bernhard Loos <bernhardloos(a)googlemail.com> wrote: > + int debug_childs:1; /* also debug all child processes */ 'debug_children' would be a better name. -- Dmitry.

Oct. 6, 2011

Re: [PATCH] winecoreaudio.drv: Reimplement IAudioClock::GetPosition()

by Alexandre Julliard

Andrew Eikum <aeikum(a)codeweavers.com> writes: > --- > dlls/winecoreaudio.drv/mmdevdrv.c | 27 +++++++++------------------ > 1 files changed, 9 insertions(+), 18 deletions(-) This fails for me: ../../../tools/runtest -q -P wine -M winmm.dll -T ../../.. -p winmm_test.exe.so wave.c && touch wave.ok wave.c:498: Test failed: waveOutGetPosition(0): returned 19845 bytes, should be 22050 wave.c:509: Test failed: waveOutGetPosition(0): returned 19845 samples (19845 bytes), should be 22050 (22050 bytes) wave.c:522: Test failed: waveOutGetPosition(0): returned 900 ms, (19845 bytes), should be 1000 (22050 bytes) wave.c:535: Test failed: waveOutGetPosition(0): SMPTE test failed wave.c:546: Test failed: waveOutGetPosition(0): MIDI test failed wave.c:557: Test failed: waveOutGetPosition(0): TICKS test failed wave.c:498: Test failed: waveOutGetPosition(0): returned 19845 bytes, should be 22050 wave.c:509: Test failed: waveOutGetPosition(0): returned 19845 samples (19845 bytes), should be 22050 (22050 bytes) wave.c:522: Test failed: waveOutGetPosition(0): returned 900 ms, (19845 bytes), should be 1000 (22050 bytes) wave.c:535: Test failed: waveOutGetPosition(0): SMPTE test failed wave.c:546: Test failed: waveOutGetPosition(0): MIDI test failed wave.c:557: Test failed: waveOutGetPosition(0): TICKS test failed wave.c:498: Test failed: waveOutGetPosition(WAVE_MAPPER): returned 19845 bytes, should be 22050 wave.c:509: Test failed: waveOutGetPosition(WAVE_MAPPER): returned 19845 samples (19845 bytes), should be 22050 (22050 bytes) wave.c:522: Test failed: waveOutGetPosition(WAVE_MAPPER): returned 900 ms, (19845 bytes), should be 1000 (22050 bytes) wave.c:535: Test failed: waveOutGetPosition(WAVE_MAPPER): SMPTE test failed wave.c:546: Test failed: waveOutGetPosition(WAVE_MAPPER): MIDI test failed wave.c:557: Test failed: waveOutGetPosition(WAVE_MAPPER): TICKS test failed wave.c:498: Test failed: waveOutGetPosition(WAVE_MAPPER): returned 19845 bytes, should be 22050 wave.c:509: Test failed: waveOutGetPosition(WAVE_MAPPER): returned 19845 samples (19845 bytes), should be 22050 (22050 bytes) wave.c:522: Test failed: waveOutGetPosition(WAVE_MAPPER): returned 900 ms, (19845 bytes), should be 1000 (22050 bytes) wave.c:535: Test failed: waveOutGetPosition(WAVE_MAPPER): SMPTE test failed wave.c:546: Test failed: waveOutGetPosition(WAVE_MAPPER): MIDI test failed wave.c:557: Test failed: waveOutGetPosition(WAVE_MAPPER): TICKS test failed make: *** [wave.ok] Error 24 -- Alexandre Julliard julliard(a)winehq.org

Oct. 6, 2011

Governance of Wine with respect to the Software Freedom Conservancy (update October 2011)

by Jeremy White

Hi Folks, I try to send out a periodic message to the wine-devel mailing list outlining the 'corporate' structure of Wine and how some decisions are made. We work with the Software Freedom Conservancy. They manage the pieces of Wine that benefit from a formal organization, such as managing money, holding Trademarks, and so on. The primary activity we have conducted with them over the past several years is managing money - about $3,000 each year. They manage all funds donated to Wine - the donate button goes into a bank account they manage and any larger private donations go there as well. For decisions on how to spend funds, we've adopted a loose set of guidelines. That is, we have a decision group and we require a majority of members to approve any spending. Alexandre and I are the current members of that group. We also claim the right to appoint anyone else to replace or augment the decision group. We CC all decisions to an auditor. We have recently asked Michael Stefanuic to replace Zachary Goldberg in that role. A critical requirement, we feel, is that a non CodeWeavers staff member be fully aware of all decisions made. We choose this strategy rather than a fully public process so that we can apply discretion and protect privacy of people that ask for help with travel funding. The SFC will recognize a 'revolt' by the Wine project. That is, the designated decision group can be overthrown, once you figure out our evil plans, if the SFC is persuaded that the majority of Wine contributors agree on that point. Patch count in the Wine tree will be the primary mechanism to recognize a contributor. Finally, all spending by the SFC on Wine's behalf for the last few years has been related to Wineconf. That has primarily been to help defray travel costs for Wine contributors to come to Wineconf. Wine's income has been around $3,000 / year for the past few years; we tend to spend down much of the balance each year for Wineconf. Cheers, Jeremy p.s. One note - the SFC also manages the GSOC payments, although I believe that they ostensibly manage that on behalf of Google, not really Wine. That is generally coordinated by Wine's GSOC coordinator, and Alexandre and I have nothing to do with it.

Oct. 6, 2011

Wine Gecko 1.4-beta1

by Jacek Caban

Hi all, I've just uploaded new Gecko builds [1]. To use it, you need the attached patch and the build installed to the right place [2]. As usually, everything that uses MSHTML is worth testing. All testing and feedback will be appreciated. Thanks, Jacek [1] http://sourceforge.net/projects/wine/files/Wine%20Gecko/1.4-beta1/ [2] http://wiki.winehq.org/Gecko

Oct. 6, 2011

Re: [patch] Fake display interface

by Jari Vetoniemi

Bleh, Forgot to include the updated patch. There we go! 2011/10/6 Jari Vetoniemi <mailroxas(a)gmail.com>: > Hello, > I have updated this to support multiple resolutions(&& frequencies) > and also made it use only one registry key. > If the registry key is empty, or does not exist, or WINE_FAKEDISP > environment variable is not defined it won't be used at all. > > Syntax is the same, expect you can separate multiple resolutions with > semicolon(;) > I've been using it for a while now, and find it really useful for > applications that might change resolution. > Also keeping both monitors alive (Game on other monitor for example, > while doing stuff on other). > And it can also make games use resolution that is normally unsupported. > > Here is screen of Ys Origins running 1440x900 where it normally does not: > http://ompldr.org/vYW91NA/YsOrigins.png > > Just let you know, if anyone else found the patch useful. > Cheers. > > 2011/9/6 Jari Vetoniemi <mailroxas(a)gmail.com>: >> Well, I did the patch mostly for personal use and dropped here as some >> might find it useful. >> If wine ever needs something like this, let's say for testing or for >> some people wanting to fake display information, or do not want to use >> XRandR or others for some reason, then it would at least need to >> support multiple resolutions I guess. >> >> ATM it only supports one, also it would be good to get rid of the >> useless registry keys and just provide one with same syntax as the >> environment variable one. Both should be easy to implement, I don't >> know where wine gets/sends the color depth information, so it could be >> faked too, but I'm not sure if it's worth it. >> >> But the patch should do the faking clean way, I guess. It's just >> another interface like the XRandR selector and such. >> >> As for, do we need it? I don't know. I need it :) >> Correct way to add it? See above, but I highly suspect this ever >> getting into mainline. It's not correct behavior and is quite niche >> patch. >> Does the patch look good? See above, registry keys could be cleaned >> and multiple resolutions separated with eg ';' letter would be nice. >> >> Also I'm not sure what is the take on defining environment variables. >> >> 2011/9/6 GOUJON Alexandre <ale.goujon(a)gmail.com>: >>> On 09/06/2011 02:25 PM, Jari Vetoniemi wrote: >>>> >>>> I have them both disabled, however then some applications won't work >>>> because they don't get any resolution information. >>>> I only use FakeDisp. >>> >>> IMO, there is a need and your patch is a solution (among other). >>> >>> Is there a relevant developer able to answer these questions ? >>> - Do we need this feature ? >>> - If so, what is the correct/clean way to add it into mainline ? >>> - Does the patch look good or what is wrong ? >>> >>> I know there is no [RFC] in the subject of this thread but you're definitely >>> requesting comments. >>> >>> >>> >> >

Oct. 6, 2011

Re: [patch] Fake display interface

by Jari Vetoniemi

Hello, I have updated this to support multiple resolutions(&& frequencies) and also made it use only one registry key. If the registry key is empty, or does not exist, or WINE_FAKEDISP environment variable is not defined it won't be used at all. Syntax is the same, expect you can separate multiple resolutions with semicolon(;) I've been using it for a while now, and find it really useful for applications that might change resolution. Also keeping both monitors alive (Game on other monitor for example, while doing stuff on other). And it can also make games use resolution that is normally unsupported. Here is screen of Ys Origins running 1440x900 where it normally does not: http://ompldr.org/vYW91NA/YsOrigins.png Just let you know, if anyone else found the patch useful. Cheers. 2011/9/6 Jari Vetoniemi <mailroxas(a)gmail.com>: > Well, I did the patch mostly for personal use and dropped here as some > might find it useful. > If wine ever needs something like this, let's say for testing or for > some people wanting to fake display information, or do not want to use > XRandR or others for some reason, then it would at least need to > support multiple resolutions I guess. > > ATM it only supports one, also it would be good to get rid of the > useless registry keys and just provide one with same syntax as the > environment variable one. Both should be easy to implement, I don't > know where wine gets/sends the color depth information, so it could be > faked too, but I'm not sure if it's worth it. > > But the patch should do the faking clean way, I guess. It's just > another interface like the XRandR selector and such. > > As for, do we need it? I don't know. I need it :) > Correct way to add it? See above, but I highly suspect this ever > getting into mainline. It's not correct behavior and is quite niche > patch. > Does the patch look good? See above, registry keys could be cleaned > and multiple resolutions separated with eg ';' letter would be nice. > > Also I'm not sure what is the take on defining environment variables. > > 2011/9/6 GOUJON Alexandre <ale.goujon(a)gmail.com>: >> On 09/06/2011 02:25 PM, Jari Vetoniemi wrote: >>> >>> I have them both disabled, however then some applications won't work >>> because they don't get any resolution information. >>> I only use FakeDisp. >> >> IMO, there is a need and your patch is a solution (among other). >> >> Is there a relevant developer able to answer these questions ? >> - Do we need this feature ? >> - If so, what is the correct/clean way to add it into mainline ? >> - Does the patch look good or what is wrong ? >> >> I know there is no [RFC] in the subject of this thread but you're definitely >> requesting comments. >> >> >> >

Oct. 6, 2011

WINMM_OpenDevice Activate failed

by GOUJON Alexandre

Hi Andrew, I saw you modified the Audio tab of winecfg to let the user choose a device. You're really doing a great job considering the mess behind it (audio architecture & drivers). I tested the latest wine and noticed that when you click the "Test Sound" button, there is no error but if you do it again (or several times), there is a err:winmm:WINMM_OpenDevice Activate failed: 80004005 on the console. Harmless but probably worth fixing.

Oct. 6, 2011

Re: [1/4] winscard: implementation

by Stefan Leichter

Am Donnerstag 06 Oktober 2011, 16:07:29 schrieb Bruno Jesus: > 2011/10/3 André Hentschel <nerv(a)dawncrow.de>: > > Am 03.10.2011 09:31, schrieb Vincent Hardy: > >> First submitted on wine-devel and modified following comments from Marcus Meissner (MAX_ATR_SIZE / bytecount). > >> > > > > OK, some notes: > > "winscard: implementation" is a very bad name for a patch, especially for 4. > > Splitting the patches is a good idea, but you need to split it different (you are adding dead code). > > In the first patch you might want to add the configure.ac and library loading stuff together with only the things needed for e.g. SCardListReadersA (why no SCardListReadersW?) and then e.g. a patch for every new function. > > I didn't looked at the code, but i want to remember you to read http://wiki.winehq.org/SubmittingPatches > > Hi to all, I would like to help Vincent to get this patches in. But we > need more objective help. The comments in this email and in previous > Vincent email differ. One says "send small patch" the other says "send > full functionality patch series". I would like to restart this thread > because otherwise it will be forgotten together with the patches. > > This is a whole new feature, in my short period into wine developing > this is the first time I see a completely new thing being introduced. > Hi, have a look at http://www.winehq.org/pipermail/wine-devel/2007-May/057057.html . There you find the reason why the patches did not go in the first time. Bye Stefan

Oct. 6, 2011

Re: Vista/w2k8/w7 users, please test mmdevapi base render test

by Erik Inge Bolsø

On Thu, 6 Oct 2011, Joerg-Cyril.Hoehle(a)t-systems.com wrote: > Hi > > thank you for your results. > > Please test again using > https://testbot.winehq.org/JobDetails.pl?Key=14738 Hi Jörg, I think your tests are actually correct, though could use a tiny bit more crash-proofing. On closer look, my capture setup seems to be broken on the E-MU 0202 USB - due to driver trouble. I get a later crash in your test this time though. render.c:167: Returned periods: 10.0000 ms 3.0000 ms render.c:179: pwfx: 00961AA0 render.c:180: Tag: fffe render.c:181: bits: 32 render.c:182: chan: 2 render.c:183: rate: 48000 render.c:184: align: 8 render.c:185: extra: 22 render.c:190: Res: 32 render.c:191: Mask: 3 render.c:192: Alg: FLOAT render.c:251: Initialize(duration=0) GetBufferSize is 1440 render.c:315: Returned latency: 10.6666 ms render.c:388: IsSupported(exclus., 44100x16x2) render.c:388: IsSupported(exclus., 48000x16x2) render.c:388: IsSupported(shared , 48000x 8x2) render.c:388: IsSupported(shared , 48000x16x2) render.c:897: Test failed: Initialize failed for capture in rendering session: 8889000f render.c:906: Tests skipped: No capture session: 8889000f; skipping capture device in render session tests render.c:1482: Test failed: Initialize failed: 8889000f render.c:1486: Test failed: GetService failed: 88890001 render.c:1486: this is the last test seen before the exception render: unhandled exception c0000005 at 76EC8DA9 When I disable my known-broken microphone device on the 0202, I get no failures. render.c:167: Returned periods: 10.0000 ms 3.0000 ms render.c:179: pwfx: 00921AA0 render.c:180: Tag: fffe render.c:181: bits: 32 render.c:182: chan: 2 render.c:183: rate: 48000 render.c:184: align: 8 render.c:185: extra: 22 render.c:190: Res: 32 render.c:191: Mask: 3 render.c:192: Alg: FLOAT render.c:251: Initialize(duration=0) GetBufferSize is 1440 render.c:315: Returned latency: 10.6666 ms render.c:388: IsSupported(exclus., 44100x16x2) render.c:388: IsSupported(exclus., 48000x16x2) render.c:388: IsSupported(shared , 48000x 8x2) render.c:388: IsSupported(shared , 48000x16x2) render.c:906: Tests skipped: No capture session: 80070490; skipping capture device in render session tests render: 668 tests executed (0 marked as todo, 0 failures), 1 skipped. And on the cheapo USB headset, I still only get the GetVolume failures. -- -erik http://useofwords.blogspot.com/

Oct. 6, 2011

Re: mscoree: Implement ICorDebug SetManagedHandler (try 2)

by Vincent Povirk

Still not sure there should be only one ICorDebug per runtime host. It seems like you might want to create multiple interfaces and use them independently.

Oct. 6, 2011

Re: [1/4] winscard: implementation

by Erich Hoover

On Thu, Oct 6, 2011 at 8:07 AM, Bruno Jesus <00cpxxx(a)gmail.com> wrote: > ... > This is a whole new feature, in my short period into wine developing > this is the first time I see a completely new thing being introduced. I'd take a look at usbd.sys, as it was introduced relatively recently. Generally for the first patch everything is just stubs: http://www.winehq.org/pipermail/wine-cvs/2010-March/065163.html I'm not sure about your other questions, but I figured that commit would at least help you get started. Erich Hoover ehoover(a)mines.edu

Oct. 6, 2011

Re: [1/4] winscard: implementation

by Bruno Jesus

2011/10/3 André Hentschel <nerv(a)dawncrow.de>: > Am 03.10.2011 09:31, schrieb Vincent Hardy: >> First submitted on wine-devel and modified following comments from Marcus Meissner (MAX_ATR_SIZE / bytecount). >> > > OK, some notes: > "winscard: implementation" is a very bad name for a patch, especially for 4. > Splitting the patches is a good idea, but you need to split it different (you are adding dead code). > In the first patch you might want to add the configure.ac and library loading stuff together with only the things needed for e.g. SCardListReadersA (why no SCardListReadersW?) and then e.g. a patch for every new function. > I didn't looked at the code, but i want to remember you to read http://wiki.winehq.org/SubmittingPatches Hi to all, I would like to help Vincent to get this patches in. But we need more objective help. The comments in this email and in previous Vincent email differ. One says "send small patch" the other says "send full functionality patch series". I would like to restart this thread because otherwise it will be forgotten together with the patches. This is a whole new feature, in my short period into wine developing this is the first time I see a completely new thing being introduced. The first Vincent patch seems ok to me, it adds the pcsclite to configure system and loads the library. I think this first patch should be commited after the next release cycle tomorrow so we will have two weeks to implement the rest of the functions, I talked to Vincent and he agreed with me that we can send one patch per function filled with tests that probably only he and me will be able to test since we have supported readers. Is this reasonable? In the order there would be patches for ScardEstablishContext, SCardListReaders, SCardGetStatus, SCardConnect, SCardTransmit. All of them with a series os tests and skips if the reader is not available or if the card is not available avoiding failures to other users. Non-users of smart cards may think this feature is not useful but I say it's a very important step and worth a line in the news when it gets implemented. Please, help us. Best wishes, Bruno -- universe* god::bigbang (void); //and then it all began...

Oct. 6, 2011

Vista/w2k8/w7 users, please test mmdevapi base render test

by Joerg-Cyril.Hoehle＠t-systems.com

Hi thank you for your results. Please test again using https://testbot.winehq.org/JobDetails.pl?Key=14738 + The crash in session tests should be gone, while render.c:887: Test failed: Initialize failed: 8889000f is left in until we gather more knowledge about sessions. + the exclusive mode should be handled correctly now, except - 5:1 IsSupported vs Initialize unchanged until we know more about 5:1 cards. - volume failure unchanged, I don't know those tests. (Saulius, a quick test is enough if there's no more issue) >And how does the test handle multiple soundcards? Not at all. The tests uses solely the default multimedia rendering device. I'm not aware of another test (devenum would be the candidate) that enumerates devices for us to check whether Wine did a good job, like the winmm:wave and midi test do. BSD and other Wine users may also be interested in the tests, e.g. Francois' BSD81 system crashed http://test.winehq.org/data/e5ba60174ef931d299894bc1e8961c822f4809c4/bsd_fg… and there's now better protection against failures (not in all places though). Regards, Jörg Höhle

Oct. 6, 2011

Re: mscoree: Implement ICorDebug SetManagedHandler (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 http://testbot.winehq.org/JobDetails.pl?Key=14737 Your paranoid android. === WVISTAADM (32 bit debugging) === Failure running script in VM: The specified guest user must be logged in interactively to perform this operation

Oct. 6, 2011

Re: mscoree: Implement ICorDebug SetManagedHandler

by Alexandre Julliard

Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> writes: > @@ -99,8 +99,28 @@ static HRESULT WINAPI CorDebug_Terminate(ICorDebug *iface) > static HRESULT WINAPI CorDebug_SetManagedHandler(ICorDebug *iface, ICorDebugManagedCallback *pCallback) > { > RuntimeHost *This = impl_from_ICorDebug( iface ); > - FIXME("stub %p %p\n", This, pCallback); > - return E_NOTIMPL; > + HRESULT hr; > + > + TRACE("%p (%p)\n", This, pCallback); > + > + if(!pCallback) > + return E_INVALIDARG; > + > + if(This->pCallback2) > + ICorDebugManagedCallback2_Release(This->pCallback2); > + > + if(This->pCallback) > + ICorDebugManagedCallback_Release(This->pCallback); > + > + hr = ICorDebugManagedCallback_QueryInterface(pCallback, &IID_ICorDebugManagedCallback2, (void**)&This->pCallback2); > + if(hr == S_OK) > + { > + This->pCallback = pCallback; > + > + ICorDebugManagedCallback_AddRef(This->pCallback); > + } You can't release the old interfaces before the new ones are in place. -- Alexandre Julliard julliard(a)winehq.org

Oct. 5, 2011

Re: [Question] Built-in indeo drivers

by Henri Verbeet

On 5 October 2011 17:14, Maxim <max_pole(a)gmx.de> wrote: > I volunteer myself to create an open-source bult-in replacement for > indeo v3,4 and 5 based on my patches for ffmpeg. The code will be > reworked in order to remove ffmpeg/libav library dependencies. > Only decoding will be implemented. Encoding would require a huge amount > of time and it doesn't worth it... > > Would be such a patch appreciated? > I'm not terribly familiar with the relevant code, but I'd suspect that the preferred way to make this work would be by going through gstreamer instead of maintaining our own codecs in Wine.

Oct. 5, 2011

Re: comctl32/tests: Removed sign comparison warning in datetime tests.

by Marko Nikolic

Joris Huizer wrote: > On 10/05/2011 04:43 PM, Marko Nikolic wrote: >> static void test_mccolor_types(HWND hWndDateTime, int mccolor_type, const >> char* mccolor_name) >> { >> - LRESULT r; >> - COLORREF theColor, prevColor; >> + //LRESULT r; >> + COLORREF theColor, prevColor, crColor; >> > > Please avoid C++/C99-style comments in Wine code > In this case you should remove the 'r' variable instead of commenting it > out. Thanks, I missed it, it left from the testing. The whole line should be removed, I'll resend the patch. Marko

Oct. 5, 2011

Re: netapi32: add stub for NetScheduleJobEnum

by Austin English

On Wed, Oct 5, 2011 at 11:35, Louis Lenders <xerox_xerox2000(a)yahoo.co.uk> wrote: > this fixes a crash in app SysIsdpector (http://download.eset.com/download/sysinspector/32/ENU/SysInspector.exe) You should've made this a series, otherwise the build fails: -- -Austin ---------- Forwarded message ---------- From: <buildbot(a)kegel.com> Date: Wed, Oct 5, 2011 at 11:41 Subject: Re: 79589: netapi32: add stub for NetScheduleJobEnum To: dank(a)kegel.com, wine-tests-results(a)winehq.org This is an experimental automated build and test service. Please feel free to ignore this email while we work the kinks out. For more info about this message, see http://wiki.winehq.org/BuildBot The Buildbot has detected a failed build on builder runtests-default while building Wine. Full details are available at: http://buildbot.kegel.com/builders/runtests-default/builds/134 (though maybe not for long, as I'm still reinstalling the buildbot periodically while experimenting) BUILD FAILED: failed shell_2 Errors: netapi32.c:23: error: lmat.h: No such file or directory make[1]: *** [depend] Error 1 make: *** [dlls/netapi32/__depend__] Error 2

Oct. 5, 2011

Re: comctl32/tests: Removed sign comparison warning in datetime tests.

by Joris Huizer

On 10/05/2011 04:43 PM, Marko Nikolic wrote: > static void test_mccolor_types(HWND hWndDateTime, int mccolor_type, const char* mccolor_name) > { > - LRESULT r; > - COLORREF theColor, prevColor; > + //LRESULT r; > + COLORREF theColor, prevColor, crColor; > Please avoid C++/C99-style comments in Wine code In this case you should remove the 'r' variable instead of commenting it out.

Oct. 5, 2011