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

Re: Help with testing new Gecko downloader

by Jacek Caban

Hi Austin, On 03/04/15 08:57, Austin English wrote: > Hi Jacek, > > I've tested a bit with wine-1.7.35 and git, I haven't experienced any > issues with the new downloader. I didn't notice any extremely slow > downloads/starts, but I didn't attempt to time it. Thanks for the > improvements. Thanks for testing. Given overall positive feedback and the fact that new Wine Mono was just released, I sent a patch that should use the same code for Wine Mono. I originally planned to propagate is slower, but I think people could use faster downloads when we're about to release Wine with two addons updated. Thanks, Jacek

March 4, 2015

Re: include: add initial d3dx10core.h

by Michael Stefaniuc

On 03/03/2015 09:16 PM, Austin English wrote: > On Tue, Mar 3, 2015 at 6:56 AM, Matteo Bruni <matteo.mystral(a)gmail.com > <mailto:matteo.mystral(a)gmail.com>> wrote: > > 2015-03-03 13:21 GMT+01:00 Matteo Bruni <matteo.mystral(a)gmail.com > <mailto:matteo.mystral(a)gmail.com>>: > > Can you replace the names of the methods arguments with some > > non-Hungarian alternatives? If nothing else, just to avoid having > > those declarations match those in the MS header character by > > character. > > > > Also please avoid tabs. > > Nikolay suggested on IRC to write this header in IDL for Wine. That > would be a better option if it works (it should). > > > Sure. I was trying to keep to what the DXSDK was doing, but if an IDL is > preferred, no problem. IDL is always preferred for COM interface declarations even if the SDK has only the .h file. Of course only if it is technical possible. Converting the existing headers to IDL is a nice and trivial janitorial task.</hint> ;) bye michael

March 4, 2015

Re: Help with testing new Gecko downloader

by Austin English

On Fri, Feb 27, 2015 at 5:40 AM, Jacek Caban <jacek(a)codeweavers.com> wrote: > Hi all, > > My today patch [1] together with changes in Wine code from yesterday > changed the way we interact with SourceForge for downloading Gecko. It's > a risky change that could use wider testing from different locations. If > you'd like to help, you need to: > > - Remove wine_gecko-2.36*.msi if you already have it. If you used > downloader to get it, it's most likely in ~/.cache/wine. If you > downloaded it manually, you know where to find it. > - Create new wineprefix > > The most important thing is to ensure that downloading and installing > Gecko still works. The expected difference is shorter connection time > and faster downloads (or better said, no slow downloads). > > I appreciate any feedback on this. > > Thanks, > Jacek > > > [1] http://source.winehq.org/patches/data/109462 > > > Hi Jacek, I've tested a bit with wine-1.7.35 and git, I haven't experienced any issues with the new downloader. I didn't notice any extremely slow downloads/starts, but I didn't attempt to time it. Thanks for the improvements. -- -Austin

March 4, 2015

Re: GSOC 2015 Applicant

by Austin English

On Tue, Mar 3, 2015 at 8:09 AM, Balkrishna Srivastava < f2012682(a)pilani.bits-pilani.ac.in> wrote: > Hi, I am Balkrishna Srivastava, a 3rd year dual degree undergraduate from > BITS Pilani, Pilani Campus, India. > > I completed my computer programming course in C. I have also been doing > extensive competitive coding on codechef.com in c ( profile: > http://www.codechef.com/users/bali161616 ). > > I wish to contribute to your organisation this GSOC. > I know c, java, python and c++. > > Please guide me how to go about contributing to your organization. > > -- > *Regards* > *BALKRISHNA SRIVASTAVA* > *Undergraduate Student* > *B.E.(Hons.) Computer Science* > *M.Sc.(Hons.) Physics* > > *▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄* > > *Birla Institute of Technology & Science,* *Pilani* > See http://wiki.winehq.org/SummerOfCode for information about Wine and Summer of Code. You'll need to propose a project (and make sure you've submitted a patch to Wine) before applying. -- -Austin

March 4, 2015

Re: [PATCH] vbscript: Implemented Asc(try 3)

by Nikolay Sivov

On 04.03.2015 9:19, Shuai Meng wrote: > + switch(V_VT(arg)) { > + case VT_NULL: > + return MAKE_VBSERROR(VBSE_ILLEGAL_NULL_USE); > + case VT_BSTR: > + bstr = V_BSTR(arg); > + break; > + default: > + hres = to_string(arg, &bstr); > + if(FAILED(hres)) > + return hres; > + } > + > + ret = bstr[0]; > + SysFreeString(bstr); > + > + if(ret == 0) > + return MAKE_VBSERROR(VBSE_ILLEGAL_FUNC_CALL); > + return return_short(res, ret); This is wrong too. You can't always free it like that, please look carefully at where 'bstr' comes from.

March 4, 2015

Re: ntdll: Assert when trying to replace an exiting file descriptor in fd_cache.

by Alexandre Julliard

Sebastian Lackner <sebastian(a)fds-team.de> writes: > On 04.03.2015 08:15, Alexandre Julliard wrote: >> Sebastian Lackner <sebastian(a)fds-team.de> writes: >> >>> The condition "prev_fd != -1" should never be true. If this is the case then something >>> is going terrible wrong, and it is better to assert instead of just closing the file >>> descriptor. >> >> It can happen if the handle was closed on the server side but not yet >> removed from the cache. Yes, handling of that case is not ideal, but an >> assert is not an improvement. >> > > Thanks for taking a look. Hm, from which codepath can it happen that prev_fd != -1? > The function add_fd_to_cache is only called from server_get_unix_fd, and immediately > before that there is a call to get_cached_fd. If an fd is cached, then the whole code > will never be executed (even if its probably the wrong cached file descriptor). > > Since its all in an uninterrupted section I also see no other reason why fd_cache > should change between get_cached_fd and add_fd_to_cache. Could you explain this a bit? > server_remove_fd_from_cache shouldn't cause any harm, because this function can only > unset a fd_cache entry. Actually you are right, this used to be possible, but with the current code it can't happen. -- Alexandre Julliard julliard(a)winehq.org

March 4, 2015

Re: ntdll: Assert when trying to replace an exiting file descriptor in fd_cache.

by Sebastian Lackner

On 04.03.2015 08:15, Alexandre Julliard wrote: > Sebastian Lackner <sebastian(a)fds-team.de> writes: > >> The condition "prev_fd != -1" should never be true. If this is the case then something >> is going terrible wrong, and it is better to assert instead of just closing the file >> descriptor. > > It can happen if the handle was closed on the server side but not yet > removed from the cache. Yes, handling of that case is not ideal, but an > assert is not an improvement. > Thanks for taking a look. Hm, from which codepath can it happen that prev_fd != -1? The function add_fd_to_cache is only called from server_get_unix_fd, and immediately before that there is a call to get_cached_fd. If an fd is cached, then the whole code will never be executed (even if its probably the wrong cached file descriptor). Since its all in an uninterrupted section I also see no other reason why fd_cache should change between get_cached_fd and add_fd_to_cache. Could you explain this a bit? server_remove_fd_from_cache shouldn't cause any harm, because this function can only unset a fd_cache entry.

March 4, 2015

Re: ntdll: Assert when trying to replace an exiting file descriptor in fd_cache.

by Alexandre Julliard

Sebastian Lackner <sebastian(a)fds-team.de> writes: > The condition "prev_fd != -1" should never be true. If this is the case then something > is going terrible wrong, and it is better to assert instead of just closing the file > descriptor. It can happen if the handle was closed on the server side but not yet removed from the cache. Yes, handling of that case is not ideal, but an assert is not an improvement. -- Alexandre Julliard julliard(a)winehq.org

March 4, 2015

Re: [PATCH] vbscript: Implemented Asc(try 3)

by Marvin

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

March 4, 2015

Re: shell32: fix a test failure in shlfileop.c

by Alexandre Julliard

Zhenbo Li <litimetal(a)gmail.com> writes: > Excuse me, > Is there anything to do to improve this patch? Why doesn't it fail on the normal testruns? -- Alexandre Julliard julliard(a)winehq.org

March 4, 2015