wine-devel March 2015

wine-devel@winehq.org

71 participants
270 discussions

Re: [2/3] dpnet: Free previous allocated data
by Nikolay Sivov 03 Mar '15

03 Mar '15

On 03.03.2015 11:59, Alistair Leslie-Hughes wrote: > + if(entry->type == DPNA_DATATYPE_STRING_ANSI) > + heap_free(entry->data.ansi); > + else if(entry->type == DPNA_DATATYPE_STRING) > + heap_free(entry->data.string); > + else if(entry->type == DPNA_DATATYPE_BINARY) > + heap_free(entry->data.string); > + You can as well just call heap_free(entry->data.binary) for all those types (or add another neutral 'ptr' field).

1 0

Google Summer of 2015 has begun
by Austin English 02 Mar '15

02 Mar '15

Howdy all, Wine has been accepted to Google's Summer Of Code for 2015: https://www.google-melange.com/gsoc/org2/google/gsoc2015/wine Developers, if you'd like to be a mentor, please go here to make a connection with the wine project, and then Andre or I will approve you: https://www.google-melange.com/gsoc/homepage/google/gsoc2015 Students, you can apply starting March 16 at 19:00 UTC. Now is a good time to start introducing yourself, explore the source, send patches, and discuss your proposals. Good luck. -- -Austin

1 0

GSOC 2015 Applicant
by Saurabh Goyal 02 Mar '15

02 Mar '15

Hi, I am Saurabh Goyal a third year undergraduate from Indian institute of Technology BHU. I have taken basic Machine Learning course on coursera, created few android applications and know algorithms and data structures in c++ and i use linux(ubuntu) for my programming work. I want to participate and work on your organisation as part of GSOC this summer and i am willing to put as many hours as required per day to match the skill set required provided i get directions from my mentor and complete the job perfectly in given time. I know c++,c,R,octave,java. Please let me know how to start and look forward to hear from you. Your faithful, Saurabh Goyal

2 1

Re: [PATCH 5/5] wine.inf: Add some knownfolders to the registry
by Marvin 02 Mar '15

02 Mar '15

2 1

Re: user32: Enforce that surfaces are flushed after ReleaseDC.
by Alexandre Julliard 02 Mar '15

02 Mar '15

Sebastian Lackner <sebastian(a)fds-team.de> writes: > @@ -1116,6 +1116,7 @@ HDC WINAPI GetWindowDC( HWND hwnd ) > */ > INT WINAPI ReleaseDC( HWND hwnd, HDC hdc ) > { > + flush_window_surfaces( FALSE ); > return release_dc( hwnd, hdc, FALSE ); > } I don't think we can afford to do that, we'd be flushing constantly. -- Alexandre Julliard julliard(a)winehq.org

2 2

Re: [PATCH] vbscript: Implemented Asc
by Nikolay Sivov 02 Mar '15

02 Mar '15

On 02.03.2015 11:12, Shuai Meng wrote: > + HRESULT hres; > + BSTR bstr; > + WCHAR ret; > + > + TRACE("(%s)\n", debugstr_variant(arg)); > + > + switch(V_VT(arg)) { > + case VT_NULL: > + return MAKE_VBSERROR(VBSE_ILLEGAL_NULL_USE); > + case VT_EMPTY: > + return MAKE_VBSERROR(VBSE_ILLEGAL_FUNC_CALL); > + case VT_BSTR: > + bstr = V_BSTR(arg); > + default: > + hres = to_string(arg, &bstr); > + if(FAILED(hres)) > + return hres; > + } > + > + ret = bstr[0]; > + if(ret == 0) > + return MAKE_VBSERROR(VBSE_ILLEGAL_FUNC_CALL); > + return return_short(res, ret); Looks like you need to handle VT_NULL explicitly and after that only distinguish between VT_BSTR or the rest. Also you're leaking memory and missing a 'break'.

2 1

Re: [PATCH 1/3] ntdll/tests: Tests for RtlIpv6StringToAddress (try 4)
by Stefan Dösinger 02 Mar '15

02 Mar '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Am 2015-03-02 um 00:08 schrieb Mark Jansen: > + for (n = 0; name_a[n]; ++n) > + name[n] = name_a[n]; > + name[n] = 0; As discussed on IRC please use RtlMultiByteToUnicodeN here. Other tests use it for similar purposes, so I think it is OK to load and use here as well. Note that the other tests assume the function is available, so you don't need to add a skip() check for it. There are a few things where I don't know if Alexandre cares about them: The long lines (it may make sense to add some line breaks e.g. in long table entries), adding things like "ex_fails" in patch 1 rather than patch 2 where they are actually used (I think it's better to keep it your way, moving this to the other patch will be lots of work and won't improve readability), and the W test could in theory be moved to a separate patch. Personally I am fine with keeping those things the way they currently are. - From Patch 2: > + init_ip6(&expected_ip, ipv6_tests[i].ip); > + > + /* we do not test ip if the ex has a special case failure here. */ > + if (res == expect_ret) > + { > + ok(!memcmp(ip.s6_addr, expected_ip.s6_addr, sizeof(ip._S6_un)), > + "[%s] ip = %x:%x:%x:%x:%x:%x:%x:%x, expected %x:%x:%x:%x:%x:%x:%x:%x\n", I'm not sure what the comment means. Afaics you're always checking the IP except in case of win_broken_6. ex_fail_6 doesn't matter here. You can move the init_ip6 call into the if branch since you're not using it otherwise. - From Patch 3: > + //ok(terminator == ipv4_tests[i].address + ipv4_tests[i].terminator_offset, > + // "[%s] terminator = %p, expected %p\n", > + // ipv4_tests[i].address, terminator, ipv4_tests[i].address + ipv4_tests[i].terminator_offset); Leftover code from the A test? Since Ex doesn't write the terminator you can just remove that I think. Personally I am not too fond of the test changing its own input data (i.e., the !(ipv4_tests[i].flags & strict_diff_4) case), but since this is existing code I'd say keep it that way. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJU9DszAAoJEN0/YqbEcdMwo6AP/jU5NK5YqSXGuUYi1eOoaSAu 23nR4KvoaS/lXnPsZ2QPm+kyeSsWynwj0UYZ4dJJczve81m+5YYDLe4zc5Io/Fz0 C4x8WIMiBGPbhYM+iyIVAItz1wnL/9sB2IrlocQ/N9gYU1m25FLMBLvORePfQQs5 UEOOeZbaws7Qd8n+XDR7JRY9e946B7OVG8TFfq4in8IlPUsmmy+m65jQXGgQeBcF JZgOqJH+fSqW0yf3sHhok9wj7KrRpDVUgBlowBXooBz5uuEJwbQ3IwlrbL28PNIj PylUAHdVjeoHmKRif8gykwOt0laOe+RenSxegJbYbz3nw/d9Jmicj5n6W0W92hvb EPMR0a/HbNF2P6TKQIKSMwoaKhtxRXzfcgBz3Ff3LH63qtRYHxMAneU/yaueBMxR ZmfgWT9FHofH5dk2b4rRuP8XhKB/UFyqhlmimIBeDATO/aasNYuRjYlmce1NnfDa pQqW+ntq/H8TEz1jc2IQS0dm9iQZITSMkQnyJdcMi2GTQEh8y41wa0MuOTC+DavF 8HqmTmo7+/VeaZfAmWx1ndtrSktcPDr4wM70aYPcRP1+JyLsLDfkoV5VDXaelZc2 PwH1MBp6ZTv8t5ckaer4wCpvuDH972/jjB56FnbRF1SiFoYcMEs+ZuHHF5YpMn5A Pd6IazMRvRk6dd+ewaSJ =aaY5 -----END PGP SIGNATURE-----

1 0

Re: include: Correct DDSCAPS2 and DDSURFACEDESC2 structures and their uses.
by Stefan Dösinger 02 Mar '15

02 Mar '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2015-03-02 um 02:05 schrieb Sebastian Lackner: > + union { > + DWORD dwBackBufferCount;/* 14: number of back buffers requested*/ > + DWORD dwDepth; > + } DUMMYUNIONNAME5; I don't mind if this patch is accepted, but I just want to note that this change was introduced in the directx8 SDK and doesn't exist in the dx7 SDK. Ddraw applications are probably not written with this change in mind, although since this is a nameless union it probably doesn't matter. The dwDepth member is most likely intended for .DDS files rather than the ddraw API. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJU9CWyAAoJEN0/YqbEcdMwhkAP/i8IUaEfm8xPckGUR6gmdChk mFNo1FS8cxs+a8CRI9P2VoLRTh68P0/tFuKVXT0vgkXApKx+vLeoRHngWktbgVSB ex05mVmlMPDlyw3rPqAw7GydbVxQKkTAzgrgskhZnEl8AjkZn1AcAzZ+LHkcLzAi MGhs1GyglPypGw996tScA0ZcAifQ/znLqA1l5y7J0iuF4jQQ/O2nVoWHZRGekWlC zJAf+2HDC+tVyF+72aefS4Oa9PyZROV36jN1vjpsfymDMB+d1pBL89xbFYMK7n+O RahYtTM1hPZS/WxWm/kF6N6kbVdj98CH4gmRoMymPmifeRpyb9SeSYZz3Aw4SJs0 j8YZb+D0o5wCYrZwXpS7cfpJ3JeKlqvifidlDpOPhTN0tU1qhNUJjTUvF159g9gR J9v/2z+XtnwtLXM0WPQGIzqwEVYwhXcxThsBoRGUVQ2/v4v9eSlVvQfyVe5LbWnc CSI7F6Q1dlue41ddWVlp/k3hbHvXw2j0AdW1eP7yj0rgbA34rt+OLRaPdbIdsZoV KWGr73foUb2brpVIN2Ms9Nmkx5ZBnIYwtfzxx54jurDFzP2+3VZI4r3QtVsm7Lv3 EcSAVB2Jhz27ueVVxAiy31Ol/6rG7Om3Sqs0UTsEWCwI3NSIL03MqoDDv8j8vVAW BQJPiryDjAgC4dA1k4+8 =AOlH -----END PGP SIGNATURE-----

1 0

Re: [PATCH] vbscript: Implemented Asc
by Marvin 02 Mar '15

02 Mar '15

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=11829 Your paranoid android. === w2000pro (32 bit) === No test summary line found === wxppro (32 bit) === No test summary line found === w2003std (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: include/debug.h: Support tracing of VT_BSTR|VT_BYREF
by Nikolay Sivov 01 Mar '15

01 Mar '15

Please ignore this one.

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel March 2015