October 2015 - Wine-devel - list.winehq.org

Re: [PATCH 1/6] hidclass.sys: Add a processing thread for HID devices
by Nikolay Sivov 09 Oct '15

09 Oct '15

On 08.10.2015 22:34, Aric Stewart wrote: > + buffer_size = RingBuffer_GetBufferSize(ext->ring_buffer); > + RingBuffer_Read(ext->ring_buffer, ptr, packet, &buffer_size); No idea what's going on there, but first call seems to be redundant. Also maybe it makes sense to make RingBuffer_Read return size since it's out-only argument right now?

2 1

Re: [PATCH 1/2] dbghelp: Parse DW_TAG_pointer_type inside dwarf2_parse_subprogram_block.
by Qian Hong 09 Oct '15

09 Oct '15

Sorry, typo in commit message, will resend soon, thanks Michael Müller.

1 0

Re: ntdll: Implement RtlValidRelativeSecurityDescriptor.
by Marcus Meissner 09 Oct '15

09 Oct '15

On Fri, Oct 09, 2015 at 06:20:50PM +0800, Dmitry Timoshkov wrote: > Signed-off-by: Dmitry Timoshkov <dmitry(a)baikal.ru> > --- > dlls/ntdll/ntdll.spec | 2 +- > dlls/ntdll/sec.c | 9 +++++++++ > include/winternl.h | 1 + > 3 files changed, 11 insertions(+), 1 deletion(-) > > diff --git a/dlls/ntdll/ntdll.spec b/dlls/ntdll/ntdll.spec > index ca3561d..1e68ef3 100644 > --- a/dlls/ntdll/ntdll.spec > +++ b/dlls/ntdll/ntdll.spec > @@ -936,7 +936,7 @@ > @ stub RtlUsageHeap > @ cdecl -i386 -norelay RtlUshortByteSwap() NTDLL_RtlUshortByteSwap > @ stdcall RtlValidAcl(ptr) > -# @ stub RtlValidRelativeSecurityDescriptor > +@ stdcall RtlValidRelativeSecurityDescriptor(ptr long long) > @ stdcall RtlValidSecurityDescriptor(ptr) > @ stdcall RtlValidSid(ptr) > @ stdcall RtlValidateHeap(long long ptr) > diff --git a/dlls/ntdll/sec.c b/dlls/ntdll/sec.c > index 360a579..bc5d5a3 100644 > --- a/dlls/ntdll/sec.c > +++ b/dlls/ntdll/sec.c > @@ -558,6 +558,15 @@ NTSTATUS WINAPI RtlValidSecurityDescriptor( > } > > /************************************************************************** > + * RtlValidRelativeSecurityDescriptor [NTDLL.@] > + */ > +BOOLEAN WINAPI RtlValidRelativeSecurityDescriptor(PSECURITY_DESCRIPTOR descriptor, > + ULONG length, SECURITY_INFORMATION info) > +{ > + return RtlValidSecurityDescriptor(descriptor) == STATUS_SUCCESS; > +} Perhaps add a semi-stub FIXME message, in case some app needs the behaviour triggered by the other arguments? Ciao, Marcus

1 0

Re: mshtml: Add IHTMLEditServices stub implementation.
by Jacek Caban 09 Oct '15

09 Oct '15

Hi Dmitry, Please add a test. A very simple one that just calls QueryService and checks its return will be enough. I can see that you used undo mgr as an example, but it has its problems that I'd rather avoid in new code, so it would be nice to improve the patch. On 10/09/15 05:53, Dmitry Timoshkov wrote: > +static HRESULT WINAPI editsvcs_QueryInterface(IHTMLEditServices *iface, REFIID riid, void **ppv) > +{ > + editsvcs *This = impl_from_IHTMLEditServices(iface); > + > + if(IsEqualGUID(riid, &IID_IUnknown)) { > + TRACE("(%p)->(IID_IUnknown %p)\n", This, ppv); > + *ppv = &This->IHTMLEditServices_iface; > + } else if(IsEqualGUID(riid, &IID_IHTMLEditServices)) { > + TRACE("(%p)->(IID_IHTMLEditServices %p)\n", This, ppv); > + *ppv = &This->IHTMLEditServices_iface; > + } else { > + *ppv = NULL; > + FIXME("(%p)->(%s %p)\n", This, debugstr_guid(riid), ppv); > + return E_NOINTERFACE; > + } Please use debugstr_mshtml_guid and add IHTMLEditServices there. > + > +static IHTMLEditServices *create_editsvcs(void) > +{ > + editsvcs *ret = heap_alloc(sizeof(*ret)); Please handle heap_alloc failure here. > + > + ret->IHTMLEditServices_iface.lpVtbl = &editsvcsVtbl; > + ret->ref = 1; > + > + return &ret->IHTMLEditServices_iface; > +} > + > /********************************************************** > * IServiceProvider implementation > */ > @@ -259,6 +381,15 @@ static HRESULT WINAPI ServiceProvider_QueryService(IServiceProvider *iface, REFG > return IWindowForBindingUI_QueryInterface(&This->doc_obj->IWindowForBindingUI_iface, riid, ppv); > } > > + if(IsEqualGUID(&SID_SHTMLEditServices, guidService)) { > + FIXME("SID_SHTMLEditServices\n"); I think it should be TRACE. Thanks, Jacek

1 0

Re: [PATCH 3/4] ole32: Add a stub for OleCreateFromFileEx.
by Dmitry Timoshkov 09 Oct '15

09 Oct '15

Huw Davies <huw(a)codeweavers.com> wrote: > --- a/dlls/ole32/ole32.spec > +++ b/dlls/ole32/ole32.spec > @@ -189,7 +189,7 @@ > @ stdcall OleCreateFromData(ptr ptr long ptr ptr ptr ptr) > @ stdcall OleCreateFromDataEx(ptr ptr long long long ptr ptr ptr ptr ptr ptr ptr) > @ stdcall OleCreateFromFile(ptr ptr ptr long ptr ptr ptr ptr) > -@ stub OleCreateFromFileEx > +@ stdcall OleCreateFromFileEx(ptr ptr ptr long long long ptr ptr ptr ptr ptr ptr ptr) The 2nd parameter should be str, but that's not your fault, probably you've just copied and extended the OleCreateFromFile entry :) -- Dmitry.

2 2

Re: kernel32: add a stub for GetCurrentProcessorNumberEx
by Nikolay Sivov 09 Oct '15

09 Oct '15

Looks like it should forward to RtlGetCurrentProcessorNumberEx, and that one should init fields to zeroes or whatever lowest limits for group/processor number are.

2 1

Re: [PATCH] oledb32: Support VT_NULL on all conversions (try 2)
by Marvin 09 Oct '15

09 Oct '15

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=17215 Your paranoid android. === wvistau64 (64 bit convert) === convert.c:2995: Test failed: got 24 === w2008s64 (64 bit convert) === convert.c:2995: Test failed: got 24 === w7pro64 (64 bit convert) === convert.c:2995: Test failed: got 24 === w864 (64 bit convert) === convert.c:2995: Test failed: got 24 === w1064 (64 bit convert) === convert.c:2995: Test failed: got 24

1 0

Re: [PATCH] oledb32: Support VT_NULL on all conversions
by Marvin 09 Oct '15

09 Oct '15

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=17213 Your paranoid android. === wvistau64 (64 bit convert) === convert.c:2995: Test failed: got 24 === w2008s64 (64 bit convert) === convert.c:2995: Test failed: got 24 === w7pro64 (64 bit convert) === convert.c:2995: Test failed: got 24 === w864 (64 bit convert) === convert.c:2995: Test failed: got 24 === w1064 (64 bit convert) === convert.c:2995: Test failed: got 24

1 0

Re: [PATCH] riched20: Implement set all caps(Ctrl+Shift+A) shortcut key. (try 2)
by Jactry Zeng 09 Oct '15

09 Oct '15

Please ignore this patch. It's wrong. I'll have another try later. 2015-09-14 22:26 GMT+08:00 Jactry Zeng <jzeng(a)codeweavers.com>: > Suppereded patch 114471. > > ChangeLog: > - Use struprW/strlwrW instead of toupperW/tolowerW; > - Remove isalphaW(). > > Thanks Nikolay! > --- > dlls/riched20/editor.c | 30 +++++++++++++++++++++++++++++- > dlls/riched20/editstr.h | 1 + > 2 files changed, 30 insertions(+), 1 deletion(-) > > > > > > -- Regards, Jactry Zeng

1 0

Re: [PATCH 1/3] ws2_32: Implement a basic synchronous TransmitFile (try 2).
by Sebastian Lackner 09 Oct '15

09 Oct '15

On 08.10.2015 03:11, Erich E. Hoover wrote: > This patch adds support for the basic file-transfer operation of > TransmitFile. It reads the file in as "bytes_per_send" chunks, which > it then sends to the destination using WS2_send. This process is > repeated synchronously (until patch 5 adds async support) until the > entire file is sent. > > This version has been updated to use a simple APC-safe NtReadFile-like > routine instead of using NtReadFile. > > > + else if (errno != EAGAIN) > + status = wsaErrno(); wsaErrno() doesn't return a status. Nevertheless, the more critical issue / question I see is, if we want to duplicate ReadFile code into ws2_32. The ntdll version is already very complicated, and your minimal version might not always be sufficient. * Missing handling for server_read_file(). * FILE_GetNtStatus() doesn't match sock_get_ntstatus() exactly. * FD type dependent code is probably simplied a bit too much. The original code behaves different depending on the exact FD_TYPE_* at some places. * NtReadFile will very likely get even more complicated over time, for example when a proper solution for message mode pipes is implemented.

3 2