wine-devel February 2016

wine-devel@winehq.org

55 participants
280 discussions

Re: windowscodecs/tests: Use todo_wine_if() in tests.
by Frédéric Delanoy 27 Feb '16

27 Feb '16

Arf, forget this one, bad title. My bad. Frédéric On Sat, Feb 27, 2016 at 2:42 PM, Frédéric Delanoy <frederic.delanoy(a)gmail.com> wrote: > Signed-off-by: Frédéric Delanoy <frederic.delanoy(a)gmail.com> > --- > dlls/dxgi/tests/device.c | 20 ++++---------------- > 1 file changed, 4 insertions(+), 16 deletions(-) > > diff --git a/dlls/dxgi/tests/device.c b/dlls/dxgi/tests/device.c > index dd5da83..7b052d3 100644 > --- a/dlls/dxgi/tests/device.c > +++ b/dlls/dxgi/tests/device.c > @@ -478,19 +478,13 @@ static void test_createswapchain(void) > hr = IDXGISwapChain_GetDesc(swapchain, &result_desc); > ok(SUCCEEDED(hr), "GetDesc failed, hr %#x.\n", hr); > > ...

1 0

[PATCH] comdlg32: Use SetDlgItemInt() instead of writing number manually.
by carlo.bramix＠libero.it 27 Feb '16

27 Feb '16

Hello friends, I have sent this patch: https://source.winehq.org/patches/data/119492 but it has been put in "Formatting" state and I cannot understand why. Could you help me and tell me what's wrong, so I will use more attention next time? Thank you very much. Sincerely, Carlo Bramini.

3 2

[GSoC] Idea: Implement functions from Concurrency namespace
by YongHao Hu 27 Feb '16

27 Feb '16

Hello, folks. I'm YongHao Hu. I participated in GSoC of Wine last year and most of the work are finished. This year I want to implement functions from Concurrency namespace[1]. As Wine had already implemented class Concurrency::critical_section[2], SpinWait and Concurrency::details::_GetConcurrency, and I had found information in Microsoft open-source project for cloud-based client-server communication in native code using a modern asynchronous C++ API design[3] which are helpful for the implementation, I think that I am able to handle this project. By now, I had made some patches as my proof of concept.[4] There are many bugs[4-8] relied on functions from Concurrency namespace, this project would fix some bugs and benefit wine's behavior on many software. By making an appropriate proposal, I think the project's work can satisfy GSoC's requirement. Thank you for reading this email. I will be grateful for any advice you can provide. [1]: https://msdn.microsoft.com/en-us/library/dd492819.aspx [2]: https://msdn.microsoft.com/en-us/library/dd492843.aspx [3]: https://github.com/Microsoft/cpprestsdk [4]: https://github.com/YongHaoWu/wine-hub/commits/Concurrency [5]: https://bugs.winehq.org/show_bug.cgi?id=37887 [6]: https://bugs.winehq.org/show_bug.cgi?id=37997 [7]: https://bugs.winehq.org/show_bug.cgi?id=39685 [8]: https://bugs.winehq.org/show_bug.cgi?id=34676 [9]: https://bugs.winehq.org/show_bug.cgi?id=37976

3 6

Wine Mono release plans
by Vincent Povirk 26 Feb '16

26 Feb '16

Hi everyone, With Wine moving to a yearly stable release series, I thought it would make sense to base Wine Mono updates on that schedule. My general plan is to create a branch of Wine Mono after each new development series of Wine begins. After this branch is made, there will be no more merges from upstream Mono (barring some compelling changes that can't easily be cherry-picked). Build fixes and obviously correct bug fixes for related platforms will be cherry-picked from upstream, as will changes that look especially relevant to Wine. If you want to suggest a specific change for Wine Mono (whether it's upstream or not), email me or send a pull request to one of my repositories on github. I've made a wine-mono-4.6 branch for this on github (https://github.com/madewokherd/wine-mono/tree/wine-mono-4.6) and there are 4.6.0 packages on dl.winehq.org (http://dl.winehq.org/wine/wine-mono/4.6.0/). I plan to send patches to update Wine to use this version shortly, but as always you can install it early if you want by using 'wine64 msiexec' (or just 'wine msiexec' if you have a 32-bit prefix). Merges from upstream Mono will still be made on the master branch, and I will work to keep Wine compatible with the master branch as the development cycle goes on. However, no releases will be made from the master branch. Each Wine Mono series will be compatible with the corresponding development series of Wine, and the stable series before and after. Thus all Wine Mono 4.6.x versions should work with Wine 1.8.x, 1.9.x, or 2.0.x. I'm not sure if I will continue to publish changelogs for each release. In this case, the only major changes in 4.6.0 are the update from upstream and the ability to function on a basic level in a 64-bit Wine process.

1 0

Re: [PATCH] winex11: Don't create a temporary context each time X11DRV_wglBindTexImageARB is called.
by Matteo Bruni 26 Feb '16

26 Feb '16

2016-02-25 16:22 GMT+01:00 Miklós Máté <mtmkls(a)gmail.com>: > Theoretically wglBindTexImageARB is supposed to be a fast > render-to-texture method, and creating a new context is anything but fast. > > This fixes horrible performance in Star Wars > Knights of the Old Republic when post-process effects are enabled. > > Signed-off-by: Miklós Máté <mtmkls(a)gmail.com> > --- > dlls/winex11.drv/opengl.c | 9 +++++++-- > 1 file changed, 7 insertions(+), 2 deletions(-) > > diff --git a/dlls/winex11.drv/opengl.c b/dlls/winex11.drv/opengl.c > index 99befde..d2b72cf 100644 > --- a/dlls/winex11.drv/opengl.c > +++ b/dlls/winex11.drv/opengl.c > @@ -235,6 +235,8 @@ struct wgl_pbuffer > GLenum texture_type; > GLuint texture; > int texture_level; > + GLXContext tmp_context; > + int has_tmp_context; > }; You don't need the "has_tmp_context" field, the struct is zeroed at allocation and you can just check if the context is non-zero. You do need to store the context which was current at the time tmp_context was last created though (see below). > > enum dc_gl_type > @@ -2940,12 +2942,15 @@ static BOOL X11DRV_wglBindTexImageARB( struct wgl_pbuffer *object, int iBuffer ) > } > > TRACE("drawable=%lx, context=%p\n", object->drawable, prev_context); > - tmp_context = pglXCreateNewContext(gdi_display, object->fmt->fbconfig, object->fmt->render_type, prev_context, True); > + if (!object->has_tmp_context) { > + object->tmp_context = pglXCreateNewContext(gdi_display, object->fmt->fbconfig, object->fmt->render_type, prev_context, True); > + object->has_tmp_context = 1; > + } As I mentioned in my previous reply, the temporary context is shared with prev_context (which is correct, second to last parameter of glXCreateNewContext()) and that means it has to be recreated if prev_context changes between calls to wglBindTexImageARB. So please store prev_context in object and destroy and recreate the temporary context if the current prev_context is different.

1 0

Re: [PATCH 2/2] authz: Stub functions AuthzAccessCheck, AuthzFreeContext, AuthzInitializeContextFromSid, AuthzInitializeContextFromToken
by Sebastian Lackner 26 Feb '16

26 Feb '16

On 25.02.2016 08:50, Alistair Leslie-Hughes wrote: > From: Zhenbo Li <litimetal(a)gmail.com> > > Moved defines to authz.h I will assume you typed the definitions in patch 1 yourself, and did not move them from Zhenbo Lis patch - otherwise a remark about authorship would be necessary in 1/2. > Minor cleanup of parameter names. > > Signed-off-by: Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> > --- > dlls/authz/authz.c | 58 +++++++++++++++++++++++++++++++++++++++++++++++++++ > dlls/authz/authz.spec | 8 +++---- > 2 files changed, 62 insertions(+), 4 deletions(-) >

2 2

Re: [PATCH 2/2] Programs: Load device drivers of the same group into the same winedevice process
by Sebastian Lackner 26 Feb '16

26 Feb '16

On 24.02.2016 15:16, Aric Stewart wrote: > Signed-off-by: Aric Stewart <aric(a)codeweavers.com> > --- > programs/services/services.c | 124 ++++++++++++++++++++++++++++ > programs/winedevice/device.c | 191 ++++++++++++++++++++++++++++++++++++------- > 2 files changed, 286 insertions(+), 29 deletions(-) > Although the general idea seems fine, the patches are still very hacky, and I fear we need a better method to communicate between services and winedevices - a separate mailslot communication doesn't seem like a good idea. The main issues I still see: * Instead of two separate communication channels, we should implement marshalling of data structures, and return them for example in the ServiceCtrlHandler callback. Depending on the exact mechanism, special care has to be taken to ensure the process is up and running before sending control commands. * Currently wine supports loading of both 32-bit and 64-bit drivers. This needs special care in both patch 1 and patch 2. A winedevice process with the wrong architecture will not be able to load the driver. * programs/services should be able to track the services correctly. Unfortunately it seems like the advapi32 functions do not offer any nice method to add additional services after startup. Maybe we could add a wine-specific extension here? * Proper locking is required before accessing the database or services structures. Those are technical issues though, and can be fixed of course. I'm currently trying a couple of own ideas, and will share them as soon as they do something useful. ;) Regards, Sebastian

2 1

Re: [PATCH] configure: Check for __builtin_ms_va_list on all x86_64 platforms.
by Alexandre Julliard 26 Feb '16

26 Feb '16

Charles Davis <cdavis5x(a)gmail.com> writes: > If we're running configure, we're probably not going to be using Visual > C++, even on Windows. Everywhere else, we need this for variadic > argument lists to work. You could probably unify the Mac OS case with the x86_64 one, instead of adding another check for the build host. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH] winex11: Don't create a temporary context each time X11DRV_wglBindTexImageARB is called.
by Ken Thomases 26 Feb '16

26 Feb '16

On Feb 25, 2016, at 9:22 AM, Miklós Máté <mtmkls(a)gmail.com> wrote: > > Theoretically wglBindTexImageARB is supposed to be a fast > render-to-texture method, and creating a new context is anything but fast. > > This fixes horrible performance in Star Wars > Knights of the Old Republic when post-process effects are enabled. > > Signed-off-by: Miklós Máté <mtmkls(a)gmail.com> > --- > dlls/winex11.drv/opengl.c | 9 +++++++-- > 1 file changed, 7 insertions(+), 2 deletions(-) You need to destroy the temporary context when the pbuffer object is destroyed in X11DRV_wglDestroyPbufferARB(). -Ken

1 0

Re: user32: Preserve beginning of extra data for MDI windows.
by Marvin 26 Feb '16

26 Feb '16

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=20905 Your paranoid android. === w7u (32 bit msg) === msg.c:8803: Test failed: did not get expected count for minimum timeout (54 != ~100). === w1064 (32 bit msg) === msg.c:6294: Test failed: Update region shouldn't be empty msg.c:6528: Test failed: InvalidateErase: 0: the msg sequence is not complete: expected 0085 - actual 0000 msg.c:6530: Test failed: Paint: 0: the msg sequence is not complete: expected 000f - actual 0000 msg.c:6300: Test failed: Regions are different msg.c:6300: Test failed: Regions are different msg.c:6300: Test failed: Regions are different

2 1

← Newer
1
2
3
4
5
6
7
...
28
Older →

Jump to page:

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 February 2016