wine-devel July 2019

wine-devel@winehq.org

65 participants
284 discussions

Start a nNew thread

[website] German translation for release 4.12.1
by Julian Rüger 08 Jul '19

08 Jul '19

Signed-off-by: Julian Rüger <jr98(a)gmx.net>

1 0

[website] German translation for release 4.12
by Julian Rüger 08 Jul '19

08 Jul '19

Signed-off-by: Julian Rüger <jr98(a)gmx.net>

1 0

[PATCH 2/2] dxgi: Fix possible null output from d3d11_swapchain_GetFullscreenState.
by Zhiyi Zhang 08 Jul '19

08 Jul '19

When swapchain is created in windowed mode, and then enter fullscreen via Alt+Enter. Calling d3d11_swapchain_GetFullscreenState will return a null output because swapchain->target wasn't initialized. Signed-off-by: Zhiyi Zhang <zzhang(a)codeweavers.com> --- dlls/dxgi/swapchain.c | 20 ++++++++++++++++---- dlls/dxgi/tests/dxgi.c | 2 +- 2 files changed, 17 insertions(+), 5 deletions(-) diff --git a/dlls/dxgi/swapchain.c b/dlls/dxgi/swapchain.c index 8dbbfab805..caf0863609 100644 --- a/dlls/dxgi/swapchain.c +++ b/dlls/dxgi/swapchain.c @@ -407,22 +407,34 @@ static HRESULT STDMETHODCALLTYPE d3d11_swapchain_GetFullscreenState(IDXGISwapCha { struct d3d11_swapchain *swapchain = d3d11_swapchain_from_IDXGISwapChain1(iface); struct wined3d_swapchain_desc swapchain_desc; + HRESULT hr; TRACE("iface %p, fullscreen %p, target %p.\n", iface, fullscreen, target); - if (fullscreen) + if (fullscreen || target) { wined3d_mutex_lock(); wined3d_swapchain_get_desc(swapchain->wined3d_swapchain, &swapchain_desc); wined3d_mutex_unlock(); - *fullscreen = !swapchain_desc.windowed; } + if (fullscreen) + *fullscreen = !swapchain_desc.windowed; + if (target) { - *target = swapchain->target; - if (*target) + if (!swapchain_desc.windowed) + { + if (!swapchain->target && FAILED(hr = IDXGISwapChain1_GetContainingOutput(iface, &swapchain->target))) + return hr; + + *target = swapchain->target; IDXGIOutput_AddRef(*target); + } + else + { + *target = NULL; + } } return S_OK; diff --git a/dlls/dxgi/tests/dxgi.c b/dlls/dxgi/tests/dxgi.c index af396e9acf..f82c3d5f5b 100644 --- a/dlls/dxgi/tests/dxgi.c +++ b/dlls/dxgi/tests/dxgi.c @@ -5455,7 +5455,7 @@ static void test_window_association(void) ok(fullscreen == tests[i].expect_fullscreen || broken(tests[i].broken_d3d10 && fullscreen), "Test %u: Got unexpected fullscreen %#x.\n", i, fullscreen); - todo_wine_if(fullscreen) ok(fullscreen ? !!output : !output, "Got wrong output.\n"); + ok(fullscreen ? !!output : !output, "Got wrong output.\n"); if (output) IDXGIOutput_Release(output); -- 2.20.1

1 0

specific api functions for screen readers questions
by Mgr. Janusz Chmiel 07 Jul '19

07 Jul '19

Dear specialists, Does somebody of you know, if Wine support API functions which could be used by very simple focusable object based screen reader? This screen reader would react on key events and other internal WIne events such as if dialog window have been displaied. Screen reader should send textual content of focusable objects such as buttons, comboboxes, dialog windows, menu items to speech output. Because screen reader which I would like to develop can not use Microsoft components including Microsoft C run-times, SAPI5, 4 or newest Windows 10 speech kit, there is only possibility to develop integrated speech engine from scrath. Or ask you how complex would be for you to develop software bridge between Wine and speech-dispatcher speech server. This software bridge would introduce simple Speech functions and procedures, which would allow developers to send textual data to active speech engine by using Speech-dispatcher speech server. FOr beginning, I would like to know, if Wine contain some USER32.dll and other API calls, which are able to get text information from object which have focus. Sure, screen reader, which I would like to develop will be very simple. It will never be comparable with NVDA, Jaws or with other complex screen readers for Windows. I would like to only develop at least simple focus and event based screen reader, which will be able to use with simple Win 32 apps such as notepad, integrated explorer.exe with Wine, with MP3directcut for Windows, ETC. Because screen reader can not use libraries from Microsoft, I Am aware, that my goal will never produce screen reader which will be able to support object hiearchi browsing inside active Window. Very important question is, if Wine contain APi calls to detect object class name, which will be detected from object, which have focus. Without this routine, my dream will be never possible. Last question. Does integrated Windows PE routines support machine code instructions, which have been generated by Free Basic compiler for Windows? Because I do not know, if generated machine code hhave not been specifically prepared for original Microsoft Windows so if compiled apps, which would run normally from original Windows will not cause random crashes and stability issues when running it with Wine. I can not use programming languages from Microsoft. There are 3 Basic language compiler from other teams than from Microsoft. Power Basic, Free Basic and Pure Basic. BUt Pure Basic is commercial, Power Basic is commercial and Free Basic is The onlyone free Basic compiler, which generates .exe apps which do not depend on Microsoft .dlls as default. I have old time experience with various screen readers. When Windows 3.11 have been developed, two very smart C++ ddevelopers in our country have developed screen readers for Windows 3.11. It did not used mSAA. Screen reader had its internal speech engine which had nothing to do with Speech API, because in 1994 there was no such routines from Microsoft. Screen reader have reacted on keyboard events, it spoken lines of text from editable fields, text of dialog windows, menu items. So do you think, that APi calls which are available inside WIne now can allow Me to develop such focusable object based screen reader? Or it is paradox situation, that WIndows 3.11 16 Bit version from 1994 have allowed that and modern Wine do not allow it? Really, I do not write about Windows 95. It was really Windows FOR WORKGROUPS 3.11 AND ITS 16 BIT VERSION, NOT Win32. Thank you very much for yours kind acces to my questions. I will intrude you as little as possible, I know, that you are very overloaded. I need to know, if my dream can come true or no.

2 1

Wine staging 4.12 release
by Alistair Leslie-Hughes 06 Jul '19

06 Jul '19

Binary packages for various distributions will be available from: https://www.winehq.org/download Summary since last release * Rebased to current wine 4.12 (822 patches are applied to wine vanilla) NOTE: FAudio will not be supported until distro's have FAudio library as part of their standard repositories. This will be the last release that FAudio isn't supported. Upstreamed (Either directly from staging or fixed with a similar patch). * winex11.drv: Allow changing the opengl pixel format on the desktop window. * gdi32: Also accept "\\.\DISPLAY<n>" devices names with <n> other than 1 as display devices. * wininet: Allow to set INTERNET_OPTION_HTTP_DECODING on sessions and connections. Added: * [23166] shlwapi: Support ./ in UrlCanonicalize. * [47419] wined3d: Dont set DDSCAPS_FLIP for gdi renderer. * [24125] kernel32: Implement SetProcessDEPPolicy. * [28170] user32: Added LoadKeyboardLayoutEx stub. * [47439] loader: Add Keyboard Layouts registry enteries. Updated: * none Where can you help * Run Steam/Battle.net/UPlay. * Try you favorite game. * Test your favorite applications. * Improve staging patches and get them accepted upstream. As always, if you find a bug, please report it via https://bugs.winehq.org Best Regards Alistair.

3 2

[PATCH] wined3d: Handle context acquisition failure in wined3d_device_create_primary_opengl_context_cs().
by Henri Verbeet 06 Jul '19

06 Jul '19

Now that we no longer always call context_acquire() from swapchain_init(), context acquisition can fail here instead. This fixes a regression introduced by commit 64d41b3dec0635c56268be64d407ed9bfd8c0695. Signed-off-by: Henri Verbeet <hverbeet(a)codeweavers.com> --- dlls/wined3d/device.c | 13 ++++++++++--- 1 file changed, 10 insertions(+), 3 deletions(-) diff --git a/dlls/wined3d/device.c b/dlls/wined3d/device.c index d35a0648c9c..2c768514c46 100644 --- a/dlls/wined3d/device.c +++ b/dlls/wined3d/device.c @@ -1108,10 +1108,19 @@ void wined3d_device_create_primary_opengl_context_cs(void *object) struct wined3d_texture *target; HRESULT hr; + swapchain = device->swapchains[0]; + target = swapchain->back_buffers ? swapchain->back_buffers[0] : swapchain->front_buffer; + if (!(context = context_acquire(device, target, 0))) + { + WARN("Failed to acquire context.\n"); + return; + } + if (FAILED(hr = device->shader_backend->shader_alloc_private(device, device->adapter->vertex_pipe, device->adapter->fragment_pipe))) { ERR("Failed to allocate shader private data, hr %#x.\n", hr); + context_release(context); return; } @@ -1119,6 +1128,7 @@ void wined3d_device_create_primary_opengl_context_cs(void *object) { ERR("Failed to create CPU blitter.\n"); device->shader_backend->shader_free_private(device, NULL); + context_release(context); return; } wined3d_ffp_blitter_create(&device->blitter, &device->adapter->gl_info); @@ -1127,9 +1137,6 @@ void wined3d_device_create_primary_opengl_context_cs(void *object) wined3d_fbo_blitter_create(&device->blitter, &device->adapter->gl_info); wined3d_raw_blitter_create(&device->blitter, &device->adapter->gl_info); - swapchain = device->swapchains[0]; - target = swapchain->back_buffers ? swapchain->back_buffers[0] : swapchain->front_buffer; - context = context_acquire(device, target, 0); context_gl = wined3d_context_gl(context); wined3d_device_gl_create_dummy_textures(wined3d_device_gl(device), context_gl); create_default_samplers(device, context); -- 2.11.0

1 0

Release 4.12 breakage
by Alexandre Julliard 06 Jul '19

06 Jul '19

Folks, There seems to be some serious breakage with 4.12 on 64-bit, sorry about that. This is what happens when you try to push everything out before leaving on vacation... So I'm going to make a bug fix release soon, and *then* I'll go on vacation for 3 weeks ;-) -- Alexandre Julliard julliard(a)winehq.org

1 0

[PATCH] wineboot: Fix cpuid asm wrapper to use ms_abi convention.
by Hans Leidekker 06 Jul '19

06 Jul '19

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=47464 Signed-off-by: Hans Leidekker <hans(a)codeweavers.com> --- programs/wineboot/wineboot.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/programs/wineboot/wineboot.c b/programs/wineboot/wineboot.c index 834bf92730..f7908561a9 100644 --- a/programs/wineboot/wineboot.c +++ b/programs/wineboot/wineboot.c @@ -207,14 +207,17 @@ __ASM_GLOBAL_FUNC( do_cpuid, "ret" ) #elif defined(__x86_64__) __ASM_GLOBAL_FUNC( do_cpuid, + "pushq %rsi\n\t" "pushq %rbx\n\t" - "movl %edi,%eax\n\t" + "movq %rcx,%rax\n\t" + "movq %rdx,%rsi\n\t" "cpuid\n\t" "movl %eax,(%rsi)\n\t" "movl %ebx,4(%rsi)\n\t" "movl %ecx,8(%rsi)\n\t" "movl %edx,12(%rsi)\n\t" "popq %rbx\n\t" + "popq %rsi\n\t" "ret" ) #else void do_cpuid( unsigned int ax, unsigned int *p ) -- 2.11.0

1 0

Wine on Solaris 2.11
by Rick V 05 Jul '19

05 Jul '19

I've managed to compile the Wine 4.10 runtime bits on Solaris 2, but i keep running into a problem with the native linker (and GNU LD/GOLD) where winebuild/winegcc fails to remove the import symbols from the wrapped PE-in-ELF shared object: ../../tools/winegcc/winegcc -o acledit.dll.so -B../../tools/winebuild -fno-PIC -fasynchronous-unwind-tables \ -shared ../../../dlls/acledit/acledit.spec -mno-cygwin main.o -lsocket -lnsl -mimpure-text -L/usr/local/lib -Wl,-R/usr/local/lib Undefined first referenced symbol in file __wine$func$msvcrt$1016$ftell ../../dlls/msvcrt/libmsvcrt.a(msvcrt.8sjEgq.o) __wine$func$msvcrt$1024$getenv ../../dlls/msvcrt/libmsvcrt.a(msvcrt.k9b5ph.o) __wine$func$msvcrt$1060$localtime ../../dlls/msvcrt/libmsvcrt.a(msvcrt.4A4GdP.o) __wine$func$msvcrt$1019$fwrite ../../dlls/msvcrt/libmsvcrt.a(msvcrt.kAOzVa.o) __wine$func$msvcrt$1007$fread ../../dlls/msvcrt/libmsvcrt.a(msvcrt.socBBA.o) (and so forth) I'm at a loss to describe any extra information, and I don't think using GNU LD or GOLD fixes this (might have to remove any target-specific code in winebuild to fall through to Linux/GNU LD behaviour to check) Thanks R

1 0

[PATCH v2] server: Rename cpu_type_t to client_cpu_t.
by Jacek Caban 05 Jul '19

05 Jul '19

To avoid conflicts with mac headers. Signed-off-by: Jacek Caban <jacek(a)codeweavers.com> --- v2: Includes make_request changes. dlls/kernel32/process.c | 2 +- dlls/ntdll/process.c | 2 +- server/protocol.def | 14 +++++++------- server/trace.c | 14 +++++++------- tools/make_requests | 2 +- 5 files changed, 17 insertions(+), 17 deletions(-)

2 1

← Newer
1
...
13
14
15
16
17
18
19
...
29
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 July 2019