wine-devel April 2015

wine-devel@winehq.org

54 participants
164 discussions

Start a nNew thread

Re: [3/3] ws2_32: Properly handle closing sockets during a select call.
by Marvin 30 Apr '15

30 Apr '15

1 0

Re: shell32: Add caption to run dialog (resend)
by Alex Henrie 30 Apr '15

30 Apr '15

Thanks for your interest in developing Wine! A few pointers: You are supposed to use your name when submitting patches. I don't think Alexandre will accept just your initials. Also, you should avoid putting all that HTML garbage into the patch by using `git format-patch` and `git send-email`. If you cannot use git send-email, send the patch as an attachment. Please read http://wiki.winehq.org/SubmittingPatches Finally, your patch is more likely to be accepted if you can give an example of a Windows program that demonstrates the problem you're trying to fix. -Alex

1 0

Re: [PATCH 2/5] ddraw: Release the surface clipper (if any) in ddraw_surface_wined3d_object_destroyed() (Valgrind).
by Marvin 29 Apr '15

29 Apr '15

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=13125 Your paranoid android. === w8 (32 bit ddraw1) === ddraw1.c:1373: Test failed: Expected color 0x00ff0000 for test 0, got 0x0000ff00. ddraw1.c:1392: Test failed: Expected color 0x000000ff for test 0, got 0x0000ff00. ddraw1.c:6666: Test failed: Got unexpected color 0x000000ff. ddraw1.c:6670: Test failed: Got unexpected color 0x00000080.

2 1

Re: Strange wined3d crash
by Francois Gouget 29 Apr '15

29 Apr '15

On Wed, 29 Apr 2015, Henri Verbeet wrote: > On 29 April 2015 at 12:40, Francois Gouget <fgouget(a)free.fr> wrote: > > I am getting a strange wined3d crash during the d3d8:device test. > > > Is that a regression? We did touch the shader generation code recently. It is actually. This is the patch that introduced the crash: commit 28343db2083de7b4afe4079da090520f44b5544d Author: Matteo Bruni <mbruni(a)codeweavers.com> Date: Mon Apr 27 17:39:12 2015 +0200 wined3d: Don't use the builtin FFP uniforms for the lights. While at it, use D3D-like uniforms for the light parameters and (consequently) implement range and proper D3D spotlights support. I can test patches but I'm not sure I'll have time to debug this much further for a while :-( Note that this is with an Intel HD Graphics 4600 GPU. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ $live{free} || die "";

3 2

Re: ws2_32: Include inttypes.h for UINT32_MAX.
by Henri Verbeet 29 Apr '15

29 Apr '15

On 29 April 2015 at 11:34, Francois Gouget <fgouget(a)free.fr> wrote: > This fixes compilation on FreeBSD. > --- > > The only other files that use UINT32_MAX are: > * The .yy.c files. These are generated and always do an ifndef+define. > * dlls/mshtml/nsembed.c though it calls it PR_UINT32_MAX for some reason. > * dlls/jscript/string.c which simply defines it. > * dlls/winemac.drv/macdrv_cocoa.h which presumably gets it from the Mac > OS X headers. > > Maybe mshtml and jscript should use inttypes.h, or to the contrary, > maybe ws2_32 should use the ifndef+define approach. > Arguably it shouldn't be using UINT32_MAX at all, since it isn't actually used with uint32_t. I guess it should be using e.g. unsigned int with UINT_MAX instead.

4 6

USB Support
by Steve Kenton 29 Apr '15

29 Apr '15

USB Support has been on the list of possible release criteria basically forever. I've read through all the old threads and other discussions I could find and it boils down to "really hard to do right". If possible could someone knowledgeable comment briefly on what might be an acceptable architecture for a Wine USB stack? In particular I'm wondering about how much support for client/function drivers would be desirable. Should we stick to only unprivileged operations or would an optional kernel mode driver to support WDM or WDF (KMDF/UMDF) privileged interfaces be acceptable? Steve Kenton

5 11

Strange wined3d crash
by Francois Gouget 29 Apr '15

29 Apr '15

I am getting a strange wined3d crash during the d3d8:device test. It's annoying because it only happens with the 64 bit build, and disappears if I add traces (+d3d or +d3d_shader), and even if I add a FIXME() just before the crash. The crash happens in shader_glsl_ffp_vertex_lighting(): shader_addline(buffer, "gl_FrontSecondaryColor = %s * specular;\n", specular); According to the checks I've been able to do the specular pointer is still correct when this gets called. Here's the backtrace: http://pastebin.com/DKvXTVJn Any idea what's up? It almost feels like a compiler bug (gcc 4.9.2 (Debian 4.9.2-10) here). -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ You can have my guns when you pry them from my kids cold, dead hands.

1 0

Re: [PATCH] wined3d: fix different level count while texture update
by Henri Verbeet 29 Apr '15

29 Apr '15

On 28 April 2015 at 20:18, Sergey Isakov <isakov-sl(a)bk.ru> wrote: > Bug 38048 > According to MSDN > https://msdn.microsoft.com/en-us/library/windows/desktop/bb205858(v=vs.85) > source texture CAN have greater level count then destination > Current comparison "!=“ causes black textures as discussed in the bugzilla. > This may be correct, it may not be. This change needs tests, and I believe that was pointed out in the bug report already.

1 0

Re: [PATCH] wined3d: fix Unrecognized usage flags
by Henri Verbeet 29 Apr '15

29 Apr '15

Please use git send-email for sending patches. On 28 April 2015 at 09:18, Sergey Isakov <isakov-sl(a)bk.ru> wrote: > + WINED3DUSAGE_TO_STR(WINED3DUSAGE_TEXTURE); This is fine, but WINED3DUSAGE_OWNDC is missing here as well. Is "buf" still larger enough after you add these flags? > - if (usage) FIXME("Unrecognized usage flag(s) %#x\n", usage); > + if (usage & ~WINED3DUSAGE_QUERY_MASK) FIXME("Unrecognized usage flag(s) %#x\n", usage); I think it makes more sense to do this in the caller. It may make even more sense to just merge debug_d3dusage() and debug_d3dusagequery().

1 0

Re: [PATCH] comdlg32: Change "Borders" to "Margins".
by Alex Henrie 29 Apr '15

29 Apr '15

2015-04-28 8:03 GMT-06:00 Alexandre Julliard <julliard(a)winehq.org>: > Alex Henrie <alexhenrie24(a)gmail.com> writes: > >> Alexandre, >> >> What was wrong with this patch that you did not accept it? > > I'm concerned that you have been looking at Windows a bit too much. At first, I thought that Wine actually used this string. On closer look, it seems that Wine always replaces the dialog's string "Borders" with the string resource "Margins [inches]" or "Margins [mm]": https://source.winehq.org/git/wine.git/blob/abd673bde93b76a361ddf7342c538c2… https://source.winehq.org/git/wine.git/blob/abd673bde93b76a361ddf7342c538c2… The following test (run with `./wine dlls/comdlg32/tests/comdlg32_test.exe.so printdlg`) also supports the hypothesis that Wine always overrides the dialog's string: diff --git a/dlls/comdlg32/comdlg32.rc b/dlls/comdlg32/comdlg32.rc index d3deeab..9d37d69 100644 --- a/dlls/comdlg32/comdlg32.rc +++ b/dlls/comdlg32/comdlg32.rc @@ -438,7 +438,7 @@ BEGIN GROUPBOX "Orientation", grp1, 8, 156, 64, 56, BS_GROUPBOX AUTORADIOBUTTON "&Portrait", rad1, 16, 170, 52, 12, BS_AUTORADIOBUTTON AUTORADIOBUTTON "&Landscape", rad2, 16, 190, 52, 12, BS_AUTORADIOBUTTON - GROUPBOX "Borders", grp4, 80, 156, 152, 56, BS_GROUPBOX + GROUPBOX "foobar", grp4, 80, 156, 152, 56, BS_GROUPBOX LTEXT "L&eft:", stc15, 88, 172, 30, 8 EDITTEXT edt4, 119, 170, 36, 12, WS_TABSTOP|WS_GROUP|WS_BORDER LTEXT "&Right:", stc16, 159, 172, 30, 8 diff --git a/dlls/comdlg32/tests/printdlg.c b/dlls/comdlg32/tests/printdlg.c index 7e06c97..d6c7dff 100644 --- a/dlls/comdlg32/tests/printdlg.c +++ b/dlls/comdlg32/tests/printdlg.c @@ -88,7 +88,7 @@ static void test_PageSetupDlgA(void) ZeroMemory(pDlg, sizeof(PAGESETUPDLGA)); pDlg->lStructSize = sizeof(PAGESETUPDLGA); - pDlg->Flags = PSD_RETURNDEFAULT | PSD_NOWARNING; + pDlg->Flags = PSD_NOWARNING; SetLastError(0xdeadbeef); res = PageSetupDlgA(pDlg); ok( res || (CommDlgExtendedError() == PDERR_NODEFAULTPRN), If I am correct, it would be better to replace "Borders" with "" so that translators have one less string to worry about. Is that acceptable to you? -Alex

2 1

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel April 2015