August 2014 - Wine-devel - list.winehq.org

Re: [PATCH 5/5] d3dx9: Correctly handle out of memory conditions while reallocating children array.
by Henri Verbeet 26 Aug '14

26 Aug '14

On 26 August 2014 16:13, Matteo Bruni <mbruni(a)codeweavers.com> wrote: > @@ -338,15 +338,20 @@ static HRESULT d3dx9_file_data_create(IDirectXFileObject *dxfile_object, ID3DXFi > > while (SUCCEEDED(ret = IDirectXFileData_GetNextObject(object->dxfile_data, &data_object))) ... > + new_children = HeapReAlloc(GetProcessHeap(), 0, object->children, > + sizeof(*object->children) * (object->nb_children + 1)); While I suspect this is hardly the only thing wrong with xfile.c, it seems suboptimal to grow the array by 1 each time you go through the loop.

2 2

Re: [PATCH 2/5] comdlg32: Implement calling IFileDialogEvents::OnTypeChange().
by Alexandre Julliard 25 Aug '14

25 Aug '14

David Hedberg <david.hedberg(a)gmail.com> writes: > @@ -1652,6 +1666,11 @@ static LRESULT on_command_filetype(FileDialogImpl *This, WPARAM wparam, LPARAM l > } > CoTaskMemFree(filename); > } > + > + /* The documentation claims that OnTypeChange is called only > + * when the dialog is opened, but this is obviously not the > + * case. */ > + events_OnTypeChange(This); It would be more obvious with a test case... -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 2/2] vbscript: Implemented Time(try 3)
by Marvin 25 Aug '14

25 Aug '14

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=8660 Your paranoid android. === w2000pro (32 bit) === No test summary line found === wxppro (32 bit) === No test summary line found === wvistau64 (32 bit) === No test summary line found === w2008s64 (32 bit) === No test summary line found === w7u (32 bit) === No test summary line found === w8 (32 bit) === No test summary line found === wvistau64 (64 bit) === No test summary line found === w2008s64 (64 bit) === No test summary line found

1 0

Re: [PATCH 1/2] vbscript: Implemented Date(try 3)
by Marvin 25 Aug '14

25 Aug '14

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=8659 Your paranoid android. === w2000pro (32 bit) === No test summary line found === wxppro (32 bit) === No test summary line found === wvistau64 (32 bit) === No test summary line found === w2008s64 (32 bit) === No test summary line found === w7u (32 bit) === No test summary line found === w8 (32 bit) === No test summary line found === wvistau64 (64 bit) === No test summary line found === w2008s64 (64 bit) === No test summary line found

1 0

Re: [PATCH 1/2] vbscript: Implemented Date(try 2)
by Nikolay Sivov 24 Aug '14

24 Aug '14

On 8/23/2014 19:38, Shuai Meng wrote: > + GetLocalTime(&lt); > + ud.st = lt; > + VarDateFromUdateEx(&ud, 0, VAR_DATEVALUEONLY, &date); > + return return_date(res, date); It's better to init 'wDayOfYear' part too, even if it's not used internally +variant will show its garbage value. Also I'm not sure about ignoring return value of VarDateFromUdateEx().

2 1

Re: configure: Add -linotify when present, for non-Linux platforms.
by Alexandre Julliard 23 Aug '14

23 Aug '14

Gerald Pfeifer <gerald(a)pfeifer.com> writes: > A FreeBSD user ran into this when sys/inotify.h was present via an > extra package and Wine went ahead using that, only to fail at link- > time. We'd want to use kqueue instead on FreeBSD. -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: [PATCH 2/2] vbscript: Implemented Time(try 2)
by Marvin 23 Aug '14

23 Aug '14

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=8634 Your paranoid android. === w2000pro (32 bit) === No test summary line found === wxppro (32 bit) === No test summary line found === wvistau64 (32 bit) === No test summary line found === w2008s64 (32 bit) === No test summary line found === w7u (32 bit) === No test summary line found === w8 (32 bit) === No test summary line found === wvistau64 (64 bit) === No test summary line found === w2008s64 (64 bit) === No test summary line found

1 0

Re: [PATCH 1/2] vbscript: Implemented Date(try 2)
by Marvin 23 Aug '14

23 Aug '14

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=8633 Your paranoid android. === w2000pro (32 bit) === No test summary line found === wxppro (32 bit) === No test summary line found === wvistau64 (32 bit) === No test summary line found === w2008s64 (32 bit) === No test summary line found === w7u (32 bit) === No test summary line found === w8 (32 bit) === No test summary line found === wvistau64 (64 bit) === No test summary line found === w2008s64 (64 bit) === No test summary line found

1 0

Re: [PATCH 1/5] wined3d: Also update the container in wined3d_surface_update_desc().
by Stefan Dösinger 22 Aug '14

22 Aug '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2014-08-22 12:32, schrieb Henri Verbeet: > This fixes a bug exposed by commit > 415b8037206b1d4c104d9623037458739f6cfdf5. In particular, > wined3d_resource_update_draw_binding() uses the multisample type to > determine to appropriate draw binding, and since we never updated > that for the container, we could end up with an incorrect draw > binding after a device reset. Why not move this call to the texture entirely? -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJT9yAyAAoJEN0/YqbEcdMwkEsP/juiBeX/o8Pj7hLFs/svF7/U 5fIjBxWSnSq/+WA0/g4OkoIPJoTp+qXjj3irv3r8JCZVTDR455pMDnBZ0yTa+jQa VEF9HvELIurpZz6qOP2UTISD2u2VizzTG74AO8dM+gGYTtX4kPa1+H3QdY7BA2nN XxWW7wGvH5sCzxPh8yx7m8p+vSKzlUQnSuNRoFK+RFLL/VtSeUBsk5OVwuv99LGw lc7DsNH7yKsfG+V5rXyWmgZQsTJDqnlaS+3t5XlqBfdBYuv5JbreUDwdlelbBcmi MWqOdFGVxw60TM7Ra/FXITse9J62lhxjZMyP5nc8nrDp9o6Ci7ynFAzev4FsK6qz eTYj+WRwmsiIKMFPKzx69vz90/ZjdhKM68LPmVythfcB4Cx3YekhME/e7QX0+wZE VBNhZB6VnP7B6BO3tPl8RxMOFzLuFmpgzH2UZevhQVOQximH343CzU0ejf5t0o5Z vkjryDR7QxWE73Ru1p+Sx2b0c81eQtzG+SeDKyjDLLJbVCvFWytj6khUuekupPzF VKHn///AO14pYD1qgRFN4g/FblS792WbXsufV4xDpEsfokoV7E/t8f8vDAoR7FFi rDoP290L95rc9t3ltFW1bVaiKKRrT6mslPZ6e9wR1un7kC9AlfeOiQn8sAVUT3O5 zl9+g1wfTHod4Mi7Sr5J =PO4N -----END PGP SIGNATURE-----

2 1

Re: [PATCH 3/5] wined3d: Get rid of wined3d_device_color_fill().
by Stefan Dösinger 22 Aug '14

22 Aug '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2014-08-22 12:32, schrieb Henri Verbeet: > + if (desc.pool != WINED3D_POOL_DEFAULT && desc.pool != WINED3D_POOL_SYSTEM_MEM) > + { > + WARN("Color-fill not allowed on surfaces in pool %#x.\n", desc.pool); > + return D3DERR_INVALIDCALL; > + } I realize that this just keeps existing code in place, but as far as I can see this check is redundant. There's already a somewhat strange check right above this one that tests if the surface is a render target or in WINED3D_POOL_DEFAULT. Unless I missed a way to create a non-default pool render target testing only for WINED3D_POOL_DEFAULT should be enough. The patch also works only as long as we keep the D3DUSAGE_RENDERTARGET check in wined3d_device_set_rendertarget_view and not move it to wined3d_rendertarget_view_create. Is that your intention? -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJT9yX4AAoJEN0/YqbEcdMw5i4P/Ao5NQVk+CMZtE6wAenF/YIx V/NuOHczkC1qnXt74CkZe96o/HukbpoyyQ3uKlDnEzgwN8OrJUfwL3kVq6N9llqu MaYGH0a4P/Ib+ZROouuolNcOFSsgjyHvTnZmHQUONhpzURnmLNdUzoKyfrZTKrwe XtIk4prgEMny5W9Oae0eniYHeVv3Gyvg1jtSoviO/KT/fys5Bb+3xW1Voi7ARPWj Ylm+D61JIQotblAcJVon4JElegbS4ENnziRSJM2774VaCaEpFOkCJ+0e3ZDzgqBQ SjGbuLURL48HHYHKzCBEy9zpTiWr40cLjwm/h6f35koHl3IjHofFuxQPxOLqVDFt L/BsdTUNKFL6EkvalC5ObdFUvgkX+1tx60h4vllue1sFbBIZRkISARoc1Q+HAwJE 4B2Ktwlwy0w2fuy8Ml7j3X8g+wqyPkCpaoFcKtauELFBkY/eqn+HFmoRAJTa2oMb ps3d79EbeRPEVhh9NOOqAAkMuA+ztr52uEbKgq7PS0PzcFIvyECTBWxSnAEjw+d8 CKRk6HGC/v8Jo4Vqw/SzDTYRM/bO5sdvgMulux0zSAJuBZe+YGIcl2d0akT6MYQf 615tmoVbSfR3FY2e7SaMXqfXMLMEZzkQWjRy0A+Zs1+sPycobS3/Q7YjOmhW6goC KQGqfd79P2SuiuAbvlue =h6dU -----END PGP SIGNATURE-----

2 1