wine-devel January 2016

wine-devel@winehq.org

71 participants
267 discussions

MSSQL ODBC as describesd in 4.3.6.2 4.3.6.2. Using Windows ODBC drivers
by Olaf Schumann 22 Jan '16

22 Jan '16

Hi, This works fine, but if the MSSQL-Server needs SSL the connection fails. To Test it, install MDAC_TYP.EXE from Microsoft (winetricks: win2k and native_mdac) Control Panel->Data Sources(ODBC)->SystemDSN->Add->SQL Server Configure a Server without SSL: Everything's fine. Configure a Server with SSL: Connection fails. I cross-checked this with a Windows 2k VM. Installing MDAC_TYP.EXE. Configuring the above SQL Servers: Connection to a SSL encryption enabled SQL Server works. Best regards, Olaf Olaf Schumann Product Manager ___________________ Logo_email dataplan GmbH Stahltwiete 23 22761 Hamburg, Germany CEO: Dr. Wolfgang Zetsche Comm. Reg.: HRB 31 083 Venue: Hamburg VAT ID No.: DE118540281 Phone +49 40 398 44 20 Fax: +49 40 390 26 39 www.dataplan.de <mailto:oschumann@dataplan.de> mailto:oschumann@dataplan.de

1 0

Re: [2/2] user32: Use IsTextUnicode instead of a helper.
by Nikolay Sivov 22 Jan '16

22 Jan '16

On 22.01.2016 10:11, Jactry Zeng wrote: > - if (!data_looks_unicode( ptr, size )) > + if (!IsTextUnicode((WCHAR *)ptr, sizeof((WCHAR *)ptr), NULL)) Why it's sizeof() now instead of 'size' ? Also why do you need a cast to (WCHAR*)?

2 1

Re: [PATCH v2] server: Implement serial port read interval timeouts.
by Alexandre Julliard 22 Jan '16

22 Jan '16

Alex Henrie <alexhenrie24(a)gmail.com> writes: > Fixes https://bugs.winehq.org/show_bug.cgi?id=39875 > > There is a test program attached to the bug report. > > Signed-off-by: Alex Henrie <alexhenrie24(a)gmail.com> > --- > server/async.c | 14 ++++++++++++++ > server/fd.c | 12 ++++++++++++ > server/file.h | 3 +++ > server/serial.c | 13 ++++++++++++- > 4 files changed, 41 insertions(+), 1 deletion(-) > > diff --git a/server/async.c b/server/async.c > index d2da976..e718462 100644 > --- a/server/async.c > +++ b/server/async.c > @@ -216,6 +216,20 @@ void free_async_queue( struct async_queue *queue ) > release_object( queue ); > } > > +/* set the timeout of the async queue head if the new timeout is shorter than the current one */ > +/* only pass negative timeouts (i.e. timeouts relative to the current time) to this function */ > +void async_queue_set_shorter_timeout( struct async_queue *queue, timeout_t timeout, unsigned int status ) > +{ > + struct list *ptr; > + struct async *async; > + > + if (!(ptr = list_head( &queue->queue ))) return; > + async = LIST_ENTRY( ptr, struct async, queue_entry ); > + > + if (!async->timeout || -timeout < get_timeout_user_remaining( async->timeout )) > + async_set_timeout( async, timeout, status ); > +} You should be able to do this in the serial code, probably by using absolute timeouts. Note that you also need to preserve the original timeout, you can't simply replace it by the interval timeout. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: server: Avoid infinite loop when we're out of timers in set_win_timer server call
by Alexandre Julliard 22 Jan '16

22 Jan '16

Piotr Caban <piotr(a)codeweavers.com> writes: > Signed-off-by: Piotr Caban <piotr(a)codeweavers.com> > --- > server/queue.c | 12 ++++++++++-- > server/trace.c | 1 + > 2 files changed, 11 insertions(+), 2 deletions(-) A test case would be nice. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 1/3] winebuild: Added support for entry points generated in runtime.
by Sebastian Lackner 22 Jan '16

22 Jan '16

On 19.01.2016 12:20, Jacek Caban wrote: > Signed-off-by: Jacek Caban <jacek(a)codeweavers.com> > --- > tools/winebuild/build.h | 1 + > tools/winebuild/parser.c | 1 + > tools/winebuild/spec32.c | 59 > ++++++++++++++++++++++++++++++++++++++++ > tools/winebuild/winebuild.man.in | 3 ++ > 4 files changed, 64 insertions(+) > I would also like to get this issue fixed, so I wouldn't complain if Alexandre really prefers the JIT approach, but I personally still do not really see a big advantage compared to static code generation. Let me quickly explain again why. I'll also send another mail to point a couple of issues with the current patch, but here again first the general discussion. * We have no way to implement support for 64-bit because SYSCALL instructions are directly part of the thunk. Unless we want to remove the "not" in the definition of "Wine is not an emulator", its technically impossible to intercept those Syscalls and we cannot implement it. * 32-bit Windows 8 thunks also cannot be implemented, with the same reason as 64-bit thunks. To see that, just take a look at the expected opcodes: // 00 b825000000 mov eax,25h // 05 e803000000 call eip+3 // 0a c22c00 ret 2Ch // 0d 8bd4 mov edx,esp // 0f 0f34 sysenter // 11 c3 ret // 12 8bff mov edi,edi And at the very strict verification: [...] CallEip != function_code.call_eip || function_code.call_offset != 3 [...] kSysenter != function_code.sysenter * Based on my knowledge, implementing WOW64 doesn't help much because we have no app which relies on it. Although their code technically would support it, it seems like Chromium and Steam never uses it in practice. At least during our testing so far, we haven't found a way to fix that. * Last but not least, one of the reasons why I haven't submitted my own approach so far: The whole idea only works reliable as long as we do NOT forward Ldr* functions to syscall thunks. If we do, like it should work on Windows, and like it is most likely required by other apps, there are race conditions all over the place and Steam webstore only works with a probability of about 50% or less. I haven't figured out what causes it yet. @ Alexandre: Do you have a preferrence? Suggestions we had so far: - JIT compilation of thunks (only x86) - Winebuild generated static thunks (see http://ix.io/nxT ) - Macro-generated thunks (see staging repo) To my knowledge, all have the same limitations: x86, non-wow64 and race-conditions when forwarding Ldr* functions through the syscall thunks. Best regards, Sebastian

6 15

Status of patch #118257
by Pierre Schweitzer 21 Jan '16

21 Jan '16

Hi, Is there anything wrong I can fix about patch #118257? Cheers, -- Pierre Schweitzer <pierre at reactos.org> System & Network Administrator Senior Kernel Developer ReactOS Deutschland e.V.

1 0

Re: [PATCH 1/2] dwrite: Ask freetype once about kerning pairs support and monospaced property
by Alexandre Julliard 21 Jan '16

21 Jan '16

Nikolay Sivov <nsivov(a)codeweavers.com> writes: > Signed-off-by: Nikolay Sivov <nsivov(a)codeweavers.com> > --- > dlls/dwrite/font.c | 10 +++++++--- > 1 file changed, 7 insertions(+), 3 deletions(-) It doesn't work here: ../../../tools/runtest -q -P wine -T ../../.. -M dwrite.dll -p dwrite_test.exe.so font && touch font.ok font.c:3088: Test failed: got 0 font.c:3095: Test failed: got 0 font.c:5059: Tests skipped: Segoe UI Emoji font not found. font.c:5165: Tests skipped: Segoe UI Emoji font not found. Makefile:212: recipe for target 'font.ok' failed make[1]: *** [font.ok] Error 2 -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: [PATCH v2 1/1] ddraw/tests: Port test_lockrect_invalid to other versions.
by Marvin 21 Jan '16

21 Jan '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=19881 Your paranoid android. === w1064 (32 bit ddraw4) === ddraw4.c:2523: Test failed: Expected {0, 0, 512, 384}, got {0, 0, 1024, 768}. === w1064 (32 bit ddraw2) === ddraw2.c:2338: Test failed: Expected {0, 0, 512, 384}, got {0, 0, 1024, 768}. === w1064 (32 bit dsurface) === dsurface.c:144: Test failed: Destination data after blitting is not correct dsurface.c:178: Test failed: Destination data after blitting is not correct dsurface.c:357: Test failed: Surface data after srckey blit does not match dsurface.c:382: Test failed: Surface data after src override key blit does not match dsurface.c:436: Test failed: Surface data after dest key blit does not match dsurface.c:462: Test failed: Surface data after dest key override blit does not match dsurface.c:524: Test failed: Surface data with src key and dest key blit does not match === w1064 (32 bit ddraw1) === ddraw1.c:2187: Test failed: Expected {0, 0, 512, 384}, got {0, 0, 1024, 768}. === w1064 (32 bit ddraw7) === ddraw7.c:2254: Test failed: Expected {0, 0, 512, 384}, got {0, 0, 1024, 768}.

1 0

Re: [PATCH 4/8] d3d11: Handle NULL source box in d3d10_device_CopySubresourceRegion().
by Henri Verbeet 21 Jan '16

21 Jan '16

On 19 January 2016 at 22:28, Józef Kucia <jkucia(a)codeweavers.com> wrote: > @@ -4002,15 +4002,25 @@ HRESULT CDECL wined3d_device_copy_sub_resource_region(struct wined3d_device *dev > } > src_surface = surface_from_resource(tmp); > > + if (src_box) > + { > + src_rect.left = src_box->left; > + src_rect.top = src_box->top; > + src_rect.right = src_box->right; > + src_rect.bottom = src_box->bottom; > + } > + else > + { > + src_rect.left = 0; > + src_rect.top = 0; > + src_rect.right = src_surface->resource.width; > + src_rect.bottom = src_surface->resource.height; > + } That's mostly what surface_get_rect() does, except that it doesn't take a wined3d_box structure, of course. wined3d_surface_blt() can handle a NULL src_rect though, so you don't need to do it here. It may make sense to require callers to pass a non-NULL wined3d_box to wined3d_texture_blt(). I think that everything that calls wined3d_surface_blt() or wined3d_texture_blt() should have easy access to the surface dimensions. That's a bit more involved because there are callers outside wined3d though.

2 2

Re: [PATCH 2/3] oleaut32: BSTRs should have 8 byte alignment on 64 bits.
by Jacek Caban 21 Jan '16

21 Jan '16

On 01/21/16 11:29, Huw Davies wrote: > Signed-off-by: Huw Davies <huw(a)codeweavers.com> > --- > dlls/oleaut32/oleaut.c | 3 +++ > dlls/oleaut32/tests/vartype.c | 3 +++ > 2 files changed, 6 insertions(+) > > diff --git a/dlls/oleaut32/oleaut.c b/dlls/oleaut32/oleaut.c > index 8a22c2e..07db9ff 100644 > --- a/dlls/oleaut32/oleaut.c > +++ b/dlls/oleaut32/oleaut.c > @@ -84,6 +84,9 @@ static CRITICAL_SECTION_DEBUG cs_bstr_cache_dbg = > static CRITICAL_SECTION cs_bstr_cache = { &cs_bstr_cache_dbg, -1, 0, 0, 0, 0 }; > > typedef struct { > +#ifdef _WIN64 > + DWORD pad; > +#endif > DWORD size; > union { > char ptr[1]; How about changing size type to SIZE_T instead? This should have the same effect. Thanks, Jacek

2 1

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

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