April 2015 - Wine-Devel - list.winehq.org

Re: [PATCH 2/4] wined3d: Keep track of renderbuffer capabilities.

by Henri Verbeet

On 30 April 2015 at 21:45, Stefan Dösinger <stefandoesinger(a)gmail.com> wrote: >>> + if ((rt_format->flags[WINED3D_GL_RES_TYPE_RB] & WINED3DFMT_FLAG_RENDERTARGET) >>> + && (ds_format->flags[WINED3D_GL_RES_TYPE_RB] & (WINED3DFMT_FLAG_DEPTH | WINED3DFMT_FLAG_STENCIL))) >> This is actually wrong. At least, as long as we don't allow (plain) >> renderbuffers to be used for FBO attachments. There's nothing in the >> spec that says formats that can be used for color rendering with >> renderbuffers have to be available for color rendering with textures >> as well, and in fact that's much of the reason for this patch set. > I'm not really making a distinction between "is this format a depth > stencil format" and "Can a resource with this type and format be > created". Maybe we should add some WINED3DFMT_FLAG_SUPPORTED flag and > check it in resource_init regardless of what the app requests? > I think WINED3DFMT_FLAG_FBO_ATTACHABLE mostly does what we want as long as FBO ORM is used, perhaps it should be generalized to e.g. WINED3DFMT_FLAG_RENDERABLE.

April 30, 2015

Re: [PATCH 2/4] wined3d: Keep track of renderbuffer capabilities.

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2015-04-30 um 11:09 schrieb Henri Verbeet: > That's not wrong as such, but it is pretty arbitrary. > WINED3DFMT_FLAG_FLOAT is a basic property of the format, like e.g. the > component masks and sizes, it shouldn't depend on the resource type. > Once we'll get proper integer types for d3d10, it will probably make > sense to keep track of the type (INT/UINT/FLOAT/UNORM/SNORM) as an > enumeration instead, perhaps even per-component. Yeah, as I said in the mail that introduced the split, I could move things like FLAG_FLOAT and FLAG_GETDC into a separate, resource-independent flags field. Or we just keep it the way it is and track things like float per component later on. I'm using WINED3D_GL_RES_TYPE_RB instead of 2D here because this function is doing checks for the onscreen WGL buffer. It's not the same as a renderbuffer but it has the similar limitations and abilities that I don't see a reason to add a separate WGL buffer resource type at this point. >> + if ((rt_format->flags[WINED3D_GL_RES_TYPE_RB] & WINED3DFMT_FLAG_RENDERTARGET) >> + && (ds_format->flags[WINED3D_GL_RES_TYPE_RB] & (WINED3DFMT_FLAG_DEPTH | WINED3DFMT_FLAG_STENCIL))) > This is actually wrong. At least, as long as we don't allow (plain) > renderbuffers to be used for FBO attachments. There's nothing in the > spec that says formats that can be used for color rendering with > renderbuffers have to be available for color rendering with textures > as well, and in fact that's much of the reason for this patch set. I'm not really making a distinction between "is this format a depth stencil format" and "Can a resource with this type and format be created". Maybe we should add some WINED3DFMT_FLAG_SUPPORTED flag and check it in resource_init regardless of what the app requests? WINED3DFMT_FLAG_TEXTURE doesn't work for this purpose because when the application creates a non-texture depth stencil surface (or even the implicit depth stencil) we have no reason to require WINED3DFMT_FLAG_TEXTURE. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJVQoZbAAoJEN0/YqbEcdMwUf0P/RfOs3qlOmR0QQp1GHruCuzz KMX5hh9Mr52MQ6Q7ZGmN2WxsWRsm0uyoIozzyjRnJncrwtYr9PH4mGn9RL3Yu4So AJMrmLWxhzoW07pBfWkiOwCnxej29pI3A2tZ2T2Gqhlb/ShiruBjwuWr7STrhg1L DSB6vDp3os7yo4w+itPyXYPRyxC/OlOXCMt27YKNKYmHdhGTYR3/TPM4yswp1zI0 0V4AFDrjtOD/c80mBVFKGcFUbN0aYlLKzHrCyXGpgutIfc8ULJOAKFlUvhP4I3so VeYtlnlMLcbxaOqd7VuteSvZl/hXwrOBOd7hy2Cfop/aHkmx6jCIL3qHowlGhZpc ADz98OkGyKX+xJ0KUmKpI1iLLsvkig5vAZsKGcawgEvAM4sycBaLLZPh5rmruXr3 ZhpmbKIONXnbNKxOx/iV02Vl7ItY0ziSsdtwrPb2GKhLhdOlohrsa0CByyY7LS6s gmZQ5IMlYaq9QLWjHxX2DW0J/3q/ovQXEMVjKoo+tK8F5pR1f5egXuDgBkOsw8z5 yTz4nvQmHoPdbLPIeiW/SC4+D6T7aOctWoy10If+mRR+VVq7uKMTicXkdgnhS2RM m7SpKTfy8vhVblVZ594kXFCPqPo5cm/CWWH7DnxaRcN3B6tbS2d5ZeamJ6qnOyps LIyM343lMK6fDVpsj0+I =trjB -----END PGP SIGNATURE-----

April 30, 2015

Re: [2/3] user32: Add some tests for EndDialog called from other thread.

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=13148 Your paranoid android. === w7u (32 bit msg) === msg.c:12230: Test failed: unexpected hwnd 0014013C msg.c:12252: Test failed: bad time 314e6/314f6

April 30, 2015

Re: [1/3] user32/tests: Add a test for calling SetWindowPos for other thread window. Resend.

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=13147 Your paranoid android. === w7u (32 bit msg) === msg.c:12230: Test failed: unexpected hwnd 0014013C msg.c:12252: Test failed: bad time 30ece/30ede

April 30, 2015

Re: [PATCH 2/5] d3d9/tests: Add a test for UpdateTexture. (v2, resend)

by Alexandre Julliard

Matteo Bruni <mbruni(a)codeweavers.com> writes: > v2: Make tests pass on the testbot, add a couple more test cases, some > small cleanups. It doesn't work here: ../../../tools/runtest -q -P wine -T ../../.. -M d3d9.dll -p d3d9_test.exe.so visual && touch visual.ok visual.c:12925: Tests skipped: No NVDB (depth bounds test) support, skipping tests. visual.c:16373: Tests skipped: DXT5 volume textures are not supported, skipping test. visual.c:18582: Test failed: Got unexpected color 0x0000ff00, case 0, 1. visual.c:18582: Test failed: Got unexpected color 0x0000ff00, case 0, 2. visual.c:18582: Test failed: Got unexpected color 0x0000ff00, case 0, 3. visual.c:18582: Test failed: Got unexpected color 0x0000ff00, case 0, 4. visual.c:18582: Test failed: Got unexpected color 0x0036c800, case 1, 1. visual.c:18582: Test failed: Got unexpected color 0x0036c800, case 1, 2. visual.c:18582: Test failed: Got unexpected color 0x0036c800, case 1, 3. visual.c:18582: Test failed: Got unexpected color 0x0036c800, case 1, 4. visual.c:18409: Tests skipped: Volume ATI2N textures are not supported, skipping some tests. visual.c:18582: Test failed: Got unexpected color 0x0000ff00, case 2, 1. visual.c:18582: Test failed: Got unexpected color 0x0000ff00, case 2, 2. visual.c:18582: Test failed: Got unexpected color 0x0000ff00, case 2, 3. visual.c:18582: Test failed: Got unexpected color 0x0000ff00, case 2, 4. make: *** [visual.ok] Error 12 -- Alexandre Julliard julliard(a)winehq.org

April 30, 2015

Re: [PATCH 4/4] wined3d: Don't use depth textures without ARB_depth_texture.

by Henri Verbeet

On 30 April 2015 at 00:00, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > + if (!gl_info->supported[ARB_DEPTH_TEXTURE]) > + { > + static const unsigned int depth_flags = WINED3DFMT_FLAG_SHADOW | WINED3DFMT_FLAG_DEPTH > + | WINED3DFMT_FLAG_STENCIL; > + format->flags[WINED3D_GL_RES_TYPE_TEX_1D] &= ~depth_flags; > + format->flags[WINED3D_GL_RES_TYPE_TEX_2D] &= ~depth_flags; > + format->flags[WINED3D_GL_RES_TYPE_TEX_3D] &= ~depth_flags; > + format->flags[WINED3D_GL_RES_TYPE_TEX_CUBE] &= ~depth_flags; > + format->flags[WINED3D_GL_RES_TYPE_TEX_RECT] &= ~depth_flags; > + } This is wrong for the reasons mentioned in patch 2/4, but it should also be unnecessary. WINED3DFMT_FLAG_TEXTURE is supposed to indicate if you can use a format for texturing or not.

April 30, 2015

Re: [PATCH 3/4] wined3d: Use renderbuffers if the resource type is RB.

by Henri Verbeet

On 30 April 2015 at 00:00, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > @@ -341,6 +341,8 @@ void wined3d_resource_update_draw_binding(struct wined3d_resource *resource) > resource->draw_binding = WINED3D_LOCATION_DRAWABLE; > else if (resource->multisample_type) > resource->draw_binding = WINED3D_LOCATION_RB_MULTISAMPLE; > + else if (resource->gl_type == WINED3D_GL_RES_TYPE_RB) > + resource->draw_binding = WINED3D_LOCATION_RB_RESOLVED; I haven't looked much into what actually happens now, but the last time I looked at using renderbuffers for FBO attachments, one of the issues that came up was the initial surface contents. Right now we handle that by clearing WINED3D_LOCATION_SYSMEM and marking it current, but that won't work so well for renderbuffers. Somewhat related, does WINED3DFMT_D16_LOCKABLE need special handling?

April 30, 2015

Re: [PATCH 2/4] wined3d: Keep track of renderbuffer capabilities.

by Henri Verbeet

On 30 April 2015 at 00:00, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > diff --git a/dlls/wined3d/directx.c b/dlls/wined3d/directx.c > index 36be539..ad9b496 100644 > --- a/dlls/wined3d/directx.c > +++ b/dlls/wined3d/directx.c > @@ -4095,7 +4095,7 @@ static BOOL wined3d_check_pixel_format_color(const struct wined3d_gl_info *gl_in > BYTE redSize, greenSize, blueSize, alphaSize, colorBits; > > /* Float formats need FBOs. If FBOs are used this function isn't called */ > - if (format->flags[WINED3D_GL_RES_TYPE_TEX_2D] & WINED3DFMT_FLAG_FLOAT) > + if (format->flags[WINED3D_GL_RES_TYPE_RB] & WINED3DFMT_FLAG_FLOAT) That's not wrong as such, but it is pretty arbitrary. WINED3DFMT_FLAG_FLOAT is a basic property of the format, like e.g. the component masks and sizes, it shouldn't depend on the resource type. Once we'll get proper integer types for d3d10, it will probably make sense to keep track of the type (INT/UINT/FLOAT/UNORM/SNORM) as an enumeration instead, perhaps even per-component. > @@ -4178,8 +4178,8 @@ HRESULT CDECL wined3d_check_depth_stencil_match(const struct wined3d *wined3d, > ds_format = wined3d_get_format(&adapter->gl_info, depth_stencil_format_id); > if (wined3d_settings.offscreen_rendering_mode == ORM_FBO) > { > - if ((rt_format->flags[WINED3D_GL_RES_TYPE_TEX_2D] & WINED3DFMT_FLAG_RENDERTARGET) > - && (ds_format->flags[WINED3D_GL_RES_TYPE_TEX_2D] & (WINED3DFMT_FLAG_DEPTH | WINED3DFMT_FLAG_STENCIL))) > + if ((rt_format->flags[WINED3D_GL_RES_TYPE_RB] & WINED3DFMT_FLAG_RENDERTARGET) > + && (ds_format->flags[WINED3D_GL_RES_TYPE_RB] & (WINED3DFMT_FLAG_DEPTH | WINED3DFMT_FLAG_STENCIL))) This is actually wrong. At least, as long as we don't allow (plain) renderbuffers to be used for FBO attachments. There's nothing in the spec that says formats that can be used for color rendering with renderbuffers have to be available for color rendering with textures as well, and in fact that's much of the reason for this patch set. > @@ -998,9 +998,9 @@ static BOOL fbo_blit_supported(const struct wined3d_gl_info *gl_info, enum wined > break; > > case WINED3D_BLIT_OP_DEPTH_BLIT: > - if (!(src_format->flags[WINED3D_GL_RES_TYPE_TEX_2D] & (WINED3DFMT_FLAG_DEPTH | WINED3DFMT_FLAG_STENCIL))) > + if (!(src_format->flags[WINED3D_GL_RES_TYPE_RB] & (WINED3DFMT_FLAG_DEPTH | WINED3DFMT_FLAG_STENCIL))) Similar to WINED3DFMT_FLAG_FLOAT, these are basic properties of the format.

April 30, 2015

Re: [PATCH 1/4] wined3d: Allow specifying a different depth stencil location.

by Henri Verbeet

On 30 April 2015 at 00:00, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > @@ -2342,12 +2352,14 @@ BOOL context_apply_clear_state(struct wined3d_context *context, const struct win > ++i; > } > context_apply_fbo_state(context, GL_FRAMEBUFFER, context->blit_targets, > - wined3d_rendertarget_view_get_surface(fb->depth_stencil), > - rt_count ? rts[0]->resource->draw_binding : WINED3D_LOCATION_TEXTURE_RGB); > + wined3d_rendertarget_view_get_surface(dsv), > + rt_count ? rts[0]->resource->draw_binding : WINED3D_LOCATION_TEXTURE_RGB, > + dsv ? dsv->resource->draw_binding : WINED3D_LOCATION_TEXTURE_RGB); > } This works because we mostly just care that the color location isn't WINED3D_LOCATION_DRAWABLE if there's no attachment. (In particular for the case where the application is doing depth only rendering.) Strictly speaking though, it's probably more correct to use the color location if there's no depth/stencil attachment, to avoid silliness like the color attachment being in WINED3D_LOCATION_DRAWABLE and the depth/stencil attachment in WINED3D_LOCATION_TEXTURE_RGB. In fact, now that the color and depth/stencil locations are separate, you can probably just pass 0.

April 30, 2015

Re: [PATCH 5/5] wined3d: Don't use the same va_list multiple times in shader_vaddline().

by Henri Verbeet

On 29 April 2015 at 23:34, Matteo Bruni <mbruni(a)codeweavers.com> wrote: > -static void string_buffer_vsprintf(struct wined3d_string_buffer *buffer, const char *format, va_list args) > +static int string_buffer_vsprintf(struct wined3d_string_buffer *buffer, const char *format, va_list args) > { > if (!buffer) > - return; > + return 0; > string_buffer_clear(buffer); > - shader_vaddline(buffer, format, args); > + return shader_vaddline(buffer, format, args); > } > You could perhaps just merge this into string_buffer_sprintf(), but I don't care that much.

April 30, 2015

Re: d3drm: Fix refcounting for IDirect3DRM{1-3}

by Aaryaman Vasishta

On Thu, Apr 30, 2015 at 1:11 PM, Stefan Dösinger <stefandoesinger(a)gmail.com> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Am 2015-04-29 um 23:47 schrieb Aaryaman Vasishta: > > - if (!refcount) > > + if (!refcount && !InterlockedDecrement(&d3drm->numIfaces)) > > HeapFree(GetProcessHeap(), 0, d3drm); > This works, but this way you have the code that destroys the object 3 > times. Not much of an issue as long as it is just a HeapFree, but I > think it would be nicer to have a separate function. Either add a > d3drm_destroy function or a pair of d3drm_add_iface and > d3drm_release_iface functions that also take care of > InterlockedIncrement / Decrement for iface_count) > > > - { &IID_IDirect3DRM3, &IID_IDirect3DRM3, > S_OK, TRUE }, > > - { &IID_IDirect3DRM2, &IID_IDirect3DRM2, > S_OK, TRUE }, > > + { &IID_IDirect3DRM3, &IID_IDirect3DRM3, > S_OK, FALSE }, > > + { &IID_IDirect3DRM2, &IID_IDirect3DRM2, > S_OK, FALSE }, > Afaics all the TODOs are gone, so you can remove this field from the > table and the todo_wine code from test_qi(). Either in the same patch > or a separate one. > I was thinking to remove the TODO's in a separate patch, as both the frame tests and d3drm tests use it. Is that okay? Hope AJ agrees with this change :) > > > - LONG ref; > > + LONG ref1, ref2, ref3, numIfaces; > > }; > Please use iface_count. Yeah, it's just a plain style thing, but d3drm > is nicely consistent so far in not using CamelCase (except in cases > where Microsoft determined the name). > > (Yesterday on IRC I said num_ifaces. Henri says xxx_count is the way > he prefers.) > I don't like CamelCase either, glad to use iface_count :) > > > + if (refcount == 1) InterlockedIncrement(&d3drm->numIfaces); > Another minor style issue: Please put the statement on a separate > line, in consistency with the existing code. > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2 > I'll make the changes and resend the patch as try-2 Thank you! Jam > > iQIcBAEBAgAGBQJVQdzBAAoJEN0/YqbEcdMw5WAP/0H52sqgEXMdSmh6sXH/dZMQ > nTZY9uRhElUbb3r6D6HG0ylit994pPaq887t9BSl8F4vbjsPXLjruDbVSwoScCfp > rIDKy9xET+ek4p5TSFC9cX1BFAiC2VKN7YYWmr/wHKVPZc+aFudU9ykac02bi9p2 > Oe+9wMBcFbwv33UhNL+2dugA4+0yj6egfPJWmju9C6ff6CPGqgXH70rHsrSf1AYs > VkNPRhGpfI9BxojBChVtgc0zwPM1HnfOwfmKWCW75YNgNg9lL0o+bdoy2wCcxiLq > FYwLLT2o9K+RnPQqRDhdJBKWwY8VrJI/fHZEURRau7RW1ia26j4UrrsAdXTQwhPs > Iy8A63pYOxyZsphq5KJ8cwGABYIlBPUG0lXZQRgKh1Jw8f39HIR5cfnu1at/fPSc > Cw6tfL/t+g4KeHaZDWZnROwyp704kIZGgvSaPuJjwkPtHh2MN14cp9KQj389kCUM > 4KfV6FxsAByRuJ8ur1HSaV2OeIOKOJkaDTzaiiMqc581A0awOeCy5SuAUSrQu4IE > 4gAIjryIJXd+kTDw46y6OW5UNXHdNJKGWAMiih25yLBi0BLBfUiW0U7qW5Lcerls > e7zefeUYNT+Umj3WU4sDu6B8B6auSZgKrLu9JAwYH2RUhKX9R+z3uTY25VUbJkoP > 9WJfJJuosIA5zqLbjxu+ > =/BI/ > -----END PGP SIGNATURE----- >

April 30, 2015

Re: d3drm: Fix refcounting for IDirect3DRM{1-3}

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2015-04-29 um 23:47 schrieb Aaryaman Vasishta: > - if (!refcount) > + if (!refcount && !InterlockedDecrement(&d3drm->numIfaces)) > HeapFree(GetProcessHeap(), 0, d3drm); This works, but this way you have the code that destroys the object 3 times. Not much of an issue as long as it is just a HeapFree, but I think it would be nicer to have a separate function. Either add a d3drm_destroy function or a pair of d3drm_add_iface and d3drm_release_iface functions that also take care of InterlockedIncrement / Decrement for iface_count) > - { &IID_IDirect3DRM3, &IID_IDirect3DRM3, S_OK, TRUE }, > - { &IID_IDirect3DRM2, &IID_IDirect3DRM2, S_OK, TRUE }, > + { &IID_IDirect3DRM3, &IID_IDirect3DRM3, S_OK, FALSE }, > + { &IID_IDirect3DRM2, &IID_IDirect3DRM2, S_OK, FALSE }, Afaics all the TODOs are gone, so you can remove this field from the table and the todo_wine code from test_qi(). Either in the same patch or a separate one. > - LONG ref; > + LONG ref1, ref2, ref3, numIfaces; > }; Please use iface_count. Yeah, it's just a plain style thing, but d3drm is nicely consistent so far in not using CamelCase (except in cases where Microsoft determined the name). (Yesterday on IRC I said num_ifaces. Henri says xxx_count is the way he prefers.) > + if (refcount == 1) InterlockedIncrement(&d3drm->numIfaces); Another minor style issue: Please put the statement on a separate line, in consistency with the existing code. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJVQdzBAAoJEN0/YqbEcdMw5WAP/0H52sqgEXMdSmh6sXH/dZMQ nTZY9uRhElUbb3r6D6HG0ylit994pPaq887t9BSl8F4vbjsPXLjruDbVSwoScCfp rIDKy9xET+ek4p5TSFC9cX1BFAiC2VKN7YYWmr/wHKVPZc+aFudU9ykac02bi9p2 Oe+9wMBcFbwv33UhNL+2dugA4+0yj6egfPJWmju9C6ff6CPGqgXH70rHsrSf1AYs VkNPRhGpfI9BxojBChVtgc0zwPM1HnfOwfmKWCW75YNgNg9lL0o+bdoy2wCcxiLq FYwLLT2o9K+RnPQqRDhdJBKWwY8VrJI/fHZEURRau7RW1ia26j4UrrsAdXTQwhPs Iy8A63pYOxyZsphq5KJ8cwGABYIlBPUG0lXZQRgKh1Jw8f39HIR5cfnu1at/fPSc Cw6tfL/t+g4KeHaZDWZnROwyp704kIZGgvSaPuJjwkPtHh2MN14cp9KQj389kCUM 4KfV6FxsAByRuJ8ur1HSaV2OeIOKOJkaDTzaiiMqc581A0awOeCy5SuAUSrQu4IE 4gAIjryIJXd+kTDw46y6OW5UNXHdNJKGWAMiih25yLBi0BLBfUiW0U7qW5Lcerls e7zefeUYNT+Umj3WU4sDu6B8B6auSZgKrLu9JAwYH2RUhKX9R+z3uTY25VUbJkoP 9WJfJJuosIA5zqLbjxu+ =/BI/ -----END PGP SIGNATURE-----

April 30, 2015

Re: kernel32/tests: Add tests for deleting readonly files with NtCreateFile.

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=13137 Your paranoid android. === wvistau64 (32 bit file) === file.c:444: Test failed: attributes of file "testfile.xxx" are 0x0820 === w7u (32 bit file) === file.c:4052: Test failed: SetFileValidData failed 87 file.c:4055: Test failed: SetFileValidData failed 87 === wvistau64 (64 bit file) === file.c:444: Test failed: attributes of file "testfile.xxx" are 0x0820

April 30, 2015

Re: [3/3] ws2_32: Properly handle closing sockets during a select call.

by Marvin

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

April 30, 2015

Re: shell32: Add caption to run dialog (resend)

by Alex Henrie

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

April 30, 2015

Re: [PATCH 2/5] ddraw: Release the surface clipper (if any) in ddraw_surface_wined3d_object_destroyed() (Valgrind).

by Matteo Bruni

2015-04-29 20:23 GMT+02:00 Marvin <testbot(a)winehq.org>: > 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. FWIW, I have a number of "fixes" for those intermittent test failures, I'll eventually get to them...

April 29, 2015

Re: Strange wined3d crash

by Henri Verbeet

On 29 April 2015 at 19:02, Matteo Bruni <matteo.mystral(a)gmail.com> wrote: > Essentially it crashes in shader_vaddline() as soon as we have to > resize the buffer because vsnprintf() tries to use "args" for a second > time. Oops. I guess this really got broken with cf12f51b1520546dc855e8e8e43135a06e7a0cbf already, but the larger initial buffer size made it work most of the time. > I attached a fix. Henri, is something like that okay with you? In principle, but I think va_copy() is C99; I'm not sure we can rely on it being present. Since shader_vaddline() only has a couple of callers, it may be better to just move the resizing code into a helper function and use that from the callers.

April 29, 2015

Re: [PATCH 2/5] ddraw: Release the surface clipper (if any) in ddraw_surface_wined3d_object_destroyed() (Valgrind).

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://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.

April 29, 2015

Re: Wine 64 bit

by Charles Davis

> On Apr 29, 2015, at 7:25 AM, Josh DuBois <duboisj(a)codeweavers.com> wrote: > > On 4/29/15 12:40 AM, Charles Davis wrote: >> I don’t use Apple’s broken as(1), because I patch Clang, whose integrated assembler is decidedly un-broken. That’s why I never submitted a patch for that. (In fact, it’s possible to make as(1) invoke Clang to do the assembly, if you pass it the ‘-q’ switch.) > Ah. Passing -q to as gave me a raft of errors the first time I tried. Clang's assembler choked on unrecognized .stabs directives and would not assemble, but removing -gstabs+ from the compile line allows clang to assemble relay.s without changing the movq instructions by passing -q to as. I'm not familiar with the impact, if any, that will have on debugging. The problem is that dbghelp doesn’t yet know how to find dSYM companions, or that it can read the DWARF data from the object files. (That’s why we don’t use DWARF yet on Mac OS.) The latter is somewhat harder, because any addresses in the DWARF data need to be fixed up to match up with their final locations. For this reason, the linker leaves a small amount of stabs data in the final binary. (Ironic, isn’t it?) > > It still seems useful to me to be able to assemble with Apples as and compile with gcc. Is there harm in changing the various movq instructions to be compatible with Apple's as? I’m tempted to say that your fix will reduce the performance of the relays slightly (since we’re loading the XMM registers from memory instead of from registers), but then it occurred to me that since we loaded that chunk of memory recently anyway, it should be cached. My other concern is that as(1) is basically in maintenance mode now that we have Clang. (That’s why we still have bugs in it like the issue with ‘movq’ from registers.) I think Apple at some point wants to kill it off—or at least make -q the default. >> That’s great! In fact, that’s actually further than I get building with Clang—even with my patches applied to it. (It doesn’t help that Clang produces broken DWARF unwind info for Win64 ABI functions, which I really need to fix…) >> >> By the way, I can tell you right now that WoW64 won’t work quite yet. > Someone on bug 38380 claims to have gotten even father and successfully run 64-bit windows code. All of the 64-bit windows apps I tried seemed to have 32-bit installers, so I guess WoW64 is really necessary to give it a good try. All right. But even with AJ’s suggestion (using separate wine32/wine64 directories for our DLLs), libwine itself still needs to be built fat, because it’s installed directly to $(libdir). For now, I think I’ll submit my patch to configure. Chip

April 29, 2015

Re: Strange wined3d crash

by Matteo Bruni

2015-04-29 18:03 GMT+02:00 Francois Gouget <fgouget(a)free.fr>: > 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. Thanks Francois, I can reproduce. Essentially it crashes in shader_vaddline() as soon as we have to resize the buffer because vsnprintf() tries to use "args" for a second time. I attached a fix. Henri, is something like that okay with you?

April 29, 2015

Re: Strange wined3d crash

by Francois Gouget

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 "";

April 29, 2015

Re: ws2_32: Include inttypes.h for UINT32_MAX.

by Jacek Caban

On 04/29/15 15:50, Bruno Jesus wrote: > On Wed, Apr 29, 2015 at 10:44 AM, Jacek Caban <jacek(a)codeweavers.com> wrote: >> When setting the timeout, the value may be rounded. If it's rounded up >> from 0xffffffff, the value will not fit in 32-bit unsigned type. It's >> not theoretical, I've seen this happening. > Hi, Jacek. Thanks for the reply, so why can't we take care of the > overflow inside the helper function and still return an ULONG to > callers? Its callers accept different types. getsockopt uses unsigned type, so it may handle all values up to 0xffffffff. In case of sendto and recv_base, we need to pass it to poll, which accepts signed types. That's why I left handling overflows to callers. Jacek

April 29, 2015

Re: ws2_32: Include inttypes.h for UINT32_MAX.

by Bruno Jesus

On Wed, Apr 29, 2015 at 10:44 AM, Jacek Caban <jacek(a)codeweavers.com> wrote: > When setting the timeout, the value may be rounded. If it's rounded up > from 0xffffffff, the value will not fit in 32-bit unsigned type. It's > not theoretical, I've seen this happening. Hi, Jacek. Thanks for the reply, so why can't we take care of the overflow inside the helper function and still return an ULONG to callers?

April 29, 2015

Re: ws2_32: Include inttypes.h for UINT32_MAX.

by Jacek Caban

On 04/29/15 14:13, Bruno Jesus wrote: > Hi all, I don't really understand why this change was made, windows > uses 4 byte to set and get the value. It's not possible to set a value > higher than 0xffffffff When setting the timeout, the value may be rounded. If it's rounded up from 0xffffffff, the value will not fit in 32-bit unsigned type. It's not theoretical, I've seen this happening. Jacek

April 29, 2015

Re: ws2_32: Include inttypes.h for UINT32_MAX.

by Henri Verbeet

On 29 April 2015 at 12:22, Francois Gouget <fgouget(a)free.fr> wrote: > The timeout receives a 64 bit value so using an unsigned int would not > work. > Do you mean for "timeout" or for the assignment to "optval"? The current code is pretty much just broken for negative values. Since it's a timeout I'm guessing those just aren't supposed to happen, but in that case get_rcvsnd_timeo() should return a UINT64, and the assignment to "optval" should use e.g. "*(unsigned int *)optval = ...;".

April 29, 2015

Re: Wine 64 bit

by Josh DuBois

On 4/29/15 12:40 AM, Charles Davis wrote: > I don’t use Apple’s broken as(1), because I patch Clang, whose integrated assembler is decidedly un-broken. That’s why I never submitted a patch for that. (In fact, it’s possible to make as(1) invoke Clang to do the assembly, if you pass it the ‘-q’ switch.) Ah. Passing -q to as gave me a raft of errors the first time I tried. Clang's assembler choked on unrecognized .stabs directives and would not assemble, but removing -gstabs+ from the compile line allows clang to assemble relay.s without changing the movq instructions by passing -q to as. I'm not familiar with the impact, if any, that will have on debugging. It still seems useful to me to be able to assemble with Apples as and compile with gcc. Is there harm in changing the various movq instructions to be compatible with Apple's as? > That’s great! In fact, that’s actually further than I get building with Clang—even with my patches applied to it. (It doesn’t help that Clang produces broken DWARF unwind info for Win64 ABI functions, which I really need to fix…) > > By the way, I can tell you right now that WoW64 won’t work quite yet. Someone on bug 38380 claims to have gotten even father and successfully run 64-bit windows code. All of the 64-bit windows apps I tried seemed to have 32-bit installers, so I guess WoW64 is really necessary to give it a good try.

April 29, 2015

Re: USB Support

by Joel Holdsworth

> Thanks for the tip. I picked up a used usb protocol analyzer for a good > price to diagnose the immediate problem (lots of NAKs at an unexpected > time) but I'd still like to pursue getting USB support into wine and not > have to depend on a Windows box (or VM) for any part of the project. > Fair enough. Well I happen to know Peter Stuge who is the guy behind libusb (http://www.libusb.org/) He tends to hang out at #sigrok under the username "CareBear\" . I would recommend having a chat with him. Joel

April 29, 2015

Re: ws2_32: Include inttypes.h for UINT32_MAX.

by Bruno Jesus

On Wed, Apr 29, 2015 at 7:22 AM, Francois Gouget <fgouget(a)free.fr> wrote: > On Wed, 29 Apr 2015, Henri Verbeet wrote: > [...] >> 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. > > The timeout receives a 64 bit value so using an unsigned int would not > work. But using UINT_MAX plus the native limits.h can work. Hi all, I don't really understand why this change was made, windows uses 4 byte to set and get the value. It's not possible to set a value higher than 0xffffffff, actually I don't even now if that value is valid, only tests can tell the truth. Unless this is a very specific broken application that uses the mysterious unixism hack from socket.c: 5295 } else if (optlen == sizeof(struct timeval)) { 5296 WARN("SO_SND/RCVTIMEO for %d bytes: assuming unixism\n", optlen); Best wishes, Bruno

April 29, 2015

Re: USB Support

by Steve Kenton

On 4/29/2015 4:27 AM, Joel Holdsworth wrote: > >> I got into this because I'm writing firmware for a custom USB device >> to use in an embedded Linux system and the vendor tools are only >> available for Windows. Sigh. And of course Wine handles everything >> fine *except* the USB snooping. I've spent my entire professional >> life working the in Unix workstation & HPC world staring with PDP-11 and >> later VAX "boot me" tapes from Bell Labs / Western Electric. I think >> the last time I had to write a Windows GUI app was when the original >> Windows 95 was released :-( So I'm woefully out of date on Windows. > > I probably shouldn't tell you this because I *really* want USB support > in Wine, but you can currently do this currently using a VM. Run your > application in a Windows in VirtualBox, then you can use Linux's > usbmon to sniff the traffic. > > To do the capture I usually start off with wireshark, and then use > this command line tool that I maintain: > > https://github.com/jhol/usbdump > > With a command line packet trace, you can then do greps, diffs, vidiff > etc. to reverse engineer the protocol. > > Kind Regards > Joel > > Thanks for the tip. I picked up a used usb protocol analyzer for a good price to diagnose the immediate problem (lots of NAKs at an unexpected time) but I'd still like to pursue getting USB support into wine and not have to depend on a Windows box (or VM) for any part of the project. Steve

April 29, 2015

Strange wined3d crash

by Francois Gouget

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.

April 29, 2015

Re: ws2_32: Include inttypes.h for UINT32_MAX.

by Francois Gouget

On Wed, 29 Apr 2015, Henri Verbeet wrote: [...] > 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. The timeout receives a 64 bit value so using an unsigned int would not work. But using UINT_MAX plus the native limits.h can work. static inline INT64 get_rcvsnd_timeo( int fd, BOOL is_recv) ... timeout = get_rcvsnd_timeo(fd, optname == WS_SO_RCVTIMEO); *(int *)optval = timeout <= UINT32_MAX ? timeout : UINT32_MAX; -- 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.

April 29, 2015

Re: ws2_32: Include inttypes.h for UINT32_MAX.

by Henri Verbeet

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.

April 29, 2015

Re: USB Support

by Joel Holdsworth

> I got into this because I'm writing firmware for a custom USB device > to use in an embedded Linux system and the vendor tools are only > available for Windows. Sigh. And of course Wine handles everything > fine *except* the USB snooping. I've spent my entire professional > life working the in Unix workstation & HPC world staring with PDP-11 and > later VAX "boot me" tapes from Bell Labs / Western Electric. I think > the last time I had to write a Windows GUI app was when the original > Windows 95 was released :-( So I'm woefully out of date on Windows. I probably shouldn't tell you this because I *really* want USB support in Wine, but you can currently do this currently using a VM. Run your application in a Windows in VirtualBox, then you can use Linux's usbmon to sniff the traffic. To do the capture I usually start off with wireshark, and then use this command line tool that I maintain: https://github.com/jhol/usbdump With a command line packet trace, you can then do greps, diffs, vidiff etc. to reverse engineer the protocol. Kind Regards Joel

April 29, 2015

Re: USB Support

by Uwe Bonnes

>>>>> "Steve" == Steve Kenton <skenton(a)ou.edu> writes: Steve> I got into this because I'm writing firmware for a custom USB Steve> device to use in an embedded Linux system and the vendor tools Steve> are only available for Windows. Sigh. And of course Wine handles Steve> everything fine *except* the USB snooping. I've spent my entire Steve> professional life working the in Unix workstation & HPC world Steve> staring with PDP-11 and later VAX "boot me" tapes from Bell Labs Steve> / Western Electric. I think the last time I had to write a Steve> Windows GUI app was when the original Windows 95 was released :-( Steve> So I'm woefully out of date on Windows. Steve> Uwe Bonnes made this comment in another email: Steve> "Newer usb devices often use winusb for usb communication. A Steve> translation dll winusb->libusb is thinkable. However the problem Steve> of device detection remains." Steve> Crawling through /sys and /proc or writing a device driver shim I Steve> think I can handle, Displaying the information or adding it to Steve> the registry is is murky (to me) which is why I'm looking at such Steve> a bass-ackwards approach. Probably the USB device handling is devided into a DLL for USB access and the programm itself using the DLL. Perhaps the DLL API is public or you may get it with some kind of NDA from the vendor. In that case writing a replacement DLL is also an option. This is not generic at all, but may solve your problem. Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

April 29, 2015

Re: user32: After handling an internal message give a chance to real message to arrive.

by Dmitry Timoshkov

Alexandre Julliard <julliard(a)winehq.org> wrote: > >> I may have one, once I understand what you are trying to fix. What is > >> the actual problem that prompted you to write the tests and the fix? > > > > The problem is described in the first test for sending inter-thread > > messages: https://www.winehq.org/pipermail/wine-patches/2015-April/138750.html > > My original guess was that the problem is caused by internal message > > handling in Wine, and the tests I created confirmed that there is a problem > > in that area. The patch we are discussing fixes the problem discovered > > by these tests. > > I still don't understand why internal messages would be different. Is > that because you get only one inter-thread message instead of several? The problem is that once Get/PeekMessage handles an internal message it doesn't yield control to another thread and checks the message queue immediately, this misses a sent message from another thread and instead returns a previously posted one. I admit that this is a pure artificial thing that I stumbled upon, but it reveals a real bug in Wine with internal message handling. > I think it would be better to try to write a test that replicates the > problem you are seeing. I tried to simplify the tests since calling EndDialog+GetMessage+DestroyMessage from different threads may create pretty complicated scenarios, and most obvious (to me) things to test are SendMessage+Get/PeekMessage and SetWindowPos+ Get/PeekMessage from different threads are two cases that should cover things that I think may lead to the observed bug(s). I can sertainly add more tests, but only when already sent ones are accepted to avoid creating conflicts and resending them again. > In particular, testing GetQueueStatus instead of > message sequences is not very convincing to me, since it doesn't > properly show what's going on. I tried to test both as much as possible, did I miss some cases where one of GetQueueStatus or a message sequence is not tested? -- Dmitry.

April 29, 2015

Re: [PATCH] wined3d: fix different level count while texture update

by Henri Verbeet

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.

April 29, 2015

Re: [PATCH] wined3d: fix Unrecognized usage flags

by Henri Verbeet

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().

April 29, 2015

Re: Wine 64 bit

by Alexandre Julliard

Charles Davis <cdavis5x(a)gmail.com> writes: > By the way, I can tell you right now that WoW64 won’t work quite > yet. Mac OS has no separate lib32/lib64 directories, so we need to > produce fat DLLs. I have another patch (also attached) to teach > kernel32 to recognize fat binaries, but there’s no build system > infrastructure for making fat DLLs yet. If you want to try out WoW64, > you’ll have to do that manually with lipo(1). (I’ve actually submitted > this second patch, but AJ hasn’t taken it. I guess he’s unconvinced > that it’s correct. Maybe if we try out WoW64 and it works, he’ll be > more convinced. ;) You'd have to make a more convincing argument for this. Not having lib32/lib64 is not an issue since Wine is looking for dlls in its own directory anyway. It would be trivial to use lib/wine32 and lib/wine64 or some similar scheme. -- Alexandre Julliard julliard(a)winehq.org

April 29, 2015

Re: Wine 64 bit

by Charles Davis

Sorry for the belated response. GCC takes forever to build on my system. > On Apr 28, 2015, at 8:26 AM, Josh DuBois <duboisj(a)codeweavers.com> wrote: > > > I was interested in compiling 64-bit wine on OS X the other day and hit some problems, so I thought I would resurrect this thread. I used gcc 4.8 from macports, because as far as I could tell there wasn't a chance of using any version of clang without patching it. Using gcc I hit winehq bug 38380 right away: > > https://bugs.winehq.org/show_bug.cgi?id=38380 > > With Ken's help I tried the attached patch, which allowed a few places where wine has assembly code calling 64-bit windows functions to assemble with Apple's broken assembler. I don’t use Apple’s broken as(1), because I patch Clang, whose integrated assembler is decidedly un-broken. That’s why I never submitted a patch for that. (In fact, it’s possible to make as(1) invoke Clang to do the assembly, if you pass it the ‘-q’ switch.) I still need to get my __ms_va_list patches upstream into LLVM/Clang, but there’s a big rewrite going on related to pointer types in LLVM IR that affects my patch (i.e. it’ll make it simpler), so I’m waiting for that to go through first. > > The only other problem I hit was the pagezero thing discussed below: > > On 1/23/15 12:03 AM, cdavis5x(a)gmail.com wrote: >>>> 0003-configure-Support-64-bit-compilation-on-Mac-OS.patch >>> Regarding the -pagezero_size option: 1) it might as well be unconditional. The 32-bit code assumes a 4096-byte page-zero, implicit in the base address of WINE_DOS. >> It’s conditional in my tree because I have another patch that turns off the __PAGEZERO segment, then sticks the WINE_DOS segment at address 0. I submitted that patch once, but Alexandre rejected it because we lack V86 support anyway on Mac OS, so what’s it matter if Win16 and Win9x programs can’t access the IVT, BDA or DOS Data Segment? :) I guess I could make it unconditional (since he’s not going to take my patch to make it 0 on 32-bit), but it’d be redundant on 32-bit, because the default size of the __PAGEZERO segment there is 4k. > Did any resolution to this problem ever appear? Just now, attached to this email. ;) (NOTE: You’ll have to regenerate configure after applying this change.) > If that were fixed and we had a workaround for the broken Apple assembler, I think you could compile and test 64-bit wine on OS X. (The mac driver still won't compile without clang, but passing --disable-winemac.drv at least allowed use of the X11 driver.) > > I haven't tested much so far, but I at least got a working prefix and ran notepad (once with relay logging, even). That’s great! In fact, that’s actually further than I get building with Clang—even with my patches applied to it. (It doesn’t help that Clang produces broken DWARF unwind info for Win64 ABI functions, which I really need to fix…) By the way, I can tell you right now that WoW64 won’t work quite yet. Mac OS has no separate lib32/lib64 directories, so we need to produce fat DLLs. I have another patch (also attached) to teach kernel32 to recognize fat binaries, but there’s no build system infrastructure for making fat DLLs yet. If you want to try out WoW64, you’ll have to do that manually with lipo(1). (I’ve actually submitted this second patch, but AJ hasn’t taken it. I guess he’s unconvinced that it’s correct. Maybe if we try out WoW64 and it works, he’ll be more convinced. ;) Chip

April 29, 2015

Re: [PATCH] comdlg32: Change "Borders" to "Margins".

by Alexandre Julliard

Alex Henrie <alexhenrie24(a)gmail.com> writes: > 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? If the string is not used, then of course it's better to remove it. -- Alexandre Julliard julliard(a)winehq.org

April 29, 2015

Re: USB Support

by Steve Kenton

On 04/25/2015 05:22 AM, Saulius Krasuckas wrote: > * On Tue, 14 Apr 2015, Steve Kenton wrote: >> On 04/14/2015 06:04 PM, Saulius Krasuckas wrote: >>> * On Sun, 12 Apr 2015, Steve Kenton wrote: >>>> I spent some more time looking at this last night and it looks like >>>> the registry enum keys are about every device ever plugged into the >>>> system, whether it's currently present or not and the actual Windows >>>> device tree is maintained in memory, so just the registry keys >>>> probably won't suffice. >>> >>> Steve, it won't of course. But this is the first required step. I >>> would say that another way: >>> >>> let's make the HwDetect [6] (custom program) work in Wine the same way >>> it works in Windows (except for disabling devices -- just the >>> monitoring part). It reads very small amount of data from "Enum\USB" >>> subkey (I guess). >>> >>> Another step might be fixing Wine so "USB Device Tree Viewer" [7] >>> works as in Windows. But this one looks like a lot more complicated >>> testcase. > ... >>> [6] http://www.codeproject.com/Articles/14500/Detecting-Hardware-Insertion-and-… >>> [7] http://www.uwe-sieber.de/usbtreeview_e.html >>> >> I was thinking along those same lines with something like the display >> portion of Windows Device Manager. ~wine/server/device.c has some >> routines for managing devices, I need to spend some more time >> understanding the current state of things. But yes, it does look like a >> good place to start. > > In bug report 37724 Henrik Haftmann talks [8] about similar issue and > offers code excerpt which uses related functions: > > SetupDiGetClassDevs() > SetupDiEnumDeviceInfo() > SetupDiOpenDevRegKey() > SetupDiDestroyDeviceInfoList() > SetupDiEnumDeviceInterfaces() > SetupDiGetDeviceInterfaceDetail() > > You might be interested in collaboration:) > > S. > > [8] https://bugs.winehq.org/show_bug.cgi?id=37724 > Actually, I think I'll come at it starting with a modified regedit so I can get familiar with the Windows API and GUI while displaying device information. And hopefully get a handle on the registry while I'm at it. I got into this because I'm writing firmware for a custom USB device to use in an embedded Linux system and the vendor tools are only available for Windows. Sigh. And of course Wine handles everything fine *except* the USB snooping. I've spent my entire professional life working the in Unix workstation & HPC world staring with PDP-11 and later VAX "boot me" tapes from Bell Labs / Western Electric. I think the last time I had to write a Windows GUI app was when the original Windows 95 was released :-( So I'm woefully out of date on Windows. Uwe Bonnes made this comment in another email: "Newer usb devices often use winusb for usb communication. A translation dll winusb->libusb is thinkable. However the problem of device detection remains." Crawling through /sys and /proc or writing a device driver shim I think I can handle, Displaying the information or adding it to the registry is is murky (to me) which is why I'm looking at such a bass-ackwards approach. Steve

April 29, 2015

Re: user32: After handling an internal message give a chance to real message to arrive.

by Alexandre Julliard

Dmitry Timoshkov <dmitry(a)baikal.ru> writes: > Alexandre Julliard <julliard(a)winehq.org> wrote: > >> I may have one, once I understand what you are trying to fix. What is >> the actual problem that prompted you to write the tests and the fix? > > The problem is described in the first test for sending inter-thread > messages: https://www.winehq.org/pipermail/wine-patches/2015-April/138750.html > My original guess was that the problem is caused by internal message > handling in Wine, and the tests I created confirmed that there is a problem > in that area. The patch we are discussing fixes the problem discovered > by these tests. I still don't understand why internal messages would be different. Is that because you get only one inter-thread message instead of several? I think it would be better to try to write a test that replicates the problem you are seeing. In particular, testing GetQueueStatus instead of message sequences is not very convincing to me, since it doesn't properly show what's going on. -- Alexandre Julliard julliard(a)winehq.org

April 29, 2015

Re: [PATCH] comdlg32: Change "Borders" to "Margins".

by Alex Henrie

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

April 28, 2015

Re: Wine 64 bit

by Josh DuBois

I was interested in compiling 64-bit wine on OS X the other day and hit some problems, so I thought I would resurrect this thread. I used gcc 4.8 from macports, because as far as I could tell there wasn't a chance of using any version of clang without patching it. Using gcc I hit winehq bug 38380 right away: https://bugs.winehq.org/show_bug.cgi?id=38380 With Ken's help I tried the attached patch, which allowed a few places where wine has assembly code calling 64-bit windows functions to assemble with Apple's broken assembler. The only other problem I hit was the pagezero thing discussed below: On 1/23/15 12:03 AM, cdavis5x(a)gmail.com wrote: >>> 0003-configure-Support-64-bit-compilation-on-Mac-OS.patch >> Regarding the -pagezero_size option: 1) it might as well be unconditional. The 32-bit code assumes a 4096-byte page-zero, implicit in the base address of WINE_DOS. > It’s conditional in my tree because I have another patch that turns off the __PAGEZERO segment, then sticks the WINE_DOS segment at address 0. I submitted that patch once, but Alexandre rejected it because we lack V86 support anyway on Mac OS, so what’s it matter if Win16 and Win9x programs can’t access the IVT, BDA or DOS Data Segment? :) I guess I could make it unconditional (since he’s not going to take my patch to make it 0 on 32-bit), but it’d be redundant on 32-bit, because the default size of the __PAGEZERO segment there is 4k. Did any resolution to this problem ever appear? If that were fixed and we had a workaround for the broken Apple assembler, I think you could compile and test 64-bit wine on OS X. (The mac driver still won't compile without clang, but passing --disable-winemac.drv at least allowed use of the X11 driver.) I haven't tested much so far, but I at least got a working prefix and ran notepad (once with relay logging, even).

April 28, 2015

Re: [PATCH] comdlg32: Change "Borders" to "Margins".

by Alexandre Julliard

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. -- Alexandre Julliard julliard(a)winehq.org

April 28, 2015

Re: include: Added IShellFolderViewDual definition

by Nikolay Sivov

On 04/28/2015 12:30 PM, Marvin wrote: > Hi, > > While running your changed tests on Windows, I think I found new failures. > Being a bot and all I'm not very good at pattern recognition, so I might be > wrong, but could you please double-check? > Full results can be found at > https://testbot.winehq.org/JobDetails.pl?Key=13085 > > Your paranoid android. > > > === build (build) === > Patch failed to apply > I had another patch in a queue that broke this one, will resend.

April 28, 2015

Re: [PATCH 5/5] d3d9/tests: Add spotlight and light range tests.

by Henri Verbeet

On 27 April 2015 at 17:39, Matteo Bruni <mbruni(a)codeweavers.com> wrote: > + static const float pi = 3.141592654f; I guess you'll have to resubmit this for the testbot, but while you're at it, I think I prefer M_PI.

April 28, 2015

Re: include: Added IShellFolderViewDual definition

by Marvin

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

April 28, 2015

Re: [PATCH 3/6] dmloader: Add and use a generic IPersistStream_GetClassID.

by Marvin

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

April 27, 2015

Re: [PATCH 2/6] dmloader/tests: Add more DirectMusicCollection tests.

by Marvin

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

April 27, 2015

Re: [PATCH 1/6] dmloader: Use the generic DirectMusicObject implementation for DMContainer.

by Marvin

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

April 27, 2015

jscript: Date.parse: long date with '/' or '-'

by Thomas Faller

Am 25.04.2015 um 18:43 schrieb Stefan Dösinger: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Am 2015-04-25 um 17:45 schrieb Thomas Faller: >> This format is not documented under >> >> https://msdn.microsoft.com/en-us/library/k4w173wk%28v=vs.84%29.aspx >> >> but its implemented in the internet explorer and in the windows >> script host. > In this case a test would be very useful. > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2 > > iQIcBAEBAgAGBQJVO8QzAAoJEN0/YqbEcdMwl4EP/1+xPW5sSLx86MPGq8e1eXCx > 7ON4cSV1u0IIAnw1qMc/VuUxxHw3LN6VSrBN8Rbq6XxXx/1fLvaIz7+ckdBvOz3c > QhregFjv7kBsRs3WCDuz8SujMMCeBL0FdeAg7xuWl61mHRKxkaeBNROHlfPxG7GE > fYBdOTUPzdEj8eYTB48xozHPMV3EadpO7GL+742upv4qxJa3m7V2ZU3/+4O1atjE > +yZyVKEwxKU6PLJNMMzva/TpQPxIEPsKg2L3hFAXnZXjn6lJeew6PWGQiR/OpNR0 > HLQcdGk3xQlslefauJpJ6ffSyHl+wRrK7DUpUDsNAQuWQ4ALwHsjkFGG8ph8xRL4 > aMnnA+afBU2VXnVpkmnjHlILIaWtCejMo4zveXjD1dk15CeOcs2ezasxhbbl9FUl > HySkMNyX6gX07BfR6e9N5gwCzHdOj0GbvRtPMcRXWkPwgzj47xX4NbT0QT8ncg2a > lsey/aE8aEscUwGROWm9xv7egKxdBM5kxccBxAMFY1Z5MBNbntlMVTwKERWAl1q9 > sRjf77vuuD8LIyXpntqVOb96Hq+4mIo0VzAClFOqSIf6bv8fPz8oFD1elE6G3M4W > cXH620URbzXsXg4ZBVRUP6t5sIy5jnSZG+I5h0BUxSizw5ekxbKWlfCicFSZStbu > Ln6ptTTJVzUg3QpSR6jN > =a7ty > -----END PGP SIGNATURE----- The TestBot test was positive (https://testbot.winehq.org/JobDetails.pl?Key=13063) Dates like 1970/01/01 were parsed by jscript as expected here.

April 27, 2015

Re: jscript: Date.parse: long date with '/' or '-'

by Thomas Faller

Am 25.04.2015 um 18:43 schrieb Stefan Dösinger: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Am 2015-04-25 um 17:45 schrieb Thomas Faller: >> This format is not documented under >> >> https://msdn.microsoft.com/en-us/library/k4w173wk%28v=vs.84%29.aspx >> >> but its implemented in the internet explorer and in the windows >> script host. > In this case a test would be very useful. > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2 > > iQIcBAEBAgAGBQJVO8QzAAoJEN0/YqbEcdMwl4EP/1+xPW5sSLx86MPGq8e1eXCx > 7ON4cSV1u0IIAnw1qMc/VuUxxHw3LN6VSrBN8Rbq6XxXx/1fLvaIz7+ckdBvOz3c > QhregFjv7kBsRs3WCDuz8SujMMCeBL0FdeAg7xuWl61mHRKxkaeBNROHlfPxG7GE > fYBdOTUPzdEj8eYTB48xozHPMV3EadpO7GL+742upv4qxJa3m7V2ZU3/+4O1atjE > +yZyVKEwxKU6PLJNMMzva/TpQPxIEPsKg2L3hFAXnZXjn6lJeew6PWGQiR/OpNR0 > HLQcdGk3xQlslefauJpJ6ffSyHl+wRrK7DUpUDsNAQuWQ4ALwHsjkFGG8ph8xRL4 > aMnnA+afBU2VXnVpkmnjHlILIaWtCejMo4zveXjD1dk15CeOcs2ezasxhbbl9FUl > HySkMNyX6gX07BfR6e9N5gwCzHdOj0GbvRtPMcRXWkPwgzj47xX4NbT0QT8ncg2a > lsey/aE8aEscUwGROWm9xv7egKxdBM5kxccBxAMFY1Z5MBNbntlMVTwKERWAl1q9 > sRjf77vuuD8LIyXpntqVOb96Hq+4mIo0VzAClFOqSIf6bv8fPz8oFD1elE6G3M4W > cXH620URbzXsXg4ZBVRUP6t5sIy5jnSZG+I5h0BUxSizw5ekxbKWlfCicFSZStbu > Ln6ptTTJVzUg3QpSR6jN > =a7ty > -----END PGP SIGNATURE----- The TestBot test was positive (https://testbot.winehq.org/JobDetails.pl?Key=13063) Dates like 1970/01/01 were parsed by jscript as expected here.

April 27, 2015

Re: [PATCH 2/2] winemac: Don't pump messages in ChangeDisplaySettings (v3).

by Ken Thomases

On Apr 27, 2015, at 2:54 AM, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > Version 3: Use SendNotifyMessage for sending WM_MACDRV_DISPLAYCHANGE. > Ken, I need your review again to make sure that this change doesn't > have any negative impact regarding the sync_window_position call that > is part of the WM_MACDRV_DISPLAYCHANGE message handling. Looks OK to me. It is not necessary for the sync_window_position() call to be made synchronously with respect to the sending code. -Ken

April 27, 2015

Re: [PATCH 5/5] d3d9/tests: Add spotlight and light range tests.

by Matteo Bruni

2015-04-27 17:54 GMT+02:00 Marvin <testbot(a)winehq.org>: > 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=13061 > > Your paranoid android. > > > === build (build) === > Patch failed to apply It looks like the testbot failed the update to today's git: http://testbot.winehq.org/JobDetails.pl?Key=13049.

April 27, 2015

Re: [PATCH 5/5] d3d9/tests: Add spotlight and light range tests.

by Marvin

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

April 27, 2015

Re: user32: After handling an internal message give a chance to real message to arrive.

by Dmitry Timoshkov

Alexandre Julliard <julliard(a)winehq.org> wrote: > >> >> Why do you need to leave the function instead of checking for further > >> >> messages? What is the issue you are seeing? > >> > > >> > If you mean the only quoted piece of code (MSG_POSTED case) then only > >> > reason of the change is to make it consistent with the sent message case. > >> > >> I don't really see any reason to make it consistent, but I'd like to > >> know why you need the other one too. > > > > The other one is needed to make the test pass for the sent message case. > > If you have a suggestion how fix it differently please let me know. > > I may have one, once I understand what you are trying to fix. What is > the actual problem that prompted you to write the tests and the fix? The problem is described in the first test for sending inter-thread messages: https://www.winehq.org/pipermail/wine-patches/2015-April/138750.html My original guess was that the problem is caused by internal message handling in Wine, and the tests I created confirmed that there is a problem in that area. The patch we are discussing fixes the problem discovered by these tests. Another guess was that it's a race between EndDialog and DestroyWindow leading to a crash. According to my tests under Windows EndDialog called from another thread never returns. At the moment I'm inclined to another theory about the source of the problem: it's the implementation of SetWindowPos called for another thread window, and the tests+patches I sent today confirm that. Moreover it looks like the real fix for the problem. There are other discovered problems caused by DestroyWindow from window's thread+SendMessage from another thread, but let's leave them aside for the time being. -- Dmitry.

April 27, 2015

Re: user32: After handling an internal message give a chance to real message to arrive.

by Alexandre Julliard

Dmitry Timoshkov <dmitry(a)baikal.ru> writes: > Alexandre Julliard <julliard(a)winehq.org> wrote: > >> >> > @@ -2931,7 +2931,10 @@ static BOOL peek_message( MSG *msg, HWND hwnd, UINT first, UINT last, UINT flags >> >> > else >> >> > peek_message( msg, info.msg.hwnd, info.msg.message, >> >> > info.msg.message, flags | PM_REMOVE, changed_mask ); >> >> > - continue; >> >> > + >> >> > + /* give a chance to real message to arrive */ >> >> > + HeapFree( GetProcessHeap(), 0, buffer ); >> >> > + return FALSE; >> >> >> >> Why do you need to leave the function instead of checking for further >> >> messages? What is the issue you are seeing? >> > >> > If you mean the only quoted piece of code (MSG_POSTED case) then only >> > reason of the change is to make it consistent with the sent message case. >> >> I don't really see any reason to make it consistent, but I'd like to >> know why you need the other one too. > > The other one is needed to make the test pass for the sent message case. > If you have a suggestion how fix it differently please let me know. I may have one, once I understand what you are trying to fix. What is the actual problem that prompted you to write the tests and the fix? -- Alexandre Julliard julliard(a)winehq.org

April 27, 2015

Re: user32: After handling an internal message give a chance to real message to arrive.

by Dmitry Timoshkov

Alexandre Julliard <julliard(a)winehq.org> wrote: > >> > @@ -2931,7 +2931,10 @@ static BOOL peek_message( MSG *msg, HWND hwnd, UINT first, UINT last, UINT flags > >> > else > >> > peek_message( msg, info.msg.hwnd, info.msg.message, > >> > info.msg.message, flags | PM_REMOVE, changed_mask ); > >> > - continue; > >> > + > >> > + /* give a chance to real message to arrive */ > >> > + HeapFree( GetProcessHeap(), 0, buffer ); > >> > + return FALSE; > >> > >> Why do you need to leave the function instead of checking for further > >> messages? What is the issue you are seeing? > > > > If you mean the only quoted piece of code (MSG_POSTED case) then only > > reason of the change is to make it consistent with the sent message case. > > I don't really see any reason to make it consistent, but I'd like to > know why you need the other one too. The other one is needed to make the test pass for the sent message case. If you have a suggestion how fix it differently please let me know. -- Dmitry.

April 27, 2015

Re: user32: After handling an internal message give a chance to real message to arrive.

by Alexandre Julliard

Dmitry Timoshkov <dmitry(a)baikal.ru> writes: > Alexandre Julliard <julliard(a)winehq.org> wrote: > >> > @@ -2931,7 +2931,10 @@ static BOOL peek_message( MSG *msg, HWND hwnd, UINT first, UINT last, UINT flags >> > else >> > peek_message( msg, info.msg.hwnd, info.msg.message, >> > info.msg.message, flags | PM_REMOVE, changed_mask ); >> > - continue; >> > + >> > + /* give a chance to real message to arrive */ >> > + HeapFree( GetProcessHeap(), 0, buffer ); >> > + return FALSE; >> >> Why do you need to leave the function instead of checking for further >> messages? What is the issue you are seeing? > > If you mean the only quoted piece of code (MSG_POSTED case) then only > reason of the change is to make it consistent with the sent message case. I don't really see any reason to make it consistent, but I'd like to know why you need the other one too. -- Alexandre Julliard julliard(a)winehq.org

April 27, 2015

Re: user32: After handling an internal message give a chance to real message to arrive.

by Dmitry Timoshkov

Alexandre Julliard <julliard(a)winehq.org> wrote: > > @@ -2931,7 +2931,10 @@ static BOOL peek_message( MSG *msg, HWND hwnd, UINT first, UINT last, UINT flags > > else > > peek_message( msg, info.msg.hwnd, info.msg.message, > > info.msg.message, flags | PM_REMOVE, changed_mask ); > > - continue; > > + > > + /* give a chance to real message to arrive */ > > + HeapFree( GetProcessHeap(), 0, buffer ); > > + return FALSE; > > Why do you need to leave the function instead of checking for further > messages? What is the issue you are seeing? If you mean the only quoted piece of code (MSG_POSTED case) then only reason of the change is to make it consistent with the sent message case. -- Dmitry.

April 27, 2015

Re: user32: After handling an internal message give a chance to real message to arrive.

by Alexandre Julliard

Dmitry Timoshkov <dmitry(a)baikal.ru> writes: > @@ -2931,7 +2931,10 @@ static BOOL peek_message( MSG *msg, HWND hwnd, UINT first, UINT last, UINT flags > else > peek_message( msg, info.msg.hwnd, info.msg.message, > info.msg.message, flags | PM_REMOVE, changed_mask ); > - continue; > + > + /* give a chance to real message to arrive */ > + HeapFree( GetProcessHeap(), 0, buffer ); > + return FALSE; Why do you need to leave the function instead of checking for further messages? What is the issue you are seeing? -- Alexandre Julliard julliard(a)winehq.org

April 27, 2015

Re: shell32: Add Association Registry entries (resend)

by Marvin

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

April 27, 2015

Re: [PATCH 1/2] winex11: Don't pump messages in ChangeDisplaySettings (v3).

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=13041 Your paranoid android. === w8 (32 bit sysparams) === sysparams.c:2497: Test failed: Waiting for the WM_DISPLAYCHANGE message timed out sysparams.c:2510: Test failed: Set bpp 32, but WM_DISPLAYCHANGE reported bpp -1

April 27, 2015

Re: [3/3] user32: Don't perform SetWindowPos synchronously.

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=13038 Your paranoid android. === w7u (32 bit msg) === msg.c:12230: Test failed: unexpected hwnd 0017014A msg.c:12252: Test failed: bad time 31267/31276

April 27, 2015

Re: [1/3] user32/tests: Add a test for calling SetWindowPos for other thread window.

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=13037 Your paranoid android. === w7u (32 bit msg) === msg.c:12230: Test failed: unexpected hwnd 00150136 msg.c:12252: Test failed: bad time 31100/3111f

April 27, 2015

Re: [PATCH 4/5] wined3d: Don't use the builtin FFP uniforms for texture transformation matrices. (v3)

by Henri Verbeet

On 24 April 2015 at 22:25, Matteo Bruni <mbruni(a)codeweavers.com> wrote: > +static void shader_glsl_ffp_vertex_texmatrix_uniform(const struct wined3d_context *context, > + const struct wined3d_state *state, unsigned int tex, struct glsl_shader_prog_link *prog) > +{ > + const struct wined3d_gl_info *gl_info = context->gl_info; > + struct wined3d_matrix mat; > + > + if (tex >= MAX_TEXTURES) > + return; I think the patch is fine as it is, but as a style comment, arguably you aren't so much validating "tex" against MAX_TEXTURES here as against ARRAY_SIZE(texture_matrix_location).

April 26, 2015

Re: [PATCH] wined3d: fix wrong struct initialization

by Henri Verbeet

On 26 April 2015 at 12:22, Patrick Rudolph <siro(a)das-labor.org> wrote: > - static const struct wined3d_query_data_timestamp_disjoint > disjoint_data = {FALSE, 1000 * 1000 * 1000}; > + static const struct wined3d_query_data_timestamp_disjoint > disjoint_data = {1000 * 1000 * 1000, FALSE}; The change is fine like this, but unfortunately it looks like your MUA has wrapped the patch.

April 26, 2015

Re: advapi32/tests: Add tests for RegQueryInfoKey.

by Thomas Faber

On 2015-04-25 21:15, Nikolay Sivov wrote: > On 04/25/2015 08:41 PM, Thomas Faber wrote: >> + todo_wine ok(classbuffer[0] == 's', "classbuffer[0] = 0x%x\n", classbuffer[0]); >> + todo_wine ok(classbuffer[1] == 'u', "classbuffer[1] = 0x%x\n", classbuffer[1]); >> + todo_wine ok(classbuffer[10] == 's', "classbuffer[10] = 0x%x\n", classbuffer[10]); >> + todo_wine ok(classbuffer[11] == 0, "classbuffer[11] = 0x%x\n", classbuffer[11]); >> + ok(classbuffer[12] == 0x55, "classbuffer[12] = 0x%x\n", classbuffer[12]); > > I think it would be more readable if you tested it against a string. > Also hardcoded offsets could be avoided in this case. Yeah it seemed simpler to do it by hand initially but you're right. I'll send an updated version. >> + ok(classbufferW[0] == 0x5555, "classbufferW[0] = 0x%x\n", classbufferW[0]); >> + ok(classbufferW[1] == 0x5555, "classbufferW[1] = 0x%x\n", classbufferW[1]); >> + ok(classbufferW[10] == 0x5555, "classbufferW[10] = 0x%x\n", classbufferW[10]); >> + ok(classbufferW[11] == 0x5555, "classbufferW[11] = 0x%x\n", classbufferW[11]); >> + ok(classbufferW[12] == 0x5555, "classbufferW[12] = 0x%x\n", classbufferW[12]); > > If first element is not changed, it's really unlikely that anything else > did. This was for consistency with the ansi version. But the other change will take care of it in any case. Thanks! -Thomas

April 26, 2015

Re: advapi32/tests: Add tests for RegQueryInfoKey.

by Nikolay Sivov

On 04/25/2015 08:41 PM, Thomas Faber wrote: > + /* class name with buffer one char too small */ > + memset(classbuffer, 0x55, sizeof(classbuffer)); > + classlen = sizeof(subkey_class) - 1; > + ret = RegQueryInfoKeyA(subkey, classbuffer, &classlen, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL); > + ok(ret == ERROR_MORE_DATA, "ret = %d\n", ret); > + todo_wine ok(classlen == sizeof(subkey_class) - 2, "classlen = %u\n", classlen); > + todo_wine ok(classbuffer[0] == 's', "classbuffer[0] = 0x%x\n", classbuffer[0]); > + todo_wine ok(classbuffer[1] == 'u', "classbuffer[1] = 0x%x\n", classbuffer[1]); > + todo_wine ok(classbuffer[10] == 's', "classbuffer[10] = 0x%x\n", classbuffer[10]); > + todo_wine ok(classbuffer[11] == 0, "classbuffer[11] = 0x%x\n", classbuffer[11]); > + ok(classbuffer[12] == 0x55, "classbuffer[12] = 0x%x\n", classbuffer[12]); I think it would be more readable if you tested it against a string. Also hardcoded offsets could be avoided in this case. > + memset(classbufferW, 0x55, sizeof(classbufferW)); > + classlen = sizeof(subkey_class) - 1; > + ret = RegQueryInfoKeyW(subkey, classbufferW, &classlen, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL); > + todo_wine ok(ret == ERROR_INSUFFICIENT_BUFFER, "ret = %d\n", ret); > + ok(classlen == sizeof(subkey_class) - 2 /* win8 */ || > + classlen == strlen(subkey_class), "classlen = %u\n", classlen); > + ok(classbufferW[0] == 0x5555, "classbufferW[0] = 0x%x\n", classbufferW[0]); > + ok(classbufferW[1] == 0x5555, "classbufferW[1] = 0x%x\n", classbufferW[1]); > + ok(classbufferW[10] == 0x5555, "classbufferW[10] = 0x%x\n", classbufferW[10]); > + ok(classbufferW[11] == 0x5555, "classbufferW[11] = 0x%x\n", classbufferW[11]); > + ok(classbufferW[12] == 0x5555, "classbufferW[12] = 0x%x\n", classbufferW[12]); If first element is not changed, it's really unlikely that anything else did. > + ok(classbuffer[12] == 0, "classbuffer[12] = 0x%x\n", classbuffer[12]); > + ok(classbuffer[13] == 0x55, "classbuffer[13] = 0x%x\n", classbuffer[13]); ... > + ok(!lstrcmpW(classbufferW, subkey_classW), "classbufferW = %s\n", wine_dbgstr_w(classbufferW)); > + ok(classbufferW[12] == 0, "classbufferW[12] = 0x%x\n", classbufferW[12]); > + ok(classbufferW[13] == 0x5555, "classbufferW[13] = 0x%x\n", classbufferW[13]); Could you replace offsets with calculated string length instead so it still works for different strings.

April 25, 2015

Re: jscript: Date.parse: long date with '/' or '-'

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2015-04-25 um 17:45 schrieb Thomas Faller: > This format is not documented under > > https://msdn.microsoft.com/en-us/library/k4w173wk%28v=vs.84%29.aspx > > but its implemented in the internet explorer and in the windows > script host. In this case a test would be very useful. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJVO8QzAAoJEN0/YqbEcdMwl4EP/1+xPW5sSLx86MPGq8e1eXCx 7ON4cSV1u0IIAnw1qMc/VuUxxHw3LN6VSrBN8Rbq6XxXx/1fLvaIz7+ckdBvOz3c QhregFjv7kBsRs3WCDuz8SujMMCeBL0FdeAg7xuWl61mHRKxkaeBNROHlfPxG7GE fYBdOTUPzdEj8eYTB48xozHPMV3EadpO7GL+742upv4qxJa3m7V2ZU3/+4O1atjE +yZyVKEwxKU6PLJNMMzva/TpQPxIEPsKg2L3hFAXnZXjn6lJeew6PWGQiR/OpNR0 HLQcdGk3xQlslefauJpJ6ffSyHl+wRrK7DUpUDsNAQuWQ4ALwHsjkFGG8ph8xRL4 aMnnA+afBU2VXnVpkmnjHlILIaWtCejMo4zveXjD1dk15CeOcs2ezasxhbbl9FUl HySkMNyX6gX07BfR6e9N5gwCzHdOj0GbvRtPMcRXWkPwgzj47xX4NbT0QT8ncg2a lsey/aE8aEscUwGROWm9xv7egKxdBM5kxccBxAMFY1Z5MBNbntlMVTwKERWAl1q9 sRjf77vuuD8LIyXpntqVOb96Hq+4mIo0VzAClFOqSIf6bv8fPz8oFD1elE6G3M4W cXH620URbzXsXg4ZBVRUP6t5sIy5jnSZG+I5h0BUxSizw5ekxbKWlfCicFSZStbu Ln6ptTTJVzUg3QpSR6jN =a7ty -----END PGP SIGNATURE-----

April 25, 2015

Re: [PATCH] wined3d: fix wrong data order for D3DQUERYTYPE_TIMESTAMPDISJOINT

by Henri Verbeet

On 25 April 2015 at 14:26, Patrick Rudolph <siro(a)das-labor.org> wrote: > At the moment the querry D3DQUERYTYPE_TIMESTAMPDISJOINT returns TRUE instead > of FALSE due to wrong data order in struct > wined3d_query_data_timestamp_disjoint. > Please use "git send-email" for sending patches. (Or fix your MUA to inline them.) Unfortunately swapping the order of the fields will introduce a hole in the structure between "disjoint" and "frequency", and make it incompatible with the equivalent d3d10 structure (D3D10_QUERY_DATA_TIMESTAMP_DISJOINT). I think it would be much nicer to fix the initializer of "disjoint_data" in wined3d_timestamp_disjoint_query_ops_get_data() to match the structure layout instead.

April 25, 2015

Re: USB Support

by Saulius Krasuckas

* On Tue, 14 Apr 2015, Steve Kenton wrote: > On 04/14/2015 06:04 PM, Saulius Krasuckas wrote: > > * On Sun, 12 Apr 2015, Steve Kenton wrote: > >> I spent some more time looking at this last night and it looks like > >> the registry enum keys are about every device ever plugged into the > >> system, whether it's currently present or not and the actual Windows > >> device tree is maintained in memory, so just the registry keys > >> probably won't suffice. > > > > Steve, it won't of course. But this is the first required step. I > > would say that another way: > > > > let's make the HwDetect [6] (custom program) work in Wine the same way > > it works in Windows (except for disabling devices -- just the > > monitoring part). It reads very small amount of data from "Enum\USB" > > subkey (I guess). > > > > Another step might be fixing Wine so "USB Device Tree Viewer" [7] > > works as in Windows. But this one looks like a lot more complicated > > testcase. ... > > [6] http://www.codeproject.com/Articles/14500/Detecting-Hardware-Insertion-and-… > > [7] http://www.uwe-sieber.de/usbtreeview_e.html > > > I was thinking along those same lines with something like the display > portion of Windows Device Manager. ~wine/server/device.c has some > routines for managing devices, I need to spend some more time > understanding the current state of things. But yes, it does look like a > good place to start. In bug report 37724 Henrik Haftmann talks [8] about similar issue and offers code excerpt which uses related functions: SetupDiGetClassDevs() SetupDiEnumDeviceInfo() SetupDiOpenDevRegKey() SetupDiDestroyDeviceInfoList() SetupDiEnumDeviceInterfaces() SetupDiGetDeviceInterfaceDetail() You might be interested in collaboration:) S. [8] https://bugs.winehq.org/show_bug.cgi?id=37724

April 25, 2015

Re: (resend)comctl32:TTM_SETTOOLINFO does not change subclassing

by Aric Stewart

On 4/24/15 7:14 AM, Alexandre Julliard wrote: > Aric Stewart <aric(a)codeweavers.com> writes: > >> + toolInfo2.cbSize = TTTOOLINFOA_V1_SIZE; >> + toolInfo2.hwnd = parent2; >> + toolInfo2.uId = 0x1234ABCE; >> + lResult = SendMessageA(hwndTip, TTM_GETTOOLINFOA, 0, (LPARAM)&toolInfo2); >> + ok(lResult, "GetToolInfo failed\n"); >> + ok(!(toolInfo2.uFlags & TTF_SUBCLASS), "uFlags has subclass\n"); >> + wndProc = GetWindowLongPtrA(parent2, GWLP_WNDPROC); >> + ok (wndProc == (DWORD)(&info_wnd_proc), "Window Proc is wrong\n"); >> + >> + toolInfo2.uFlags |= TTF_SUBCLASS; >> + SendMessageA(hwndTip, TTM_SETTOOLINFOA, 0, (LPARAM)&toolInfo2); >> + lResult = SendMessageA(hwndTip, TTM_GETTOOLINFOA, 0, (LPARAM)&toolInfo2); >> + ok(lResult, "GetToolInfo failed\n"); >> + ok(toolInfo2.uFlags & TTF_SUBCLASS, "uFlags does not have subclass\n"); >> + ok (wndProc == (DWORD)(&info_wnd_proc), "Window Proc is wrong\n"); > > Please use the correct types for window function pointers. > Thanks, resent. -aric

April 24, 2015

Re: (resend)comctl32:TTM_SETTOOLINFO does not change subclassing

by Alexandre Julliard

Aric Stewart <aric(a)codeweavers.com> writes: > + toolInfo2.cbSize = TTTOOLINFOA_V1_SIZE; > + toolInfo2.hwnd = parent2; > + toolInfo2.uId = 0x1234ABCE; > + lResult = SendMessageA(hwndTip, TTM_GETTOOLINFOA, 0, (LPARAM)&toolInfo2); > + ok(lResult, "GetToolInfo failed\n"); > + ok(!(toolInfo2.uFlags & TTF_SUBCLASS), "uFlags has subclass\n"); > + wndProc = GetWindowLongPtrA(parent2, GWLP_WNDPROC); > + ok (wndProc == (DWORD)(&info_wnd_proc), "Window Proc is wrong\n"); > + > + toolInfo2.uFlags |= TTF_SUBCLASS; > + SendMessageA(hwndTip, TTM_SETTOOLINFOA, 0, (LPARAM)&toolInfo2); > + lResult = SendMessageA(hwndTip, TTM_GETTOOLINFOA, 0, (LPARAM)&toolInfo2); > + ok(lResult, "GetToolInfo failed\n"); > + ok(toolInfo2.uFlags & TTF_SUBCLASS, "uFlags does not have subclass\n"); > + ok (wndProc == (DWORD)(&info_wnd_proc), "Window Proc is wrong\n"); Please use the correct types for window function pointers. -- Alexandre Julliard julliard(a)winehq.org

April 24, 2015

Re: [PATCH 5/5] wined3d: Move volume DXTn handling to apply_format_fixups.

by Henri Verbeet

This fails the d3dx9_36 tests: ../../../tools/runtest -q -P wine -T ../../.. -M d3dx9_36.dll -p d3dx9_36_test.exe.so texture && touch texture.ok ... texture.c:1778: Test failed: D3DXCreateVolumeTextureFromFileInMemory returned 0x8876086c, expected 0

April 24, 2015

Re: [PATCH 6/6] wined3d: Introduce a scratch string buffers framework.

by Matteo Bruni

2015-04-23 16:12 GMT+02:00 Matteo Bruni <matteo.mystral(a)gmail.com>: > 2015-04-23 14:45 GMT+02:00 Henri Verbeet <hverbeet(a)gmail.com>: >> On 22 April 2015 at 19:30, Matteo Bruni <mbruni(a)codeweavers.com> wrote: >>> struct wined3d_shader_buffer >>> { >> At some point we'll probably want to rename this to something like >> "wined3d_string_buffer". > > Right, and probably that should happen in the patch introducing this > stuff to limit the amount of churn (while moving some of the hunks > making use of the new functions to separate patches). I thought that probably it would be even better if I do the rename before introducing those changes. The resulting patch is still quite large but I think it should be okay. Initially I also renamed shader_addline into string_buffer_addline. Not a good idea... I can certainly wait for your shader_vaddline() patch before sending this one (and then the v2 of the patch in subject).

April 23, 2015

Re: [PATCH 6/6] wined3d: Introduce a scratch string buffers framework.

by Matteo Bruni

2015-04-23 14:45 GMT+02:00 Henri Verbeet <hverbeet(a)gmail.com>: > On 22 April 2015 at 19:30, Matteo Bruni <mbruni(a)codeweavers.com> wrote: >> It's somewhat of an RFC at this point. In particular I'd like some >> feedback about the API. > In general, I think it goes in the right direction. > >> An obvious variant would be to store the pointer to the parent >> wined3d_shader_buffer structure right before the string and just >> return the string itself (thus avoiding having to add ->buffer to >> all the uses of the string). > Personally, I don't particularly mind the couple of extra characters, > and it seems like a good thing to explicitly distinguish between > string buffers and regular strings. > >> + tex_reg_name = shader_sprintf_unsafe(&priv->string_buffers, "tex%u", stage); >> shader_glsl_color_correction_ext(buffer, tex_reg_name, WINED3DSP_WRITEMASK_ALL, >> settings->op[stage].color_fixup); > The problem with this construction is that it is likely to break as > soon as shader_glsl_color_correction_ext() does anything that ends up > calling shader_get_buffer(). To make it worse, > shader_glsl_color_correction_ext() isn't aware of this because it just > gets a const char *, and shader_glsl_generate_ffp_fragment_shader() > isn't supposed to care about the internals of > shader_glsl_color_correction_ext(). > >> @@ -276,13 +276,17 @@ int shader_vaddline(struct wined3d_shader_buffer *buffer, const char *format, va >> char *base = buffer->buffer + buffer->content_size; >> int rc; >> char *new_buffer; >> + unsigned int new_buffer_size; >> >> while(1) >> { >> rc = vsnprintf(base, buffer->buffer_size - buffer->content_size, format, args); >> if (rc < 0 /* C89 */ || (unsigned int)rc >= buffer->buffer_size - buffer->content_size /* C99 */) >> { >> - new_buffer = HeapReAlloc(GetProcessHeap(), 0, buffer->buffer, buffer->buffer_size * 2); >> + new_buffer_size = buffer->buffer_size * 2; >> + while (rc > 0 && (unsigned int)rc >= new_buffer_size - buffer->content_size) >> + new_buffer_size *= 2; >> + new_buffer = HeapReAlloc(GetProcessHeap(), 0, buffer->buffer, new_buffer_size); >> if (!new_buffer) >> { >> ERR("The buffer allocated for the shader program string is too small at %d bytes.\n", buffer->buffer_size); >> @@ -290,7 +294,7 @@ int shader_vaddline(struct wined3d_shader_buffer *buffer, const char *format, va >> return -1; >> } >> buffer->buffer = new_buffer; >> - buffer->buffer_size = buffer->buffer_size * 2; >> + buffer->buffer_size = new_buffer_size; >> base = buffer->buffer + buffer->content_size; >> } >> else > This is a bit of an unrelated change, but probably the right thing to > do. Note that I have an unsent patch that separates tracing the shader > source from shader_vaddline() though, so it's going to look a bit > different fairly soon. That was prompted by the change of the initial size of the wined3d_shader_buffer to 32. They should both go into a separate patch indeed. >> +static char shader_empty_string[] = ""; > This should be const, right? > >> +static void shader_sprintf_va_list(struct wined3d_shader_buffer *buffer, const char *format, va_list args) > I probably would have called that vprintf/vsprintf instead of sprintf_va_list. > >> +{ >> + int ret; >> + char *new_buffer; >> + unsigned int new_buffer_size; >> + >> + if (!buffer) >> + return; >> + while (1) >> + { >> + ret = vsnprintf(buffer->buffer, buffer->buffer_size, format, args); >> + if (ret < 0 || (unsigned int)ret >= buffer->buffer_size) >> + { >> + new_buffer_size = buffer->buffer_size * 2; >> + while (ret > 0 && (unsigned int)ret >= new_buffer_size) >> + new_buffer_size *= 2; >> + new_buffer = HeapReAlloc(GetProcessHeap(), 0, buffer->buffer, new_buffer_size); >> + if (!new_buffer) >> + { >> + ERR("Couldn't allocate buffer for temporary string.\n"); >> + buffer->buffer[0] = 0; >> + return; >> + } >> + buffer->buffer = new_buffer; >> + buffer->buffer_size = new_buffer_size; >> + } >> + else >> + { >> + break; >> + } >> + } >> +} > Once tracing the shader source is removed from shader_vaddline(), this > comes down to a shader_buffer_clear() followed by shader_vaddline(). > And arguably shader_get_buffer() should always shader_buffer_clear() > the buffers it returns. > >> +/* This function immediately puts the buffer back into the free list (it's >> + * intended to be used when the string is to be used and discarded immediately, >> + * mostly useful to avoid having to move the string pointer out of the block). */ >> +const char *shader_sprintf_unsafe(struct list *buffer_list, const char *format, ...) > Not a fan, for the reasons mentioned at > shader_glsl_generate_ffp_fragment_shader() above. > >> +void shader_release_buffer(struct list *list, struct wined3d_shader_buffer *buffer) >> +{ >> + if (!buffer) >> + return; > Can buffer ever legitimately be NULL? Only on allocation failure. At that point though the caller of shader_get_buffer() will probably crash, unless it checks the returned value. In that case the caller could avoid calling shader_release_buffer() altogether but I though to be consistent with free() and HeapFree() and allow a NULL parameter too. I'm not sure there will be any such user in practice though. >> +void shader_buffer_list_free(struct list *list) >> +{ >> + struct wined3d_shader_buffer *buffer, *buffer_next; >> + >> + LIST_FOR_EACH_ENTRY_SAFE(buffer, buffer_next, list, struct wined3d_shader_buffer, entry) >> + { >> + shader_buffer_free(buffer); >> + HeapFree(GetProcessHeap(), 0, buffer); >> + } >> +} >> + > This doesn't actually remove the buffers from the list. There may also > be an argument for wrapping the list itself in a structure, similar to > struct wined3d_private_store. That would only matter if one tries to use the list after calling shader_buffer_list_free() and before calling list_init() again. Yes, that's somewhat asymmetric. I'm going to go with the separate structure, that should indirectly help. >> struct wined3d_shader_buffer >> { > At some point we'll probably want to rename this to something like > "wined3d_string_buffer". Right, and probably that should happen in the patch introducing this stuff to limit the amount of churn (while moving some of the hunks making use of the new functions to separate patches).

April 23, 2015

Re: [PATCH 2/5] wined3d: Introduce resource-type specific format flags.

by Henri Verbeet

On 23 April 2015 at 14:25, Stefan Dösinger <stefandoesinger(a)gmail.com> wrote: > Am 2015-04-23 um 13:52 schrieb Henri Verbeet: >> But now it's still going to write an ERR when it tries to create a >> volume texture and s3tc support is unavailable. Wouldn't it make >> more sense to just explicitly exclude volume textures by adding a >> "desc->resource_type != WINED3D_RTYPE_VOLUME_TEXTURE" condition? > This was intentional (hence the "otherwise" in the comment), because I > think having an application that in any way tries to use DXTn and > having no DXTn support is worth warning the user about. I don't have > any objections against never writing this for volumes though. I > seriously doubt that there's an application that doesn't need DXTn 2D > textures but tries to create a DXTn volume texture. > But that's the thing, this will only make a difference for applications that try to create DXTn volume textures, but never try to create DXTn 2D or cube textures. But creating a DXTn volume texture is going to fail either way, regardless of whether the driver has s3tc support or not. So you create a situation where you're suggesting to users that they should somehow acquire s3tc support, but already know in advance that it isn't going to make a difference.

April 23, 2015

Re: [PATCH 6/6] wined3d: Introduce a scratch string buffers framework.

by Henri Verbeet

On 22 April 2015 at 19:30, Matteo Bruni <mbruni(a)codeweavers.com> wrote: > It's somewhat of an RFC at this point. In particular I'd like some > feedback about the API. In general, I think it goes in the right direction. > An obvious variant would be to store the pointer to the parent > wined3d_shader_buffer structure right before the string and just > return the string itself (thus avoiding having to add ->buffer to > all the uses of the string). Personally, I don't particularly mind the couple of extra characters, and it seems like a good thing to explicitly distinguish between string buffers and regular strings. > + tex_reg_name = shader_sprintf_unsafe(&priv->string_buffers, "tex%u", stage); > shader_glsl_color_correction_ext(buffer, tex_reg_name, WINED3DSP_WRITEMASK_ALL, > settings->op[stage].color_fixup); The problem with this construction is that it is likely to break as soon as shader_glsl_color_correction_ext() does anything that ends up calling shader_get_buffer(). To make it worse, shader_glsl_color_correction_ext() isn't aware of this because it just gets a const char *, and shader_glsl_generate_ffp_fragment_shader() isn't supposed to care about the internals of shader_glsl_color_correction_ext(). > @@ -276,13 +276,17 @@ int shader_vaddline(struct wined3d_shader_buffer *buffer, const char *format, va > char *base = buffer->buffer + buffer->content_size; > int rc; > char *new_buffer; > + unsigned int new_buffer_size; > > while(1) > { > rc = vsnprintf(base, buffer->buffer_size - buffer->content_size, format, args); > if (rc < 0 /* C89 */ || (unsigned int)rc >= buffer->buffer_size - buffer->content_size /* C99 */) > { > - new_buffer = HeapReAlloc(GetProcessHeap(), 0, buffer->buffer, buffer->buffer_size * 2); > + new_buffer_size = buffer->buffer_size * 2; > + while (rc > 0 && (unsigned int)rc >= new_buffer_size - buffer->content_size) > + new_buffer_size *= 2; > + new_buffer = HeapReAlloc(GetProcessHeap(), 0, buffer->buffer, new_buffer_size); > if (!new_buffer) > { > ERR("The buffer allocated for the shader program string is too small at %d bytes.\n", buffer->buffer_size); > @@ -290,7 +294,7 @@ int shader_vaddline(struct wined3d_shader_buffer *buffer, const char *format, va > return -1; > } > buffer->buffer = new_buffer; > - buffer->buffer_size = buffer->buffer_size * 2; > + buffer->buffer_size = new_buffer_size; > base = buffer->buffer + buffer->content_size; > } > else This is a bit of an unrelated change, but probably the right thing to do. Note that I have an unsent patch that separates tracing the shader source from shader_vaddline() though, so it's going to look a bit different fairly soon. > +static char shader_empty_string[] = ""; This should be const, right? > +static void shader_sprintf_va_list(struct wined3d_shader_buffer *buffer, const char *format, va_list args) I probably would have called that vprintf/vsprintf instead of sprintf_va_list. > +{ > + int ret; > + char *new_buffer; > + unsigned int new_buffer_size; > + > + if (!buffer) > + return; > + while (1) > + { > + ret = vsnprintf(buffer->buffer, buffer->buffer_size, format, args); > + if (ret < 0 || (unsigned int)ret >= buffer->buffer_size) > + { > + new_buffer_size = buffer->buffer_size * 2; > + while (ret > 0 && (unsigned int)ret >= new_buffer_size) > + new_buffer_size *= 2; > + new_buffer = HeapReAlloc(GetProcessHeap(), 0, buffer->buffer, new_buffer_size); > + if (!new_buffer) > + { > + ERR("Couldn't allocate buffer for temporary string.\n"); > + buffer->buffer[0] = 0; > + return; > + } > + buffer->buffer = new_buffer; > + buffer->buffer_size = new_buffer_size; > + } > + else > + { > + break; > + } > + } > +} Once tracing the shader source is removed from shader_vaddline(), this comes down to a shader_buffer_clear() followed by shader_vaddline(). And arguably shader_get_buffer() should always shader_buffer_clear() the buffers it returns. > +/* This function immediately puts the buffer back into the free list (it's > + * intended to be used when the string is to be used and discarded immediately, > + * mostly useful to avoid having to move the string pointer out of the block). */ > +const char *shader_sprintf_unsafe(struct list *buffer_list, const char *format, ...) Not a fan, for the reasons mentioned at shader_glsl_generate_ffp_fragment_shader() above. > +void shader_release_buffer(struct list *list, struct wined3d_shader_buffer *buffer) > +{ > + if (!buffer) > + return; Can buffer ever legitimately be NULL? > +void shader_buffer_list_free(struct list *list) > +{ > + struct wined3d_shader_buffer *buffer, *buffer_next; > + > + LIST_FOR_EACH_ENTRY_SAFE(buffer, buffer_next, list, struct wined3d_shader_buffer, entry) > + { > + shader_buffer_free(buffer); > + HeapFree(GetProcessHeap(), 0, buffer); > + } > +} > + This doesn't actually remove the buffers from the list. There may also be an argument for wrapping the list itself in a structure, similar to struct wined3d_private_store. > struct wined3d_shader_buffer > { At some point we'll probably want to rename this to something like "wined3d_string_buffer".

April 23, 2015

Re: [PATCH 2/5] wined3d: Introduce resource-type specific format flags.

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2015-04-23 um 13:52 schrieb Henri Verbeet: > But now it's still going to write an ERR when it tries to create a > volume texture and s3tc support is unavailable. Wouldn't it make > more sense to just explicitly exclude volume textures by adding a > "desc->resource_type != WINED3D_RTYPE_VOLUME_TEXTURE" condition? This was intentional (hence the "otherwise" in the comment), because I think having an application that in any way tries to use DXTn and having no DXTn support is worth warning the user about. I don't have any objections against never writing this for volumes though. I seriously doubt that there's an application that doesn't need DXTn 2D textures but tries to create a DXTn volume texture. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJVOOS1AAoJEN0/YqbEcdMwDawQAJMDnPgtmpktD5gHiTrmgqkT Ssz1BIpl2F08jqy2XZk38ASw/EH4VG/vfsyFtGZRtM8nPe2FdQTjOfxtnEcl6kp4 lEt6oYb7DAwCbuvLkvkowGNKNs/QfDlxJOmO+a+61AA+aN/WVLyFyp940p2sw/g/ Wo8VnUqC9xKKnP5pAEohvUjrPxdV3hfSO9faf9vk7Ph0MY711nXEJfY+JEY5/FCG 4YhO+Ckg6Ln75zVklL5IpwoOK+H/8B0VUiMmBmrXWvZjrNZkIxxUS3kTfkLN3VUA 1CAM2DclLvxKG+mfF6Woca1QUiH/Ef82i/jxJqFXDoppXnoe9exUWl9D0nE3VvjL 4w1ZYqfhBXEHRmTbHtVjXHq4nC9WGuU1rBlB/uu44cp+tMRZzF38i6kMAKTpJEIN 2Sdej41mjw1zZp9H6SNLeunQMYK9GFMS7BKLSEhS1PhR04plTx5TIx1FAGQudIIb UxBuz8fPIEuj+Nuk0KoMIPkUvrYRTMEaJlNw97OggBJi5ltsO6NVNPaBrYeCnqrI Z7wqk39rcBJ3F9gGL2iyjqJonMnKmhDa5RKI+e7Qfx8bXEfv07uTuGaCrhMhooZv 98/KJgdI74DAracxcRuK4YzHZCnn3oTDqUPodeDED/pJLWpv8epjv9e0IeulJopG mpJTS1/P1na3Xeq+MSlc =DBKL -----END PGP SIGNATURE-----

April 23, 2015

Re: Wine Joysticks, seeking a plan

by Aric Stewart

On 4/16/15 2:12 PM, Ken Thomases wrote: > On Apr 16, 2015, at 9:46 AM, Andrew Eikum <aeikum(a)codeweavers.com> wrote: > >> On Thu, Apr 16, 2015 at 08:11:39AM -0500, Aric Stewart wrote: >>> Now completely unresearched but it may be possible to make a single >>> joystick driver, maybe replacing winejoystick.drv that would build >>> only the platform code that is relevant. >> >> This makes sense to me, and is how dinput already works. Make some >> sane API for it and build dinput/winmm/xinput on top of that. > > Makes sense to me, too. > > -Ken > Thanks to the great leads that Vincent gave me about Raw Input and such I ended up on a path reading about the HID minidrivers and the whole HID class. I bounced the idea that the Joystick support should be in HID and Alexandre seemed warm to the idea. So I will do work to implement and update our hid.dll to see about putting joystick code in there. Then, all the other joystick areas can be build off of the HID code. It is already clearly stated in the HID documentation that dinput is a client of the HID code. The main trick is going to see if all the special functionality (such as forcefeedback or rumble) has a path through HID or not. -aric

April 23, 2015

Favor / heads up - wine tasks in a hackathon

by Jeremy White

My alma mater is putting on a hackathon for college students in our region. http://carlhacks.io/ As an experiment, I'm wanted to see if I could get any of these students interested in Wine hacking. So we've sponsored prize money for any students that can fix a bug in Wine or fix a test. I have no idea if any students are going to take it on or not, but if you see an influx of urgent requests on #winehackers or here, starting Saturday and ending Sunday, you'll know why :-/. And if any such student does actually succeed in contributing a clearly useful or even promising patch, please let me know, so I can make a point to award the prize money during the closing ceremonies. Cheers, Jeremy

April 23, 2015

Re: [PATCH 4/5] wined3d: Query info for each resource type from ARB_internalformat_query2.

by Henri Verbeet

On 23 April 2015 at 11:28, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > +static GLenum wined3d_gl_type_to_enum(enum wined3d_gl_resource_type type) > +{ > + switch (type) > + { > + case WINED3D_GL_RES_TYPE_TEX_1D: > + return GL_TEXTURE_1D; > + case WINED3D_GL_RES_TYPE_TEX_2D: > + return GL_TEXTURE_2D; > + case WINED3D_GL_RES_TYPE_TEX_3D: > + return GL_TEXTURE_3D; > + case WINED3D_GL_RES_TYPE_TEX_CUBE: > + return GL_TEXTURE_CUBE_MAP_ARB; > + case WINED3D_GL_RES_TYPE_TEX_RECT: > + return GL_TEXTURE_RECTANGLE_ARB; > + case WINED3D_GL_RES_TYPE_BUFFER: > + return GL_TEXTURE_2D; /* TODO: GL_TEXTURE_BUFFER. */ > + case WINED3D_GL_RES_TYPE_COUNT: > + break; > + } > + ERR("Unexpected GL resource type %u.\n", type); > + return 0; > +} > + > + You have an extra newline here. > + for (type = 0; type < sizeof(format->flags) / sizeof(*format->flags); ++type) This isn't wrong as such, but you can use ARRAY_SIZE for this now. > { > - TRACE("Format %s doesn't support %s.\n", debug_d3dformat(format->id), string); > - format_clear_flag(format, flag); > + gl_info->gl_ops.ext.p_glGetInternalformativ(wined3d_gl_type_to_enum(type), internal, pname, 1, &value); > + if (value == GL_FULL_SUPPORT) > + { > + TRACE("Format %s supports %s.\n", debug_d3dformat(format->id), string); It would probably be helpful if this mentioned the resource type as well.

April 23, 2015

Re: [PATCH 2/5] wined3d: Introduce resource-type specific format flags.

by Henri Verbeet

On 23 April 2015 at 11:28, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > + /* Always check 2D textures here, we don't want to write this ERR when the app tried > + * to create a compressed volume texture but s3tc support is otherwise available. */ > if ((desc->format == WINED3DFMT_DXT1 || desc->format == WINED3DFMT_DXT2 || desc->format == WINED3DFMT_DXT3 > || desc->format == WINED3DFMT_DXT4 || desc->format == WINED3DFMT_DXT5) > - && !(format->flags & WINED3DFMT_FLAG_TEXTURE) && !once++) > + && !(format->flags[WINED3D_GL_RES_TYPE_TEX_2D] & WINED3DFMT_FLAG_TEXTURE) && !once++) > ERR_(winediag)("The application tried to create a DXTn texture, but the driver does not support them.\n"); But now it's still going to write an ERR when it tries to create a volume texture and s3tc support is unavailable. Wouldn't it make more sense to just explicitly exclude volume textures by adding a "desc->resource_type != WINED3D_RTYPE_VOLUME_TEXTURE" condition?

April 23, 2015

Re: [PATCH 5/6] d3d9/tests: Add a specular lighting test.

by Henri Verbeet

On 22 April 2015 at 19:30, Matteo Bruni <mbruni(a)codeweavers.com> wrote: > +#define VERTICES_SIDE 5 > +#define INDICES_COUNT ((VERTICES_SIDE - 1) * (VERTICES_SIDE - 1) * 2 * 3) > + I don't think you really need to #define these, but if you do you should probably #undef them once you're done with them.

April 23, 2015

Re: [PATCH 3/6] wined3d: Introduce D3D7+ normal matrix computation.

by Henri Verbeet

On 22 April 2015 at 19:30, Matteo Bruni <mbruni(a)codeweavers.com> wrote: > +#define SWAP_ROWS(a, b) { float *tmp = a; a = b; b = tmp; } > + I assume this is mostly borrowed from Mesa like invert_matrix_3d(), but unfortunately Mesa isn't particularly good at writing macros, even though they have more than enough of them. This one happens to more or less work for the cases you have here, but consider the following in particular: if (...) SWAP_ROWS(a, b); else SWAP_ROWS(c, d); Please just use the standard "do { ... } while(0)" construction when you need to define a macro like that. In this particular case there's of course no reason you need a macro in the first place.

April 23, 2015

Re: [PATCH 2/2] ntdll: Add support for FileFsFullSizeInformation class in NtQueryVolumeInformationFile(try 2)

by Alexandre Julliard

"Jianqiu Zhang" <zhangjianqiu_133(a)yeah.net> writes: > + if(!S_ISREG(st.st_mode) && !S_ISDIR(st.st_mode)) > + { > + io->u.Status = STATUS_INVALID_DEVICE_REQUEST; > + } > + else > + { > + ULONGLONG bsize; > +#if !defined(linux) || !defined(HAVE_FSTATFS) > + struct statvfs stfs; > + > + if(fstatvfs( fd, &stfs ) < 0) > + { > + io->u.Status = FILE_GetNtStatus(); > + break; > + } > + bsize = stfs.f_frsize; > +#else > + struct statfs stfs; > + if(fstatfs( fd, &stfs ) < 0) > + { > + io->u.Status = FILE_GetNtStatus(); > + break; > + } > + bsize = stfs.f_bsize; > +#endif Please avoid duplicating all that code. -- Alexandre Julliard julliard(a)winehq.org

April 23, 2015

Re: ws2_32/tests: Add a trailing '\n' to an ok() call.

by Marvin

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

April 23, 2015

Re: user32: After handling an internal message give a chance to real message to arrive.

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=12973 Your paranoid android. === w7u (32 bit msg) === msg.c:12230: Test failed: unexpected hwnd 00150136 msg.c:12252: Test failed: bad time 315f0/315ff

April 23, 2015

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

by Dmitry Timoshkov

Qian Hong <qhong(a)codeweavers.com> wrote: > On Wed, Oct 23, 2013 at 1:51 PM, Dmitry Timoshkov <dmitry(a)baikal.ru> wrote: > > It looks like that these new winstation tests now leave a reference to > > a wineserver object which makes wineserver stay in memory after the tests > > have finished. Please fix. > > Thanks for comment, I noticed this as well, it is an existing Wine bug > discovered by my test, I have a comment regarding this bug in my > [patch 4/6], I'll try to fix Wine rather than my test. So much time has passed but it's still not fixed, wineserver stays forever in memory after 'make test' in user32/tests, this is very annoying. Please either fix it or at least limit the winstation tests to run only in interactive mode. Moreover, plain 'make winstation.ok' doesn't work at all, explorer fails to start. -- Dmitry.

April 23, 2015

Re: [PATCH 2/2] krnl386: Invalid console handles should translate into real handles when creating a new process.

by Alexandre Julliard

"Erich E. Hoover" <erich.e.hoover(a)gmail.com> writes: > This patch fixes an issue exposed by the fix in patch 1. The current > mechanism for initializing the DOS handles for a process uses > DuplicateHandle, which converts INVALID_HANDLE_VALUE into a usable > handle (but not 0). Without this fix the Caesar III demo installer > crashes with an unhandled page fault, though it may be more desirable > to allocate new handles than to replicate the behavior we used to have > prior to patch 1. Proper handles would be better, simply open the null device or something like that. -- Alexandre Julliard julliard(a)winehq.org

April 23, 2015

Re: [PATCH 2/5] wined3d: Shadow format flags in wined3d_rendertarget_view.

by Henri Verbeet

On 22 April 2015 at 11:30, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > @@ -101,6 +101,7 @@ static void wined3d_rendertarget_view_init(struct wined3d_rendertarget_view *vie > view->parent_ops = parent_ops; > > view->format = wined3d_get_format(gl_info, desc->format_id); > + view->format_flags = resource->format_flags; That's wrong. We won't be able to do much with this until we support ARB_texture_view, but the view format is mostly independent of the resource format, other than that they have to be from the same compatibility class. I guess you'd want something like "view->format_flags = view->format->flags[resource->gl_type];".

April 22, 2015

Re: dpnet: Implement IDirectPlay8Address GetComponentByIndex (try 9)

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2015-04-22 um 05:30 schrieb Alistair Leslie-Hughes: > + if(*pdwBufferSize < entry->size || *pdwNameLen < namesize) > + { > + *pdwNameLen = namesize + 1; > + *pdwBufferSize = entry->size; > + return DPNERR_BUFFERTOOSMALL; > + } > + > + if((*pdwNameLen && !pwszName) || (*pdwBufferSize && !pvBuffer)) > + return E_POINTER; This check suggests that a NULL pwszName is ok if *pdwNameLen is 0. However, the above check fails in this situation. Depending on how you want this to behave there's either an error in your logic or you have some redundant checks in there. Are you sure *pdwDataType is not set in the BUFFERTOOSMALL case? I mentioned pdwDataType in the last feedback already, please take a bit more care and check if some things I point out apply in a similar way to other places, and re-read the feedback you get after you think you have implemented all the changes to see if there's anything you missed. > + case DPNA_DATATYPE_DWORD: > + *(DWORD*)pvBuffer = entry->data.value ; The extra space in front of the semicolon looks weird. > hr = IDirectPlay8Address_GetComponentByIndex(localaddr, 100, NULL, NULL, NULL, &bufflen, &type); > - todo_wine ok(hr == E_POINTER, "got 0x%08x\n", hr); > + ok(hr == DPNERR_INVALIDPOINTER, "got 0x%08x\n", hr); In the code you return E_POINTER. DPNERR_INVALIDPOINTER is defined as E_POINTER, but please try to be consistent. > hr = IDirectPlay8Address_GetComponentByIndex(localaddr, i, NULL, &namelen, NULL, &bufflen, &type); > - todo_wine ok(hr == DPNERR_BUFFERTOOSMALL, "got 0x%08x\n", hr); > + ok(hr == DPNERR_BUFFERTOOSMALL, "got 0x%08x\n", hr); > + ok(namelen > 0, "namelen length is 0\n"); > + ok(bufflen > 0, "bufflen length is 0\n"); Please check the exact length, not just > 0. Please also check the name string, and the string and lengths in the success case (e.g. if you pass a length > than the necessary size does dpnet change the size?). Also, as pointed out above -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJVN25ZAAoJEN0/YqbEcdMwf1cP/jXMXUuyMNzg5JAVG6YMMKgJ yIac4X5zxnmcPrJMjMRKIr2xU3u6ZDki/Kk5/GulDCCd4NQGlDJP0QY9WuuZ9eIN YiAipjXLpO4DPVi6eTRlDIbfCSDfpNJnjSWdDGbjpF/dpUkJOOZzwWvkJKZr598O kZohPT1kwTs12sU3yQyT8N3NGQer+AaWHcfohMW5f0UeZ+whviwjg3CGavrR65mH Q2fWn92mgw8KPTu+zvJ5oBbWQLf24o+lBp/vQ6zeOIA2lxXVLoMfg5q8QRWvKge9 IiPIG8BEOfrTXXSEZSUauif97fdq23JGQJOOGYUyZ+YLg/4Pqj2nWZBOmFM+3gVy E5FgFPT4EdE1vpyn7cnWGufzNtnctTZGOJ4F7AKxdMoBPqXxDEgdjmMFqN0yeTH8 Pm6NGVJP7uR8+wqXApHoGN2S7ceZLuEhMhdGYHbFakx9McPzCEayWMGQ/CIlbjHt YRB5aaxOAk896Fmb+PMuv3G9d4+y4409iLB+/Jrda20VOFfAp1qzNa33R9rhWXN7 sSdCale2KKYwStnzSWAcH4Mn7L+i1B/Dl7Md83HqPumAPfwlSK8VZVeqF0ZVjLaR KlokPcmQnIuS/ia6gPdGVbmAHnpoIIn0CNtgstKBqXkvGUlasXsKhy2ofWkWoaiW lO+hrwausmSORbzMGVaW =fTwv -----END PGP SIGNATURE-----

April 22, 2015

Re: dpnet: Implement IDirectPlay8Address GetComponentByIndex (try 9)

by Marvin

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

April 22, 2015

Re: comctl32:TTM_SETTOOLINFO does not change subclassing

by Aric Stewart

On 4/21/15 12:02 PM, Nikolay Sivov wrote: > On 21.04.2015 17:40, Aric Stewart wrote: >> >> Prevents crashes when a subclassed window is unsubclassed and then destroyed. >> >> As per information found at: >> https://support.microsoft.com/en-us/kb/kbview/154122 >> --- >> dlls/comctl32/tooltips.c | 6 +++++- >> 1 file changed, 5 insertions(+), 1 deletion(-) >> >> > > We definitely need a test for that. > You are correct, working on those. -aric

April 21, 2015

Re: comctl32:TTM_SETTOOLINFO does not change subclassing

by Nikolay Sivov

On 21.04.2015 17:40, Aric Stewart wrote: > > Prevents crashes when a subclassed window is unsubclassed and then destroyed. > > As per information found at: > https://support.microsoft.com/en-us/kb/kbview/154122 > --- > dlls/comctl32/tooltips.c | 6 +++++- > 1 file changed, 5 insertions(+), 1 deletion(-) > > We definitely need a test for that.

April 21, 2015

Re: [PATCH 5/5] ddraw/tests: Port the lighting test to the previous d3d versions.

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=12921 Your paranoid android. === wvistau64 (32 bit ddraw1) === ddraw1.c:2488: Test failed: Expected message 0x46, but didn't receive it. ddraw1.c:2490: Test failed: Expected screen size 1024x768, got 0x0. ddraw1.c:2496: Test failed: Expected {0, 0, 1024, 768}, got {-8, -8, 1032, 746}. ddraw1.c:2527: Test failed: Expected {0, 0, 1024, 768}, got {-8, -8, 1032, 746}. ddraw1.c:2535: Test failed: Expected {0, 0, 1024, 768}, got {-8, -8, 1032, 746}. ddraw1.c:2562: Test failed: Expected {0, 0, 1024, 768}, got {-8, -8, 1032, 746}. ddraw1.c:2582: Test failed: Expected {0, 0, 1024, 768}, got {-8, -8, 1032, 746}. ddraw1.c:2606: Test failed: Expected {0, 0, 1024, 768}, got {-8, -8, 1032, 746}. ddraw1.c:2633: Test failed: Expected {0, 0, 1024, 768}, got {-8, -8, 1032, 746}. ddraw1.c:2650: Test failed: Expected {0, 0, 1024, 768}, got {-8, -8, 1032, 746}. ddraw1.c:2687: Test failed: Expected {0, 0, 1024, 768}, got {-8, -8, 1032, 746}. ddraw1.c:2698: Test failed: Expected {0, 0, 1024, 768}, got {-8, -8, 1032, 746}. ddraw1.c:2725: Test failed: Expected {0, 0, 1024, 768}, got {-8, -8, 1032, 746}. ddraw1.c:2745: Test failed: Expected {0, 0, 1024, 768}, got {-8, -8, 1032, 746}. ddraw1.c:2762: Test failed: Expected {0, 0, 1024, 768}, got {-8, -8, 1032, 746}. ddraw1.c:2789: Test failed: Expected {0, 0, 1024, 768}, got {-8, -8, 1032, 746}. ddraw1.c:2806: Test failed: Expected {0, 0, 1024, 768}, got {-8, -8, 1032, 746}. ddraw1.c:2844: Test failed: Expected {0, 0, 1024, 768}, got {-8, -8, 1032, 746}.

April 21, 2015

Re: [PATCH 4/5] ddraw/tests: Add more d3d7 lighting tests.

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=12920 Your paranoid android. === w8 (32 bit visual) === visual.c:1494: Test failed: unexpected colortable on offscreen surface

April 21, 2015

Re: iexplore: Update version to 9.0.8112.16421.

by Hans Leidekker

On Tue, Apr 21, 2015 at 11:25 AM, Nikolay Sivov <bunglehead(a)gmail.com> wrote: > Maybe ieframe/mshtml versions should be updated as well? I considered that but they are trailing behind already. It might be better to wait for an application that needs it, so we don't break too much at once.

April 21, 2015