wine-devel December 2014

wine-devel@winehq.org

51 participants
126 discussions

Re: ole32:fix CoWaitForMultipleHandles cause RPC hang
by Sebastian Lackner 13 Dec '14

13 Dec '14

On 11.12.2014 15:07, Changhui Liu wrote: > Because there's a RPC request need to be handled by OLE apartment window proc apartment_wndproc. > So, after received a WM_QUIT, > if the GUI thread in calling CoWaitForMultipleHandles don't handle message loop any more , > the RPC will never be handled, the RPC dispatch thread will be hang. > > > > There are several issues with this patch. You wrote in your last mail: > so this patch can't pass test on testbot.winehq.org, it only pass test on wine. > The test result is here, https://testbot.winehq.org/JobDetails.pl?Key=10727. It is not clear what you mean. The test should of course also pass on testbot.winehq.org, if it doesn't, this means that Wine doesn't properly reproduce the expected behaviour. You need to create a test so that it passes on both wine and the testbot, otherwise nothing is tested at all. Other issues in your patch: * It seems very unlikely that this is how quit messages are processed. Immediately calling PostQuitMessage(...) but continuing to process messages means that effectively WM_QUIT is lost. * Always add a "\n" at the end of ok(...) messages. * Try to avoid huge sleeps like Sleep(5000). This will probably cause the tests time out. Unfortunately I didn't have much time to look into this issue myself so far, but I guess I'll have more time at the weekend. Regards, Sebastian

2 4

Re: [PATCH v3 03/10] reg: Add system error printing function
by Indrek Altpere 13 Dec '14

13 Dec '14

Seems that the patches have reached the magical "1 month" limit where they disappear from the list silently. Last I saw, your patchset contained about 8 or 10 patches? Not sure if the best suggestion by official rules/guidelines, but perhaps it would be possible to add the new stuff in multiple, smaller patchsets, instead of one mega-patchset? It would mean that reviewers don't have to dig around in hundreds of lines of code changes that change a lot of functionality, makes it hard to keep track of all of it and review it thoroughly. Many big patchsets have gotten stalled like that: reviewer notices a few things, notifies developer, developer makes the changes, sends the changed full patchset again, reviewer checks full patchset again, finds more stuff in next files (or even the same files), notifies developer and so on and so on. Sometimes multiple reviewers also cause havoc, because due to many coding rules not being written down (http://wiki.winehq.org/SubmittingPatches contains general and vague guidelines, but essentially 0 hard examples) and each reviewer having a bit different viewpoint about what styling issues are could-be or should-be, so sending a huge set will end up with responses "here's about ~10 things wrong with your code" and like that after each submit. As I understand, someone correct me if I'm wrong, there is currently also no active reg component maintainer, who would be able to review things quickly, so smaller patchset would probably help things move along much faster? About https://source.winehq.org/patches/data/107580 getting stalled, I have no clue/opinion, does not seem to be overly complex? Regards, Indrek Altpere

3 2

Re: jscript: Added test of Date object default value.
by Marvin 12 Dec '14

12 Dec '14

1 0

Re: [PATCH v4 2/4] combase: Implement creation and deletion of HSTRING objects.
by Martin Storsjö 12 Dec '14

12 Dec '14

On Wed, 10 Dec 2014, Martin Storsjo wrote: > --- > configure.ac | 1 + > .../api-ms-win-core-winrt-string-l1-1-0.spec | 8 +- > dlls/combase/Makefile.in | 3 +- > dlls/combase/combase.spec | 8 +- > dlls/combase/string.c | 143 +++++++++++++++++++++ > dlls/combase/tests/Makefile.in | 4 + > dlls/combase/tests/string.c | 128 ++++++++++++++++++ > tools/make_specfiles | 1 + > 8 files changed, 287 insertions(+), 9 deletions(-) > create mode 100644 dlls/combase/string.c > create mode 100644 dlls/combase/tests/Makefile.in > create mode 100644 dlls/combase/tests/string.c Any further comments on these ones (2-4), or should I resubmit them for a new look? // Martin

1 0

Drawbridge -- WinAPI/NT API sandbox in Windows
by Saulius Krasuckas 11 Dec '14

11 Dec '14

Hello, I just have heard about MS project called Drawbridge. [*] They use NT kernel (ntoskrnl + win32k) implementation in user-mode (NTUM) to load native DLLs and services from different versions of Windows, IIUC. Set of downcalls from NTUM (to native kernel) is reduced to 45 items. This way a process-based isolation is achieved. Some sort of sandbox/container. It sounds like Wine on Windows. Just FYI. S. [*] http://research.microsoft.com/en-us/projects/drawbridge/

1 0

Re: ole32:fix CoWaitForMultipleHandles cause RPC hang
by Marvin 11 Dec '14

11 Dec '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=10727 Your paranoid android. === w2000pro (32 bit compobj) === compobj.c:2325: compobj.c:2299: Test failed: sleep 5 second === wxppro (32 bit compobj) === compobj.c:2325: compobj.c:2299: Test failed: sleep 5 second === wvistau64 (32 bit compobj) === compobj.c:2299: Test failed: Expected OLE apartment window is valid!compobj.c:2334: The RPC request is processed OK! === w2008s64 (32 bit compobj) === compobj.c:2299: Test failed: Expected OLE apartment window is valid!compobj.c:2334: The RPC request is processed OK! === w7u (32 bit compobj) === compobj.c:2299: Test failed: Expected OLE apartment window is valid!compobj.c:2334: The RPC request is processed OK! === w8 (32 bit compobj) === compobj.c:2299: Test failed: Expected OLE apartment window is valid!compobj.c:2334: The RPC request is processed OK! === wvistau64 (64 bit compobj) === compobj.c:2299: Test failed: Expected OLE apartment window is valid!compobj.c:2334: The RPC request is processed OK! === w2008s64 (64 bit compobj) === compobj.c:2299: Test failed: Expected OLE apartment window is valid!compobj.c:2334: The RPC request is processed OK!

1 0

Re: ole32:fix CoWaitForMultipleHandles cause RPC hang
by Marvin 11 Dec '14

11 Dec '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=10726 Your paranoid android. === w2000pro (32 bit compobj) === compobj.c:2296: Test failed: Expected OLE apartment window is valid!compobj.c:2325: sleep 1 second === wxppro (32 bit compobj) === compobj.c:2296: Test failed: Expected OLE apartment window is valid!compobj.c:2325: sleep 1 second === wvistau64 (32 bit compobj) === compobj.c:2296: Test failed: Expected OLE apartment window is valid!compobj.c:2325: sleep 1 second === w2008s64 (32 bit compobj) === compobj.c:2296: Test failed: Expected OLE apartment window is valid!compobj.c:2325: sleep 1 second === w7u (32 bit compobj) === compobj.c:2296: Test failed: Expected OLE apartment window is valid!compobj.c:2325: sleep 1 second === w8 (32 bit compobj) === compobj.c:2296: Test failed: Expected OLE apartment window is valid!compobj.c:2325: sleep 1 second === wvistau64 (64 bit compobj) === compobj.c:2296: Test failed: Expected OLE apartment window is valid!compobj.c:2325: sleep 1 second === w2008s64 (64 bit compobj) === compobj.c:2296: Test failed: Expected OLE apartment window is valid!compobj.c:2325: sleep 1 second

1 0

Re: d3dx9: ID3DXFont PreloadCharacters return S_OK
by Bruno Jesus 11 Dec '14

11 Dec '14

On Thu, Dec 11, 2014 at 1:27 AM, Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> wrote: > Hi, > If any program uses the SharpDX library, it throws an exception when > PreloadCharacters > returns E_NOTIMPL. > > Changelog: > d3dx9: ID3DXFont PreloadCharacters return S_OK Missing patch. > > Best Regards > Alistair Leslie-Hughes Regards, Bruno

1 0

Re: dwrite: Block creation of unsupported face types
by Marvin 10 Dec '14

10 Dec '14

1 0

Re: [8/9] winhttp: Don't try to read data when the server response is HTTP_STATUS_NO_CONTENT or HTTP_STATUS_NOT_MODIFIED.
by Bruno Jesus 10 Dec '14

10 Dec '14

On Tue, Dec 9, 2014 at 9:50 AM, Hans Leidekker <hans(a)codeweavers.com> wrote: > Tests based on a patch by Bruno Jesus. > --- > dlls/winhttp/request.c | 15 ++++++----- > dlls/winhttp/tests/winhttp.c | 62 +++++++++++++++++++++++++++++++++++++++++++- > 2 files changed, 69 insertions(+), 8 deletions(-) > Hans, I can no longer find the bug that this was about. Can you please give the bug URL? Do you think your current patch set fixed it? Best regards, Bruno

2 1

← Newer
1
...
5
6
7
8
9
10
11
12
13
Older →

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 December 2014